I meant both in terms of amperage and efficiency -- does it get hot or need hefty heatsinks... I guess I can always look up the specs, but would you use it instead of a Super Chief (or a Zephyr) just based on power output, not on other bells and whistles? I ran across this article on the web the other day. Very interesting read for DIY DCC builders: http://railstars.com/2010/08/10/lolbooster-output-stage-part-1/ I have a perfectly oversized Digitrax system for my little layout (four N-scale engines and two dozen turnout servos and stationary decoders all feeding from the DCC bus), so my interest in this project is purely as a learning opportunity. I do see it used for a little Christmas layout, but primarily, I'd like to show my DCC-reluctant friends what some of the possibilities are.
If you watch Greggs videos of his Nscale layout he is operating 3-4 trains, turnouts and much more using the DCC++ system. I am running HO Scale just in a testing phase and my locomotives are sound units. I plan on using this system in a few weeks at my train clubs annual mall show and I have a good sized On30 setup and instead of dragging my DCC system with me I will be using the DCC++ system. The trains run for a full 8 hours on Saturday and Sundays so we shall see how this setup will hold up to being on all day.
At last, we have some success: DCC++ base station running multiple trains through JMRI with WiThrottle. It's still very basic - power on/off, throttle speed and direction. Not even lights, nor multiple slots - I'm sending all throttle commands to slot 1, but somehow WiThrottle manages to control the two trains independently. I'm not sure how -- I didn't expect it to work, and yet it works. I'm guessing the locos are caching the last received values. Even consisting works (WiThrottle sends independent commands to the base station for each loco). I'm planning to add those missing items and also turnout and sensor commands, and then I'm so making some DCC converts at our club's next show and tell. However... ...I did spent a few hours today troubleshooting some strange communication issues on my Mac Java development setup. As soon as the first command was sent, the base station would execute it (like turn power on), but then JMRI would freeze and not see any communication back. Force quitting JMRI didn't help because the serial port was still in use, so JMRI couldn't restart, and whatever terminal commands that I could find on the web that were supposed to free the port didn't work, either. The only way to get JMRI back online was to restart the whole computer. This would work just until the next debugging step, where it would do the same thing. I may have misconfigured something or done something else wrong, but debugging an issue like this in an unfamiliar IDE and this huge code base wasn't very enjoyable. So at last I said so much for this Apple "just works" thing, and decide to install NetBeans on Windows, and guess what? I'm suspecting it might have been some incompatibility (it fails on the first read from the serial port -- it never returns from the call). All the more reason to thoroughly test TwinDad's "official" driver.
By the way, I used an ordinary 12V power adapter from a portable hard drive to test the DCC setup. There is some voltage drop through the motor shield, and the trains run a bit slower than on the Digitrax system (I select 12V output to the rails for N scale), but they run just nice and smooth, nevertheless. The two trains ran for some 20 minutes or so, and it only gets moderately warm (the shield doesn't even have a heatsink).
Gregg used a 15 volt power supply and as you can see in the videos he runs 3-4 trains and controls turnouts etc....in two weeks or so I will have a few loops setup for the christmas train show and as stated before those are long 8 hour days running for the public. We shall see how it performs.
I submitted a pull request for the driver yesterday and it passed the continuous integration test. Once it is approved it will be in the "head" of The main code tree. Should be more or less fully functional, but I am sure there will be bugs. As a bonus right now I am working on adding a TCP pipe ala the LocoNetOverTCP tool. And there is a current meter tool that should show the booster load. I assumed the <a Val> feedback is a % of max. Correct me if I am wrong... Anyway, a few more days should do it.
FTR aside from it taking a long time to get through the splash screen phase (on the bug list), I had no comms issues with my Arduino Mega and MBPro.
I've got an update on my Perl/Tk GUI Throttle: it connects to the Arduino via the Win32::Serialport module and it connects via Com 6 and I can issue Track Power On/Off commands as well as hard coded commands. Now I am in the process of being able to select locomotive addresses and throttles. As stated previously this throttle is based off of a Digitrax throttle which supports operating two locos at one time. For now the basic commands will be F0 lights on/off F1 Bell On/Off F2 Horn On/Off F3 Coupler F8 Sound On/Off and DISP which dispatches the locomotive from throttle memory so you can select another loco.
You should be able to do this with bitwise logic operators without knowing the actual state of the CV. To set a bit do a bitwise OR of the CV value with the number that has the single bit set you want. To clear a bit do a bitwise AND with the inverse... like this: Try this... to set bit 4 (counting from zero as LSBit), do CV = CV OR 16 To clear bit 4 do CV = CV AND 239 In Java, the bitwise-OR operator is '|' (the pipe character), and bitwise-AND is '&'. I think this is the same with C and C++ IIRC. In binary, 16 is 00010000b so only bit 4 is set. Any value ORed with this will be the same value, but with bit 4 set. In binary, 239 is 11101111b, so only bit 4 is cleared. Any value ANDed with this will be the same value, but with bit 4 cleared. The OR and AND values to use for each bit are: Bit 0 : OR 1 (0x01), AND 254 (0xFE) Bit 1: OR 2 (0x02), AND 253 (0xFD) Bit 2: OR 4 (0x04), AND 251 (0xFB) Bit 3: OR 8 (0x08), AND 247 (0xF7) Bit 4: OR 16 (0x10), AND 239 (0xEF) Bit 5: OR 32 (0x20), AND 223 (0xDF) Bit 6: OR 64 (0x40), AND 191 (0xBF) Bit 7: OR 128 (0x80), AND 127 (0x7F) Sorry about the formatting. Don't know tables are possible here. The number in parentheses are the hexadecimal equivalents.
BTW, has anyone seen or tried out this motor shield? https://www.sparkfun.com/products/10182 A bit pricey, but at 6A, it's potentially a competitor for commercial boosters...
Great work, TwinDad. I'm looking forward to trying it out. I won't be able to test CV reading functionality for the time being as my motor shield doesn't do current sensing, but I'll test it with different hardware and OS's that I have around. I've done some more testing (and rebooting) on the iMac that was giving me trouble. It turns out that not only my (possibly buggy) JMRI driver code hangs, but so does Arduino IDE, and what's even stranger, so does JMRI with my Digitrax PR3 interface (but they both show the serial devices as /dev/cu.usbmodemA121 if I'm not mistaken). Which probably means that the particular Arduino unit is ok, and it's something else. It doesn't matter which serial port I plug it in, while other peripherals like flash drives work just fine. I'm baffled. The computer is running the latest Mac OS X and it's fully updated. That said, after moving the development over to Windows, I was able to make the driver fully functional for my own needs -- power, throttle, accessories... I didn't bother with consisting (WiThrottle does it a lot easier, anyway) nor CV reading/writing, so it's nowhere release quality (I guess you were at this stage a week ago), so I feel quite lucky that someone as proficient as yourself took to the task to bring it to the community. But I also feel good about being able to jump into an unfamiliar language, IDE, and totally unfamiliar huge code base that is JMRI, and still find my way around.
I agree with the logic above but the problem is that the state of functions is not actually stored in a known CV in the engine's decoder, and are also not saved when the power is cycled. Hence either the base station or the controller needs to contain the logic above (in my case I have it in the DCC++ Controller code). If DCC itself allowed you to read the state of a decoder's function that would have allowed us to flip individual bits without keeping the state of all functions stored in the software.
An engine decoder generally stores the throttle setting and will continue to operate without receiving an update. I think some decoders require receipt of a throttle packet addressed to themselves once every so often or they will automatically halt - the assumption being that the throttle had been disconnected and the user has lost control. The main reason to continuously send throttle commands is to prevent a halt if the train temporarily has a power gap. When you have two engines running using the same slot, try removing and replacing each engine on the tracks. The engine you addressed last should start moving again whereas the engine you addressed first will not restart. At least that's my guess .
This shield is unfortunately missing the additional logic circuits that combine The two direction inputs for each channel into a single direction input for each channel. This could be added with a simple logic gate, but right out of the box the shield could not be used with the DCC++ code base.
OK. The DCC++ system code is in the main JMRI codeline as of late last night. So if you pull the HEAD of the main JMRI/JMRI code from GitHub, you should have it. Functions that should work (at least basically): Serial connection over USB Base Station Simulator Track power on/off Throttle control with at least on/off function buttons, speed and direction Programming, both prog track and on the main Turnout control (see below) Stationary decoder control via JMRI "Lights" Loco Consisting with the JMRI Generic Consist Manager Current monitoring with the new current monitor tool (interprets the <a ... > response as a % of max current) Things that may not be working: Function buttons for momentary buttons ??? Note on turnout control: You must use the predefined turnout number assigned in the Base Station as the Turnout Number in the System Name when you define the turnout in JMRI. One of the things I need to sort out how to do is this: JMRI treats almost any accessory decoder device as a "Turnout" ... since DCC++ only sends feedback from (predefined) Turnout commands and not from Stationary Decoder commands, it was easier to map a JMRI "Turnout" to a DCC++ Turnout. But this means you can't (yet) just directly address a stationary decoder from JMRI through DCC++ without first defining it as a predefined turnout in the Base Station. I've mapped the Stationary Decoder command to the JMRI "Light" object, temporarily, until one (or more) of three things becomes clearer: (a) Base station sends a response -- any response -- from a Stationary Decoder command (easiest to work with JMRI, but requires a Base Station firmware update) (a) how to short circuit the response feedback JMRI assumes will be coming from a Turnout command (this should also be easy) so that JMRI can deal with not getting a response from the Stationary Decoder command (b) How to map both Stationary Decoder commands and predefined Turnout commands to existing (or new) JMRI objects in a user-friendly way. The thing that comes to my mind as most likely... JMRI only has one kind of "Turnout" but it recognizes several different modes of feedback from those turnouts, everything from "crickets chirping" to real-time points position data. I should be able to map Stationary Decoder commands to the "no feedback" variety and Turnout commands to the "Direct" mode (which is what they are now). Once I do that, the user can select which type of Base Station command will be sent by choosing the feedback type when defining the Turnout in JMRI. Anyway, if you want to check it out (literally) and try it, please do. Log bugs in the JMRI Bug Logger on Sourceforge (http://sourceforge.net/p/jmri/bugs/? source=navbar) or message me directly. Right now I'm working on adding a TCP pipe similar to LocoNetOverTCP. I have the Server side working, and expect to have the Client side up shortly... just chasing one nasty little bug. Then I'll get back to addressing the turnout thing above...
Quick question TwinDad....if I download form Github and unzip it where do I put it? I already have JMRI installed on my computer the 4.1.3 test version....how do I get the DCC++ stuff installed into it? Sorry I haven't messed with JMRI much at all. Thanks
You might want to be patient and wait for the next development release, which will likely be in the next few weeks. They tend to do them roughly monthly, more frequently as they approach the twice-a-year production releases. Right now you'll have to build the code yourself. There's some technical documentation here: http://www.jmri.org/help/en/html/doc/Technical/index.shtml for building the code but if you're not at least a little bit familiar with the general process, it may be tricky to help you through it.
Thanks TwinDad.....compiling source code is nothing new to me....I'm a linux/unix user myself so this should be a breeze to do.
OK, Cool. You should be fine then. I traditionally use Ant and Emacs for most stuff, but if you want to use NetBeans, you can open your local Git repository directly in NetBeans as a project. Oh, and it's probably better to clone the repository than to download a snapshot of it as a Zip file. That way you can update it easily as changes are made. In other news... I had an idea I want to pursue as soon as I get things buttoned down on the initial JMRI implementation. I just finished up implementing a DCC++ Over TCP link that allows a remote computer to send Base Station commands to a host computer running JMRI with a local connection to the Base Station. It occurs to me that it should be straightforward to port the Server side of this link into the Arduino itself (with an Ethernet or WiFi shield), creating a Base Station that can just be plugged into the local network. Then it occurred to me that if I could do that, I can also port the WiThrottle server-side interface into the Arduino, and allow folks to connect smart phone (WiThrottle/iOS or EngineDriver/Android) throttles directly to the Base Station. So anyway, I'm going to dig into that and see how far I can get. Motor shield is on its way, and I'll have to pick up an Ethernet shield on the next budget cycle.
Oh, hey... I just noticed when looking through PacketRegister.cpp that I don't have the parsing of the programming replies (<r...>) quite right. Missed the use of the "|" delimiter. I'll have that fixed shortly. And I'll be adding Sensor support (<Q ...>) ASAP as well.
