Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Locked Operate more than one WiFi throttle simultaneously?
Doug Lowing
Is it possible to control more than one decoder with separate Wifi throttles through one instance of jmri?
If possible, can it be done through a DCC++ base station? Through NCE Powercab? I know PowerCab allows for 2 throttles- one smart handheld unit, and one dumb ProCab throttle.? Would the jmri? act as second throttle through the NCE usb interface? |
On 11/19/18 5:46 AM, Doug Lowing wrote:
Is it possible to control more than one decoder with separate WifiYes, we've had up to nine engines, each on their own DCC address, running with five separate throttles simultaneously. If possible, can it be done through a DCC++ base station?That I don't know, I only tried it with a DCS51 (Zephyr Xtra) and an Intellibox "1.5" (HW 1, SW 2) connected through a PR3. Good luck, Heiko -- eMails verschl¨¹sseln mit PGP - privacy is your right! Mein PGP-Key zur Verifizierung: |
Information on the NCE Power Cab (Physical Throttle) Cab Bus address range is below.
toggle quoted message
Show quoted text
However, all JMRI throttles (and hence WiThrottles) are funnelled through the computer connection (in your case the NCE USB, which occupies only one Cab Bus address) so the same limitations do not apply. However, the number of trains that can be moving simultaneously is governed by the amount of space allocated for the Track Queue in the command station. - For the Power Cab - 12 trains running simultaneously. - For the SB5 - 18 trains running simultaneously. - For the Power Pro - 250 trains running simultaneously. Trains are automatically removed from the track queue by the command station after a train is brought to a stop and an (adjustable) number of stop packets are sent (to make sure the train got the message). If your Power Cab firmware (second screen at startup of your Power Cab, after the "Pro Cab V1.3" message) is: - "V1.28C" the only valid addresses for extra cabs are 3 & (unofficially) 4. - "V1.65" the only valid addresses for extra throttles are 3, 4 and 5. Non-throttle devices such as the NCE USB, Mini Panel or AIU can also use addresses 8, 9 & 10. However if you have ever done a System Reset, you will have lost all the extra addresses and be back to the V1.28C restrictions. - "V1.65B" the only valid addresses for extra throttles are 3, 4 and 5. Non-throttle devices such as the NCE USB, Mini Panel or AIU can also use addresses 8, 9 & 10. Similar comments apply to the SB3/5 with the range 2-5 for V1.28 and 2-7 for V1.65B. The number of simultaneous trains running differs from the number of possible cabs. 12 is the limit for all Power Cab versions, provided the current draw does not exceed the Power Supply current capability or the Power Cab's limit of 2A. I strongly recommend that you purchase a V1.65B upgrade chip for your Power Cab, not only for the above reasons but because of other bug fixes and added features. You can buy it direct from the NCE website, or often from a dealer. Also there can be electrical problems that can cause failure of extra cabs to work properly. This is due to a run of cab bus communication chips that needed extra components on your Power Cab Panel (PCP). Check the following website for how to find out if your PCP has the extra components (now fitted to all new PCPs sold) and what to do about it: <> -- Dave in Australia On 19 Nov 2018, at 3:46 PM, Doug Lowing <delowing1903@...> wrote: |
I'm afraid JMRI has to interact with the host DCC system and hence WiThrottles are subject to command station limitations, but these limitations may differ from physical throttle limitations (as in the case of NCE systems).
toggle quoted message
Show quoted text
-- Dave in Australia On 20 Nov 2018, at 4:50 AM, Dennis Cherry <dbcherry@...> wrote: |
I built a DCC++ based system for my club, and it certainly can operate multiple locos from a WIFI input to the JMRI computer.
The base DCC++ is memory limited on an Arduino UNO, but stripping out what's not need specifically for operating the trains themselves, 35 or so locos can be run concurrently. I'm in process building a system base on an Arduino MEGA, and that should be able to run many more trains. That exact number will be determined, but I expect it to be 200 or more. Be aware that the basic architecture of the DCC signal limits the number of packets to about 110 per second. DCC doesn't send every packet to every loco continuously, so the number of packets needed to actually operate a loco is dependent on what the loco is doing. If every loco had a packet sent to it, after 110 locos, the response time would suffer, but that would be regardless of the system used. I had an friend whose club uses an NCE system, and since NCE treats each loco, even in a consist as a separate loco, every loco gets commands sent to it as required, where most other system only send commands to the consist address. Having said that, the friend has never had any issue operating, even on a large modular layout in a convention center. The layout was so large that one 'loop' around it took 45 minutes without stopping. |
¿ªÔÆÌåÓýResponse time only suffers if many changes are happening at once. Every DCC system must send packets continuously so the DCC power is maintained. If no locos are moving an IDLE packet is sent continuously. If only one loco is moving, speed packets to that loco are sent continuously.?If two or more locos are moving, speed packets are?sent continuously, but to each loco in turn. Speed packets must be sent occasionally to every moving loco or the loco will time out and stop. Most DCC systems have a priority system in the track queue so that changed packets "jump the queue". So if you have 250 locos moving simultaneously and you change speed of one loco, the response is immediate. If 100 users try to change speed at once, you will see a response time degradation. Accessory and Function commands are only sent a limited number of times and also jump the queue. Many changes at once are needed for degradation to occur. Your understanding of NCE advanced consists is not quite correct. NCE always uses the consist address for speed and direction packets. It sends Function packets to the Lead and Consist addresses. It doesn't send individual commands directly to any non-lead loco address. --? Dave in Australia On 20 Nov 2018, at 8:01 AM, crusader27529 <crusader2752939@...> wrote:
Be aware that the basic architecture of the DCC signal limits the number of packets to about 110 per second.?If every loco had a packet sent to it, after 110 locos, the response time would suffer, but that would be regardless of the system used. |
Just to be on the same page, we are talking about virtual throttles number in JMRI, right? not total engines number. Because there could be consisted sets of engines. Also, do not forget that if you run warrants or automatic running, those do count as more virtual throttles. Cheers LeoP On Mon, Nov 19, 2018 at 12:59 PM crusader27529 <crusader2752939@...> wrote: I built a DCC++ based system for my club, and it certainly can operate |
Some DCC systems (e.g. NCE) support an unlimited number of virtual throttles as virtual throttles all share one "cab" address/slot. The only limit is on the number of simultaneously-moving (requested speed>0) locos/consists (consists count as one), due to the need to store all these in a track queue. This number always exceeds the number of "cab" addresses/slots.
toggle quoted message
Show quoted text
Other DCC systems and JMRI implementations differ in concept and limitations. -- Dave in Australia On 20 Nov 2018, at 8:44 AM, leo pesce <lpescester@...> wrote: |
to navigate to use esc to dismiss