Jump to content
 

sprog and sporog command


esmor

Recommended Posts

Ok I have two locos that will run quite hapily with sprog but wont run under sprog command station. These use different decoders (DDC concepts and Gaugemaster opti25) . Both run quite hapily with  my Bachman dymam9is pro set up. what am i doing wrong.

Link to post
Share on other sites

Ok I have two locos that will run quite hapily with sprog but wont run under sprog command station. These use different decoders (DDC concepts and Gaugemaster opti25) . Both run quite hapily with  my Bachman dymam9is pro set up. what am i doing wrong.

sprog 3 that is,

Link to post
Share on other sites

OK, that's weird.

 

What addresses are the locos?

 

Are you using 2 or 4 digit adressing?

 

I assume that you're using JMRI with the SPROG?

 

I have to ask, are you sure that you are getting the track power turned on OK when using the SPROG in Command mode?

 

Cheers, Mark.

Link to post
Share on other sites

The addresses ar 101 and 121. There is power, and all other locos seam to work fine, but  did have a problem will erratic running with a couple of others, but this seams to have been cured possibly by resetting the decoders. Using short addressing at mo for bot, but will try long to see if that makes any dif. And yes JMRI.

Link to post
Share on other sites

Hmm,  long and short addresses......

 

In theory, the short address range is 1-127, and the long address range 1-16383, but most systems only support four digits, so the upper limit is 9999. 

 

BUT,  there are a lot of variations in how short and long are handled by various DCC system makers.   Some treat 1-99 as short and 100-999 as long.  Others treat 1-127 as short and 128-9983 as long (and values above 9983 are not permitted),  others treat 1-127 as short and 01-9999 as long, but reserve some short addresses above 100 for consist management,   etc.. etc..  

 

If you want maximum compatibility and minimum hassle, I recommend the following strategy:    Short addresses 1-99 ,   Long addresses 128-9983  ,  the numbers 100-127 and values more than 9983 are not permitted. 

 

 

- Nigel

Link to post
Share on other sites

I'd follow Nigel's advice, for 2 digit systems, take it as two human readable digits, so 1 to 99.

 

Interestingly, I had something similar with a 4 digit address, 9997, the Sprog would work fine with it, but my Digitax Command Station reserves that address and won't let you select it.

 

Hope you get it sorted.

Link to post
Share on other sites

Digitrax has an upper limit of 9983 for long addresses.

 

This seems at first glance a very strange number to have for an upper limit.

In theory the true upper limit allowed by the NMRA spec (RP 9.2.1) is 10239 (39*256 + 255) so in reality can extend to five decimal digits if the system has a means of inputting (and displaying) five.

The Digitrax limit of 38*256 + 255 = 9983 automatically keeps their four digit number checking software much simpler by disallowing MS byte values over 38 regardless of the LS byte value thus avoiding the possibility of five digits being entered.

Link to post
Share on other sites

This may be a bit off topic but I can't immediately see how you would program a check like this. For example if the user entered the 4 digits 9984?

 

It seems to me easier to count the number of keypresses and only accept the first (or last) 4 - since an individual keypress can't be more than 9 (unless there is a very strange keypad). That would make it trivially simple to accept numbers up to 9999.

 

...R

The Digitrax limit of 38*256 + 255 = 9983 automatically keeps their four digit number checking software much simpler by disallowing MS byte values over 38 regardless of the LS byte value thus avoiding the possibility of five digits being entered.

Link to post
Share on other sites

This may be a bit off topic but I can't immediately see how you would program a check like this. For example if the user entered the 4 digits 9984?

 

It seems to me easier to count the number of keypresses and only accept the first (or last) 4 - since an individual keypress can't be more than 9 (unless there is a very strange keypad). That would make it trivially simple to accept numbers up to 9999.

 

...R

 

Do the checks in binary/hex as you go along.  9983 is 26FF in Hex.  9984 is 2700hex.  Just disallow the 9984 or higher. 

 

With my two different Digitrax throttles, they behave the same.  Type 9984 (or 9985, 9991, etc..) and what appears on the display as loco number is 9983. You still have to press another button to confirm the address selection, so there is scope for a user to change it if they want. The throttle firmware is checking as you type, and if the number is above 9983, it assumes you meant 9983. 

 

 

 

- Nigel

Link to post
Share on other sites

With respect ...

 

That's not the issue.

 

What you say will work if you want to restrict it to 9983.

But it doesn't require you to restrict it.

 

There may be some logical reason why they limit the max to 9983 but the explanation has not been presented yet :)

 

...and you can't check for 9983 (in decimal, binary or hex) as you go along - only after 4 keys have been pressed and the sequence of key presses has been converted into an integer or a string. Whereas you can count keypresses as you go along.

 

...R

 

Do the checks in binary/hex as you go along.  9983 is 26FF in Hex.  9984 is 2700hex.  Just disallow the 9984 or higher. 

 

With my two different Digitrax throttles, they behave the same.  Type 9984 (or 9985, 9991, etc..) and what appears on the display as loco number is 9983. You still have to press another button to confirm the address selection, so there is scope for a user to change it if they want. The throttle firmware is checking as you type, and if the number is above 9983, it assumes you meant 9983. 

 

 

 

- Nigel

Link to post
Share on other sites

With respect ...

 

That's not the issue.

 

What you say will work if you want to restrict it to 9983.

But it doesn't require you to restrict it.

 

There may be some logical reason why they limit the max to 9983 but the explanation has not been presented yet :)

 

...and you can't check for 9983 (in decimal, binary or hex) as you go along - only after 4 keys have been pressed and the sequence of key presses has been converted into an integer or a string. Whereas you can count keypresses as you go along.

 

...R

 

If you want the real reason, suggest you email Digitrax and ask that they pass your question to AJ Ireland (owner of Digitrax, and designer of their equipment) for a definitive answer. 

 

Gordon covered the ease of checking 9983 as a Hex/binary number.  Its also likely to be related to ancient Digitrax kit as their older kit will still work with a newer system.

 

I'm not sure what your point is about key presses.  Clearly the conversion of the sequence of key presses to a number has to be made as each key is typed, and until the last key is typed the final value isn't known.  That's fine.  But converting/limiting as the keys are pressed is pretty simple to implement.

 

- Nigel

Link to post
Share on other sites

  • 1 year later...

I hate to bring back an old topic, but I am having this issue as well.

 

I have 2 locomovites with the Digitrax DZ126 decoder in them. They work fine (I have them set up as a basic consist, address 5013) with the SPROG III in programming mode. In command station mode however, they do not work.

The light will tun on and off, but the motors will not run. Other locomotives work fine, and if I swich back to command station mode these will work again.

 

Any chance you can remeber what you did to resolve your issue wih the command station mode?

Link to post
Share on other sites

I hate to bring back an old topic, but I am having this issue as well.

 

I have 2 locomovites with the Digitrax DZ126 decoder in them. They work fine (I have them set up as a basic consist, address 5013) with the SPROG III in programming mode. In command station mode however, they do not work.

The light will tun on and off, but the motors will not run. Other locomotives work fine, and if I swich back to command station mode these will work again.

 

Any chance you can remeber what you did to resolve your issue wih the command station mode?

 

Before switching from programming mode to command station, select an unused address in the throttle. That will probably fix it.

 

A SPROG throttle in programming mode can only address a single loco, so what do you mean by "basic consist"? Have you set them both to the same address? Is there a reason why you are not using the decoder consist address?

 

Andrew

Link to post
Share on other sites

Strange, I have had this problem with 2 digitrax decoders recently, in fact one is still not sorted. The trouble is I'm not sure how it became 'fixed'.

I reset the decoders to factory settings and started again. In decoder pro they work fine, but in panel pro they will not move, although you can hear the motor powering up but not enough to move it.

As I say got one of them sorted but still the other is affected. Put in a 2 digit address and no problems.

 

??? Sorry no help but lots of sympathy.

 

Ivan

Link to post
Share on other sites

I suppose the Digitrax decoders have not been left in 'sound testing' mode; which, when used on their programmer, allows the throttle to control the sound etc, but appears to diasable the actual drive to the motor/wheels - as presumably not everyone has a rolling road to program locos on.  The functions probably all work too ... so that any sound function alloction could be checked.

 

Referring back to the 2-digit / 4-digit and the problem of 100-127:

Expressnet protocol (Lenz and others) advocates 1-99 for Short Addresses, and 100+ as long addresses. ... this is certainly followed by Roco, for example.

However, the nmra recommendation is to change at 127 ... and, although the ZTC411 uses Expressnet, it follows the nmra guidance here.

SO always be cautious of numbering locos in the 100-127 area .... oh dear - that is how I identify all my Heritage DMUs Classes 101-128....8-(   I'm okay now, I sold my ZTC and only use Roco.

(Whichever was chosen as the MASTER dictated how the Expressnet behaved

 

Other makes adopted differing options: EG: Entry without leading zeroes, below 128 = short address, and ANY address entered as 4 characters eg 0001-9999 is a long address.

 

A further complication might be caused by adding a Software control program ... as it might be affected by how that chooses the 100-127 range.

Link to post
Share on other sites

Yeap - by Basic consist I mean I set them to the same address.

I did that rather than the decoder based advanced consisting only because I had read that the Digitrax decoders running in consist mode worked a bit sporadically with BEMF active; I didn't actually try it though.

 

I did fully restart both the PC running JMRI and the SPROG, whoich would clear any throttle settings, but still the same issue.

 

As far as I know the decoder doesn;t have a "sound testing mode" - at least if it does I don't know how to turn it off/on.

 

Super-throughly cleaning the loco wheels and tracks made it so it will run erratically occasionally in command station mode, still runs flawlessly in programming mode.

 

I notice as well that in command station mode the SPROG sends a single throttle change command, where in command station mode it seems to continually send a steam of commands, even if the throttle position is steady. I am wondering if that means there is a "time out" of some sort and the connection isn't good enough, or is too garbled to deal with the consent stream of commands.

Link to post
Share on other sites

I had originally soldered the power leads to the 2 halves of the loco's split frame.

I tried removing them and soldering the leads directly to the copper wipers to reduce the number of connections in the electrical path - didn't help though.

Link to post
Share on other sites

I notice as well that in command programming station mode the SPROG sends a single throttle change command, where in command station mode it seems to continually send a steam of commands, even if the throttle position is steady. I am wondering if that means there is a "time out" of some sort and the connection isn't good enough, or is too garbled to deal with the consent stream of commands.

 

Corrected above description.

 

It's two different modes, that's why you should select an unused throttle before switching. The issue is that the SPROG continues to send speed packets to the address used in programming mode, based on the last throttle setting, when you switch to command station mode. If you then use the same address in command station mode then the decoder will receive conflicting speed commands leading to exactly the kind of erratic running you are reporting.

 

If it's still a problem after a complete power on/off of the SPROG then are you using address 3? Older SPROGs default to sending speed zero to address 3 and you may still get conflicts when running in command station mode. Newer SPROGs default to address 100.

 

Andrew

Link to post
Share on other sites

Thanks for the help everyone!

 

I did turn the SPROG off and back on, which didn't help. I have the locomotives both set to address 5013.

 

I do have one of them mostly working now. I took it back apart and redid the solder job, re-routed the power pick up lines, and carefully cleaned all the wipers and connections.

It now runs except on 2 sports on my layout, where it stalls and restarts. As before, all my other engines (and that engine when the SPROG is in programming mode) have no trouble with that section of track and I can't see anything wrong with it.

Tomarrow I will rework the other engine and see if it improves as well.

 

It looks like that for some reason, either this engine or this decoder is simply much fussier about reading the command data off the track.

 

This is the only energized frame style DCC locomotive I have done, is that the same for the other folks having this issue?

Link to post
Share on other sites

Good news! Reworking the second locomotive had the same effect as the first. I moved the power lines to the decoder to pick up directly from the wipers rather than the frame, shortened and re-routed them, and cleaned up all the contacts. It now runs reasonably, with the occasional drop  out in specific places (the same spots as the other). I guess I will tear into the track in a bit;  but at least they work well enough I can use them now. 

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...