Project

General

Profile

the gsd4t gps chip on galaxy s2 - terminal software required

Added by robin p about 8 years ago

hi, i'm going to analyse the output from this gps chip, but am struggling to find a serial port terminal application which is free software. denis, what did you use to do the logging on GSD4t? or can anyone recommend any other software?

cheers,

robin


Replies (36)

RE: the gsd4t gps chip on galaxy s2 - terminal software required - Added by Paul Kocialkowski over 7 years ago

Matija Nalis: Good to see that we know agree on how to conduct research on this. Decoding the generated OSP data may indeed help understanding the meaning of the raw data from the chip, but last time I checked, I could not find binary matches between the produced OSP and the raw chip data. I hope you have better luck.

I suppose it would also be relevant to find a common part in the raw messages, like some sort of header.

If you're looking for more info about OSP, you could look here: https://github.com/illarionov/sirfdump
And if you didn't know about it already: http://gps.0xdc.ru/ http://gps.0xdc.ru/static/

Yes, it depend on the direction. Data that goes IN to GSD4t are limted to ~900 bytes, while data coming OUT is in several KB.

I haven't seen any request being written to the GSD4t (or maybe I just have a bad memory).

Also, thanks to our Chinese friends, here is the datasheet for the GSD4t:

About the pdf datasheet, unfortunately, it doesn't explain much about the protocol, it's mostly electrical stuff.

RE: the gsd4t gps chip on galaxy s2 - terminal software required - Added by E3V3A XDA over 7 years ago

I haven't seen any request being written to the GSD4t (or maybe I just have a bad memory).

Any settings you (or kernel) changes, are being sent to the chip.
So it seem that there are 2 different paths used. One is for UART
(ttySAC1) [controller] and the other is via SPI or I2C that is used
to read and write EE, ROM patch and NV data in /data directory. I
have not checked that this is truly the case, but this is how most
GSD4e setups work, where one can also choose to have an external
EEPROM, or other device for this. In our case, I think the NVM<N>
files are taking the place of EEPROM.

In addition, when device is in NMEA mode, it speaks the equivalent to the AT language,
again...

Anyway, I edited my previous post. Since there is a 2 byte limit on the
Payload Length and that MSB have to be <=7F, it imposes a maximum Payload
size of 0x7fff (32767) bytes. In addition, the input message buffer has a
size limit of 912 (0x390) bytes. Thus i/o longer than that has to be chopped
up into sequences. I also read that the Payload Data is in Big Endian format.

The unknown (as shown in earlier post) is funny. Because MID 132 (0x84) is
supposed to be a "polling" input request, but the data seem to be coming out?
Can you check the direction. It could be that data is part of some NV upload?
(But then the 1 sec timing doesn't make sense.) Anyway, according to docs,
the 2nd byte of "84 00", is "not used" and thus can be used as a "counter".
There are many more counters in those strings.

One final question, if you have enabled logging into those files, then that
data has to be pulled/pushed to/from somewhere. Is it possible that we're just
looking at additional log data getting fed out to the files? So, that basically,
we're looking at ourselves in the mirror and saying, "hey there's another guy there!"

RE: the gsd4t gps chip on galaxy s2 - terminal software required - Added by Paul Kocialkowski over 7 years ago

Any settings you (or kernel) changes, are being sent to the chip.

What are you talking about here? There are two GPIOs (power/reset) and UART. The kernel handles the GPIOs, which are also exported to userspace and the gps module uses UART (and uses the GPIOs). I was saying that the gps module only reads on UART, but looking at the traces, it turns out it also writes to it.
Obviously, there is also the firmware upload thing.

So it seem that there are 2 different paths used. One is for UART (ttySAC1) [controller] and the other is via SPI or I2C that is used to read and write EE, ROM patch and NV data in /data directory. Ihave not checked that this is truly the case, but this is how most GSD4e setups work, where one can also choose to have an external EEPROM, or other device for this. In our case, I think the NVM<N> files are taking the place of EEPROM.

There is only UART and GPIOs, no SPI nor i2c. The chip doesn't have much EEPROM which is why we have to send the firmware over UART (or maybe it is just a patch, but looks like the whole thing). Keep in mind that GSD4t and GSD4e are fundamentally very different in the way they work.

In addition, when device is in NMEA mode, it speaks the equivalent to the AT language, again...

The GSD4t cannot provide NMEA, OSP nor coordinates directly. We've established that some time ago.

RE: the gsd4t gps chip on galaxy s2 - terminal software required - Added by E3V3A XDA over 7 years ago

There is only UART and GPIOs, no SPI nor i2c. The chip doesn't have much EEPROM ...

It does have UART/I2C/SPI possibility, but after reading some more they are using
the same pins, so you can only use one at the time. UART is default.
Also, there is no physical on-chip EEPROM, AFAICT, unless you consider
SRAM as euivalent, and that's why I said it seem "emulated" by the NVM
files. There are the following:

Function        Size(KB)        Notes
----------------------------------------------------------
ARM Code ROM    64 (total)      Includes Boot ROM
ARM Code RAM    192             (SRAM)
ARM Patch RAM   8               write lock/unlock
ARM Data RAM    96              -
ARM BB RAM      4               KA RAM
ETB RAM         8               -
GPS DSP RAM     256             -

The BBRAM content is validated using checksums.

And I think something like this:

 4096 Jul  8 00:15 NVM0    4 KiB = 0x1000         BB RAM (KA-domain) 1K*32 bits.
16384 Jul  7 23:59 NVM1   16 KiB = 0x4000         ?SiRFHost (or 8K patch + 8K cache)
    0 Apr 30 11:19 NVM2                           
83724 Jul  7 23:36 NVM3   ~82 KiB                 SiRFInstantFix
  112 Jul  8 00:15 NVM5                           ?SiRFLSM (settings)
    0 Apr 30 11:19 NVM6   
 2832 Jul  8 00:15 NVM13  ~2.7 KiB 

And for anyone else following this discussion:

The GSD4t tracker portion of the software provides GPS status, range
measurements and demodulated GPS satellite data to the host-based software.
The GPS software running on the host provides commands and
initialization data to the GSD4t and GPS navigation data at a 1Hz
output rate to the user host software.

Anyway, thanks for clarifying. I was very tired when I wrote that last post.

BTW. Do you know of any other Android devices use this chip?

RE: the gsd4t gps chip on galaxy s2 - terminal software required - Added by Paul Kocialkowski over 7 years ago

Also, there is no physical on-chip EEPROM, AFAICT, unless you consider SRAM as euivalent, and that's why I said it seem "emulated" by the NVM

Well, SRAM is not a persistent storage, so I wouldn't say it's equivalent. My guess is that the firmware upload loads the firmware to SRAM and then executes it.

BTW. Do you know of any other Android devices use this chip?

So far, I know it's used on the Galaxy Nexus and the Galaxy S 2 (I9100)

RE: the gsd4t gps chip on galaxy s2 - terminal software required - Added by Matija Nalis over 7 years ago

E3V3A XDA wrote:

The unknown (as shown in earlier post) is funny. Because MID 132 (0x84) is
supposed to be a "polling" input request, but the data seem to be coming out?
Can you check the direction. It could be that data is part of some NV upload?
(But then the 1 sec timing doesn't make sense.) Anyway, according to docs,
the 2nd byte of "84 00", is "not used" and thus can be used as a "counter".
There are many more counters in those strings.

No, that is different file. OSP commands (with MID/SIDs) are visible only in SLCLog.gp2* files (after SiRFHost in gps.exynos4.so processes raw binary data from chip).

Raw binary data from chip, which I named "raw4t" (and which we're interested in decoded ourselves, without help of closed source SiRFHost) is contained only in strace.log* files.

So command 132 (0x84) is raw4t command, which has no relation to OSP MID 0x84 whatsoever.

According to my current knowledge (https://github.com/mnalis/gsd4t_parser/blob/master/decode/raw4t/84_3B.WIP.txt), it is actually related partly to OSP MID 0x40 (Nav Library), and partly to some other (yet undetermined) data.

One final question, if you have enabled logging into those files, then that
data has to be pulled/pushed to/from somewhere. Is it possible that we're just
looking at additional log data getting fed out to the files? So, that basically,
we're looking at ourselves in the mirror and saying, "hey there's another guy there!"

No, the strace.log.* data is generated only from file descriptor pertaining to /dev/ttySAC1 on read(2), so those files contain only incoming raw data from /dev/ttySAC1.

RE: the gsd4t gps chip on galaxy s2 - terminal software required - Added by Matija Nalis over 7 years ago

Paul Kocialkowski wrote:

Matija Nalis: Good to see that we know agree on how to conduct research on this. Decoding the generated OSP data may indeed help understanding the meaning of the raw data from the chip, but last time I checked, I could not find binary matches between the produced OSP and the raw chip data. I hope you have better luck.

I have already managed to match a few, so it looks hopeful.

I suppose it would also be relevant to find a common part in the raw messages, like some sort of header.

Yes, I've found and deciphered encapsulation part (it is detailed in README.txt on [my github](https://github.com/mnalis/gsd4t_parser). To recap, after A0A2 lead-in, ih has two kinds of sequences (command sequence and session sequence?), then size, then CRC16 of the headers, then actual payload, and then CRC16 of the payload and B0B3 lead-out. enc4t_gp2_to_raw4t_gp2.pl script checks those headers and extracts raw payload, which I then process with raw4t_gp2_to_human.pl to get human readable descriptions of packets.

If you're looking for more info about OSP, you could look here: https://github.com/illarionov/sirfdump

thanks, I've already found one named gps-kit-cvs.tgz, which is BSD-based C source and perl scripts, which suits me more (especially perl), so I'm looking into them.

I won't have much time for hacking in the next two weeks, but I plan to dive in again after that.

RE: the gsd4t gps chip on galaxy s2 - terminal software required - Added by E3V3A XDA over 7 years ago

To recap, after A0A2 lead-in, it has two kinds of sequences (command sequence and session sequence?), then size, then CRC16 of the headers, then actual payload, and then CRC16 of the payload and B0B3 lead-out.

What do you mean by "CRC16 of the headers", which headers exactly? (It sound strange that there are 2 CRC, but if its is a subcommand (SID) or an encapsulated OSP/NMEA payload, it would make more sense.

Anyway, I was messing around, trying to understand how the two config files: sirfgps/gps.config are read and interpreted, when BAM, the phone refused to boot. I was not able to catch any logs of why that happened, but it would not boot until I removed the sirfgps.conf that I had carefully crafted.

Two other questions:
1) Where and by what is gps.conf read? (It doesn't seem part of gps.exynos4.so as it doesn't contain all the strings available in config.)
2) Does the order of config items in sirfgps.conf matter? (I can't find what exactly is causing the refusal to boot.)

Q: Why is this important?
A: Because we need to understand what config options should be available in a free GSD4t library.

RE: the gsd4t gps chip on galaxy s2 - terminal software required - Added by Paul Kocialkowski over 7 years ago

I'm not sure it's going to help so much (I didn't really look in-depth) but I found this for the GSD5t: https://github.com/klogg/gsd5t_memsgw
It seems to have a raw serial interface that may use the same data format as the GSD4t. Perhaps some of the comments on that code are relevant and could help a bit?

RE: the gsd4t gps chip on galaxy s2 - terminal software required - Added by Matija Nalis over 7 years ago

Paul: thanks. I've looked some more into it (but not too deep, so it is possible I missed something interesting) and unfortunately it seems it reads GSD5T already processed OSP output, and sensors output also in OSP format?

E3V3A: no, there is no OSP or NMEA encapsulated.

from device you read (what I call "enc4t" for encapsulation) strace.log.enc4t.gp2:

00/00/0005 16:21:34.951 (0) A0 A2 00 00 2F 00 04 00 14 08 8F E1 0A 2D 03 12 40 02 58 05 00 0C 18 60 01 81 09 1E 00 20 F8 16 C1 B0 B3

which is

A0 A2 -- leadin
00 -- unknown flag, always 0
00 2F - sequence1
00 04 - sequence2
00 14 - lenght = 0x14
08 8F - CRC-16 Modbus of above bytes ("headers")
E1 0A 2D 03 12 40 02 58 05 00 0C 18 60 01 81 09 1E 00 20 F8 -- payload (which I call "raw4t", or raw data from chip we need to interpret)
16 C1 - CRC-16 modbus of above bytes ("payload")
B0 B3 -- leadout

so after processing that strace.log.enc4t.gp2 with enc4t_gp2_to_raw4t_gp2.pl you get just raw payload in strace.log.raw4t.gp2:

00/00/0006 16:21:34.951 (0) E1 0A 2D 03 12 40 02 58 05 00 0C 18 60 01 81 09 1E 00 20 F8         # seq1=002F seq2=0004 len=0014

which is what we try to interpret.

As for conf files: you should start with working ones, and then change order, remove lines, add other lines, and you will learn if order is important, how it handles invalid commands, what lines are required and what are optional etc. You could also try grep(1)/strings(1) on all files on system to find what file processes what config options, if they are not in gps.exynos4.so. Note that it is possible that some options are not processed and are simply ignored.

As for the refusal to boot, if not related to file content, it might be file permissions. Or unseen in editor LF vs CR/LF line ends.

(I'm back looking into it, but submerged in GPS theory and calcultions, needed to process pseudorange measurements and turn those into lat/lon/height coordinates, so not processing raw4 data currently - that will follow soon again)

RE: the gsd4t gps chip on galaxy s2 - terminal software required - Added by E3V3A XDA over 7 years ago

@Matija : Thanks for summary and status update.

I haven't looked further into this, since then. File permissions is not an issues as I always fix them and neither is CR/LF as I have a good editor showing these. As for looking into these calculations, I recommend this (IIRC) the manual made by Ublox:
http://www.u-blox.com/images/downloads/Product_Docs/GPS_Compendium(GPS-X-02007).pdf
It sound crazy that you should have to re-create these calculations from scratch... and that they're not already done by the chip itself.
Would reversing a GPS app like the GPSTest.apk be of any help?

Do you see any changes in the "sequence" items?
Have you tried to move phone around (i.e. driving) while collecting enc4t and see if they change?
How many different (i.e. different length and headers) unknown enc4t items do we have at the moment?

(26-36/36)