I2C Neo-8M buffer content

0 votes
Hi, I'm new to GPSs.
I have access to the NEO-M8N via I2C, address 0x1E. I read a buffer from address 0 to 255. I see data from 0 to 31, then everything is 0xFF. The buffer data are:
0x10, 0x20, 0x03
0xFF, 0x51, 0x01, 0xF6, 0xFF, 0x5D and then repeat these 6 bytes until you get to byte 31. From now on, as I said, 0xFF.

Can someone tell me what I'm seeing? What are these records / data? Why do not I see more than 32 bytes? Where is all the information of Lat., Long., Sat., ...?

I have not found information of the records accessible via I2C (DDC).
Please help!!!
by Tomas asked Mar 13
199 views
0 votes
Please read the documentation on the DDC (I2C) usage

https://www.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_%28UBX-13003221%29.pdf

First read the length registers at 0xFD/0xFE, then if data is available repeat a read of register 0xFF to pull the buffer content.
by clive1 answered Mar 13
Hi Clive1,
Thanks for your previous quick response.

Now I read 0xFD & 0xFE with 0x00 0x00. That means "No data"?
I do not know what does read 0xFF, when? for?
Do you have an example in C language, or others?
Or do you have a flow chart of the consultation procedure?

Thanks,
The 0xFF address is like an fgetc() operation, you read the length from the 0xFD/0xFE pair, then pull the stream of bytes to your own local buffering and parse.

To get some output, or test, I'd recommend sending a request form of UBX-MON-VER or UBX-NAV-PVT, ie 8 byte packet with no payload.
Hi Clive1,
I begin to understand the topic, but I continue without a correct answer.
My program sends order UBX-MON-VER (B5 62 0A 04 00 0E 26). Then I read FD i FE and I have 00 00, always. I repeat in a loop, same, I put delays and the same.
This process should work, right?
Thank you,
Packets with incorrect checksums will be ignored by the receiver, you will get ACK-NAK only if parameters within the command are wrong. The length field is 16-bit, not 8-bit

You need to send
B5 62 0A 04 00 00 0E 34

https://forum.u-blox.com/index.php/3131/mon-ver-failing-to-retrieve-software-information-neo-m8n?show=3131#q3131
Well, little by little.
Now I send the order for version {0xB5, 0x62, 0x0A, 0x04, 0x00, 0x00, 0x34, 0x0E}, thanks.
I also try to send the orders of Time {0xB5, 0x62, 0x01, 0x21, 0x00, 0x00, 0x22, 0x67} and Position {0xB5, 0x62, 0x01, 0x07, 0x00, 0x00, 0x08, 0x19} ...
But all I have in response 00 00.
To order the answer counter I send: W-0xFD and R-XX-XX, and it is always 00 00.
Can my GPS be defective or do I need to re-initialize it in some way? (The Tx communication sends me data periodically.
Here the checksum bytes are backward
 {0xB5, 0x62, 0x0A, 0x04, 0x00, 0x00, 0x34, 0x0E}

This is the sequence I suggested
 {0xB5, 0x62, 0x0A, 0x04, 0x00, 0x00, 0x0E,0x34}

I'm sure I could bring up a workable system, but that would take several hours of billable time.
Hello Clive1,
I really made a mistake in putting the checksum, it is effectively 0E 34 (error when writing it).
On the other two commands, they are not reliable, I have deleted them and I focus only on MON_VER, which still does not work for me.

Anyway, I appreciate all your support, interest and patience. I will try to continue to find the solution to my problem.

Thank you,
0 votes
See also

https://forum.u-blox.com/index.php/17700/reading-available-bytes-registers-returns-while-data-ready

regarding the required frequency of reads ( > 0.7 Hz) before timeout occurs and about handling leading 0xFF fill characters
by grampy answered Mar 14
by grampy edited Mar 15
website banner