Using the Digikeijs DR5000 with TrainController

[melmerby]

Hi Keith,

 

Given that I have a computer (three actually) at my work bench I was thinking that a Pico as standard equipment on the bench might be nice.

 

In the past I had a HP Logic Analyzer which was much used. So I was thinking about one of the MSO versions of the Pico.

 

Still thinking.

 

 

I was working today with the DR5000 along with a DR4018 and a DR4024 making sure that they worked as advertised.

 

I noticed that the DR5000 doesn't display the track current very often. I've seen it come up a few times but then it goes back to zero.

 

Any track current displayed on your unit?

 

 

Thanks.

 

Frederick

Hi Frederick

 

The Pico is a nice device and, for me, the fact that it is designed and made in the UK rather than China, was a welcome bonus.

The factory is in Cambridgeshire and the Amazon purchases are delivered direct from them  by express carriage, hence the 24hr UK service

 

Re your question whether any track current is shown:

It did when I first tried it (see the post with the DR monitor window above)

I was surprised that about 1200mA was being used without any running but there about 50 stall motors and 35 locos sitting on the track as well as a couple of accessories and a turntable and transfer table.

At that point I couldn't get the RS bus monitor to work

 

Since then I have updated the firmware, reversed the JK connexion to layout the RS bus works correctly but now 0mA is recorded!

 

Looks like possibly something to do with the update?

 

Cheers

 

Keith

Edited July 28, 2016 by melmerby

[Anthony James]

Hi Guys

 

I have just recently found this site and topic.  Some of you already know my problem with digikeijs but here is a quick update.  I received their DR5000 Command Station and booster DR5033 about 6 weeks ago.  The booster just never worked, there was no power on the output, I have contacted them many times about it but received a few emaisl which took at least 8 days to get a reply, ths last one being to just try the new firmware update.  I recently had had enough and sent both items back to them, today I received this back from Rory Keijs.

 

Dear Mr. Hedges,

Ok no problem. We will inspect both products when they arrive. 
We also want to know what is wrong with them.

I will update you when they arrive.

Kind regards,

Roy Keij
DIGIKEIJS

 

Interesting!.  I could also never get my RS-8's to work with the DR5000 so I will be following this thread to see how it all goes, some useful information so far.

 

Regards

 

Anthony

 

   

 

[melmerby]

 

Hi Guys

 

I have just recently found this site and topic.  Some of you already know my problem with digikeijs but here is a quick update.  I received their DR5000 Command Station and booster DR5033 about 6 weeks ago.  The booster just never worked, there was no power on the output, I have contacted them many times about it but received a few emaisl which took at least 8 days to get a reply, ths last one being to just try the new firmware update.  I recently had had enough and sent both items back to them, today I received this back from Rory Keijs.

 

Dear Mr. Hedges,

Ok no problem. We will inspect both products when they arrive. 

We also want to know what is wrong with them.

 

I will update you when they arrive.

Kind regards,

Roy Keij

DIGIKEIJS

 

Interesting!.  I could also never get my RS-8's to work with the DR5000 so I will be following this thread to see how it all goes, some useful information so far.

 

Regards

 

Anthony

 

   

 

Welcome to RMWeb Anthony.

 

I've been on here much longer than Freiwald forum and find it's a much better place to get discussions going.

Herr Freiwald doesn't like the subject to wander much before he stops it!

As you can see Frederick (Wilt) and John (Barry) have also joined as well as Johnsy1975.

 

As regard the RS-8s, there is definitely a problem with the JK phasing as you cannot program them with it reversed, although they work just fine with Lenz kit after it's done.

The DR5000 seems to be even more critical and until I swapped to track output I had problems.

I have concluded that, although unmarked, the LH output (with the DR5000 facing up) is J.

Since then I can run my layout with the DR5000 instead of the Lenz setup just by using the Lenz USB setting and the correct COM port.

 

I have two LDT DB-4 boosters, which when connected via the Roco 4 pole PB bus do work but do not show up in the booster monitoring window!

 

IMHO the DR5000 is still a work in progress as regards the firmware/software

 

Cheers

 

Keith

[Johnsy1975]

Hello all,

 

I have updated to the latest firmware (as suggested by Roy DIgikeijs) on the DR5000 as advised with my phasing issue. I have done this. I was also told to turn off all the tick boxes in the track output section of the dr5000 of interface, which I did! These refer to auto phase changes when a short occurres. I'm still testing this!

 

After updating to the new firmware I had to reprogram all of my ldt turnout decoders! A lot of frustration regarding the above! The next step is to start using s88 block occupancy modules by DIgikeijs on the dr5000 output! I'm hoping i don't have the same issues that you gentlemen have had with rs8 hardware

[john barry]

Hi All,

 

Johnsy

When you say you had to re-program all your LDT turnout decoders do you mean you had to re do the decoders by pressing the button on each and sending a turnout command OR do you mean by changing the addresses in Train Controller?

I am curious what the update did. I can't see how updating the firmware could by itself change the address set in a decoder. Surely this can only happen by pressing the button and sending a new address?

Were the decoders working correctly with the DR5000 before the firmware update?

The only possibility I can think of is the mystical address offset of 4 that I encountered with my z21. There is a selection box for that in the DR5000 setup and maybe it's state changed with the update, effectively shifting all the addresses (output by the DR5000) by 4. Maybe we will never know although you can't be Robinson Crusoe.

 

On the subject of LDT being sensitive to DCC polarity the PicoScope (and I am sure the TD series Tek) shows that the waveform from the DR5000 is less ideal than from my Lenz system. Slower transition times with a 'wobble' where it crosses the baseline.

I reckon that the strange coupling of the optocoupler to the processor input in the LDT decoders and RS-8s would have a slow transition in one direction because of the 220K resistor used as pull up and their software would depend on that somehow. Possibly it would then be sensitive to the slower, less clean waveform of the DR5000 as well. Just speculating. I won't be buying any more LDT devices that require DCC input.

I always find the NMRA DCC standard hard to read but it would be interesting to see what it has to say about waveform limits.

-john

[melmerby]

Hi All,

 

Johnsy

When you say you had to re-program all your LDT turnout decoders do you mean you had to re do the decoders by pressing the button on each and sending a turnout command OR do you mean by changing the addresses in Train Controller?

I am curious what the update did. I can't see how updating the firmware could by itself change the address set in a decoder. Surely this can only happen by pressing the button and sending a new address?

Were the decoders working correctly with the DR5000 before the firmware update?

The only possibility I can think of is the mystical address offset of 4 that I encountered with my z21. There is a selection box for that in the DR5000 setup and maybe it's state changed with the update, effectively shifting all the addresses (output by the DR5000) by 4. Maybe we will never know although you can't be Robinson Crusoe.

 

On the subject of LDT being sensitive to DCC polarity the PicoScope (and I am sure the TD series Tek) shows that the waveform from the DR5000 is less ideal than from my Lenz system. Slower transition times with a 'wobble' where it crosses the baseline.

I reckon that the strange coupling of the optocoupler to the processor input in the LDT decoders and RS-8s would have a slow transition in one direction because of the 220K resistor used as pull up and their software would depend on that somehow. Possibly it would then be sensitive to the slower, less clean waveform of the DR5000 as well. Just speculating. I won't be buying any more LDT devices that require DCC input.

I always find the NMRA DCC standard hard to read but it would be interesting to see what it has to say about waveform limits.

-john

My spare RS-8 which I was using to test the DR5000 did not change address after the software/firmware update.

It was 65 before and 65 afterwards. (513 -520 in the DR5000 addressing range)

Like this:

It worked fine on the DR5000 but TrainController was not getting occupancy information.

After the update and after reversing J&K it all works as it should.

Before the update and J&K reversal I could not drive my layout, afterwards it works fine.

 

I have a spare RS-16 and will try that as well. I assume the RS bit is the same as the RS-8 but it reserves two consecutive address blocks instead of one.

 

Considering that after getting the phasing/firmware right I now have 15 RS-8s all reporting occupancy correctly to the DR5000 I don't feel there is much of a problem with using them.

 

Keith

Edited July 31, 2016 by melmerby

[melmerby]

As promised here is the RS bus monitor window when using a LDT RS-16

 

This uses two consecutive address blocks of 8, in this case I have used Lenz Addresses 90 & 91.

These equate to 713 & 721 in the DR5000 adress space.

 

 

Also is the Traincontroller switchboard with 16 contact indicators shown set to these addresses:

 

 

I also had a loco running:

 

 

But moitoring the track it still shows 0mA:

 

 

As you can see it all works just fine.

 

Cheers

 

Keith

 

 

Edited August 1, 2016 by melmerby

[Johnsy1975]

Hi john, I had to push the button to re program them. I only used my multimaus to test the decoder before not TC. After I did this they worked again! I did this this with my only DIgikeijs turnout decoder too

[Johnsy1975]

Ps all my ldt occupancy modules on the ldt s88 interface had no issues showing occupancy on TC.?

[john barry]

That makes sense Johnsy.

The S88 modules are a different bus and not involved in DCC addressing issues.

 

The Multimaus is Roco so probably has their 4 address offset. This means that if you originally set them up with the Multimaus they would have a 4 address offset on other systems. I can't remember if it is +4 or -4.

So if you then connected them to the DR5000 they would not respond to the same address unless you went through the address setting procedure again via the DR5000.

Of course if you then used the Multimaus they would have an offset the other way until re programmed again. (I am assuming the Multimaus is the same this way as my z21 was).

 

TC doesn't know about any of this and the way I discovered it was by noticing that a turnout connected to the z21 switched at the same time as one with an address 4 away was switched by TC. There is a setting in the z21 (and in the DR5000) to turn this offset on or off. The default for Roco is offset on.

 

It is confusing but doesn't really matter as long as each decoder is programmed via the system it will be used on. No idea why Roco does this unless it is some legacy thing.

-john

[john barry]

Hi Frederick and others,

I just got this PicoScope offer from Elektor  http://us8.campaign-archive2.com/?u=4ecb620f8ed264d1d84aa0981&id=a86d4eb68d&e=40ef083a7f

in case you were thinking of getting one.

 

Also Frederick my post above got me thinking about your RS-8 problem, keeping in mind that you use a Z21. Could it be that you have set the RS Bus address with the Z21 and they thus have a 4 address offset when used with the DR5000? Just a thought.

-john

[MikeH_83]

 

RS-16.JPG

 

 

 

I have no idea what those windows mean or how they work. lol

 

I have a dr5000 and the demo of train controller and so far (bar my power supply being faulty and away for repair/replacement) it seems to work together well, that's using the digikeijs loconet occupancy detectors and the digikeijs boosters.  Then again iv'e only got around to doing the fiddleyard and now that's gotta change again

[fcwilt]

 

Also Frederick my post above got me thinking about your RS-8 problem, keeping in mind that you use a Z21. Could it be that you have set the RS Bus address with the Z21 and they thus have a 4 address offset when used with the DR5000? Just a thought.

-john

 

The LDT units were purchased for testing with the DR5000 and were never used with another system.

 

The DR5000 now sees the units after I found that both of the INx connections need to be made for the RS-8 to work.

 

The remaining problem is that the units appear to be defective - the first four sensors always how up in the DR5000 monitor screen as unoccupied and the last four always show up as occupied.

 

I scoped the inputs to the processor chip in the RS-8 and they are getting the correct signals. Somewhere between that chip and the DR5000 the information is getting mangled.

 

Thanks.

 

Frederick

[melmerby]

I have no idea what those windows mean or how they work. lol

 

That is showing that the DR5000 is recognising occupancy

Row starting 713 equates to Lenz address 90 input 1

If you hover the mouse over the address it gives the Lenz (and A.N.other) equivalent.

 

Cheers

 

Keith

[melmerby]

The LDT units were purchased for testing with the DR5000 and were never used with another system.

 

The DR5000 now sees the units after I found that both of the INx connections need to be made for the RS-8 to work.

 

The remaining problem is that the units appear to be defective - the first four sensors always how up in the DR5000 monitor screen as unoccupied and the last four always show up as occupied.

 

I scoped the inputs to the processor chip in the RS-8 and they are getting the correct signals. Somewhere between that chip and the DR5000 the information is getting mangled.

 

Thanks.

 

Frederick

Hi Frederick

 

Were they purchased new?

If so they have a 2 year warranty (at least in the EU/UK)

 

Looking at John's circuitry it doesn't look as if you could damage them easily with an incorrect connection.

 

I've even put 18v AC onto the RS output (Accidently) and it didn't suffer!

 

Cheers

 

Keith

[MikeH_83]

That is showing that the DR5000 is recognising occupancy

Row starting 713 equates to Lenz address 90 input 1

If you hover the mouse over the address it gives the Lenz (and A.N.other) equivalent.

 

Cheers

 

Keith

 

Ah thanks Keith!  I will check it out on my system when I boot it up next.

 

Cheers

[melmerby]

Hi All,

 

On the subject of LDT being sensitive to DCC polarity the PicoScope (and I am sure the TD series Tek) shows that the waveform from the DR5000 is less ideal than from my Lenz system. Slower transition times with a 'wobble' where it crosses the baseline.

-john

Hi John.

 

Just did a comparison of the two waveforms and attempted DCC decoding as well

 

Lenz:

 

DR5000:

 

I noticed that the Picoscope couldn't resolve the DCC signal as well on The DR5000 as with the Lenz only managing about 10-15% success compared with 50% or more with the Lenz signal.

 

The Lenz system had my whole layout hanging on it and still generally had a good, clean risetime.

The Dr5000 only had 1 x RS16 and 1 x loco (but not running)

 

Particularly noticeable with the DR 5000 were the frequent steps in the rising & falling edges.

The average frequency of the the DR5000 was just over 5kHz whilst the Lenz was was over 7kHz!

 

Keith

Edited August 2, 2016 by melmerby

[john barry]

So the big question is does the DR5000 meet NMRA DCC standards? And similarly do LDT DCC decoders meet them?

I have gone back to using my Lenz system to run trains some time ago (for other reasons) after using the DR5000 track output to drive the Lenz units as boosters with a home made CDE interface.

That gave me the benefit of the good waveform. I never looked at the actual frequency / pulse width of each.

Without actual knowledge I would assume (dangerous I know) that the standard would specify positive and negative widths rather than frequency because the frequency is not stable from moment to moment.

Given that (surely) the signal timing would derived digitally it is hard to see why there would be a difference of 5 / 7 between systems. I bet the Lenz is spot on!

 

Frederick, You use the plural to describe your RS-8(s). Does that mean you have more than one with exactly the same problem? Maybe still an RS-Bus problem even if the units are recognised? Time to Google Arduino RS Bus analyser

-john

[john barry]

So here it is:-

s-9.1_electrical_standards_2006.pdf

 

It covers up time, down time and aberrations at the crossover.

Meanwhile I am applying the PicoScope to my RS-Bus...

-john

[fcwilt]

 

Frederick, You use the plural to describe your RS-8(s). Does that mean you have more than one with exactly the same problem? Maybe still an RS-Bus problem even if the units are recognised? Time to Google Arduino RS Bus analyser

-john

 

Yes two new units, assembled by LDT, both used only with the DR5000, both exhibiting the exact same problem.

 

Frederick

[john barry]

The Big RS-Bus Explanation...a work in progress. Corrections, clarifications and questions welcome.

Maybe this should be a new blog. Here it is for the moment.

 

Hardware Details

(all measurements taken on a Lenz LR101 module and a Lenz LZV100 command station)

Actual circuit details may be different according to manufacturer etc.

 

Each feedback module has two current regulators. A 3mA one for receiving data and a (approx) 20 mA one for sending data.

This circuitry is optically isolated from the rest of the module.

 

The central station has a 12V DC supply and an input circuit for detecting the 20 mA current as an incoming signal.

The 12V +ve side is connected to R on the bus. S from the bus is connected to 12V -ve side (ground) via the detector circuit and with a switching transistor in parallel for sending from the central station

When T1 in the central station is turned ON 12V is applied to the RS circuit and each connected module draws 3mA. This turns ON the (RH) incoming optocoupler in each module.

When any module turns on it's (LH) output optocoupler 20 mA flows in the RS circuit and this turns on T3 in the command station.

The control and timing of what goes on is done by processing in both the command station and modules.

 

Signal Details

In all following diagrams current is shown downwards from zero. The current was measured as voltage across a 100 ohm series resistor in the R leg using a PicoScope 2204A.

When nothing is happening the command station sends bursts of 130 pulses with a 7 mS gap between bursts.

Pulses are nominally 93 uS on and 107 uS off.

 

When a module has something to say it counts the incoming pulses from the beginning of the burst and then inserts it's reply after it's own address is counted.

This is a module with address 1 reporting that it's first input is occupied.

 

Modules only make reports at power up or when an input changes state. I am not absolutely sure yet but I think only one report is made for each burst of command station pulses.

If no inputs are occupied or inputs 1 - 4 are occupied then a single report (nibble) is made. If inputs 5 - 8 are occupied then a second nibble is sent in the following burst of pulses.

As an example, with 3 unoccupied modules connected (addresses 1, 2 and 3) when the system is powered up then each of the first three pulse bursts gets a report from one of the modules. Then nothing happens until an input is changed on one of the modules.

 

The following is a series of plots with a single module connected as address 1.

The first is with no inputs then each has only one input occupied at a time.

 

And these are with a single module using address 3. The last two show the two nibbles in use.

 

There was some tricky scope triggering to aquire all these.

 

Note that the nibbles also contain start bits, parity bit and a bit showing which nibble it is.

 

Enjoy! Time to start work on an Arduino RS-Bus module.

-john

 

 

 

 

 

[fcwilt]

Hi John,

 

I may be not seeing things correctly but it looks like the response from the module is stomping on some of the pulse train from the command station.

 

Is that correct?

 

If so how do other modules with higher addresses get their chance?

 

Frederick

[john barry]

Hi Frederick,

From what I have seen so far only one module reply happens per burst of pulses. I am just looking at some code © I found for a module project and it states this in the comments but of course that is not the 'official' Lenz line which we may never know.

I haven't yet seen in practice a second module respond in the same burst but I will experiment further.

When a module reply starts the command station suspends the burst but then continues it after. Whatever happens it then resumes the burst so maybe another module could reply. From the module design pov it wouldn't matter if multiple responses (in a burst) were acceptable by the command station but never implemented by modules.

I will try two modules with a low and a high address switching an input simultaneously and see what happens.

 

I was wondering if your RS8 problem might go away if you tried address 1...worth a try. The thinking being cumulative timing inaccuracy in the DR5000.

I know what the manufacturers say but I still don't understand the need to start RS addresses at 65. What possible conflict could there be with turnout decoder addresses? Even if using turnout feedback sensing it would only be for neatness that the addresses would have to line up with the DCC address of the turnout?

-john

[john barry]

A bit more Frederick,

I did observe (noted in post) that when I power it up with 3 sequentially addressed modules connected they report their status on three consecutive bursts, not in the one burst which tends to confirm the one response per burst theory. Just the firmware in the modules keeping track of what is happening.

Also I noticed above that when I typed the letter "c" meaning type of code it came out as a copyright symbol. The first thing I do with a new cell phone is turn off autocorrect!

-john

[fcwilt]

A bit more Frederick,

I did observe (noted in post) that when I power it up with 3 sequentially addressed modules connected they report their status on three consecutive bursts, not in the one burst which tends to confirm the one response per burst theory. Just the firmware in the modules keeping track of what is happening.

Also I noticed above that when I typed the letter "c" meaning type of code it came out as a copyright symbol. The first thing I do with a new cell phone is turn off autocorrect!

-john

 

I wonder how the first module to respond knows not to respond on the next burst(s)?

 

Do they "learn" what other modules are present and yield to one another in round-robin fashion?

 

Curious.

 

Frederick