Thanks for all the work Bob.
I'll install Catalina over night and see how JMRI goes in the morning.
It's not the end of the world if it trips upon because I can run the railways either with Mac or with machines that are Linux based.
Best wishes
John

开云体育

You’ll want to grab a RTC module.?

We hope 4.17.5 is compatible with Catalina. There’s been a bunch of testing.

But there are limitations, particularly on how to install Java:

Bob

On Nov 2, 2019, at 6:42 AM, John Kneeshaw <john@...> wrote:

Thanks Bob
Is 4.17.5 compatible with Mac OS Catalina
Thanks
John

--
Bob Jacobsen
rgj1927@...

Thanks Bob
Is 4.17.5 compatible with Mac OS Catalina
Thanks?
John

Hi?
I think a found a solution . I will hold the data in ArrayList? ? that consist? instances of class that? ?define? the trains?
Doron

开云体育

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.

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.?

Koos,

On 2 Nov 2019, at 11:51 AM, Dave Heap <dgheap@...> wrote:

Koos,

On 2 Nov 2019, at 9:01 AM, Dave Heap <dgheap@...> wrote:

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.

- 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).

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

Ok, thanks for looking into this. I'll stand by.
Allen?

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




?

Test version 4.17.5 of JMRI/DecoderPro is available for download.

This is the next in a series of test releases that will culminate in a production release, hopefully in early December 2019.

If you are currently using JMRI 4.9.6 or earlier, we strongly recommend that you first update to JMRI 4.12 and make sure that's running OK before updating to this test release. There have been a number of changes in serial port support, panel file format and configuration options since those earlier releases, and moving to the stable JMRI 4.12 release is a good way to work through any possible problems.
<>

If you use JMRI on Linux or Mac and are updating from JMRI 4.7.3 or earlier, there’s a necessary migration step. (Not needed on Windows) Please see the JMRI 4.12 release note for details: <>

For more information on the issues, new features and bug fixes in 4.17.5 please see the release note:
<>

Note that JMRI is made available under the GNU General Public License. For more information, please see our copyright and licensing page.
<>

The download links, along with lots of other information which we hope you'll read, can be found on the release note page:
<>

Bob
--
Bob Jacobsen
rgj1927@...

On Oct 31, 2019, at 11:06 PM, Paul Bender <paul.bender@...> wrote:
Could you try this for me:
Start PanelPro
Make a copy of your current profile ( make sure your IDTag file has the original name )
Save preferences and restart PanelPro with the new profile ( the copy )
Open preferences and delete the LocoNet connection.
Save preferences and restart PanelPro with the new profile ( the copy )

Ok, I had some time to look into this myself tonight, and I am able to replicate what you are seeing. That means I can debug the problem locally.

At least one part of the problem is that the Transponding tag manager isn’t doing any bounds checking, but I don’t think that is the only issue.

Paul

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.......

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

I have a Raspberry Pi with USB connection to my layout but no internet connection so it never gets time updated unless I do it manually.? I would like a simple, automated way to have the Pi time reset from my phone when I connect using WiThrottle (Engine Driver). Is there a way to do this? It helps to have correct timestamps on logs and files.
- Regards, Dave Mc.

Koos,

On 2 Nov 2019, at 9:01 AM, Dave Heap <dgheap@...> wrote:

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.

- 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

Steve 009 in UK,

On 2 Nov 2019, at 11:05 AM, bluetobits <steve.lomax@...> wrote:

I have just loaded JMRI onto a old windows 10 netbook as a more portable PC than my main desktop. I keep my panel files and preference files containing custom icons, throttle images etc. in a Google drive folder so that both PCs have access to them and can sync local copies with both PCs

Hopefully you are using the principles set down at:
<>

With more detail at:
<>

Dave in Australia

Perhaps Koos should contact Andrew Crosland at SPROG, he may have a wonky
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