**** BEGIN LOGGING AT Mon Dec 07 02:59:57 2009 Dec 07 07:34:36 denkenz, I found that you have add code to sedn AT+CFUN when AT*EMRDY ready. Dec 07 07:34:59 denkenz, it works fine, on my MBM card works fine with it. Dec 07 07:35:09 denkenz, I can close the bug. ;-) Dec 07 07:37:51 bug #8040 Dec 07 08:17:29 denkenz, which modem do you use has E2IPCFG? my F3507 dose support the AT Command. Dec 07 08:18:53 Only the F36xx support E2IPCFG. Dec 07 08:19:34 denkenz, Ok, I can try to lend Samo from support guys. :-) thanks! Dec 07 08:20:18 s/samo/samos Dec 07 08:20:28 which has f3607 built in Dec 07 08:31:31 martin_lab: Btw. I did change DHCP handling in ConnMan to remove dead and old code. Hope I didn't break anything. Please double check with your setup. Dec 07 08:34:13 ok Dec 07 08:34:48 Mainly the task exit stuff and the pending bits you added. I forgot how to test these. Dec 07 16:18:52 holtmann: Can you prod our Swedish friends to see if there are any commands for signal strength reporting Dec 07 16:19:11 holtmann: Polling CSQ doesn't seem like a good idea, and CIND is just yucky Dec 07 16:26:54 I think the official Ericsson way is CIND. Dec 07 16:27:04 At least that is what they did for ModemManager. Dec 07 16:28:57 yuck, ok Dec 07 16:35:28 I can ask, but expect the answer will be CIND. Dec 07 16:35:57 Won't hurt Dec 07 16:36:15 CIND is a bit coarse Dec 07 16:36:44 We need same info for HSO Dec 07 16:43:52 Did you check that CIND is not working for HSO? Dec 07 16:58:02 I'm sure HSO has its own one Dec 07 16:58:11 Not all modems report CIND Dec 07 17:02:16 e.g. looks like option uses _OSQI Dec 07 17:04:09 Yeah. And another one. Dec 07 17:05:01 Also sounds like Option has SIM status type command too for phonebook/sms/sim ready Dec 07 17:05:15 Where did you find these information? Dec 07 17:05:44 http://trac.warp.es/wader/browser/trunk/wader/common/hardware/option.py?rev=270 Dec 07 17:08:56 While you are at it, please also enable the band reporting. So we at least see the AT commands. Dec 07 17:09:55 band reporting might have to wait until next year Dec 07 17:10:09 Actually, we already report technology Dec 07 17:10:27 band selection will have to wait til next year Dec 07 17:12:53 I don't wanna have it implemented. Just enable the notifications. So we can see what the hardware does in the logs. Dec 07 17:12:56 Could be helpful. Dec 07 17:13:36 sure, which one you want enabled? Dec 07 17:14:37 All of them that you find in the Wader hardware quirks. Dec 07 17:14:45 Just enable them. Dec 07 17:14:49 heh, ok Dec 07 20:12:00 holtmann: So we still ok with stuffing signal_quality stuff for invidual vendors into atmodem as quirks? Dec 07 20:13:27 alternatives are to do it in the modem driver, but this backdoor approach isn't elegant Dec 07 20:17:11 can driver push atoms yet? Dec 07 20:17:35 eh? Dec 07 20:18:04 for things like that signal quality Dec 07 20:18:13 or is that not what was meant? Dec 07 20:18:19 'push atoms'? Dec 07 20:23:43 I mean can new atoms be added to the .c driver instead of modifying atmodem Dec 07 20:24:35 yes Dec 07 20:24:49 okay Dec 07 20:28:31 holtmann: And option card also takes itself off the usb bus when using CFUN=0 Dec 07 20:28:32 fuckin a Dec 07 20:29:36 atoms? Dec 07 20:36:00 denkenz: Whatever makes the card work right now. Long term we might have to have a separate atom for signal strength. Dec 07 20:37:02 holtmann: Perhaps, though that is really just silly :P Dec 07 20:37:57 Can we combine with band selection or things like that. Where everything is different in all modems anyway. Dec 07 20:38:20 band selection will be its own proper atom Dec 07 20:38:33 netreg is for the most part identical everywhere Dec 07 20:38:44 Except for the bogus unsolicited signal quality Dec 07 20:38:51 someone in 3GPP should be shot Dec 07 20:39:04 There is nobody left anymore to be shot. Dec 07 20:39:21 Have they been shot already? Dec 07 20:39:29 I would assume so ;) Dec 07 20:39:41 Damn, I'm late to the party then Dec 07 20:40:06 Yep. Dec 07 23:07:23 holtmann: http://pastebin.ca/1706176 Dec 07 23:07:37 Can you apply and tell me what your option hardware does Dec 07 23:07:47 I can't seem to catch any 3G signal from AT&T here Dec 07 23:07:57 Just push it. Dec 07 23:08:06 And i find my Option modem and SIM card. Dec 07 23:09:03 holtmann: No don't wanna, since some of it belongs in gprs Dec 07 23:09:21 holtmann: It seems Option decided not to use the CREG/CGREG fields and implemented their own hack Dec 07 23:09:23 Chicken. Dec 07 23:09:51 No seriously, I suspect half of them belong in netreg.c and some in gprs.c :P Dec 07 23:09:58 No idea which ones tho :) Dec 07 23:11:34 patching file drivers/atmodem/network-registration.c Dec 07 23:11:35 Hunk #1 succeeded at 524 (offset -19 lines). Dec 07 23:11:35 Hunk #2 FAILED at 688. Dec 07 23:11:35 1 out of 2 hunks FAILED -- saving rejects to file drivers/atmodem/network-registration.c.rej Dec 07 23:13:53 ah I suppose I should push my changes first Dec 07 23:14:12 Push the whole thing. You can always move them around anyway. Dec 07 23:14:32 Ok fine Dec 07 23:14:41 I really don't mind having git history. git is really good at this actually. Dec 07 23:15:39 ok pushed Dec 07 23:17:57 ofonod[11529]: App:> AT_OSSYS=1\r Dec 07 23:17:57 ofonod[11529]: App:< \r\nOK\r\n Dec 07 23:17:58 ofonod[11529]: App:> AT_OCTI=1\r Dec 07 23:17:58 ofonod[11529]: App:< \r\nOK\r\n Dec 07 23:17:58 ofonod[11529]: App:> AT_OSQI=1\r Dec 07 23:17:58 ofonod[11529]: App:< \r\nOK\r\n Dec 07 23:18:00 ofonod[11529]: App:> AT+CREG?\r Dec 07 23:18:02 ofonod[11529]: App:< \r\n+CREG: 2,1,"560E","6E32"\r\n\r\nOK\r\n Dec 07 23:18:04 Anything special I need to look out for? Dec 07 23:18:35 you were already registered Dec 07 23:18:48 try on a non-registered dongle Dec 07 23:19:13 roughly you should see _OSSYSI: 0-3 Dec 07 23:19:18 _OCTI: 0-3 Dec 07 23:19:23 _OWCTI: 0-4 Dec 07 23:19:25 I wasn't, but maybe plugging it in registers. Dec 07 23:19:31 it does Dec 07 23:19:37 power down + up? Dec 07 23:20:32 ofonod[11529]: App:< \r\n+CREG: 1,"560E","6E32"\r\n\r\n+CGREG: 1,"560E","6E32"\r\n Dec 07 23:20:33 ofonod[11529]: App:< \r\n_OSSYSI: 0\r\n Dec 07 23:20:33 ofonod[11529]: OSSYSI mode: 0 Dec 07 23:20:54 _OCTI 1: GSM, OCTI 2: GPRS, OCTI 3: EDGE Dec 07 23:21:19 OWCTI 1: UMTS, OWCTI 2: HSDPA, OWCTI 3: HSUPA, OWCTI 4: HSDPA+HSUPA Dec 07 23:21:31 Now attach Dec 07 23:21:57 Did attach. context active. Nothing. Dec 07 23:22:23 ofonod[11529]: App:< \r\n_OSIGQ: 18,0\r\n Dec 07 23:22:23 ofonod[11529]: App:< \r\n_OSIGQ: 17,0\r\n Dec 07 23:22:23 ofonod[11529]: App:< \r\n_OSIGQ: 18,0\r\n Dec 07 23:22:28 Covering the dongle gives me this. Dec 07 23:22:39 Well at least signal reporting works :) Dec 07 23:23:10 That is good. We need that for ConnMan and its UI. Dec 07 23:23:44 Try detach / attach? Dec 08 00:04:08 we still need some kind of powered signal on the telepathy bindings if I understand robert properly Dec 08 00:04:15 robot* Dec 08 00:04:36 how is that different? Dec 08 00:07:20 tmzt: What are you talking about? There are Powered property changed signals sent. Dec 08 00:07:28 denkenz: No changes for tech so far. Dec 08 00:07:45 Should have used my laptop. The desktop is so hard to move. Dec 08 00:08:07 You might wanna add code to retrieve the initial values of these and not wait until the first notification. Dec 08 00:08:35 I might actually end up querying them on a CGREG Dec 08 00:08:44 Instead of waiting for unsolicited Dec 08 00:08:50 sorry, must be an old debate Dec 08 00:09:15 Robot101: do you know this issue and why it was a point of contention? Dec 08 00:09:35 Seems I am stuck in a GSM only zone. Normally this area flips between UMTS and GSM. Dec 08 00:09:52 How can I trigger a AT+COPS=? from the API? Dec 08 00:11:06 Which TTY's are you using ttyHS0 and ttyHS1, right? Dec 08 00:11:54 Or are these notifications limit to one TTY again. Dec 08 00:12:08 holtmann: 'ProposeScan' should do the AT+COPS=? correct me if i am wrong. Dec 08 00:12:21 what zhenhua said Dec 08 00:12:39 Dunno, I'm ussing whichever ones are labeled Control and Application Dec 08 00:12:46 They might be different depending on your dongle Dec 08 00:13:26 That one gives me ERROR? Dec 08 00:13:32 We need a propose-scan test script. Dec 08 00:13:55 Seems like with activated context you can't scan. Dec 08 00:14:06 Btw, I do get _OCTI, but usually it is _before_ CGREG Dec 08 00:15:12 And I honestly don't know what the OCTI actually refers to, GPRS network registration or Network Dec 08 00:18:34 I leave this running over night and see if something changes. Dec 08 00:23:13 And worst case, I take it for a drive tomorrow morning. I have enough UMTS black spots. Dec 08 00:23:45 yep Dec 08 00:24:00 I'll be in 3G area next week, so I might do some testing there too Dec 08 00:24:47 We have a similar command for the MBM cards. Did you add that one, too. Dec 08 00:25:05 Then I stick SIM cards in both devices and go driving. Dec 08 00:25:11 MBM reports technology in CGREG Dec 08 00:25:16 that one is sane actually Dec 08 00:25:26 They do have this other one. Dec 08 00:25:46 name? Dec 08 00:26:37 *ERINFO Dec 08 00:26:50 That one's capability though Dec 08 00:26:53 Not the selected tech Dec 08 00:27:01 if (g_at_result_iter_next(&iter, "*ERINFO:") == FALSE) Dec 08 00:27:01 return; Dec 08 00:27:01 g_at_result_iter_next_number(&iter, &mode); Dec 08 00:27:01 g_at_result_iter_next_number(&iter, &gsm); Dec 08 00:27:01 g_at_result_iter_next_number(&iter, &umts); Dec 08 00:27:01 connman_info("network capability: GSM %d UMTS %d", gsm, umts); Dec 08 00:27:13 Yes, but add it for fun. You see it either shows GSM or UMTS. Dec 08 00:27:15 Never both. Dec 08 00:27:37 Probably the way your towers are setup Dec 08 00:27:43 In fact it should never be both :) Dec 08 00:28:20 However, ERINFO is not unsolicited Dec 08 00:28:38 Yes it is. Dec 08 00:28:41 So not sure what I would do with it exactly besides querying on every CREG change Dec 08 00:29:03 Is it? lemme check Dec 08 00:29:34 Ah yep you're right Dec 08 00:30:05 Just add it. Then we have proper information in the logs at least and can see if it helps us. Dec 08 00:30:42 ok, lemme add it to MBM driver for now Dec 08 00:32:11 btw, you sure mode gets reported in unsolicited notification? Dec 08 00:36:35 holtmann: Anyway pushed, lets see what it gives us Dec 08 00:52:34 ofonod[11529]: App:< \r\n_OSIGQ: 17,0\r\n Dec 08 00:52:34 ofonod[11529]: App:< \r\n_OCTI: 0\r\n Dec 08 00:52:35 ofonod[11529]: OCTI mode: 0 Dec 08 00:52:35 ofonod[11529]: App:< \r\n+CREG: 1,"5620","5EEF"\r\n\r\n+CGREG: 1,"5620","5EEF"\r\n Dec 08 00:52:35 ofonod[11529]: App:> AT+COPS=3,2\r Dec 08 00:52:35 ofonod[11529]: App:< \r\nOK\r\n Dec 08 00:52:37 ofonod[11529]: App:> AT+COPS?\r Dec 08 00:52:39 ofonod[11529]: App:< \r\n+COPS: 0,2,"26201",2\r\n\r\nOK\r\n Dec 08 00:52:41 ofonod[11529]: App:> AT+COPS=3,0\r Dec 08 00:52:43 ofonod[11529]: App:< \r\nOK\r\n Dec 08 00:52:45 ofonod[11529]: App:> AT+COPS?\r Dec 08 00:52:47 ofonod[11529]: App:< \r\n+COPS: 0,0,"T-Mobile D",2\r\n\r\nOK\r\n Dec 08 00:52:49 ofonod[11529]: App:< \r\n_OSIGQ: 6,0\r\n Dec 08 00:52:51 ofonod[11529]: App:< \r\n_OSIGQ: 5,0\r\n Dec 08 00:52:55 You got lucky. Dec 08 00:54:49 With that signal strength it should be UMTS now. Dec 08 01:07:29 eh? Dec 08 01:08:10 Funny how COPS reports UMTS yet CTI/WCTI do not Dec 08 01:08:17 Sigh Dec 08 01:08:36 What Option card are you using btw? Dec 08 02:48:53 denkenz: ping Dec 08 02:49:57 denkenz: for hfp_release_specific, my plan is to simply use CHLD=1x, if phone doesn't support CHLD=1x, what we should do? Dec 08 02:54:06 report error or use CHUP to release it if this one is the active call Dec 08 02:54:24 i would perfer the second option Dec 08 02:57:03 I think we should just return the error Dec 08 02:57:24 oFono will take care of using CHUP if necessary Dec 08 02:58:50 ok **** ENDING LOGGING AT Tue Dec 08 02:59:56 2009