Building simh for OpenWRT

I have always had a soft spot for minicomputers... real minicomputers from the early 70's... machines that filled 19" racks with panels full of blinking lights.  

I remember my father having a PDP8 at work before micros slowly took over...

and the Data General Nova I supported in one of my first jobs.... oh the Nova 3...

what I lovely machine.  I wish I had the forthought to save it when it was decommissioned.  

 

But back to now.... from time to time I have played with simh mainly OS8 on the PDP8 but had never really done anything serious.  The lack of blicking lights didn't make it quite the same.  One day I would build a PDP8 simulator to get a better experience but that is a big job and it stayed an idea until I wondered... could I compile simh (at least the simpler machines... definitely not the VAX or PDP11) and run this on a DLink DSL-502T router? (my NZ$1 universal hardware platform at the moment).  If I could then was it possible to add some blinking lights?

 

Part One... Building simh for OpenWRT

This turned out to be surprisingly easy if you have an OpenWRT build environment.  The steps are:

1. Download the simh sources from http://simh.trailing-edge.com/sources/simhv38-1.zip

2. Create a simh subdirectory in the package directory of your OpenWRT build environment.

3. Create a Makefile in the simh directory so the OpenWRT build process will find your new simh package.

4.  Create a src directory in the simh directory.

5.  Unzip the contents of the simh sources zip file into the src directory.  If you check the src directory contents you will find a subdirectory for each emulator and some shared files.

6.  Replace the standard simh Makefile in the src directory with one compatible with the OpenWRT build process.  

The following example builds the PDP8 and Altair simulators and is based on the style of the standard simh makefiles.  You can download it from here.

 

# build selected SIMH modules executable when user executes "make"
 
SIMHFLAGS = -lrt -lm -I .
SIM = scp.c sim_console.c sim_fio.c sim_timer.c sim_sock.c \
sim_tmxr.c sim_ether.c sim_tape.c
 
PDP8D = PDP8
PDP8 = ${PDP8D}/pdp8_cpu.c ${PDP8D}/pdp8_clk.c ${PDP8D}/pdp8_df.c \
${PDP8D}/pdp8_dt.c ${PDP8D}/pdp8_lp.c ${PDP8D}/pdp8_mt.c \
${PDP8D}/pdp8_pt.c ${PDP8D}/pdp8_rf.c ${PDP8D}/pdp8_rk.c \
${PDP8D}/pdp8_rx.c ${PDP8D}/pdp8_sys.c ${PDP8D}/pdp8_tt.c \
${PDP8D}/pdp8_ttx.c ${PDP8D}/pdp8_rl.c ${PDP8D}/pdp8_tsc.c \
${PDP8D}/pdp8_td.c ${PDP8D}/pdp8_ct.c ${PDP8D}/pdp8_fpp.c
PDP8_OPT = -I ${PDP8D}
 
ALTAIRD = ALTAIR
ALTAIR = ${ALTAIRD}/altair_sio.c ${ALTAIRD}/altair_cpu.c ${ALTAIRD}/altair_dsk.c \
${ALTAIRD}/altair_sys.c
ALTAIR_OPT = -I ${ALTAIRD}
 
ALTAIRZ80D = AltairZ80
ALTAIRZ80 = ${ALTAIRZ80D}/altairz80_cpu.c ${ALTAIRZ80D}/altairz80_cpu_nommu.c \
${ALTAIRZ80D}/altairz80_dsk.c ${ALTAIRZ80D}/disasm.c \
${ALTAIRZ80D}/altairz80_sio.c ${ALTAIRZ80D}/altairz80_sys.c \
${ALTAIRZ80D}/altairz80_hdsk.c ${ALTAIRZ80D}/altairz80_net.c \
${ALTAIRZ80D}/flashwriter2.c ${ALTAIRZ80D}/i86_decode.c \
${ALTAIRZ80D}/i86_ops.c ${ALTAIRZ80D}/i86_prim_ops.c \
${ALTAIRZ80D}/i8272.c ${ALTAIRZ80D}/insnsa.c ${ALTAIRZ80D}/insnsd.c \
${ALTAIRZ80D}/mfdc.c ${ALTAIRZ80D}/n8vem.c ${ALTAIRZ80D}/vfdhd.c \
${ALTAIRZ80D}/s100_disk1a.c ${ALTAIRZ80D}/s100_disk2.c ${ALTAIRZ80D}/s100_disk3.c\
${ALTAIRZ80D}/s100_fif.c ${ALTAIRZ80D}/s100_mdriveh.c \
${ALTAIRZ80D}/s100_mdsad.c ${ALTAIRZ80D}/s100_selchan.c \
${ALTAIRZ80D}/s100_ss1.c ${ALTAIRZ80D}/s100_64fdc.c \
${ALTAIRZ80D}/s100_scp300f.c ${ALTAIRZ80D}/sim_imd.c \
${ALTAIRZ80D}/wd179x.c ${ALTAIRZ80D}/s100_hdc1001.c \
${ALTAIRZ80D}/s100_if3.c ${ALTAIRZ80D}/s100_adcs6.c
ALTAIRZ80_OPT = -I ${ALTAIRZ80D}
 
ALL = pdp8 altair altairz80
 
all : ${ALL} 
 
pdp8 : ${PDP8} ${SIM}
$(CC) $(CFLAGS) ${SIMHFLAGS} ${PDP8} ${SIM} ${PDP8_OPT} -o $@ $(LDFLAGS)
 
altair : ${ALTAIR} ${SIM}
${CC} $(CFLAGS) ${SIMHFLAGS} ${ALTAIR} ${SIM} ${ALTAIR_OPT} -o $@ ${LDFLAGS}
 
altairz80 : ${ALTAIRZ80} ${SIM}
${CC} $(CFLAGS) ${SIMHFLAGS} ${ALTAIRZ80} ${SIM} ${ALTAIRZ80_OPT} -o $@ ${LDFLAGS}
 
# remove object files and executable when user executes "make clean"
clean:
rm *.o ${ALL}
 

 

7.  Use Make MenuConfig to select the OpenWRT packages.  The simh package will appear in the Utilities group if you used the Makefile from step 3.  Select to build simh as a Module.

8.  Use Make to rebuild.  All going well this will compile simh with the results in the build_dir/mipsel/SIMH folder in my environment.  Copy the pdp8, altair, altairz80 and any other simulators you have compiled and upload them to your OpenWRT powered router.

It worked well for me.  The DSL-502T is not particularly fast and is a bit limited in available storage but it happily runs OS8 on the PDP8, 4K and 8K Basic and AltDos on the Altair.  I haven't tried CP/M yet and need to free up some space or add some additional flash memory.

In the mean time... on to the blinking lights.  The DSL-502T does not have enough free GPIO pins to provide a display of a 12 or 16 bit address or data bus.  It does support I2C via the GPIO-i2c driver so I have ordered a couple of MCP23016 I2C port extenders to try.  Each chip can drive 16 LED's.... the trick will be to get enough blinking light effect without slowing the simulator.  I am sure the bit bashed I2C bus will be too slow to update with ever address change in the simulator.  Watch this space.

 

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
done

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.

 

Pump

 

(Pump)

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 http://www.qsl.net/zl1vkaprs/dsl502t.  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.
 
 

Programming the DSL-502T IGate using “Damn Small Linux”

Items you need to get started:
 
1.  The “Damn Small Linux” ISO from http://distro.ibiblio.org/pub/linux/distributions/damnsmall/current/current.iso burn to a CD (approx size 50mb).
2.  A PC able to boot the Damn Small Linux CD with a connection to the internet.
 
Follow the programming steps as follows:
1.  Boot the “Damn Small Linux” ISO.
 


 
2.  To program the DSL502T the PERL and CURL software in the “Damn Small Linux” image needs to be updated
Start the “MYDSL Browser”.
 

 
Download the “MYDSL” application database if prompted.
Use “Text Search” to locate the “Perl 5.8.0DSL” package.

Select the “Perl5.8.0DSL” package and “Install Selected” (approx size 8mb).

Use “Text Search” to locate the “CURL.tar.gz” package.
Select the “CURL.tar.gz” package and “Install Selected” (approx size 300kb).
Close the “MYDSL Browser”.
 
3. Download the latest DSL-502T firmware:
Press the “Term” button on the toolbar to open a terminal window.
Download and extract the firmware with the command:
 
curl http://www.quicktrip.co.nz/igate_dsl502t.tar.gz | tar xvz

On completion of the download you will have a “dsl502t” folder containing three files.
To program a DSL-502T with the downloaded firmware:
Change to the dsl502t folder
 
cd ./dsl502t
 
Ensure the DSL-502T is switched off.
Disconnect your PC from the internet connection and connect it the DSL-502T.
 
Ideally this should be done using a hub as most modern Ethernet cards take too long to power up if connected directly to the DSL-502T.
It is recommended that there be no other devices connected to the hub as other network traffic can interfere with the programming process.
 
4.  Set the IP address of “Damn Small Linux” to “192.168.1.3”.
 
Press the “Panel” button on the toolbar to open the “DSL Control Panel”.

 
Press the "NetCardConfig" button to open the network configuration dialog.
Enter the network configuration as follows:
 

Use DHCP Broadcast  No 
Address IP  192.168.1.3
Network Mask  255.255.255.0
Broadcast 192.168.1.255 
Gateway  192.168.1.254
Save Configuration  Yes
 


Press “Apply” to activate the configuration.
Close the “DSL Control Panel”.
 
5. Program the DSL-502T in the terminal window by:
 
Entering the command:
 
./flash
 
Power on the DSL-502T.
 
All going well the DSL-502T will be detected, the programming will be performed and the DSL-502T will reboot at the end of the process.
 
Possible problems are:
1. The DSL-502T is not found on the network and the programming fails.

Repeat step 5 to ensure the IP address is correctly configured as 192.168.1.3
Try using a different network cable or hub.
 
2. A device is recognised but it is reported as being the wrong type. This may occur if you have a Generation II (C5 Hardware revision) DSL-502T or a different device. You will not be able to program the device using this procedure.
3. The device is recognised and the programming starts but the dots stop. This can occur due to other network traffic or timing issues when transferring data to the DSL-502T.
 
Press Cltr-C to stop the programming script.
Repeat step 5 without powering off the DSL-502T.
 
 
 

Mangaging your FT-7800R memories.... with a VX5 bonus

I really like my FT-7800R, I found it to be a basic but reliable 2m rig with good wide band coverage... at least wide enough to cover the aircraft band.
 
What isn't so good is the effort required to manage the memories... particularly if you want to program more than a few frequencies.  If you are like me you probably have a limited set of frequencies programmed and everything else is done through the VFO as and when neaded.
 
After having the rig for a couple of years and feeling I really wasn't getting the best use out of it (particularly when scanning), it really was time to investigate programming software and the hardware required for an interface cable.
 
My software selection was based on the following criteria:
  • Not expensive
  • Positive comments on www.qrz.com
  • Quick review of the demo version suggested that it would do the job OK.
 
 
I also needed an interface cable.... something equivilent to the Yaesu CT-91.  
 
Some internet digging turned up a few designs but nothing that matched the junk box parts... the level conversion was easy... standard MAX232 design but additional interfacing was required to covert the two line TTL serial to one line to suit the FT-7800R.  I discovered this design for the Three to Two Wire Converter ... and I had a 4069 in the junk box so combined it with the MAX232 as shown.
 
Yaesu Programming Cable
 
.. and it works really well.  A recycled PS2 keyboard extender cable provided the connection for to the FT-7800R.  It worked first time.... 
 
For many years my VX5 had a similar managment problem with it's lack of memory management.... could the new interface work for the VX5 as well?  The internet suggested so but many times over the years I had looked at VX5 programmer schematics but always been put off by the difficulty in getting the 3.5mm plug with 4 connections.
 
These must have finally become popular for some consumer devices and they now (2010) appeared in the Jaycar catalog.  Replacing the interface PS2 connector with a 4 connection 3.5mm and testing using EVE on the VX5 worked well.
 
But the really big bonus is the relationship between FTB-7800 and KC8UNJ's free VX-5 Commander software..... FTB-7800 will export in VX-5 Commander format and if you can keep your FT-7800 definition within the VX-5 limits, especially limiting the number of memories to 220 and memory banks to 5 means you have have exactly the same memory configuration on the FT-7800 and VX5 with no extra work.
 
I can only say thank you to G4HFG and KC8UNJ for their software tie up... it really was an added bonus I didn't expect.
 
I don't have one of the more recent Yaesu radios such as the VX2, VX6 or VX7 but FTB-7800 supports exports for KC8UNJ's Commander software for each of these so you probably get the same benefits.
 

Building a DLink DSL-502T Based IGate - The TNC

In addition to configuring the DLink DSL-502T routers for the IGate project we also needed a TNC to connect between the radio and the serial port.

Our TNC selection was based on the following criteria:

  • The TNC board was to be installed inside the DSL-502T case
  • The DSL-502T serial port is used during the powerup sequence to display boot messages and will halt the boot process if it receives any characters so the ability to change the TNC code (or hardware) to not send or receive any data during the boot sequence was critical
  • Low cost
  • Accurate decoding
  • Monitor mode compatible with APRSD

We found the ATMega8 based TNC design from Henry Carl Ott (N2RVQ) which at first glance addressed the requirements and a prototype was built and tested.

In comparative testing of the N2RVQ reference design against an MFJ-1270C TNC using the WA8LMF APRS Test CD we found almost identical performance.  There were a small number of differences in the decode... sometimes the MFJ got packets the ATMega8 didn't and vice versa.

The source code for the ATMega8 TNC is very well written and was easily modified to handle the power on delay required for the DSL-502T boot process.

Long term performance testing of the ATMega8 TNC / DSL-502T / APRSD combination was performed with assistance for Ian ZL1AOX at his QTH overlooking Auckland.  The location of Ian's QTH provided excellent reception over the Auckland area and ensured plenty of traffic was gated through to the APRS-IS network.


After thirty days of continuous operation with no system errors or crashes we were happy enough with the design for Ian ZL1VFO to design a printed circuit board for the ATMega8 TNC that would fit into the DSL-502T case.

TNC Components

Because the DSL-502T would not be used as an ADSL router the telephone interface components were removed from the PCB providing space for the TNC to be mounted on the serial port pin header.

The next image shows the PCB before and after removing the telephone interface components.

DSL502T PCB Comparison

The final result with the TNC mounted on the serial port pin header is shown below.  +12V power for the TNC and available on the radio connector is provided by the red wire.  This connects to the DSL-502T PCB after the diode bridge rectifier and filtering capacitors. 

DSL502T and installed TNC

The current plan is to deploy many DSL-502T/TNC Igates around Auckland and the north Waikato to improve APRS-IS coverage.

 

Building OpenWRT for DSL502T Appliances - Removing Modules

When building OpenWRT Kamikaze 8.09.2 for the DSL502T there are a number of mobiles included by default that are important if you are using the device as a modem but unnecessary if you plan to use the device as an appliance.

After some playing I have found the following modules can be excluded:

Kernel Modules = kmod-sangam-atm-annex-a, kmod-ppp, kmod-pppoa, kmod-pppoe, kmod-ocx

In my configuration the difference in after boot memory usage is as follows:

Before

Mem: 10268K used, 2492K free, 0K shrd, 1300K buff, 4168K cached

Modules

Module                  Size  Used by    Not tainted
tiatm                 151008  0
acx                   136704  0
nf_nat_tftp             1088  0
nf_conntrack_tftp       3760  1 nf_nat_tftp
nf_nat_irc              1856  0
nf_conntrack_irc        4768  1 nf_nat_irc
nf_nat_ftp              2432  0
nf_conntrack_ftp        6880  1 nf_nat_ftp
ipt_MASQUERADE          2080  0
iptable_nat             4240  0
nf_nat                 14624  5 nf_nat_tftp,nf_nat_irc,nf_nat_ftp,ipt_MASQUERADE,iptable_nat
xt_state                1600  0
nf_conntrack_ipv4      12064  3 iptable_nat,nf_nat
nf_conntrack           46592  11 pppoatm                 4320  0
ipt_REJECT              2976  0
xt_TCPMSS               3136  0
ipt_LOG                 6720  0
xt_multiport            2528  0
xt_mac                  1312  0
xt_limit                2016  0
iptable_mangle          2080  0
iptable_filter          2080  0
ip_tables              10064  3 iptable_nat,iptable_mangle,iptable_filter
xt_tcpudp               2624  0
x_tables               11504  11 ppp_async              10944  0
ppp_generic            26080  2 pppoatm,ppp_async
slhc                    5952  1 ppp_generic
crc_ccitt               1440  1 ppp_async
br2684                  7920  0
atm                    48912  3 tiatm,pppoatm,br2684

After

Mem: 7628K used, 5132K free, 0K shrd, 964K buff, 3180K cached

Modules

Module                  Size  Used by    Not tainted
acx                   136704  0
gpio_dev                3184  0
br2684                  7920  0
atm                    48912  1 br2684

 

 

 

Ubuntu 8.1 - Network Configuration Change Script

Ubuntu 8.1 works really well as a build environment for OpenWRT and programming environment for the DSL502T. 

I have found that to make OpenWRT a network connection with Internet access is required but to program the DSL502T using adam2flash-502T.pl minimizing network traffic is important to prevent hangs during programming.

Also all the DSL502T units I have seen use 192.168.1.1 as the IP address for programming... but my internal network using 10.x.x.x network addresses.

So I needed a quick/easy way to switch between DHCP assignment of addresses for the internal network and STATIC assignment when programming.

Directly editing /etc/network/interfaces and restarting the network services works but gets old fairly quickly.... instead I wrote the following setnet script which is called passing DHCP or STATIC as the parameter.  It changes the network configuration and restarts the networking services.

#!/bin/sh

# Check if parameters are provided

if [ $# -ne 1 ]
then
    echo "Must specify STATIC or DHCP"
    exit 1
fi

INTERFACES="/etc/network/interfaces"
ETHMODE=`echo $1 | tr [:lower:] [:upper:]`

# Force both interface types to be off

sudo sed -i "s/#iface eth0 inet dhcp/iface eth0 inet dhcp/" $INTERFACES
sudo sed -i "s/#iface eth0 inet static/iface eth0 inet static/" $INTERFACES
sudo sed -i "s/iface eth0 inet dhcp/#iface eth0 inet dhcp/" $INTERFACES
sudo sed -i "s/iface eth0 inet static/#iface eth0 inet static/" $INTERFACES

# Now select the one that is required

if [ $ETHMODE = "STATIC" ]
then
    echo "setting STATIC"
    sudo sed -i "s/#iface eth0 inet static/iface eth0 inet static/" $INTERFACES
    sudo /etc/init.d/networking restart
elif [ $ETHMODE = "DHCP" ]
then
    echo "setting DHCP"
    sudo sed -i "s/#iface eth0 inet dhcp/iface eth0 inet dhcp/" $INTERFACES
    sudo /etc/init.d/networking restart
else
    echo "Unknown network mode"
fi
 

Probably no awards for great linux shell scripting but it works for me.

 

DSL502T + Ruby + Webrick + YAML = DIY Monitoring Appliance

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

So what does this have to do with DLink DSL502T routers, Ruby, Webrick and YAML?

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.  By querying every 5 minutes and storing the data in a MYSQL database 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 DSL502T's to provide Amateur Radio IGate services and had a build environment configured for the OpenWRT firmware.   Included in the OpenWRT packages is Ruby and I know I could easily write a ruby program with a web interface (using Webrick) and simple data storage (using YAML) so replace the original monitor board.

It took some playing but I was able to build OpenWRT with Ruby and the required modules for Webrick and YAML to operate with the following configuration:

make menuconfig

With the following options:

Target System = TI AR7 [2.6]
Target Profile = No WiFi
Target Images = squashfs

Base System = base-files, br2648ctl, busybox, dropbear, hotplug2, libgcc, libpthread, libstdcpp, mtd, opkg, uci, uclibc, udevtrigger

Network = atm-tools, wget
Library = (none)
IPv6 = (none)

Kernel Modules = kmod-ipt-core, kmod-ipt-nathelper, kmod-sangam-atm-annex-a, kmod-ppp, kmod-pppoa, kmod-pppoe, kmod-ocx

Utilities = gpioctl

Languages = ruby, ruby-core, ruby-erb, ruby-irb, ruby-openssl, ruby-webrick, ruby-yaml

The ruby-erb and ruby-openssl libraries are required in addition to ruby-webrick if you actually want webrick to work.  Not including these libraries will cause errors when you require 'webrick' in your ruby code.

I have not attempted a minimum size configuration here... it is highly likely when not used as a modem that modules such as kmod-pppoa, kmod-pppoe and kmod-sangam-atm-annex-a can be excluded.

It's not blindingly fast serving pages but as a stand alone monitoring appliance interfaced to data collection sensors via the onboard serial port and providing a simple web interface showing the current status and historical trends it does the job for me.

Another great use for $1 modems.  Time to buy a few more for the stockpile.

 


Page 8 of 11

Powered by Easytagcloud v2.1

Contact Andrew Quinn

jaquinn@ihug.co.nz http://twitter.com/jaquinn