I accidentally ordered a roll of ABS filament (I had been using PLA) so that forced me to do a bit of tweaking on my 3d printer. Tried the glass bed with it, didn’t work very well. Ended up going back to the regular one but I don’t use painters tape anymore, just print right on the bed. Everything sticks fine although I’m not sure I like ABS for people. Anyhow, I have been meaning to post files of my people if anyone wants to play with them or 3d print. I use Makehuman to create them, Blender to pose em, Netfabb to seal the ‘holes’ and Cura to slice them for my Creality Ender 3. Almost all of these files are originals but I may have a few things I downloaded from thingiverse.com or something like that in there, they are just dumps of my 3d folders.

There are two zips, one has the blender files which are the ‘source’ files. You can load these into Blender and pose and sculpt them in various ways, then export them into stl or obj files for printing, that file is here:

blender.zip

The other one has already processed files, exported from blender ready to be loaded into a slicer for 3d printing. That zip is here:

3dpeopleOBJ.zip

Computer Lab

My current setup. Left to right. CHG computer, RaspberryPi development, ProxMox VE (repurposed PowerEdge), Windows 10 Fileserver, Ubuntu/Ansible box, printer, Windows 10 main machine, Solder/Lab area for model train controls, Ender3 3D printer.

In my quest to drive ever larger locomotives, here is my latest development rig. It is designed for both very large motors and DCC. It can drive motors up to about 50A and can also supply about 8A of DCC. It consists of the Protothrottle Receiver, the Syren50 50Amp motor controller, a SoundTraxx TSU2200 DCC decoder, a Cytron Amp for the DCC, a 5v buck converter (to power the rx), a power relay and two motor trucks. One of the trucks is driven with the Syren50 and the other is hooked to the TSU2200.

I am pretty close to a final release on this iteration. It includes a new ESC mode, PHYSICS, and four parameters for setting up acceleration/deceleration and braking with the Syren50 motor controller. The braking responds to the brake lever on the Protothrottle and has a variable rate. The brake function parameter sets which function code the brake effect reacts to. On the TSU, this is F11, so I’ve set that here to get the brake squeal sound out of the decoder.

With the exception of the Brake Function Code, all of the values are in milliseconds. These represent an increment or decrement of one throttle step every X milliseconds until it reaches the value sent by the Protothrottle. Low values closely follow the PT, larger values take more time to reach the PT value. The brake rate is similar, however it is affected by the amount of deflection of the Protothrottle’s brake lever. The more deflection, the more brake is applied.

Here is a video of it in action. Note that the acceleration/deceleration of the large motor block, tied to the Syren50, differs quite a bit from the acceleration values in the decoder controlled motor truck. In actual use, these would be ‘tweaked’ so the DCC and ESC rates match.

Protothrottle Dead Rail Receiver

So it turns out the newest Digi Xbee3 network radios can do good ole 802.15.4 packets just like the older S1s and S2Cs. But one REALLY COOL thing they can do that the old ones can’t (ok there are two cool things, but I’ll get to the second) is they can talk Bluetooth BLE. At the same time as the regular Xbee network. And what is really neat about that is that the messages appear on the serial port, thus my application firmware can get these, interpret them and do STUFF. All sorts of stuff like actually control the throttle AND configure the module. Oh, and the second really cool thing is they have microPython built in too! Not that I know what to do with that now but it’s just really COOL 🙂

So, first pic is one of my Android phones (that I don’t have service on). It shows the connection to the Xbee3 via BLE on my little Android App. It was a bit of challenge to get the Xbee Library in there and there are still a few kinks that I need to work out (I have a love/hate relationship with Android Studio) but you can see on the second shot that I am getting valid Xbee Packets coming into my Receiver Firmware. Last pic is my setup (I have a Syren50 now)

So now I can have one receiver that talks to the Protothrottle and my phone at the same time. Sweet! I can configure parameters with the phone, or even drive the locomotive. I can also get data back to the phone (with the appropriate sensors), like speed, battery status, position, etc.

The original Protothrottle Receiver was able to control an ESC, but it just output throttle value as is, no manipulation. In some implementations this could cause abrupt changes in speed. So I added a new ESC mode, ‘PHYSICS’. This allows a standard center off ESC to now have a programmable acceleration and deceleration value. I also added a brake function that you can set to any DCC function code on the PT. This will allow you to drive a DCC decoder for the sound and lights, but actually control the motor with an ESC. There still isn’t any BEMF to feed into the decoder but I’m thinking on that one.

I’ve been building out my little towns with houses, stores and trailer parks, but I had nowhere to actually switch loads. So I came up with this little industry. It’s some sort of chemical company, I’m not sure what but it was in a good place to spot a couple of tank cars. I plan on a small office building/factory about where the dog is sitting, but have not gotten that far yet.

Fixed a few things and cleaned up a bit of code for a new firmware release on the AirRx. Here I’m using it to control a small live steam locomotive.

Below are a couple of shots of the electronics in the tender:

The electronics on the bench:

Short video:

All of the CV settings:

/*
 * Decode message packets here and do servos and config variables
 *
 *   CV 201 - Radio Channel 0-15
 *   CV 202 - DCC Address lo
 *   CV 203 - DCC Address hi
 *   CV 204 - Servo Mode 0=Steam, 1=couplers, 2=ESC
 *   CV 205 - Servo0 LowLimit Lo
 *   CV 206 - Servo0 LowLimit Hi
 *   CV 207 - Servo0 HighLimit Lo
 *   CV 208 - Servo0 HighLimit Hi
 *   CV 209 - Servo0 Reverse
 *   CV 210 - Servo1 LowLimit Lo
 *   CV 211 - Servo1 LowLimit Hi
 *   CV 212 - Servo1 HighLimit Lo
 *   CV 213 - Servo1 HighLimit Hi
 *   CV 214 - Servo1 Reverse
 *   CV 215 - Function Code for Coupler 0
 *   CV 216 - Function Code for Coupler 1
 *   CV 217 - Function Code for Output x
 *   CV 218 - Function Code for Output y
 *   CV 219 - On/Off Code for Output x
 *   CV 220 - On/Off Code for Output y
 *   CV 230 - Reset to factory defaults
 */

More info – http://blueridgeengineering.net/

I managed to get a bit of time between the extremes of heavy rain and oppressive heat we are having to do some real-world testing of my new consist feature. I’ve had a basic consist setup in the receiver for a long time now and if you run similar locomotives with the same decoder setup, it worked ok.

However I have two very similar looking but different Chessie locomotives. An Aristocraft U25B with a Soundtraxx TSU4400 DCC decoder and a USA Trains GP38 with a TCSWow 501. The Aristo U25 ran about twice the speed of the GP38 at the same PT notch setting. Lots of grinding and coupler pops, these two were not happy together.

I did not like the idea of custom speed tables and all that CV programming etc, so I decided to just intercept the notch/throttle and apply a custom value. Hence this feature.

This adds a table in the receiver that is enabled if the loco is a consist ‘slave’. You can program each of the notches as sent by the Protothrottle to a unique throttle value that is sent to the decoder. This lets you more closely match up speeds.

Above is my outside setup with a closer shot below. Yes, it’s in a cardboard box but it keeps the electronics in one place and is very portable! (the fold out card is for the TSU4400 CVs, I can’t ever remember them) I use one of those phone external batteries to power my programmer and a Asus 7 inch tablet to run the web app. Works well and the parameters are updated in real time.

In the following video I’m just letting the locomotives chase each other to test on how closely they are matched up. This also required that I change a few CVs in the U25B to dial in the acceleration and deceleration to more closely match the GP38. The GP38 is the lead locomotive on the left.

In the next video, I’ve built up a fairly heavy train. The tank cars are particularly chunky. I still have some small tweaking to do at notch 4, the U25B does not have quite enough deceleration dialed in. But it works well and looks pretty good. I see I will need one more programming aspect- a filter on the slave so that the bell and horn can be turned off. Right now, that passes through so I get two bells and two horns, sounds a bit weird.

Below are some screen shots of the web app interface. For the most part, the cosmetics are the same but I have refactored the Xbee message passing and screen refresh code to make it more robust. I’ve also added a way to set the Node Identifier in the Xbee, this is a 20 character ASCII string that I use as the locomotive name. I used it to set the name of the Protothrottle to ‘Protothrottle’ since it comes from the factory as a blank. I would like to access more of the PT innards, particularly the configurations so I can save and load them on the computer, but that doesn’t seem to work in the current PT firmware? I would hack on the PT code but I like having a unit I ‘use’ and a ‘development unit’ to experiment with but I don’t have a spare $500 right now. Anyhow, note that these are screen grabs from my testing inside on the bench, not the above outside consist testing. For reference, the name at the top is the Xbee Node ID and the number under that is the mac address of that Xbee.



Boards and Software are available at:

Blueridge Engineering