Porting Moshe-Braner fork to Midi Edition (Heltec Wireless Tracker)

[Sasa Mihajlovic]

Hello everyone,

I want to port the Moshe-Braner fork of SoftRF to the Midi Edition hardware (Heltec Wireless Tracker ).

This is the hardware:

• ESP32-S3FN8 SoC
• Semtech SX1262 sub-GHz radio
• UniCore UC6580 GNSS (GPS, GLONASS, BDS, Galileo, NAVIC, QZSS)
• 0.96" SPI TFT 160x80 display

Chip info dump:

start detect chip...please wait

chip sync ...
Chip is ESP32-S3 (QFN56) (revision v0.1)
Features: WiFi, BLE, Embedded Flash 8MB (GD)
Crystal is 40MHz
MAC: f412fa6c60d4
Manufacturer: c8
Device: 4017
Status value: 0x200200
Detected flash size: 8MB

Looking for guidance, tips, or experience on porting MB fork to this hardware.

[Moshe Braner]

Should be doable.  First, find out how to detect this specific model at runtime - there is probably code for that in Linar's version.  Alternatively, can select this model at compile time, but then you'll have various different binaries, rather than one unified binary for all ESP32-S3 boards.

Once the model is detected or assumed, you need to know the correct GPIO pins for the various functions, e.g., GPS serial input, PPS wire, radio chip control pins, etc.  Those too are presumably in Linar's code.

The rest is easy, other than possible differences in the way the display interface works.  Nice to have twice the flash space.  Will need to design a case for this board.

If you do all this, I would add your code into my version to support this hardware!

[Moshe Braner]

I see this in Linar's ESP32.cpp:

#elif defined(CONFIG_IDF_TARGET_ESP32S3)

switch (flash_id) {

...

case MakeFlashId(GIGADEVICE_ID, GIGADEVICE_GD25Q64):

 /* Heltec Tracker has no PSRAM onboard */

 esp32_board = ESP32_HELTEC_TRACKER;

 hw_info.model = SOFTRF_MODEL_MIDI;

...

- so that's how that specific board is detected.  The bad news: it does not have PSRAM.  Even in the ESP32-S3 the size of RAM is very limited (about 300 kbytes!!!!!!) thus I make as much use of PSRAM as I can.  Since I've added more features to SoftRF than in Linar's version, more RAM (and flash) is needed.  If you use later ESP32 board support libraries (needed for ESP32-S3, at least 2.0.15), those tend to be larger, i.e., use more RAM.  So it may be difficult to fit into RAM.  On the old T-Beam I already had to add code to disable Bluetooth if you access the web interface, since there is (sometimes?) not enough RAM to run both at the same time.  (Reboot to restart BT.)

[Sasa Mihajlovic]

I asked ChatGPT to compare the ESP32 with the ESP32-S3FN8, and it generated the following table:

| Feature                | ESP32                          | ESP32-S3FN8                                   |
|------------------------|--------------------------------|-----------------------------------------------|
| CPU Cores              | Dual-core Xtensa LX6           | Dual-core Xtensa LX7 (newer architecture)     |
| Max Clock Speed        | 240 MHz                        | 240 MHz                                       |
| Performance            | Standard                       | ~15% faster per MHz + AI vector instructions  |
| Internal RAM (SRAM)    | ~520 KB                        | 512 KB                                        |
| RTC Memory             | 8 KB                           | ~16 KB                                        |
| PSRAM Support          | Yes (external, 4–8 MB common)  | No (FN8 = 0 MB PSRAM)                         |
| Flash Memory           | Typically 4 MB (module-dep.)   | 8 MB integrated                              |
| Wi-Fi                  | 2.4 GHz b/g/n                  | 2.4 GHz b/g/n                                 |
| Bluetooth              | BT 4.2 + BLE                   | BLE 5.0 (longer range, 2M PHY)                |
| USB                    | No native USB (needs CH340,...)| USB-OTG integrated                           |
| GPIO Pins              | Up to 34                       | Up to 45                                      |
| ADC                    | 12-bit (noisy)                 | 12-bit improved                               |
| Power Consumption      | Deep sleep ~5–10 µA            | Deep sleep ~5 µA (more optimized)             |
| Security Features      | Basic HW security              | Enhanced: Secure Boot v2, Flash Encryption v2 |
| Special Notes          | Available with PSRAM (WROVER)  | No PSRAM → limits large buffers / GUIs        |
|------------------------|--------------------------------|-----------------------------------------------|

I will first try to compile Linard’s latest version for that module, as well as your latest version for the T-Beam, to see how much space each version occupies.

[Moshe Braner]

Careful, so-called "AI" stands for "artificial information".  It may be mixing the MCU itself (ESP32-S3) and modules that include the MCU (which is what I suspect "ESP32-S3FN8" stands for, but I am not sure).  Just like the plain ESP32 MCU comes in modules such as the WROOM (without PSRAM) and WROVER (with PSRAM).  Both the flash and PSRAM are in separate chips, they communicate with the MCU via a (relatively slow) 4-wire connection (SPI).

In any case, if you're talking about that specific board from Heltec, then reportedly it does not have PSRAM.

I am still aghast that the newer chips still only have so little RAM.  I keep saying "about 300 kb" because the total (512 kb in this case) is not all usable for normal "RAM" to hold variables.  It is partitioned in complex ways, with areas for caching parts of the program (for faster access than the external flash chips) and so forth.  But why so little in total, can't they quadruple it in these massive ICs?

My version of SoftRF periodically reports (to the USB-serial) how much free RAM (heap space) it has.  After much effort I've brought that up to around 100 kb most of the time.  Before those efforts just adding BT to the Wifi ran out of RAM.  As far as flash space use, within the 4MB flash on the T-Beam, with OTA, it is now 91%.  (OTA requires two partitions in the flash, each large enough to hold the firmware, so one can have the new firmware loaded into it while the previous firmware is still running from the other.)

[Sasa Mihajlovic]

  In the SoftRF firmware, when the build is run on ESP32 hardware that has PSRAM, is the PSRAM accessed via explicit SPI read/write routines in the application code, or is the PSRAM integrated into the controller’s address space (memory‑mapped) and used like internal RAM (e.g., via malloc/heap and arrays)? I'm trying to understand if SoftRF expects PSRAM to be memory‑mapped or requires explicit peripheral access for buffering/data structures.  

[Moshe Braner]

It is in-between.  Explicit peripheral access is not required (unless you want to use more than 4MB of PSRAM).  Instead, in ESP32_setup() I use an ESP library call to tell the OS to allocate heap blocks above a certain size in PSRAM instead of regular RAM:

#if defined(CONFIG_IDF_TARGET_ESP32)
#include "esp_heap_caps.h"

...

      heap_caps_malloc_extmem_enable(1024);

#endif

This affects calls to malloc() and also implicit memory allocation calls when C++ objects are constructed.  Memory addresses returned by such calls can be used like any pointers but are somehow mapped to PSRAM (or rather, blocks of PSRAM temporarily cached in regular RAM).  When I don't want a block to be in PSRAM because access speed is important, I declare it as a static variable.  See for example data_block_buf[] in IGC.cpp.

[Sasa Mihajlovic]

I compiled Linar’s latest official version, SoftRF_v1.7.1, on Windows using Arduino IDE 2.3.6 with ESP32 core 2.0.9. I copied all of Linar’s libraries into my Arduino libraries folder and used a partition scheme of 8MB with SPIFFS (3MB app / 1.5MB SPIFFS). The build was extremely slow on my machine — I suspect it’s because Arduino IDE seems to use only a single thread for compilation.

Compilation results:

Sketch uses 1,842,417 bytes (55%) of program storage space. Maximum is 3,342,336 bytes. Global variables use 96,560 bytes (29%) of dynamic memory, leaving 231,120 bytes for local variables. Maximum is 327,680 bytes.

I’m curious — do you compile on Linux or Windows, and which ESP32 core version do you use? I’m also considering trying the new CLI version, or moving the build to Visual Studio Code + PlatformIO, which should compile faster since it can utilize multiple cores.

[Moshe Braner]

I use the tools mentioned in the documentation:  ESP32 Core version 2.0.3.  I wonder why you chose 2.0.9, which, too, is rather old.  For the ESP32-S3 I suggest at least 2.0.15, since there was a serious bug in earlier versions that did not allow the ESP32-S3 to boot while not connected to USB.  At least that was the case when I compiled OGNbase.  Note that the ESP32-S3 (unlike the original ESP32) has a USB interface built in, and it can work in various modes - you need to choose, e.g., USB-CDC in the compilation settings.  And USB-CDC in versions before 2.0.15 was buggy.  See here:  https://github.com/espressif/arduino-esp32/issues/9545

And yes the Arduino IDE compiles very slowly.  About 20 minutes to compile SoftRF on the old PC I use.  I have used both Linux and Windows, that is not the issue.  You can port to PlatformIO, I hear it is good.  But it will take some work to do the porting.  So far I have accepted the slow compilation instead  :-)

Nice to have 8MB flash rather than 4MB.  But notice (in the "Compilation results" above) the very small amount of RAM space available, sigh.

[Sasa Mihajlovic]

This is reason why I chose 2.0.9:

I'm currently trying to compile with arduino-CLI and I'm having trouble with the options...

I'll try 2.0.15 too.

--
You received this message because you are subscribed to the Google Groups "SoftRF_community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softrf_communi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/softrf_community/4dcd21b0-0234-4082-ae8c-c4ebdfc2a175n%40googlegroups.com.

[VirusPilot]

I am successfully compiling SoftRF upstream S3 targets (T-Beam Supreme and ThinkNode M5) with the following cli commands:

prepare:

arduino-cli config add board_manager.additional_urls https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json

arduino-cli core update-index

arduino-cli core install esp32:es...@2.0.17

ThinkNode M5:

arduino-cli compile -e -b 'esp32:esp32:esp32s3:PartitionScheme=no_ota,CPUFreq=240,PSRAM=enabled,FlashSize=4M,CDCOnBoot=cdc,USBMode=default'

ThinkNode M5 (alternative):

arduino-cli compile -e -b 'esp32:esp32:esp32s3:PartitionScheme=no_ota,CPUFreq=240,PSRAM=enabled,FlashSize=4M'

T-Beam Supreme:

arduino-cli compile -e -b 'esp32:esp32:esp32s3:PartitionScheme=default_8MB,CPUFreq=240,PSRAM=enabled,FlashSize=8M,CDCOnBoot=cdc,USBMode=default'

[Moshe Braner]

For the most part I don't mind the Arduino IDE GUI.  But it's rather annoying that every time I switch boards (e.g., from the T-Echo to the T-Beam) I have to re-enter all the compiler settings (CPU MHz, flash size, whether to enable PSRAM, etc).  If I could only save all those as a set in some sort of config file!

[Moshe Braner]

VirusPilot: are you compiling with "PartitionScheme=no_ota" for the boards with 4MB flash because it no longer fits within the 1.9 MB or so of each partition when using OTA?  That of course means you can't update the firmware via WiFi.

On Sunday, December 14, 2025 at 3:03:20 AM UTC-5 VirusPilot wrote:

[Sasa Mihajlovic]

I managed to compile and install versions 2.0.15 and 2.0.17.

The code is larger than with version 2.0.9 and at first glance it seems to work but I was unable to connect to the wifi web server. There is a problem with wifi authentication, it seems like the passwd is not good.

Linar does not have Wifi lib in its Library folder so it uses Wifi lib from core.

I would conclude that Wifi lib that comes with version 2.0.9 and versions 2.0.15 and 2.0.17 are not 100% compatible.

I used this script to compile:

arduino-cli compile "C:\Users\sasa\Documents\Arduino\SoftRF_v1.7.1_esp-s3" ^
   -e -b "esp32:esp32:esp32s3:CPUFreq=80,FlashSize=8M,PartitionScheme=default_8MB" ^
   --jobs 8 --verbose

To view this discussion visit https://groups.google.com/d/msgid/softrf_community/8e98f7d0-027a-46a4-bf43-eb3984e36d0bn%40googlegroups.com.

[VirusPilot]

Correct, with S3 and 4MB flash there is no chance for OTA. Maybe there would be a chance with a custom partition table ...

[VirusPilot]

I believe I came to the same conclusion.

[Moshe Braner]

I have had "wrong wifi password" issues on some T3S3 boards (on which I installed OGNbase), and that was solved by using a full "flash erase" in the ESPtool (and then re-installing the firmware of course).  So it wasn't a library issue.

[Sasa Mihajlovic]

Hi Moshe,

I did some tests comparing ESP32 core 2.0.9 and 2.0.17 by compiling SoftRF v1.7.1. After performing a full flash erase (EraseFlash=all), WiFi works fine on both versions.

Here’s a summary of the results:

I’ve also attached a screenshot from Notepad++ highlighting the compilation outputs and used libraries for both cores. This gives a clear visual comparison of differences in sketch size, memory usage, and library versions.

Thanks again for your guidance!

Best regards,
Saša

To view this discussion visit https://groups.google.com/d/msgid/softrf_community/05049081-6ff1-4e8a-a9bb-7c8323d4dce9n%40googlegroups.com.