**** BEGIN LOGGING AT Tue Jun 08 02:59:56 2010
Jun 08 10:23:28 <akiniemi_> 20:36 < denkenz> akiniemi, pessi: Do you know if the RAT can change on the same cell? E.g. drop from edge->gsm or hspa->umts
Jun 08 10:23:31 <akiniemi_> 20:36 < denkenz> akiniemi, pessi: Do you know if the RAT can change on the same cell? E.g. drop from edge->gsm or hspa->umts
Jun 08 10:23:43 <akiniemi_> sheez...
Jun 08 10:24:25 <akiniemi_> denkenz: I don't think so. Both edge and hsxpa support are indicated by the cell.
Jun 08 10:24:58 <akiniemi_> denkenz: then, e.g., HSDPA or HSUPA channels get allocated is a different story.
Jun 08 10:25:55 <akiniemi_> denkenz: but I think the set of services supported by a cell is static.
Jun 08 14:01:00 <denkenz> kvalo: Paste a log of your operator name issue?
Jun 08 14:01:08 <denkenz> kvalo: I probably broke something
Jun 08 14:02:18 <kvalo> denkenz: I'll find it
Jun 08 14:05:31 <wagi> denkenz: I did some testing with the version I posted this morning. Results are good :)
Jun 08 14:09:50 <kvalo> denkenz: sent to your gmail address
Jun 08 14:10:58 <denkenz> wagi: I'm looking at it now, so you basically don't query at all
Jun 08 14:14:18 <wagi> denkenz: exactly. I just wait for the notifications
Jun 08 14:14:48 <wagi> I think for huawei I would do exactly the same
Jun 08 14:15:56 <denkenz> wagi: Then can't you just save off the owcti/octi info into ->tech and report it in creg_notify?
Jun 08 14:16:33 <denkenz> otherwise according to your patch, you always report status/lac/ci as -1
Jun 08 14:16:45 <wagi> oops
Jun 08 14:17:18 <wagi> do we get always a creg_notify after a ossysi/ouwcti/octi info?
Jun 08 14:17:43 <denkenz> I think so, probably why your patch works so well ;)
Jun 08 14:17:54 <wagi> hehe
Jun 08 14:19:29 <wagi> just as side note. I'll try to measure the tech during for car ride. So I'm interested to get them as soon as possible.
Jun 08 14:19:41 <wagi> s/for/a/
Jun 08 14:20:21 <denkenz> I think you're nearly there
Jun 08 14:23:20 <denkenz> kvalo: Can't find anything wrong...
Jun 08 14:24:04 <wagi> btw, finally my huawei e160 works!! :)
Jun 08 14:24:51 <denkenz> yeah all the Huaweis should work more or less
Jun 08 14:26:41 <kvalo> denkenz: ok
Jun 08 14:28:06 <denkenz> My E160G 'just works', pretty sweet
Jun 08 14:28:15 <denkenz> even waits for sim to initialize, etc :)
Jun 08 14:32:02 <kvalo> :D
Jun 08 14:33:56 <wagi> during the ride I noticed that if the connection is lost there is no reconnect. only if the technology has changed from umts to edge then there was for short time a connection. I guess this is something in connman
Jun 08 14:35:24 <denkenz> wagi: Not sure, we have not stress tested the ppp part roaming across cells, etc
Jun 08 14:40:23 <wagi> wagi: this was with the icon 451. the e160 has problems already at my desk withouth moving around.
Jun 08 14:40:53 * wagi has to warm.... 28 degree celsius
Jun 08 14:41:54 <wagi> denkenz: wanna see the log without the _status_notify calls in the ossysi/ouwcti/octi notify functions?
Jun 08 14:42:04 <denkenz> wagi: Ah, the 451 is a high-speed interface, if it fucks up, oFono has nothing to do with it
Jun 08 14:42:11 <denkenz> wagi: sure
Jun 08 14:42:56 <denkenz> wagi: As long as the modem notifies us about context state, we should be handling it
Jun 08 14:43:37 <wagi> http://pastebin.com/Cyrqz1JR
Jun 08 14:46:24 <wagi> if this is patch then is okay, I'll implement the same for huawei
Jun 08 14:46:26 <denkenz> the owcti / octi queries seem to get the wrong info
Jun 08 14:46:48 <wagi> which line?
Jun 08 14:47:02 <denkenz> 192
Jun 08 14:47:06 <denkenz> of the log
Jun 08 14:48:57 <wagi> that's the first update. so this should match to the first OUWCTI entry
Jun 08 14:49:21 <denkenz> #
Jun 08 14:49:22 <denkenz> ofonod[3233]: App:> AT_OCTI?\r
Jun 08 14:49:24 <denkenz> #
Jun 08 14:49:26 <denkenz> ofonod[3233]: App:< \r\n_OCTI: 1,0\r\n\r\nOK\r\n
Jun 08 14:49:27 <denkenz> #
Jun 08 14:49:29 <denkenz> ofonod[3233]: drivers/atmodem/network-registration.c:option_octi_ouwcti_to_tech() ossysi -1 octi 1 ouwcti 1 tech 2
Jun 08 14:49:33 <denkenz> The OCTI you're interested is the 2nd number
Jun 08 14:49:37 <denkenz> octi should be 0 here
Jun 08 14:49:56 <denkenz> OUWCTI is wrong as well
Jun 08 14:50:00 <denkenz> but it just works by luck
Jun 08 14:50:59 <wagi> so it's not the first digit? it's the second? pfff, stupid me
Jun 08 14:51:19 <denkenz> it actually depends
Jun 08 14:51:24 <denkenz> the unsolicited version has a single number
Jun 08 14:51:26 <denkenz> the query has 2
Jun 08 14:52:26 <wagi> aha, didn't know. just another thing I could have read up in the standard...
Jun 08 14:53:42 <denkenz> yeah, the standard does it sometimes for really legacy commands
Jun 08 14:53:44 <denkenz> like CREG
Jun 08 14:53:54 <denkenz> The newer commands separate the unsolicited and query prefixes
Jun 08 14:53:55 <wagi> Can I handle the query results also in the _notify functions? Or should I add callbacks? I would prefer to handle in the notifies.
Jun 08 14:54:25 <denkenz> you can, see erinfo_notify
Jun 08 14:55:38 <wagi> cool
Jun 08 14:55:54 <denkenz> wagi: Seems that when you roam off 2g to 3g, only the ossysi is fired, not owcti
Jun 08 14:56:21 <denkenz> so guess we need to track ossysi too
Jun 08 14:56:38 <wagi> no problem, I'm doing it already
Jun 08 15:03:12 <denkenz> wagi: yeah, but I think we need to tweak the logic a bit
Jun 08 15:03:14 <denkenz> ofonod[3233]: App:< \r\n_OSSYSI: 2\r\n
Jun 08 15:03:15 <denkenz> ofonod[3233]: drivers/atmodem/network-registration.c:option_octi_ouwcti_to_tech() ossysi 2 octi 0 ouwcti 0 tech -1
Jun 08 15:03:27 <denkenz> If OSSYSI is reported as 2, and OWCTI is not reported, lets default to something
Jun 08 15:03:37 <denkenz> otherwise tech becomes unknown when you roam onto 3g cell
Jun 08 15:04:32 <wagi> ouwcti was set to 0 before, right? 
Jun 08 15:04:48 <denkenz> yeah, because you roamed onto 2g cell
Jun 08 15:05:02 <wagi> but no octi update so far
Jun 08 15:05:19 <wagi> ah no
Jun 08 15:05:27 <denkenz> seems they get reported in this order: octi ossysi [owcti]
Jun 08 15:06:23 <wagi> okay
Jun 08 15:06:42 <wagi> here is the log for the query result parsing:
Jun 08 15:06:45 <wagi> ofonod[3556]: App:< \r\n_OUWCTI: 1,1\r\n\r\nOK\r\n
Jun 08 15:06:45 <wagi> ofonod[3556]: drivers/atmodem/network-registration.c:option_octi_ouwcti_to_tech() ossysi -1 octi -1 ouwcti 1 tech 2
Jun 08 15:06:48 <wagi> ofonod[3556]: App:> AT_OCTI?\r
Jun 08 15:06:50 <wagi> ofonod[3556]: App:< \r\n_OCTI: 1,0\r\n\r\nOK\r\n
Jun 08 15:06:53 <wagi> ofonod[3556]: drivers/atmodem/network-registration.c:option_octi_ouwcti_to_tech() ossysi -1 octi 0 ouwcti 1 tech 2
Jun 08 15:07:25 <denkenz> yeah, that's looking better
Jun 08 15:07:29 <wagi> great
Jun 08 15:07:51 <denkenz> also, you can probably skip ossysi query and guess it based on octi / owcti query results
Jun 08 15:09:57 <denkenz> e.g. if octi:0, set ossysi to 3
Jun 08 15:10:16 <denkenz> if octi > 0, set ossysi to 0, etc
Jun 08 15:12:21 <wagi> not sure if I understand you right. so if octi >0 take this value for tech, if ouwcti > 0 take this value for tech. ouwcti overrules octi?
Jun 08 15:14:42 <denkenz> no, I mean something like
Jun 08 15:14:50 <denkenz> octi goes to 1, set ossysi to 0
Jun 08 15:14:57 <denkenz> octi goes to 0, set ossysi to 3
Jun 08 15:15:06 <denkenz> then ossysi goes 2, set owcti to 1
Jun 08 15:15:58 <denkenz> Just make intelligent guesses since this crap doesn't get reported atomically
Jun 08 15:16:02 <denkenz> Even Huawei got this right
Jun 08 15:17:07 <wagi> hehe
Jun 08 15:17:43 <wagi> okay, I'll add this and put the log again on pastebin
Jun 08 15:18:48 <wagi> ah you suggest not to read the ossysi value the modem at all
Jun 08 15:19:22 <denkenz> keep track of the unsolicited, but you don't need the query
Jun 08 15:20:30 <wagi> there was no query for the ossysi. the modem reports error when doing this
Jun 08 15:20:45 <denkenz> AT_OSSYS?
Jun 08 15:20:58 <wagi> != OSSYSI
Jun 08 15:21:07 <denkenz> you sure?
Jun 08 15:21:28 <wagi> quite sure
Jun 08 15:21:37 <denkenz> ok then, my bad
Jun 08 15:22:41 <wagi> I think the sequence is always "octi ossysi [ouwcti]" as you identified it
Jun 08 15:23:44 <wagi> but between ossysi and ouwcti there can be a long delay
Jun 08 15:25:03 <denkenz> I think its simply not reported when roaming off 2g to 3g
Jun 08 15:25:19 <denkenz> I only see owcti when roaming from 3g to 2g and when roaming from 3g to 3g
Jun 08 15:25:49 <denkenz> more testing data needed
Jun 08 15:26:04 <wagi> I have the log from my drive from today
Jun 08 15:26:08 <wagi> a lot of roaming
Jun 08 15:26:43 <denkenz> holtmann: What do you think of adding a timestamp to our logs? Or is that too expensive?
Jun 08 15:27:46 <holtmann> It would be pretty expensive. You have a system call for everything. Except you read it directly with read(). Not sure if that works on non-socket fds.
Jun 08 15:27:47 <wagi> http://pastebin.com/R9fT66zL
Jun 08 15:28:18 <wagi> that one is with the wrong _status_notify calls in the owcti_notify
Jun 08 15:28:40 <denkenz> holtmann: What about some sort of high performance timer register?
Jun 08 15:28:55 <denkenz> holtmann: Does glibc provide some hacks for that on popular platforms?
Jun 08 15:29:05 <holtmann> Not that I know of.
Jun 08 15:29:27 <denkenz> hmm, then perhaps make it optional?
Jun 08 15:29:35 <denkenz> Timing info is actually important for this crap
Jun 08 15:29:49 <denkenz> e.g. does stuff happen before a cell change, etc
Jun 08 15:30:30 <wagi> --enable-debug-timestamps?
Jun 08 15:31:13 <denkenz> if we can swing an if () it would be better
Jun 08 15:31:25 <denkenz> too painful to rebuild just to turn this on
Jun 08 15:31:33 <wagi> very true
Jun 08 15:33:07 <denkenz> #
Jun 08 15:33:09 <denkenz> ofonod[2493]: App:< \r\n_OSSYSI: 3\r\n
Jun 08 15:33:15 <denkenz> when it goes to 3, we should reset octi/owcti
Jun 08 15:34:16 <wagi> okay, done
Jun 08 15:35:19 <denkenz> hah
Jun 08 15:35:30 <denkenz> OWCTI goes to 4 when a gprs context is activated
Jun 08 15:35:56 <denkenz> and back to 1 when it is deactivated
Jun 08 15:35:59 <denkenz> all within the same cell
Jun 08 15:37:12 <wagi> MM inteprets OUWCTI: 4 as hspa
Jun 08 15:37:37 <denkenz> yeah, it seems owcti reports the current technology being used
Jun 08 15:37:47 <denkenz> not the network capability
Jun 08 15:38:18 <denkenz> which is different from octi, which reports edge/gprs
Jun 08 15:38:19 <denkenz> bizarre
Jun 08 15:39:59 <wagi> I though octi does the same as ouwcti
Jun 08 15:52:09 <wagi> reseting when "OSSYSI: 3" will lead to a long delay on the update, since octi/ouwcti updates can come late
Jun 08 15:53:25 <denkenz> yeah, but then you're just faking it
Jun 08 15:54:20 <wagi> okay, let me collect some logs 
Jun 08 16:05:00 <wagi> I found an anoying problem. If OUWCTI comes after CREG the update on the tech has to wait until the next CREG. In my case there was tech = -1 as I moved to a window and for the whole time it stayed on -1 until I moved a bit around to force CREG again
Jun 08 16:05:06 <wagi> http://pastebin.com/BrDzCB7y
Jun 08 16:05:12 <wagi> that's the log 
**** ENDING LOGGING AT Wed Jun 09 02:59:57 2010