ERR Mini Commanders are no more! Possible Replacements

@Lionelzwl2012 posted:

I have a question for anyone here. in doing these legacy conversions. how is the lionel tach reader installed on the converting engines motor.

mth uses a tach strip to attach to the flywheel of the motor. wich can be used in any engine with a flywheel right. so converting to ps3  fairly easy.

now I understand getting all the lionel boards such as the right rcmc board ect. but there motor speed encoder is a plastic squirrel type cage set up.how is that Handeled in non lionel engine conversions?

Roger, Lionel uses a similar ( not exactly the same as MTH ) system, ….there’s a sensor, and legacy encoder ring on the flywheel,….the two systems simply count the motor revolutions, and calculate tings like speed, and chuff rate,…..IMO, the MTH system is way more flexible, and a thousand times more user friendly,……with the ability to manipulate sound files, and running characteristics via chain files, ….plus chuffs can be changed to oblivion via the remote,……with Lionel Legacy, you’d better pick the one you want correctly the first time, …..cause it is what it is out the box,….😉

Pat

@gunrunnerjohn posted:

Those are the kinds of lessons you remember.

I learned that the LCRU has a random polarity of it's lighting outputs, sometimes positive to ground, sometimes negative.  That drove me nuts for some time before I sorted it out!

I wonder if this is why the R2LC-C07 is so frustrating to get working with the CC-M sometimes it works. Sometimes it doesn't. Is the serial bus line polarity random I wonder?

@gunrunnerjohn posted:

Bruk's documents made a huge difference, that's for sure.  I did find one minor mistake in the documents when doing the RCMC test set, the smoke thermistors are wired wrong in the diagrams.

Was this a recent discovery? I followed Bruk's diagrams to the T and had no issues.

@rplst8 posted:

Was this a recent discovery? I followed Bruk's diagrams to the T and had no issues.

I got the correction from the horse's mouth, and I suspect it's correct.

The interesting thing is, the thermistor doesn't have nearly as big a role as I first thought, which is why I think even wiring it wrong it may not affect the operation enough for you to see it.  In my RCMC Test Set, I just used a 4.7K resistor for the thermistor, the RCMC is happy as a clam.

@rplst8 posted:

I wonder if this is why the R2LC-C07 is so frustrating to get working with the CC-M sometimes it works. Sometimes it doesn't. Is the serial bus line polarity random I wonder?

Oddly, I've never had any issue getting the R2LC-C07 to work with the CC-M, and I know of no reason why it wouldn't.  Clearly the serial bus data is the same or the RailSounds cards wouldn't work!

@Professor Chaos posted:

That's why there's a radio module in the operating car.

One 'master' radio module plugs into, and is powered from, the Legacy PDI bus. It then passes on Legacy or TMCC commands over the RF69 wireless network to radio modules installed in operating cars, accessories, etc.

Hello Chaos,

I saw you made a TMCC receiver that decodes serial? Is that right? If so can you share the arduino sketch?

thanks

@Pu239 posted:

Hello Chaos,

I saw you made a TMCC receiver that decodes serial? Is that right? If so can you share the arduino sketch?

thanks

The sketch here has code for state machines, either TMCC serial or Legacy PDI, that will read and parse TMCC or Legacy commands.

It works by instantiating an object that you periodically poll with the updateSerial routine, and if you have a command received, you can read and parse it in several formats.

But that may be more complex and more general than you need, depending on your application.

@Professor Chaos posted:

The sketch here has code for state machines, either TMCC serial or Legacy PDI, that will read and parse TMCC or Legacy commands.

It works by instantiating an object that you periodically poll with the updateSerial routine, and if you have a command received, you can read and parse it in several formats.

But that may be more complex and more general than you need, depending on your application.

Oh so it has to be a PDI bus connection? I wish I was better with Arduino, I’d love to have a sketch that I could throw on a nano, and chose what action via serial I’d like to activate. IE, like whistle steam, or anything else. I’m a PLC guy and it’s hard to learn new stuff in depth when I’m deep into PLC stuff.

@Pu239 posted:

Oh so it has to be a PDI bus connection? I wish I was better with Arduino, I’d love to have a sketch that I could throw on a nano, and chose what action via serial I’d like to activate. IE, like whistle steam, or anything else. I’m a PLC guy and it’s hard to learn new stuff in depth when I’m deep into PLC stuff.

No, it will work either with the PDI bus or a straight serial connection. You instantiate a a "PDIClass" for a PDI monitor, or a "TMCCSerialClass" if reading from a 9600 baud serial connection.

I meant to clean everything up into a single class at some point but never got around to it.

The main code in that sketch monitors the serial port for ENG or ACC commands and sends them to radio modules, but the code in "PDI.h" "TMCCSerial.h" and "tmcc.h" is general.

I ran into some other missing include files, maybe I'm not ready for this one.   FWIW, I'd want this to read the serial data in a locomotive, it's and the oddball bit rate of around 3,000 BPS.

@Professor Chaos posted:

No, it will work either with the PDI bus or a straight serial connection. You instantiate a a "PDIClass" for a PDI monitor, or a "TMCCSerialClass" if reading from a 9600 baud serial connection.

I meant to clean everything up into a single class at some point but never got around to it.

The main code in that sketch monitors the serial port for ENG or ACC commands and sends them to radio modules, but the code in "PDI.h" "TMCCSerial.h" and "tmcc.h" is general.

Thanks, I will give it another look.

Any chance you would strip it down to just decode tmcc/ legacy? What would the code look like to say activate an output if the whistle is blown?

Thanks very much

Hi John & Pluto -

If all you're looking to do is read commands from the serial port, this minimal sketch should do (you could delete the PDI tab as well).

It's configured to read TMCC commands from a serial port, and output debugging info via SoftwareSerial. John, you could try changing the TMCCBAUD parameter in the TMCC tab to 3000 and see what happens - I've never tried with anything but the output from a command base.

Disclaimer: untested!

Will this run on the Arduino Nano?

@gunrunnerjohn posted:

Will this run on the Arduino Nano?

No reason it shouldn't, just adjust the SoftwareSerial pins if you need the debugging output.

I usually prefer one of the Pololu A-star boards, since they're cheaper (at least the 328PB one) and the second UART is extremely convenient for serial projects.

I'll have to look at those, but I have several of the Nano boards and an UNO, so might as well tinker with something for free.

The second serial port would be very handy however!

@Professor Chaos posted:

Hi John & Pluto -

If all you're looking to do is read commands from the serial port, this minimal sketch should do (you could delete the PDI tab as well).

It's configured to read TMCC commands from a serial port, and output debugging info via SoftwareSerial. John, you could try changing the TMCCBAUD parameter in the TMCC tab to 3000 and see what happens - I've never tried with anything but the output from a command base.

Disclaimer: untested!

Thanks

So if Im reading it correctly, this decodes eng 3 data? Im sorry, Im very new to this way of coding. If I can ask some basic questions, I can wrap my head around it. If say I want eng 3 to blow its horn, is this what this will do? I also need to find the serial data for a horn etc to compare to.

@Professor Chaos posted:

No reason it shouldn't, just adjust the SoftwareSerial pins if you need the debugging output.

I usually prefer one of the Pololu A-star boards, since they're cheaper (at least the 328PB one) and the second UART is extremely convenient for serial projects.

Since I want to go small and eventually stick this in a locomotive, I picked the Pololu A-Star 32U4.  However, I ran into a problem.

If I pick the Arduino Nano, it compiles fine. I'm only three of the files of the TMCC reader, I removed PDI.h as I don't need it.

However, when I pick the Pololu A-Star 32U4 as my board, I get this error.

D:\Arduino\Read_TMCC\Read_TMCC.ino: In function 'void setup()':
D:\Arduino\Read_TMCC\Read_TMCC.ino:39:30: error: no matching function for call to 'TMCCSerialClass::begin(Serial_*)'
   monitor.begin(&MONITOR_PORT);
          ^
In file included from D:\Arduino\Read_TMCC\Read_TMCC.ino:23:0:
D:\Arduino\Read_TMCC\TMCCSerial.h:24:6: note: candidate: void TMCCSerialClass::begin(HardwareSerial*)
void TMCCSerialClass::begin(HardwareSerial* whichPort) {
      ^~~~~~~~~~~~~~~
D:\Arduino\Read_TMCC\TMCCSerial.h:24:6: note:   no known conversion for argument 1 from 'Serial_*' to 'HardwareSerial*'

exit status 1

Compilation error: no matching function for call to 'TMCCSerialClass::begin(Serial_*)'

I'm assuming I have to change something about MONITOR_PORT.  That's an emulation for the debug port, right?  Apparently I falsely assumed since you recommended these boards I'd have better luck with them.

@gunrunnerjohn posted:

D:\Arduino\Read_TMCC\Read_TMCC.ino: In function 'void setup()':
D:\Arduino\Read_TMCC\Read_TMCC.ino:39:30: error: no matching function for call to 'TMCCSerialClass::begin(Serial_*)'
   monitor.begin(&MONITOR_PORT);
          ^
In file included from D:\Arduino\Read_TMCC\Read_TMCC.ino:23:0:
D:\Arduino\Read_TMCC\TMCCSerial.h:24:6: note: candidate: void TMCCSerialClass::begin(HardwareSerial*)
void TMCCSerialClass::begin(HardwareSerial* whichPort) {
      ^~~~~~~~~~~~~~~
D:\Arduino\Read_TMCC\TMCCSerial.h:24:6: note:   no known conversion for argument 1 from 'Serial_*' to 'HardwareSerial*'

exit status 1

Compilation error: no matching function for call to 'TMCCSerialClass::begin(Serial_*)'

Based on the “no known conversion message” it looks like maybe you’re missing a library. Total WAG on my part though.

@rplst8 posted:

Based on the “no known conversion message” it looks like maybe you’re missing a library. Total WAG on my part though.

That's kinda' what I thought, but I have no idea which library I might need.

@gunrunnerjohn posted:

That's kinda' what I thought, but I have no idea which library I might need.

Is there a software serial library?

Can you figure out what to change on the sketch?

MONITOR_PORT is the serial port connected to the TMCC data stream. (as helpfully noted in the comment following the definition )

"Serial" on the 32U4 boards is the built-in USB interface.  You're not somehow connecting that to the TMCC stream, are you? Assuming you are using the UART pins to connect, you would want to change "Serial" to "Serial1" in the definition of MONITOR_PORT.

This sketch was stripped down from the one built for the Moteino, which has only one hardware serial port ("Serial"). So in the original the hardware serial port is used for the TMCC interface, and software serial for debugging on the PC.

@Professor Chaos posted:

MONITOR_PORT is the serial port connected to the TMCC data stream. (as helpfully noted in the comment following the definition )

"Serial" on the 32U4 boards is the built-in USB interface.  You're not somehow connecting that to the TMCC stream, are you?

Assuming you are using the UART to connect, you would want to change "Serial" to "Serial1" in the definition of MONITOR_PORT.

I didn't change anything in the files, just compiled them.  I would be using the UART to connect to the serial stream.  I just changed the board to the 32U4 from the Arduino Nano and compiled again.

Where is the definition of Serial1?  I couldn't find it anywhere.  It compiles for the 32U4 board with that change, just wanted to know where that definition comes from.

Not sure where the definitive documentation is, but this page shows the serial definitions for the official boards - the Leonardo and Micro are 32U4 based.

Exactly where the pins are mapped in the guts of the board definitions... no idea!

The error you're seeing is because if you compile the unmodified sketch to a 32U4, you are essentially trying to pass a reference to a USB port ("Serial" on the 32U4) to a function that is expecting a UART.  

@gunrunnerjohn posted:

I didn't change anything in the files, just compiled them.  I would be using the UART to connect to the serial stream.  I just changed the board to the 32U4 from the Arduino Nano and compiled again.

Where is the definition of Serial1?  I couldn't find it anywhere.  It compiles for the 32U4 board with that change, just wanted to know where that definition comes from.

Hi John

Can you share your working version? Do you have any insight as to what variables you change in the sketch?

@Professor Chaos posted:

Not sure where the definitive documentation is, but this page shows the serial definitions for the official boards - the Leonardo and Micro are 32U4 based.

Exactly where the pins are mapped in the guts of the board definitions... no idea!

The error you're seeing is because if you compile the unmodified sketch to a 32U4, you are essentially trying to pass a reference to a USB port ("Serial" on the 32U4) to a function that is expecting a UART.  

I was curious where that specific symbol was defined, I couldn't find it anywhere.  However, that table at least tells me what maps to what, that was the primary goal.  Apparently, the actual symbol is buried in the basic Arduino code generation.

If you're using the USB as your debug output, what application do you have on the other end to display the debug output?

I see this in that page you referenced.

You can use the Arduino environment’s built-in serial monitor to communicate with an Arduino board. Click the serial monitor button in the toolbar and select the same baud rate used in the call to begin().

That implies I can do this in the IDE, correct?

@Pu239 posted:

Hi John

Can you share your working version? Do you have any insight as to what variables you change in the sketch?

The only thing I changed is I removed the reference to PDI.h as I'm not going to be using it that way.  I also changed the Serial to Serial1, that allows it to compile error-free with the Pololu A-Star 32U4 board specified.  The only files I'm using are...

My goal is to get the code running using the command base serial output at 9600 BPS, then move it to the R2LC output serial data and get it working at the oddball 3000 BPS internal data rate.  Once I sort that out, I will start adding features for the intended tasks.

@gunrunnerjohn posted:

The only thing I changed is I removed the reference to PDI.h as I'm not going to be using it that way.  I also changed the Serial to Serial1, that allows it to compile error-free with the Pololu A-Star 32U4 board specified.  The only files I'm using are...

My goal is to get the code running using the command base serial output at 9600 BPS, then move it to the R2LC output serial data and get it working at the oddball 3000 BPS internal data rate.  Once I sort that out, I will start adding features for the intended tasks.

Sounds good, when I’m free this weekend, I plan on doing some testing via a R2LC.

Id be nice to somehow use an arduino as a R2lc. I guess it would need a radio receiver attached.

I know you were developing a replacement on your own, but arduino seems like a good fit or am I not on the right track?

@Pu239 posted:

Sounds good, when I’m free this weekend, I plan on doing some testing via a R2LC.

Id be nice to somehow use an arduino as a R2lc. I guess it would need a radio receiver attached.

I know you were developing a replacement on your own, but arduino seems like a good fit or am I not on the right track?

There's a lot more than the serial data processing to the R2LC.  You need the power supply, the drivers for the various outputs, the 455khz FM receiver, etc.  My goal with the TMCC serial data receiver is to drive other functions using the serial data from the TMCC receiver.  I'll probably build a sandwich using the Pololu A-Star 32U4 board and a motherboard that has the necessary support hardware.  The concept is the same as my MP3 board that uses a commercial MP3 decoder with a micro-SD reader and the 1527 learning code receiver.  My board provides the glue to hold it all together and interface it to the outside world, power, optical isolation for input conditioning, configuration jumpers, etc.

@gunrunnerjohn posted:

I was curious where that specific symbol was defined, I couldn't find it anywhere.  However, that table at least tells me what maps to what, that was the primary goal.  Apparently, the actual symbol is buried in the basic Arduino code generation.

If you're using the USB as your debug output, what application do you have on the other end to display the debug output?

I see this in that page you referenced.

You can use the Arduino environment’s built-in serial monitor to communicate with an Arduino board. Click the serial monitor button in the toolbar and select the same baud rate used in the call to begin().

That implies I can do this in the IDE, correct?

Yes, I usually use the IDE's serial monitor if the debugging port is the same as the programming one. If it's SoftwareSerial for debugging I use a USB-TTL cable and a serial terminal program.

Just for fun I hunted down the definition of the serial ports. The files are in the Arduino15 folder, location dependent on your OS.

Serial1 is defined in packages/arduino/hardware/avr/1.8.6/cores/arduino/HardwareSerial1.cpp:

HardwareSerial Serial1(&UBRR1H, &UBRR1L, &UCSR1A, &UCSR1B, &UCSR1C, &UDR1);

Those register locations are defined per processor; for the 32U4 it is in packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/avr/include/avr/iom32u4.h

@Professor Chaos posted:

Just for fun I hunted down the definition of the serial ports. The files are in the Arduino15 folder, location dependent on your OS.

Serial1 is defined in packages/arduino/hardware/avr/1.8.6/cores/arduino/HardwareSerial1.cpp:

HardwareSerial Serial1(&UBRR1H, &UBRR1L, &UCSR1A, &UCSR1B, &UCSR1C, &UDR1);

Those register locations are defined per processor; for the 32U4 it is in packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/avr/include/avr/iom32u4.h

Ah ha, I was grepping the headers, and didn't find Serial1.

It wasn't in the place you specified, AAMOF, there's two identically named files, and they are quite different.

@Professor Chaos posted:

Yes, I usually use the IDE's serial monitor if the debugging port is the same as the programming one. If it's SoftwareSerial for debugging I use a USB-TTL cable and a serial terminal program.

Any reason I can't use the IDE serial monitor until I want this to be stand-alone?  Obviously, once I go stand-alone, I'll have to switch gears to use the SoftwareSerial for the debug output.

How do I change from SoftwareSerial to the IDE serial monitor?

@gunrunnerjohn posted:

Any reason I can't use the IDE serial monitor until I want this to be stand-alone?  Obviously, once I go stand-alone, I'll have to switch gears to use the SoftwareSerial for the debug output.

How do I change from SoftwareSerial to the IDE serial monitor?

To output debugging info over the USB connection of the 32U4, you should be able to just change this line:

SoftwareSerial debugSerial (15, 14); // or use second hardware serial port if available

to:

#define debugSerial Serial

and of course you can delete the include of SoftwareSerial.h.

Would this work? I know it’s going to need refined for our purpose.

int in = 0;                   // Variable to store the desired value
byte pinOut = 10;             // PWM output pin

void setup() {                // This executes once
  Serial.begin(9600);             // Initialize serial port
  pinMode(pinOut, OUTPUT);        // Prepare output pin
}

void loop() {                 // This loops continuously
  if(Serial.available()){         // Check if there's data
    in = Serial.read();           // Read said data into the variable "in"
    analogWrite(pinOut, in);      // Pass the value of "in" to the pin
  }
}

Or maybe like this? Would need an argument for the actual serial data, if serial sees x then turn on y.

const int stepsPerRevolution = 1500;
int incomingByte;
Stepper myStepper(stepsPerRevolution, 11, 9, 10, 8);

void setup() {
  myStepper.setSpeed(20);
  Serial.begin(9600);
}

void loop() {
  if (Serial.available() > 0) {
    // read the incoming byte:
    incomingByte = Serial.read();
    Serial.print("I received: ");
    Serial.println(incomingByte);
      if (incomingByte = "1") {
        Serial.println("Moving clockwise...");
        myStepper.step(stepsPerRevolution);
        delay(500);
      }
      if (incomingByte = "2") {

@Professor Chaos posted:

To output debugging info over the USB connection of the 32U4, you should be able to just change this line:

SoftwareSerial debugSerial (15, 14); // or use second hardware serial port if available

to:

#define debugSerial Serial

and of course you can delete the include of SoftwareSerial.h.

Actually, I'll make it a conditional since I may want the use the software serial option when I get it all working on the bench with the computer.

Thanks!  Now I just have to see if the 3,000 BPS actually works for the Arduino UART...   I'm still waiting on the order for these boards, love the fact that they're only .6" x 1.0", and very thin.  Perfect for embedded use.

@Pu239 posted:

Would this work? I know it’s going to need refined for our purpose.

What's "our purpose"?  I know my purpose is to decode serial commands to activate actions in a locomotive and rolling stock.  I don't see how that code is what I'll need.

@gunrunnerjohn posted:

What's "our purpose"?  I know my purpose is to decode serial commands to activate actions in a locomotive and rolling stock.  I don't see how that code is what I'll need.

Mine is the same purpose. I will just sit back and hopefully you guys can figure it out. I’m out of my depth I guess. Just trying to help.

If I could fit a PLC into a engine, this would be easy for me. I have the serial on the cab2 base already interfaced into a PLC, so I can issue commands to engines and use my HMI to throw switches.

@Pu239 posted:

Mine is the same purpose. I will just sit back and hopefully you guys can figure it out. I’m out of my depth I guess. Just trying to help.

If I could fit a PLC into a engine, this would be easy for me. I have the serial on the cab2 base already interfaced into a PLC, so I can issue commands to engines and use my HMI to throw switches.

Well, I think that @Professor Chaos did the heavy lifting and figured it out.  I'm just trying to do some fine tuning.  My final question mark is if the USART will use non-standard baud rates.  I know it'll compile them, but all I read says it won't use them.  All of this is for naught if I can't read the serial data coming from the R2LC.

@gunrunnerjohn posted:

Well, I think that @Professor Chaos did the heavy lifting and figured it out.  I'm just trying to do some fine tuning.  My final question mark is if the USART will use non-standard baud rates.  I know it'll compile them, but all I read says it won't use them.  All of this is for naught if I can't read the serial data coming from the R2LC.

Very true. I thought it was bytes per second, so as long as both know the speed it should work right? I wish lionel would engineer a replacement to the r2lc, it’s not like they will not be needed in the future. I’m glad my rate of buying engines is slow due to the collection being 99% complete, but there needs to be a path to the future. If MTH keeps making the ps 2/3 upgrade, they will be the go to for repairs/ upgrades.

@gunrunnerjohn posted:

Well, I think that @Professor Chaos did the heavy lifting and figured it out.  I'm just trying to do some fine tuning.  My final question mark is if the USART will use non-standard baud rates.  I know it'll compile them, but all I read says it won't use them.  All of this is for naught if I can't read the serial data coming from the R2LC.

John, where have you read that a non-standard baud rate won't work for hardware serial?

I've never tried it, but the AVR UART should be able to do 3000.

@Professor Chaos posted:

John, where have you read that a non-standard baud rate won't work for hardware serial?

I've never tried it, but the AVR UART should be able to do 3000.

I did a search and came across multiple folks complaining about not being able to use other than standard baud rates.  I never found a definitive statement that says it won't, but then I didn't find one that said it would.

I have no doubt the UART can do it, but it's all about what the Arduino serial port code allows I would expect.

If I assume 8mhz for a clock rate, it appears the hardware of the processor can generate a 3031 baud rate, certainly close enough to 3,000 to async reception.  So, I guess in the worst case, I hand stuff the baud rate numbers into the registers, I can get it to do the rate I need.

I did a little spread sheet, actually I can get even closer if I can use other clock speeds.  I didn't find anything in the A-Star 32U4 User Guide about the default clock speed for that board, but I assume any clock speed it runs at will be close enough.

So I guess this is probably doable after all!