Re: qtMoko getting bad Network Time

2015-01-18 Thread 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 ofonoqtmoko.

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

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: qtMoko getting bad Network Time

2015-01-07 Thread Christ van Willegen
Hi,

On Wed, Jan 7, 2015 at 4:08 AM, Paul Wise pa...@bonedaddy.net 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


Re: qtMoko getting bad Network Time

2015-01-07 Thread Jorge

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



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

2015-01-07 Thread Jorge

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

2015-01-06 Thread Jorge
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).


Jorge

On 05/01/15 23:39, Paul Wise wrote:

On Mon, Jan 5, 2015 at 2:15 AM, Jorge wrote:


I have a correctly set time  timezone (America/Montevideo), and when my
qtMoko boots up, after connecting to the cellular network a weird dialog
appears : The network time is (GMT +34). Set this new time?. If I say No,
everything keeps working. If I say Yes the timezone is changed to GMT-34
and as expected the time is borked (00:00 1/1/1970).

34 hours past GMT sounds like your provider has a broken time server.
Usually GMT timezones are 0-12 hours before/after GMT and no further.
Of course QtMoko should probably handle such broken timezones by
ignoring them rather than breaking. Please file a bug about it on the
QtMoko bug reports page:

https://github.com/radekp/qtmoko/issues




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: qtMoko getting bad Network Time

2015-01-06 Thread Paul Wise
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.

-- 
bye,
pabs

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: qtMoko getting bad Network Time

2015-01-05 Thread Paul Wise
On Mon, Jan 5, 2015 at 2:15 AM, Jorge wrote:

 I have a correctly set time  timezone (America/Montevideo), and when my
 qtMoko boots up, after connecting to the cellular network a weird dialog
 appears : The network time is (GMT +34). Set this new time?. If I say No,
 everything keeps working. If I say Yes the timezone is changed to GMT-34
 and as expected the time is borked (00:00 1/1/1970).

34 hours past GMT sounds like your provider has a broken time server.
Usually GMT timezones are 0-12 hours before/after GMT and no further.
Of course QtMoko should probably handle such broken timezones by
ignoring them rather than breaking. Please file a bug about it on the
QtMoko bug reports page:

https://github.com/radekp/qtmoko/issues

-- 
bye,
pabs

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


qtMoko getting bad Network Time

2015-01-04 Thread Jorge

Hi to all again:

I have a correctly set time  timezone (America/Montevideo), and when my 
qtMoko boots up, after connecting to the cellular network a weird dialog 
appears : The network time is (GMT +34). Set this new time?. If I say 
No, everything keeps working. If I say Yes the timezone is changed to 
GMT-34 and as expected the time is borked (00:00 1/1/1970).


I guess there is some problem requesting the timezone from the provider. 
The output from running qpe by hand is the following (just after reading 
the contacts from the SIM):


-
AtChat :  T : AT+CMER=1,0,0,1,0
AtChat :  F : OK
AtChat :  T : AT+CNMI=2,1,2,0,0
AtChat :  F : OK
AtChat :  T : AT+COPS=0
AtChat :  N : +CREG: 2
AtChat :  N : %CSQ:  31, 99, 5
AtChat :  N : +CIEV: 1, 5
AtChat :  t : AT+CSCB=0,50
AtChat :  N : +CREG: 1,000B,25FA
AtChat :  F : OK
AtChat :  f : AT+CSCB=0,50
AtChat :  f : OK
AtChat :  t : AT+COPS=3,2
AtChat :  f : AT+COPS=3,2
AtChat :  f : OK
AtChat :  t : AT+COPS?
AtChat :  f : AT+COPS?
AtChat :  f : +COPS: 0,2,74801
AtChat :  f : OK
AtChat :  t : AT+COPS=3,0
AtChat :  f : AT+COPS=3,0
AtChat :  f : OK
AtChat :  t : AT+COPS?
AtChat :  f : AT+COPS?
AtChat :  f : +COPS: 0,0,Antel
AtChat :  f : OK
AtChat :  t : AT+CSCB=0,50
AtChat :  f : AT+CSCB=0,50
AtChat :  f : OK
AtChat :  N : %CSQ:  31, 99, 3
AtChat :  N : +CIEV: 1, 5
AtChat :  N : +CTZV: 136
Unable to open '/usr/share/zoneinfo/Etc/GMT-34'
QTimeZone::data Can't create a valid data object for 'Etc/GMT-34'
TimeZoneData::fromUtc invalid
TimeZoneData::fromUtc invalid
TimeZoneData::fromUtc invalid
AtChat :  N : %CSQ:  31, 99, 5
AtChat :  N : +CIEV: 1, 5
TimeZoneData::fromUtc invalid
AtChat :  T : 
AtChat :  W : 
AtChat :  W : OK
TimeZoneData::fromUtc invalid
AtChat :  T : AT+CCFC=0,2
TimeZoneData::fromUtc invalid
TimeZoneData::fromUtc invalid
AtChat :  F : +CCFC: 0,7
AtChat :  F : OK
TimeZoneData::fromUtc invalid
TimeZoneData::fromUtc invalid
-

Around here is when the dialog appears, and it keeps printing 
TimeZoneData::fromUtc invalid until I select No.


Hope it's interesting.

Jorge

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community