Relay card 8fa +Power-Manager
I've made software for managing of the 8fa relay
card (approx. 40 Euro), from www.conrad.de with posix commands via
a serial port:
relais.c
README (german)
Tested with Linux, should work with every posix conforming
operating system and Cygwin.
The 8 relays can be used up to 250 V AC, 5 A.
For switching higher voltages, e. g. 400 V, you must use a relay which is specified for higher
voltages.
It's important that the maximum current of the relay should not be exceeded and that capacitive
loads like switching power supplys, e. g. in PCs, have a high inrush current of about 100 A and
i have measured up to 200 A.
An example is the 850 W
EPS12
PSU
PSL-6850P
with an inrush current of max. 150 A at 230 V.
An automatic circuit breaker or fuse does not limitate the inrush
current,
because the inrush current of a capacitive load is a short puls of several mikro- to milliseconds,
where the threshold current of a common 16 A automatic circuit breaker or fuse is about 500 A.
So for switching capacitive loads like PCs you have to use an inrush
current limitation like an NTC, an inrush current reduction like a zero-crossing-switch, e. g.
CRYDOM A2410, or a relay which is specified for at minimum 100 A, like the CT multi 9 15977 from
Schneider Electric.
Otherwise the relay is overloded and has a short lifetime. The lifetime
is usually around 200,000 make-and-break cycles when it is not overloaded.
The pictures below do show the 8fa in a Power-Manager (also from www.conrad.de, approx. 40 Euro), with an integrated line filter.
I installed the 8fa with a serial port plug socket which is isolated
from the chassis, because the 8fa ground is connected with a (560 Ohm) resistor
to the protective earth conductor to avoid both floating and a high ripple
current (from the ground loop):
Building this relay box takes about one hour and less than 100 Euro.
The 8fa relay card can also be powered from the Firewire bus, instead from
an AC adapter.
Update July 2007
I found the bug that using the program (relais) only with the -s or -r parameter did not
work correct and eleminated that bug.
Because the 8fa has no power LED i added one with an integrated series resistor
(for 5 V):
For viewing the power LED and the status LEDs i added a (quick and dirty) window, made of two
self-adhesive transparent foils which are glued together:
For anti-interference and electrical safety i marked the two power wires at the connecter plug so
that the wire with the phase (P) is switched by the relays and the neutral line (N)
is not switched:
For using this feature, you have to measure where the phase and where the neutral line is in
the plug socket, or you have to use a plug socket where the position of the
phase and the neutral line is defined.
An example is a CEE2 (IEC 60309 P+N+PE, 6h) plug:
The picture above is from a CEE 16 A P+N+E 230 V socket with the standard conform position of the neutral line (N), Phase one
(L1) and grounding wire (PE); picture from wikipedia.
This is also relevant for HiFi applications and a german howto for finding and marking the phase can be found here:
http://www.audiotronic-service.de/faq/phaseindex.html.
For discharging of the devices at the AC outputs, e. g. devices with an
anti-interference capacitor or an EMI filter without a discharge resistor,
i added a (2.7 MOhm) discharge resistor from the N wire to the protective earth conductor:
and also a discharge resistor (2.7 MOhm) from each P output to the protective earth conductor:
This ensures a discharging of every wire of the devices at the AC output
to the protective earth conductor when N and P are connected correct and the relay
or associated switch is switched off.
A typical application of such a relay card is powercycling a network device such as a Router, DSL
Modem, PC, etc. which will hang every now and then.
An example are DSL routers which do hang instantly when they try to resolve
ULRs longer than 50 bytes; e. g. from ebay:
http://www.tecchannel.de/netzwerk/extra/402395/.
Another example from 2005, with a very simple relay card, can be found here (in german):
http://www.schlager.bz/projekte/powerplug/
Powercycling the DSL modem also helps against many DSLAM bugs and against
a modem hangup because of many connections, e. g. caused by a Weberver like
Apache or an Onion Router like Tor; this can be found in the Tor documentation
(
https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#Mycablemodemkeepscrashing.What.27sgoingon.3F
)
and i have seen this problem with some DSL modems (which are often router in
bridging mode), although i'm using my Tor server only with a low bandwidth (options BandwidthRate 90 KB,
BandwidthBurst 95 KB, and MaxAdvertisedBandwidth 85 KB).
Because sometimes the cause of the hanging is in the OS or a driver, the software which
manages the modem must also have a software watchdog for a reboot.
A typical example is a hanging smpppd-ifcfg with a zombie child:
(list all Zombies)
> ps ax -o s,pid,comm,ppid | grep '^Z'
Z 22541 getcf <defunct> 22540
(list the parent process by searching for it's PID)
> ps ax -o pid,s,comm | grep 22540
22540 S smpppd-ifcfg
Via top i can see that there is a zombie and i can kill it's parent manually,
but i'm not always checking my server for zombies and automated killing of parents
from zombies is not a good idea because that crashes e. g. KDE4
in a short time (i see around 18 zombies when KDE4 is running because
ksmserver creates zombie processes), so i'm using the script (which now also kills
smpppd-ifcfg)
checkdsl.sh together with this
/etc/inittab line:
12:2345:respawn:/root/bin/checkdsl >> /var/log/checkdsl 2>&1
and some lines in /etc/crontab like this:
-7 0 * * * root /root/bin/stopdsl.sh
-7 12 * * * root /root/bin/stopdsl.sh
with the scripts stopdsl.sh,
modemon.sh, modemoff.sh and
modem_powercycle.sh.
The first script checkdsl.sh does a modem power cycle after every 5
consecutively unsuccessful dial-up tries and a reboot after 31 consecutively unsuccessful dial-up
tries. With this configuration and a medium quality DSL connection
in 2007 i could see that the checkdsl.sh
does about two modem powercycles per week and a reboot after about 50 days
uptime with an Sphairon AR871.
If you want to rotate the logfile (/var/log/checkdsl) via logrotate, you must
use the option copytruncate (in /etc/logrotate.d/checkdsl).
An alternative is to use
rotatelogs, a piped logging program.
By default, after power up, the relays of the 8fa and most other relay cards
are off. This can be changed by replacing the monostable on-off switching relay
by a monostable commutating relay and using the deault-on output. But this
inverts the output behavior and the driver has to be adjusted.
A description of some other relay cards can be found here: http://www.bksoft.de/licht24pro.htm
Update January 2008
An alternative is using a remote controllable multiple socket outlet
via ethernet, because at the beginning of 2008 they do cost only about 120 Euro:
MS SDL PM211MIP :: Infratec Master/Slave Steckdosenleiste IP
At the vendor itself the PM 211-MIP
does cost 145 Euro:
http://www.infratec-ag.de/index.php?option=com_wrapper&Itemid=341&lang=en
At reichelt.de you can also find a dimmable socket outlet with an ethernet
interface, the ALLNET ALL3076 (99 Euro).
Multiple socket outlet with Ethernet, Webserver, ssh Server etc., which also do
monitor and/or log the current/power consumption and AC voltage are available
from vendors like Raritan, Rittal and Infratec, e. g. at the (german) e-tailer
Fröhlich +Walter:http://www.f-u-w.de/de/storefront.aspx?katalogID=236&kido=231.
You can see the prices via "Demozugang".
2014: The NETIO4 is availible in versions with WiFi, Bluetooth, LAN etc. for about 100 Euro, also at reichelt.de
and many other stores.
Later Updates
February 2008: With my USB-RS232 adapter (USB to Serial Adapter) with an Pl2303
chip (driver pl2303) i've got the problem
that this adapter does nothing after somes hours and a user (Stephan R.)
reported defect checksums and lost bytes with such an adapter while
communication with the 8fa works without problems over an onboard serial port.
I'm using an USB to Serial Adapter with an FTDI chip (driver ftdi_sio, chip
FT232BM and similar from FTDI) without problems. An example is the
DIGITUS USB to serial adaptor/converter, which costs about
7 Euro.
You can see what's inside an USB converter e. g. via the dmesg command (from root) under Linux.
March 2008: Because of the bad connection with dozens disconnects per day, i switched from doing
deterministic DSL reconnections via crontab to disconnects via a countdown in the checksl
skript. The countdown gets resetted by every new connection.
Via Telnet i can see that the FritzBox often hangs with a load greater than 10;
it seems the firmware has a build-in fork bomb. Changing the firmware nor the
DSL options could help. I also tried additional line filters, a shielding
case made of iron (magnetic shielding) and cooling by an fan but that did
not help.
Switching from the
FritzBox 7170 to the 7270 also did not help.
On my main client PC i'm using a skript which detects the disconnects
and shows a parallel countdown on this PC. Now the disconnects from my router
do vary, but i can see when it will do the next planned disconnect.
February 2009: Since november of last year i'm monitoring my FritzBox 7270 via
"ping -c 15 -s 24 -W 10 -w 50 -Q 0x02 -l 1 192.168.178.1 -q" and mrtg.
I'm using the FritzBox only as a modem, with deactivated WLAN and no telephone.
Because the connection to the FritzBox is only a 2 meter
patch cable and ethtool shows that the connection is always 100baseT/Full,
the average round trip time (avg RTT) should be about 2 ms and the packet loss
should be much less than 0.1 %.
But the measured avg RTT is 24 ms and the average packet loss is 4 %, so both
are very bad!
The daily log shows that the RTT and packet loss increases with the load of the
FritzBox, till the internal watchdog or the poweroff resets the Fritzbox and
this happens nearly every hour:
X-axis: Time (hour), blue: RTT (5 minute average in ms), green: Packet loss (%).
The RTT is limited via the monitoring script to 100. By pinging manually i
could see RTTs of several seconds!
The AVM support could not help and updating the firmware,
extra cooling with a fan, shielding with an grounded iron case and variation of the
options (increasing/decreasing powercutback, limit for up-/download etc.) also did
not help.
Switching back to the good old Sphairon AR871 at the end of week 6 changed the measured avg RTT to
1 ms and the average packet loss to less than 0.1 %:
X-axis: Time (week), blue: RTT (2 hour average in ms), green: Packet loss (%).
The AR871 also changed the avg RTT to the DSLAM from 120 to 100, the
average packet loss to the DSLAM from 23 % to less than 1 % and it increased
the average throughput by 15 % (mainly caused by much less hangups and disconnects).
And the AR871 needs a reset about once a day, not once an hour!
So the Sphairon ADSL2+ router are much better than the AVM router.
March 2009: In the updated script (checkdsl.sh) i added a killing of the pppd via signal 9 for
defined termination and this reduced the number of powercycles per week by more
than 90 %! This does affect neighter the ping time nor the packet loss to the
modem.
2009-03-22: Since the last day i could see a mysterious increase of the packet
loss to the router (AR871) and the DSLAM from less than 1 to about 20 %, but the
RTT to the router was always around the common 1 ms.
ethtool did show normal behaviour of the network card to the router but
ifconfig did show hardware errors:
> ifconfig eth1 | grep errors
RX packets:583380 errors:16 dropped:0 overruns:0 frame:16
TX packets:716131 errors:13040 dropped:0 overruns:0 carrier:13040
Powercycling the router and rebooting the PC did not changed the error rate, but
exchanging the router did solved the problem; the router simply got defect.
Therefore i made this script (last updated 2009-11-11):
#!/bin/bash
# eth_errors.sh: Check the interface $1 (first argument, e. g. eth0) for
# errors: Send an email when RX and TX errors are present,
# send an email when the interface has less than 100 Mbit/s,
# send an email when the interface is half-duplex.
# Version 1.1, Dr. Rolf Freitag, 2009
#set -x
INTERFACE=$1
# Check for RX and TX errors
typeset -i linecount=$(ifconfig $INTERFACE | grep "errors:0" | wc -l)
if [ $linecount -lt 1 ]
then
echo "Interface $INTERFACE has RX and TX errors (NIC or Peer is defekt)."
ifconfig $INTERFACE 2>&1 | mail -s "Interface $INTERFACE has RX and TX errors (NIC or Peer is defekt)." root@localhost
else
if [ $linecount -eq 1 ]
then
echo "Interface $INTERFACE has either RX or TX errors."
else # linecount is 2 (or greater)
echo "Interface $INTERFACE has no errors."
fi
fi
# Check for 100 Mbit/s or more speed
linecount=$(ethtool $INTERFACE | grep "Speed: 100" | wc -l)
if [ $linecount -lt 1 ]
then
echo "Interface $INTERFACE has less than 100 Mbit/s speed."
ethtool $INTERFACE 2>&1 | mail -s "Interface $INTERFACE has less than 100 Mbit/s speed." root@localhost
else
if [ $linecount -eq 1 ]
then
echo "Interface $INTERFACE has 100 Mbit/s or more speed."
else # linecount is 2 (or greater)
echo "Unknown error 1."
fi
fi
# Check for if the device is not half-duplex
linecount=$(ethtool $INTERFACE | grep "Duplex: Half" | wc -l)
if [ $linecount -lt 1 ]
then
echo "Interface $INTERFACE has full-duplex."
else
if [ $linecount -eq 1 ]
then
echo "Interface $INTERFACE has only half-duplex."
ethtool $INTERFACE 2>&1 | mail -s "Interface $INTERFACE has only half-duplex." root@localhost
else # linecount is 2 (or greater)
echo "Unknown error 2."
fi
fi
and added the following lines in /etc/crontab to get an email when a peer gets defect.
-*/25 * * * * root /bin/bash /root/bin/eth_errors.sh eth0
-*/26 * * * * root /bin/bash /root/bin/eth_errors.sh eth1
Because in many forums many other people also do report that their ADSL2+
modem/router died after about 2 years, it seems that many of them have a
lifetime limitation, e. g. by drying electrolytic capacitors with the
internal heat production and bad cooling. Therefore i will use my future
modems/router with additional cooling.
December 2009: Adding toroids, with Al = 43µH, to all cables to the
router did improve
the ADSL2+ connection only slightly. But i found a simple way to test
ADSL2+ router (now Turbolink 1203):
ping -l 32 -p 0f1e2d3c4b5a6978 -f 192.168.1.1
This shows a packet loss of 0 % without ADSL2+ traffic and about 4 % with
traffic of 1 Mbit/s up and down.
Anoter point is the bandwidth caused by this pinging: This pinging shows only
about 500 kB/s while PCs (also at 100 Mbit/s connection) show about 16 times
more.
The last point is the RTT time at pinging without the -f option:
It's 1.5 ms while it's only 0.065 to another PC.
March 2010:
After 6 years i changed the server from a Supermicro P3TDLE with two P
III S 1.266 GHz with SuSE 10.2 to a Supermicro X8SAX with one Core
i7 940 and Debian Lenny an a half. Now the RTT to the modem is always
one ms and the packet loss is zero, but the connection to the
DSLAM did not changed significant. The actual DSL checking script
can be found
here
and the old one
here.
In these scripts i'm using
this
MAC changer script to avoid leaking a real MAC via the DSL modem.
Beside the information from the modem/router the pppd output is a
good source of information about the connection. You can see the pppd
output via
tail -n 1234 -f /var/log/messages | grep pppd
or
cat /var/log/messages | grep pppd | less
A Similar project for the GEMBIRD (m)SiS-PM device family under Linux
can be found at
http://sispmctl.sourceforge.net/.
August 2011:
I switched to a cable modem and now the modem poweroff/poweron plus a
MAC change is necessary for getting a new IP every day. So even
with a stable modem it makes sense to use the modem with a relay card.
I found a site about using the 8f via a CGI
script, so that the relays can be switched via a web interface
(website):
http://www.netzmafia.de/skripten/perl/perl7.html.
May 2015:
If you only need to reset a device, e. g. a modem or computer, you can use a cheap used
APC UPS, e. g. a Back-UPS CS 650 for 10 Euro from Ebay.
The system shutdown test, which can be made with apctest (point "1) Test kill UPS power") or
touch /etc/apcupsd/powerfail; apcupsd --killpower
This sets the UPS to offline mode for a minute and at the end of this minute the output is
switched of for five seconds.
The smart APC USPses have more options, e. g. can set a longer poweroff time, but are more expensive.
The Apcupsd manual says: "If you have a SmartUPS, there are depending on the UPS at least 12 different
values stored in the EEPROM that determine how the UPS reacts to various conditions such as
high line voltage, low line voltage, power down grace periods, etc."
These values can be configured with apctest, point 5) Program EEPROM.
Before you should terminate a running apcupsd (/etc/init.d/apcupsd stop).
Sitemap