Jump to content
 

Using the Digikeijs DR5000 with TrainController


Recommended Posts

A module only responds once to a change of input. Either one nibble or two depending which inputs change so if (say) module 1 has a change of inputs 1 - 4 it will respond after the first pulse of the next burst that occurs. And not again until something else changes.

While the reply occurs the command station stops sending.

 

What I said in the last two posts was wrong however. I have been looking more closely at what happens at power up and I have seen two (different addressed) modules respond in 1 burst. Still working on clarifying that. I need to check if the length of the burst is stretched by each module nibble received.

All modules respond at least once on power up, spread over several bursts. This would be how the system knows how many/which addresses are connected.

 

Anatomy of Nibbles:

Nibbles are always 9 bits. They start just as the preceding 3mA pulse returns to zero mA. The start pulse pulls the signal (down) to 20mA and I presume that inhibits the command station until the nibble is finished. At the end of a nibble there are always two bits of zero mA before command station pulses resume.

 

I note that 2nd nibbles are only sent if needed but I am not sure if first nibbles are sent if there is only a change in inputs 5 - 8. Still looking.

This diagram shows how nibbles are constructed. The first is nibble 1 with no occupancy in 1 - 4 and the second is nibble 2 with input 8 occupied.post-29679-0-54764400-1470368113_thumb.jpg

-john

Link to post
Share on other sites

Some more answers (I am compiling all this into a word file as a final reference when it is done).

 

The length of module replies gets added to bursts of command pulses.

 

A single command pulse is 93uS current on and 109uS current off.

An empty (no module reports) burst has 7mS current off (pause between bursts) then 130 current on pulses of 93uS each shown as downwards in my diagram.

 

The bits in the module nibbles are 202 uS ie the same as a command pulse cycle so a complete nibble is 11 X 202uS (9 bits plus 2 off bits at the end) = 2.222 mS.

 

A single burst can have more than one nibble (presumably up to 128 nibbles) and each nibble makes the burst 2.22 mS longer.

 

A change in module inputs 1, 2, 3, 4 only sends nibble 1. A change in inputs 5, 6, 7, 8 only sends nibble 2. If a change happens in both groups two nibbles are sent but in different bursts because each address can only send one nibble in a burst.

 

Some more pictures:

All taken with 3 modules attached. Note that the measured of command burst pulses is now 3 times as much.

Interesting to see which point indicates address 1.

 

address 1 input 2 (nibble 1 only)
post-29679-0-36785500-1470378687_thumb.jpg

 

address 2 input 3 (nibble 1 only)

post-29679-0-51664700-1470378701_thumb.jpg

 

address 3 input 6 (so nibble 2 only)

post-29679-0-68165900-1470378722_thumb.jpg

 

all 3 at once (2 X nibble1 and one X nibble2)

post-29679-0-63571200-1470378743_thumb.jpg

 

address 128 input 1

post-29679-0-47402800-1470378771_thumb.jpg

 

Whole burst showing address 1 input 2, address 65 input 3 and address 128 input 6 all triggered at once

post-29679-0-87510300-1470378789_thumb.jpg

 

Only the parity bit left to understand.

-john

Link to post
Share on other sites

Hi John,

 

Great work. 

 

At one point I was intending to design for a friend a "RS to some other protocol" device as the new command station he wanted to use did not support RS but he had numerous RS devices from the previous command station that he still wanted to use.

 

Looks like you are well on the way to making such a device possible.

 

Frederick

Link to post
Share on other sites

  • RMweb Premium

John & Frederick

 

I have attempted (!) to get a similar capture on the RS bus using the DR5000 with an RS-8 & RS-16 connected with all inputs activated.

They were on address 65 and address 90+91  (513 & 713+721 DR5000 style)

This was the result:

 

post-6208-0-57651300-1470436185_thumb.jpg

 

Never had anything in the second pulse window. Should I have had something?

 

Cheers

 

Keith

Edited by melmerby
Link to post
Share on other sites

Hi Keith,

Keep in mind that each module only sends a single (or at most two) nibble reply once when an input change occurs. And any one module can only send one nibble in a single burst.

 

Your trace shows what looks like a single response at either address 90 or 91. I am just judging that from the position in the burst of pulses.

You probably could move the trigger up a bit as it is right at the bottom of the pulse.

 

To get the last plot in my last post I joined all the commons together over 3 modules (I am using switched input LR101s, not current sensing modules). Then I joined a single input from each module into a common bunch. By momentarily touching the group of inputs to the group of commons the modules all send a reply in the same burst.

post-29679-0-89860600-1470438940_thumb.jpg

To capture it I used single trigger mode because after the first one more replies happen due to switch bounce etc.

 

If your module input changes are not all happening at exactly the same moment then you are either looking at the first one to occur (if using single trigger) or else you are looking at the last one to occur if using repeat trigger.  I guess if you are just trying to see that they all work you don't need to trigger and capture them all at once. On the real railway input changes woud not often occur all at the same moment.

I intend to look at the timing on the DR5000 today to compare with the (gold standard) Lenz.

-john

Link to post
Share on other sites

A bit more,

You say you are using modules with all the inputs activated Keith.

Keep in mind that if you wire them that way and then turn the system on they will all report over a few bursts at power on. Then nothing will happen until you change one of the inputs. I also found that the power on reporting is a bit random wrt which module reports first and I saw some reporting more than once. I suspect that because power up involves each internal processor doing stuff they aren't all ready at the same instant. I definitely saw address 3 report before 1 & 2 consistently. Might be something as simple as tolerance of their power supply capacitors leading to reaching the correct voltage a few uS apart.

Also it is easier to see what is happening with low address modules because you can count the burst pulses more easily.

-john

Link to post
Share on other sites

Using LR101 modules with addresses 1, 65 and 128 seems to work OK on my DR5000. The display in RS monitor shows them correctly except the line for address 128 shows a start of 017. The 1000s digit is missing as it should be 1017. However it shows correctly when hovered over and they come up correctly in TC.

A few pictures with notes:

Triggering on the nibble was hard because the start of the burst often has a big spike on it. I got it to trigger by setting a negative pulse width of 150 uS in the advanced options.

Address 1 input 2 with detail labels
post-29679-0-39673400-1470453838_thumb.jpg

 

Address 65 input 3

post-29679-0-38533900-1470453853_thumb.jpg

 

 

Address 128 input 7 (shows 2nd nibble bit set)

post-29679-0-00223200-1470453867_thumb.jpg

 

All 3 switched at once (1, 65 and 128)

post-29679-0-59449300-1470453901_thumb.jpg

 

Address 1 with inputs 2 and 7 switched together showing 2 nibbles on consecutive bursts

post-29679-0-50838400-1470453920_thumb.jpg

 

Now for the possibly bad news (compared with the Lenz Station)

The burst pulses have a lot of jitter in their length resulting in a large cumulative effect at the end of the burst.

 

Persistence trace of start of burst accumulated over 20 seconds

post-29679-0-13743900-1470453958_thumb.jpg

 

consecutive burst starts...note occasional big spikes and variable pulse widths

post-29679-0-73308100-1470453973_thumb.jpg

 

consecutive burst ends. The trigger markers are at exactly 27mS from the burst start.

post-29679-0-48496100-1470453989_thumb.jpg

 

All this doesn't faze the LR101 modules and everything works. Who knows about RS8 modules though?

-john

 

 

Link to post
Share on other sites

  • RMweb Premium

John

 

I had the two modules connected but not powered up, then I connected the AC supply and tried to trigger what was first to report.

Interestingly the RS bus monitor on the DR5000 nearly always reported the RS-16 (addresses 90+91) before the RS-8 (add 65) which would suggest the RS-8 is slower at reporting on power up.

 

Cheers

 

Keith

Link to post
Share on other sites

Hi Guys

 

I just read through all the discussion so far, but at the moment it won't help me.  I received notification that my DR5000 and DR5033 arrive back to digikeijs seven days ago, so far not a word from them even to acknowledge that they had received it.  Great service!

 

Regards

 

Anthony J

Link to post
Share on other sites

My saga with the DR5000 continues.,Not sure whether it is a phasing issues or something else! The other day I turned on the system and tested some turnouts (LDT decoders) with TC..nothing. I turned on the check boxes within track outputs inthe the dr5000 interface. I changed the phase and still nothing. Reprogram the ldt modules and they work all bar two which I physically had to change the connections around on the J and K input. The system now works. All control and programming viaS1 in the ldt modules, button and within TC. I have one DR 4018 turnout module which was not effected, it worked fine! I never had these issues with my old old zimo mx1. I'm considering going to a Roco Z21..I'm just hoping I'm not going to have issues the the DIgikeijs s88n occupancy modules.?.. Any thoughts crew??

Link to post
Share on other sites

My saga with the DR5000 continues.,Not sure whether it is a phasing issues or something else! The other day I turned on the system and tested some turnouts (LDT decoders) with TC..nothing. I turned on the check boxes within track outputs inthe the dr5000 interface. I changed the phase and still nothing. Reprogram the ldt modules and they work all bar two which I physically had to change the connections around on the J and K input. The system now works. All control and programming viaS1 in the ldt modules, button and within TC. I have one DR 4018 turnout module which was not effected, it worked fine! I never had these issues with my old old zimo mx1. I'm considering going to a Roco Z21..I'm just hoping I'm not going to have issues the the DIgikeijs s88n occupancy modules.?.. Any thoughts crew??

 

The Z21 doesn't have (as far as I know as of today) support for the RS bus.

 

I only use my Z21 to run trains and program mobile decoders. All sensing and control issues are via a standalone LocoNet using a variety of RR-CirKits devices.

 

All works well.

 

 

I have a number of Digikeijs modules and they all work fine with the DR5000.

 

I consider the RS bus support of the DR5000 a work in progress - so I am not upset that I am having problems - but I am only bench testing the DR5000 at this point.

 

The LDT stuff is a little suspect in my mind - odd circuity - at least in the RS-8 units.

 

Frederick

Link to post
Share on other sites

Hi Guys

 

I finally received advice that both my items are being looked at, here's hoping. 

 

I have an LDT S-DEC-4DC Magnetartikel decoder that operates Turnout 1 to 4 and another from 5 to 8  then all the rest are LENZ  LS150's starting at 9 and so on, just wondering how I am going to program these on the DR5000?

 

Regards

 

Anthony

Link to post
Share on other sites

Anthony,

If they are programmed (meaning have had their internal DCC addresses set) then you don't have to re-program them to use a different system. They will still respond to the same address. If not the problem isn't the decoder. The decoder address is stored in non-volatile memory in the decoder.

I wouldn't worry about it until you get your DR5000 back.

My DCC decoders, a mix of Lenz LS150s, a couple of LDT ones like yours, a couple of Veissmann ones and several home made Arduino ones all worked fine with my DR5000 and with my z21 after initially having their addresses set (years ago) with my Lenz system.

The only complications I ever had were having to turn off the 4 address offset in the z21 when installing it and (as mentioned above) making sure the LDT ones had J and K the right way around.

As also discussed extensively above, and alluded to by Frederick, the LDT DCC input arrangement on both their turnout decoders and their RS8 feedback modules is a bit weird and seems to only work in ideal conditions. I said before I won't be buying any more of them.

-john

Edited by john barry
Link to post
Share on other sites

Hello Guys

 

today is a better one.  I have just heard back from digikeijs, and what was wrong with my DR5000 and DR5033 as follows.

 

We examined both the DR5000 and the DR5033.
Inside the DR5000 we found one of the voltage fuses is burned. Therefor there is no voltage on 
the LocoNet and B-Bus connections. 
This can only be caused by some external voltage that was placed on the LocoNet or B-Bus connectors.
But this we have to examine inside the DR5000 log history. 

So it is not the DR5033 Booster. However we will also ship a new DR5033 to be 100% sure.
I will also be shipping a new cable just to make sure there is nothing wrong with that one.
Please make sure only to use official LocoNet cable.

 

They have also very quickly posted two new items to me, so it won't be long until I can get it all going again.  This time I am going to set it up on a computer in my office and try the LS150's and RS-8 first, then with TC, once it is all going and importunately I do understand it I will introduce it to my full layout.

 

Thanks John for the info, I look forward to seeing it all working correctly.

 

Regards

 

Anthony

Link to post
Share on other sites

  • RMweb Premium

My findings

The LDT RS-8s work fine with the JK either way round when using my Lenz setup*, they don't however (in my set-up) work correctly with the JK reversed on the DR5000.

The RS-8s can be programmed correctly on both the DR5000 or the Lenz system with JK correctly phased but not with JK reversed on either system.

 

* due to an accident at birth my layout has J&K reversed, I only really found out it was wrong when I experimenting with the DR5000.

This error will be corrected!

 

Although I haven't yet used a RS-16 in anger, it would appear to exhibit the same characteristics.

 

Keith

Link to post
Share on other sites

My findings

The LDT RS-8s work fine with the JK either way round when using my Lenz setup*, they don't however (in my set-up) work correctly with the JK reversed on the DR5000.

 

Keith

 

The "polarity" of the J-K connections should not matter. I cannot understand why they do. 

 

Frederick

Link to post
Share on other sites

Frederick wrote 'The "polarity" of the J-K connections should not matter.'

I agree totally Frederick but a look at the waveform at the input of the DCC signal to the processor (on LDT modules and decoders) shows that it probably does. 'Normal' designs pass a clean square J-K waveform to the processor and process all transitions as interrupts in a way that makes the outcome independent of J-K polarity. We don't have access to the code used by LDT modules but what's the bet they only look at one transition?

 

Keith wrote "The LDT RS-8s work fine with the JK either way round when using my Lenz setup*, they don't however (in my set-up) work correctly with the JK reversed on the DR5000."

Do you mean that if they are correctly programmed they still don't work for detecting occupancy unless the J-K polarity is correct? That is even worse because the J-K waveform has no relevance to occupancy or what transpires on the RS Bus. If LDT has designed them to use the actual J-K waveform for some purpose while detecting occupancy then I am amazed. Hard to imagine why.

 

And of course it is made worse by the less than ideal J-K signal from the DR5000.

-john

Link to post
Share on other sites

I have received an email from Peter Littfinski of LDT fame he says his decoders less than 5 years old in design, will detect automatically a phase change and deal with it appropriately. I never had this issue with my old zimo MX1, so I know it's the Dr5000

Link to post
Share on other sites

  • RMweb Premium

Frederick wrote 'The "polarity" of the J-K connections should not matter.'

I agree totally Frederick but a look at the waveform at the input of the DCC signal to the processor (on LDT modules and decoders) shows that it probably does. 'Normal' designs pass a clean square J-K waveform to the processor and process all transitions as interrupts in a way that makes the outcome independent of J-K polarity. We don't have access to the code used by LDT modules but what's the bet they only look at one transition?

 

Keith wrote "The LDT RS-8s work fine with the JK either way round when using my Lenz setup*, they don't however (in my set-up) work correctly with the JK reversed on the DR5000."

Do you mean that if they are correctly programmed they still don't work for detecting occupancy unless the J-K polarity is correct? That is even worse because the J-K waveform has no relevance to occupancy or what transpires on the RS Bus. If LDT has designed them to use the actual J-K waveform for some purpose while detecting occupancy then I am amazed. Hard to imagine why.

 

And of course it is made worse by the less than ideal J-K signal from the DR5000.

-john

I must do my checks again but when I connected the DR5000 to my layout which has 13 RS-8s working correctly with a Lenz system (but with J&K reversed to what should be the normal) I got no indication of occupancy with TrainController.

I reversed J&K and Presto all the RS-8s would show occupancy.

Unless something wasn't making proper contact it appears the RS-8s weren't compatible with the DR5000 unless J&K were correct.

 

As regards programming mode, my 2016 purchased RS-8 cannot be programmed unless J&K is correct (Lenz or DR5000) this is the same as all the others, most of which have the same revision number on the PCB.

 

Keith

Link to post
Share on other sites

 We don't have access to the code used by LDT modules but what's the bet they only look at one transition?

 

-john

 

Since occupancy is being indicated by current flow, at what INSTANT the current is flowing is not really the issue. 

 

I use RR-CirKits WatchMan devices and they use a sensing coil that goes around one of the track feeder wires - no connection to the DCC track power at all.

 

And it works just fine regardless of what feeder wire the coil is on or if the track is powered through an "auto-reverse" unit.

 

That is how it should be.

 

Frederick

Link to post
Share on other sites

Agree entirely Frederick.

I use the series diode and AC optocoupler method almost exactly like the circuit of the RS8. I have a series resistor and a 1 uF capacitor across the input to the optocoupler so there is no trace of the DCC on the output side, just a solid transistor switching open or closed.

 

The observation that detection by the RS8 is J-K dependent (my reading of what Keith said) makes me wonder though.

 

My mention of transitions above was in regard to when the DCC IS being used ie in programming mode or on an accessory decoder.

-john

Link to post
Share on other sites

  • RMweb Premium

Right.

Double checked wiring and terminal blocks.

 

I have done all the same tests as I did before and the DR5000 works perfectly with the RS-8s and TrainController, with the J&K in either phase.

Whats more I now have the track current reading back, which I haven't seen for a couple of weeks!

 

Keith

Link to post
Share on other sites

  • 5 months later...

Hello

 

I have brought this topic back to the top because I have received from digikeijs a new DR5000 and also a booster DR5033 to replace the faulty ones that I had. 

 

I have been running a Lenz system and have just now connected the digikeijs gear.  After many attempts at downloading the latest update with missing drivers I finally have it running with Lenz USB on COM9 and Loconet on COM7, the DR5000 is on COM8.  I have power on both top and bottom tracks, I can run trains and all points work (LS150) etc.  I have changed TC Gold over to the new system but it does not show up any RS-8 blocks/sensors.  I am using a Roco MM on the Xpress net bus.  The J is on the left of the command Station looking from the back of it, and I have tried to copy the same for the booster, this did show a short at the start from the booster but I just swapped the J and K wires around on it and that went away.

 

Any comments welcome.

 

Regards

 

Anthony

Edited by Anthony James
Link to post
Share on other sites

Hello

 

I have read what there is of a manual on the digikeijs site, they seam to say that Loconet should be on COM7 which it is, Xpress net on COM8 which it is not, and DR5000 on COM9 which it is not?

 

Regards

 

Anthony

 

Hi Anthony,

 

What COM ports are used can be effected by what COM ports are available.

 

You can use Windows Device Manager (see Control Panel) to see what COM ports are assigned to what external devices.

 

See the attached screen shot of Device Manager on one of my computers. You can see that COM3 is connected to an Arduino UNO 3.

 

If I had TWO UNO 3 devices connected I would see both listed, each to a different COM port, and I would have to disconnect one of them to see which COM port went to which.

 

Frederick

post-29673-0-96279900-1484542905.jpg

Edited by fcwilt
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...