Anyone use Arduino on layout

Question for Professor Chaos,  RFID, What distance from the cars do you have to place the reader and how fast can the train go and still reliably read the tag? What is the speed of train vs distance from reader. I assume you are using the larger 2.13" x 3.35" tags.  

Thanks,

Dan

The answer to how fast and how close depends on 2 factors. The strength of the signal generated by the transceiver and the size of the TAG. The TAG receives the RF signal to make power to send back its signal. So the bigger the TAG the further away it can be to make suffient power to generate a return signal. I tried 2 different RFID transceivers- Parallax and Innovations. The Innovations worked better for my application. I can use a 1" diameter TAG under an engine at any speed.

Another example is EZ-PASS. I go thru a hiway EZ-PASS at 70-75 mph and the 3X4" TAG is on my windshield. Probably a strong transceiver signal.

FWIW, there is a battery in the EZ-Pass, so it's not a simple RFID tag.

I am struggling to connect my Legacy base to my Arduino via the DB9 connector on the legacy base, thru a 9-pin cable to a MAX232-based RS232-to-TTL converter board, and then to my Arduino.

Even without connecting the Arduino board, I would expect that when I apply +5v and Ground to the converter board, I should see the receive LED on the board flash whenever the activity LED flashes on my Legacy base.  Have I lost you yet?

U:US:3160" target="_blank">Here is the type of board I am connecting to my Legacy base.

So simply plugging the DB9 end of this board into my Legacy base, and connecting +5 volts and ground (which happens to be from my Arduino) powers the thing up and *should* flash the "receive" LED on the converter board -- shouldn't it?

Is my Arduino Mega not providing enough current?  Is the Legacy base not sending regular serial data???  Suggestions appreciated.  Thanks!

It seems so, if the board is working. But not knowing anything about the board, hard to tell. 

Do you have a different serial device to test the board with?

And be sure you are not using a crossover serial cable.

You do realize that in order to actually use the Legacy commands, you'll need the serial buffer or WiFi module, right?  You can use the 8-bit TMCC commands direct to the serial port.

I can tell you that I put my RS-232 test box on the serial port of the Legacy base and I see data on pin 2 of the connector when I press the whistle control on the CAB2, so data is coming out.

Hi Randy - what you are doing should work, though I don't think I have looked much at data coming OUT of the Legacy serial port.

I send commands to the Legacy base with a MAX232 circuit hooked up to the Arduino, though one of my own making.

Just occurred to me:  Common ground? The Legacy base ground (exposed on pin 5) must be connected to the Arduino ground for serial communication.  See if your converter board connects the grounds, by looking for continuity between pin 5 of the DB9 to the GND connector on the board.

One other thing to try would be to use the Legacy Y-cable.  I hook things up using the Y-cable;  it may not make a difference, but the Legacy serial port does use non-standard pin assignments to enable incoming serial from both a TMCC base and another serial device.  The Y-cable re-routes some of the pins so that devices plugged into the Y-cable will see the right connections.

If neither of those work, get something else with a RS-232 port to test communication with the Legacy base, and with your converter.  If you don't have an old computer with an RS-232 port, you should be able to find a USB-RS232 (not USB-TTL) converter.  Then you can use a terminal program on your computer to test communication with the Base and with your converter board.

SOLVED!

I inserted a null modem adapter at the end of my RS232 cable.  My cable is wired straight through, so the null modem adapter (as I understand it) flips the TX and RX wires.  That would probably also have been accomplished by using the Y cable that Prof. Chaos is suggesting. 

Now when I do anything on my Legacy remote, the RXD LED on my MAX3232 adapter flashes!  And when I connect my Arduino (and after flipping the TX and RX wires again, trial and error) with a bit of "Serial1.read" code, my serial monitor on my PC will spit out one or a few garbage characters -- so now even my Arduino is seeing the output from the Legacy base!  Yay!

Next I modified my code that was sending the FE FF FF "all stop" command, and now it is working too!  I use the following code and it will stop a moving loco in its tracks (good pun, eh?):

    Serial1.begin(9600);

    Serial1.write(0xFE); 
    Serial1.write(0xFF); 
    Serial1.write(0xFF);

This is for an Arduino Mega which has 4 serial ports.  I'm using port 0 for my PC serial monitor, and port 1 to talk to my Legacy base.  (I have some additional code to read the input from port 1 (from Legacy) and spit it out to the serial monitor.  It looks like garbage because the hex translates to crazy ASCII characters.

Thanks to all, especially gunrunnerjohn and my hero, Prof. Chaos.

DTE v. DCE... the bane of serial communication for generations!

Welcome to the non-standard standard of RS-232.

How complete are the component libraries of DipTrace, and how easy do you find it to generate new parts?

For those that are trying to see the serial output of the command bases, there is a free to download terminal program called Real Term. It can be set to display HEX code or even Binary code instead of trying to decode ascii characters. The program can also be used to send HEX code to the bases for testing.

I use the USB-to-Serial adapter that I use for updating the Legacy software and plug it into the SERIAL COMM connector on the "Y" cable that came with the Legacy.

Try this - Dropbox went through some security reconfigurations.

John, I think Diptrace libraries are probably not as complete as Eagle, but it was pretty easy to design new parts.  It's the only layout program I've used - I found Eagle way too hard to use!

Well, I struggled with Eagle as well, I did a small board layout with it some time back.  I'm trying to lay out my current little PIC project using DipTrace, we'll see how that goes.  I'm having to use a lot of generic parts and modify them on the schematic, the PIC12F1501 was my first problem, it's not in the library. 

It seems the easy part is coming up with the design and software, the really difficult stuff is getting in in a form that you can then generate a proper board layout! I'm jealous of Jon Z. at Lionel, he whacks those schematics and boards out really quickly, he obviously has a proper library of the parts he uses.  I suspect he's also a lot faster at making new ones that he needs.

I was spoiled when I was gainfully employed, we had folks who's only job was to keep the parts libraries updated with all the approved parts.

I have used the Arduino Uno with a RS-232 Shield from Link Sprite to send commands to the TMCC Base and the Legacy Base (COM-1 mode). I made a three wire cable as shown in the diagram and it works on the SERIAL COMM connector on the cable that comes with the Legacy or plugged directly into the TMCC base or plugged directly into the Legacy Base. It works with the CAB-1, the CAB-1L, and the CAB-2 (in CAB-1 mode).
 

A short sketch (program) for the Arduino is shown that blows the whistle for engine 60 three times one second apart, then waits ten seconds and repeats.


With nothing plugged into the Arduino the RS-232 shield blinks the RX LED when the commands are sent. With a base connected the RX LED blinks and the command is echoed back and the TX LED blinks also. Any commands from any of the three handhelds also blinks the TX LED. It is not necessary to have ENG 60 on the track or even have track power on to see the blinking LEDs


Only two wires are required to send commands from the Arduino to the Base but by adding the third wire the Arduino can also receive commands, plus with three wires the cable is symetrical. It doesn't matter which end is plugged into the Arduino and which end is plugged into the base.


I have not looked into any Legacy commands.

Fascinating!  I've only skimmed through this thread and got a taste of what is possible.  Thanks and keep up the good work!  

When you get to the routing stage, you might check out www.freerouting.net.

It has an autorouter that worked better than Diptrace's - you export your board as a DSN file then route it through the freerouter.

I'm still stuck on generating parts with board outlines.  For some reason I can generate the schematic symbol, and then the footprint, but I can't for the life of me get them combined to make a part I can use on the PCB!

It's been a while, but I think from Component Editor you choose Component > Attached Pattern...

Select the pattern library and then choose your pattern. 

I figured it out, there was some mix-up with my libraries and I was getting errors.  I managed to do an initial layout of my board, though I may tweak it before I go to press.

I did find out why the mass move to surface mount, you can't fit squat on a board with thru-hole parts!

I'm neck deep in designing an Arduino-controlled layout and have made a lot of "theoretical" progress, which I will share soon.  However I don't understand how TMCC (or Legacy) controls "Trains" versus "Engines."  I have the Engine control figured out, no problem.  But I want my Arduino to control trains (multiple engines) and as I monitor the serial codes coming out of my Legacy base (my train is composed of TMCC engines) I can't figure out how this works.

The commands simply address the particular train, not the individual engines which is what I was expecting.  I.e. I thought the CAB-2 would be sending individual commands to each engine in the train, but it isn't.  It's only sending individual 3-byte commands, addressed to a train rather than an engine.

So if I tell CAB-2 to open the rear coupler or the front coupler, the commands are the same except for the last two bits (00101 vs 00110) even though the couplers would be on different engines.

I didn't actually have the engines on the track when I defined the trains on my CAB-2, and it spent 10 seconds or so defining the train -- I have no idea what it was doing.

Are the TMCC engines themselves supposed to be on the track, maybe in programming mode, when I define the trains?  Or is the RF signal being sent to the trains different than the serial codes that are being echoed out of the port on my Legacy base (the answer I dread)?

In short, I need to understand what commands my Arduino needs to send out the serial port in order to make a multi-engine train behave -- synchronized speeds, accounting for "reversed" locos, appropriate couplers being opened, speech out of the lead loco only, etc.

Thanks in advance for shedding light on this!

Randy, I would assume that the conversion would happen like you expect, but I haven't actually tried it.  The base knows what discrete engines comprise the "train", so it's capable of actually sorting all of this out.

I believe (although I am not certain) that each locomotive simply tracks which train it is in.  When you press SET to program a train, a locomotive notes that it is part of that train, and will thereafter respond to TR commands with that ID.

You can confirm this by assigning a locomotive to a different train when it is not on the track.  Does it thereafter respond to the old train, new train, or both?

Randy, you do have a copy of The Complete Guide to Command Control, don't you?  It shows the serial codes for engines vs trains etc.

Actually, that makes perfect sense.  When you program the train on the Legacy, the last step is programming the trains, and the horns all honk a bunch of times as they respond to the programming.

Okay, well either explanation will be great for me -- just set up the trains on my CAB-2 (with the engines on the track, presumably) and issue simple "train" commands from the Arduino, and Legacy takes care of the rest.  Perfect!  Thanks for your thoughts.

I have what I think are some pretty great solutions for tracking occupancy, setting turnouts, and other hardware control that will be needed on my Arduino-controlled automatic train layout.  If you have any interest in this idea, please continue reading and let me know what you think...

For occupancy, I found these great 15VAC time-delay relays on eBay.  I have chosen 15VAC with 0 to 5 seconds delay, but they are available in a variety of coil voltages and delay ranges.  I can trip them with short isolated rail sections and 15VAC hot.  I figure I'll set them at around 2 seconds and this will eliminate any potential "chatter" due to problems with wheels not making a perfect connection as they bridge the isolated rail, or long cars that could momentarily bridge the isolated section.  I tested one and just an instantaneous tap of power to the coil closes the contacts and holds them for the specified time - the capacitor charges quickly!  So when the relay releases, I can be pretty confident that the train has left the isolated section.

I also don't have to worry about contact bounce, because I'm going to be wiring the relay contacts to the input pins of a Parallel In Serial Out register (actually a bunch of them chained together) and simply poll them fairly frequently.  So if a contact is bouncing when the input pin is latched -- no big deal, I'll catch it in another moment when I poll it again.  I hope that makes sense.

These relays may seem like overkill because they close huge contacts which only need to provide a TTL-level signal to the shift register pins, but what I like about them is they really solve a lot of problems, they're self contained, and are only around $7 each including shipping.  I don't even need to add bridge rectifiers!

I'll be glad to fill in more details for anyone who wants to know more, but that's the gist of it.

For turnout control, I've decided to use a gang of Serial In Parallel Out shift registers controlling an opto-isolated 5vdc bank of relays, available on eBay for less than $1 per relay on boards of 8.  The relay coils can be powered independently, so the shift register pins are only powering the optos.  The contacts will energize the switch machine coils with 14VAC.

I'll program the Arduino to just set one register bit at a time -- throw that particular coil, then set them all to zero to release that coil (all coils.)  By holding the coil for only perhaps .1 second, I'll avoid burning out any switch machines, and never throw more than one machine simultaneously.

For routes, I'll just repeat the process for all of the switches in the route -- only triggering one switch at a time, but getting through them all very quickly.

I am also thinking I can avoid the need for the Atlas 6924 non-derail boards (which I would use as a "non coil fry" device) by wiring Atlas #57 turnout control buttons to my Arduino rather than to a 6924 or directly to switch machines.  I won't have a non-derail feature, but I can easily implement one if I want to look at my occupation sensors at the entrances to turnouts -- even when the layout is not in "Automatic" mode.

Because Arduinos only cost around $10 each on eBay, I think I'm going to dedicate individual Arduinos to some tasks, such as monitoring the occupancy sensors, and managing turnouts/routes/switch controls -- even when not running my trains in "automatic" mode.  I may also dedicate an Arduino to being the sole interface to Legacy via the RS232 serial port -- and let that Arduino build and disassemble TMCC (and eventually Legacy) commands to and from the rest of my automation system -- so only that one Arduino has to "know" how to do this. 

Inter-Arduino communication could be via the I2C "two wire" bus, and could even allow for features that may be implemented in the future -- such as conditional requests to turn on accessories or stop the train momentarily or blow horns or whatever, when certain trains (or classes of trains) entered or left specific blocks.  There are so many possibilities!

I can also add Arduino-based boards to control accessories, manage all of the signals, and other fun things that have not yet occurred to me ;-)

The turnout/route control Arduino and others will totally negate the need for Lionel's SC-2, ASC, etc. as well as the Atlas 6924 boards.  They will be better for my purposes and cost *significantly* less than the commercial products.  Even when in "manual" mode, the system will watch for switch and route and accessory commands from the CAB-2, and turnout "commands" from Atlas #57 control boxes, and respond accordingly.  All of the hardware is really inexpensive and basically "off the shelf" -- no need for any custom circuitry, other than stringing shift registers together.

Sorry if that's confusing -- I have a ton of notes and test results that I am bringing together into an Evernote-based design document.  And none of this has even touched on the algorithm I'm working on which will automatically control multiple trains and (hopefully) avoid collisions and deadlocks.  But these are some hardware highlights of what I hope to do, and I wanted to share my thoughts with you guys (and gals?).  I welcome any feedback you may have of what I may be overlooking etc., and am happy to compare notes with anyone working on similar projects.  Lots of my early ideas and assumptions turned out to be wrong, and probably some of the above may be as well.

Thanks gunrunnerjohn and others for your helpful advice.  Above all, I want to thank Professor Chaos for inspiring me to dive into this project, and for sharing his source code and hardware designs and ideas so freely.  Have a look at his YouTube videos and you might see why I am so enthusiastic about this.  Lots of fun!

Randy, a couple of points.

You talk about the switching and insuring that they are only energized for a brief period.  Remember, you need to cover the eventuality that the processor goes to lunch, or you have some other hardware failure.  I'd have a reset on the shift registers that is driven by a watchdog of some kind, say a 555 or a dedicated watchdog chip.  The WD would be triggered by the processor in the I/O routine that services the shift register, and if it doesn't get triggered, all the register bits get reset.

I'd give a little though to having some sort of larger computer that is the central "brain" of the logic, that way you can have graphics on the screen and a user interface only limited by your imagination.

For block detection I'm using a 16F631 PIC. You can hook it directly to the rails (thru a resistor of course). It has 16 I/O pins so it'll give you 15 blocks in and 1 output. It's main function is to do the filtering and detection and  then send that out to the main processor (another PIC, Arduino, PC, whatever). And it's only a dollar something.

You'll want some signal conditioning on the block sensors, you certainly can't put AC from the track directly on the pins of something like an HC165! 

FWIW, you don't have to use AC for the block detection.  You have an insulated rail and a ground.  If you use the insulated rail to the input filter with a pull-up resistor to the VCC supply of the chip, you'll have a low input for any occupied track.  For your 74HC165, I'd probably have maybe a 2.2K resistor in series, a 10uf capacitor to ground, and a 10k resistor to VCC for each input.  The other end of the 2.2K resistor connects directly to the insulated rail, when it's grounded by the rolling stock on the rails, you have detection.

If you're ultimately connecting your detection system to the Legacy serial port, don't you have to deal with isolating the track common from earth ground?

I'd do that downstream from the detection so I only had to isolate one connection.  An opto-isolated serial port like this B&B Electronics 232SPHI4 would probably work.

I can't believe I'm saying this to YOU John, but why would you buy a $100 serial isolator when you can roll your own for a few bucks with an optocoupler?

OK, if you needed to pass all the signals maybe, but if you're just isolating a serial line it's easy to to with an optocoupler.

I would up isolating my RFID readers because the switching supply on a monitor was clobbering the read range. I suppose I could have played around with filters, but I just built a little isolator with an HCPL-7710.  Even that was probably gross overkill at 9600 baud.