Anyone using the U-BLOX NEO-M9N GPS?

[peter-h]

Sorry - I meant the track from the GPS module to the SMA socket



It is about 3cm long.

[thinkfat]

BTW: I didn't had much luck trying to use a uBlox M8 (whatever) module at other update rates than 1Hz.

I have used a M8T with nav rates up to 4 Hz, but only in a stationary use case. The M8T is a timing module and I use 4Hz measurement rate during the survey-in to converge faster on a precise position.

[peter-h]

The M9N is supposed to go up to 25Hz.

I am running some mesages at 5Hz and some at 1Hz.

It is fairly obvious that for 25Hz you would have to cut the output right down, to perhaps just one message, otherwise the data would never get out

A lot of applications I work with need 5Hz e.g. avionics.

[nctnico]

Sorry - I meant the track from the GPS module to the SMA socket



It is about 3cm long.

Ah, that makes sense. If you know the stackup of the board then you can use the Saturn tool to get a rough estimate of the trace width you need. For a regular 4 layer board (not impedance controlled) the dielectric between the outer and inner layers will be thick enough not to cause a very large error. Formula based tools like the one from Saturn have large errors with really thin (<0.1 mm) dielectrics which are typically used on very high speed layouts. In the end it is not super critical anyway but you want to be in the right ballpark. If you check the datasheet, the impedance of the GPS module's antenna input likely has a tolerance of 10%.

[peter-h]

I make it 0.014", for a 0.2mm thick outer FR4 laminate and 1oz copper.

[thinkfat]

I make it 0.014", for a 0.2mm thick outer FR4 laminate and 1oz copper.

Sounds about right for a microstrip line.

[nctnico]

'My' PCB package which uses a field solver says to use 0.31mm

[peter-h]

That is 0.0122 which is close enough for government work, as they say

Which relative permittivity did you use for FR4? It isn't well controlled anyway.



This is a commercial devkit for the module, which uses a much thicker track there but then it has a copper pour close to it

[nctnico]

In my experience (based on measurements) 4.5 is a good number to use.

[thinkfat]

Looking at the footprint you use for the SMA connector - it looks a bit off. The launch zone is too wide and there's a discontinuity when it hits your 50\$\Omega\$ line.

I'm just saying that to give you more to fuzz about. It won't matter, actually :-)

[peter-h]

For SPI, I have given up trying to implement the 0xFF handling while reading the UBX-NAV-SAT binary packets. The code gets just too messy (basically treating 0xFF as real data once the header is identified, all the way to the verified packet end, but excluding the very end) and I found I was able to extract all the info I need from the ASCII-only packets like

PUBX,00 (position etc) - ASCII packet
PUBX,03 (status) - ASCII packet
G*RMC Recommended minimum data - ASCII packet - this one also works with a generic (non UBLOX) GPS

I have a sample UBX-NAV-SAT packet which actually contains 0xFF (three of them):

Code: [Select]

0xB5, 0x62, 0x01, 0x35, 0xD4, 0x00, 0xB0, 0xAD, 0xB2, 0x21, 0x01, 0x11, 0x00, 0x00, 0x00, 0x0A,
0x15, 0x28, 0x8D, 0x00, 0x04, 0x00, 0x1C, 0x19, 0x00, 0x00, 0x00, 0x0C, 0x00, 0x12, 0x2F, 0x00,
0x00, 0x00, 0x11, 0x12, 0x00, 0x00, 0x00, 0x15, 0x15, 0x1F, 0x12, 0x01, 0xEA, 0xFF, 0x1C, 0x09,
0x00, 0x00, 0x00, 0x19, 0x13, 0x23, 0x5C, 0x00, 0x38, 0x00, 0x1C, 0x09, 0x00, 0x00, 0x00, 0x1F,
0x13, 0x3C, 0xD4, 0x00, 0xCE, 0xFF, 0x1C, 0x19, 0x00, 0x00, 0x00, 0x20, 0x00, 0x42, 0x2F, 0x00,
0x00, 0x00, 0x11, 0x12, 0x00, 0x00, 0x01, 0x85, 0x00, 0x29, 0xC2, 0x00, 0x00, 0x00, 0x01, 0x07,
0x00, 0x00, 0x01, 0x87, 0x00, 0x18, 0xEC, 0x00, 0x00, 0x00, 0x01, 0x07, 0x00, 0x00, 0x01, 0x89,
0x00, 0xDF, 0x28, 0x01, 0x00, 0x00, 0x01, 0x07, 0x00, 0x00, 0x06, 0x05, 0x1D, 0x26, 0x5E, 0x00,
0x4B, 0x00, 0x1F, 0x09, 0x00, 0x00, 0x06, 0x06, 0x00, 0x3D, 0x5B, 0x01, 0x00, 0x00, 0x11, 0x12,
0x00, 0x00, 0x06, 0x07, 0x00, 0x11, 0x34, 0x01, 0x00, 0x00, 0x11, 0x12, 0x00, 0x00, 0x06, 0x09,
0x00, 0x12, 0xBD, 0x00, 0x00, 0x00, 0x10, 0x12, 0x00, 0x00, 0x06, 0x0F, 0x1C, 0x2A, 0x2B, 0x00,
0x6F, 0x00, 0x1F, 0x19, 0x00, 0x00, 0x06, 0x10, 0x1A, 0x3D, 0x97, 0x00, 0xC1, 0xFF, 0x1C, 0x19,
0x00, 0x00, 0x06, 0x15, 0x18, 0x0A, 0xFC, 0x00, 0x00, 0x00, 0x14, 0x12, 0x00, 0x00, 0x06, 0x16,
0x00, 0x12, 0x2C, 0x01, 0x00, 0x00, 0x11, 0x12, 0x00, 0x00, 0x3A, 0x8A,
A query has gone out to U-BLOX (via their UK disti) but it looks like it will be a while. I will update this thread with any solution they offer to this bizzare issue

[jc101]

I don't know how your reading in the packet, but from that example packet it should be simple...

Read data until you get 0xB5, 0x62, throwing away anything until you get that pair.  Read the next two bytes which identify the type of packet it is for processing later on, read the next two to tell you there are n more bytes to read (0x00D4 or 212 in this case), add 2 for the checksum.  Read (212 + 2) bytes, verify the checksum, frame complete and start again. The code snippet I posted earlier in the thread is part of a function that takes a mix of ASCII and U-Blox packets, and passes the received packets onwards for processing.

Yes, 0xFF can be a byte in a packet, but then it is data.  The whole U-Blox protocol and ASCII is packet driven, do you ever see an 0xFF mid stream when receiving an ASCII packet over SPI?

I have a couple of U-Blox dev modules somewhere, I might hook one up and give it a try via SPI and see if I can generate an under/over run on the buffers.  As I'm just getting over COVID and waiting for a dental abscess to be sorted out, it should prove a distraction from the pain!

[peter-h]

You are right - it can be done that way.

Unfortunately in my case it is a bit harder because I am running the whole thing co-operatively under an RTOS. I have a loop which calls ipqcount() which, for a serial port, returns mostly 0, in which case I yield to the RTOS. If ipqcount returns >0 then I call fgetc and get the byte, and off it goes to a state machine to sort out the rest (looking for various packet types, etc). That yields to RTOS after each byte.

Now, with SPI, you cannot implement an ipqcount like you can with an interrupt-driven UART RX queue. You read the SPI (writing an FF at the same time, which the modem ignores) and if you get FF then you chuck it away and return ipqcount=0 except when decoding the inner part of a binary packet. If you get non-FF then you save that char for the subsequent fgetc call, and return ipqcount=1.

So it isn't hard, but you have to test that code, with binary data containing FFs in every possible place, and especially at the very end It would take time to generate packets which have an FF at the very end.

I decided to not bother because while I am parsing and checking that binary packet, I am not actually extracting data from it, and it doesn't look like my project will need it. And it is quite a rabbit hole to spend a day or so on this, when we are entirely speculating how this stupid interface is supposed to work.

do you ever see an 0xFF mid stream when receiving an ASCII packet over SPI?

I may do that test, but as I say this whole scheme is speculation, based on a crappy data sheet.

I find it pretty amazing that U-BLOX really and truly expected users to do a stunt like this. If affirmative, it looks like a cockup i.e. somebody forgetting that there are binary packets. And if it wasn't a cockup then anybody with a brain would have documented it.

Interestingly, with ASCII-only packets, there is no SPI speed limit (apart from the overriding 5.5MHz max clock). Well, there is actually: for the initialisation of the GPS, to which one again presumes the 125kbytes/sec limit applies also.

One workaround is to init the GPS separately somehow and save the config to its FLASH. The problem with that is that these U-BLOX units have no "factory reset" so if you end up saving some "wrong stuff" you have no way to clean up the unit other than create a huge list of all possible config packets and send them all in Brainless? You bet!

[jc101]

Yes, I do it much the same way under FreeRTOS.  The 'packet finder' is a task that sleeps until it receives a byte via a stream buffer.  Does it stuff, then sleeps until another byte is received.  Once it has a whole packet, it drops it into queue to be picked up and processed in another task.  That queue data is a union struct with all the different expected packet types in, so it's very easy to identity the packet type and then pull out the data as needed.  Again that task uses no CPU until a fully formed and verified packet is passed to it.  If it doesn't recognise it as a packet it is interested in is junks it.

This way the packet finding is interface agnostic.  Though it is a 1:1 as I'm using stream buffers, so I'd need a separate instance of the packet-finder per physical interface.  I generally have a serial interrupt send stream the data via the stream buffer to the task, so neither take any CPU when there is no data.  I guess it's tricker with SPI and the need to poke the interface to get a byte back, I think with the PIC32's I normally use I could trigger an interrupt on a SPI RX and just send the SPI poke byte out as often as I needed to, also possibly inside a transmit interrupt linked to a timer.

It's an interesting problem, I like the U-Blox modules, so it would be worth me spending the time to write some library code suitable for SPI I can use in future projects.  Might not be too readable given painkillers I'm on though...

[peter-h]

I've just been wrapping up the code for when my SPI U-BLOX PCB arrives... Due to the RF side I am not birdsnesting it.

The initialisation of the GPS is not a problem because one can intentionally space out the bytes sent to it. I am putting in osDelay(2) since osDelay(1) delivers a delay of 0 to 1ms. This is FreeRTOS.

So it is easy to run the SPI at 5.5MHz. I have a 5.25MHz option so will use that. That will generate lots of FFs on the receiving side but might make the RTOS thread run better. Basically it will deliver a much faster executing ipqcount() - the input queue size query.

EDIT: just checking the SPI timing, and it seems weird how they spec it. Every SPI device I have used has some requirement on how long you have to wait after setting CS=0, before you can start clocking. And similarly from the last clock to CS=1 at the end.

For example I have a STLED316 display controller where these times are of the order of microseconds!

But this data sheet contains the bizzare statement that this is dependent on the Master. Well, it is, but the Master needs to meet the Slave's timing requirements!!!

[peter-h]

Does anyone have any ideas on the above SPI timing?

[jc101]

Is it not "A" - MISO data valid time (CS), given for difference bus capacitance values?

[peter-h]

These parameters are normally specified for an SPI slave, and the Master /CS timing has to be arranged to achieve it. But U-BLOX don't specify it, instead giving that strange note about it being determined by the master

For example this chip specifies them



as 400ns and 1us respectively (the STLED316 clocks the data on the +ve clock edge, so the 1st one is implicit in the min clock width of 400ns).

[peter-h]

Well, I have a report on testing this bizzare SPI interface

It does work.

Due to limitations on SPI clock divisors I am running it at 650kHz SPI clock, which is a max of 81250 bytes/sec. This keeps it within the 125000 bytes/sec speed limit in the data sheet.

It's been speculated that exceeding this read rate returns 0xFF bytes within packets (which can be safely discarded on ASCII packets) but actually not exceeding this speed limit is more important on data going to the GPS. If one runs the SPI at the next speed up (1.3MHz) then the GPS really slows down and is basically useless. Consequently I was not able to really test "SPI underruns" beyond confirming that with a 1.3MHz SPI clock I was not seeing any 0xFFs within the RMC packet.

I suspect this GPS has the SPI RX wired to an ISR so when you send it a byte (which is usually 0xFF, except when you are initialising it) that triggers some code which doesn't run all that fast.

And with SPI one has to send data to the GPS in order to read data out of it, obviously.

The end result is a lot faster than the serial interface: 650000 versus say 38400 (the default) or 115200.

I did not detect any 0xFF bytes within packets, at 650kHz SPI clock, and at faster clocks it didn't work anyway. I am not using any binary packets.

To run the SPI faster, up to the 5.5MHz in the data sheet, one would need to sync the SPI to a timer so that whatever the SPI clock is, the above byte rate is not exceeded. That is completely pointless unless you have to run the SPI fast for some other reason.

As regards the crappy data sheet and the SPI /CS timing, I tried basically no delay and that still runs, so I put in 1 us.

[clive.one]

For context there's half a dozen threads over at the u-blox forum on this

https://portal.u-blox.com/s/question/0D52p0000CL5I0OCQV/neom9n-and-spi-does-it-work-with-proprietary-ubx-packets
https://portal.u-blox.com/s/question/0D52p0000CMtsm5CQB/neom9n-spi-master-timing-data-sheet-is-strange
https://portal.u-blox.com/s/question/0D52p0000AOH1lzCQD/neom9n-spi-am-i-reading-the-manuals-correctly

Let me summarize..

SPI on these receivers is a stream interface, it is not like a peripheral read/writing registers.
SPI is a symmetrical interface, one clock moves data in both directions.
The availability of data on each side of the interface may be asymmetrically, usually the receiver generates new data continually, and the host just wants to consume that.
The interface needs to be clocked/pumped to move the data.
Data movement in each direction is expected to be complete, intact packets.
When no packet data is available a dummy / stuff byte of 0xFF is used.
The packets have defined/predictable structure, and can include any 8-bit byte patterns, in any number of combinations.
The burst rate can be high, allowing for reduced latency (time to get actionable / usable data)
The packets are assembled on the receiver side, and serviced from a common memory pool, in a scatter-gather fashion.
If you stall the interface, ie ignore it so data backs up and log jams, you typically send a polled/query type command to indicate that you're ready to actually pull the data in a semi-continuous fashion. ie as fast as it is generated, and not in a way that you run the data dry.
If the receiver doesn't have data for the host, it stuffs it's side with 0xFF, but this causes a lot more friction and load on the processor, especially if you keep playing "Are we there yet?" at 5.5 MHz wire rates.

[peter-h]

Indeed; those threads were started by me

Some of the info was helpful, while in others I was told that an octet has 8 bits, or that I should not post "deep" questions in the U-BLOX forum and instead ask my distributor's field engineer (an idea which died out about 40 years ago ).

Most questions scroll off very fast. That forum is full of desperate people posting questions and mostly not getting answers. Same as the https://community.st.com/ forum actually.

especially if you keep playing "Are we there yet?" at 5.5 MHz wire rates.

My tests show that you can't do that anyway; sending the 0xFF "have you got data" poll at about 160kbytes/sec (1.3MHz SPI clock) buggers up the NEO-N9M pretty well. It is still doing something but the packets which are supposed to be say 5Hz come out at about 0.5Hz.

Looks like the 125000 bytes/sec data sheet limit is quite a hard limit (in that 160000 bytes/sec does not work) for all SPI ops regardless of whether the intention is

- write to the GPS (sending a non-FF byte)
- polling the GPS for data (sending a FF byte and looking at what came back)

[clive.one]

>>That forum is full of desperate people posting questions and mostly not getting answers. Same as the https://community.st.com/ forum actually.

It's a user-to-user forum, and the quality of the users is pretty low. We do what we can..

[peter-h]

Indeed, but really the manufacturers should participate. They are making the $$$ after all, while all us poor bastards are just wasting our time getting their chips to work

It's an old problem, going back to the earliest days of the "internet" (say mid-1990s, with Usenet) which has never been addressed. Manufacturers generally hate social media. I run a "tech" forum (not electronics) and we have huge problems getting "trade" people to participate.

Big users get direct support, and everybody else wastes months googling for bug fixes which, when they develop+implement them, they rarely post because it was done in company time

I feel sorry for the few clever users who provide support, presumably unpaid, on these forums, and I am very grateful to them. However in this case I suspect the SPI feature is used by almost nobody.

BTW I never established an upper limit on how fast one can send GPS init strings to the module. That was another Q of mine. It isn't time-critical so I just do it at 650kHz and put a osDelay(2) - a delay of 1-2ms - after each byte sent. It is very likely one could then run the SPI at the full 5.5MHz but there is not likely to be any point. It's true that osDelay() yields to the RTOS, and shortening the blocking (SPI has to be blocking so you can drop and raise /CS) SPI operation accordingly might help in some cases, but one is not initialising the GPS all the time... plus I have no data sheet spec on the /CS timing before/after the clocking, so I am wasting 1us before and 1us after, rendering the benefit of anything at "5.5MHz" dubious.

Probably the slickest way to implement the SPI interface is with a FIFO, like a UART, and with a hardware-limited means of driving the SPI at a specific rate of 125kHz. This - an interrupt every 8us - is a bit too fast for a timer ISR though, especially as access to the 32F417 peripherals is very slow, so perhaps a timer triggering a 1-byte DMA transfer. I don't know if the 32F417 is capable of interrupting on received SPI data (non-FF value).

[peter-h]

I've been thinking about this some more, regarding the context-dependent 0xFF non-discarding on binary packets.

It is easy enough to implement, by detecting the packet header and then not discarding any FFs until the packet length has been fulfilled.

The problem is that if you did get an underrun you will never know, other than the checksum will come up duff (well, 1 in every 256 duff packets will have a valid checksum).

If the data sheet guaranteed a minimum internal buffer fill speed, then you could time the SPI precisely (with a timer, say) to make sure the SPI actions do not happen faster, and also do not happen slower than the internal buffer size would overflow.

The problem is that U-BLOX do not specify the internal buffer fill speed, and do not specify the buffer size.

One could assume that by the time the header is available, the whole buffer has been filled, but that is really unlikely.

So basically you cannot develop a product which reads non-ASCII packets using SPI and be sure there is any kind of margin.

One day I will be looking at their 4G modules and if they do the same thing, that won't work either because UDP packets definitely can contain FFs.

The other thing I have just found is that the initialisation can also contain an FF (see 1st line):

Code: [Select]


uint8_t neo_m9n_init_data[] =
{
0xB5,0x62,0x06,0x01,0x08,0x00,0xF0,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xFF,0x23, // disable GGA
0xB5,0x62,0x06,0x01,0x08,0x00,0xF0,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x2A, // disable GLL
0xB5,0x62,0x06,0x01,0x08,0x00,0xF0,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x31, // disable GSA
0xB5,0x62,0x06,0x01,0x08,0x00,0xF0,0x03,0x00,0x00,0x00,0x00,0x00,0x00,0x02,0x38, // disable GSV
0xB5,0x62,0x06,0x01,0x08,0x00,0xF0,0x05,0x00,0x00,0x00,0x00,0x00,0x00,0x04,0x46, // disable VTG
0xB5,0x62,0x06,0x01,0x08,0x00,0xF0,0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x07,0x5B, // disable ZDA

How the hell does the module deal with that, when all FFs sent to it are discarded?

[thinkfat]

Well. It's not unreasonable to assume that the module has the same state machine built-in that you describe above. It is obvious that they have to parse packets, and also verify the checksum. Though I'd have used a CRC-16 at least, instead of a simple summing of bytes. Also, the documentation does not say that the module will discard all 0xFF bytes it receives. I think you misinterpret something. It would be extremely dumb, knowing that the UBX protocol requires that the channel is "transparent".

PS: the only sane response to a checksum error is discarding the packet without even looking at it.