qtMoko getting bad Network Time
xxopxe at gmail.com
Thu Jan 8 02:37:04 CET 2015
Wait... If I apply to the calue 136 the code from
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.
On 07/01/15 16:03, Jorge wrote:
> I've found this wording for the time zone info :
> "(indicates the difference, expressed in quarters of an hour, between
> the local time and GMT; range
> So, a value of 136 would not be valid. I'll try to track this one.
>  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
>>> excerpt is the one of interest, and it actually says the provider is
>>> the +34 time zone? That would be strange, being the biggest celular
>>> around here. With my Nokia dumbphone I've never seen something like
>>> (OTOH, time updatting hasn't worked for me at all last time I needed
>> America/Montevideo seems to be two hours behind UTC.
>> The log confirms that QtMoko is definitely looking for the GMT-34
>> Looking at the QtMoko source code, +CTZV is an "Unsolicited result
>> code for time zone change events".
>> Your operator's CTZV value is 136.
>> The code handling the +CTZV message is here:
>> That code produces 34 hours in front of UTC for your operator's CTZV
>> There are two other FLOSS implementations of CTZV handling that I know
>> of, FSO and oFono:
>> Looking at the FSO code, it produces 8 hours behind UTC for your
>> operator's CTZV value.
>> Looking at the oFono code, it produces 34 hours in front of UTC for
>> your operator's CTZV value.
>> 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