In addition to my own control system using Xbees, I also play around with standard radio control. I have one of the Hobby King systems shown above, I think it was like $25 for the TX and RX pair. In the second picture I’ve taken the TX out of the shell and replaced the joy sticks with pots. I’ve mounted it on a board so I can get to it’s innards.
Anyhow, what I’ve done is leverage my R/C signal software and my DCC generation software into one widget. I continuously sample the servo pulse coming out of the R/C RX and then translate that into DCC messages. In this case, throttle messages, although they could be anything.
It all fits into an 8 pin Attiny85, then feeds into my other new widget, the DCC output board.
With this board, one side goes to the battery connection, the other is the output. You can see the small R/C type connector which carries the signal from the Attiny to the board. The DCC output of this board then directly feeds the sound decoder.
Finally, here is a video showing it in action. You can hear the notches of the sound decoder increase as the output pot is twisted and the servo pulse width increases-
Above is the basic install I do on all my locomotives. The green RX box can be a regular R/C RX or it can be my Xbee Control Board. Same basic wiring.
Latest incarnation of the Phone Throttle Contraption. The phone communicates with the Xbee Controller via bluetooth, a custom app runs on the phone. This is based on previous experiments with an android tablet, you can read about that here- Android, Bluetooth and Xbee
I’m trying to emulate a generic sort of DCC throttle ‘feel’ with this. I have all of the base code written and tested, it’s just a matter of pulling all the parts together. Slowly I’m getting everything working.
I have all the hardware installed and a basic smoke test done. So far so good. The firmware needs to be updated and my phone throttle is still not quite there but I’m close. By springtime I’ll have everything refactored. My Aristocraft U25B will be my development platform for this iteration.
Yet another project in the works. This one is intended to leverage my DCC circuit boards into a interrupt driven DCC I/O system for the Arduino Pro Mini. I actually have all of the software done and tested for both the input and output of DCC signals on my Attiny1634 board but I’ve never actually used a real ‘Arduino’. I’ve always built my own boards so this is a learning experience. I’m probably not going to make it compatible with the larger ‘Arduino’ universe, I’ll just optimize it for the Pro Mini. Anyhow, this project is actually number two on the list, the refurbish of my U25B locomotive is first so I can polish off the main widget code base.
Yes, I know this is a little weird but I want a knob AND a nice user interface (ala smartphone) to run my trains so I am working on this design. The Knob and underlying circuitry communicate directly with the 802.15.4 network. The phone is just there for the user interface and graphics. Bluetooth is used to communicate between knob/wireless controller and the phone. A custom app runs on the phone. I have the infrastructure working for this, its just a matter of smushing all the components into this small space and refactoring the software a bit. Both the case and the face plate for this were cut on my Probotix X90 3D router.
Today I got my order of printed circuit boards from Bay Area Circuits. I promptly populated them with components and powered them all up to see how they would do. Everything works! Very nice! Next step is to install these into one of my locomotives and replace all the breadboards with something clean and production quality.
Pictured, in order, is the 8Amp DPDT relay module, it’s used to reverse the direction of the locomotive. It can be triggered either with a logic one or zero, say from an Ardunio, or from an R/C signal via your generic radio control system. (The logic version is shown, the R/C version has an additional chip on the board, you can see the outline).
Second is the DCC output module. It is designed to be driven with a logic signal from a micro-controller such as the Ardunio. Logic input in, attach your choice of battery (or other) power to the input terminals and it provides up to 3Amps of DCC encoded power on the outputs.
Below that is the DCC input module, connect this to any DCC device like the MRC Prodigy or NCE DCC units and it converts the high voltage DCC signal down to what a micro-controller or Ardunio needs.
The last one is my Control Widget Node. This device is a micro controller wired to an industrial strength Xbee Series 1 802.15.4 Wireless Network Module. I use this for both my Control and Slave nodes. It allows high speed data delivered in an organized network infrastructure with a range of about 300 ft. I send both proprietary packets and DCC messages over this in real time. This is the latest PCB design.
I’ve been doing quite a bit of PCB design these days, here is a version of my controller board, the ‘microwidget’. It’s quite compact. I have not had any made yet but I thought it came out really sort of, well, neat. Like art kinda.
All total I have about five or six small circuits for doing control networks- specifically for large scale model trains. DCC input and output, servo control, DC brushed motor control, reversing relays- all via Industrial strength Xbee Network wireless.
I’m also thinking of making an apt-get debian package to install JMRI on a RPi 2 and gitlab for my code. Hmm.
Here are the final two prototypes. The master obviously connects to the Prodigy Express and sports a long range antenna for max transmission power. What I’m thinking here is this is the module that will be connected to my RPi 2 which I am planning on running JMRI on. The Pi 2 will also have a long range wifi antenna on it so I can use it to source web pages to my phone and tablet. My standard handheld design is what I actually use to drive my trains with.
The second pic is the client. This one is fairly comprehensive and has quite a few parts but I use it as my standard prototype rig. In addition to the control board, it also has an (expensive) Pololu 18v7 motor controller and a current sensor. The DCC output stage is the board with the large chip beside the speaker. All it is used for in this incarnation is to drive the Econami Diesel DCC decoder which powers the speaker on the right.
Here are all the parts labeled, you can click on the picture for a larger version-
Well, I didn’t like some things about the DCC output state machine in the last post, the one with the (wrong) zero bit on the end so I refactored it and now it works mucho better. I took the background scan timer down to nothing so it would spit out DCC as fast as possible, this is the trace. The top trace is the rebuilt DCC, the bottom is the output of the Prodigy with just the default 003 loco address, albeit set to 128 step mode. Aside from the lesser number of preamble bits I’m sending they are the same, well within a microsecond or two. I am running this on an Attiny1634R-SU which is the 2% clock. Costs a few pennies more but worth it over the regular vanilla chip which is 10%, a bit loose.
I think the diagram in the last post caused a bit of confusion. Suffice to say I am just breaking apart the components of DCC and the subsequent ‘decoders’. I find the term ‘decoder’ somewhat problematic, I would refer to them as ‘clients’ with the DCC ‘booster’ or ‘cab’ as the ‘master’.
Anyhow, one of the things I do not like about DCC is the power aspect. DCC is sort of a bastard child of both power and data packets which makes messing with it more difficult. I realize that is really important when you carry power on the track but I don’t want to do that. I want the compatibility with DCC accessories and JMRI but I want to run battery power (or maybe steam one day) So I am chopping the power part out and siphoning off the data packets, sending the data out via xbee and rebuilding them on the client. The client takes the battery power, injects that into the data part and out comes DCC. I don’t need much in the locomotive that requires DCC per se, except possibly sound but I am interested in choosing routes via something (JMRI?) and setting turnouts (accessory decoders?) and signals and things like that too so I want all this to work.
Oh yeah, another aspect of DCC I’m finding I don’t like is the slam-bam sort of thing. Well, ‘not like it’ is relative I suppose, it’s probably the easiest one and most ‘organic’ of the protocols. Constantly send everything as fast as possible and you are at least sure some are getting there, right? So I’ve also, sort of, modified this at least over the air. This keeps network traffic low. I currently have only one priority queue in the master, I think I may have to expand this to two later one. A ‘hi’ priority for the locomotive situations and a ‘low’ for other things? Dunno yet.
A diagram of what I’m working on. Not shown is my prototype battery powered handheld, it would be (in addition to or to replace) the master in this diagram. 300ft range between the master and any client node, 250kbs.
I have about 80% of this working as indicated. I’m still coding up the Client DCC output state machine. It’s almost there but I think I’m off one bit at the end of the message. Hmm. Also, I have not yet tested the LMD18200 driver that will power the DCC out to drive the decoder, so that’s another step.
The weak link to me is the purple arrow between the prodigy and the base station. Right now, I have the cheap express unit, so it’s that thick telephone sort of wire. But from what I’ve read the wireless unit only has about a 40 ft range? Not so good. That is where the proto handheld I’ve built will come in. But that’s another project.
The whole idea of all of this is to be as transparent and fast as possible. DCC in at one end, it pops out at the client with only a small delay. How small? I’m hoping 10ms or so but that’s probably optimistic and will depend on the traffic. Lots of experimentation and testing to do but so far so good.
So this is the trace. The upper signal is the generated DCC waveform out of the client microcontroller. The lower waveform is from the Prodigy Express. Same message, skewed a bit, the top trace is about 1.5ms to the left. Look carefully and count the pulses and consider the widths, see how they are almost dead on except for that last bit? Hmm. Oh that will drive me nuts until I fix it!