Our team is looking to design and create a surveying tool that will utilize RTK from an online NTRIP server (no Base hardware) as well as an additional sensor (via I2C) that collects separate data to be mapped and logged. The plan is to have our GPS hardware alongside a tablet that will act as our GUI for the surveying tool. I have scoured over all the great resources on Sparkfun and checked out the hardware and firmware files for the Sparkfun RTK products. I knew very little about GPS before this project but thanks to Sparkfun and all the FANTASTIC resources and open source content, we feel we at least have a very clear path forward, so thank you Sparkfun! That said, I have a few lingering design questions.
Since we don’t need/want a Base station, it seemed like the RTK Express Plus was a good place to start. However, our application is not automotive and our surveying will not be happening in or around a car. Does the internal IMU on this device need special configuration for this use case? Or can we simply use the RTK source like we would for any other Sparkfun RTK product?
Can we use SW Maps (or other GIS app) for the NTRIP Client for corrections over Bluetooth at the same time we are receiving cm-level NMEA sentences, also over Bluetooth? i.e. our Samsung tablet will have an internet connection to receive RTK correction data via the built in NTRIP Client on SW Maps (we’ll most likely be using Skylark as a source). Does the RTK Express Plus utilize Bluetooth for both the correction data going TO it at the same time as the NMEA coming FROM it? Are both of these data streams using the same Bluetooth SPP service?
For testing and prototyping purposes, it seems that we could easily purchase an RTK Express Plus and simply tack on our additional sensor via the I2C connector. To fetch this data, we’d obviously need our firmware flashed to the ESP32. Is it advisable to fork the Sparkfun open source firmware and flash modified code directly to the ESP32 on the RTK device?
I could only find the main firmware for the RTK surveyor, is the RTK Express Pluss Firmware also open source?
Since we don’t need/want a Base station, it seemed like the RTK Express Plus was a good place to start. However, our application is not automotive and our surveying will not be happening in or around a car. Does the internal IMU on this device need special configuration for this use case? Or can we simply use the RTK source like we would for any other Sparkfun RTK product?
The Express Plus is best for automotive applications where signal will be potentially lost (like a tunnel). Otherwise, there is no benefit to the IMU. This may change someday if ublox adds IMU support for other applications but they are really focused on the car market for the time being.
Can we use SW Maps (or other GIS app) for the NTRIP Client for corrections over Bluetooth at the same time we are receiving cm-level NMEA sentences, also over Bluetooth? i.e. our Samsung tablet will have an internet connection to receive RTK correction data via the built in NTRIP Client on SW Maps (we’ll most likely be using Skylark as a source). Does the RTK Express Plus utilize Bluetooth for both the correction data going TO it at the same time as the NMEA coming FROM it? Are both of these data streams using the same Bluetooth SPP service?
Yes. Yes. Yes.
For testing and prototyping purposes, it seems that we could easily purchase an RTK Express Plus and simply tack on our additional sensor via the I2C connector. To fetch this data, we’d obviously need our firmware flashed to the ESP32. Is it advisable to fork the Sparkfun open source firmware and flash modified code directly to the ESP32 on the RTK device?
Yes.
I could only find the main firmware for the RTK surveyor, is the RTK Express Pluss Firmware also open source?
Sorry for the confusion. The RTK Firmware (https://github.com/sparkfun/sparkfun_rtk_firmware) is what you want. It’s one firmware to rule them all. The RTK firmware uses a handful of ID methods to determine the platform its operating on. Generally speaking, this is a pair of resistors off an analog input pin, but for older designs like the RTK Surveyor we scan the I2C bus to help us ID what is available. You should be able to run the RTK Firmware on any ESP32 based board with nothing else attached. It’s designed to run even if the GNSS fails, display fails, accel fails, etc. So if you have a Thing Plus (https://www.sparkfun.com/products/20168) it should run. If you start to plug on additional hardware (ZED-F9x, display, etc) the RTK firmware will then activate and use those peripherals.
Thank you for all the confirmations! It seems these RTK products are going to be a great platform for us to prototype with. We ended up purchasing the RTK Express (w/o IMU) and I have one main follow up question:
I noticed in the firmware and radio configs that there is an option to switch the Bluetooth radio from Classic to BLE, could you explain what occurs when the ESP is set to BLE? Is it still utilizing the same SPP or a different profile? As my initial post alludes, we are looking to implement at least one workflow that ONLY requires Bluetooth for high-accuracy GPS readings AND some additional sensor data. So my prototyping challenge at the moment is finding a clever way to interrupt(?) the NMEA TXs from the ring buffer and send our sensor data, also over Bluetooth. I’m confident in my ability to write a trigger for this process (controlling exactly when sensor data is captured and transmitted) but I’m more concerned about the implementation within the Bluetooth capabilities of the ESP. Additionally, I’ve developed plenty of BLE firmware but precisely 0 with Classic profiles, hence my curiosity with that particular setting.
SPP = Bluetooth v2.0. BLE = Bluetooth v4.0 (I think). It’s a very different protocol. The main purpose for the BLE option:
Bluetooth SPP does not work at the same time as the ESPNow radio: https://docs.espressif.com/projects/esp … exist.html But ESPNow has been shown to work along side BLE. Unfortunately not many GIS apps support BLE (only SWMaps to my knowledge).
Thank you! And thank you for time in responding to this thread, we are making excellent progress due in part to your info and confirming my questions.
Back to the BLE configuration: Do you know if, when the BLE option is selected in the RTK firmware, the ESP is using the SPP service as documented here?
This seems likely, but I wasn’t sure if the ESP32 WROOM fell under this particular category. The Bluetooth capabilities seems to vary across ESP versions.
Let me know if this thread is too old and/or if I should make a new post.
But my question now is still about the BLE implementation on the RTK firmware.
It seems some of the libraries and firmware have been updated and I’m getting some compile errors that I haven’t been able to resolve myself.
In the bluetoothSelect.h file there seems to be some issues with the Bluetooth callback function registrations.
~\\Firmware\RTK_Surveyor\bluetoothSelect.h: In member function 'virtual void BTLESerial::onConnect(BLEServer*)':
~\\Firmware\RTK_Surveyor\bluetoothSelect.h:155:48: error: expression cannot be used as a function
connectionCallback(ESP_SPP_SRV_OPEN_EVT, nullptr);
^
~\\Firmware\RTK_Surveyor\bluetoothSelect.h: In member function 'virtual void BTLESerial::onDisconnect(BLEServer*)':
~\\Firmware\RTK_Surveyor\bluetoothSelect.h:161:54: error: expression cannot be used as a function
connectionCallback(ESP_SPP_CLOSE_EVT, nullptr);
^
~\\Firmware\RTK_Surveyor\Bluetooth.ino: In function 'void bluetoothStart()':
~\\Firmware\RTK_Surveyor\Bluetooth.ino:214:61: error: no matching function for call to 'BTSerialInterface::register_callback(void (&)(esp_spp_cb_event_t, esp_spp_cb_param_t*))'
bluetoothSerial->register_callback(bluetoothCallback); // Controls BT Status LED on Surveyor
^
In file included from ~\\Firmware\RTK_Surveyor\RTK_Surveyor.ino:400:
~\\Firmware\RTK_Surveyor\bluetoothSelect.h:16:23: note: candidate: 'virtual esp_err_t BTSerialInterface::register_callback(void (**)(esp_spp_cb_event_t, esp_spp_cb_param_t*))'
virtual esp_err_t register_callback(esp_spp_cb_t * callback) = 0;
^~~~~~~~~~~~~~~~~
~\\Firmware\RTK_Surveyor\bluetoothSelect.h:16:23: note: no known conversion for argument 1 from 'void(esp_spp_cb_event_t, esp_spp_cb_param_t*)' to 'void (**)(esp_spp_cb_event_t, esp_spp_cb_param_t*)'
Compiler doesn’t seem to be liking the implementation here:
// override BLEServerCallbacks
void onConnect(BLEServer *pServer)
{
// bleConnected = true; Removed until PR is accepted
connectionCallback(ESP_SPP_SRV_OPEN_EVT, nullptr);
}
void onDisconnect(BLEServer *pServer)
{
// bleConnected = false; Removed until PR is accepted
connectionCallback(ESP_SPP_CLOSE_EVT, nullptr);
Server->startAdvertising();
}
Nor does it like the main firmware’s attempt to register the connection callbacks. That one might be a typo in the pointer syntax but I’m not entirely sure.
This happens when compiling right out of the box. Firmware and dependencies most recent as of today. My first inclination was that this error was happening upon an update to BleSerial library from Avinab Malla. But I’ve looked through the library and its edit history on Github and can’t seem to figure out where or when the problem might have arose.
Feel free to post these sorts of issues on the firmware repo.
Try downgrading the ESP32 core to v2.0.2. Espressif ate an additional ~30k of RAM between the WiFi and BT libraries so we’re not able to be on the latest core version yet.
Thank you for your contributions to this thread. Your above response resolved the issues I was having.
Now I have more of a curious question that could possibly fix a mistake we made. The EAGLE files for the RTK Express board seems to include the ESP32-WROOM-32D as the actual component populated in the schematic. Of course there is also the text note with the part # listed as ESP32-WROOM-32E-N12 included in the schematic as well. However, since the component properties were populated with the 32D version, that’s what showed up on our BOM - which we most definitely should have caught in QC. But alas, we did not and now have two boards with the wrong ESP32 silicon and not enough flash memory to fit this application it seems. So my question is: Are we completely SOL here? Or is there a way to fit this firmware on the previous version? I’ve sifted through the datasheet of the 32D version and I’m pretty sure we’re SOL. But I thought I’d post here just in case.
Sorry for the confusion over that part. We updated our internal BOMs but the schematic lagged.
Our firmware and our tools have to support both the 4MB and 16MB versions of the ESP32-WROOM modules that were sold on the RTK Surveyor at the very beginning of the RTK product line. Said differently, I think you’re ok (but not ideal).
The GUI tool pings the ESP under test to see if it reports 4MB or 16MB flash, then picks the appropriate partitions bin (https://github.com/sparkfun/SparkFun_RT … r/resource) and loads the RTK firmware bin + partitions(4 or 16MB) bin + boot_app0.bin + bootloader.bin.
If you’re building from source, you should be just fine, just load the correct partitions.bin file.
OTA is disabled on the 4MB version because there’s not enough room for the main firmware bin (~2.1MB) to fit into two equal OTA partitions on 4MB flash. Now if you shaved off some features, you might get it all to fit into ~1.8MB, re-do the partitions file to have two OTAs + SPIFFs (for settings) and retain OTA on a 4MB module, but we had to forgo that feature to support other, more important features (to us).