// probleemoplossing
Per symptoom de oorzaak en wat je eraan doet. Veel van deze problemen geven geen foutmelding: de radio is gewoon stil, of een board lijkt dood terwijl alleen de stekker verkeerd zit.
Oorzaak: spreading factor, bandbreedte of coding rate wijkt af. Een LoRa radio decodeert alleen packets met exact dezelfde SF, BW en CR. Een ander packet is voor hem ruis.
Oplossing: zet alle nodes op dezelfde vier waarden en controleer ze op het apparaat zelf, niet alleen in je config. De frequentie mag een paar honderd Hz afwijken (dat valt ruim binnen 125 kHz), de andere drie niet. Voor ReticulumNet: 869.463 MHz, BW 125 kHz, SF8, Coding Rate 5. Zie LoRa.
# instellingen die de radio echt gebruikt
rnodeconf --info /dev/ttyACM0
Oorzaak: de ontvanger raakt overstuurd door een zender op een paar centimeter afstand.
Oplossing: zet ze voor een test 1 tot 2 meter uit elkaar.
Oorzaak: op boards met een externe versterker, zoals de Heltec V4, is de waarde in het log waarschijnlijk het niveau van de SX1262 vóór die versterker. De SX1262 zelf gaat tot 22 dBm. Ingesteld 28 dBm, in het log txp=19: dat verschil is de versterking.
Oplossing: geen. Kijk of pa=1 in de TX regel staat: dan is de versterker actief.
Oorzaak: --txp accepteert alleen 0 tot 17.
Oplossing: geef de waarde via de prompt van rnodeconf, bijvoorbeeld met echo.
echo 21 | rnodeconf -T --freq 869463000 --bw 125000 --sf 8 --cr 5 /dev/ttyACM0
Oorzaak: aan één kant van de USB-C connector maakt een datapin geen contact. USB-C heeft twee sets datapinnen, en welke gebruikt wordt hangt af van hoe je de stekker insteekt. Een kabel die alleen laadt geeft hetzelfde beeld.
Oplossing: draai de stekker 180 graden om, nog vóór je andere kabels of knopvolgordes probeert. Verschijnt er dan nog niets, steek een telefoon in dezelfde poort met dezelfde kabel. Ziet de computer die wel, dan ligt het aan het board.
# live lijst van USB apparaten
ls /sys/bus/usb/devices/
# kernel meldingen bij insteken
sudo dmesg -w
Oorzaak: marginaal contact in de connector (EPROTO). Dit is het voorstadium van het vorige probleem: de connector gaat stuk.
Oplossing: gebruik de andere oriëntatie en zet het board direct in de computer, niet in een hub. Een board dat steeds wegvalt kan andere apparaten op dezelfde hub mee laten resetten.
Oorzaak: een ander programma houdt de seriële poort open: een seriële monitor, een script of een service die op dezelfde poort een ander apparaat verwacht. Fouten als "Inflate error" of een MD5 mismatch lijken op een kabelprobleem, maar zijn het niet.
Oplossing: zoek het proces en stop het tijdens het flashen.
lsof /dev/ttyACM0
Oorzaak: de header van het merged image geeft een andere flashgrootte op dan het board heeft, bijvoorbeeld 8 MB op een board met 16 MB. Flash je met --flash_size keep, dan neemt esptool die verkeerde waarde over. Kenmerk: elke herstart op hetzelfde adres, en geen enkele regel van de firmware zelf.
Oplossing: wis het flashgeheugen, flash met de juiste grootte, en haal daarna de stroom eraf voor een echte koude start. Byte 4 van het image moet bij 16 MB 4f zijn, bij 8 MB staat er 3f.
# header controleren
od -An -tx1 -N8 firmware_merged.bin
# wissen en flashen voor een board met 16 MB
esptool --chip esp32s3 --port /dev/ttyACM0 erase_flash
esptool --chip esp32s3 --port /dev/ttyACM0 write_flash --flash_mode dio --flash_freq 80m --flash_size 16MB 0x0 firmware_merged.bin
Oorzaak: bij veel goedkope kastjes gaat die poort naar de laadprint, met alleen voeding en geen datalijnen.
Oplossing: open het kastje en gebruik de USB-C op het board zelf. Bij sommige kant en klare repeaters, zoals de SenseCAP Solar Node P1, is de externe poort wel volledig doorverbonden.
Oorzaak: spanningsdip zodra wifi en radio opstarten (brownout).
Oplossing: gebruik een korte kabel of een voeding die genoeg stroom levert.
Oorzaak: de firmware vergelijkt de hash van zijn eigen image met een doelhash in EEPROM. Bij een flash via .uf2 kent de bootloader de grootte van het image niet, dus die doelhash is nooit gezet. Gevolg: ook rnodeconf -T lijkt te werken, maar de instellingen worden stil niet opgeslagen.
Oplossing: zet de doelhash op de hash die de firmware zelf rapporteert. Na een flash via .uf2 is dat de hash van nul bytes. Controleer het na elke nieuwe flash.
rnodeconf --get-firmware-hash /dev/ttyACM0
rnodeconf --get-target-firmware-hash /dev/ttyACM0
rnodeconf -H e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /dev/ttyACM0
Oorzaak: je hebt de poort in de config gezet: port = tcp://192.168.1.50:7633. RNS voegt poort 7633 zelf toe en probeert de hele string als hostnaam op te zoeken.
Oplossing: laat de poort weg.
[[LoRa]]
type = RNodeInterface
port = tcp://192.168.1.50
Oorzaak: pip install upgradet rns en lxmf systeembreed mee, ook onder services die op een bepaalde versie draaien.
Oplossing: installeer extra tools in een eigen virtual environment, of met pipx.
python3 -m venv ~/nomadnet-venv
~/nomadnet-venv/bin/pip install nomadnet
Oorzaak: de tijd op rmap.world is het moment van ontvangst, niet van verzenden. Transport nodes bewaren announces en sturen ze opnieuw uit als iemand een pad opvraagt. Komt de discovery announce van een host (rnsd) in plaats van het board, dan gaat hij ook door als de radio uit staat. Waarden als accuspanning en ruisvloer blijven de laatst bekende.
Oplossing: trek geen conclusies uit de kaart alleen. Zeker weten doe je het pas als het adres van de node in het log van een andere node in LoRa bereik verschijnt, of als je de node zelf uitleest.
Oorzaak: een discovery announce gaat bij de meeste firmware eens per zes uur uit, plus één kort na het opstarten. Een node zonder internet komt pas op de kaart als een transport node met een internetverbinding zijn announce doorgeeft.
Oplossing: zet discovery aan (discoverable = yes in rnsd, of de advert optie in standalone firmware), herstart de node voor een directe announce en wacht een paar minuten. Zie op de kaart.
Oorzaak: rmap.world haalt een node pas weg na 7 dagen zonder announce. Handmatig verwijderen kan niet.
Oplossing: wachten. Komt er nog steeds een announce binnen, kijk dan of een host met discoverable = yes namens die node announcet.
Oorzaak: rnpath leest de padtabel, en die kan gevuld zijn met een oude announce. Een pad met een onwaarschijnlijk aantal hops is meestal zulke oude kennis. rnprobe werkt alleen naar het probe adres van een transport node, niet naar zijn discovery adres.
Oplossing: probe naar rnstransport.probe met het juiste adres, en lees een timeout niet als bewijs dat de node dood is.
rnpath <destination hash>
rnprobe rnstransport.probe <probe hash>
Oorzaak: de README van het project noemt een ander netwerk en adres dan de firmware gebruikt.
Oplossing: houd PRG langer dan 5 seconden ingedrukt. Verbind met het open wifinetwerk RTNode-Setup en ga naar http://10.0.0.1. Het portaal opent ook bij een board zonder opgeslagen configuratie, en na 5 resets achter elkaar vóór de firmware stabiel draait. Uit en aan zetten met een schakelaar telt niet als reset. Over de seriële poort zijn geen commando's.
Oorzaak: de firmware laadt zijn tabellen uit flash. paths en dsts zeggen dus niets over ontvangst.
Oplossing: kijk naar de teller pin (packets in). Loopt die op, dan ontvangt de node echt iets.
Oorzaak: RTNode heeft geen OTA, en het portaal kan geen firmware ontvangen.
Oplossing: flashen kan alleen via USB. Bij een node op een moeilijk bereikbare plek betekent elke update dat je erheen moet.
Oorzaak: een laad LED zegt alleen dat er spanning op de laadschakeling staat. Op boards met twee gelijke JST connectors, zoals de Heltec V4 (zonnepaneel en accu), kan een kabel op de verkeerde connector de LED laten branden terwijl de ESP32 niet start.
Oplossing: controleer op welke connector de kabel hoort, en kijk of de node echt zendt (TX regels in het log, of ontvangst op een andere node).
Oorzaak: JST kabeltjes worden door verschillende fabrikanten met omgekeerde draadvolgorde geleverd. Omgekeerde polariteit op de accu aansluiting sloopt het board.
Oplossing: vergelijk vóór het aansluiten de plus en min op de print met de draadkleuren. Passen betekent niet dat hij goed zit.