Problem:  I, along with several other families, live at the end of a 1/2-mile 1-lane driveway that is very curvy and heavily forrested so you don't know if someone else is coming the other way until they are right on top of you.  When two cars meet each other, it's a real pain since one of the cars has to back up quite a bit to one of the two turnouts or back to the very beginning to let the other car pass.

Solution:  Have two WRT's connected to each other wirelessly (probably with antennas) on either end of the driveway and have each control a little light that would be mounted by a sign on a tree that says "Traffic Coming".  If that light is on as you approach, just wait for the car that's already on the driveway to exit before getting on yourself.

Method:  I need one input (I guess the reset button) and one output (/proc/sys/diag) with the proper circuitry to interface to the outside world.  I plan to use break-beam sensors to sense the cars and relays to control the lights.  Power to the wrt's isn't a problem.

So, I've got most of the programming concepts down but I'm stumped at how to get the two wrt's to communicate with each other.  I need a way to simply pass an alert from one wrt to the other that the sensor was tripped.  Once the alert gets to the other wrt, it will keep /proc/sys/diag high until it senses the car pass on its side.  Can anyone think of any way to accomplish this passing of the alert?

One idea I had was to simply do a continuous loop that would wget a file from the other wrt.  Normally, the file wouldn't be there so the wget command wouldn't be successful but, should the other WRT indeed sense a car, it would "touch" a file on its end which would then be picked up by the other wrt with a successful wget.  The file in the source wrt would be deleted seconds later automatically.  Two problems - 1) I don't think I should use files for communication since the flash chip will wear out over time, 2) Seems like a lame way to communicate.

Any pointers regarding any of this would be helpful.  In case it's useful (and I'm successful) I'll post back here the source and the schematics in case anybody wants to do anything similar.

That is a cool idea.
I guess those things are called traffic lights ;-)

I once read an interesting article about inetd or xinetd, that could be used to write a daemon that is listening on a socket with a few lines of a (b)ash script. I can not remember where...
Thus you could implement your own small protocoll in an easy way.

(Last edited by cornelinux on 22 Aug 2005, 00:01)

How about this for a dirty hacked solution:

Use a wl-500g instead (has parallel port, so its easier to configure - dont need to worry about modding hardware to add serial ports).  Use the parallel port essentially as digital I/O.  ie binary input on one pin corresponds to the switch, output is to a driver for the light (solid state relay would be easiest).

Setup samba server on one and use client on other (im not sure this can be done, but i guess so).  Have a single file (or two might be better) showing the state of each end.  Then need to run a script constantly that loops and does the checking.

If the road is windy etc - are you sure youll get good signals at each end?

And how are you going to tell the diff when the break-beam is interrupted by a car or something else, like a leave?

Well, the usual approach for this is to have two break-beams at either side with a reasonable distance (let's say 1.5 m) and to trigger the "car is approaching" only if both break-beams are interrupted simultaniously for at least some msec. The idea is to detect objects that are "large enough".
By analyzing the order of interruptions you may get furhter evidence and also distinguish between "car entering" and "car leaving".

Daniel

maybe your display should also timestamp the entering cars and display them all, then timeout...

daniel is right, you need several inputs.

I think there are GPIO pins inside the wrts which you might use.

I've got the multiple break-beam sensor thing down ok.  I'll use a simple "and" gate for that.  What I do need help with nobody has been able to address:  How can one WRT send an alert wirlessly to another WRT?  I'd prefer not to send files since that uses the flash chip which has a finite write life.

Put something like this on each wrt and call it /www/set_car:

#!/bin/ash
nvram set car_coming=1
echo "1";

and likewise /www/set_nocar:

#!/bin/ash
nvram set car_coming=0
echo "0";

and, /www/get_car:

#!/bin/ash
echo "`nvram get car_coming`";

(these are just proof of concept and might require modification to do anything useful)

then,

chmod a+x /www/*car

then, assuming wrt ip addresses are 192.168.1.x, you could:

wget http://192.168.1.x/set_car

or

wget http://192.168.1.x/set_nocar

or

if [ "`wget http://192.168.1.x/get_car -q -O -`" = "1" ]
then
  echo "car_coming on remote wrt is 1";
else
  echo "car_coming on remote wrt is not 1";
fi

so a wrt, when triggered by a sensor, would check with the other wrt by calling the get_car script as above.  if it decided there was already a car in the run, this trigger must be telling us a car is leaving, so call the set_nocar script on both routers.  If it decided there was NOT already a car in the run, this trigger must be telling us a car is entering, so call the set_car script on both routers.  You don't need to use wget to control the local router, just do a '/www/set_car' or a '/www/set_nocar' or even a 'nvram set car_coming=x'. 

Someone tell me this is better (or different) than writing to flash ram, however....  Since we're never 'nvram commit'ting, what kind of memory is the nvram actually sitting in while the wrts are on?  flash ram? 

If this is the case, fizgig, I don't know how you can get away without wearing out your flash chips eventually.  I guess the only way to do this is to have a system separate from the wrts but within radio range that can have a web server and some php or cgi interface, that you can store the files on.

HTH

On the communication aspect:
the two wrt's don't even need to be connected in the TCP/IP sense.
Both can operate as a station and e.g. by changing the SSID name and a number of other transmission parameters (shortslot, shortpreamble) can indicate the states they are in. Either side can do a 'wl scan' for the particular MAC number of the other and get to know a number of parameters of the other side that way, as long as they receive one another. A script with some grep statements in it can keep track of status on either side and give feedback by changing the own transmission parameters.
Traffic is a serious matter though, with liability aspects.
Make sure that the default is (in case of loss of functionality) don't go. This kind of signalling tends to lower the attentiveness of the driver and may give a false sense of security. Scripts on both sides that sense the other and change their own state can establish a clear to send and acknowledge system on a high level as long as ultimate speed is not of the essence.
Normally a station sends its beacon like 10 times per second, but it can be adjusted.

I have written programs to read data from serial ports and parallel ports (on traditional laptop/PCs). Basically you just read the port and wait for data. From what I understand on your project you need to communicate with two different devices. 1) Input from your sensors that detect a car and 2) Output to the sign/light indicating a car is coming. You'll obviously need a program running to read the input data on both devices. Once a car is detected on WRT1 it has to notify WRT2 to turn on the "car is coming" light. If you don't want to write a simple client/server program in C (these really are trivial) you could write a simple program to turn the light on and off that would reside on each WRT you could use a system call to "ssh" to execute the command on the remote WRT like:

system("ssh remotewrt turnlighton");

It sounds like you have logic for determining if a car is entering and/or leaving so you know whether to turn the lights on or off. Here's the most recent thing I wrote that reads timer info from the serial port:

http://voidmain.is-a-geek.net/hts/

Of course I wrote all that in Perl (except for the small amount of C I stole from "xt" to configure the serial port so I can read from it). If I were to do it for the WRT I would write it in C.

Thankyou all for your suggestions!  Doddel, I really like your idea.  I'll probably go that direction at first.  I'm currently investigating how to change the ssid and get it to stick without rebooting.

Just a couple of observations:
- /tmp is kept in RAM, so no problems with writing files there
- wget isn't that lame a way to communicate - we use HTTP programatically for everything from checking that our servers are alive to posting credit card details to the bank..!

Dave