qtMoko getting bad Network Time

[EdorFaus]

On 01/08/2015 02:37 AM, Jorge wrote:
> 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.

It's a bit weirder than that actually. The 4th-lowest bit is used as the
sign, yes, but the rest are passed through a BCD decoder while swapping
the high and low bits.

This is a strange enough encoding that I'd guess they actually had to
look at the standard to figure out how it works.
Looking at the comment you linked to, that seems to be what they did.


> 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.

Perhaps some modems do this BCD decoding internally, while others don't?
That might explain them expecting sign-value instead of BCD, if they had
only encountered the former...


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

I think you are correct.

Assuming that FSO actually have checked the standard, and thus have done
this correctly, I think this counts as a bug for oFono and QtMoko.


>> On 07/01/15 01:08, Paul Wise wrote:
>>> 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.

This is a bit odd - that method is being registered to handle CTZV, but
it appears to be designed to handle CCLK responses (with CTZU on), not
CTZV responses.
(Note: the above CCLK vs CTZU vs CTZV info is based only on a tiny bit
of googling, so may be wrong.)

For the CTZV message given, it seems to me that this method would not
produce a value at all, for two main reasons:

- it calls QAtUtils::nextString() to get the time string; that method
looks for a string enclosed in quotes, which doesn't exist here, so an
empty string is returned. Hence zoneIndex starts out being 0.
- even if it did return the number, the following code looks for a sign
character (+ or -), and since this CTZV value doesn't contain one,
zoneIndex would end up being 0.

When zoneIndex is zero, this method returns on line 704, without doing
any time/timezone calculation or setting.


>>> The closest I could find is a reference to the value being an offset
>>> from Universal Time in units of 15 minutes.

That would explain oFono's code, if this was the closest they found as
well. It wouldn't explain QtMoko's code though.

Regards,
Frode Austvik