I have the F9P board sending I2C data to a Redboard QWIC and displaying it on an I2C SerLCD 4x20 display. I got this all working quickly using the excellent example code (specifically AutoPVT). Now I need to also log raw UBX data to the SD card for post-processing. The update rate is 1 second so there should be plenty of time to update the display and write to the card. I am able to read and write to the SD card using other example code (SPI) so that works. I haven’t been able to figure out how to get raw data from the F9P to the SD card. And I’m not even sure what data needs to be stored for post processing. Has anyone out there done that?
Congrats! And thanks! That was a lot of fun example code to write. tve did the good work on AutoPVT tho (yay! collaboration).
I agree with you - you should have plenty of time to write ~1k bytes via SPI to microSD card.
Checkout this example: https://github.com/sparkfun/SparkFun_Ub … e.ino#L149
This shows how to create your own function to handle incoming RTCM bytes however you want. In your case I’d blend in the SPI/SD write functions inside this processRTCM() function.
Hope you get it working!
Sparky, thanks for the quick reply. My application is to measure the locations of fixed points by saving 15 to 30 minutes of UBX data and then post processing that data later with CORS correction. So this device will NOT be providing or receiving RTK corrections and it will not be connected to a PC. The example you pointed out seems to be intended to send correction data to another device over VHF radio. I am still trying to get my head around all this so excuse me if I misunderstood. As I see it, UBX raw data needs to be saved for post processing with CORS. I am assuming that the F9P can be configured to send UBX raw data (5.15.3 UBX-RXM-RAWX from the interface description) , although I don’t know how, which I can write to a file on the SD. Can RTCM binary data also be used for post processing?
PhilG-
I am working toward the same goal - logging raw data for post processing. I haven’t been able to write to my sd card. Can you share that set up? This post tells you what data you need to write.
Skyveyor. I have this working but it took me quite a while and I had to modify the Sparkfun library to look for RAWX data. My hardware uses a 4x20 LCD to display all the PVT data, a Feather M0 which has plenty of RAM for buffering data and a Featherwing SD/RTC board. I use the RTC to create a 8x3 filename for the SD files and I intend to keep it up to date with the TIMEUTC which I am getting from the Ublox. I have two buttons, one to scroll all the data on the LCD and the other to start and stop the RAWX data writes to the SD. The SD is SPI, the Ublox and RTC are I2C and the LCD is Serial. What I am looking at now is how to get the SD data off the card without having to remove it every time. It’s just not convenient and too delicate to keep removing. I am thinking of using a terminal app to request and save the data files to a PC. All my development work is n a Mac but the RINEX conversion has to be done on a PC (ugh). I would be glad to share the code but there’s a lot of it and I’m not sure how to do that.
PhilG,
Thanks for the reply. I plan to try logging with a Sparkfun Openlog via UART. Not sure if this will work. I thought I was going to test it today. Unfortunately, my openlog module arrived damaged and unusable. I hope to give it another go next weekend.
Thank you,
David
David,
Serial is kinda slow but I like the I2C version of Openlog. I think It would be better to capture the Ublox data from the I2C port directly to the SD. That would be simpler than my solution. But, I am also getting PVT and TIMEUTC data from the I2C port that I display every second. That’s extra data that I don’t want in the RAWX data file. I don’t know if I am loosing any RAWX data. The convert program isn’t complaining but I wonder if it is throwing out any corrupt data. I am still looking for a better way to load the data to the PC. A PiZW would be the way to go if it is fast enough to capture and store the data. Then I could access it over a LAN. I though of sharing the SD between the M0 and a PiZW but I don’t want to go down any more rabbit holes right now.
Phil -
This is already a bigger and deeper rabit hole than I wanted. I am not sure I can use I2C. According to Ublox f9 documentation the receiver must be in slave mode. Can I use openlog as the master. The other thing I am concered about is polling data. Openlog needs to know when to receive data. I have zero experinece with I2C or coding. I mostly hack together snippets of wisdom from various sources.
Skyveyor, Well I don’t know the answer to many of those questions. In my case the F9P is set to send RAWX, PTV and TIMEUTC over I2C when requested. The Arduino library takes care of reading the data. I don’t know about Openly but I am guessing it can’t be a master requesting data. Yes, this is a rabbit hole. I bought into it thinking it would be easy given the Arduino library but I guess we are trying to do something that those on the bleeding edge using RTK don’t care about. I have something working but I am looking for a way to easily transfer the RAWX files to the PC without removing the SD card. It could be done over USB or Bluetooth but it will take about 20+ minutes to reliably transfer 10 files containing 15 minutes of fixed location RAWX data of 1.4MB each at 115.2kbps. Wifi is the way to go. I plan to explore whether a pi zero w is responsive enough to handle the data coming from the Ublox. If it could store the data on it’s own SD then it could easily be transferred over wifi. Problem is, there’s no library to handle this so I would start from scratch and I’m certainly not a Linux guru.
PhilG,
At least we can commiserate. I am bit surprised Ardusimple or Sparkfun aren’t providing a data logging module. My guess is many people are interested in PPK GEO Tagging. It’s really the best way to get cm level accuracy to drone images. I suspect you are correct that openlog can’t be a master. I should have an opportunity to connect the serial version of openlog via UART this weekend. One of the advantages of binary data is it’s compact so I think UART will be fast enough. We’ll see.