Electronics > Projects, Designs, and Technical Stuff

Anyone using the U-BLOX NEO-M9N GPS?

(1/12) > >>

I have just started on a project which will probably use this.

Basically I need a WAAS/EGNOS GPS with an SMA passive antenna socket and outputting NMEA. I need to get lat/long, ground speed, track, VDOP, HDOP. At 5Hz.

The manuals e.g. https://www.u-blox.com/en/docs/UBX-19035940 are impenetrable. Half the stuff is defined in terms of the other half... Even working out the defaults is very hard i.e. what actually comes out as default.

I will probably just hook it up to Teraterm and see what comes out...

In the final project I may want to talk to it via SPI - because I am already using SPI for other stuff.

However, the SPI port can run at 5MHz+ and the rate at which one can transfer a new sentence is much higher than over 38k serial, and this fits in a bit better with the RTOS environment I am working with. But there are all sorts of weird limitations on this. There is no message register which you could read out with a single (long) SPI read, by sending e.g. an opcode and then reading N bytes. With SPI, you send it a byte (which is supposed to be 0xff, otherwise the device will try treating it is a config etc byte) and then you read a byte (which arrived in the SPI RX queue as the output byte was being shifted to the device) and that is the next byte in what would have been the serial data stream if you used the UART port. And if there was no data in the queue then you get 0xff. So you run the SPI at whatever speed, transmitting 0xff and if the received byte is 0xff you throw it away. That is their "UART emulation over SPI". Is this correct?

But there are some weird implied limitations on how fast the device can fill its queue. One suggests that if a serial port is set to say 38k, that also limits how fast the SPI can be fed by the device. So you can extract data at ~4k bytes/sec max. That would imply that if using SPI one must either disable serial output, or set the baud rate to the highest value possible. But if a byte gets transmitted over serial, doesn't it disappear from SPI? There is a suggestion that there is only one buffer for all output options. Another limitation says max SPI transfer rate is 150kbytes/sec, which is a lot better than 38kbps.

The docs are written by "documentation purists" :) Their support is nonexistent, except via a forum, where a couple of employees respond, but mostly they just tell you to read the manual. I just want to know how to achieve the above output, and 38k serial will do for a start.

Another thing is that the only sentence I can find which returns both VDOP and HDOP is the UBX-private one 2.8.2 POSITION (PUBX,00). This appears to need polling with a PUBX,00 message without any data fields. But it isn't clear if this needs to be sent each time you want this message to come out. However I also don't want other messages being transmitted because that will make parsing harder. How are they disabled?

And finally I am after the highest precision so may try the config option to extend the number of decimal places. I will be using sscanf() into a double. That's another config but the manual says the command has been deprecated and it lists others which are not obvious to decipher.

Many thanks for any pointers.

As an update, I never got any definitive response on how the device actually works w.r.t. running its side of the SPI interface, so I am sticking with serial.

It is a TTL-level (3.3V) inverted serial and with the message choice I am configuring I am seeing 1.4kbytes/sec which is fine for a 38k UART.

SPI would have been really nice if they implemented it properly i.e. have a buffer for the whole "sentence", with a length value, and then one long 5MHz SPI transfer would grab the whole lot. Very efficient all around, not to mention the avoidance of data arriving from a serial port circular queue which then needs to be searched for valid sentence headers etc.

If you approach ublox directly, the support is not going to be great. What you need to do, turn to your distributor, and ask them the questions. Basically most companies dont provide direct support, because they dont know if you are just a maker trying to make one device working, or a company that will use millions of their products.
Sometimes it is just easier to implement a product the way the manufacturer meant it to be implemented. For GSM/GPS module that is UART. When you deviate from it, all kind of weird things start to happen, because 90% of their users dont use that interface, and they might not even test those parts properly. What happens is, there is a product manager, and he goes on and lists every possible interface that they can think of, and it doesnt matter how fitting that interface is. They just want to tick checkboxes.

Yep as NAND said. Pretty much all GPS receiver modules are designed around using UART to periodically spit out messages with new data. As soon as you start using some other interface you pretty much get that same UART interface wrapped up to fit trough the I2C or SPI or whatever protocol. So what you end up talking to is pretty much a UART to SPI converter block rather than the GPS module itself.

So if you have UART just use that and be done with it.

That's my conclusion too.

A pity because SPI is incredibly efficient. I have several SPI devices hanging on one SPI controller and everything runs very fast and very smoothly.

U-BLOX don't support anything but on their forum there is a user there, who may be working for U-BLOX but doesn't say so, who does answer, and I did eventually get the required answers.

I also like posting questions here because they are properly searchable and the answers may help somebody one day.


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version