tx, rescue for FRM303, few more optimizations

[olliw42]

title says it just for testing purposes @rotorman

[olliw42]

a comment for testing based on pure phenomenological observation, using the new JRPIN5_FULL_INTERNAL_ON_RX_TX instead of the previous JRPIN5_RX_TX_INVERT_INTERNAL and JRPIN5_DISABLE_TX_WHILE_RX defines gave me much lower probability for the error to occur, i.e., the radio has to typically run for longer for the issue to occur (for the first time). For testing of the rescue mechanism it can thus be usefull to revert back to the previous JRPIN5_RX_TX_INVERT_INTERNAL and JRPIN5_DISABLE_TX_WHILE_RX defines.

[rotorman]

Built with added #define MLRS_FEATURE_OLED and

#define JRPIN5_RX_TX_INVERT_INTERNAL
#define JRPIN5_DISABLE_TX_WHILE_RX
//#define JRPIN5_FULL_INTERNAL_ON_RX_TX

After only 20 seconds or so, have now blue to teal LED blinking instead of green blinking, but the telemetry still runs on the radio. Thus, CheckAndRescue();does its thing, but the underlying issue is still there.

Update: tested next also with:

//#define JRPIN5_RX_TX_INVERT_INTERNAL
//#define JRPIN5_DISABLE_TX_WHILE_RX
#define JRPIN5_FULL_INTERNAL_ON_RX_TX

first time got blue LED in 5 seconds, second time took ca. 1 minute.

[olliw42]

MANY thx! so the CheckAndRescue() will go in. And it will stay, even if we ever find the real issue, and will go in also for the other modules, just as a feel-safe. interesting, JRPIN5_FULL_INTERNAL_ON_RX_TX works consistently much better for me. But what do we know. LOL.

[olliw42]

@rotorman so here is another test for you, use the "old" code in main, but set UART_IRQ_PRIORITY 0 in main-tx.cpp.

I'm writing up a longer report of my results, and I will comment on this there, but you may want to test this :)

1 made it much better, but I still got a stuck. With 0 it runs even better, as much as I can tell so far. Can't tell it's 100% safe, but safer. (the underlying rational: the F07x only has 2bits for priority !!!!!)

[rotorman]

First test results with previous CheckAndRescue() firmware state, where I removed the M5Stack ATOM Lite from the serial Pins of FRM303, and replaced with FTDI adapter, running Mission Planner via cable - that took now 8 Minutes to get into blue LED state.

Next test, using current main branch with changed UART_IRQ_PRIORITY 0 (old setting was 10). Only other change relative to GH main is addition of #define MLRS_FEATURE_OLED. Testing again with FTDI, instead of M5Stack ATOM Lite on TX-side FRM303 serial pins. After 20 minutes, still going. Will update here as something new happens, or 1h is reached w/o telemetry lost. Then will retest again with M5Stack ATOM Lite attached instead of FTDI.

Update: after 1 hour still no telemetry lost. Changing now to M5Stack ATOM Lite and starting the counter over.

[olliw42]

great news. 0 is also running well for me so far.

I'm not sure your one-shot time numbers are meaningfull, for me it can vary a lot in repeated runs. Anyway, assuming they are, strange that the device hanging on the serial pins would make such a difference. Any idea as to why?

[rotorman]

Second try, with M5Stack ATOM Lite, running DroneBridge ESP32, hooked to TX side FRM303 serial port. Telemetry lost after 59 minutes and 4 seconds. And it seems more catastrophic as before, as now following new behaviors showed up:

• RX side FRM303 blinks red for lost link
• OLED display on TX side FRM303 has been frozen.
• No LED lights on the TX side FRM303 - no blinking, thus RGB LED off (black).
• Serial port telemetry on TX side also not functioning (obviously) anymore.

[olliw42]

oje ... this seems to be a different issue though ... that's a complete crash

I started a run now with OLED, in crsf mode, and with serial connected via usb-ttl adapter, and MissionPlanner running

is it possible that the M5Stack draws too much current? I mean, teh average consunption might be low, but it may do heavy spikes. I just recall the case of the ESP8266, which requires a quite beefy voltage source, like 500 mA beefy, not because it would consume that much power, but it does in short spikes ...

[olliw42]

added this now to the main branch. So closing.