DCC++ Hardware - Throttles

KE4NYV Jan 25, 2016

  1. UK Steve

    UK Steve TrainBoard Member

    431
    632
    11
    Bill,

    You are correct in that Register 1 will effectively be overwritten when switching between cabs. However this will not prevent you from operating several loco's on the one register. The throttle code stores current status of each loco and recalls such at each switch. The most useful purpose of putting each loco on it's own register, is that Base Station also keeps track of each loco's status. Then one can use a more 'smart' throttle or indeed multiple 'smart' throttles joining a session. Such throttles would call <s> upon connection then parse the returned data, so synchronising with current status. Adding such code to Dave's design would be possible, and your suggested mod goes the first step, but bear in mind Dave was aiming for some simplicity in the design, and you would have to establish bi-directional communication to make it work. For a single throttle setup, it's not really worth the effort.
     
    Scott Eric Catalano and Atani like this.
  2. William E Van Buskirk

    William E Van Buskirk TrainBoard Member

    18
    15
    2
    Hi UK Steve, thanks for the reply. My understanding of the base station may be wrong but I thought it handled re-sending throttle values, based on the internal registers, periodically till new commands are received. I.E. Train A, reg1, is set fwd at Speed 50 and Train B, reg2, is set rev at Speed 35. The base would refresh the commands to both trains till changed, the throttle(s) doesn't need to resend any commands. It's up to the Controller to manage the reg use for concurrent Trains.
    Dave's throttle seems to be restricted to handling only 1 Active train at a time through Base reg 1, I.E. I set cab A to speed 50, train A moves. Then I switch to cab B and set speed to 35, train B moves. Now reg 1 will refreshes train B's speed periodically but train A is no longer refreshed and will stop (?) at some point, timeout or dirty track.
    I agree that returning status and syncing is beyond the scope here, but would having the throttle coded to use a specific set of regs, 1-4 or 5-8 or 9-12, be 'bad' for a simple layout? Multiple throttles could be preset to their own reg set, to not interfere with any other throttles.
    Thanks in advance for any insights,
    Bill
     
  3. UK Steve

    UK Steve TrainBoard Member

    431
    632
    11
    Bill,

    Yes, you have a good understanding of how Base Station works and just to give that 'resend' functionality, there is absolutely nothing 'bad' in your proposed changes. Sorry if I sounded like I was trying to dissuade you from tinkering with the code :)
    Go right ahead there, I can't see any errors, it should work as you envisaged. In fact, perhaps other users should also adopt this relatively simple upgrade, as again you are right, if there is a derailment, dirty track or other such power interruption the loco concerned will stop unless it is the one 'actively' registered at the time, hadn't considered that myself, well done Sir.
     
    Scott Eric Catalano likes this.
  4. William E Van Buskirk

    William E Van Buskirk TrainBoard Member

    18
    15
    2
    Thank UK Steve, very much appreciate ALL input. I'm just starting into trains; TBH I got involved last month on behalf of a buddy. AND have been reading/devouring all I can find, so keeping all this new info straight is a challenge.
    My friend is a HO Lionel collector/modeler and has been running on his club's layout, using DCC, but has very little basic electronics background. I jumped in to help him setup his own layout after discovering all the great open source DCC projects (I'm a uC/electronics geek, mainly been doing Midi based synth projects lately). DCC++ is a great entry point IMO, low cost compared to commercial systems. So not alot of 'hands on' with DCC++ just yet, I'm in the process of setting up test track ect to learn for myself and to guide him some, on the learning curve.
    My buddy isn't too computer savvy but willing to learn, so Dave's wireless throttle and a DCC++ base station would be ideal for his needs and skills, with JMRI as a fallback controller for programming and expansion. I'm very interested in your WiFi based throttle system (too cool) but TBH my friend doesn't even have a router at his home so it would be of limited use for him. Would have to setup a network from scratch, and even downloading an throttle app to his phone might be a problem :)
    Anyway, thanks for your help, will be digging deeper into the code,
    Bill
     
    Scott Eric Catalano likes this.
  5. UK Steve

    UK Steve TrainBoard Member

    431
    632
    11
    Thank you Bill,
    You're doing exceptionally well if you've only been studying for a month, that's quite impressive.
    And, Wow, I find it hard to believe your buddy can manage without WiFi these days, but anyways :)
    Sometime soon I'll be revising all I've learned over the last few years, and publishing some up to date throttle designs, a lot of my code is not yet 'open source'. In fact I'm just in the process of sourcing parts for my latest idea. Worlds smallest DCC++ WiFi pocket throttle anyone??? Based on the new chip from Expressif, the ESP32. In fact probably the worlds most compact wireless DCC throttle per se! That would just be for fun though, there'll be something more practical derived from that development :)
    Watch this space.
     
    esfeld likes this.
  6. William E Van Buskirk

    William E Van Buskirk TrainBoard Member

    18
    15
    2
    Well, I've really enjoyed following the development of DCC++ on the (massive)thread, and your WiFi development in particular. Reading all the pages in a couple weeks can kind of bakes the gray cells but it's fun. I've been coding PICs for years (8052s before that and started on an Atari 800 many years ago) so kind of have a leg up when diving into DCC.
    Yea, Mac lives in the countryside and he and his wife rely on their smart phones for the little web access they need. They have one desktop connected to the net and the connection is very slow. Could setup an ad hoc WiFi connection for his layout but like I said he's reluctant to go all digital and I live in the next state so IT support would be sketchy. He likes a knob and real switches, push buttons will do. He's open to the idea of an old computer for just JMRI but from what I have seen, you really have to 'roll up your sleeves' to setup the panels and cabs for your layout. So he'd be a little on his own as he builds his layout.
    Will be looking forward to seeing your latest and greatest throttles, especially the micro throttle :) I ordered a couple Witty Cloud 12F boards but have yet to get started with them, have to get the basics up and running first. Kind of thinking along the lines of a RPi3 running JMRI connected via WiFi to the Base station and a WiFi throttle for direct control.
    Bill
     
    Scott Eric Catalano likes this.
  7. esfeld

    esfeld TrainBoard Member

    355
    325
    10
    Steve
    You know I'll be watching .....
    Steve F
     
    Scott Eric Catalano likes this.
  8. William E Van Buskirk

    William E Van Buskirk TrainBoard Member

    18
    15
    2
    So I thought I'd report back some of my adventures with Dave's throttle.
    I had a case from an older project, it has a 4x4 keypad, 16x2 LCD, On/Off switch and LED already mounted. I needed to add an encoder and a I2C back-pack to the LCD. The front panel was already laid out so ended up mounting the encoder on the right side of the case. Retro fitted the LCD for I2C, had a PCF board on hand.
    I used one of Geoff's 17 function decoder boards, built up just the V Regulator. Could have just used some perf board or a Pro Mini break out board, as the decoder board is just mainly used as solder points and the keyboard cable is soldered direct to the Mini anyway.
    Built a perf header board to mount to the encoder, following Dave's schema. With the basic code the encoder was somewhat buggy. Thinking it was an software issue, tried Encoder lib. It was a little better but it counts every transition so used here the return inc/dec count is x4 per detent. And there still was issues with missed counts ect. The more I played with the encoder the more it looked like a mech problem. So I reverted to the original encoder ISR code and setup a test harness for quick testing other encoders. Plugged in a few other encoders and all were very solid. I started thinking the one I had grabbed when I built the mounting board was bad or I damaged it when soldering. But before I built a second mounting board, had a light bulb moment and tried clipping out the 0.1uF caps. Bingo the first encoder is now very well behaved running Dave's ISR code!
    Went through the code:
    Added support for DCC++ registers, as discussed above in this thread, now each loco uses it's own Base Reg.
    Added support for 4x4 keyboard, still need to decide on the use of the alpha keys. Changed the handling of the '*' key, it had been sending temp 0 speed messages to all the locos and turn-off the Base when pressed. I change it to only reset the speed of the active loco. My thinking is I would like to use the throttle in parallel with JMRI (need to change the Base station code) and maybe a second throttle so stopping all activity on the layout when changing the address of one loco didn't seem correct. A dedicated E-Stop switch will be added to the throttle code.
    Fixed a few bugs. The main one was mentioned above in the thread, can't set throttle to only 1 loco. In getNumberOfLocos() ascii key value is scaled to 0-3 and then " if (key == 1 || key == 2 || key == 3 || key == 4) { " tests and sets maxLocos. Changed it to " if (key == 1 || key == 2 || key == 3 || key == 0) { " and now correctly allows only one loco.
    So waiting on the HC-12 boards but very happy with the build :) Here is the current code if anyone is interested, have fun
    Bill
     

    Attached Files:

Share This Page