Keeping only the last downloaded podcast....

My linux server uses podget to download podcasts. 

The downloaded podcasts are picked up using rsync by my Asus WL-520GU / OpenWRT based car audio player.

The Asus WL-520GU uses an 8GB USB stick for storage so care is needed to ensure that downloaded podcasts are cleaned up.

I went with the approach of keeping only the most recent copy of each subscribed podcast.

While podget has a facility to cleanup old podcasts this is time based and did not always seem to work for my subscriptions.  

Instead to solve the problem I created a shell script which is run on the linux server immediately after the podget process completes.

# Remove playlist files

rm *.m3u

# Remove all but the most recent podcast in each subfolder

for directory in `find . -type d \( ! -iname ".*" \)`; do
    find $directory -maxdepth 1 -type f -printf "%T@\t%p\n" | sort -k1,1n | cut -f2- | sed '$d' | tr '\n' '\0' | xargs -r0 rm -f

On the ASUS WL-520GU the rsync process is run with the --delete flag to ensure files that no longer exist on the server are deleted from the ASUS.


Who is using the water?... the bore monitor speaks

At the top of the hill on my rural property is a bore that provides stock water for my stock and three neighboring properties.


Bore Shed


So what does this have to do with thingspeak?

From time to time faults in the various farm system drain water from the header tank faster than the bore pump can pull water out of the ground.... so the pump runs continually.  Expensive on power but also potentially damaging.  Normal use is about 1 hour per day in summer, much less in winter.





The problem was how to know if the pump was running excessively without climbing the hill.... and even if I did check it was hard to know if the pump was running because it had just reached to refill point or had been running for three days.

A couple of years back I built a bore monitor that used an IR beam to determine of the bore pump was running and could be queried over the wireless network by a ruby application. 

The IR source and receiver are both powered by PICAXE08M microcontrollers.


IR Sender

(IR Beam Sender)



IR Receiver


(IR Beam Receiver)

The PICAXE code for the IR Beam Sender and Receiver are available here.  The Receiver uses a TTL output to indicate the bore running state. 

By querying every 5 minutes and storing the data in a MYSQL database on my server I could graph daily usage over time and see when things had gone awry.

The network connection in the original design was performed using an AVR AT90S8515 and a Packet Wacker ethernet interface.  For 2 years this worked well and then the Packet Wacker died.

Around this time i had been playing with DLink DSL-502T ADSL models and reflashing them with OpenWRT to provide Amateur Radio IGate services.  These worked really well in the APRS application so I wrote a Ruby application that monitors the IR sensor via a GPIO pin on the DSL and provides a browser based summary of the last 30 days activity.

Bore Running Summary

The status pages work well inside my network but I wasn't keen on opening a port on my router so I can check the status while I was at work or on vacation.  Unfortunately problems only happen when you go on vacation.


Thingspeak to the rescue....


Building a DLink DSL-502T Based IGate - TNC Schematic and Firmware

As mentioned elsewhere the TNC we use in the Igates is based on the ATMega8 based TNC design from Henry Carl Ott (N2RVQ).

For those interested in constructing their own here is the schematic

Mega8TNC Schematic

and version 1.9 AVR TNC firmware.

The firmware is a slightly modified version of N2RVQ's version 1.8 firmware which we call version 1.9.  

The difference is a startup delay to prevent the TNC transmitting via the serial port and preventing the DSL-502T from booting.

When programming an ATMega8 with the firmware ensure you set the fuses to 0xDA (High) and 0xBF (Low).   Incorrect fuse settings will prevent the chip from starting correctly.


DSL-502T IGate Front Panel LEDs

There are 5 LED's on the front of the DSL-502T.
DSL-502T IGate Front Panel 
Not much to say about the Power LED.  If the power is connected it should be lit.
The Status LED will start flashing as the unit boots and once the boot process is complete it will continue flashing at a slower rate (approximately once per second) as a "heartbeat".
The third (ADSL) LED does nothing.  Unfortunately it is not connected to a GPIO pin so we can't do anything useful with it.
The fourth Ethernet/Network LED has three states:
Off = Only during the initial stages of boot.
Flashing = Could not get an IP address on the network.  Check your network connection and that you have a DHCP server somewhere that will allocate an address.
On = Network running and IP address correctly assigned.
The USB/APRSD LED has three states:
Off = Only during the initial stages of boot.
Flashing = Could not find a configuration file for this unit at  The configuration files are named with the Ethernet MAC Address of the unit.
On = Configuration file loaded and aprsd running.
So if everything boots OK and is operational then the Power, Ethernet and USB LED's should be steady on and the Status LED will be flashing.

Page 16 of 25

Powered by Easytagcloud v2.1

Contact Andrew Quinn