I found this evening that the modem had lost connection again. Not sure when it failed as I had not checked it for a few days. The system is now reset. I might try a higher gain patch antenna for the modem if one can be found. Anyhow all listen up while it is still working, aye !!
THE LISTENING POST.
- Thread starter BillC
- Start date
Hi Dallas, I have reset the modem a couple of times around 11.00 pm. Had 4 bars too but still dropped out or froze. Tomorrow I go to mac street with modem and flydog. so the LP will be offline tomorrow during the day.
The watchdog is finished and ready to get installed.
There is a cron job that runs every 5 minutes and checks for upstream network connection, if it fails then the raspberry pi gpio is used to drive a relay to cycle power to the modem.
crontab entry
/usr/bin/check-net.sh
There is a cron job that runs every 5 minutes and checks for upstream network connection, if it fails then the raspberry pi gpio is used to drive a relay to cycle power to the modem.
crontab entry
Code:
*/5 * * * * /usr/bin/check-net.sh
Code:
#!/bin/bash
#
# Test network availability by pinging a nameserver
if ping -q -c 1 -W 1 8.8.8.8 > /dev/null; then
logger -t watchdog "Internet available. Modem is ok"
else
logger -t watchdog "*********** MODEM FAILED ******** No network, cycling power to the modem"
PIN=23
#set pin as an output
raspi-gpio set $PIN op
#turn relay on. Power to modem should be connected to the Normally closed
# so turning the relay on will remove power to the modem.
raspi-gpio set $PIN dh
#sleep for 5 seconds
sleep 5
# turn relay off, restoring power to the modem
raspi-gpio set $PIN dl
# restore gpio to input
# raspi-gpio set $PIN ip
fi
The raspberry pi outputs are 3V3, and can be easily damaged by 5V, so a buffer is required to drive the relay coil, I used the Jaycar relay module, it already has the drive transistor, the flyback diode and an indicator LED, plus it saved time in getting it finished. The duty cycle is expected to be fairly low, maybe one or two activations per day at the most. So the relay quality is not a major consideration,
The arduino gpio pins are by default inputs and with internal pullups enabled ( at least on GPIO23 ) so that when the raspberry pi is first powered up the input high can source sufficient current to turn on the relay, which is not desirable. A 10K pull down wasn't sufficient to keep the relay off.
However adding the following line in /boot/config.txt
forces the gpio pin 23 to an output low which fixes the problem.
I also put an additional 1K5 in series with the GPIO line.
I think it's time to deploy it to the listening post base station....
The arduino gpio pins are by default inputs and with internal pullups enabled ( at least on GPIO23 ) so that when the raspberry pi is first powered up the input high can source sufficient current to turn on the relay, which is not desirable. A 10K pull down wasn't sufficient to keep the relay off.
However adding the following line in /boot/config.txt
Code:
gpio 23=op,dlI also put an additional 1K5 in series with the GPIO line.
I think it's time to deploy it to the listening post base station....
Last edited:
Good idea, the logger already timestamps the log file entries in /var/log/syslog, but a counter is a great idea...
So Version 1.1 now looks like this.
Code:
#!/bin/bash
# Version 1.1 Ray Gardiner 17/5/2026
# Test network availability by pinging a nameserver
if ping -q -c 3 -W 2 8.8.8.8 > /dev/null; then
logger -t watchdog "Internet available. Modem is ok"
else
# increment a counter for the number of modem resets
bc <<< "1 + $(</usr/bin/reset_counter)" > /usr/bin/reset_counter
logger -t watchdog "$(</usr/bin/reset_counter)" "*********** MODEM FAILED ******** No network, cycling power to the modem"
PIN=23
#set pin as an output
raspi-gpio set $PIN op
#turn relay on. Power to modem should be connected to the Normally closed
# so turning the relay on will remove power to the modem.
raspi-gpio set $PIN dh
#sleep for 5 seconds
sleep 5
# turn relay off, restoring power to the modem
raspi-gpio set $PIN dl
# restore gpio to input
# raspi-gpio set $PIN ip
fiThe log file entries in /var/log/syslog now look like this... ( this is me unplugging the cat 5 cable to simulate network failure)
May 17 21:25:03 sdr watchdog: Internet available. Modem is ok
May 17 21:28:44 sdr kernel: [ 3150.102955] smsc95xx 1-1.1:1.0 eth0: Link is Down
May 17 21:30:04 sdr watchdog: 4 *********** MODEM FAILED ******** No network, cycling power to the modem
May 17 21:31:12 sdr kernel: [ 3298.901625] smsc95xx 1-1.1:1.0 eth0: Link is Up - 10Mbps/Full - flow control off
May 17 21:35:03 sdr watchdog: Internet available. Modem is ok
Fantastic work Ray. I hope that the watch dog system would automatically reset in the event of a power supply disconnection. This would not happen normally as the 12volt battery of cells works as a no break supply with charging by shore power charger and solar. But if the supply fuse were to fail would the watch dog regain its original settings upon the re application of power?
Nice relay unit Ray complete with the essential back emf diode too.
Update:
The watchdog has been deployed and commissioned.
The modem has been swapped out for a different one, ( same brand and model ) it was noticed that the modem had trouble connecting until the sim card contacts were cleaned and given a dose of deoxit. It's possible that, the sim card contact issue was the primary cause of the connection failures.
No connection failures since the modem was swapped over.
All three SDR's now on line
The watchdog has been deployed and commissioned.
The modem has been swapped out for a different one, ( same brand and model ) it was noticed that the modem had trouble connecting until the sim card contacts were cleaned and given a dose of deoxit. It's possible that, the sim card contact issue was the primary cause of the connection failures.
No connection failures since the modem was swapped over.
All three SDR's now on line
Tracking some strong interference this evening. I discovered that a battery charger in my workshop area about 100 meters from the SDR antennas was radiating crapp and noise into the SDR system. I fixed the noise problem with a sledge hammer, can,t put up with bad design.
Hi Bill, nice work with the sledge hammer 
I had a similar issue with a battery charger.
No watchdog timeouts on the modem since we installed it yesterday. So I'm thinking the dodgy sim card contacts, might have been the major culprit all along. It's still early days, but so far so good.
May 19 20:40:03 sdr watchdog: [Pass= 329 Fail= 0] Internet available. Modem is ok
I had a similar issue with a battery charger.No watchdog timeouts on the modem since we installed it yesterday. So I'm thinking the dodgy sim card contacts, might have been the major culprit all along. It's still early days, but so far so good.
May 19 20:40:03 sdr watchdog: [Pass= 329 Fail= 0] Internet available. Modem is ok
Last edited:
First connection failure. ??
May 20 19:10:03 sdr watchdog: [Pass= 599 Fail= 0] Internet available. Modem is ok
May 20 19:15:05 sdr watchdog: 1 **** MODEM FAILED ***** No network, cycling power to the modem
May 20 19:20:03 sdr watchdog: [Pass= 600 Fail= 1] Internet available. Modem is ok
May 20 19:10:03 sdr watchdog: [Pass= 599 Fail= 0] Internet available. Modem is ok
May 20 19:15:05 sdr watchdog: 1 **** MODEM FAILED ***** No network, cycling power to the modem
May 20 19:20:03 sdr watchdog: [Pass= 600 Fail= 1] Internet available. Modem is ok
Yes good work Bill, the 3 P's of problem solving well displayed.
1. Proactive decision
2. Positive action
3. Permanent outcome
'Strike while the iron is cold'
Just checked the log files, and we had a significant jump in network connectivity errors on July 8th, the first was at around 4:05AM on 8/7/2026, and intermittent failures continued up until 15:10PM. This was caused by the nationwideTelstra network outage.
Prior to that outage we had 2 unplanned outages over a 60 day period, both recovered automatically.
So the conclusion is that the original cause of failures was most likely the bad contacts on the Sim card.
Prior to that outage we had 2 unplanned outages over a 60 day period, both recovered automatically.
So the conclusion is that the original cause of failures was most likely the bad contacts on the Sim card.
A fantastic result Ray, well worth the effort on your part to design the automatic reset. Also it was interesting to discover that the Flydog operating system has enough spare capacity to operate the sense and reset, good job . I might have shut the system down a few days ago to test a B+ power filter, still noisy of course. Cheers.