Problem sending speed to F9R via UBX-ESF-MEAS (0x10 0x02)

GPS/GNSS Development Boards
1

OK so I am sending the speed signal to the F9R using the SparkFun GNSS library.

I am stealing heavily from the canned example in the library.

I am also using https://github.com/cturvey/RandomNinjaC … ESFspeed.c for as and example for the UBX-ESF-MEAS (0x10 0x02) message.

#define max_pckt_size 16//defines maximum custom packet size
uint16_t maxWait = 2000; // Wait for up to 250ms (Serial may need a lot longer e.g. 1100)
uint8_t customPayload[max_pckt_size] = { 0 }; // This array holds the payload data bytes. MAX_PAYLOAD_SIZE defaults to 256. The Speed payload is only 12 bytes!
  // The next line creates and initializes the packet information which wraps around the payload
  ubxPacket customCfg = {0, 0, 0, 0, 0, customPayload, 0, 0, SFE_UBLOX_PACKET_VALIDITY_NOT_DEFINED, SFE_UBLOX_PACKET_VALIDITY_NOT_DEFINED};
  customCfg.cls = UBX_CLASS_ESF; // This is the message Class
  customCfg.id = UBX_ESF_MEAS; // This is the message ID
  customCfg.len = 12; // Setting the len 8 + numMeas·4 + [0,1]·4(sending speed only.)
.
.
.
  if (myGNSS.sendCommand(&customCfg, maxWait) != SFE_UBLOX_STATUS_DATA_SENT) // This time we are only expecting an ACK
  {
#ifdef F9_speed_debug
    ConSerial.println(F("sendCommand (set) failed!"));
#endif
    return false;
  }

Not I am using serial at 115200 but I am never getting an acknowledge even with 2000 ms? (I wend overboard just to make sure.)

My message keeps getting rejected:

F9R Payload(in hex): 77,71,00,00,00,08,00,00,41,FE,FF,0B

So per the “F9-HPS-1.21_InterfaceDescription_UBX-21019746.pdf” (I am actually running firmware HPS 1.20).

00 00 71 77 is from the Arduino millis() which is the system clock in ms.

Per the above examples, all the flags are 0 and I am sending 1 sensor.

Bit 3 of the send byte (bit 11 overall is set for sending 1 sensor therefore a 0x08 in the second byte)

08 00

00 00 for the ID (like the example)

0B FF FE 41 for the sensor type 11 (aka 0x0B) and 1 mph is reverse aka -447 mm/s.

Any idea what I am missing?

Thanks

Bruce

2

Hi Bruce,

To my eyes, your packet looks OK.

I wonder if the receiver is expecting timeTag to be ‘close’ to iTOW? Maybe the data is being rejected because your millis timeTag is too far from ‘now’? Just a guess…

Cheers,

Paul

3

According to clive on the uBlox support portal:

clive1 (Customer)

3 days ago

ttag should be your time base, say the MCU side 1 ms tick when you acquire the measurement. This should allow for relating things in your time line with changes seen by the GNSS in it’s time line. Creates a f(x) = mx + c relationship

I had the same question myself.

Above makes sense as the the clocks are asynchronous and if you interpolate between reading then you need to know the time stamp of the readings.

I was wondering of my byte order is correct(lowest byte to highest for a given input type). I looked in the libary and saw that baud rate was being modified in this manner so that is how I interpreted it.

Thanks

Bruce

4

Hi Bruce,

Yes, everything is little-endian. So, yes, your data looks fine - to my eyes.

Cheers,

Paul

5

Things that might help:

Set the starting spot to zero. If this has a ‘random’ value in it, it could cause issues…:

https://github.com/sparkfun/SparkFun_u- … nd.ino#L99

6

(OK, yes, the initializer should do that for you… Clutching at straws here!)

7

3.5.1 UBX 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 also use the same acknowledgement mechanism.

Are we sure that ESF-MEAS is a message to expect and ACK from?

Thanks

Bruce

8

Humm… Very good point! There are other ACK-less messages… Set a maxWait of zero and the ‘send’ will return immediately without wasting two seconds waiting for a reply - that may never come…

9

Michael Ammann get the credit. He suggested monitoring MON-MSGPP to see if a valid message is received in the appropriate port.

Thanks

Bruce

10

PS, I wish uBlox gave a way to see the “raw” data like the do for the built in sensors.

Thanks

Bruce

11

So I am still trying to figure out the speed part.

If I look at the ESF-MEAS-graph in UCenter I can’t figure out the how to get a negative speed values:

ESF-MEAS.JPG
ESF-MEAS.JPG1261×200 27.3 KB

Says it is signed 24 bits but when I try two complementing values I end up very large values as if speed is being interpreted as a unsigned values and the two complement value is a large valued unsigned int,

DataType.JPG
DataType.JPG1224×267 52.4 KB

The data field below is defined as unsigned so I tried mannually applying two complement and get the same.

I also tried just changing bit 23 (the 24th bit) to no avail. Does not seem to be very well defined in the documentation.

ESF-MEAS-Struct.JPG
ESF-MEAS-Struct.JPG753×534 32.9 KB

Any ideas would help.

Thanks

Bruce

12

Hi Bruce,

I’d try something like the following:

  union
  {
    int32_t signed32;
    uint32_t unsigned32;
  } signedUnsigned; // Avoid any ambiguity casting uint32_t to int32_t
  // The dataField is 24-bit signed, stored in the 24 LSBs of a uint32_t
  signedUnsigned.unsigned32 = sensorData.data.bits.dataField  << 8; // Shift left by 8 bits to correctly align the data
  float speed =  signedUnsigned.signed32; // Extract the signed data. Convert to float
  speed /= 256.0; // Divide by 256 to undo the shift
  speed /= 1000.0; // Convert from m/s * 1e-3 to m/s

I hope this helps!

Paul

13 
if (dir == 0)
  {
    message.data[0].data.bits.dataField = 0;
  }
  else
  {
    message.data[0].data.bits.dataField = (lroundf(speed) & 0xFFFFF);//speed is now mph2mmpsec
    if (dir == 3)
    {
      message.data[0].data.bits.dataField = ~message.data[0].data.bits.dataField + 1;
    }
  }

dir is come from the PRNDL indicator. 0 is park, 3 is reverse. 2 and 1 (for low).

Good old two’s complement.

Thanks

Bruce

14

Hi Bruce,

You might find this useful:

https://github.com/sparkfun/SparkFun_u- … ag/v2.2.14

There were some gremlins in the ESF RAW code which are now fixed. But I see now that there are similar issues in the ESF MEAS code. ESF MEAS is also output-only. It cannot be polled. So I need to make similar tweaks there. getEsfDataInfo and getESFMEAS both need to go… So does the first overload of getSensorFusionMeasurement. You probably won’t notice any difference, it’s just a code clean-up. In theory, ESF MEAS coudl contain more than 7 readings - possibly up to 31, so I’ll make sure the library supports that.

Please watch out for v2.2.15. Coming soon! (Hopefully today…!)

All the best,

Paul

15

Thanks…