Prototype Lionel/TMCC Controller

That's way cool, now you just have to figure how to get it into a handheld version with an RF link.

@gunrunnerjohn posted:

That's way cool, now you just have to figure how to get it into a handheld version with an RF link.

I bet such an effort could easily be funded by Kickstarter etc.  You're not talking a ton of money being that the code is open sourced and there's a working prototype already.  The hardest part is already done!

Kudos, Dave.  I don't think people realize yet what a big deal this is.  You may have opened up a whole new segment of the hobby as there are a bunch of Gen Xers like myself who have worked a whole career in technology and are approaching retirement.  A lot of us will want to play with different projects like this after "real work" is over to keep our tech skills and minds sharp.

@BlueFeather posted:

I bet such an effort could easily be funded by Kickstarter etc.  You're not talking a ton of money being that the code is open sourced and there's a working prototype already.  The hardest part is already done!

Kudos, Dave.  I don't think people realize yet what a big deal this is.  You may have opened up a whole new segment of the hobby as there are a bunch of Gen Xers like myself who have worked a whole career in technology and are approaching retirement.  A lot of us will want to play with different projects like this after "real work" is over to keep our tech skills and minds sharp.

I am a retired "boomer" who just can't stop developing code . I started my professional career in software development in 1979. I've been fortunate to find many opportunities to continue plying my trade since retirement, mostly volunteering for organizations I believe in. This is my second larger-scale personal project, and I have to say, it's been a ton of fun. One of my professional specialties was integration; connecting software platforms that weren't designed to be interconnected. Those skills served me well here, as even with the Lionel partner documentation, a lot of things had to be figured out using network sniffing tools (Wireshark) and trial and error. I am particularly happy that the code runs so well on inexpensive Raspberry Pi's!

There is still a lot more to be done. I really need to add more documentation and get this codebase up on PyPi. Putting it up on that platform will make installation a lot easier for those that just want to use the software (and not develop/hack with it). I also need to add support for Lionel's new 4 digit addressing. I understand how they are doing it, I just need to implement it...

Thank you for your post!

  -- Dave

@gunrunnerjohn posted:

That's way cool, now you just have to figure how to get it into a handheld version with an RF link.

The RF link is easy; WiFi! And I've seen Pi's that run off of 3-4 AA batteries, although I have no idea how long you could run before you needed new batteries. The main challenge would be fabricating the case and coming up with a touch-screen GUI, like the Cab 2/Cab 3 that could reconfigure based on what the user wanted to do.

Huh, will you look at this: https://www.amazon.com/dp/B08C...typ_imgToDp&th=1. A $20 touch screen that works with a Raspberry Pi!. It arrives next Tuesday

  -- Dave

Incredible work.  Hopefully some others can enter the project on the hardware side to integrate it into a handheld size.  This has been my plan from the beginning, but I haven't hit retirement yet, so time is scarce.

I like where you're headed with the touch screen.  I (and others I assume) would be quite content with a cab2-like form factor that includes cab3 functions and is made from non-discontinued electronics.  I would probably opt for a capacitive touch screen, and keep a partial overlay grid for easier eyes-free tactile operation.

I'll tag in if/when time allows, but I'm just as content to watch from the sidelines.

@cdswindell posted:

I figured this deserved its own post . I've completed my prototype controller that uses my Python code to control a Lionel layout. The software runs on (relatively) inexpensive Raspberry Pi computers, and the components in the control panel itself mostly came from Amazon. Excluding the Pi, there is less that $100 in parts in the picture below.

Here is a photo of the controller, all powered up:

I also have software support for a Train Brake, but I didn't leave enough space on my panel for it. I'm also missing one physical button, which will send the Engine Reset command when pressed.

The switches are all (on)-off-(on) momentary contact. The labels are self-evident, except for the boost and brake switch. If held in the up or down position, the boost or brake command is sent repeatedly, resulting in the selected engine/train speeding up or down, until the switch is released, at which point, the engine returns to its normal speed.

The "quilling horn" command is a simple linear pot that sends the "quilling horn" command with a value of 1 - 15, depending on how far up the lever is moved. When you return the lever to the bottom, the horn stops. Similarly, the Bell button results in a single ding if pressed and released, or uf held, turns the bell on or off, just like the Lionel Cab 2 and Cab 3. The Horn button blows the horn for as long as the button is depressed.

Here is a video that shows the panel at work: https://youtube.com/shorts/8Lv...?si=mD6XoV8rb7_KgIL6. I apologize in advance that it looks like a beaver with an overbite cut out the opening for the LCD display

In January, I'm working with a group in Lower, MA, Stephan Lamb Associates, to fabricate a nice looking panel I will place on my layout. They built my layout, and I couldn't be happier with their team and their work. In fact, I am going to have them build me a handful of panels to operate my Gantry Crane, Rocket Pad, Culvert loader & unloader, etc, as well as the generalized engine/train controller you see above. The accessory-specific panels will each contain a small Pi (probably a Pi 4 or a Pi Zero 2W), and will have the TMCC ID of the accessory they control "burned into" the code, rather than be selectable, as you see on the panel above.

I'm excited to be moving from the development stage into the control panel building stage!

  -- Dave

This is great! Do any of the buttons control smoke on/smoke off and fire the couplers as well, or are those for a future version?

Outstanding Work!

Reading through the notes... noticed python 3.13 is not supported (as of a couple of months ago).   Is that is still the case?   It's not an issue... just curious.

@Dynamo2112 posted:

This is great! Do any of the buttons control smoke on/smoke off and fire the couplers as well, or are those for a future version?

Yes. You can fire the front and rear coupler, as well as turn smoke on and off. I ran out of room on my panel, but the software support to do those things is in place with what I’ve checked in.

Yes. You can fire the front and rear coupler, as well as turn smoke on and off. I ran out of room on my panel, but the software support to do those things is in place with what I’ve checked in.

The real gating factor are the number of pins on the raspberry pi. I have to double check, but I think I only have two open pins at the moment. Of course, you could make other choices for how you allocate switches and, say, give up volume control, or labor effects to free up more pins.

  — Dave

@Dennis-LaRock posted:

Outstanding Work!

Reading through the notes... noticed python 3.13 is not supported (as of a couple of months ago).   Is that is still the case?   It's not an issue... just curious.

I got rid of my last class property last night. This lets the code compile under Python 3.13. However, the pi’s Only support 3.11 currently. Also, the lgpio Library that I rely on doesn’t seem to compile under 3.13 yet.

Thanks Dave!  I'll reconfigure the pi and hopefully begin a little testing this weekend.

Btw, here is the one line of code a user would need to write to support the controller shown above:

GpioHandler.controller(
 keypad_address=0x20,
 speed_pins=[17, 27],
 halt_pin=10,
 start_up_pin=21,
 shutdown_pin=20,
 boost_pin=15,
 brake_pin=14,
 fwd_pin=16,
 rev_pin=12,
 rpm_up_pin=8,
 rpm_down_pin=7,
 labor_up_pin=24,
 labor_down_pin=25,
 vol_up_pin=26,
 vol_down_pin=19,
 tower_dialog_pin=13,
 engr_dialog_pin=6,
 quilling_horn_chn=0,
 base_online_pin=23,
 base_offline_pin=4,
 lcd_address=0x27,
 lcd_rows=4,
 lcd_cols=20,
)

There are also arguments for reset, horn, bell, smoke on/off, couplers, and train brake. I will probably add arguments to support the six "official railroad speed" as well as roll, and stop immediate. I could add options for lighting controls too (ditch, mars, etc), but that feels like overkill...

As I've mentioned, the real limitation are the number of pins on the Pi that you can connect switches/buttons to. Of course, you could always put another Pi in the control panel and slave it to the master...

  -- Dave

@gunrunnerjohn posted:

That's way cool, now you just have to figure how to get it into a handheld version with an RF link.

OK John, The JWA Remote... the 15 minute design version is pretty darned rough but it's easy enough to soften the edges and add some artdeco detailing.  It's is on the build plate... and, will be done printing this afternoon.

So what about the guts? What switches/triggers/pots/displays etc?  Anyone have any idea about what would fit to make it work?  For a prototype skip the batteries and just use a walwart to see if it can be done... and, later used as the charger if the thing actually worked.

@cdswindell posted:

The real gating factor are the number of pins on the raspberry pi. I have to double check, but I think I only have two open pins at the moment. Of course, you could make other choices for how you allocate switches and, say, give up volume control, or labor effects to free up more pins.

You can also use something like SPI to handle an addressable input mux register like the 74HC165 to add inputs without the complexity of adding another Raspberry PI.

@gunrunnerjohn posted:

You can also use something like SPI to handle an addressable input mux register like the 74HC165 to add inputs without the complexity of adding another Raspberry PI.

True. I'me using the I2C bus to drive the keypad, which otherwise would have consumed 8 pins! Do you know if there is a way to support discrete buttons via SPI or I2C? I've only seen how to use them with matrix devices (keypad).

Interestingly enough, because of the client/server capability I support, using multiple Pi's isn't actually very complex at all. This is especially so if you are just handling simple button presses (as opposed to polling a pot or listening for broadcasts from a Base 3 or Ser 2). And with Pi Zero 2 W's at $25, it is pretty inexpensive as well...

  -- Dave

@Dennis-LaRock posted:

OK John, The JWA Remote... the 15 minute design version is pretty darned rough but it's easy enough to soften the edges and add some artdeco detailing.  It's is on the build plate... and, will be done printing this afternoon.

So what about the guts? What switches/triggers/pots/displays etc?  Anyone have any idea about what would fit to make it work?  For a prototype skip the batteries and just use a walwart to see if it can be done... and, later used as the charger if the thing actually worked.

The 4 line LCD display I'm using is 1.5" by 3.75", and the matrix keypad is 2.25" by 2.5". What's the dimensions of the 2 large openings?

Upper is, 34x50mm - 1.34" x 1.97"

Lower is, 40x50mm - 1.57" x 1.97"

The dimensions are rough (but, close) measurements of the Cab2.  A few mm one way or another wouldn't matter.  We would need some 'tiny' parts!

I'd probably look for the display(s) first and then size the remote to the display.  The multi-purpose controls that Lionel used on the CAB2 might be somewhat hard to duplicate.

I personally like the idea of a touchscreen remote (which allows for soft buttons which can do many things, like the CAB3 phone software) *plus* dedicated, quality hardware control for throttle, whistle / horn, brake / boost, and maybe other critical functions.  It doesn't necessarily have to be sized like a CAB2 -- maybe base the design around an integrated tablet-sized touchscreen.  That larger format makes integration of WiFi, rechargeable batteries, more components, etc. a lot easier.

Just thinking out loud.  Literally anything is possible with this software stack!

@cdswindell posted:

True. I'me using the I2C bus to drive the keypad, which otherwise would have consumed 8 pins! Do you know if there is a way to support discrete buttons via SPI or I2C? I've only seen how to use them with matrix devices (keypad).

Interestingly enough, because of the client/server capability I support, using multiple Pi's isn't actually very complex at all. This is especially so if you are just handling simple button presses (as opposed to polling a pot or listening for broadcasts from a Base 3 or Ser 2). And with Pi Zero 2 W's at $25, it is pretty inexpensive as well...

  -- Dave

What about something like the MCP23017?  That would seem to be a much cheaper and more compact solution than a complete new PI board.

@BlueFeather posted:

I personally like the idea of a touchscreen remote (which allows for soft buttons which can do many things, like the CAB3 phone software) *plus* dedicated, quality hardware control for throttle, whistle / horn, brake / boost, and maybe other critical functions.  It doesn't necessarily have to be sized like a CAB2 -- maybe base the design around an integrated tablet-sized touchscreen.  That larger format makes integration of WiFi, rechargeable batteries, more components, etc. a lot easier.

Just thinking out loud.  Literally anything is possible with this software stack!

Agreed!

The Cab2 was just a place to start.  I just fitted Dave's displays to it... moved a few buttons around and came up with the same height and increased the width by 12mm.  Overall it's H240mm, W112mm at top narrowing to 85mm at hand placement.

@gunrunnerjohn posted:

What about something like the MCP23017?  That would seem to be a much cheaper and more compact solution than a complete new PI board.

I just ordered 3 of these, at about $3 apiece: https://hobbycomponents.com/ou...igital-port-expander.

Looks like the same idea but with just 12 ports.

Thanks John,

  -- Dave

@BlueFeather posted:

I personally like the idea of a touchscreen remote (which allows for soft buttons which can do many things, like the CAB3 phone software) *plus* dedicated, quality hardware control for throttle, whistle / horn, brake / boost, and maybe other critical functions.  It doesn't necessarily have to be sized like a CAB2 -- maybe base the design around an integrated tablet-sized touchscreen.  That larger format makes integration of WiFi, rechargeable batteries, more components, etc. a lot easier.

Just thinking out loud.  Literally anything is possible with this software stack!

I have a couple of touch screens on order. You are correct about the details just being a software issue, but make no mistake, it will take a bit of software!! One of the shortcuts I took was to use components that did not have configurable UI components. The function of each control could be clearly specified by a simple label. As soon as you switch to a touch screen, which I agree would be preferable for a handheld, you actually have to design a GUI (graphical user interface) and then implement that in software (like the Cab 3).

The OLED screens I looked at had pretty primitive libraries, offering only line drawing and character output primitives. There would be a bit of work needed to design a middle layer to build up the primatives needed for easy train control.

Would make a fun follow-on project for what I've done!!

  -- Dave

@cdswindell posted:

I just ordered 3 of these, at about $3 apiece: https://hobbycomponents.com/ou...igital-port-expander.

Looks like the same idea but with just 12 ports.

Thanks John,

  -- Dave

Yep, it gives you all the buttons you want.

@cdswindell posted:

I figured this deserved its own post . I've completed my prototype controller that uses my Python code to control a Lionel layout. The software runs on (relatively) inexpensive Raspberry Pi computers, and the components in the control panel itself mostly came from Amazon. Excluding the Pi, there is less that $100 in parts in the picture below.

Here is a photo of the controller, all powered up:

I also have software support for a Train Brake, but I didn't leave enough space on my panel for it. I'm also missing one physical button, which will send the Engine Reset command when pressed.

The switches are all (on)-off-(on) momentary contact. The labels are self-evident, except for the boost and brake switch. If held in the up or down position, the boost or brake command is sent repeatedly, resulting in the selected engine/train speeding up or down, until the switch is released, at which point, the engine returns to its normal speed.

The "quilling horn" command is a simple linear pot that sends the "quilling horn" command with a value of 1 - 15, depending on how far up the lever is moved. When you return the lever to the bottom, the horn stops. Similarly, the Bell button results in a single ding if pressed and released, or uf held, turns the bell on or off, just like the Lionel Cab 2 and Cab 3. The Horn button blows the horn for as long as the button is depressed.

Here is a video that shows the panel at work: https://youtube.com/shorts/8Lv...?si=mD6XoV8rb7_KgIL6. I apologize in advance that it looks like a beaver with an overbite cut out the opening for the LCD display

In January, I'm working with a group in Lower, MA, Stephan Lamb Associates, to fabricate a nice looking panel I will place on my layout. They built my layout, and I couldn't be happier with their team and their work. In fact, I am going to have them build me a handful of panels to operate my Gantry Crane, Rocket Pad, Culvert loader & unloader, etc, as well as the generalized engine/train controller you see above. The accessory-specific panels will each contain a small Pi (probably a Pi 4 or a Pi Zero 2W), and will have the TMCC ID of the accessory they control "burned into" the code, rather than be selectable, as you see on the panel above.

I'm excited to be moving from the development stage into the control panel building stage!

  -- Dave

HEY DAVE,

I'm really interested in your UNIT!  Curious, how is this UNIT interfaced with yout BASE3?

FREDSTRAINS

@Fredstrains posted:

HEY DAVE,

I'm really interested in your UNIT!  Curious, how is this UNIT interfaced with yout BASE3?

FREDSTRAINS

Fred, the panel uses WiFi to communicate with the Base 3 and, optionally, a USB serial cable to connect to an LCS Ser 2. A Ser2 is needed if you also want to control your layout with a Cab 2 or Cab 3, as the Base 3 does not echo out all received commands, at least with Firmware Rev 1.28. Lionel just dropped a new release that I haven't tested yet. If it broadcasts more commands, the Ser 2 won't be needed.

  -- Dave

@cdswindell posted:

Fred, the panel uses WiFi to communicate with the Base 3 and, optionally, a USB serial cable to connect to an LCS Ser 2. A Ser2 is needed if you also want to control your layout with a Cab 2 or Cab 3, as the Base 3 does not echo out all received commands, at least with Firmware Rev 1.28. Lionel just dropped a new release that I haven't tested yet. If it broadcasts more commands, the Ser 2 won't be needed.

  -- Dave

@Fredstrains, I just tried Firmware 1.32 and confirmed you would still want a Ser2 to keep state in Sync. The Base 3 seems to broadcast some state change information, like when speed or direction change. However others, like manual changes to RPM and effort levels, or smoke levels, are not broadcast out by the Base 3, and my stuff has no idea the changes happened. Since all of these state changes are broadcast out the serial connection (from an LCS Ser2), I would recommend having one connected to the PyTrain server so everything is in sync.

Maybe one day, Lionel will change this behavior and echo all changes out from the Base 3...

  -- Dave

@gunrunnerjohn posted:

What about something like the MCP23017?  That would seem to be a much cheaper and more compact solution than a complete new PI board.

@gunrunnerjohn

Gees, I must be getting old. It turns out, I was already using an I2C port expander! I was using one to drive the 4x4 keypad. I just never realized it could be used in a discrete way to read individual button presses.

I will google, but do you know off hand if there is a practical limit to the number of I2C modules you can chain together? I can't see using more than 4 (LCD driver, Matrix Keypad, ADS 1115 ADC, and a port expander), but I'd like to know...

Thanks,

  -- Dave

Pretty sure you can connect any reasonable number of 12C modules to a single processor port.

@cdswindell posted:

I have a couple of touch screens on order. You are correct about the details just being a software issue, but make no mistake, it will take a bit of software!! One of the shortcuts I took was to use components that did not have configurable UI components. The function of each control could be clearly specified by a simple label. As soon as you switch to a touch screen, which I agree would be preferable for a handheld, you actually have to design a GUI (graphical user interface) and then implement that in software (like the Cab 3).

The OLED screens I looked at had pretty primitive libraries, offering only line drawing and character output primitives. There would be a bit of work needed to design a middle layer to build up the primatives needed for easy train control.

Would make a fun follow-on project for what I've done!!

  -- Dave

I think there are some pretty straight forward options for a GUI that integrates nicely with Python.  I've used pyQt and pySide, but my current favorite is kivy.  It has build-in touch screen support and a decent library of widgets.  The hardest part for me has always been getting Linux to auto-start and display the thing, get rid of the cursor, turn the screensaver off, but all that's just a few google searches away.

I spent some time thinking about how it might be laid out a while back, and while it would be straight forward to try and replicate the cab2 or cab3 layout, I imagined a fairly simple window class that has an information area at the top and a button array at the bottom.  I think with today's screens, there is no need to have two separate ones.  I figure each type of TMCC/Legacy control object could subclass that abstract screen with all the appropriate information and buttons.  Then the user could add a new "tab" for each item they want to control and possibly have some physical buttons to scroll through each of the tabs.  Perhaps these could optionally be added to a "favorites" list in order to have them auto-generated each time the controller is booted.

I think with a high quality encoder wheel, a well thought out touch screen display, and a nice feeling whistle/horn slider, (and a handful of other common buttons) this thing could have a way better user experience than the cab3 and possibly even the cab2.  Also, I don't think one would need to reproduce the cab3 functionality entirely.  Personally, I'm perfectly happy using the cab3 app to configure and set things up initially (new engines, accessories, etc.)