Re: qtMoko getting bad Network Time
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.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: qtMoko getting bad Network Time
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. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko & Firefox OS
Hi all, anybody took over QtMoko maintanence? Seems that Radek will not release any new version. If not, is anybody working on Firefox OS port to GTA02/4? -- Peter Viskup ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtMoko getting bad Network Time
Hi, On Wed, Jan 7, 2015 at 4:08 AM, Paul Wise wrote: > 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". > > Your operator's CTZV value is 136. I also noticed this in his log file. Just 'blindly' dividing 136 by 34 gives me 4, that gives me the impression that is indeed 'offset in quarters of an hour from UTC', and that this value gives 34... This helps not in the slightest, but it makes 'sense' in the sense that 136 would lead to 34... Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
