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

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

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

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

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

Yes mine is the 10MHz one as shown. I bought it as a special through Elector magazine. It included two probes which the one in your link doesn't. There is also a built in waveform generator. If I went again I might up it to a 100 MHz one although the 10 MHz is good enough to show and measure the frequency of the 16MHz crystal on an Arduino. If you wanted to spend more they have models which do mixed signal. ie analog channels and 16 logic inputs. -john

My oscilloscope story: My last job was 15 yrs at a large government research establishment. They occasionally sold off old equipment and I now have a 7704A with a collection of plug ins, a 453A (portable) and my pride and joy a 531A with trolley and many plug ins including a spectrum analyser. My problem was becoming used to using state of the art digital scopes at work and it is hard to go back so now I use a PC based PicoScope and the beautiful old collection gather dust under Amsterdam Centraal. https://www.youtube.com/watch?v=b4KBJ__IvcE The 7704A is the only one I've had to repair...tantalum capacitors gone shorted. They all still work although the valve (tube) based spectrum analyser is too unstable for real use. I recommend the PicoScope. Base model for ~$200 and I was amazed to find it even decodes DCC. With a laptop it is good for floating measurements too. -john

Hi Keith, "Won't the optocoupler be passing the the DCC waveform (basically square) clipped to the level across the back to back diodes (approx 1.2v P-P) through to the next component?" The answer is no because the LTV844 optocouplers use two leds one each way so whichever way the DCC switches one led is on and the phototransistor gets constant light and stays conducting. An optical full wave rectifier if you like. S88 modules (at least the ones I have) use exactly the same arrangement. Thats why a single led opto is necessary to get the DCC signal for decoding. In the real world the DCC transitions have a rise time so there could be dropouts on transitions but it is a few uSec at most. Probably the opto output response time would mask it. Something to check with the oscilloscope some time. I don't have the plots to hand but I did compare rise times of the Lenz LZV100 and the DR5000. The Lenz is very fast and very clean. The DR5000 less so with a slight step at the zero crossing in both directions. I will look up the figures tomorrow. I suppose I will do the final schematic version tomorrow. I worry slightly about leaving all the previous versions there. J.F. wouldn't like it. -john

OK one more go. https://sites.google.com/site/dcctrains/rs-bus-feed/hardware shows how the current source must be. -john

From post #13 23rd July Frederick asked 'Anybody have the schematic for an RS-8?' Well here it is: Only two connections between IC2 and IC1 missing and I'm not to sure about the area around T2, T3 and R11. It should form a 3mA current regulator. Thats it. SWMBO says I have been sitting here too long. -john

Interesting use of IC4 and IC9. IC9 would be on continuously if DCC was present on IN-1 as it is an AC optocoupler. This would 'enable' IC4 to pass the IN-2 DCC to the processor via the 'dodgy' LDT standard circuit. So both DCC connections are required. Only experiment will show if this is just for address setting (when it is essential) or if they have used the firmware to make it a requirement for normal operation. For the future...write Arduino / ATmega code and make my own one, just for the satisfaction. Only if I can completely understand RS Bus signalling. -john