SiRF raw measurements output

[lawrence]

I have a SiRF EDK (SiRFstarIIe/LP).

I am developing a software to get the raw measurements from the receiver and process them with my algorithm. However, I got problem with the SiRF binary output. The data I need are pseudorange and carrier phase raw measurements, which can be obtained in SiRf binary output message id 5 or 28. I have tried to decode them but not all of them are correct. My program can identify the SiRF binary message id 5 and 28 and decode all one byte data and some two bytes data but none of 4 or 8 bytes data. Since SiRF chipset uses ARM CPU, the output of 4 or 8 bytes data should be long integer or IEEE 754 floating point single or double precision. I would like to ask:

i) Can SiRFstarIIe/LP output both SiRF binary message id 5 and 28?

ii) Regarding for message id 5 (in case I got valid output), I have tried to work out the pseudorange accounting to the brief steps in the SiRFstarIIe/LP Evaluation kit user's guide Feb 2002, however, I don't know the right method to work out the pseudorange from the given data and I have got the source code of calcpsr. Would you please tell me how to do this computation or where could I download the source code of calcpsr?

iii) Regarding for message id 28 (in case I got valid output), I got problem of convesion of binary (hex) data to ASCII data since I don't know how to work out the pseudorange and phase measurement. Are they in IEEE 754 floating point format? But it seems not.     

On the other hand, I tried to log the message id 28 using SiRFdemo 3.36 and copied and pasted the measurements to RINEX and then processed by commercial software, however, the positioning result is far away from my known position.

Could you please tell me how to get the right measurements from SiRF binary message id 28?

I have read Marc's messages. I would like to ask how to "interpret as integer values but as floating point numbers". The way I am doing is to convert hex binary to binary and then converting it to IEEE 754 floating point. Is it a correct way to do it?

Would you please help me?


_________________
lawrence

[DavidW]

The information I have implies that Message ID 5 is not valid in SiRFstar II - and therefore is probably not valid in SiRFstar IIe/LP.



The format of the pseudorange in Message ID 28 isn't something I can work out straightforwardly. The representation is documented as big-endian, and is clearly in a FP format - though precisely which I can't help you with.





Does that move you on any?









David

[lawrence]

Yes, I read it in some documents. Message ID 5 is not valid. However, I can decode it and work out receiver time within 100ms (when comparing with Message ID 7 output) from bit number, chip number, millisecond number. That's why I think the data in Message 5 is valid. The time has been tested for few days at different time and even after turning on and off. The reason for why it is within 100ms because my computation may not be the right method which SiRF is using, or the two messages are not received at the same time.

Do you mean you know how to convert SiRF hex binay to FP? I can decode Garmin's binary data using IEEE floating point 754 format (after reodering) but it doesn't work in SiRF. Even in the example of Message ID 28 in SiRF's document, it seems not standard IEEE FP. I have tried to reorder the code and scaling it, they don't work. I have asked some experts in FP on the web, they think the conversion in the example isn't a standard FP.

Would you please tell me how to convert it?     


_________________
lawrence

[DavidW]

Sorry - I'm afraid I don't know what FP format SiRF are using.



As you rightly said, ARM use IEEE 754 format for floating point numbers. I have worked in ARM assembler - though not with the floating point opcodes.



I don't have any SiRF documentation on what FP format they are using - all I'm doing is reading the documentation I have, which I suspect is very similar to the documentation you have. I suspect the easiest way ahead is to approach SiRF - or keep looking. If you figure it out, I'm interested to know the answer.







David

[ckuethe]

[ckuethe]

Do a search for the u-blox sirf firmware documentation, perhaps at linkwave.co.uk ... ;) The use of message 5 is strongly discouraged, though my TN200 (GSW2 2.3.1) does generate this message and the data does appear to be valid.
_________________
http://www.ualberta.ca/~ckuethe/gps/

[FarmGPS]

I had the same problem recently for my farm software on Pocket PC. This is how I solved it:

I decided to use message 28 and wrote a routine that takes a pointer to the 8 bytes and rearranges them in the correct order. I tested by putting the bytes from the example in the GPS.G2-X-01003-E1.pdf document (see ckuethe's post above) through and came out with the correct floating point value. Checked out the output from my GPS receiver and the pseudo ranges were within reasonable values and incrementing consistently for each satellite.

[ckuethe]

Don't forget about host byte order. SiRF sends 32-bit quantities MSB first, but sends 64-bit quantities with the low 32 bits first. Pfff...

On a little-endian machine you want this:
01234567 (RDROETYB)

On a big-endian machine you want this
76543210 (BYTEORDR)

The SiRFStarII sends this
32107654 (ORDRBYTE)

A better transform might be two calls to ntohl() (no op on a big endian machine) followed by a 32bit swap (3 xor operations) between the low half and high half on a big endian machine. I think the xor-driven swap would be faster than the copy-driven swap. It's still 3 operations, but these can be kept in registers:

let A ^ A = 0, A^0 = A

r0 <- x, r1 <- y

r0 <- $r0 ^ $r1 = (x^y)
r1 <- $r0 ^ $r1 = (x^y)^y = x
r0 <- $r0 ^ $r1 = (x^y)^x = y

Thus, r0 = y and r1 = x. This transform works on pretty much any size of word.

I have not yet taken that into account in my library; for now I'm assuming IA32. I will eventually get around to writing better wrappers for all the bitfield junk. *sigh* Oh, and there are a few documentation bugs in SiRF's manuals. Thank goodness for overlap between message types allowing me to internally check consistency.
_________________
http://www.ualberta.ca/~ckuethe/gps/

We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
Have you considered making a donation towards website running costs?.
Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!