Is DCC++ as a programmer 'sensitive' ?

lyled1117 Jun 18, 2017

  1. lyled1117

    lyled1117 TrainBoard Member

    42
    21
    8
    Firstly, I haven't had time to test this but on a few decoders and a few computers, but ....

    I have a DCC++ system built on an Uno and an Arduino Motor Shield. I am using the original software that has only been tweaked to raise the mainline current threshold, otherwise it is 'stock'. It works the mainline fine. However, I am getting mixed results with different brands of decoders when it comes to programming. I am hoping because of the open source nature of the DCC++ system that there may be refinements for the device that helps fix my issue.

    This has only been tested with a small number of decoders and on different computers at different locations, but with the same system in all cases. I am not getting consistent results reading decoders and am hoping there may be some 'dialing-in' that may be done to get consistent results. Before I go any further, I realize that I have yet to test the same decoder on all four computers I have used this unit on so this *could* indicate a computer setting as the actual problem. I'm wanting this system to be a portable workbench system where it is a programmer for most if not all of its use, hence the question. I know I don't have a lot of information yet because I have only just started to try to use the system.

    laptop #1, Win10 & DPro
    =======
    a Loksound select and a NCE D13SR read fine. No red line "can't read" prompts and reread by Decoderpro

    desktop #1, Win7 & Win10 (dual boot system)
    ========
    same results as the laptop above on both op systems. Both decoders get smooth reads, no errors in read attempts, etc.

    laptop #2, Win10
    ========
    a Loksound V4 micro has very intermittent successful reads. Example , go to the speed table tab and read that page. It varies. The first few CVs usually read fine, but perhaps the 5th, perhaps, the 7th fails and turns red for a while then successfully reads, then a few CVs later same result. Sometimes two consecutive CVs. DPro struggles to read it but eventually gets the full page

    A Soundtraxx Econami won't read or write whatsoever. This decoder does read/write on a Digitrax system with no track booster, so it can work on a 'normal' program track.

    laptop #4
    =============
    same result with the Econami. Have not tested the Loksound V4 on it yet

    In addition a coworker with an identical system (I built it for him) has the same problem on laptop #4 with the Econami, and has not been able to read any of his WOW decoders at his home on a 5th laptop.

    Thanks for any thoughts, ideas, info' etc
    Lyle Dowell
     
    Scott Eric Catalano likes this.
  2. w8one

    w8one TrainBoard Member

    89
    109
    5
    Locos respond to commands by turn the motor on and off, this is what the h-bridge is reading. Sometimes newer locos and decoders are more efficient and are harder to read. Some people add a resistor in line (not across) one of the wires to the track to better read the locos others have added the resistors across the two leads to the loco's motor using alligator clips.
     
    Scott Eric Catalano likes this.
  3. Scott Eric Catalano

    Scott Eric Catalano TrainBoard Member

    205
    57
    6
    Yes. I have had to add resistors to programming tracks and reading sound equipped locos I have had to up the programming amp to 5amps or more as it takes so much energy to program those. QSI, BLI, just to name a few. I also model in HO Scale that make a difference too.
     
  4. BarstowRick

    BarstowRick TrainBoard Supporter

    8,650
    2,569
    129
    And they wonder why I say, DCC is to da$%d complicated.
     
    Scott Eric Catalano likes this.
  5. lyled1117

    lyled1117 TrainBoard Member

    42
    21
    8
    I'm aware of the use of bias resistors to tweak program track functionality. I will test and see if that might assist in the DCC++ system I'm evaluating getting better results. The decoders in question read fine on other systems without these adjustments. Since the original post I have tested more decoders on a couple of the computers and gotten similar results with the inability to do 'clean' reads.

    I'm hoping to use this DCC++ as a portable mini workbench device, and programming will be it's principal use. It seems to do individual and small count reads fine. I do suspect that the program track of the DCC++ system being ON between reads is a factor. The systems I've got experience with drop power between reads

    Lyle
     
    Scott Eric Catalano likes this.
  6. RCMan

    RCMan TrainBoard Member

    255
    112
    9
    There was some post here also saying the Program track was to powerful for the 'N' & 'Z' stuff and you needed to just change a parameter in the sketch.

    Here is that post.


    Maybe the work around needed.
     
  7. lyled1117

    lyled1117 TrainBoard Member

    42
    21
    8
    Dennis, thx for that information. While it is probably premature to say I have success, I have made the change to 15 for the threshold value and I am now getting clean reads on a decoder that had definite issues. Decoderpro is not getting hung up, etc. I'll try on other decoders as I can to make sure I haven't lost any abilities on those that did work previously

    edited to add:
    I have tested two decoders that did work, they continue to work so I am feeling a bit optimistic. Tomorrow I'll get a chance to be more complete in my testing

    Lyle
     
    Last edited: Jun 19, 2017
    Scott Eric Catalano likes this.
  8. Curn

    Curn TrainBoard Member

    687
    287
    26
    I'm glad that lowering the threshold worked for you. I have used the mod for some time now. If you run into any problems please let it be known. A few people have been helped by the mod, and I haven't seen any problems with lowering the threshold, so I'm starting to think 15 should be the default. I arrived at 15 by lowering the value to 5 and then raising it 5 at a time until I had trouble reading Z scale decoders at 20. I then backed it down to 15.

    Matt
     
    Scott Eric Catalano likes this.
  9. lyled1117

    lyled1117 TrainBoard Member

    42
    21
    8
    So far everything tested has been reading fine. One qualified exception has been a Econami 2000 decoder when DecoderPro tries to read indexed CVs. That however is probably DP or the decoder itself. There are no red line "can't reads" , just lengthy delays before a value is returned. A non indexed CV on this decoder reads promptly and perfectly fine so it is certain the system can read the decoder. Today I may get a chance to try some other decoders, especially an Econami 4000 series one. A coworker may have been able to test some WOWs as well.

    Lyle
     
    Scott Eric Catalano likes this.
  10. RCMan

    RCMan TrainBoard Member

    255
    112
    9
    Just tried this code change on some 'N' Scale factory installed decoders at the club layout. I had to use the lower number of 5 to make them work, however I could not get one decoder to work at all.

    It is a Atlas model number 40000471.

    It looks like it reads everything except the last read attempt. Then I see the 308 failure message.

    Doing this post from memory as I cannot find my notes.

    2 out of 3 engines did read all CV's at the 5 setting. These did not read at the 15 or 30 setting.
     
    Curn and Scott Eric Catalano like this.
  11. lyled1117

    lyled1117 TrainBoard Member

    42
    21
    8
    My coworker has encountered difficulty reading a WOW decoder, no keep-alive connected. His reads single CVs fine, but has difficulty reading indexed ones. His will eventually read the indexed one, but with significant delay. I'm going to readjust the threshold on his (and mine) to see if it makes a difference. It'll be a couple of days before I can test the results.

    Also, curious if anyone reading this has tested a 1st gen Tsunami. These most of the time required a booster. I won't have access to a Tsunami until next week, would like to know what to expect

    Lyle
     
    Scott Eric Catalano likes this.
  12. RCMan

    RCMan TrainBoard Member

    255
    112
    9
    Yes, having to same problem using JMRI. It worked a few test version ago but now I get a lot of 308 errors. I did see a post that some updates for the Wow decoders go missed in the latest test version of JMRI (4.7.7) and they are trying to get the updates in 4.7.8 before the next production release 4.8.0.

    I am also having problems with my Lenz (Set 100 R3.6) reading the CV's also, but get a error of 310.

    Will wait and see.
     
    Scott Eric Catalano likes this.
  13. lyled1117

    lyled1117 TrainBoard Member

    42
    21
    8
    A little more evaluation. I'm coming to the conclusion the indexed CVs and the Arduino software don't always get along. That may be decoder brand dependent because I have Loksound decoders that the indexed ones read fine. However, my coworker and a friend did some evaluation. They tried the same decoder with the Arduino as the brains and a PowerCab as the brains, all else the same. They sent me this:

    ==

    "OK we tried several and it works perfect on all the soundtrax we tried UNTIL U get to an index CV then it stops for 3 to 4 min and reads one. Any decoders that do not have index CVs it reads ALL sheets in seconds. It seems the Arduino cannot digest the index CVs ?? I put the non sound factory PLYMOUTH on there and it reads thru that fast, but it has no index CVs so I & Larry also think that it is in the software of the Arduino because Decoder Pro will read ALL sheets (even a WOW) non stop with the POWER CAB & the NCE interface hooked to the DecoderPro ! SO THERE, U know all that we know!

    ==

    If indexd CVs are truly the issue, it still could be timing between the Arduino and DecoderPro, between the Arduino and the decoder itself, or both. I'm leaning toward Arduino/decoder timing. It's not much to go on, but it's what I have so far.

    Lyle
     
    Scott Eric Catalano likes this.
  14. RCMan

    RCMan TrainBoard Member

    255
    112
    9
    I have a DCC++ and a Lenz Set100 and use JMRI Decoder Pro.
    Both system are giving me errors on reading index CV's. Only swap the leads from one to the other and setup JMRI for which command station is connected.

    DCC++ gives me 306 errors and the Lenz gives me 308 or 310 errors.

    Yes I can read the CV's but none of the indexed CV's.
     
    Scott Eric Catalano likes this.
  15. lyled1117

    lyled1117 TrainBoard Member

    42
    21
    8
    I'm going to continue to research as best as I can, but I believe without deep effort by someone more knowledgeable than I am that DCC++ is going to be an intermittent programmer. I'm feeling that, understandably, the system was designed first and foremost for powering a mainline. It needs to be a programmer as well, and is, but it seems to have come on line just as indexed CVs were starting to become common. DecoderPro is also complicit as it doesn't always handle indexed CVs smoothly either. Because of that it is hard to know where the problem is. Is it current sense levels? Is it timing between the Arduino and the decoder when indices are involved? Between the Arduino and DecoderPro? Both? Are there timing issues with the decoders themselves, that is Loksound indices work differently than Soundtraxx indices and the differences haven't been accommodated?

    I have tested where DP and an NCE system will smoothly read a decoder where the Arduino won't. However I have also had issues with an NCE system and Digitrax also have occasional issues with index reads. They'll read a string of CVs, but one is missed and the NCE system and DP get completely out of sync. DP needs to be restarted to get it communicating with the NCE system again. I think there is more than one issue to solve and they're in multiple locations.

    My goal in having the Arduino is to use it as a programming station, almost exclusively. It and a laptop are a lot smaller than a laptop, an NCE PowerHouse system, 5A power supply (linear transformer, not digital power brick), and a Soundtraxx program booster that I have been using. I don't mind it, but am hoping to get something much more condensed. The Arduino by itself ALMOST replaces these, but it's not there yet. Here's to hoping this can happen.

    Lyle
     
    Scott Eric Catalano likes this.
  16. RCMan

    RCMan TrainBoard Member

    255
    112
    9
    I am also having problems with JMRI indexed CV's. My Lenz Set100 R3.6 has the same issue trying to read the TCS indexed CV's

    It did work some test revisions ago when I first used the DCC++ unit and also with the Lenz system. I was hoping your code change would help fix this problem, but did not see any difference.

    I wish someone came up with a program that actually works on indexed CV's so there is a reference to check the command stations firmware.

    Dennis
     
  17. RCMan

    RCMan TrainBoard Member

    255
    112
    9
    Just tried the update on Java 1.8.0 -141 and that improves the Indexed CV's some but not 100%.

    Updating to JMRI test version 4.9.1 to see if that helps.
     
    Scott Eric Catalano likes this.
  18. RCMan

    RCMan TrainBoard Member

    255
    112
    9
    Some improvement also using JMRI Test Version 4.9.1 also, but still get some errors, if you go back and read changes on sheets it will eventually read them correctly.

    Let here some others feedback on this.
     
    Scott Eric Catalano likes this.
  19. lyled1117

    lyled1117 TrainBoard Member

    42
    21
    8
    BTW, one of my problems has not been reading, but WRITING indexed CVs. This can happen if I do a "write full sheet" on the CVs tab. This happened on a decoder where I could get a clean read on the CVs tab. Individual writes seem to work fine, but if I want to copy one decoder into another, I \'d rather not have to do 300+ individual writes.

    Lyle
     
    Scott Eric Catalano likes this.
  20. RCMan

    RCMan TrainBoard Member

    255
    112
    9
    Yes, there might be, I haven't got that far as all my decoders are already programmed.

    I have only made two modifications only to the original code.

    One is the sample threshold as described above:

    DCC++ has a noise filter/smoother on the current signal to deal with system noise. With newer low current motors, sometimes the current draw is below the cut off. With Z scale I had to edit ACK_SAMPLE_THRESHOLD in PacketRegester.h to get it to read. I currently have it set to 15 from the default of 30. You could try playing with this setting. I’ve gone as low as 5 and had it work.

    Still need to work with this setting. BTW my Engine is a Bachmann Forney in LargeScale with a TCS WOW-121 installed.

    The other is making sure the Read and Acknowledge timing is correct.

    loadPacket(0,resetPacket,2,3); // NMRA recommends starting with 3 reset packets
    loadPacket(0,bRead,3,5); // NMRA recommends 5 verfy packets
    loadPacket(0,resetPacket,2,1); // forces code to wait until all repeats of bRead are completed (and decoder begins to respond)

    This is the original code from the BaseStation. The DH10C does not perform the acknowledgement because of the last resetPacket that is used to wait until all bRead Packets have been digested. I changed the resetPacket to another bRead Packet and all works fine.

    loadPacket(0,resetPacket,2,3); // NMRA recommends starting with 3 reset packets
    loadPacket(0,bRead,3,5); // NMRA recommends 5 verify packets
    loadPacket(0,bRead,3,1); // forces code to wait until all repeats of bRead are completed (and decoder begins to respond)

    Similar changes are necessary in the routines for WriteCVByte and WriteCVBit. Use the bWrite and not the bRead on theses two changes

    So essentially this post is question and answer in one, but I hope it helps :).

    See if any of these makes a difference.
     
    Scott Eric Catalano likes this.

Share This Page