NEO-M8U IMU data (UBX_ESF_RAW_MAX_LEN not correct) #133
Comments
|
Hi @adamoskaranikas , Let's walk this through... The datasheet says that the M8U's Max navigation rate is 30Hz. But it also says that the max sensor measurement output rate is 100Hz. Then in section 1.9: "For post-processing applications sensor data is available from messages UBX-ESF-MEAS and UBX-ESF-RAW (high rate). Each message includes the time of measurement." So, if I'm reading this right, you should be able to request ESF-RAW at the full 100Hz. My starting point would be Example5 which lets you access the ESF data using callbacks. The example doesn't include RAW but the functions are there:
There's a cryptic note in the M8 protocol description for UBX-ESF-RAW which says "Note that the rate selected in UBX-CFG-MSG is not respected. If a positive rate is selected then all raw measurements will be output.". So it sounds like you should get RAW at the full rate as soon as it is enabled? More detail: So, again, this suggests you cannot actually set the rate of the RAW messages. Once enabled, you get them at the maximum rate by default? One thing you will need to change is this: The ESF-RAW message will be 68 bytes long. At 100Hz, that's 6800 bytes/sec. With I2C, that's approximately 70 kbits/sec. So you will probably find that 100kHz I2C runs out of steam, especially if you have other messages enabled. You're going to need to use 400kHz. Please give it a try and see what happens. I don't have time to test this for you. You will need to do all of the experimenting yourself. But I'm happy to leave this issue open until you've got it working. Let me know if you need more pointers. Best wishes, |
|
Hello @PaulZC , Thanks a ton for the pointers, for me this is a great starting point, I was aware of some of the points you brought up, but it's nice to have the validation from someone with a bit more experience in the area. I'll start doing some tests and will update on the issue, as I feel like I'm not the only one that has thought of implementing this functionality. That way there can be a starting point for others. |
|
Hi Adam, Please let us know if you need more help with this - otherwise can you please close this issue? Very best wishes, |
|
Hi @PaulZC, I found this issue just now, looking to basically do the same as Adam. To summarize, I would like to get the raw IMU measurements out (UBX_ESF_RAW), hoping that these are available even before getting to a proper calibration (fix type 4). I followed the same procedure as in the ESF callback examples (which work for me) for the ESF_RAW message, but unfortunately to no avail. Do you have any pointers as to how I could get raw IMU readings via that msg. From the documentation and your post above, I understand the module should be able to do that... Best, |
|
Hi Nico, Are you using I2C to communicate with the NEO? I'm wondering if 100kHz I2C is the bottleneck, preventing the messages from being generated? How often are you calling Have you called I just tried enabling ESF RAW on USB using u-center and it's working:
Wow... It is generating a LOT of data... It appears to be generating 0x23C = 572 bytes in each message. Every ~50ms... OK. That's about 91kBits/sec. There's no way 100kHz I2C will be able to keep up... You really need 400kHz I2C as a minimum. If you switch to Serial - the library supports both - you're going to have to change the UART1 baud rate to 460800 to stand a chance of keeping up... SPI might be a smart move. The library supports that too. That's all the time I can spare for now. Please dig into this yourself and let me know what you find. Please reach out again next week if you're still having problems. Best wishes, |
|
Hi @NicoZobernig @adamoskaranikas , Hang on! The ESF RAW messages are much bigger than I was expecting... When I added ESF RAW to the library, I assumed each message would contain one 'set' of raw sensor measurements. But the NEO is sending way more than that. The messages above contain 564 data bytes. Subtract 4 for the OK. We need to change this line: to something like: Humm. Yes. That might explain why you've not been getting any data! Ah. We need to make a change here too: to something like: Please try making these changes and let me know what happens. (I don't have time to do it myself. Sorry!) Thank you, |
PaulZC
changed the title
|
The more I think about this, the more weaknesses I see…. This line needs to change: |
|
This is problematic too. It can only access the first sensor block. It is unaware of blocks 2-10…. |
|
Hi @PaulZC, back in front of my PC, will start to look into this now! I did the setup correctly I believe, ESP32 with 1kHz tickrate, I2C running at 400kHz, called and call to check if I'm getting something. After including the proposed changes (all besides I am, however, still a little confused about what exactly I am getting here... I will continue playing around with it. |
|
Also, what is the purpose of However, when also calling it at the end of the task loop, I am getting output that seems more correct in a way: Only getting a specific timestamp once. The rate seems quite slow though, definitely not the 100Hz I hoped for yet. |
|
Hi @PaulZC! I got something going, manage to read it all out now :) The code is more or less calling inside the main loop of the task. The code in the callback is not getting executed if I don't call Anyway, the output looks like this: which seems correct. The one thing that's bothering me is that the data is only available at around 10 Hz, although we do get around 10 sensor readings per batch (ergo 100Hz). But since new data is only available at this lower rate, I don't see the point in having old data. I believe this behavior is coming from the NEO though, and not the library, is that correct? |
|
Hi Nico (@NicoZobernig ), Great job - thanks for digging into this. The callback only gets called if you call When I wrote the ESF RAW "auto" code, I was expecting the module to output the RAW data one 'set' of measurements at a time, like it does when you poll a single set. I suspect the module is sending 10 at a time to make the interface more efficient. The overhead is 8 bytes per packet/message. In summary, it is outputting data at 100Hz. You do get all the data, and each reading is timestamped. It is just arriving in sets or groups of 10 readings, not one at a time. You need to be a little bit careful when manipulating the sensor data. It is 24-bit signed (two's complement). There is a forum post here that might help. OK. I've got some work to do here. As a minimum, I need to add an extra field to I won't be able to get to this straight away. I'm working on a different project at the moment. But I will hopefully get to it in a few days. Thank you for your patience. The other project is to do with logging data at high speed, and logging ESF RAW data would a great example for that, so I might use that as an excuse to work on this sooner! ;-) Very best wishes, |
|
Hi @NicoZobernig @adamoskaranikas , OK... I believe this is fully resolved in v2.2.14. Please see the release notes for more details. Please try the new examples and let me know if you see any more weirdness. Thank you for your patience - and for reporting this issue. It is good to have it fixed. I'm going to close this issue as I believe it is - now - fully resolved, but please re-open if necessary. Enjoy! |
|
Hi @PaulZC However, when replacing the NEO-M8U with a ZED-F9K (automotive version of ZED-F9R) we cannot receive the raw sensor measurements. Is this an issue with the module or the library? From my understanding, there is no difference between F9R and F9K apart from the automotive rating (temperature, ruggedness etc.) Can you confirm this understanding and if so do you know why the F9K cannot report raw sensor measurements? Thanks! |
|
Hi Simon (@shecker ), What version of the HPS firmware is your F9K module running? I'm wondering if this is linked to the UBX-CFG-MSG being deprecated. Or, maybe the F9K outputs the RAW data differently to the F9R? Some things to try: Please enable the debug messages with Do you see any ESF-RAW data arriving: Class 0x10 ID 0x03? If so, please post the data here. Please also try v3 of the GNSS Library: https://github.com/sparkfun/SparkFun_u-blox_GNSS_v3 Best wishes, |
|
Please also scroll back to this comment: It would be helpful if you could do the exact same thing with the F9K: enable ESF-RAW on USB using u-center; copy and paste the HEX packet here so I can take a look. I'd like to check the F9K is outputting the same amount of data as the F9R. |
|
Hi @PaulZC We checked the firmware of our ZED-F9K module and this is version 1.00. Unfortunately there is no firmware update available on the official ZED-F9K product support page. However, there is a newer firmware HPS1.30 available for the ZED-F9R. Do you know if this is compatible and we can flash this? We would like to avoid bricking the device. |
|
Hi Simon, I'm afraid I've got zero experience with the F9K... The best way forward is to create an account at u-blox.com, go to the support portal, and open a support case. (I see you've already asked a public question about this.) Best wishes, |
|
Hi @PaulZC The updated example was very helpful. I used the code of "SparkFun_u-blox_GNSS_Arduino_Library/examples/Callbacks/CallbackExample12_ESF_MEAS_In_Loop/". However, we found one problem with running this file. The acceleration is updated normally, but the gyro value is very slow to update. I used ZED-F9R and ESP32, have you had this problem before? Thank you. |
|
Hello @jinhyeongRepo , I do all of my work from my desk. It is difficult for me to put the F9R into a car - to perform the calibration. Is the gyro slow to update both before and after the calibration? How are you testing the gyro? In a vehicle? The gyro will only give a non-zero value when the sensor's angular velocity is changing. Best wishes, |
|
Hello @PaulZC Thank you for your answer.
Thanks! |
|
Hello @jinhyeongRepo , Thank you. I had not used the "graph" option in u-center before. That is very useful! OK. I see the same issue. I see the Time and 3*Accel arriving rapidly:
The speed ticks arrive much less often. The gyro data - almost never... I suspect this is to do with the I2C bandwidth. We are using 400kHz, but maybe it is not fast enough? I will try SPI next... |
|
Very curious... This is from the ESF Callback example - modified so it uses SPI:
Sensor Type 16, 17 and 18 are the accelerometers. Type 10 is the speed tick. Again, almost zero gyro data. If I change the code so it prints only gyro data, I see almost zero data:
Investigating... |
|
Ah. OK. I understand what is happening! Looking at the ESF MEAS data in u-center: Notice how six messages arrive all together at 12:05:58.589: The data highlighted in green is accelerometer data (16, 17 and 18) (0x10, 0x11 and 0x12). The data highlighted in blue is the gyro data (14, 13, 5 and 12) (0x0E, 0x0D, 0x05 and 0x0C).
If the data is all being added to the I2C - or SPI - buffer at the same time, then the library code will only save the first message and will ignore the others as it has nowhere to store them. (The code does not allow the callback copy to be overwritten.) OK. To be able to record the accelerometer and gyro data, I need to create additional storage. Possibly some kind of circular buffer (ring buffer) like we do for the MGA messages: SparkFun_u-blox_GNSS_Arduino_Library/src/u-blox_structs.h Lines 2385 to 2391 in 2ae7289 OK. I am going to create an issue (feature request) for this: #179 It will take me some time to implement this. Thanks again for reporting. Best wishes, |
|
It's a nasty hack, but you can access the gyro data by reading
Here is the modified code: |
|
hello @PaulZC Thank you for your help. I've been able to understand what's causing the issue thanks to you. I'm going to use an external sensor for now, and if everything works out, I'll update my project later. Thanks again. |
|
Or use ESF RAW? Best wishes, |
|
Thank you for your suggestion to solve the problem.
On the other hand, "SparkFun_u-blox_GNSS_Arduino_Library/examples/CallbackExample12_ESF_MEAS_In_Loop/CallbackExample12_ESF_MEAS_In_Loop/CallbackExample12_ESF_MEAS_In_Loop.ino", which uses MEAS instead of RAW, works well. However, in this case, the problem I mentioned earlier occurred. It's late now, so I think I have to work on it tomorrow. |
|
Hi jinhyeong (@jinhyeongRepo ), That's very strange... Example10 and Example11 work OK for me:
Please check what version of firmware your module is running. In u-center, open UBX-MON-VER:
Perhaps you need to upgrade? Best wishes, |
|
Hi @PaulZC Thank you. As you said, after updating the firmware the values are coming in normally!! Now I can do other things. :) Thank you!! |
Subject of the issue
This is more of a question than an issue. I'm using a NEO-M8U at high nav rate (~30Hz) and its been really good. After diving in to it a bit more, I've began wondering if it's possible to extract its IMU data at rates higher than 30Hz. If this is possible, it'll allow me to remove an external IMU from my setup which would save quite a bit of cost.
Your workbench
The module is connected to a ESP32 WROOM32D via qwic i2C. It's normally powered by USB, but eventually I'll be powering everything out of a motorcycle can bus.
I was wondering if you guys have any experience with getting the IMU data out separately from the UBX message at different rates.
Any help is greatly appreciated!
PS I know that I should probably be asking this on the UBLOX forum, but the response times there are atrocious and this is slightly time sensitive so I'm hoping I could pick your guys' brains about this idea.
The text was updated successfully, but these errors were encountered: