PicoScope 2205A MSO can't decode DCC at timebase >2ms

Having problems ? let us know the details here
Post Reply
axelfarr
User
User
Posts: 2
Joined: Thu Oct 21, 2021 6:22 pm

PicoScope 2205A MSO can't decode DCC at timebase >2ms

Post by axelfarr »

Hello,

I am right now testing my brand new PicoScope 2205A MSO with track signal from Märklin CS2. I changed the CS2 settings so only DCC locomotive decoder signals are generated (in regular distances some MM2 type function decoder signals are strayed into the track signal, but this does not significantly disturb the DCC decoder).

What I found out is that the DCC decoding works for time base of 2ms and slower (given the signal fits to the buffer). This is independant from bit rate, the same situation with 100kBit/s and with 1MBit/s.

What is not working is DCC decoding for time base settings larger than 2ms. This makes the DCC decoder nearly useless as one single DCC frame may extend over more than 10 ms (= blow the 100% of one buffer) in case it is e.g. a configuration frame in long format including the complete adress of the decoder (programming-on-the-main, POM). Since frames extending from one buffer to another are not treated as one but handled in two pieces this leads to the problem that trigger must be very precisely at the frame to decode.

When the time base is set to 5 or mor ms/div the decoder still detects the edges, counts the bits but all bits are sensed as "1" and the decoder is simply finding preamble, but not a single starting bit.

Info delivers the following data:

PicoScope® 6 - PC-Oszilloskop-Software Version: 6.14.44.5870
Copyright © 1995-2021, Pico Technology Ltd.

Modell: PicoScope 2205A MSO
Seriennummer: IU910/0136
USB-Version: 2,0
Kalibrierungsdatum: Mittwoch, 27. Januar 2021
Hardwareversion: 1
Treiberversion: 2.1.61.2597
Firmwareversion: 1.3.3.0 / 1.0.39.0

What I would need was a working capability to e.g. look at 2s of track signal decoded to see the reaction of my decoder on e.g. a frame received without the need to generate a trigger from inside my decoder SW.

Greetings, Axel

bennog
Advanced User
Advanced User
Posts: 104
Joined: Mon Nov 26, 2012 9:16 am
Location: Netherlands

Re: PicoScope 2205A MSO can't decode DCC at timebase >2ms

Post by bennog »

I am afraid you need a scope with more memory, your scope has only 48k of sample memory if using 2 channel you have 24k/S per channel.

Every bit needs at least 5 samples (preferred 10).

According the specs you can do 1MS/sec in streaming mode (500kS/sec if 2 ch in use)

So in streaming mode it should be possible to capture 2 seconds at 500kS/sec en decode the signal.

Benno

axelfarr
User
User
Posts: 2
Joined: Thu Oct 21, 2021 6:22 pm

Re: PicoScope 2205A MSO can't decode DCC at timebase >2ms

Post by axelfarr »

Hello,

I think I found at least one work-around to the problem and a possible reason for the problem:

When I let the decoder work on a small portion of the captured data, it works (by activating the "decode between time rulers" setting and placing rulers before and after the respective portion with DCC signal content). The reason behind this could be:
  • Märklin CS2 is (even if only DCC protocol is selected for locomotives) allways sending MMC "idle" packets. The reason are old decoders which automatically change to analog mode (and start driving the locomotive away) when within few seconds no valid MMC packet is received even if it is not "their" address.
  • To switch between the packets, the CS2 inserts gaps of ~4s into the data stream of track output. Track level is "low" in this time (B negative vs. 0).
  • The decoder seems to have a flaw that such long "half-bits" as DCC calls them are not properly diagnosed as "0". Instead, the decoder seems to "stick" to the last bit detected. The same happens if abnormally short half bits (such are part of MMC signalling) are detected. They seem to somehow "poison" the decoder, and from this moment of "poisoning" the decoder cannot decode properly any more.
  • With 2ms/div the decoder has a quite good chance to do a good job - if a DCC packet is recorded, it will fill ~1/3 of the measured buffer, there is either no or only a fractioned MCC frame before it.
If more than DCC protocol is activated, the DCC portions of the track signals generated by the CS2 will contain some sort of "jam" consisting of arbitrary sequence of "1" and "0" half bits and bits (may be needed to make MMC decoders ignore DCC data stream). They do not deliver any meaningful content and should be ignored by DCC decoders. Instead, the decoder starts to interprete this as a constant sequence of "1" bits and syncs to the first complete "0" bit found. The next portion of bits is then considered as the adress byte, even if it is not properly terminated by a "0" for the next byte (there is no "1-byte package" possible, if the decoder found such a packet with a content of "FF" in the single byte it should change the state to "sync sequencing" and set the sync bit count to at least "8" for the eight "1" bits in the "FF" data byte "detected".

See the attached, commented screen shot.

The streaming mode is really well working on my system. With 2 channels, up to 1 MS/s can be streamed. For proper decoding for DCC it looks as if 100 kS/s are sufficient.
Attachments
Commented decode made with 5ms/div in streaming mode
Commented decode made with 5ms/div in streaming mode

Post Reply