Mode Zero

Here is the video, hope it is ok to see.
I am not very good to do videos.

https://www.youtube.com/watch?v=gXdXe540VoA


br KH

Thank you. That was very useful. I used the YouTube freeze-frame thing when it was on one of the SBUS displays and wrote down the values for each channel. Because each channel is "5-weight" more than the previous one, you'd expect the SBUS numbers to go up in roughly equal increments. And they do, except for channel 9.
I've put in parentheses what channel 9 should have been (1360) and if it had been, then every difference would have been a regular 41 (+/- 1).

I'll investigate what's going wrong with channel 9 - maybe I can fix it even if I don't have a receiver to test it myself.

Martin, at the moment I am using the same FrSky XSR receiver.
But I could also do the test with a X6R, if helpful.
Also could try to improve my ability to make better (readable) videos.

KH

Thanks KH, I don't think you need to do any more right now. Wait for me to (hopefully) fix the program and upload a version 4B or whatever.

I don't have a suitable SBUS receiver to test all the channels, but I think I found the bug. It was just two characters missing: '+k' on line 82 - it used to say frame[1] when it should have been frame[1+k]

Here's the corrected line: I've uploaded the modified version to the opening post of this thread. KH, perhaps you would be kind enough to test it for me and confirm that the bug is fixed?

Martin, come back with a test this evening

br KH

Did the test and it looks good.





But what about the 9.0 ms in the first line?

The moment I increase the number of channels in the TX > 8, the tx switches from 9 ms to 18 ms.



Should or can that be corrected, Martin?

br KH

Thank you.

I think the 9ms displayed by the OLED is probably correct. Remember that the Arduino can only see the SBUS signal - it doesn't know how often the transmitter is sending a new frame of data. So even though your receiver only receives a full update of all 16 channels every 18ms, it still outputs the SBUS data every 9ms.

Remember that the format used between the transmitter and receiver is not SBUS - in your case I think you are using FrSky D16 protocol - it's only inside the receiver that the numbers are converted to SBUS format.

The SBUS format consists of bytes of data, which, when packed close together without gaps, take only 3ms per frame. The Orange receiver I did most of my testing with does output each SBUS frame in 3ms - but then leaves an 8ms gap before the next frame - so my sketch displays 11ms. When the Orange receiver is no longer receiving a signal from the transmitter, it continues to output 3ms SBUS frames, but the gaps between them increase to 19ms, so my sketch then displays 22ms. I've checked that this is correct using an oscilloscope to display and time the SBUS signal.

Thank you for explaining, Martin.

I get my oscilloscope and have a look myself.

br KH

Hello Martin.

I made the realization of your SBUS decoder today on an Arduino proto shield. It will do fine for me.

https://www.youtube.com/watch?v=31qxGi2 ... e=youtu.be

Deleted the other YT videos. Don't make any sense ....

And I learned today another thing. There are two 0.96" OLED with the same I2C ADDR 0x3C. Took some time to find out.

Thank you very much for helping me with your project.

br KH