I dont know what version you are using but MTS3 can operate 28/128 sped steps.
Raspberry Pi Zero Controlling Things
- Thread starter John Russo
- Start date
Well, yes, but not with LGB MTS equipment (LGB Throttles). (Yes, I have an MTS3 Central Station) The Central Station can operate with 28/128 speed steps IF you use a Massoth controller. If you have only LGB equipment (55016 or 55015, even with both parallel capability) you are still in the 14 speed step range. That is the PITA I was mentioning. Like the little side effect of no lights (or, I have heard, lights on and off according to which speed step you request) when an LGB decoder is set for 14 speed steps.
And why I am building a Central Station that operates JMRI.
Last edited:
Didn't mean to wait 2 weeks before reporting in. High current H-bridge working fine, as is my loco with 22027 decoder that was having issues when set to 14 speed steps. Lights and all work as expected.
New task is to duplicate a 'newer' LGB 55090 Booster Module (with the ability to provide particular speed step directions (Stop being one of them) so they can work with a 55063 (MTS Braking Module). All that is needed from the 'newer' 55090 Booster Module is the ability to send a "stop" or particular speed step command to the block it is controlling. My goal is to create an Arduino controller that, with a switch (again, the 55063), can output "stop", or particular "speed step" commands to emulate the newer 55090.
The functionality, combined with the 55063, are enjoyable. Since LGB and Massoth will not help, I'll do it myself!!
New task is to duplicate a 'newer' LGB 55090 Booster Module (with the ability to provide particular speed step directions (Stop being one of them) so they can work with a 55063 (MTS Braking Module). All that is needed from the 'newer' 55090 Booster Module is the ability to send a "stop" or particular speed step command to the block it is controlling. My goal is to create an Arduino controller that, with a switch (again, the 55063), can output "stop", or particular "speed step" commands to emulate the newer 55090.
The functionality, combined with the 55063, are enjoyable. Since LGB and Massoth will not help, I'll do it myself!!
Last edited:
Not trying to derail, just understand, the 55090 is no longer made but it's sort of a programmable 5 amp booster, with the ability to send a stop or arbitrary speed command to any loco in the block? My understanding from reading the 55063 manual is that when used to send an arbitrary speed command, that was set in the 55090.
Is this your understanding too? (Also "newer" means 2004 on, right, although there is some mention that the 55063 box had a "coupon" that explained how to modify older 55090's)
Greg
Is this your understanding too? (Also "newer" means 2004 on, right, although there is some mention that the 55063 box had a "coupon" that explained how to modify older 55090's)
Greg
Yes, the "newer" 55090 did have a mode that could be selected to send a "broadcast" speed command to the block it was connected to. When combined with a 55063, a loco could be told to stop or slow down (or speed up, for that matter) after it was in the designated block (triggering the switchover from Central Station to 55090 by a reed switch).
The coupon you mention was to send in your "older" 55090 for an upgrade by Massoth. I have been told by Massoth dealers that they no longer perform the upgrade, so of my three 55090 units, only one has this functionality and the other two cannot be used with the 55063.
Greg
The coupon you mention was to send in your "older" 55090 for an upgrade by Massoth. I have been told by Massoth dealers that they no longer perform the upgrade, so of my three 55090 units, only one has this functionality and the other two cannot be used with the 55063.
Greg
It's a firmware upgrade. I do not have the firmware file and the upgraded chip appears to have the lock engaged. I can read the older units (I have a programmer) but cannot read the newer unit.
Greg
Greg
Well, I didn't contact Massoth directly, only dealers, so perhaps not totally thorough... there is only one "programmable" chip in the device, and it was obsolete many moons ago. Luckily, so am I 
. I was disappointed that the newer firmware appears to be locked. I was really hoping to solve the issue using my antiquated skills. Now I have to use my newer ones to re-invent the Massoth wheel, so to speak. As a side note, this experience has left a sour taste in my mouth regarding using Massoth products going forward. I have been in Customer Support (at the Engineering level) for 20+ years and really dislike a manufacturer that disassociates itself from its earlier products. Shows a certain lack of pride, in my opinion. But I digress...
. I was disappointed that the newer firmware appears to be locked. I was really hoping to solve the issue using my antiquated skills. Now I have to use my newer ones to re-invent the Massoth wheel, so to speak. As a side note, this experience has left a sour taste in my mouth regarding using Massoth products going forward. I have been in Customer Support (at the Engineering level) for 20+ years and really dislike a manufacturer that disassociates itself from its earlier products. Shows a certain lack of pride, in my opinion. But I digress...
Sorry for bumping an old post but I found this an awesome read... I am in the process of building an Arduino based DCC Command Station - ill try and create a step by step setup guide in case others are interested in doing something similar 
D
Deleted member 4232
Guest
Sorry if this a bit late.
I have tried a Rasberry PI zero as a controller for Rocrail- I.E, as the main "PC" running rocrail (not as a points/ sensor or loco decoder) It worked, but was rather too slow in my application, that required it to also run "Mosquitto" (MQTT broker) { the bit that interfaces messages sent over wifi and links them into rocrail for me}- so that my points/ track sensors and Wirelessly controlled loco all connect and Rocrail can control everything.
In my experience, the crucial failure of the PI was that the whole operating system and program is contained on one SD card, and if it crashes, (as mine did), you have to completely set up everything again.
In contrast, a simple and cheap old laptop PC is reliable and runs everything I need well.
FYI, I have "developed" a very inexpensive set of wireless components for use with Rocrail. They are all based on NodeMCU "ESP8266" boards, readily available at around £5 each.
There is one program that makes the board into a universal 8 i/o "Static" unit for points, lights and track sensors, and another one for "Mobile" (LOCO" applications, where it acts as a decoder (With twin track sampled sounds, including synchronised chuffs).
There are descriptions of everything on my Rocrail user page, Dagnall53 ESP8266
There is a video here of the loco demonstrating some of the sounds and control over a tablet.
The overall system is shown below.
Some examples of the hardware, NodeMCU on "motor drive card" for "Static" version 8 i/o on the left, Wemos + motor drive for loco "Mobile" on the right.
I have tried a Rasberry PI zero as a controller for Rocrail- I.E, as the main "PC" running rocrail (not as a points/ sensor or loco decoder) It worked, but was rather too slow in my application, that required it to also run "Mosquitto" (MQTT broker) { the bit that interfaces messages sent over wifi and links them into rocrail for me}- so that my points/ track sensors and Wirelessly controlled loco all connect and Rocrail can control everything.
In my experience, the crucial failure of the PI was that the whole operating system and program is contained on one SD card, and if it crashes, (as mine did), you have to completely set up everything again.
In contrast, a simple and cheap old laptop PC is reliable and runs everything I need well.
FYI, I have "developed" a very inexpensive set of wireless components for use with Rocrail. They are all based on NodeMCU "ESP8266" boards, readily available at around £5 each.
There is one program that makes the board into a universal 8 i/o "Static" unit for points, lights and track sensors, and another one for "Mobile" (LOCO" applications, where it acts as a decoder (With twin track sampled sounds, including synchronised chuffs).
There are descriptions of everything on my Rocrail user page, Dagnall53 ESP8266
There is a video here of the loco demonstrating some of the sounds and control over a tablet.
The overall system is shown below.
Some examples of the hardware, NodeMCU on "motor drive card" for "Static" version 8 i/o on the left, Wemos + motor drive for loco "Mobile" on the right.
Last edited:
D
Deleted member 4232
Guest
John,
re the PI, Zero, my limited experience with it shows its just too small for the task of fully running a railway, but its remarkable how close it comes at the price!
I understand the temptation/benefits to "just connect directly". In fact Rocrail has a whole set of Raspberry PI based "Rocnet" interfaces that do connect directly. There are some excellent and low cost interface boards available, and some very nice interfaces in Rocrail for setting the boards up etc. My main issue with them is that each PI on the network then needs separate boards for Track sensing, servo operation etc. - But you can have lots of these interfaces connected to each PI, so for physically small layouts, this is hardly a problem. You can even update the PI firmware from within RocRail.
My NodeMCU boards are aimed at a rather different situation, where each physically remote station on my garden track I can have a single low cost board to support a few track sensors and points servos (sufficient for a station). The reason for using MQTT as the interface and the extensive RocNet protocol is that by using existing standards I did not have to redo all the work that has gone into the interfaces and automatic train control etc that Rocrail already has. Because of the physical simplicity (and low cost of the hardware), each station has one ESP8266 and can be solar/battery powered and easily removed/moved. If the layout is very complex, I would recommend direct connection not WiFi, and probably to use the LocoNet, C-Bus or Rocnet interfaces. (Half of my layout (the bit in the shed) actually uses C-bus modules, and my track powered locos run from an C-Bus controller/booster).
If you just want a train or a few points controlled from a tablet, then using customised HTML is fine if you want to program it, but for sequences, automated scheduling, nice graphics, why repeat what has already been done??
ESP BASIC was new to me, but from what I see its an HTML based interpreter? so may have speed issues in comparison to the "normal" Arduino compiler approaches??
FYI my "Mobile" ESP based decoder was partly designed as a speed test for the ESP, and I was very pleased to find that it is able to simultaneously run two channels of speed synchronised digitised sampled audio, as well as doing all the WiFi PWM loco speed control and RocNet interface stuff (as I hope you can see from the linked video in my original post). By the way, because I used NMRA compatible "CV" locations, an additional "extra" from using standards was that you can use any programming interface to read and program the loco features.
I'm not connected to Rocrail, just a satisfied user! I tried JMRI, but ended up confused!
re the PI, Zero, my limited experience with it shows its just too small for the task of fully running a railway, but its remarkable how close it comes at the price!
I understand the temptation/benefits to "just connect directly". In fact Rocrail has a whole set of Raspberry PI based "Rocnet" interfaces that do connect directly. There are some excellent and low cost interface boards available, and some very nice interfaces in Rocrail for setting the boards up etc. My main issue with them is that each PI on the network then needs separate boards for Track sensing, servo operation etc. - But you can have lots of these interfaces connected to each PI, so for physically small layouts, this is hardly a problem. You can even update the PI firmware from within RocRail.
My NodeMCU boards are aimed at a rather different situation, where each physically remote station on my garden track I can have a single low cost board to support a few track sensors and points servos (sufficient for a station). The reason for using MQTT as the interface and the extensive RocNet protocol is that by using existing standards I did not have to redo all the work that has gone into the interfaces and automatic train control etc that Rocrail already has. Because of the physical simplicity (and low cost of the hardware), each station has one ESP8266 and can be solar/battery powered and easily removed/moved. If the layout is very complex, I would recommend direct connection not WiFi, and probably to use the LocoNet, C-Bus or Rocnet interfaces. (Half of my layout (the bit in the shed) actually uses C-bus modules, and my track powered locos run from an C-Bus controller/booster).
If you just want a train or a few points controlled from a tablet, then using customised HTML is fine if you want to program it, but for sequences, automated scheduling, nice graphics, why repeat what has already been done??
ESP BASIC was new to me, but from what I see its an HTML based interpreter? so may have speed issues in comparison to the "normal" Arduino compiler approaches??
FYI my "Mobile" ESP based decoder was partly designed as a speed test for the ESP, and I was very pleased to find that it is able to simultaneously run two channels of speed synchronised digitised sampled audio, as well as doing all the WiFi PWM loco speed control and RocNet interface stuff (as I hope you can see from the linked video in my original post). By the way, because I used NMRA compatible "CV" locations, an additional "extra" from using standards was that you can use any programming interface to read and program the loco features.
I'm not connected to Rocrail, just a satisfied user! I tried JMRI, but ended up confused!
D
Deleted member 4232
Guest
D
Deleted member 4232
Guest
D
Deleted member 4232
Guest
This on the surface seems to be what I am looking am after a method of displaying a train location on a track line drawing monitor, I do not use any power to the track. Basically train detected ( Dave Bodnar and others have done a lot of work on this with lasers and other type of sensors) - signal to Pi GPIO pin- Pi send info to JMRI or some other system running on an old PC (XP) or another Pi which draws the line and colours the occupied portion a different colour (Green vacant, Red occupied).
Just a thought on this; "SD Cards these really are a hit and miss affair, one option is just confine the "bootloader" to the SD card, and run everything else from an USB device." I am going through this at this very moment with my Pi and have been for nearly a month and its still ongoing. I will advise that if you attempt this be mindful that not all USB devices will work especially external HDDs (spin up time is the problem with mine) it has been recommended that I invest in an Solid State Drive to overcome this.
Just a thought on this; "SD Cards these really are a hit and miss affair, one option is just confine the "bootloader" to the SD card, and run everything else from an USB device." I am going through this at this very moment with my Pi and have been for nearly a month and its still ongoing. I will advise that if you attempt this be mindful that not all USB devices will work especially external HDDs (spin up time is the problem with mine) it has been recommended that I invest in an Solid State Drive to overcome this.