Anyone using the U-BLOX NEO-M9N GPS?

[peter-h]

From the Integration manual, UBX-19014286 - R073 Receiver functionality Page 29 of 95



The 0xFF to the GPS is the "disable GGA sentence" config which, if it doesn't work, will simply cause that sentence to be emitted, and since I am not looking for it, discarded.

The only thing in the doc that you can hang your coat on is the 125000 byte/sec max SPI speed. The entire edifice here is based on the speculation that the programmer carefully made sure that not exceeding this speed will never cause an underrun within a packet (which is probably quite difficult looking at the huge complexity of the code inside) and at the same time made sure that the buffers allocated to the packets are big enough to hold the longest possible packets for the case where the SPI speed is less than 125000 bytes/sec. There is no minimum speed specified...

The English in the doc is terrible (gramatically fine but poor for disambiguating what are IMHO obvious questions from anyone writing code for it) which doesn't help.

[thinkfat]

The manual says to discard all 0xFF bytes "which are not part of a message", right? So, 0xFF bytes within a message are perfectly fine.

[peter-h]

For receiving data from the GPS, yes, but please read my timing explanation/concerns. It isn't simple.

All I can say is that it works fine, with ASCII packets and with a 650kHz SPI clock (81250 bytes/sec max data rate). I cannot tell with what margin, and it isn't easy to margin-test it because the SPI clock is settable only in powers of two. At 162500 (81250 * 2) bytes/sec the GPS is quite unhappy. I will try lower speeds but it will obviously work because other RTOS tasks run fine with it.

The text screenshot I posted above refers to data sent to the GPS. It implies initialisation data sent to the GPS must not contain FFs and any such are discarded. I would hope that this text is BS and actually once the GPS sees the start of an init packet (0xB5,0x62,0x06...) it does accept FF bytes.

SPI is always "back to back write/read" and this is what gives rise to all these issues. You have to have a means of sending a byte to the device and discarding what naturally comes back on SPI RX (which is trivial; read it and discard it) and a means of getting a byte from the device but without sending it one (which is impossible with SPI, and in this case is achieved by sending an FF).

With a UART, it's all fine.

EDIT: lower SPI speeds tested. I did a breakpoint on an NMEA checksum error counter increment and go zero at 650kHz, 325kHz, 162.5kHz and can't go any lower. Interestingly I also don't get any errors at 1.3MHz but the GPS really slows down and cannot maintain the specified 5Hz rate. At 2.6MHz it really slows down, to about 0.5Hz, but still no NMEA checksum errors. This suggests that the SPI generates an internal interrupt which the CPU is only just about able to service at the specified 125kbyte/sec rate (equivalent to SPI clock of 1MHz).

With the NEO-M9N costing probably under $5 in volume, it won't have a 168MHz ARM32 inside It's probably an 8051 core of some sort, next to the hardware GPS implementation.

[thinkfat]

For receiving data from the GPS, yes, but please read my timing explanation/concerns. It isn't simple.

All I can say is that it works fine, with ASCII packets and with a 650kHz SPI clock (81250 bytes/sec max data rate). I cannot tell with what margin, and it isn't easy to margin-test it because the SPI clock is settable only in powers of two. At 162500 (81250 * 2) bytes/sec the GPS is quite unhappy. I will try lower speeds but it will obviously work because other RTOS tasks run fine with it.

The text screenshot I posted above refers to data sent to the GPS. It implies initialisation data sent to the GPS must not contain FFs and any such are discarded. I would hope that this text is BS and actually once the GPS sees the start of an init packet (0xB5,0x62,0x06...) it does accept FF bytes.

SPI is always "back to back write/read" and this is what gives rise to all these issues. You have to have a means of sending a byte to the device and discarding what naturally comes back on SPI RX (which is trivial; read it and discard it) and a means of getting a byte from the device but without sending it one (which is impossible with SPI, and in this case is achieved by sending an FF).

With a UART, it's all fine.

EDIT: lower SPI speeds tested. I did a breakpoint on an NMEA checksum error counter increment and go zero at 650kHz, 325kHz, 162.5kHz and can't go any lower. Interestingly I also don't get any errors at 1.3MHz but the GPS really slows down and cannot maintain the specified 5Hz rate. At 2.6MHz it really slows down, to about 0.5Hz, but still no NMEA checksum errors. This suggests that the SPI generates an internal interrupt which the CPU is only just about able to service at the specified 125kbyte/sec rate (equivalent to SPI clock of 1MHz).

With the NEO-M9N costing probably under $5 in volume, it won't have a 168MHz ARM32 inside It's probably an 8051 core of some sort, next to the hardware GPS implementation.

I see no constraint on 0xFF bytes within a message, expressed or implied. You assume too much, I reckon. Can you pinpoint the sentence you base your assumption on?

[peter-h]

The yellow bit above.

This is the inherent way SPI works. You cannot read data without also writing the same amount of data. This issue arises with all SPI devices which "accept" data e.g. an ADC for config purposes (look up ADS1118, which deals with this by you sending it the same 16 bits of config data every time you read out the 16 bit value), while other devices are read-only (e.g. MCP3550) and have just the MISO output (no MOSI input).

So when reading this U-BLOX module (a GPS module is mostly just read, not written) it ignores 0xFF bytes written to it.

[jc101]

I see no constraint on 0xFF bytes within a message, expressed or implied. You assume too much, I reckon. Can you pinpoint the sentence you base your assumption on?

There is a constraint, in 11.6.2 (of my protocol guide anyway) it says...

To prevent the receiver from being busy parsing incoming data, the parsing process is stopped after 50 subsequent bytes containing 0xFF. The parsing process is re-enabled with the first byte not equal to 0xFF. The number of bytes to wait for deactivation (50 by default) can be adjusted using the field mode.ffCnt in CFG-PRT for SPI, which is only necessary when messages shall be sent containing a large number of subsequent 0xFF bytes.

This implies that providing you don't send more than 50 0xff in the payload of any packet all should be fine.  But there is a limit, software settable, with a default of 50 0xff's before the RX in the module just chucks the data away until a non 0xff arrives. 


When sending CFG commands to the modules, it will either ACK or NAK it has received and processed the command. 

32.5.1 Acknowledgement
When messages from the class CFG are sent to the receiver, the receiver will send an
"acknowledge" (UBX-ACK-ACK) or a "not acknowledge" (UBX-ACK-NAK) message back to the sender,
depending on whether or not the message was processed correctly.
Some messages from other classes (e.g. LOG) also use the same acknowledgement mechanism.

So, for me, I send the CFG, and only move to the next CFG command once I've had the corresponding ACK back.  If I get a NAK, I try again and if I still get a NAK I report a comms error.  It doesn't matter that 0xFF may be in the payload of the CFG packet, the module knows it's receiving a packet.

If the receiver has no more data to send, it sets MISO to logic high, i.e. all bytes transmitted decode
to 0xFF. An efficient parser in the host will ignore all 0xFF bytes which are not part of a message
and will resume data processing as soon as the first byte not equal to 0xFF is received.

This is also pretty clear, to me anyway, that receiving an 0xff is perfectly fine within a packet.

[thinkfat]

The yellow bit above.

This is the inherent way SPI works. You cannot read data without also writing the same amount of data. This issue arises with all SPI devices which "accept" data e.g. an ADC for config purposes (look up ADS1118, which deals with this by you sending it the same 16 bits of config data every time you read out the 16 bit value), while other devices are read-only (e.g. MCP3550) and have just the MISO output (no MOSI input).

So when reading this U-BLOX module (a GPS module is mostly just read, not written) it ignores 0xFF bytes written to it.

But SPI does not mandate the discarding of 0xFF bytes within a packet. The 0xFF are "idle" bytes only, you need to send them when you want to receive messages while you don't have anything else to tell the receiver. While you're sending a message, there is no implication that the receiver will discard them.

In fact:

There is a constraint, in 11.6.2 (of my protocol guide anyway) it says...

To prevent the receiver from being busy parsing incoming data, the parsing process is stopped after 50 subsequent bytes containing 0xFF. The parsing process is re-enabled with the first byte not equal to 0xFF. The number of bytes to wait for deactivation (50 by default) can be adjusted using the field mode.ffCnt in CFG-PRT for SPI, which is only necessary when messages shall be sent containing a large number of subsequent 0xFF bytes.

This implies that providing you don't send more than 50 0xff in the payload of any packet all should be fine.  But there is a limit, software settable, with a default of 50 0xff's before the RX in the module just chucks the data away until a non 0xff arrives. 

Exactly. No more than mode.ffCnt consecutive 0xFF byte in any message and you're fine.

[peter-h]

That all sounds ok then and explains why it is working

The only thing I don't do is checking for the ACK after sending it the config. I just send the config every 2 secs until recognisable NMEA packets start appearing.

[camerart]

>>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..

Hi C1,
I'm one of those low quality uses, you speak about.  (No offence felt, as I can't help it )

However behind me are high 'quality' people who are helping me, I'm just who you 'speak' to.
Cheers, Camerart

[camerart]

That all sounds ok then and explains why it is working

The only thing I don't do is checking for the ACK after sending it the config. I just send the config every 2 secs until recognisable NMEA packets start appearing.

Hi P,
Do you mean that you have gotten the M9N to send $NMEA messages using SPI, back to your 'microcontroller' ?

We've been trying for months!

Would you be good enough to post the key lines of CODE, that produce this please?
Cheers, Camerart

[peter-h]

Firstly you have to config SPI to run slow enough to assure the 125kbytes/sec tx rate is not exceeded (a lot of BS is written online about this, but it is real)

Code: [Select]

m_spi.Init.Direction = SPI_DIRECTION_2LINES;
m_spi.Init.DataSize = SPI_DATASIZE_8BIT;
m_spi.Init.CLKPolarity = SPI_POLARITY_LOW;
m_spi.Init.CLKPhase = SPI_PHASE_1EDGE;
m_spi.Init.NSS = SPI_NSS_SOFT;
m_spi.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_64; // 64: 650kHz (max 1MHz for 125kbyte/sec max data rate)
m_spi.Init.FirstBit = SPI_FIRSTBIT_MSB;
m_spi.Init.CRCPolynomial = 7;
m_spi.Init.Mode = SPI_MODE_MASTER;
m_spi.Instance = NEO_M9N_SPI;
   HAL_SPI_Init(&m_spi);

This is the init code

Code: [Select]


void neo_m9n_init()
{

// Initialise internal (SPI) GPS
{

#ifndef TEST_DATA
uint8_t tmp;
for (uint16_t i=0; i < sizeof(neo_m9n_init_data); i++)
{
kde_neo_m9n_spi3_write_read_byte(neo_m9n_init_data[i], &tmp);
osDelay(2); // this delay removes any need for SPI speed limit when feeding the GPS
}
#endif

debug_thread_printf("GPS init sent to SPI");

}

Code: [Select]


/*
 * NEO-M9N GPS byte write+read over SPI.
 * For normal data read, transmit 0xFF. If you get 0xFF back, that indicates an under-run so discard it.
 * The read speed is limited to 125kbytes/sec and this is supposed to avoid under-runs *within* packets, which is
 * necessary otherwise binary packets could not be received! This issue has been sidestepped by not implementing
 * any binary packets.
 * We achieve the 125kbyte/sec limit (equivalent to a 1MHz SPI clock) by running SPI3 at 650kHz clock which is
 * the nearest value below 1MHz. However since we aren't processing binary packets (GET_UBX_NAV_SAT not defined)
 * we could run SPI a lot faster, except that will overspeed the SPI *to* the GPS.
 * It is a truly shit interface, but much faster than a UART even at 115kbaud, and avoids using up any of our
 * four serial ports. In any case, none of the four serial ports come out on the two expansion connectors.
 * In normal operation, this function will return solid FFs during the inter-packet gaps (every 200ms) and
 * should return few if any FFs during the packets.
 *
 */

static void kde_neo_m9n_spi3_write_read_byte(uint8_t out_value, uint8_t * ret_value)
{

// These are static so DMA can be used
static uint8_t outv = 0;
static uint8_t inv = 0;

outv = out_value;

kde_neo_m9n_cs(0);
hang_around_us(1);

SPI3_DMA_TransmitReceive(&outv, &inv, 1, false, false, RTOS_YIELD);

hang_around_us(1); // 1 microsecond
kde_neo_m9n_cs(1);

*ret_value = inv;

}

I am not posting the DMA code; you don't really need it since the speed here is so low.


The code shows SPI3 is mutexed; you may not need to do that if not sharing SPI3.

Here is the init data and you tweak that to select which packets you want

Code: [Select]


/*
 *
 * Transmit config data block to the GPS.
 * This disables various default NMEA messages (sentences) and selects three proprietary U-BLOX messages
 * which were chosen to return not just location but also HDOP and VDOP, and whether SBAS is being used.
 * The GPS is set to run, and emit the basic position and HDOP/VDOP, at 5Hz which is important for high quality
 * positioning purposes.
 * The satellite status messages come out at 1Hz because they are not needed as often, and due to their size
 * would overrun the 38k serial baud rate.
 * This configuration results in about 1.4kbytes/sec coming from the GPS, which is manageable at 38k.
 * Working out this config was a bastard. Each config message below ends with a checksum and U-BLOX have
 * special software for composing these and calculating the checksums. I managed to extract these messages
 * from their tech support.
 *
 * Port is 1 2 3 4 for serial ports 1 2 3 4. 3 is not used because it is 2-wire RS485.
 * Port of -1 means internal (SPI) GPS.
 *
 * Unless SPI GPS is used, the size of the init block must be no bigger than opqspace(g_gps_port)! This
 * was done to avoid a blocking call and yet another timeout, etc.
 * Currently the opqspace is 1k.
 *
 */

static const uint8_t neo_m9n_init_data[] =
{

// 0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x08,0x01,0x03,0x20, // enable ZDA
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,0x04,0x00,0x00,0x00,0x00,0x00,0x00,0x03,0x3F, // disable RMC
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

#ifndef RMC_ONLY
0xB5,0x62,0x06,0x01,0x03,0x00,0xF1,0x00,0x01,0xFC,0x13, // enable PUBX,00
#endif

0xB5,0x62,0x06,0x08,0x06,0x00,0xC8,0x00,0x01,0x00,0x01,0x00,0xDE,0x6A, // GPS rate 5 Hz

// UBX-NAV-SAT (0x01 0x35) at 5Hz - satellite data, binary
// B5 62 06 01 03 00 01 35 01 41 AD

#ifndef RMC_ONLY
// above at 1Hz - preferred for less data
#ifdef GET_UBX_NAV_SAT
0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0x01, 0x35, 0x05, 0x45, 0xB1, // enable UBX-NAV-SAT at 1/5 of rate = 1Hz
#endif

// PUBX,03 (Satellite data, ASCII) and at 5Hz
// B5 62 06 01 03 00 F1 03 01 FF 19

// above at 1Hz - preferred for less data
0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0xF1, 0x03, 0x05, 0x03, 0x1D // enable PUBX,03 at 1/5 of rate = 1Hz
#endif

// This saves the config in flash, UBX-CFG-CFG
// NOT doing this on new devices because there is no evident factory reset!
// 0xB5, 0x62, 0x06, 0x09, 0x0D, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x1D, 0xAB

};


Hope this helps.

The SPI interface on this module is a bodge. They probably stuck it on the front of their UART, sort of.

[camerart]

Firstly you have to config SPI to run slow enough to assure the 125kbytes/sec tx rate is not exceeded (a lot of BS is written online about this, but it is real)

Code: [Select]

m_spi.Init.Direction = SPI_DIRECTION_2LINES;
m_spi.Init.DataSize = SPI_DATASIZE_8BIT;
m_spi.Init.CLKPolarity = SPI_POLARITY_LOW;
m_spi.Init.CLKPhase = SPI_PHASE_1EDGE;
m_spi.Init.NSS = SPI_NSS_SOFT;
m_spi.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_64; // 64: 650kHz (max 1MHz for 125kbyte/sec max data rate)
m_spi.Init.FirstBit = SPI_FIRSTBIT_MSB;
m_spi.Init.CRCPolynomial = 7;
m_spi.Init.Mode = SPI_MODE_MASTER;
m_spi.Instance = NEO_M9N_SPI;
   HAL_SPI_Init(&m_spi);

This is the init code

Code: [Select]


void neo_m9n_init()
{

// Initialise internal (SPI) GPS
{

#ifndef TEST_DATA
uint8_t tmp;
for (uint16_t i=0; i < sizeof(neo_m9n_init_data); i++)
{
kde_neo_m9n_spi3_write_read_byte(neo_m9n_init_data[i], &tmp);
osDelay(2); // this delay removes any need for SPI speed limit when feeding the GPS
}
#endif

debug_thread_printf("GPS init sent to SPI");

}

Code: [Select]


/*
 * NEO-M9N GPS byte write+read over SPI.
 * For normal data read, transmit 0xFF. If you get 0xFF back, that indicates an under-run so discard it.
 * The read speed is limited to 125kbytes/sec and this is supposed to avoid under-runs *within* packets, which is
 * necessary otherwise binary packets could not be received! This issue has been sidestepped by not implementing
 * any binary packets.
 * We achieve the 125kbyte/sec limit (equivalent to a 1MHz SPI clock) by running SPI3 at 650kHz clock which is
 * the nearest value below 1MHz. However since we aren't processing binary packets (GET_UBX_NAV_SAT not defined)
 * we could run SPI a lot faster, except that will overspeed the SPI *to* the GPS.
 * It is a truly shit interface, but much faster than a UART even at 115kbaud, and avoids using up any of our
 * four serial ports. In any case, none of the four serial ports come out on the two expansion connectors.
 * In normal operation, this function will return solid FFs during the inter-packet gaps (every 200ms) and
 * should return few if any FFs during the packets.
 *
 */

static void kde_neo_m9n_spi3_write_read_byte(uint8_t out_value, uint8_t * ret_value)
{

// These are static so DMA can be used
static uint8_t outv = 0;
static uint8_t inv = 0;

outv = out_value;

kde_neo_m9n_cs(0);
hang_around_us(1);

SPI3_DMA_TransmitReceive(&outv, &inv, 1, false, false, RTOS_YIELD);

hang_around_us(1); // 1 microsecond
kde_neo_m9n_cs(1);

*ret_value = inv;

}

I am not posting the DMA code; you don't really need it since the speed here is so low.


The code shows SPI3 is mutexed; you may not need to do that if not sharing SPI3.

Here is the init data and you tweak that to select which packets you want

Code: [Select]


/*
 *
 * Transmit config data block to the GPS.
 * This disables various default NMEA messages (sentences) and selects three proprietary U-BLOX messages
 * which were chosen to return not just location but also HDOP and VDOP, and whether SBAS is being used.
 * The GPS is set to run, and emit the basic position and HDOP/VDOP, at 5Hz which is important for high quality
 * positioning purposes.
 * The satellite status messages come out at 1Hz because they are not needed as often, and due to their size
 * would overrun the 38k serial baud rate.
 * This configuration results in about 1.4kbytes/sec coming from the GPS, which is manageable at 38k.
 * Working out this config was a bastard. Each config message below ends with a checksum and U-BLOX have
 * special software for composing these and calculating the checksums. I managed to extract these messages
 * from their tech support.
 *
 * Port is 1 2 3 4 for serial ports 1 2 3 4. 3 is not used because it is 2-wire RS485.
 * Port of -1 means internal (SPI) GPS.
 *
 * Unless SPI GPS is used, the size of the init block must be no bigger than opqspace(g_gps_port)! This
 * was done to avoid a blocking call and yet another timeout, etc.
 * Currently the opqspace is 1k.
 *
 */

static const uint8_t neo_m9n_init_data[] =
{

// 0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x08,0x01,0x03,0x20, // enable ZDA
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,0x04,0x00,0x00,0x00,0x00,0x00,0x00,0x03,0x3F, // disable RMC
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

#ifndef RMC_ONLY
0xB5,0x62,0x06,0x01,0x03,0x00,0xF1,0x00,0x01,0xFC,0x13, // enable PUBX,00
#endif

0xB5,0x62,0x06,0x08,0x06,0x00,0xC8,0x00,0x01,0x00,0x01,0x00,0xDE,0x6A, // GPS rate 5 Hz

// UBX-NAV-SAT (0x01 0x35) at 5Hz - satellite data, binary
// B5 62 06 01 03 00 01 35 01 41 AD

#ifndef RMC_ONLY
// above at 1Hz - preferred for less data
#ifdef GET_UBX_NAV_SAT
0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0x01, 0x35, 0x05, 0x45, 0xB1, // enable UBX-NAV-SAT at 1/5 of rate = 1Hz
#endif

// PUBX,03 (Satellite data, ASCII) and at 5Hz
// B5 62 06 01 03 00 F1 03 01 FF 19

// above at 1Hz - preferred for less data
0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0xF1, 0x03, 0x05, 0x03, 0x1D // enable PUBX,03 at 1/5 of rate = 1Hz
#endif

// This saves the config in flash, UBX-CFG-CFG
// NOT doing this on new devices because there is no evident factory reset!
// 0xB5, 0x62, 0x06, 0x09, 0x0D, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x1D, 0xAB

};


Hope this helps.

The SPI interface on this module is a bodge. They probably stuck it on the front of their UART, sort of.

Hi P-h,
Yes, it will!  I haven't seen much proof, that SPI works with these modules, it's a pity it's a bodge.
I have forwarded it to my mate who is multilingual.
Thanks very much.
C

[peter-h]

It certainly works and at 650kbits/sec SPI, is much faster than RS232 would be.

There is a problem if you enable packets which may contain 0xff within the data (NMEA ones don't but the U-BLOX ones can do) and then you need to write a much more complex state machine, plus I am not sure if this even works at all over SPI.

[camerart]

It certainly works and at 650kbits/sec SPI, is much faster than RS232 would be.

There is a problem if you enable packets which may contain 0xff within the data (NMEA ones don't but the U-BLOX ones can do) and then you need to write a much more complex state machine, plus I am not sure if this even works at all over SPI.

Hi P-h,
My method so far is to program the GPS wih U-center, then as all I need is the $GNRMC sentences, I've been sending what I think is the 'request' series of BYTES (24 50 55 42 58 2C 30 30 2A 33 33 0D 0A) via SPI, then 0xffs.
D_sel high for programming, D_SEL low before (power on) and CS, SCK.
So far, I haven't received a $ yet.
C

[peter-h]

You may need a scope and look at the SPI signals.

[camerart]

You may need a scope and look at the SPI signals.

Hi P-h,
This time I tried (U-CENTER) UBX-NAV-POSLLH and POLLED it, using a digital analyser.  Copied the BYTES, into my program.
Result: I see $GNRMC and the time on the MISO, which is NOW.  If I'm not mistaken I'ts working.
What do you think?
C

[camerart]

Hi,
False alarm, this is Serial data
C

[camerart]

Hi P-h,
The modules I have at present are M8Ns, and in desperation to find SPI information, tried M9Ns where I found this forum.  I now find that the two are not quite the same, so and added difficulty.
As I have a back-up way if splitting the 2x UART inputs, by using the second PIC on my units, I have chosen to go this direction instead of the SPI route.
Thanks for your CODE.
It's a pity that the mighty Ublox acts in this way!
Thanks C.