Scott - I am not quite sure I understand why it works that way but I certainly have collected evidence that it does happen! I have yet to notice a corrupted data packet! dave
If say Digitrax and NCE are operating at the same time there would not be cross talk....now if there are 2 of the exact same NCE setups or Digitrax there "maybe" cross talk. I have not run into that problem yet....having been aprt of several train shows with several modular groups at the same time we have never had this issue
Scott, I fully understand how that works when a system is designed to have multiple RF units coexist. What is surprising to me is the fact that I did nothing to have multiple throttles communicate with the DCC++ receiver and it still worked. I saw nothing in the HC-12 documentation about such things. Interesting! Dave
I'm not sure if you are still trying the project. If you are still carrying on, I can point you to another project which include the circuit diagrams, software & libraries. They are using their phones as controllers or multimouse so no hand held included. It is actually a whole DCC (Xpressnet & Loconet) based on either a Uno, Mega or Sanguino,
Good day. I have revised the hardware and software on the wireless throttle to support a rotary encoder and have a few questions. How often should the throttle send a speed or function command to the DCC++ unit? Is it sufficient to send a new speed update once when the speed or direction changes or should it be repeated every second, 10 seconds, etc? What about function key commands? Also, I am using the button on the rotary encoder to switch from forward to reverse direction. What is everyone's preference? When the loco is running at a certain forward speed and the button to change direction is pressed should the throttle slowly stop then reverse and speed up the loco or should it immediately send the direction change and depend on the loco's momentum setting to slow it down & speed it up? Or should a direction change bring the speed to zero every time? thanks! dave
Hi Dave, On the speed setting I had a problem when designing the Javascript to send the command. Lets say you wanted to move a Loco from 0 to 89. Gregg's Controller will send every increment in separate packets 1 through 89. No problem over regular serial and Base Station doesn't seem to mind. However sending all that data rapidly over to the ESP Server would overwhelm the buffer and crash the the firmware. Digging into how Loco Decoders work, it seems the better ones at least only need the last packet say <t1 03 89 1> to get the job done. When they are programmed correctly (with acceleration/deceleration parameters) sending <t1 03 89 1> will result in a nice smooth acceleration (of your programmed preference for that loco) to speed 89 from the standing start and therefore any combinations in-between. Exception being <t1 03 -1 1> for emergency stop. Great, I could solve my buffer overflow by just sending the end packet. Once the decoder has the instruction there is no need to repeat. If such repeat packet housekeeping exists then Gregg will have written it into Base Station code. So I guess you could try something similar to what I did in your code. On the direction change. You once presented me with the same question again as I was developing my code. My own thoughts are that you shouldn't suddenly change a moving loco's direction. So the default action should be to emergency stop it if it is moving, then wait for an new command in the other direction. That at least covers direction changes that are done in error. If the loco is stationary at the direction change the EmStop will be ignored anyway. Sorry I can't give any info on function keys, but i think similar operation applies. Steve.
Hi Dave, Have a look at this one, http://members.home.nl/robert.evers/mdrrcmouse.htm. His code is unfortunately a hex file, but maybe he will give you the source if you ask him. The zip includes a manual with the functions of the mouse. Another mouse manual that is base on Xpressnet, http://usuaris.tinet.cat/fmco/download/MiniMaus_manual_v2A.pdf, (English is halfway down). There is a rotary encoder version for this one but the developer wont give the code, he will only refer you to his shop. The one thing the lot across the pond from you, insist on, it an emergency button on their mouse/ controllers. If you want to include Xpressnet/ max485 here is a schematic on how to include it on a Mega/ Uno, http://pgahtow.de/wiki/index.php?title=Datei:Arduino_ROCO_Booster.png. The site also has the library for it. Pieter
Hello Dave, I am going to use the Digitrax DT400 as an example.....the rotary knobs continue to turn....speed goes from 0-99.....you can either push the knob to reverse the direction or use the push button to reverse the direction....when either is pushed it does not zero out...it reverses the direction at the same speed as it was already moving....now I do like your rotary knob that has the indent to zero out.....and the button to push to reverse direction.....my GUI interface sends a speed command do the base station when ever there is a change....not constant. Hope that helps - Scott
Dave ... as a proponent of magnetic uncoupling I prefer an immediate reverse without slowing down (subject only to momentum setting) Steve F
That is all great info, Gents --- Thanks! Looks like I should do the following: Have the reverse function send out the same speed it was and let the loco decide how fast to switch motor direction Send out instruction packets only when a change is done thanks again! dave
From the perspective of the DCC++ Base Station, any throttle command could be sent at any time. The Base Station will transmit the appropriate packet through the tracks as soon as it finishes processing whatever packet it was already in the middle of transmitting. Hence, you can switch from forward to reverse, jump speed steps, etc. Once the new packet is transmitted it is included the Base Station's register list and it will be continuously retransmitted along with any other throttle commands in the register list. Continuous re-transimssion is desired for two reasons: 1) some decoders shut down automatically if they are not periodically addressed; 2) a momentary loss of power to an engine (dirty track, misaligned frog points, etc.) can cause the decoder on that engine to reset the throttle to zero. Having the Base Station continuously retransmit throttle packets means that the engine will start right back up, often so fast that you are not able to detect the temporary power break. Unless you need to change the throttle setting, there is no reason a handheld throttle itself needs to retransmit the same throttle command (with one caveat - if the Base Station loses power, you'll need to re-send all current throttle commands). Function commands, on the other hand, are not stored in the Base Station register list. They are processed immediately but then forgotten. Thus, if you have the front headlight on and the engine hits a dirty spot on the track, the engine will continue moving but the headlight may turn off if the decoder briefly lost power. Some of my decoders seem to turn on their headlight upon power up, but others do not. In some of my autopilot code, I periodically re-transmit headlight settings to the active engines to make sure everything that is supposed to be turn on, is indeed on. Note that the slide throttle on DCC++ Controller does in fact transmit each incremental step as you raise or lower the slider. This is by design. But other parts of DCC++ Controller (such as autopilot) jump from zero to half-throttle all in one step.
Dave B, I am quietly and very excitedly watching your progress with the new wireless throttle. I really like the encoder concept. I agree with letting the motor decoder decide how fast to switch directions. And it is great to see that you can use multiple throttles on the same Base Station. I appreciate all your effort. Regards, Dave Merrill
Thanks, Dave - I have the code just about and will put the hardware and software info on my web page as soon as it is done. Stay tuned..... dave
The latest version of the wireless DCC++ throttle is working well. It has a rotary encoder to adjust the speed. It uses the button that is built into the rotary encoder to change direction. The video (link below) shows how it works and goes into some detail about how I made the laser cut Plexiglas case. It also shows how two wireless throttles can be used on one layout. There is additional information on my web page here: http://www.trainelectronics.com/DCC....htm#Rotary_Encoder_in_place_of_Potentiometer Enjoy dave
Just watched the video and very well done. Where did you get your laser cutter from....I know it wasn't cheap that's for sure!
Scott - the laser cutter is from eBay (see: http://www.ebay.com/itm/281882801833?_trksid=p2057872.m2749.l2649&ssPageName=STRK:MEBIDX:IT ) and cost less than $1500 delivered. It is my second laser cutter - the first (see my notes here: http://www.trainelectronics.com/LaserEngraver/index.htm ) was less than $400 - You need to add to that the cost of CorelDraw (about $150 - you cannot use the student version!) Either could be used to cut the materials for this project but the new one is much more capable in terms of power and the capabilities of the controller. If you are interested in laser cutters like the one in the video I strongly recommend the videos done by Russ Sadler (see: https://www.youtube.com/channel/UCqCyShJXqnElPTUnxX0mD5A ) His videos gave me the confidence to trust the eBay unit and convinced me to upgrade from the first one. Great fun! dave
Dave Great video .... I have parts on order and can not wait to get started on this project. Since I have built other projects of yours I am equally fascinated by a look at your shop ...... a video tour of your shop would be great. Steve F
Thanks, Steve - good to hear that you enjoyed it - I am anxious for others to try the design to help flush out bugs! Let me know if you want me to cut a case for you dave
