mirror of
https://github.com/richonguzman/LoRa_APRS_iGate.git
synced 2026-10-31 02:51:58 +01:00
QRPLabs LightGateway Plus (Solar) 1.0 reboot loop at startup when unable to find programmed network #229
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/LoRa_APRS_iGate#229
Reference in new issue
Block a user
EDIT7:
Heltec V3.2 connected via real USB-C cable to pc, COM5. Silicon Labs CP210x USB to UART Bridge
Flash from website.
Goes through normal sequence.
Takes about 2 minutes to download.
Automatically reboots the board.
Board presents a hotspot.
I minimally configure hotspot for my home Wi-Fi network.
I save and it reboots.
Shows version data 10-15-2025.
I now via my home network connected browser configure the webpage (callsign, late/lon/icon, etc., as for a fully standalone digipeater.
I SAVE and it reboots and presents as hotspot (192.168.4.1) with N0CALL-10 as callsign.
yellow light flashes once per second.
does not receive packets that it should be receiving. I wait a few minutes to see if it reboots on its own.
after 15 minutes, i rejoin the network hotspot.
None of my settings have been remembered.
I try again.
SAVE, it reboots, none of my settings have been remembered.
I then for giggles flashed it with Heltec V3, that did not work.
I then reflashed it with Heltec V3.2 as before.
Programmed the hotspot webpage with my home network. Saved and it rebooted.
finished setting up the board using a webbrowser on my home network.
Save, it reboots, my settings have been remembered.
On the hotspot webpage, change the home network to a ficticious one. Save and reboot.
Now it has become unstable. It shows a hotspot but perhaps as soon as it receives a packet it causes the hotspot to crash and the board restarts.
I'll stop here and not even involve platformio and VSCode.
EDIT6:
Same thing is happening to a brand new Heltec V3.2 board I just received. I used VSCode and platformio to clone the igate repository, flashed the board directly from platformio, the board started up in hotspot mode, I edited it to recognize the home network. I then completed the setup using a webbrowser on the home network.
The board worked fine for 30-40 minutes, even through multiple further edits of the webpage and subsequent saves.
I then purposefully changed the Wi-Fi ssid, hit SAVE and the board restarted, could not find the fake home network, and the first time it receives a packet it crashes and reboots.
Is there something special about flashing from Platform IO that I'm not doing? Whether I click first on the Build check-mark or the upload right arrow, it seems to compile and do the same thing.
For the Heltec board, I am using this variant:
EDIT5:
The unit has been sitting on the bench for the past day or two, connected to the home network, and seemingly stable. I put it in the truck, and drove a 100 m from the house to see what happens when it loses the home network. After a minute or two, it rebooted and upon not finding the home network, went into hotspot mode with the active node display (callsign, WiFi: OFF, APRS-IS OFF, Stations, last heard, RSSI, etc.) and continued to behave properly (didn't reboot when it received a packet). I waited about 10 minutes while away from the home network, and it continued to behave properly, digipeating packets as necessary, and obviously receiving packets without rebooting.
I forced a reboot while away from the house. It rebooted, and went into hotspot mode. I sent a packet from my truck's node, and immediately it caused the QRPLabs unit into a reboot. From this point on, the unit would reboot, go into hotspot mode, show the active node display, then upon decoding a packet, would reboot, endlessly.
I drove back to the house, and upon re-acquiring the home network, the rebooting behavior stopped and it continued to operate as normal.
It does seem to be something about losing the home network?
EDIT4:
The reason it has something to do with the SF7 is because my network is operating at SF7, and when a packet is received successfully by this board it causes the firmware to crash. This is my current operating theory. I do not have a spare board, there are 3 in the post tho.
I will bring out another type of board, a Heltec, and a LilyGO, and see if those boards exhibit any similar issue. I don't know that they will. I can also state that I have 3 other QRPLabs LightGatewayPlus 1.0 boards and they are all on the air and running as far as I know properly.
This may be a hardware issue?
EDIT3:
It might need callsign and LoRa RX SF7 setting to start happening.
EDIT2:
Has something to do with enabling SF7 in RX
If i program it for SF8 or higher it doesn't seem to do it.
EDIT1:
No, it's not even that it happens when it's unable to find the home network. If I fill out all the details
callsign
lat/lon
igate star
no wi-fi network
enable rf beacon
repeater mode wide 1-1 2-1
enable tx
433775000 tx/rx
SF7 tx/rx
CR6 tx/rx
bw 125
send internal/external voltage as telemetry
save it
it will continue to reboot irregularly. It's really hard to figure out what setting is triggering it or if it's any setting.
Issue: Board cycles when starting up hotspot
Description
After flashing from website and some configuration, board reboots multiple times, showing
connecting to wifi
...
WiFi not connected!
Loading
CALLSIGN N7UV-5
then reboots
(during the above, green light on for two seconds, then blinks 10x 1/s)
Perhaps useful details
Using QRPLabs_LightGateway_Plus_1_0 firmware, dated 15OCT25
Flashed using WebFlasher on site
Connected to hotspot 192.168.4.1 configured it for my home network (SSID/password) and save.
Rebooted, joined my home network. Seems stable.
Now, I changed the SSID to a non-existent network, save and reboot
From this point on it randomly reboots at times:
154354
154418
154441
154503
154724
154746
154820
154843
154903
154929
152950
etc...
Did the following one at a time to some extent to see when the problem occurred.
Loaded in callsign, lat/lon, enabled LoRa TX, changed LoRa params, nothing specific seems to cause it to start rebooting, and there doesn't seem to be anyway to prevent it from rebooting once it has been programmed once for a valid network.
Let me know what else that I can do that might help.
Cheers and 73 - Jon N7UV
I think I was able to get around this problem. I went back to digi/igate version 13OCT25 3.1.3 and the QRPLabs board is behaving properly even when not connected to the home network. Perhaps there was something that changed in the wifi_utils.cpp section?
The board reboots its wifi unless you are connected or until it connects to something
what is your goal with this? (i could not get the goal)
Have the board as Digi or iGate?
if Digi, which "eco mode"?
my goal is to have a remote digi, same as always. I have 4 remote digis currently. None of the digis have aprs-is connection.
There is no network connection available at those remote locations. When I initially build the digi, it is at home and I use my network to configure it via a full screen network web gui. When at the remote site, I need to check the functionality of the digi looking at received packets, and may need to modify the configuration as necessary. For that, the hotspot mode is the only way.
This is no different from the way I have been using the devices since I put the first one in the field 9 months ago.
I have not understood the utility of your "eco modes" so I leave those settings alone. I want to be able to hike up to the remote site and connect to the hotspot without opening the enclosure. If there is an eco-mode that turns on the hotspot function every 10 minutes and leaves it running for a minute or two, and then shuts it down if there's no local connection, perhaps that would be useful to me. At the remote locations, I do not currently need serial, but I do need hotspot available.
OFF : normal mode, has wifiAP and also serial output
ULTRA: Wifi AP of, no serial, just repeating using ultra low current at idle
OFF: same as the first one without WiFiAP
as you need the WiFiAP (although it uses 250mA at idle more or less) the first one is the only one for you, unless you do it the ULTRA EcoMode and exit from it with Queries (?EM=OFF)
That's what I thought. I would prefer to not run the AP when not needed, but it looks like there's no way to avoid doing that. Perhaps there would be a way to hike to the site while it is running in ECO Ultra mode, open the enclosure, push the reset button, and it will keep the WiFi AP running for a few minutes?
I will have to size the batteries accordingly. In any event, I am using 3.1.3 firmware for now since it does not do the continual rebooting.
To send the ?EM=OFF command over the air, is that via a message from me directed to the callsign of the digi? For that, I would need to have a keyboard on the device I carry, yes?
You can use the phone to send messages using the tracker as tnc for this
Enable the phone callsing to be the manager and this will enable you to control it over radio which mode to work.
there is no phone service at the sites.
You don't need any phone service to send messages over Lora using the tracker as tnc
This apps can work without any cell coverage
my mobile aprs.fi app does not allow me to send messages directly. Do I have to upgrade to the more expensive version to send the appropriate message?
Also, I realized that I could carry my T-Deck Plus with me and send a message via RF to the digi. Would that work?
Aprs.fi has indeed a payment fee to free the messages 🫠
T-deck would work
thanks for that info. I hadn't wanted to spend the money on aprs.fi unless I saw real value.
I have a qrp-labs unit on the bench running 3.1.3 firmware. I sent it a command ?EM=ON and the screen became blank. If I send it the ?EM=OFF command, the screen remains dark. Should it turn back on?
Never mind. I must have done something wrong the first time. I sent the ?EM=OFF command again and the screen came back on.
I believe I can figure out a way to work with this remote control feature!
check that the board is only as digi (not as igate with aprs-is enabled nor wifi ssid added)
this way it goes back and forth from EcoMode to Normal with queries
I am closing this issue as it seems that the original problem has been resolved. Gracias Ricardo