cheap ethernet box to host owserver

[KLD]

My current 1-wire network hooks up on a DS9490R '1-wire to USB' bridge, which is hosted on a NSLU2 (a.k.a. slug). The latter is a very low energy consumption machine. I've put Debian/Gnu linux on it, and collect the 1-wire sensor data through owserver.
Now I like to expand the sensor network to include a counter chip on the 'leccy meter (many thanks to Eric!). Trouble is, there is no 1-wire cable near it. But, there is an lan ethernet connector nearby. So, my plan is to put a second 1-wire controller here, and connect the two owservers together via the lan. Alas, the going rate for slugs is £30 to £40 second hand.
OWserver is ported to OpenWRT, an open-source firmware for embedded systems like routers etc. I've got a cheap Netgear router DG834G v.2 off fleebay (£5), and spent ages flashing OpenWRT v10.03 onto it. This router sadly has got no USB port, and only an internal serial port header. A mobile phone data cable (e.g. Nokia DLR-3P) makes a suitable level shifter (phone and router both run an asymmetrical 0 to 3.3V port, the level shifter transforms this to +- 5V). This cable is also very useful to monitor the boot process of the router, since the serial port is the standard "console" of the device.
Up to this point I'm quite comfortable, and everything is working just fine.

The level shifter cable provides an interface that looks like a DCE (Data Communication Equipment, like a modem that is). So, instead of setting up DTR (data terminal ready) and RTS (ready to send) signals, it provides CD (carrier detect), DSR (data set ready), CTS (clear to send), and RI (ring indicator). And, when data is sent out of this port, it would appear on the RxD line (instead of the TxD line if it was sent by a PC for instance(acting as a DTE, data terminal equipment)).
This all becomes important when I try to connect a DS9097U '1-wire to RS-232' bridge to it. The bridge is a DCE itself, and thus wants to be talked to from a DTE. Before I read up on all this, I tried to simply connect the two female DE-9 plugs with a male-male gender changer.    So, now I made up something like a crossover gender changer. Tx/Rx become Rx/Tx, and DSR/CTS become DTR/RTS.  The latter is not critical (I hope), but the 9097U "steals" power of these two signal lines. DSR+CTS are indeed both at +6V on the cable, which should be good enough to power the 9097U.

Alas, owserver still cannot see the 9097U! 

Putting the 9097U onto the serial port on my PC (also running Debian) works OK.
The cable is tested when monitoring the console output.
Well, I'm a bit stuck here, anybody got an idea what to try next?

Klaus

[EccentricAnomaly]

I'd wonder if the level shifter is providing enough power.  Have you checked the voltages on the pins used to power the DS9097U while it's connected?  (You say +6V, but it's not clear if that's open circuit.)

Can you talk to the adapter at all through the serial port?

I just plugged one into my USB-to-serial adapter then in one terminal window ran:

Code:

raw-serial /dev/ttyUSB0
cat -v /dev/ttyUSB0

where raw-serial is my own script:

Code:

#!/bin/bash
PORT=${1:-/dev/ttyS0}
SPEED=${2:-9600}
stty -F $PORT $SPEED raw pass8 -cstopb -crtscts clocal -echo

and -v tells cat to turn control characters into something printable.

Then in another window:

Code:

echo blah > /dev/ttyUSB0

and got a few funny characters back.

Can you telnet/ssh into OpenWRT twice to get two terminal prompts?

[KLD]

EA,

Thanks again for your input! I've used that quick test before, when I eventually found out how serial headers on a motherboard and their matching "10-pin idc to DE-9 adaptor" don't always quite follow the same conventions 

A quick re-test on that same miniITX motherboard, shortening TxD and RxD, produces the expected result (echo shows in 'listening' terminal.) Repeat with the shortening jumper replaced by a DS9097U: no echo. So, I can't directly reproduce what you got?!

Repeat on the OpenWRT board: no echo whatsoever, whatever I do. I can still see the console output, but I can't receive anything on the RxD pin. This is new, 'cause when I started I had a proper two-way console. It unlikely to be having anything to do with any software setting, since even the bootloader is no longer accessible. I guess I've bust the Rx side of the port. Bugg er.

The Netgear board has a TI AR7 processor, with internal UART. http://wiki.openwrt.org/oldwiki/openwrtdocs/hardware/netgear/dg834g It runs on 3.3V, and the serial port operates on 3.3V TTL signals. The mobile phone level-shifter cable contains (most likely) a MAX3232 line driver, which uses the 3.3V power supply from the Netgear router, and converts 0 to 3.3V TTL into +-5V RS-232 signals.
Experimentally I stuck a 7805 voltage regulator onto the 9097U one-wire controller, supplying 12V from the router power supply. I can only guess that this 5V got back onto the Rx pin of the routers serial header, and bang.  Is there any way of how to test that hypothesis? I've excluded a fault in the level shifter cable (by using three different cables). 

It's amazing how any hours one can spend fiddling with Minicom, stty, flashing and r-flashing firmware, etc    Well, at least I've learnt a lot about this now nearly obsolete interface. 

Klaus

[EccentricAnomaly]

A quick re-test on that same miniITX motherboard, shortening TxD and RxD, produces the expected result (echo shows in 'listening' terminal.) Repeat with the shortening jumper replaced by a DS9097U: no echo. So, I can't directly reproduce what you got?!

Just in case of misunderstanding: the 9097U doesn't echo; I've no idea what "blah\n" means in its language and just hope it doesn't mean erase the EPROM and never work again :-).  I forget what the bytes which came back were but they looked binary rather than printable ASCII.

Repeat on the OpenWRT board: no echo whatsoever, whatever I do. I can still see the console output, but I can't receive anything on the RxD pin. This is new, 'cause when I started I had a proper two-way console. It unlikely to be having anything to do with any software setting, since even the bootloader is no longer accessible. I guess I've bust the Rx side of the port. Bugg er.

Yep, not looking very hopeful.

The Netgear board has a TI AR7 processor, with internal UART. http://wiki.openwrt.org/oldwiki/openwrtdocs/hardware/netgear/dg834g It runs on 3.3V, and the serial port operates on 3.3V TTL signals. The mobile phone level-shifter cable contains (most likely) a MAX3232 line driver, which uses the 3.3V power supply from the Netgear router, and converts 0 to 3.3V TTL into +-5V RS-232 signals.

Note 1: TTL is normally 0 to 5V.  3.3 V is some new-fangled thing whereas TTL was around when I were a lad.

Note 2: RS-232 is not +/- 5 V.  As I recall (my copy of the standard's packed in a box somewhere at the moment) it's at most +/- 3 V on the receive end, at least +/- 6 V on the transmit end (to allow a 3 V noise margin on the line) with a maximum of, I think, +/- 25 V at the transmit end.  Typically ports put out 6 to 12 volts, e.g., TxD on my USB to serial adapter shows -6.56 V.

Experimentally I stuck a 7805 voltage regulator onto the 9097U one-wire controller, supplying 12V from the router power supply.

Actually, the 9097U should be quite happy with the original 12 V, as noted above.

I can only guess that this 5V got back onto the Rx pin of the routers serial header, and bang.  Is there any way of how to test that hypothesis? I've excluded a fault in the level shifter cable (by using three different cables). 

My first suggestion would be the loop-back test you've already done which seems pretty conclusive, really, given you know the output is still working.

It's amazing how any hours one can spend fiddling with Minicom, stty, flashing and r-flashing firmware, etc    Well, at least I've learnt a lot about this now nearly obsolete interface.

I know what you mean.  Personally, I'm reluctant to spend much time on learning stuff which won't have at least a couple of year's life.  E.g., I have a "bricked" D-Link router (upgrade failed when I made the wrong guess in their very ambiguous instructions) which it seems a shame to just throw away but on the other hand...

[KLD]

So, after several weeks of hiding the box in a dark corner, I thought I have another go.
The first incarnation was a Netgear router DG834G v2, which I've had for many years and it's a reliable box. Thanks to EA I eventually found that I fried the Receive side of its serial port. Harumph. OK, the stock Netgear firmware is back on it, and it chucks happily away as my router/ ADSL modem.

Before I started all this putting a new firmware onto a router and running owserver on it, I actually bought a second router, same type, but hardware version 3. According to the OpenWRT page, v3 is much more difficult to upgrade. Netgear changed the bootloader, and the new one can't be interrupted as easily to flash new firmware on. With a major bit of faffing --- finding and installing a better bootloader, bricking the unit, de-bricking via JTAG --- I finally ended up with a router that can be flashed via FTP, and an OpenWRT cross-compile environment to build the firmware.

Per default the serial port is used as the standard console. Eventually I found how to disable this standard feature and thus silence the port.

Now, EA's standard loop-back test works fine. With two terminal sessions open, one listens to the serial port

Code:

cat /dev/ttyS0

, while in the second terminal I send characters to it:

Code:

echo 123 > /dev/ttyS0

. The "123" appear in term1.

One step further, and I tried connecting two systems via a serial link. So, on my desktop (Debian GNU/Linux) I open a terminal and do the "echo 123 > /dev/ttyS0", while in telnet term1 I listen to the port on the router. It works.

The reverse order of this experiment is where things start falling apart. So, I send "1234567890" from the router to the desktop. When both ports are set to 9600 baud (this is the speed I need for the DS9097U), I find that what is received is

Code:

klaus@desktop:~$ stty -F /dev/ttyS0 9600
klaus@desktop:~$ cat /dev/ttyS0
223567890
224557890
224557890
224567890

Strangely, when I set both ports to 115200 baud, I get the correct function:

Code:

klaus@desktop:~$ stty -F /dev/ttyS0 115200
klaus@desktop:~$ cat /dev/ttyS0
12345678901234567890
1234567890
1234567890
1234567890

Why there sometimes is a linebreak and other times not, I don't know either.
As it should be, when I set the speeds differently on the two ends, say 9600 baud on the desktop, and 115200 baud on the router, I get no transmission.

Owserver uses 9600 baud when it tries to connect to a DS9097U serial-to-1wire bridge. The openwrt version of owserver doesn't have the --baud switch.
Starting owserver seems to find the DS9097U ("seems" because only errors are reported, and there isn't one. When I unplug the 9097, I get a "not found" type error.), but I can't talk to the sensors with owdir or owread.

Well, here is the problem then: When I set the serial port speed on the router with "stty -F <device> 9600" it seems to do as expected, but transmission is garbled. After "stty -F <device> 115200", transmission is fine. Using owserver, for which the man pages state it uses 9600 baud when connecting to a 9097U, I don't get an error, but the 1-wire commands don't produce any output.

Is there anywhere in the kernel configuration (?) where the serial port default speed value is set? Any other hypothesis?

Klaus

[Countrypaul]

Klaus, not sure how relevant this may be, but have you checked that the  other parameters for the serial lines are set equally? Things such as number of stop bits, parity etc.

I also remember that the timing on different manufacturers for serial comms were never quite the same. Whilst one might be 114,800 for a nominal 115,000 baud line another would be 115,256 for example. In most cases this poses no problem but can occasionally cause lack of communications. As the baud rate drops, the difference in speeds reduces so at 9600 there would be little or no noticable difference.

Paul

[EccentricAnomaly]

I'm a bit worried that you are connecting an RS-232 serial port on your computer, via a USB-to-serial adapter or directly - typically on a 9-pin sub-min D connector, to a TTL serial port on your router. If that's what you are doing then I'd recommend stopping before you blow something up. I might be wrong and the router might have RS232 signal levels on its serial port but that would be a bit unusual, I think. Anyway, it'd be helpful if you'd clarify exactly what you are doing.

[KLD]

Paul,
All other parameters (that I know off) are controlled and set the same one both ends. Here is the router side

Code:

root@OpenWrt:/# stty -aF /dev/ttyS0
speed 9600 baud; rows 24; columns 80;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

EA, the connection between the CMOS level port on the router (0 to +3.3V) and the RS232 port on the desktop is via a MAX232 level shifter and line driver. Having fried one port on the version 2 router, I promise to be careful 

Klaus

[EccentricAnomaly]

Ah, OK, good.

The information around is pretty confused though.  E.g., this post, the first in a Google search for "DG834 serial port":

https://forum.openwrt.org/viewtopic.php?id=2221

says it's an RS422 port yet RS422 uses differential signalling and the pin outs given are clearly not differential.  This post:

http://wiki.openwrt.org/toh/netgear/dg834gt

seems to confirm the pin outs.

Still, I think it might well be a voltage issue causing a few bits to get flipped along the way.  Perhaps the earth reference isn't right so if the line stays persistently in one particular state the reference floats down so it works at high baud rates but fails at lower baud rates when there are long enough sequences of zero bits, or something.

[KLD]

The naming for these devices is very confusing. Many of Netgear's boxes look the same, but the internals are quite different. DG834GT is not the same as DG834G, etc. And as you've just found out again, the available information is of varying quality as well. So, my box is version 3 of this here: http://wiki.openwrt.org/oldwiki/openwrtdocs/hardware/netgear/dg834g The one good thing relative to version 2 is that now there is a JTAG header, which made it possible to replace the stock adam2 bootloader with a more hacker friendly version, PSPBoot1.4 (download-able from a rather "interesting" russian source.)

Flashing a stock OpenWRT firmware image (Kamikaze 8.09.2) works well, and yields a fully functional router.
Before building my own binary image (with owserver, owshell, stty, setserial, built-in), I de-selected the serial console option in the kernel config. After flashing the image, I also commented out the line in /etc/inittab about ttyS0:

Code:

root@OpenWrt:/# cat /etc/inittab
::sysinit:/etc/init.d/rcS S boot
::shutdown:/etc/init.d/rcS K stop
tts/0::askfirst:/bin/ash --login
::ttyS0::askfirst:/bin/ash --login
tty1::askfirst:/bin/ash --login

Hmm, the voltage levels. The MAX232 produces +10V and -10V, and Tx, Rx, and GND are all connected to the RS232 port on the desktop.  
Any pointer how I could test your hypothesis? (sorry, haven't got a 'scope   )

Klaus

[KLD]

And I've just repeated the experiment with a different level shifter / line driver, a mobile phone cable Nokia DLR-3P (which contains a MAX3232 chip). Same result, 115200baud work well, 9600baud garbles the output.

K

[KLD]

EA,

In order to test your "too many zero bits drag the voltage level down" hypothesis, I created a file of 6000 characters long (that is all there was room for on the router's memory).

Experiment 1)
fill the file with <space> characters. Their binary code is 00100000. Put a "1" at the end. Send. Result: 9600baud, lots of spaces, then 11 at the end. At 115200, lots of spaces, then a single 1.

Experiment 2)
fill the file with "~" characters. Their binary code is 01111110. Put a "1" at the end. Send. Result: 9600baud, lots of ~, then a single "1" at the end. At 115200, lots of spaces, then a nothing.

I don't know exactly what we learn from this, but it looks like there is a problem here.

Klaus

[EccentricAnomaly]

MAX3232

Good, I was about to ask about that.  It's been a few years since I've played with MAX232s so I wondered how they'd cope with 3.3 V inputs.

Your experiment 2 seems to gable at 115200 baud but works OK at 9600 which is contrary to what you said before.

[KLD]

Yes, the difference is that now a lot of high bits are sent first, before the "information".

[wookey]

You seem to be past this stage, but one thing to be aware of is that ARm serial ports are generally flow-control free. i.e they are 3-pin serial ports (gnd/Tx/Rx) with no RTS/CTS. This makes them easier to wire as you you only have 3 wires to get right, but it does mean that you can have syncronisation issues. However at 9600 baud that really shouldn't be a problem unless something is keeping your hardware very busy.

It's a good idea for this sort of work to explicitly set all the serial port paramaters, not just speed. So use stty to suck out the config on the working port (stty --save < /dev/ttyS0 > portconfig) and then program it back with stty -F /dev/ttyS0 < portconfig   (or something like that). I have found uninitialised ports to cause pain and suffering in the past.

What happens if you flash a kernel with the serial console re-enabled (and the getty in inittab turned back on). Does serial console access work reliably there? Can you use sz to send a file? (checksummed and thus a useful test)

I'm not really sure what's amiss here. It could be port setup. It could be flow-control (maybe there is some on your board and it's not being used - I'd be suprised though). It could be not enough volts.

Is your test with dodgy data entirely deterministic? i.e it always goes wrong the same way for given data? Or is it just 'unreliable'? That could be a clue.

Oh don't we all love serial ports. (There was actually golden period in serial ports after the 25pin D went away but every machine had one and before we had to worry about TTL levels and 3V ports making things complicated again).

Another little wrinkle is that 'high' bits are normaly sent as 0V and low as +V (IIRC), so thinking about 'too many zeros dragging the voltage down' is probably backwards.