UPDATE Massoth XLS being uncooperative with my Sprog

beavercreek

beavercreek

Travel, Art, Theatre, Music, Photography, Trains
Country flag
Scenario
I have installed a Massoth XLS in an Aster K28 (it has two Buhler motors)
I had downloaded the Mogul sound with my loaned PC programmer and loaded it onto a XLS board just like three other XLS boards and under test outside of the loco it operated fine with my ESU test rig under analogue and DCC power... sounds and all.
Installed it in the loco and tested with analogue LGB 1 amp power supply...all is fine (lights, sound and motors) except that, as I am not using reed triggers yet, the chuff start-up was not synchronised exactly with start-up of the movement.


So I attached up my Sprog/JMRI II DCC programmer/command station...it has a 14v 1.25 amp power supply) and tested the loco again..various problems occurred...sometimes the loco would pause at a slow-ish moderate speed (so would the sound) but if the Sprog throttle was increased it seemed to sort itself until the speed got to the stage where the Sprog did not have enough 'oumph' to power the the power draw at that speed....... where the motor would stop and so would the sounds.. back off the throttle and it would start again, sounds as well.

The Sprog obviously just does not have enough power, under 'command mode', to push the Massoth board's own requirements, the K28's twin motors, the lights and the sound amplifier when under heavy load.

So I went into the Sprog programmer to change some CV's and settings to try to synchronise the motion start with the chuff start. The power requirements for programmer are not so severe.
Although the Sprog was saying that the CV changes were being written to the XLS, in actual effect, on checking they were not being changed at all.
So I decided to check to look at CV 15 and 16 to make sure that the newly downloaded sound had not 'locked' the XLS ...BUT.....CV15 and CV 16 after once showing a value of (-1) were not visible again!
I checked with another loco and the CVs 15 and 16 were definitely showing for that one.

So I am perplexed....

Why use a Sprog?....
I have not used the Massoth PC programmer to change the CVs as it is a real pain in the 'oojah' as you cannot immediately test the change like with the Sprog. You have to test the loco with a DCC power supply/controller, then if things are not right, go back to the programmer to change, then back to the power supply setup to check etc etc.
To synchronise a chuff you really need to be able to whiz back and forth.

Also
Why would the XLS show that it was being changed by the Sprog..but actually not be changed (normally the Sprog would give a statement that there was a problem writing to the board if there was one.
Would there be a reason why this XLS CV15 and 16 became non visible (not even greyed out) in Sprog environment?

Hope there are some Sprog/Massoth gurus out there.........
 
Re: Massoth XLS being uncooperative with my Sprog

I'm as perplexed as you as I've programmed XLS with a SPROG before, I'd guess that something is just on the limit power wise and it's just causing interference as you program. One possible solution would be to disconnect some of the auxiliaries so only the motor is connected and see if that helps while synching.
 
Re: Massoth XLS being uncooperative with my Sprog

Wrong programming mode maybe? With for example PoM programming there is no feedback so the only thing the s/w can do is assume it worked.

One thing I always do with any brand of decoder before programming it is to turn off all of the functions for lights sound etc. This is similar to what Paul is saying.

If you can find an ESU programmer somewhere (?!) that has the ability to test running and functions after programming. Of course you can only use the CV mode to program Massoth Decoders, and can't load sound. If it worked it would tell you there wasn't anything wrong with the XLS. It would be good enough to test chuff synchronisation etc.
 
Re: Massoth XLS being uncooperative with my Sprog

Hi Cliff and Phil
Many thanks for your input.
It definitely looks like the load that the K28 motors (and heavy, metal motion) are putting on the the Sprog II's power ability is having an effect. This is strange as they are buhler jobbies but they do seem a bit beefier than those found in 'normal' LGB fare. But even with just the motors connected to the decoder, there is still a problem programming the Massoth board with the Sprog.

I tried programming a few more DCC locos with different makes of decoders using the Sprog and it had no problem programming them. So it may be the Massoth decoder that is up the Swannie.

I won't have another chance till the weekend to look again but I will follow your ideas with more investigation.

Now I wonder where I can put my hands on an ESU programmer Cliff?....Oh yes I know ;) ;)
Will report back with my findings.
 
Re: Massoth XLS being uncooperative with my Sprog

Did you update the firmware as well as the sounds Mike?

If you did update the firmware, did you unlock the decoder prior to attempting to read/write CVs?

To unlock the decoder, set CV15 to 148.

----------------------
1.2. Programming lock
Since firmware 2.84 you can also set the programming lock on LS/XLS Decoder
To prevent unintentional programming this decoder offers a programming lock in CV 15 / 16. If CV 15 matches CV 16 programming is possible. If CV 15 ≠ CV 16 the programming lock is active.
We recommend to not change the value of CV 16. This allows to alter CV values anytime even when the decoder is installed with other decoders.
The standard value of CV 15 / 16 = LS(144) XLS(148).
If the programming lock is active and you do not remember the value of CV 16, you may reset the programmig lock with CV 7 = 55 to its factory default settings.
After programming the decoder it is absolutely recommended to activate the programming lock.
 
Re: Massoth XLS being uncooperative with my Sprog

Is there a way of attaching just one motor and seeing if that works? Does it work with a motor from another engine that has programmed OK?

Does it program directly from your Massoth Command Station? That presumably has more 'ompf' than the sprog (or the ESU)?

Most of the time I don't bother with separate programmers I use my command station directly and used a DPDT switch to quickly and easily switch between the programming track and the main track.
 
Re: Massoth XLS being uncooperative with my Sprog

Mark
The problem is that CV 15 and CV 16 for this decoder are no longer visible in the Sprog programming window.
There was only one update file and that was the sound file. It is an old file and it's version was lower than that already on the decoder.
The Sprog is testing fine with other loco/decoder combinations.

Cliff

I can isolate one motor but it will then put strain on the rod motion as it will have try to 'turn' the other ' dead' motor so it will not be a good idea as I ain't dismantling the motion!

The reason I use the Sprog is to circumvent the, what is in my mind, the onerous CV programming language. The Sprog shows the names of the functions features etc that the CV stand for in a graphical and, for my small brain, much more user friendly approach. CVs, to me, are like going back to the DOS command prompt!
The Sprog also has the option of programming as well as acting as a command station with easy switching back and forth.

I will put another Massoth decoder in situ and try it out.
I will also try to program the 'recalcitrant' decoder with the Massoth programmer but use the Sprog as my ' interpreter'.
 
Re: Massoth XLS being uncooperative with my Sprog

Sounds to me like there's something wrong with the load the programming track is seeing, given that the XLS originally responded to programming OK on the ESU test rig. Could be a fault in the loco wiring, a dodgy motor or sound/smoke unit load? I think Cliff's right, you should go back to testing the decoder with the ESU test rig, or use the SPROG and simply attach a spare motor to the decoder as a first check.

There should be no need for any more "oomph": the programming track of a command station, SPROG or whatever you use is always deliberately designed to supply restricted current, maybe a few 100 ma at most? That's all that should be needed when programming, but it does mean that sometimes sounds/smoke and other stuff needs to be turned off in case there's too much inrush of current.

I presume you've tried a full "read all sheets" in JMRI to confirm the SPROG is reading the decoder ok? Check the wheels and progamming track are scrupulously clean - I've had problems in the past with dirt on my rolling road rollers causing mis-reading.

Strange that CV's are not showing up. That's not a fault of SPROG but a problem with the JMRI software. Which "programmer" sheet are you using - "Comprehensive?"
 
Re: Massoth XLS being uncooperative with my Sprog

beavercreek said:
The reason I use the Sprog is to circumvent the, what is in my mind, the onerous CV programming language. The Sprog shows the names of the functions features etc that the CV stand for in a graphical and, for my small brain, much more user friendly approach. CVs, to me, are like going back to the DOS command prompt!
The Sprog also has the option of programming as well as acting as a command station with easy switching back and forth.
Click to expand...

It is a pity that DecoderPro doesn't work directly with the Massoth. I've often thought that would be a good project for someone to contribute to JMRI .

As Nick says 'oomph' is restricted on the programing track. Sometimes I have found that decoders that don't program on the programming track will program when PoM is used.

Another good point is about good contact on the programming track. If a loco has skates I connect the power directly to them and/or feed it in via the power socket.
 
Re: Massoth XLS being uncooperative with my Sprog

Cliff George said:
It is a pity that DecoderPro doesn't work directly with the Massoth. I've often thought that would be a good project for someone to contribute to JMRI .
Click to expand...

Licensing issues unfortunately - the Massoth communicatin protocol is proprietory. I don't think they're interested in letting JMRI developers have access as long as their own Massoth programing software exists and they've licenced the protocol to StellWerk (I think?) for layout control.
 
Re: Massoth XLS being uncooperative with my Sprog

You can obtain the protocol from them if you desire, but you are bound by their terms which include not releasing it into the public domain (which you would be doing if you contributed to JMRI).

The PC module programming protocol is similar to that used by the LGB programming module and the I believe the protocol is owned by StellWerk who wrote the original software for LGB. Massoth will not release that protocol to me.
 
Re: Massoth XLS being uncooperative with my Sprog

I believe Mark has a licence, perhaps he could tell us what the restrictions are in the licence. Probably they will only licence use for specific purposes.

Yes Stellwerk are able to use the Massoth computer interface protocol, but there are some others as well RR&Co, Railware, Rocrail, iTrain, Win-Digipet. Rocrail is a an open source project so there could be some hope of use with JMRI.

It says on the Massoth web site:

"For interested customers MASSOTH gladly offers the DiMAX PC interface protocol for software development. To register for the protocol please fill out this form."

Edit: Sorry posts crossed! I still find it interesting that Rocrail have a licence.
 
Re: Massoth XLS being uncooperative with my Sprog

I do have a license. I cannot locate my original agreement.

I think Rocrail get over some of the restrictions by not providing the source for the interface protocol to the Massoth units. I do not recall finding any source code that related to it.
 
Re: Massoth XLS being uncooperative with my Sprog

Sounds like both JMRI (and Massoth) need to update their templates that the software uses to put CV values into..
Bit of a pain that the Massoth software does not either show (or even read, perhaps) all the CV's of their decoders.. There again, the Massoth software did not install properly for me, and I have not found a 'config' file that I could massage to correct it. :(
 
Re: Massoth XLS being uncooperative with my Sprog

When I mention 'not enough oomph', I am talking about when the Sprog is in Command' mode, not programming mode.
I am programming using the Sprog in comprehensive mode.
The 'missing' CVs 15 and 16, are there for all other of my decoders Massoth, ESU, QSI etc BUT not for this particular decoder.
It WAS working fine when I tested it alone on the ESU test rig.

The loco and the decoder work perfectly fine with a 1 amp DC supply but not when with the Sprog unit with DCC (both in programming and in command mode).

I will try the ESU and the Massoth programmer to see if the decoder will show he 'missing' CVs with those units.
 
Re: Massoth XLS being uncooperative with my Sprog

Mike,

If you have firmware prior to 2.81 (check CV 7 to find out) CVs 15 & 16 do not exist and neither does the programming lock. Maybe the JMRI software will only show those CVs if the firmware version is 2.8 or above!

I'm not sure that the Massoth software is intelligent (as per our phone conversations prior to this) enough. The latest version (1.3.42.0) does have a "Programming Lock" element for the XLS template but I'm sure it does not enable/disable it based on the current decoder firmware version.
 
Re: Massoth XLS being uncooperative with my Sprog

If the CVs are not showing up in DecoderPro and you're definitely on the new decoder firmware (as per muns above) then I'd have thought that would imply it's not using / not identified the correct decoder template? Could be it misread the manufacturer id or version number as part of the general read problems you seeem to be having with this one?

You're right, the SPROG is limited to about 1 amp-ish in command station mode. I think a couple of my locos don't drive very well on the SPROG, but other than that it is very useful to be able to program then test without removing from the rollers.
 
Re: ..UPDATE Massoth XLS being uncooperative with my Sprog

Update
Using the Massoth PC module, I have the XLS set up with the correct sound.
But testing with the SPROG II showed that the SPROG did not have enough welly to 'drive the loco and work the sounds...so

Enter the SPROG III plus 3 amp power supply.
This is able to test the loco very well but when it came to programming the XLS...everything was fine until I tried to sync the chuffs etc (CV195=0 so it is taking info from the speed steps).

Suddenly, after altering the two chuff settings, I was confronted with a very fast chuff which the SPROG III could not then reprogram back to default. In fact it was reading that CV as -1 and all other CVs as 255!

So back to the Massoth PC module for the programming, then switching with a 1200Z for testing......and everything is now fine.
I am still struggling to get the sound to start dead on when the wheels begin turning. The trigger CV is not far off but either the sound starts too soon (at CV setting 8) or too late (at CV setting 7).
Is there any other setting that might affect the sync?

So now the Aster K28 has DCC and good sound with a tube baffled speaker tucked away inside the boiler and also one in the tender for more bass oomph.
It took some time but all is good

Many thanks for the loan Mark !
 
You must log in or register to reply here.
Back
Top Bottom