Go Down

Topic: would you like a program challenge? (Read 2 times) previous topic - next topic


I can use the cat 6 cable , do you think the distances would cause a problem?


Having thought it over some more, I think multidrop RS485 using async serial protocol might be better because of the long cable runs, with an attiny84 at each signal. If you use Cat 5 cable (or preferably Cat 6 for its lower resistance), then depending on the power requirement of the signals, you might be able to use 1 pair for the RS422 and the remaining 3 pairs for power. The attiny84 has enough pins to connect all 4 lights, the RS485 transceiver, and the switch.

I was trying to keep it KISS with small part count, but the limitations of I2C might be biting me in the rump. Looking at a schematic used on something here at work I see that we use RS485 with a MAX1480 providing the UART translation and support circuitry to protect from shorts and static. If you want to see that part of the schematic I can check to see if I'm allowed to scan it and post it publicly. (I don't see why not as we are a research department at a University, not a commercial company...)


Apr 01, 2013, 11:28 pm Last Edit: Apr 01, 2013, 11:31 pm by matelot Reason: 1
that sounds as if it is getting serious. I am only volunteering to wire a set of signals for the railway.
Would sending it to me e-mail be easiest?
I think I would want to be fairly sure I had a grasp of the software program to make it happen before I spent that sort of money.


Apr 01, 2013, 11:40 pm Last Edit: Apr 02, 2013, 12:07 am by Erdin Reason: 1
The Arduino Mega 2560 can use the same code as for the Arduino Uno. The I2C pins and SPI pins are at another location, so not all shields are compatible.

With that distance, use many wires or use RS485 or go wireless.
I like the idea to use Cat5 or CAt6 cable.

I would like to make a layout for the code.

Programming :
The best way to do this, is to actually create the (location of the) train in software.
The second train is just another variable.
Divide the track in parts. The switches are the dividers.
Make functions for the signals. A function for each signal. So the way the signal works is in the function. But the functions can be called in the same way.
The magic happens in a block that makes decisions on the situation at that moment. This should be written well, because it will be the hardest part to understand.

Updated according post below: To make the decisions it would be handy to have all switches in variables. So perhaps the switches should be updated a number of times per second and copied in the variables. The switches should be filtered before copied, since every wheel activates it. The variables should have the 'clean' and filtered value to make the decisions upon.


Apr 01, 2013, 11:44 pm Last Edit: Apr 01, 2013, 11:46 pm by matelot Reason: 1
yea that looks about it.
One problem is that each wheel is going to be going over the sensor so it should only trigger once for each train. A delay or a ref that the train has triggered the next switch should be enough to separate the signals. I worked out <2 secs for each bogey. i.e. if switched again in less then 2 secs it is the same train.
The system as it works now is that the switches are the dividers for each section.

Go Up