**** BEGIN LOGGING AT Mon Feb 08 02:59:57 2010 Feb 08 16:46:59 sorry to ask again, but how to get more debug information out of ofono? i start it with ofono -n -d * Feb 08 17:04:45 matgnt: -n -d '*' I believe Feb 08 17:04:58 matgnt: You can also export OFONO_AT_DEBUG=1 to get AT command traces Feb 08 17:05:17 It is inadvisable to have both -d and at debug trace on at the same time ;) Feb 08 17:06:00 denkenz: oh damn, you are so right :) lots of debug information now :) Feb 08 17:06:12 matgnt: And to your previous SimManager problem, give me a trace from oFono using OFONO_AT_DEBUG Feb 08 17:06:23 matgnt: Most likely your sim is locked, or it might be a bug Feb 08 17:07:05 i can use the sim in another phone - without pin. Feb 08 17:07:29 when i query simmanager.getproperties it says "none" for required pin Feb 08 17:07:44 What modem / driver are you using? Feb 08 17:09:09 i use atgen with a wavecom board. it was working some days ago with phonesim and the same wavecom modem, but not now Feb 08 17:09:46 Does it work with phonesim now? Feb 08 17:10:08 when i query simmanager.getproperties i get empty arrays for lockedPins, but empty array for subscribernumbers as well, shouldn't be there a number Feb 08 17:11:08 Depends on whether your SIM has one Feb 08 17:11:29 Usually they do have the field available, but nothing in it Feb 08 17:12:33 It might also be useful to run dbus-monitor --system sender=org.ofono in the background Feb 08 17:12:44 That will get you all the signals oFono is sending Feb 08 17:13:04 ok, i will check the debug output now and check the dbus-monitor. thanks for your help Feb 08 17:13:05 Get me that + OFONO_AT_DEBUG trace and post it on pastebin or email, then I can say more Feb 08 17:27:09 denkenz: when i set "Powered" to true i get only "AT+CRC=1\r" and after that ofono_sim_add_ready_watch() Feb 08 17:27:43 Does your modem respond to the CRC? Feb 08 17:28:39 Basically it sounds like your modem does not respond to commands Feb 08 17:29:02 the CRC is part of initialization procedure in voicecall driver, which never gets to complete Feb 08 17:29:39 when i use direct serical connection with cu i get a OK for this command Feb 08 17:30:05 Then you might want to check whether your modemconf is setup properly Feb 08 17:30:30 For serial devices you need to setup the options properly or it treats it like a raw device Feb 08 17:30:37 This might explain the communications issue Feb 08 17:30:55 directly after connecting via cu i get the modem answer probably for ofno "AT+CRC=...=1 Feb 08 17:31:58 read gatchat/gattty.h Feb 08 17:32:06 Setup your modemconf options appropriately Feb 08 17:33:16 ok, will check. thank you very much :) Feb 08 17:33:19 Most likely the Baud setting is not correct Feb 08 18:31:34 denkenz: ok, i'm a few steps further. now i get a cpin:ready and i can see the VoiceCallManager. but when i use Dial, it seems no AT command is sent to the modem. Feb 08 18:32:09 Does dial return an error? Feb 08 18:33:06 i use dbus-send and i get a timout. no output from dbus-monitor Feb 08 18:34:45 try using the dial-number test script in test/ Feb 08 18:35:05 i did. nothing happens. Feb 08 18:35:36 have all AT commands been responded to? Feb 08 18:36:06 The dial won't start unless the previous commands in the queue have been finished Feb 08 18:36:52 Also, sanity check everything by running phonesim first Feb 08 18:38:00 ok, i will check phonesim. maybe you can see somthing here: http://pastebin.com/m38709391 Feb 08 18:45:00 sigh, I know why Feb 08 18:47:28 why? Feb 08 18:51:05 the CPIN is assumed to be a final response by your modem, no other modem I've ever encountered did it this way Feb 08 18:51:16 all respond with an OK afterwards Feb 08 18:52:37 I will need to think about how to fix it, for now it effectively blocks the command queue Feb 08 18:55:35 so is it a firmware bug or is this beavior possible, according to the specification? Feb 08 19:00:30 unclear Feb 08 19:00:36 The spec does mandate a final response Feb 08 19:00:46 But one of the examples in the spec seems to omit the OK Feb 08 19:04:43 for now I suggest hardcoding the return to be READY and going on with your testing Feb 08 19:04:51 I should have a fix later this week Feb 08 19:05:53 sounds great. thanks a lot :) Feb 08 22:01:59 padovan: Is there a reason why you're using g_timeout_add instead of setting the timeout on dbus_connection_send_with_reply? Feb 08 22:05:22 denkenz: yes. I didn't know that dbus_connection_send_with_reply supports timeout. :) Feb 08 22:06:53 padovan: Ok lets try it using dbus_connection_send_with_reply only, should be much cleaner Feb 08 23:57:02 matgnt: I've pushed a quirk for wavecom's whacky cpin handling, you will have to create a modem driver that makes use of it Feb 09 00:04:34 denkenz: ok, thanks. i will have a look at it tomorrow. dont know how to create my own modem driver, but i will try ;) Feb 09 00:05:22 just follow plugins/g1.c or similar, straightforward Feb 09 00:06:18 ok. i will try tomorrow and then i will come back and report **** ENDING LOGGING AT Tue Feb 09 02:59:56 2010