qtMoko getting bad Network Time

Jorge xxopxe at gmail.com
Thu Jan 8 02:37:04 CET 2015


Wait... If I apply to the calue 136 the code from

https://github.com/freesmartphone/cornucopia/blob/master/fsogsmd/src/lib/consts.vala#L975

I get -120 minutes, which is Ok:

---------------------------
  public int ctzvToTimeZone( int ctzv )     // ctzv = 136
{
   var bcd1 = ( ctzv / 0x10 );        // =8
   var bcd2 = ( ctzv % 0x10 ) & 0x7;        // =0
   var zone = bcd2 * 10 + bcd1;        // =8
   var sign = ( ctzv & 0x08 ) == 8;        // true
   return sign ? -zone * 15 : zone * 15;        // =-120
}
---------------------------

This assumes the number is encoded as a 8 bit integer, with the 4 bit 
being the sign. There is a comment that seem s to refer to the GSM spec.

The ofono and qtmoko give the same result (+34 hours), and both seem to 
expect the sign being in a string form ("+" or "-"). ofono uses atoi(), 
qtmoko parses it by hand.

Seems that my provider/modem would work with FSOs interpretation, but 
not with ofono&qtmoko.


Jorge



On 07/01/15 16:03, Jorge wrote:
> Thanks.
>
> I've found this wording for the time zone info [1][2]:
>
> "(indicates the difference, expressed in quarters of an hour, between 
> the local time and GMT; range
> -96...+96)"
>
> So, a value of 136 would not be valid. I'll try to track this one.
>
>
> Jorge
>
>
> [1] 
> http://www.etsi.org/deliver/etsi_ts/127000_127099/127007/08.03.00_60/ts_127007v080300p.pdf
> [2] download-c.huawei.com/download/downloadCenter?downloadId=16235
>
> On 07/01/15 01:08, Paul Wise wrote:
>> On Wed, Jan 7, 2015 at 8:51 AM, Jorge wrote:
>>
>>> Thanks for the confirmation. A question, can you confirm that the 
>>> session
>>> excerpt is the one of interest, and it actually says the provider is 
>>> giving
>>> the +34 time zone? That would be strange, being the biggest celular 
>>> provider
>>> around here. With my Nokia dumbphone I've never seen something like 
>>> that
>>> (OTOH, time updatting hasn't worked for me at all last time I needed 
>>> it).
>> America/Montevideo seems to be two hours behind UTC.
>>
>> The log confirms that QtMoko is definitely looking for the GMT-34 
>> timezone.
>>
>> Looking at the QtMoko source code, +CTZV is an "Unsolicited result
>> code for time zone change events".
>>
>> https://github.com/radekp/qtmoko/blob/master/doc/html/atcommands.html
>>
>> Your operator's CTZV value is 136.
>>
>> The code handling the +CTZV message is here:
>>
>> https://github.com/radekp/qtmoko/blob/master/devices/neo/src/plugins/phonevendors/neo/vendor_neo.cpp#L683 
>>
>>
>> That code produces 34 hours in front of UTC for your operator's CTZV 
>> value.
>>
>> There are two other FLOSS implementations of CTZV handling that I know
>> of, FSO and oFono:
>>
>> http://www.freesmartphone.org/
>> https://01.org/ofono
>>
>> Looking at the FSO code, it produces 8 hours behind UTC for your
>> operator's CTZV value.
>>
>> https://github.com/freesmartphone/cornucopia/blob/master/fsogsmd/src/lib/consts.vala#L975 
>>
>>
>> Looking at the oFono code, it produces 34 hours in front of UTC for
>> your operator's CTZV value.
>>
>> https://git.kernel.org/cgit/network/ofono/ofono.git/tree/drivers/atmodem/network-registration.c#n841 
>>
>>
>> I then tried to find a reference for how to do this correctly, since
>> none of the FLOSS implementations I can find produce a result that
>> matches TZ=America/Montevideo.
>>
>> The closest I could find is a reference to the value being an offset
>> from Universal Time in units of 15 minutes.
>>
>> Not sure what the right answer is here, I think you will need to do
>> more testing with the same SIM card in a variety of phones from you
>> and your friends and record the resulting timezone offsets. If you can
>> also record the CTZV value (some phones have debug info available)
>> that would be helpful too, in case different phones get different
>> values or use another command. Start by setting the timezone UTC, then
>> turn on automatic timezone info and then find out what the resulting
>> timezone offset is. If any of them then get the correct timezone
>> you'll need to figure out how.
>>
>




More information about the community mailing list