Skip to main content

The reason I thought of a simply IR receiver to sense when the locomotive passed are two fold. First, I believe I read somewhere or it was mentioned to me that the locomotives are built with an IR emitter/detector for use with the Sensortrack  unit. Second, if this is so, then by placing a small multiband IR receiver in the track I should be able to detect that signal as the locomotive passes over and pass that to the arduino mega to initiate commands at each passing. Simple trigger device requiring no modification of the train itself. This would be more than adequate for the layout they currently have. Because of the dimensions, we are unable to lengthen or shorten the track design without purchasing additional track segments and still have enough room for the scenery(trees, rocks, building, etc.). The IR receiver is small enough that a 1/8th inch hole in the track and under layment would suffice, without involving disassembling the current system. Wiring would be simple enough to conceal as 22 or 24 awg would work fine. The main issue is programming the arduino to send commands to the legacy controller as I have very little experience in this aspect with regards to legacy command structure. I have read up/downloaded as much as I could find in order to do so, but seem lost when it comes to understanding legacy. I have no experience in hexadecimal. 

Charlie Rounds posted:

The reason I thought of a simply IR receiver to sense when the locomotive passed are two fold. First, I believe I read somewhere or it was mentioned to me that the locomotives are built with an IR emitter/detector for use with the Sensortrack  unit. Second, if this is so, then by placing a small multiband IR receiver in the track I should be able to detect that signal as the locomotive passes over and pass that to the arduino mega to initiate commands at each passing. Simple trigger device requiring no modification of the train itself. This would be more than adequate for the layout they currently have. Because of the dimensions, we are unable to lengthen or shorten the track design without purchasing additional track segments and still have enough room for the scenery(trees, rocks, building, etc.). The IR receiver is small enough that a 1/8th inch hole in the track and under layment would suffice, without involving disassembling the current system. Wiring would be simple enough to conceal as 22 or 24 awg would work fine. The main issue is programming the arduino to send commands to the legacy controller as I have very little experience in this aspect with regards to legacy command structure. I have read up/downloaded as much as I could find in order to do so, but seem lost when it comes to understanding legacy. I have no experience in hexadecimal. 

Hi Charlie,

I am pretty much an expert when it comes to the TMCC and Legacy command structure since I am a Lionel LCS Partner who has been writing software for years.  I also have many years of Hex experience.  I can help you out if you want.

Harvey, I appreciated any help I can get. Our customer is also a friend, so we are trying to help them as cheap as possible yet give them something that will be pleasing to both them and their customers. It is a small village and where this building sits, long ago was a train depot, hence it is called "The Depot" now. The train tracks have been abandoned and are now a hiking, bicycle, seasonal trail. The train set is a hit with all the children that come in, so getting it up and operational has been an endeavor to say the least. If I were to post a scenario, step by step as to how we would like it to run, all I would need are the legacy commands needed to make the actions work with the base unit. I believe I can program that in to arduino as I have a little experience doing so. I am not so experienced in C, but I believe with the use of my Arduino programming books and examples I will be able to make it work. Again, I really appreciate any help we can get.

"Hi Charlie,

I am pretty much an expert when it comes to the TMCC and Legacy command structure since I am a Lionel LCS Partner who has been writing software for years.  I also have many years of Hex experience.  I can help you out if you want."

********************

Hi Harvey,

I'm glad for the chance to talk to a Legacy command expert.  I'd like to program my Arduino to send serial commands to the Legacy base to blow a diesel horn, or a steam whistle, in a prescribed pattern -- such as long, long, short, long for a grade crossing.  Yet the Legacy "blow horn" command (command 28) gives a very short toot and that's it.

The only solution I've been able to think of is to send a constant stream of "blow horn" commands, every n milliseconds.  However that timing, and the length of the blow, seems to be a little different for each loco.  I did a little testing and the whistle sounded choppy -- sometimes it sounded okay and other times it would stutter.

At worst, I could come up with the maximum delay between "blow" commands that sounds okay, and just spray out hundreds of commands.  But this is complicated by the fact that my Arduino is busy doing a lot of other things, including sending commands to several other locos concurrently, and abiding by a rule suggested by Prof Chaos that transmit bursts should be separated by at least 30ms (and sent in triplicate, which isn't a problem in this case.)

And if I have two or three engines that want to blow their horns at the same time...ugh.  There must be a better way, isn't there?

Have you figured out a way to do this, or does your software rely on the Legacy's built-in record option?

If you're using the brute-force method (per above) kindly share any details such as the delay between subsequent "blow" commands to keep it sounding, and the delay between subsequent any-kind-of commands.  Maybe I'm sending my "blow" commands too rapidly rather than too slowly...???  What is the minimum delay between serial bursts to the Legacy base, in your experience?

Thanks!

Randy

Hi Randy,

Horn commands should be repeated every 100 ms. That will give you a sustained blow as long as the commands keep coming.

If you have access to the LCS WiFi module, the free LCS WiFi Monitor Windows program would give you an easy way to see what commands the Lionel Remote is generating. TMCC commands may be enough for your application and these can be injected directly into the Lionel command base's serial port.

Sending Legacy commands requires an LCS SER2. But again, from reading your description of the desired operation, I think TMCC-style commands should be sufficient.

(http://www.lionel.com/lcs/LCSproducts/page/index.html)

Rudy

Railsounds posted:

Hi Randy,

Horn commands should be repeated every 100 ms. That will give you a sustained blow as long as the commands keep coming.

If you have access to the LCS WiFi module, the free LCS WiFi Monitor Windows program would give you an easy way to see what commands the Lionel Remote is generating. TMCC commands may be enough for your application and these can be injected directly into the Lionel command base's serial port.

Sending Legacy commands requires an LCS SER2. But again, from reading your description of the desired operation, I think TMCC-style commands should be sufficient.

(http://www.lionel.com/lcs/LCSproducts/page/index.html)

Rudy

Hi Rudy!

Thanks so much for this information!  Very helpful.  I do have all of the above products you mention (two of almost everything), and I have monitored the flood of commands in real-time on a laptop.  I was just hoping that Harvy (or anyone) might have knowledge of something I was overlooking -- aside from simulating pulling down on the horn control.

Great to have the 100ms number as a baseline gap.  Not too bad.

Since I have your attention - when sending a number of commands (i.e. several different commands stored in a buffer, such as set momentum, then set absolute speed, then turn on the bell, then trigger an announcement), my understanding is that I can send pairs (TMCC) or triplets (Legacy) of bytes together at the full 9600 baud rate -- but how long should I delay between subsequent commands?  Prof Chaos came up with the idea to leave a 30ms silence between contiguous commands -- whether addressed to the same or a different device.  Is there a standard you guys use?  Or is 9600 baud slow enough that any TMCC or Legacy device can swallow commands as quickly as they can be transmitted?

Thanks again -- your time is very much appreciated!

Randy

I don't know anything about Arduino (including how to pronounce it), but I can tell you that I pause 120ms between Horn commands while a user of my software holds down the Horn button.  This works 99.9% of the time.  You are correct that some engines seem to be pickier than others, but from my experience it is not the engine, it is the processor in whatever device is sending the commands.  It is not going to dedicate 100% of its CPU to sending out commands.  All you can hope for is to use trial and error to get it to work the best you can.  In your case you are lucky.  You are working with a finite number of engines.  For me, It is whatever engines my customers happen to have.

As far as wanting your Arduino to be doing other things while you are sending out Horn commands like there is no tomorrow, I use the "Application.DoEvents();" object in C#.  For my software, it allows it to detect the mouse up event so it can break out of the loop when the user releases the button of the mouse to stop sending horn commands.  It also allows you do anything else you want.

Another option for you, since there will be no user as such, is to create a separate thread to handle just the string of Horn commands.  That way your code can go on and do whatever you want.  If you don't understand the concept of threads, please let me know and I will explain it.

Here is my code for the Horn.  This does not include the Legacy variable horn.  That is separate code.

Let me know if you need me to explain this code more.  It is in C#.

 

I agree that a modest space between commands is prudent. Given the example you posted (set momentum, then set absolute speed, then turn on the bell, then trigger an announcement) I see no down-side to spacing out the commands somewhat. Using the monitor you can see how we handle timing from the remote, for example, when continuously spinning the throttle.

And as Harvy says, trial and error can be your friend!

Railsounds posted:

I agree that a modest space between commands is prudent. Given the example you posted (set momentum, then set absolute speed, then turn on the bell, then trigger an announcement) I see no down-side to spacing out the commands somewhat. Using the monitor you can see how we handle timing from the remote, for example, when continuously spinning the throttle.

And as Harvy says, trial and error can be your friend!

I am the developer behind High Rail for iPhone and iPad (https://highrailcompany.com). For those interested, I gave a talk earlier this year at the St. Louis CocoaHeads group on some techniques for building Lionel Legacy commands in Swift (https://swift.org). I did not, though, go into details on the Wi-Fi PDI protocols or the underlying async network connectivity. You can use the techniques I outline in the presentation and sample code to build type-safe multi-byte commands, too. It's cool stuff.

Here's the sample code: https://github.com/briancoyner/FiddleYard

Regarding the "spacing" (i.e. delay between commands): High Rail has the concept of a composite command that allows me to easily specify uniform delays between a group of homogeneous commands (e.g. dynamic whistle) or arbitrary grouping of heterogeneous commands. The default delay is 100ms, but can be changed as needed.

Lionel's PDI Wi-Fi tool is definitely helpful when debugging/ learning about the LCS/ Legacy/ PDI protocols. 

Perhaps this will be of interest to someone. 

 

 

Harvy posted:

I don't know anything about Arduino (including how to pronounce it), but I can tell you that I pause 120ms between Horn commands while a user of my software holds down the Horn button.  This works 99.9% of the time.  You are correct that some engines seem to be pickier than others, but from my experience it is not the engine, it is the processor in whatever device is sending the commands.  It is not going to dedicate 100% of its CPU to sending out commands.  All you can hope for is to use trial and error to get it to work the best you can.  In your case you are lucky.  You are working with a finite number of engines.  For me, It is whatever engines my customers happen to have.

As far as wanting your Arduino to be doing other things while you are sending out Horn commands like there is no tomorrow, I use the "Application.DoEvents();" object in C#.  For my software, it allows it to detect the mouse up event so it can break out of the loop when the user releases the button of the mouse to stop sending horn commands.  It also allows you do anything else you want.

Another option for you, since there will be no user as such, is to create a separate thread to handle just the string of Horn commands.  That way your code can go on and do whatever you want.  If you don't understand the concept of threads, please let me know and I will explain it.

Here is my code for the Horn.  This does not include the Legacy variable horn.  That is separate code.

Let me know if you need me to explain this code more.  It is in C#.

 

Harvy. thanks for the info. Unfortunately I can’t see the C# code you posted. I see the screen shot in your following post, but nothing for this one. Can anyone else see it?

Randy

Randy P. posted:
Harvy posted:

I don't know anything about Arduino (including how to pronounce it), but I can tell you that I pause 120ms between Horn commands while a user of my software holds down the Horn button.  This works 99.9% of the time.  You are correct that some engines seem to be pickier than others, but from my experience it is not the engine, it is the processor in whatever device is sending the commands.  It is not going to dedicate 100% of its CPU to sending out commands.  All you can hope for is to use trial and error to get it to work the best you can.  In your case you are lucky.  You are working with a finite number of engines.  For me, It is whatever engines my customers happen to have.

As far as wanting your Arduino to be doing other things while you are sending out Horn commands like there is no tomorrow, I use the "Application.DoEvents();" object in C#.  For my software, it allows it to detect the mouse up event so it can break out of the loop when the user releases the button of the mouse to stop sending horn commands.  It also allows you do anything else you want.

Another option for you, since there will be no user as such, is to create a separate thread to handle just the string of Horn commands.  That way your code can go on and do whatever you want.  If you don't understand the concept of threads, please let me know and I will explain it.

Here is my code for the Horn.  This does not include the Legacy variable horn.  That is separate code.

Let me know if you need me to explain this code more.  It is in C#.

 

Harvy. thanks for the info. Unfortunately I can’t see the C# code you posted. I see the screen shot in your following post, but nothing for this one. Can anyone else see it?

Randy

Sorry.  It was there before.  Hopefully you can see this:

Attachments

Images (1)
  • mceclip0
Last edited by Harvy

Well, it has been a bit since I posted, and I wanted to update on our progress to date. I had to wait for the IR receivers (tsop382) to arrive. In the meantime, we captured the various commands sent to the train from the legacy base unit to get an idea of what we were up against. The ir receivers arrived and I wired one up for testing to an arduino mega 2560, programmed it to flash an led signal when it received ir signal from a remote, then today we tested it on the tender behind the engine. The results are positive, it will receive a signal as the tender passes over. I wasn't quite sure if the ir signal from the tender was of the spectrum required, but the test removed all doubt. So we now have all the hardware required, and simply(or not so simply) need to write the software and upload it to the arduino to test. As I stated in previous post, the ir signal is simply a trigger to start a series of commands which will run in a loop, continuous all day until powered down, and will restart in the morning when powered up. Since we won't know the location of the train when power is turned on, it will slowly begin as a normal power up until it passes over the ir receiver at which point it will do certain commands, and repeat those commands for 3 more passes at which point it will slow to a stop, make certain noises intermittently for a period of 20 or 30 minutes, then start the loop over again. This pattern will continue throughout the day until powered down.

Hi Don - it's pretty easy to read and write TMCC or Legacy commands to and from the command base serial ports.  As Rudy mentioned, a SER2 is the most convenient way to go. Do keep in mind that the earth ground (ground for the command base) is supposed to be isolated from layout common (outside rail).

If you take a look at this link, you can find some of my Arduino projects. "Train Control" is a very complex system that automates train control, controls switches, signals, and accessories, and communicates with JMRI running on a computer.  But you will find examples of how to send TMCC, Legacy, and DCS commands over the Arduino serial port.

"Uncoupler Monitor" is a much simpler program that listens to the serial stream from the command base, and activates a relay module in response to commands directed to ACC 1-8.  Essentially a cheap and customizable version of the ASC.

For layout control I like the Arduino Mega, because it has four hardware serial ports. For accessories like the uncoupler monitor I like the Arduino Pro Mini, which is very small and costs less than $10. I am fiddling with transmitting commands from the Legacy base to HC-12 radio modules, with Arduino Minis in rolling stock picking up the radio commands (like a cheap and customizable Mini Commander).



Hi Professor

I have been studying the information you sent and sorry to report, I am confused (to say the least). First of all, when I try to open the files my Mac says I can't read the files and opens Arduino and then all the Arduino file names come up one after theater saying I can't open them. I need to force close Arduino after that. I tried to follow the short page you sent with the train codes, but I don't know what to type in as the parameter items in your function. Is it possible for you to send me (use my email if you wish (davidt@hotray.com) the library that I will need, plus the function calls to perform four actions: 1) Blow a horn of a selected engine (44, 81, 85);  2) Stop a selected engine; 3) Start a selected engine; and 4) operate a turnout. I assume that before the actual function calls I need to have code lines that specify which serial terminals to use. In this case that would be 0(Rx) and 1(Tx).

I thank you.

Add Reply

Post

OGR Publishing, Inc., 1310 Eastside Centre Ct, Suite 6, Mountain Home, AR 72653
800-980-OGRR (6477)
www.ogaugerr.com

×
×
×
×
Link copied to your clipboard.
×
×