meshtastic
[Bug]: T3S3 E-ink only working using non E-Ink firmware
Category
Other
Hardware
Other
Is this bug report about any UI component firmware like InkHUD or Meshtatic UI (MUI)?
- [ ] Meshtastic UI aka MUI colorTFT
- [ ] InkHUD ePaper
- [ ] OLED slide UI on any display
Firmware Version
2.7.13.597fa0b
Description
Ive just got a LoRa T3-S3 E-ink and im trying to get it to work with meshtastic
Installing the correct firmware does appear to work at first, but attempting to set a region causes the device to reboot with after a RadioLib err=-707
This has happened on a variety of firmware versions, both beta and alpha.
Attempting to use the non E-Ink version of the firmware however does appear to work seemingly normally. Region can be set, nodes discovered etc.
Switching back to the e-ink firmware without a wipe does preserve settings, however it then starts bootlooping again, each time with the RadioLib err=-707 message before a reboot.
Relevant log output
Based on some information in https://github.com/meshtastic/firmware/issues/6294
I attempted building the project myself with #define TCXO_OPTIONAL,
This instead results in RadioLib err=-2
As a follow-up, 2.7.16.a597230 tested, issue still present
At this point, I'm running the non e-ink firmware as a fallback.
I'm happy to help test experimental builds to debug if needed
Do you know what type of radio chip you have? I see in the T3S3 oled variant there's a definition for a LR1121 radio which does not exist in the T3S3 ePaper variant.
Can you post the log when it detects the radio successfully?
The one i have has a SX1262 label on the back
The label may be irrelevant. Important is the detection. Please check the log and post the result.
Detection seems to confirm it ``WARN | ??:??:?? 10 No RF95 radio
DEBUG | ??:??:?? 10 SX126xInterface(cs=7, irq=33, rst=8, busy=34)
DEBUG | ??:??:?? 10 SX126X_DIO3_TCXO_VOLTAGE defined, using DIO3 as TCXO reference voltage at 1.800000 V
INFO | ??:??:?? 10 Start meshradio init
INFO | ??:??:?? 10 Radio freq=906.875, config.lora.frequency_offset=0.000
INFO | ??:??:?? 10 Set radio: region=UNSET, name=LongFast, config=0, ch=19, power=30
INFO | ??:??:?? 10 myRegion->freqStart -> myRegion->freqEnd: 902.000000 -> 928.000000 (26.000000 MHz)
INFO | ??:??:?? 10 numChannels: 104 x 250.000kHz
INFO | ??:??:?? 10 channel_num: 20
INFO | ??:??:?? 10 frequency: 906.875000
INFO | ??:??:?? 10 Slot time: 28 msec, preamble time: 131 msec
INFO | ??:??:?? 10 Final Tx power: 22 dBm
INFO | ??:??:?? 10 SX126x init result 0
INFO | ??:??:?? 10 Frequency set to 906.875000
INFO | ??:??:?? 10 Bandwidth set to 250.000000
INFO | ??:??:?? 10 Power output set to 22
DEBUG | ??:??:?? 10 Current limit set to 140.000000
DEBUG | ??:??:?? 10 Current limit set result 0
DEBUG | ??:??:?? 10 Set DIO2 as RF switch, result: 0
DEBUG | ??:??:?? 10 SX126X_RXEN not defined, defaulting to RADIOLIB_NC
DEBUG | ??:??:?? 10 SX126X_TXEN not defined, defaulting to RADIOLIB_NC
DEBUG | ??:??:?? 10 Use MCU pin -1 as RXEN and pin -1 as TXEN to control RF switching
INFO | ??:??:?? 10 Set RX gain to boosted mode; result: 0
INFO | ??:??:?? 10 SX1262 init success``
I can kinda reproduce this. I doesn't happen always but when the eInk display is redrawn (which happens very often) it seems to block the radiolib operation, hence the assert and reboot.
That would make sense.
I had previously tested both with and without the inkyhub firmware, the behaviour varied slightly but ultimately it was pretty unreliable.
That could explain why it works on the non e-ink firmware though. Maybe there's a voltage sag, or sufficiently long hold up that causes the issue.
The BLE connection seems a bit flaky too, could be related? But I don't necessarily want to mix the issues.
I'll investigate a couple theories I have when I'm home and report back if I find anything interesting