MicroReticulum for Heltec v4.3

[daylight-hub]

Hi! I compiled the microReticulum firmware for the Heltec v4 using the new RNode v1.86. There is one change made to the MTU setting:

Config.h:59:20: error: expected unqualified-id before numeric constant
#define MTU 508
RNode's Config.h defines MTU 508 as a plain preprocessor macro, but microReticulum's Type.h also defines Reticulum::MTU = 500 as a class constant. When the preprocessor runs, it replaces MTU everywhere including inside the microReticulum class definition, causing a syntax error.
The fix is to rename RNode's MTU macro to LORA_MTU in Config.h and everywhere it's used.

Would you consider this fix to be stable? If so, that is what I have compiled here: https://github.com/daylight-hub/heltec_v4_transport

[massimilianopal]

Hi,

this is probably a different issue than the MTU compile-time conflict, but it may still be related to Heltec V4/V4.3 support.

I tested a Heltec WiFi LoRa 32 V4 in EU868 with microReticulum_Firmware 1.86.2.

The firmware flashes and the board can be used from MeshChatX/RNS in RNode-compatible mode, but I am seeing an RX-side problem:

• Heltec V4 TX works: a RAK4631 running microReticulum receives packets from the Heltec.
• The RAK sometimes receives the Heltec transmission with noticeable delay.
• Heltec V4 RX does not appear to work: the RX counter does not increase and it does not receive packets from the RAK4631.
• Same LoRa parameters were used on both devices.
• Swapping macOS / Windows 11 hosts does not change the behavior: the issue follows the Heltec.
• I reproduced the same behavior with standard RNode_Firmware.
• The same Heltec V4 hardware works correctly with Meshtastic via the web flasher, so the board, antenna and LoRa hardware seem to be OK.

This makes me suspect that the issue may be in the RNode-compatible Heltec V4 support path rather than in microReticulum transport mode specifically.

Possible areas could be SX1262 initialization, DIO/BUSY/RESET pin mapping, PA/LNA handling, RF switch handling, or GC1109/front-end initialization.

Has anyone tested RX/TX on Heltec V4/V4.3 in RNode-compatible mode against another RNode/microReticulum device?

[massimilianopal]

Small correction / update after more testing.

I originally suspected a Heltec V4 RX-side problem, but after further tests I think that conclusion was wrong.

At the time I only had one Heltec V4 available, so I was testing it against a RAK4631. Yesterday I flashed two Heltec V4 boards with microReticulum_Firmware and tested them against each other using the same LoRa parameters.

Result:

• Heltec V4 ↔ Heltec V4 communication works.
• Both Heltec V4 boards can communicate with each other.
• The problem appears when using the RAK4631.
• The RAK4631 has now been tested both in normal RNode-compatible mode and in transport/TNC mode.
• The previous LittleFS / SPIFlash boot crash reported in issue RAK4631 crashes at boot in LittleFS / Adafruit SPIFlash init #50 is fixed with firmware 1.86.2.
• However, a communication problem remains on the RAK4631 side.

So I no longer think this is primarily a Heltec V4 RX issue. The more likely current issue is with the RAK4631 / nRF52 / SX1262 communication path, or possibly with RF switch / DIO2 / RX-TX handling on that board.

I will collect cleaner logs and test results and probably open a separate issue for the RAK4631 communication problem, since issue #50 was specifically about the flash init crash and that part is fixed.