I noticed the following module differences between RTK Torch and RTK Facet:
RTK Torch uses ESP32-WROOM-32U-N16R2, which supports an external antenna for WiFi/BLE.
RTK Facet uses ESP32-WROOM-32E-N16R2, which has an embedded antenna.
Both modules include 16 MB flash and 2 MB PSRAM.
Based on this, I’m evaluating options for adding logging and external storage.
My Questions
If I embed eMMC or an external memory card slot on the RTK Torch for continuous logging, is the 2 MB PSRAM enough when the device is acting as a base or rover while also handling BLE/WiFi communication and mobile connectivity at the same time?
For smoother, lag-free performance during high-rate logging and multitasking, would it be better to upgrade to ESP32-S3-WROOM-2-N32R16V (32 MB flash + 16 MB PSRAM)?
If switching to the ESP32-S3-WROOM-2-N32R16V, are there sufficient available pins on the Torch design to integrate eMMC or a microSD slot without major redesign?
And finally, is it possible to add logging support to the RTK Facet with minimal firmware changes, without modifying other existing functionality?
I’m looking for hardware/firmware guidance from SparkFun community members.
Let me know your thoughts!
The original RTK Facet uses ESP32-WROOM-32E-N16. It does not have PSRAM. The Bluetooth stack takes up most of the available SRAM. This is why we are limited to v2.0.2 of the ESP32 Arduino Core; Bluetooth uses even more RAM on the later cores. Even so, we run into RAM issues when we have BT and WiFi running simultaneously.
On RTK Everywhere, we are currently limited to v3.0.7 of the core, because again the later versions use more SRAM.
Only the original ESP32 supports Bluetooth Classic + BLE. The S3 is a nice microcontroller, but it only supports BLE.
I only want to know whether an ESP32-S3 module (32 MB flash + 16 MB higher PSRAM) would perform better than the current ESP32-WROOM-32U-N16R2 in the RTK Torch if I redesign the hardware and firmware to add continuous logging.
My main concern is:
Will the S3 handle BLE connection + WiFi + ongoing configuration + high-rate raw GNSS logging more smoothly than the original ESP32, or would the S3 still struggle with memory/throughput while multitasking?
I understand the S3 does not support Bluetooth Classic, only BLE — but if BLE is enough for my mobile app, is the S3 a better overall option for adding logging?
If not, please suggest any better alternative MCU/module for this type of workload.
I’m sorry. You will need to test the S3 to find out. I do not know how much RAM Bluetooth uses on the S3 with the latest Arduino Core, or any core. I do not have an S3 to test.
If I compile RTK Everywhere for the ESP32 using v3.0.7 of the Core, I see:
#42 107.8 Sketch uses 3432109 bytes (84%) of program storage space. Maximum is 4055040 bytes.
#42 107.8 Global variables use 82512 bytes (25%) of dynamic memory, leaving 245168 bytes for local variables. Maximum is 327680 bytes.
If I compile for ESP32S3 using v3.3.4 of the Core, I see:
#42 19.76 /RTK_Everywhere/bluetoothSelect.h:10:10: fatal error: esp_sdp_api.h: No such file or directory
#42 19.76 10 | #include "esp_sdp_api.h"
If I compile for ESP32S3 using v3.0.7 of the Core, I see:
#42 41.78 /RTK_Everywhere/bluetoothSelect.h: In member function 'virtual void BTClassicSerial::enableSSP(bool, bool)':
#42 41.78 /RTK_Everywhere/bluetoothSelect.h:129:26: error: 'enableSSP' is not a member of 'BluetoothSerial'
#42 41.78 129 | BluetoothSerial::enableSSP(inputCapability, outputCapability);
#42 41.78 | ^~~~~~~~~
#42 41.78 /RTK_Everywhere/bluetoothSelect.h: In member function 'virtual void BTClassicSerial::onConfirmRequest(void (*)(uint32_t))':
#42 41.78 /RTK_Everywhere/bluetoothSelect.h:149:26: error: 'onConfirmRequest' is not a member of 'BluetoothSerial'
#42 41.78 149 | BluetoothSerial::onConfirmRequest(cbPtr);
#42 41.78 | ^~~~~~~~~~~~~~~~
#42 41.78 /RTK_Everywhere/bluetoothSelect.h: In member function 'virtual void BTClassicSerial::respondPasskey(uint32_t)':
#42 41.78 /RTK_Everywhere/bluetoothSelect.h:159:26: error: 'respondPasskey' is not a member of 'BluetoothSerial'
#42 41.78 159 | BluetoothSerial::respondPasskey(passkey);
So, if you do want to use the S3 and do want to reuse our firmware, you have some challenges to solve…