Skip to main content

Replies sorted oldest to newest

Hey Patentguy - I have done quite a lot with Arduino and TMCC/Legacy.  I have attached to this post some snippets from a much larger automated control program.  These are the routines I use to transmit TMCC or Legacy commands to the Command Base.  I've also attached a library for circular buffers that the program uses.

You will see that the "send" routines just deposit the command string into the circular buffer. Then the main program checks to see if there is a serial command in the buffer waiting to be sent to the base, and sends it if at least 50 milliseconds have elapsed since the last TMCC transmission.  That may be a complexity you don't need, in which case you could just transmit the command as soon as you have built it.

You should refer to the document MED posted for the TMCC/Legacy protocol, or I can also post some routines showing how to control speed and trigger sound effects using that protocol.

Let me know if you have questions - I have also written routines for parsing TMCC or Legacy commands from either the serial port or the LCS PDI bus.

And what's your patent law connection?  I teach it!

Attachments

Last edited by Professor Chaos

Hey Patentguy - I have done quite a lot with Arduino and TMCC/Legacy.  I have attached to this post some snippets from a much larger automated control program.  These are the routines I use to transmit TMCC or Legacy commands to the Command Base.  I've also attached a library for circular buffers that the program uses.

You will see that the "send" routines just deposit the command string into the circular buffer. Then the main program checks to see if there is a serial command in the buffer waiting to be sent to the base, and sends it if at least 50 milliseconds have elapsed since the last TMCC transmission.  That may be a complexity you don't need, in which case you could just transmit the command as soon as you have built it.

You should refer to the document MED posted for the TMCC/Legacy protocol, or I can also post some routines showing how to control speed and trigger sound effects using that protocol.

Let me know if you have questions - I have also written routines for parsing TMCC or Legacy commands from either the serial port or the LCS PDI bus.

And what's your patent law connection?  I teach it!



Thank you. I will let you know how this works for me.

As to your patent question, I have a bsee degree from Pitt (1960 vintage) and graduated law school in 1966. I worked as a patent attorney for Bell Labs until 1989 and from then until retirement I headed up the Dallas section of Fulbright and Jaworski’s patent section and wrote several microprocessor patents in the 70s but never programmed one. Be well.


Ok, definitely start by reading pp. 3-6 of the document MED posted.  This explains the format of the 3-byte TMCC command strings.

The function I wrote takes these parameters:

sendTMCCCommand (SysTypes deviceType, byte deviceID, byte commandField, byte dataField, byte repeats) 

For your example (blowing a horn on a TMCC engine)

  • deviceTYPE = ENGType (B00000000 as I've defined it in the defs.h tab)
  • deviceID = xx (whatever TMCC ID# you've assigned your engine)
  • commandField = 00 (as shown on page 5 of the Lionel document for horn command)
  • dataField = B11100 (also as shown as page 5 for horn command)
  • repeats = 1  (transmit this command 1 time)

so our call is:

sendTMCCCommand(ENGType, xx, B00, B11100, 1);  //blow horn 

Some other examples:

sendTMCCCommand(ENGType, xx, B11, 10, 1); // set engine speed to step 10

sendTMCCCommand(ENGType, xx, B00, B10101, 1); // numeric 5 for slow dialogue

I should add, that I'm assuming you've got the hardware end of things sorted. The TMCC or Legacy bases use RS-232 signaling, so you'd need something like a MAX232 chip to convert voltage level and polarity  between the Arduino's TTL and the Base's RS-232.

I do have the hardware portion sorted out. I will be using a SparkFun shifter PRT-00449.  I do believe I understand the TMCC byte structure but I will review the document again. When I address my engine from the hand controller I put in ENG 2344. But I don't know how to do that with only a 7 digit binary address field. I must be missing something. Thank you for all the help. You can use my email address of davidt@hotray.com to discuss patent related questions. Someone on this link seems concerned that I or someone will try to patent this info. I really hope that person is joking since this is either public domain or at the very least not my work. I doubt if there is anything to patent even if it was new,

I think you're addressing your engine by a road number, which is only stored in the Legacy base/remote. Each engine has an internal TMCC address ranging from 1-99 (referred to as a "Traditional ID #" in the Legacy manual).

You should see that # above the "ENG" box on the Legacy remote if you press the INFO button once or twice.



People have strange ideas about patents sometimes. I was once being interviewed on a radio show about gene patents. A caller asked: if Monsanto were to inject patented DNA into me, would Monsanto then own me?  Ok then....

Last edited by Professor Chaos

This is an interesting discussion, but I'm not clear on what role the Arduino is playing (at the risk of asking a stupid question...) - where does it "sit" in the operator - locomotive communications scheme?  In an 'ordinary' TMCC scheme, the operator has a handheld controller, which communicates 'wirelessly' with the TMCC controller, which then communicates with the loco.  Does the Arduino talk with TMCC controller or does it eliminate the TMCC controller by sitting in the loco/tender and talk directly to the TMCC board in the loco/tender?  In the latter case, then presumably one can talk with the Arduino via bluetooth and a phone app?

In my thoughts on using the Adruino with TMCC or Legacy, the Arduino would logically be in parallel with the Cab1 or Cab2 - meaning I could send any command from the Arduino that I could send from the Cab1 or Cab2. A simple application could have the Arduino sense (via isolated outer rail section) when an engine enters a auto/pedestrian crossing and the Arduino blows the horn.

Once you get the Arduino and associated hardware with its programming capable to send TMCC or Legacy commands, you can just about do anything from the Arduino - you imagination becomes the limit.

My personal interest has to do with the DZ2500 switch machines, and making a central switch control panel. I am running DZ2500s by there serial capability, thus the Arduino could send commands to the switches. I was hoping to use the capability of the DZ2500 via its serial where you send a switch set address command to a switch (the switch set address sent is the address that the switch was set to during layout set up), and the switch will return FFFF for one direction, 0000 for the other direction. For example, one switch on my layout is set to address 20. If I send a switch set address command containing the address 20, the switch 20 will return FFFF for one direction, 0000 for the other direction.

@MED posted:

In my thoughts on using the Adruino with TMCC or Legacy, the Arduino would logically be in parallel with the Cab1 or Cab2 - meaning I could send any command from the Arduino that I could send from the Cab1 or Cab2. A simple application could have the Arduino sense (via isolated outer rail section) when an engine enters a auto/pedestrian crossing and the Arduino blows the horn.

Once you get the Arduino and associated hardware with its programming capable to send TMCC or Legacy commands, you can just about do anything from the Arduino - you imagination becomes the limit.

My personal interest has to do with the DZ2500 switch machines, and making a central switch control panel. I am running DZ2500s by there serial capability, thus the Arduino could send commands to the switches. I was hoping to use the capability of the DZ2500 via its serial where you send a switch set address command to a switch (the switch set address sent is the address that the switch was set to during layout set up), and the switch will return FFFF for one direction, 0000 for the other direction. For example, one switch on my layout is set to address 20. If I send a switch set address command containing the address 20, the switch 20 will return FFFF for one direction, 0000 for the other direction.

Someone recently posted a sketch for controlling TMCC signaling. The sketch included two libraries. 1) TMCC Comm and 2) SoftwareSerial Class. The link that was posted seems to be a dead end for me. I can't find either of these in the Arduino Library. I must be doing something wrong, but can't figure out what it is. Need a bit of help. THANKS

@richs09 posted:

This is an interesting discussion, but I'm not clear on what role the Arduino is playing (at the risk of asking a stupid question...) - where does it "sit" in the operator - locomotive communications scheme?  In an 'ordinary' TMCC scheme, the operator has a handheld controller, which communicates 'wirelessly' with the TMCC controller, which then communicates with the loco.  Does the Arduino talk with TMCC controller or does it eliminate the TMCC controller by sitting in the loco/tender and talk directly to the TMCC board in the loco/tender?  In the latter case, then presumably one can talk with the Arduino via bluetooth and a phone app?

The straightforward role is to have a single Arduino talk to the Command Base via the serial port, and let the Command Base communicate with locomotives, switches, accessories, etc. I have used that approach to create a complex signaling and automated train control system that you can find here.

One could theoretically install small Arduinos into locomotives, but if you're starting with command control locomotives I'm not sure what the advantage would be over having your Arduino use the existing TMCC communication infrastructure.

I did create an Arduino-based board to install in operating cars (sort of a replacement for the ERR Mini Commander), but used a master Arduino node connected to the Command Base to read TMCC commands and transmit them over a radio link to nodes installed in the operating cars (documented here).

Add Reply

Post
OGR Publishing, Inc., 1310 Eastside Centre Ct, Suite 6, Mountain Home, AR 72653
330-757-3020

www.ogaugerr.com
×
×
×
×
Link copied to your clipboard.
×
×