john barry

I recently spent some time converting an old Marklin 7186 M-track turntable to indexed control using an Arduino. This allows me to use it with automatic running under TrainController. Description and youtube video attached. https://www.youtube.com/watch?v=aXwNfM7zvxg Turntable-Upgrade.docx

Hi, As Frederick says connection of the DR5000 to the PC allocates 3 usb COM ports. These can be seen in Windows Device Manager. They are Lenz Digital Plus, Loconet and the DR5000 tool. The DR5000 tool (without reference to TC) will show which ports are used and you can then select them in TC under Set Up Digital Systems. TC Bronze allows 2 digital system connections which is fine as you don't connect it to the DR5000 tool. I have tried it in the past and it works fine. (I normally use TC Gold with a DR5000 and other systems). Also you can download and try out TC (any colour) for free as a demo. It will connect to your system for 15 minutes. -john

Wow a blast from the past. I just enjoyed skimming through it all again. I still use the DR5000 but only to deal with my S88 detectors. It seems to do this OK. I use the Lenz LZV100 plus a booster to run trains because it has perfect output waveform and seems indestructable. I also use it for a string of RS Bus occupancy modules (Lenz LR1) because I already had them. It does this without any problems. I run a separate DCC bus from a z21 to operate accessories. I am just starting to experiment with LocoNet and intend to use the DR5000 for this too. My summary of the issues:- (as of 2017...I haven't checked since) DR5000 has substandard DCC waveform and also it's DCC output voltage is a bit variable affecting the speed of some locos. From the analysis done earlier it's RS Bus timing might not be good either. LDT detectors and decoders are (or were) very sensitive to DCC polarity and waveform. The polarity issue doesn't matter for me as I use 3 rail but would be difficult with 2 rail reversing loops and polarity switching. Lenz is the gold standard. The waveforms are perfect and their accessory decoders seem to work well with J-K either way around. My own Arduino decoders are pretty good but not as good as the Lenz ones with J-K reversed. This could probably be improved with attention to the actual packet handling library stuff but I just use it as downloaded. I am currently enjoying the battle of converting an old Marklin turntable (M Track with a motor, solenoid and locating pin arrangement but no sensing) to fully automatic using Hall sensors and an Arduino. The idea is to use it fully automatically with TrainController. It is looking pretty good. -john

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

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

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

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 Address 65 input 3 Address 128 input 7 (shows 2nd nibble bit set) All 3 switched at once (1, 65 and 128) Address 1 with inputs 2 and 7 switched together showing 2 nibbles on consecutive bursts 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 consecutive burst starts...note occasional big spikes and variable pulse widths consecutive burst ends. The trigger markers are at exactly 27mS from the burst start. All this doesn't faze the LR101 modules and everything works. Who knows about RS8 modules though? -john

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

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

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) address 2 input 3 (nibble 1 only) address 3 input 6 (so nibble 2 only) all 3 at once (2 X nibble1 and one X nibble2) address 128 input 1 Whole burst showing address 1 input 2, address 65 input 3 and address 128 input 6 all triggered at once Only the parity bit left to understand. -john

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

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

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

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

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