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
ESU Decoders and JMRI
#esu-decoders
|
Hi all,
As usual I find JMRI Decoder Pro a huge help in setting up decoders. ?However I find that when I program an ESU Loksound decoder (aside from sound programming for which I use a Lok Programmer) when it comes to testing a CV change , be it a function button assignment or some motor parameter or whatever, if I select a throttle, select the loco and then go for a test drive on the programming track I find the decoder might respond to the first one or two commands and then it all freezes. it might be that if I moved the throttle , it then starts moving but I then cannot stop it anymore, if I switched a headlight on or activated the horn, it then won't respond to the next command etc. ?This happens regardless of which ever loksound decoder I use. It doesn't matter if I do it in programming track mode or POM, ?it's done it with many versions of Decoder Pro , several different computers (both WIN and MAC). The only constant in this all is a SPROG programmer (but again,doesn't matter if it is a SPROG II , a SPROG 3, using an SBOOST , I have all of the above, but nothing changes this. The only way to test the loco is to take it of the programming track and test on the layout, or using the Lok Programmer, which is also fine. ?What is is that causes this issue with JMRI+ SPROG on a ESU Loksound decoder?? ? |
|
This may or may not help... clean the programming track and wheels. I have had
toggle quoted message
Show quoted text
the odd problem before, I find a quick clean of the program track helps, after all, it isn't used that often so it will get dirty (oxidize). John ---------- Original Message ---------- |
开云体育I just purchased 2 dash 9 engines with emu sound decoders.Am i going to have issues using jmri decoder pro to program them. Will i need an extra programming device Tony On Nov 1, 2019, at 12:08 PM, torikoos via Groups.Io <torikoos@...> wrote:
|
|
Most likely you are seeing the results of low current limit on the programming track. Programming tracks are design to operate on minimal current. This is to protect the decoder from faulty installs. It has a 250mA limit. The idea is to program the values on the programming track and test operations on the tracks /main line. Just a fail safe measure.
Inobu |
|
That I know, but even in OPS mode, when the SPROG is not limited and can be used at full capacity it is still doing the exact same thing. ?It is not happening with other decoders such as a Tsunami (although they have other issues in that they are notoriously hard to program on programming track mode and need to disconnect the keep alive capacitor to do so reliably)....?
|
开云体育torikoos, This happens regardless of which ever loksound decoder I use. 1) Does it mean that you've tried multiple LokSound-equipped locos? 2) Does it mean that you've tried multiple JMRI definitions? If you mean (2), there's one and only one correct LokSound definition to use; the one chosen by New Loco->Read type from decoder. This applies to any modern ESU decoder. It doesn't matter if I do it in programming track mode or POM, ?it's done it with many versions of Decoder Pro , several different computers (both WIN and MAC). The only constant in this all is a SPROG programmer (but again,doesn't matter if it is a SPROG II , a SPROG 3, using an SBOOST , I have all of the above, but nothing changes this. The only way to test the loco is to take it of the programming track and test on the layout, or using the Lok Programmer, which is also fine. ?What is is that causes this issue with JMRI+ SPROG on a ESU Loksound decoder??? ESU decoders are quite sensitive to poor DCC waveform quality. This can be in the SPROG, it can be because the EU-mandated suppression components (needed only for DC mode) have not been removed, or by some peculiarity of your program track wiring. Did you fit the decoder yourself? What brand and model of loco? JMRI ignores the decoder brand/model as far as ?throttle commands are concerned. What version of JMRI are you using? What DCC system are you using on your layout (where the loco behaves)? Dave in Australia |
|
Gents,? Koos reported the exact same symptoms using JMRI/SPROG and ESU decoders back in 2015. There was no follow up and? thread was a dead end.
He was using a LENZ system on his layout in 2015 and he reported the ESU decoders worked fine under control of the LENZ system back then also.? The issues were using the SPROG3 setup with MAC. Marc |
|
Perhaps Koos should contact Andrew Crosland at SPROG, he may have a wonky
toggle quoted message
Show quoted text
SPROG3. For what it is worth; I had a SPROG2, it worked great for several years, then it decided it didn't like trains anymore. Contacted Andrew, I was invited to return the unit, I did, he sent it back reprogrammed. It was explained to me that the programing gets scrambled under certain circumstances that the team at SPROG have yet to duplicate. It worked great for a week or so then went dumb again, contacted Andrew again, he sent me a replacement, SPROG2v4, this works great too. John ---------- Original Message ---------- |
|
Koos,
On 2 Nov 2019, at 9:01 AM, Dave Heap <dgheap@...> wrote:- How long/large is your programming track? - How long are the wires between your programming track and the SPROG? - What gauge are the wires between your programming track and the SPROG? - Are the wires between your programming track and the SPROG twisted loosely together? These factors become important for a loss-of-control situation (they can have a big effect on DCC signal quality). Dave in Australia |
|
With JMRI you can do anything except load new sounds into the Lok. You need special hardware for that.
You can ske who in your qarea has a Lokprogrammer you can borrow, if you need a new sound set installed. Sdeveral folks have advertised availability. Just be patient. Over 2000 CVs to read in the new V5, so it takes a while to load everything. I have more of these than I want to count, and am always getting more Loks with Loksound. They even have a workaround to allow programming (WIth JMRI) using the bad version of a control system that cannot program other indexed decoders. At the club we recently had a control system on our programming track table go bad. Programmed fine, but the POM/running loop was dead. (Not a SPROG). Sunspots, cosmic rays, Voudon curses, oxidation, something makes electronics die after a time. Just Life. Thomas DeSoto, TX |
|
This from Sprog..\\
The SPROG does not need or benefit from programming boosters. They actually do not add anything to the SPROG capabilities, and some do not work at all. For programming, the NMRA specification says that any conforming locomotive will need no more than 250mA to program, and SPROG II is fully able to support this. Some of the sound-equipped locomotives draw higher currents starting up, and so have had issues when programming on conventional DCC programming tracks, but again, we have developed SPROG II and SPROG 3 to support these needs. Some sound decoders have been found to respond better when programming with a higher voltage supply than the 12V we usually offer with the SPROG II, and so if you have TCS WoW, Broadway Limited or some other newer sound installed we do recommend that you purchase the SPROG 3 package to get the higher voltage, or contact us at sprog@... for advice, or to obtain an alternative or replacement higher voltage power supply. This nothing to do with JMRI...... If you want to isolate the issue get an O-Scope and look at the square wave....... |
|
The buck stops for JMRI at the SerialMessage constructor. This is where it captures the byte string.
But to say that JMRI has to do something different doesn't make sense as it is capturing charter strings in both directions. And that common throughout the code. Now if you are stating that the issue worked with windows and fails with Mac. Then look at the RS232 serial adapter. If the adapter is a FTDI chipset knock off the errors could be introduced there. Or if its a bogus serial adapter that could injecting error or noise as well. This is why an O-Scope would be useful. Still bottom line it has nothing to do with JMRI coding. I give it less than a 3% chance that it is. The other 97% is the Serial adapter. Inobu ? |
|
Koos,
On 2 Nov 2019, at 11:51 AM, Dave Heap <dgheap@...> wrote:I have a SPROG IIv3 firmware version v3.3, powered by a regulated 15VDC 2.0 amp power supply. On my Train Room iMac (10.10.5) running JMRI V4.17.4 I tried: - SPROG Programmer Mode. - SPROG Command Station Mode. I have two ESU decoder testers, complete with motor, lights and speaker: -One was fitted with a V4.0 decoder, Sound project "*ALCO 12cyl 244 (FT)*". -The other was fitted with a 5 DCC decoder, Sound project "ALCO 12-244". Both were set to Short Address 3. Used a JMRI throttle set to 128 SS Mode. For each decoder, in each mode (Command Station and Programmer), I activated sound (F8) and took both up to Speed Step 126, with motors screaming all the time testing Horn, Bell and Headlight at various speed steps, then back to Speed Step 0. At no stage was there any hint of loss-of-control. So it appears to come back to some factor in your hardware - I'd suspect SPROG Power Supply, programming track wiring or cleanliness, loco factors. What JMRI version are you using? Have you tried multiple LokSound decoders? Is the decoder firmware up-to-date (use LokProgrammer). I've had a V4.0 with CV read/write data mismatch (both JMRI and LokProgrammer) that was cured by a firmware update. Dave in Australia |
|
Thanks everyone,?
Let me clarify the issue as it is today: The no control of ESU equipped locos when testing happens regardless of: Computer (MAC or PC (Win 10) ) type of SPROG: (I own and tested with both SPROG II , SPROG 3, and also tried with an SBOOST in series). I have used various versions of the JMRI software, both test releases and production and currently run the latest production release. I have set up several environments, one where I use SPROG DCC in Service mode, and another in Operations mode (hoping this would work around the power restriction issue of a programming track which I know is restricted to 250mA normally) ?The power supplies i use for these are 2.5Amp 15VDC so there's enough power available. The programming track is 2 feet long, is fed with 2.5 sqmm feeders, is clean. As said the only way I can get ESU decoders programmed and test drive if I use the ESU Lokprogrammer. No issues there. Now I could of course just do that, but there must be a way to get JMRI to work as well.? On the Layout, using LENZ DCC system, not a problem controlling them. ?The issue is that I would like to be able to test the loco after programming with JMRI on my programming track at my work bench, rather than having to go back up to the layout to see if the latest changes are as desired Hope this clarifies the situation.? Thanks for all the feedback.? |
|
and before I forget, YES the ESU decoder CV changes that I program with JMRI do WORK , when testing on layout the changes generally have been applied, it is just that I cannot RUN the loco on the test track at my work bench using a JMRI throttle on my screen, no matter what I have tried. ?
Again, this happens regardless of which ESU Sound decoder I have tried, I have several, they all do the same. Therefore I firmly believe there must be a set up issue that I simply havent found. ? So anyone that can get this to work please let me know your JMRI settings and I'll try them out. |
开云体育torikoos, and before I forget, YES the ESU decoder CV changes that I program with JMRI do WORK , when testing on layout the changes generally have been applied, it is just that I cannot RUN the loco on the test track at my work bench using a JMRI throttle on my screen, no matter what I have tried. ? Let's get this firmly clear. JMRI throttles with SPROG have absolutely no way of telling whether a decoder is ESU versus Tsunami. There is no feedback between the decoder and the SPROG/JMRI when you are driving a loco. The DCC speed and function packets the JMRI sends out to the SPROG are identical irrespective of what is or is not connected to the track. You state "It is not happening with other decoders such as a Tsunami". In that case there is absolutely nothing wrong with your JMRI settings. You need to read and reply to my questions about your programming track setup and wiring. ESU decoders are very sensitive to wiring problems and experience loss of control when there are wiring problems. You need to change your thinking and answer all my questions about wiring. You just ignored them. Trying to find a non-existent JMRI problem is futile. Here they are again: Note: ESU decoders are quite sensitive to poor DCC waveform quality. This can be in the SPROG, it can be because the EU-mandated suppression components (needed only for DC mode) have not been removed, or by some peculiarity of your program track wiring. - Did you fit the decoders yourself? What brand and model of locos. - What version of JMRI are you using? - What DCC system are you using on your layout (where the loco behaves)? - How long/large is your programming track? - How long are the wires between your programming track and the SPROG? - What gauge are the wires between your programming track and the SPROG? - Are the wires between your programming track and the SPROG twisted loosely together? Note: These factors become important for a loss-of-control situation (they can have a big effect on DCC signal quality). Dave in Australia |
|
D ear Dave
toggle quoted message
Show quoted text
To your knowledge will I be able to program esu decoders using DIGITRAX handheld Will I be able to read and write to the esu decoders using jmri Tony On Nov 2, 2019, at 2:31 AM, Dave Heap <dgheap@...> wrote: |
|
I have had loss of control issues with Loksound (V4) decoders when they are installed in locos that have suppression caps on the motor, ie they are between decoder and motor and affect how the decoder sees the motor. ?I’ve seen this with several locomotives, mostly Hornby, a few Bachmann, ?I have not seen it with any other modern decoder in the same installations. ?It is fixed every time by snipping the caps off the motor. ?So, in addition to everything that Dave H has suggested, I would also suggest checking this. |
|
Tony,
On 3 Nov 2019, at 8:51 AM, AD <bklyns_baseball_club@...> wrote:No, you'll most likely make a mess for anything more than the simplest settings. I've happily programmed ESU decoders using JMRI and a PR3 belonging to a club member. There were some issues with early PR4 firmware but I believe they've been resolved, however you may need to turn off Confirm Reads and possibly also Cache Index CVs in Preferences->Roster->Programmer. I mainly use NCE (Power Pro or Power Cab) or SPROG with JMRI for programming ESU decoders. Dave in Australia |
to navigate to use esc to dismiss