vJoySerialFeeder with SBUS is glitching

[Khalid-Hersafril-Flowcopter]

So I first followed the following instruction

https://github.com/Cleric-K/vJoySerialFeeder/blob/master/Docs/Sbus.md

which I then connect it to my FrSky R8 pro which utilizes the SBUS protocol.

I manage to get readings into the application as seen in the gif below where I connect to my Arduino COM port, and as you can see, there is some glitching occuring every now and then where the values just dropped to 0 for some reason. I thought it might be my receiver issue, so I used another one, and same thing occured unfortunately. Im not sure what might have cause this issue

[Cleric-K]

Hi, I'm not sure what this could be. The values seem too regular to be just an error. Could it be that failsafe is activated and the receiver sends some predefined values? You may check the failsafe settings on the transmitter and see if they match the values that flash for a moment on the interface. May you look at the Setup dialog next to the protocol selection in the vjsf? What is the failsafe setting there?

I have heard that some frsky receivers may have problems if they are too close to the TX. Can you try moving further away and see if it still glitches?

[Khalid-Hersafril-Flowcopter]

You may check the failsafe settings on the transmitter and see if they match the values that flash for a moment on the interface.

Sorry, but Im not sure what you mean by this. I've checked my failsafe settings on my transmitter and it is currently set to custom where if activated, all channels will hold.

May you look at the Setup dialog next to the protocol selection in the vjsf?

Im also not sure what you mean by vjsf here. I've never used that before. Do you mind providing me with a bit of guidance?

I have heard that some frsky receivers may have problems if they are too close to the TX. Can you try moving further away and see if it still glitches?

I've tried about 3m away from my PC but its still glitching sadly.

[Cleric-K]

vjsf is simply vJoySerialFeeder.
You may try to follow the instructions here: #3 (comment)
and take some hex dump of whatever comes from the receiver. Make sure you capture enough seconds such that a glitch is likely to be present. Save it in a file and attach it here. Then we'll look into the dump and see if the glitch values really come from the receiver.

[Khalid-Hersafril-Flowcopter]

Hi, thanks for the help! I've recorded 2 of the logs just in case, im pretty sure this should be long enough to capture the glitch.

SBUS_glitch.zip

[Cleric-K]

The dump doesn't look OK but I think it is because the terminal program can't keep up with the incoming data and skips bytes. Let's try with putty.

Choose the Serial mode of connection:

Enter the name of your port, baudrate to 100000 and even parity:

In the Logging section choose All output, browse to select a place to save the log, uncheck header and click open to get to start the connection:

The text in the window will be garbled but that's OK because the data is binary. The log file will also contain binary data (not hex). Let's see if that dump will be better.

[Khalid-Hersafril-Flowcopter]

Log Binary.zip

Here you go, I wont be able to work on this for awhile cause I got an exam coming. Hopefully this should be enough! Please do let me know if there's anything I can do from my side as well

[Cleric-K]

I've checked the output, this time everything is fine. It seems that the terminal app can't log fast data.
All the packets in these logs are perfectly consistent. There are no missing bytes, it looks that there is no data corruption.
Here are the parsed packets:
log_1.zip
In other words, it seems that this is how the data is sent from the RX itself. I have no clue why it could be so. Do you have another receiver to test with? Maybe start with a new clean model on the TX? But in all cases the glitches are not communication errors but the data simply comes like this from the RX.

[Khalid-Hersafril-Flowcopter]

I've tested with 2 different receivers and it occured on both, I think I might have another spare one. I'll try it out and keep it updated here.

Also, just a quick note, that the receiver has already been tested on the actual drone, and it works flawlessly. It may be the case that my computer isnt fast enough to process the information coming from the COM port which I am a bit skeptical of this since my computer's specifications are as below:

• Processor: AMD Ryzen 5 5500U with Radeon Graphics, 2100 Mhz, 6 Core(s), 12 Logical Processor(s)
• Total Virtual Memory: 41.9 GB

[Khalid-Hersafril-Flowcopter]

Just tested it, I have 3 of the receiver and still the same bug occuring, unfortunately :(

[Khalid-Hersafril-Flowcopter]

I'll try to debug this further from my side, and see if there might be potential fix for my specific issues. I'll try to keep it updated here if I found any solution