Is there a recommended buffer size for successive read bytes from 0xFF register using i2c from a Ublox Neo7 ?

0 votes
I am using an MCU and i2c to access and read a Ublox Neo7, reading the stream from address 0xFF.  The docs say that I can read 1 to N bytes from this address, however I am getting what I sense are unpredictable results (when compared to using UART) depending on the size of the read from 64 to 256Bytes. Is there a recommended size limit for optimum performance and accuracy of successive reads at a clock cycle of 100KHz?  Are their any config settings that might improve results?  I have not adjusted any of the manufacturers original settings.

Also, I am getting a large number of text messages and fewer of the more important positioning messages, could there be a reason for this due to configuration or whatever?
 $GPTXT,01,01,01,NMEA unknown msg*58
 $GPTXT,01,01,01,NMEA unknown msg*58
 $GPTXT,01,01,00,txbuf alloc*7F
 $GPRMC,,V,,,,,,,,,,N*53
 $GPVTG,,,,,,,,,N*30

Thanks in advance for any help with this.
by post2pa asked Apr 16
159 views
+1 vote
From your short example it appears that your MCU is sending garbage or echoing incoming messages (gptxt...unknown NMEA...), you are not fetching all messages or you have too many output messages enabled (gptxt ...txbuf...).
Your host DDC software must discard 0xFF characters before and between messages but must not discard 0xFF within UBX binart messages.
Limit your selection of output messages using CFG-MSG to turn off unwanted messages

Your RX buffer should accommdate the largest message you expect plus the characters that will come in while you are processing the previous message, assuming that you are discarding the out-of-message 0xFF bytes.
by grampy answered Apr 16
0 votes
The unknown message suggests you're stuffing one of the interfaces with inbound traffic (sending NMEA sentences)

Buffering can occur at multiple levels and tends to depend on how you parse and manage the stream of data.

As you recover data you're going to want to be able to buffer around 256 bytes, and depending on your parsing methodology you might want to hold complete NMEA lines, or whole UBX packets, the latter can be upward of 1200-1500 bytes for certain commands.

You can reduce loading by turning off messages you don't need (via UBX-CFG-MSG) so they don't come out of the interfaces you aren't using. GxGSV can produce particularly large volumes of data.

The messages are also generated at the top-of-second, so you should be able to quantify a high-water-mark for the total data generated in a burst, and either use a buffer at least that large, or reduce the total to something you can manage on your micro-controller.

I2C/DDC provides for auto-increment addressing, so the more data you read the less initial overhead there will be.
by clive1 answered Apr 16
website banner