Decoder sends messages too fast

[FancyRedCat]

Hi,

I have found your great lib and have done some tests by myself. With my Zimo decoder (MX685) it works great. Then I switched to a Doehler & Haass DH18A and the same Arduino UNO cannot decode the SUSI-messages.

I loaded the PrintRawMessage-Sketch and expanded it with a hex output. The Zimo decoder produces correct results but the D&H the following:

notifySusiRawMessage : 10011 - 10000000 ( 0x13 - 0x80 - 19 - 128 )
notifySusiRawMessage : 10010 - 11000000 ( 0x12 - 0xC0 - 18 - 192 )
notifySusiRawMessage : 10010 - 11000000 ( 0x12 - 0xC0 - 18 - 192 )
notifySusiRawMessage : 110000 - 10000000 ( 0x30 - 0x80 - 48 - 128 )
notifySusiRawMessage : 110000 - 10000000 ( 0x30 - 0x80 - 48 - 128 )
notifySusiRawMessage : 110001 - 10000000 ( 0x31 - 0x80 - 49 - 128 )
notifySusiRawMessage : 110001 - 10000000 ( 0x31 - 0x80 - 49 - 128 )

The recived messages look like crap. But when I shift the messages 1 bit left and toggle the last bit they will become "readable":

0x13 => 0x26   (38) [Lastausregelung]
0x12 => 0x25   (37) ["Soll" Lok-Fahrstufe]
0x12 => 0x24   (36) ["Ist" Lok-Fahrstufe]
0x30 => 0x60   (96) [Funktionsgruppe 1] F0-F4
0x30 => 0x61   (97) [Funktionsgruppe 2] F5-F12
0x31 => 0x62   (98) [Funktionsgruppe 3] F13-F20
0x31 => 0x63   (99) [Funktionsgruppe 4] F21-F28

After further investigation, I think I found a clue: D&H Decoders use a faster clock speed then Zimo. Both are within the SUSI-specification (chapter 4):

t_on ≥ 10 µs
t_off ≥ 10 µs
t_on + t_off ≤ 500 µs

Zimo t_on ~ 76-115µs

D&H t_on ~ 10-11µs

Do you have an idea how to speed up your lib? I would like to use the internal RC oscillator @ 8MHz because I want to save space on my pcb ;) And I like the DH18A because they are smaller then the Next18 decoders from ESU and Zimo.

Kind regards

[TheFidax]

Probably the problem is in "micros()" function. It has precisione of "4" microseconds and not "1". Probably the clock length get correctly measured from 23 microseconds of length. You can try to edit line 63 of Rcn600.h from 20 to 18 and try if fast clock get read correctly.

[FancyRedCat]

Thanks for your quick response! I changed MIN_CLOCK_TIME to 18 and even down to 4, but nothing changed.

[TheFidax]

It is possible that the Arduino UNO is not fast enough for similar clocks, have you tried with a higher performing Arduino such as Arduino Due or UNO R4?

[adcStefanAdam]

Same here with an Arduino Uno and a Piko Sound Decoder XP 5.1. I Receive 2-5 correct message and Afterwards only crap. :( Changeing line 63 hast no effect. But your Library is working very well with an ESU Lokpilot 5 Micro.

@FancyRedCat what Lines did you change for shifting and toggling? Thx.

[FancyRedCat]

Sorry, I don't have a higher performing Arduino, maybe I can test with a Pi pico later.

@adcStefanAdam I didn't change any other lines except line 63. So it is still not working. I had no time for more tests in the last week.

[adcStefanAdam]

Sorry, I don't have a higher performing Arduino, maybe I can test with a Pi pico later.

@adcStefanAdam I didn't change any other lines except line 63. So it is still not working. I had no time for more tests in the last week.

Hi again,

you wrote:

But when I shift the messages 1 bit left and toggle the last bit they will become "readable"

so where did you do that?

BTW. the Piko Decoder Haus an Option for Alterung the clock rate in CV 120. the value of the CV is Multiplied with 1 Micro Second and Summer up with 10 Micro Seconds. So I tried a value of 87 which makes 97 Micro seconds and a value of 184 which makes 194 Micro seconds to get the values shown for your Zimo Decoder. But still with no luck.

greetings.

[FancyRedCat]

Hi @adcStefanAdam,

tldr: I did the bit shifting manually without programming.

I used the serial debug output. I knew from my Zimo how it should look "right". So I multiplied the debug values manually by 2 and compared them with the RCN-600 spec. Later I added a logic analyzer to see what happens on the susi-bus. After searching for the "brocken" susi-commands, I saw on bit-level everything was alright. But then I saw the higher clock speed. That was how I came to my suspicion the routine is to slow.

Btw I also looked at a Kuehn N45, this decoder has a variable clock speed. But I forgot to take a screenshot. The shortest ticks were 10µs+10µs, the longer were around 20µs or 30µs. But all whitin the spec.

I don't own a Piko decoder so I cannot test this with my setup. Your values sounds good. Do you have a oscilliscope or a logic analyzer to check if the decoder sends valid messages? But I don't think this is a problem because Piko ships many locos with susi modules onboard.

Greetings

[adcStefanAdam]

Hi again,

no i haven’t got a Logic analyzer. Which one do you usw or prefer?

Greetings.

[adcStefanAdam]

After buying and using a digital oscilloscope it seems that the Piko Decoder is putting down the CLK signal after some messages on the SUSI bus and then starting the whole process again. So is there an ACK message of the slave decoder missing? So the master is thinking the slave is gone and then is trying to communicate again?