Cleric-K / vJoySerialFeeder

Feed Virtual Joystick driver with data from a serial port
GNU General Public License v3.0
258 stars 55 forks source link

failsafe (waiting for Serial data) #34

Closed Crcrozes closed 2 years ago

Crcrozes commented 4 years ago

Hi I’am new here. I was able to connect and fly on simulator by SBUS and arduino setup until it stopped working and vjoy serial feeder failsafed. How do I fix it? my transmitter and receivers are linked properly.

Cleric-K commented 4 years ago

What kind of arduino are you using? Does it have TX led? If yes, is it blinking when there is data coming from the receiver?

Crcrozes commented 4 years ago

I’m using arduino nano,. yea the tx led is flickering when connected.

Cleric-K commented 4 years ago

Take a look at this post: https://github.com/Cleric-K/vJoySerialFeeder/issues/3#issuecomment-379047569

You can try and dump some of the protocol data to see what comes from the arduino.

Crcrozes commented 4 years ago

Hi I get this

Terminal log file Date: 5/26/2020 - 10:46:12 AM

0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 01 08 07 38 00 10 80 00 24 0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 01 08 07 38 00 10 80 00 34 0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 01 08 07 38 00 10 80 00 04 03 C0 30 0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 01 08 07 38 00 10 80 00 14 0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 01 08 07 38 00 10 80 00 14 0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 01 08 07 38 00 10 80 00 24 0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 01 08 07 38 00 10 80 00 34 0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 01 08 07 38 00 10 80 00 04 0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 01 08 07 38 00 10 80 00 04 03 C4 00 0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 01 08 07 38 00 10 80 00 14 0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 01 08 07 38 00 10 80 00 24 0F FC 0B 60 58 00 08 40 50 83 1A 2C 00 04 20 00 01 08

Crcrozes commented 4 years ago

it seems 00 doesn't precede 0F...

Crcrozes commented 4 years ago

flashing this sketch to arduino and vJSF does connect and works

void setup() { Serial.begin(100000, SERIAL_8E2); }

int n; void loop() { Serial.write(0x0f); Serial.write(n&0xff); Serial.write((n++>>8)&7); for(int i=0;i<22;i++) Serial.write(0);

delay(20); }

Cleric-K commented 4 years ago

Yeah.. strange. Obviously there's some corruption of the data. The dump shows some 25 byte periodicity but not every time. And the last byte is rarely 00. If you have logic analyzer it would be best to capture what is coming from the receiver.

Maybe try to use another port of the Arduino for input? Or another Arduino if you have one.

Crcrozes commented 4 years ago

Ok, I don't have logic analyzer but what I am suspecting is the faulty Arduino nano board (?) . Maybe I bought it from amazon and it seemed it was opened before even though it is a legit Arduino board.

but thanks for the fast replies :)

Cleric-K commented 4 years ago

Arduinos are simple boards so as long as the MCU is working, rarely there could be a problem with the board itself. So you can either experiment with other pins to be used as inputs. Sometimes voltage surges can damage individual pins on the MCU. Or double check the connections between the Arduino and RX. Faulty GND wire can be a problem.

Crcrozes commented 4 years ago

How do I change the in put pins? also is this correct way to wire them?

IMG_4124 IMG_4125 IMG_4126

(-) - blue - GND (+) - grey - 5V (S) - white - D3

I am using R3001sb futaba.

Cleric-K commented 4 years ago

I meant to use other than D3 - any one should do, just change the #define SBUS_PIN 3 in the sketch accordingly.

Crcrozes commented 4 years ago

Hi I checked all of D1-D13, but same result.

Crcrozes commented 4 years ago

Ok I am able to fly on sim now with no problems. I didn’t put the transmitter on ACT off for trainer mode (it was on inhibit). I guess I am learning quite a bit everyday figuring out stuff.

Hey thanks for the help trying to get me flyin!

Cleric-K commented 4 years ago

I'm glad you figured that out.

Happy flying~

Crcrozes commented 4 years ago

Wow this is weird. sometimes I can connect, but sometimes it just failsafe randomly. I have no idea what's causing it to failsafe in the middle of sim flight...

Cleric-K commented 4 years ago

Weird stuff. You can try with another receiver if you have one. If the same happens there's something wrong with the arduino or the wires.

Crcrozes commented 4 years ago

Can you explain what failsafe waiting for serial data means? Is it waiting for the correct sequence of sbus? (0F ... 00)?

Cleric-K commented 4 years ago

Yeah, I haven't done the best job choosing the text of that message. Basically it means that there is incoming data (otherwise the message would be saying Timeout) but it can not get a lock on proper frames.

Crcrozes commented 4 years ago

I got different Arduino board and it seems to work for now. I don't know if it is the board that makes it nonfunctional or functional until it fails to work. then I will have to change receiver.

Crcrozes commented 4 years ago

HI I data dumped again and rearranged the data so that it matches up with the sbus sequence (25 bits) I moved throttle up and down during the logging session so it looks like this.

Sbus missing data 2

Any idea why there are "missing" bytes from the receiver??

Cleric-K commented 4 years ago

I'm really clueless at this point.

The missing bytes can be the result of some kind of noise interfering and the bytes failing checksums.

But the strange thing is that the 00 byte must the that last in each frame (25th) - it is the End byte of the SBUS protocol and 0F is the Start byte. Personally I've never tested anything with Futaba hardware. I wonder if there can be any variations in the SBUS protocol, but so far I haven't found any documentation that mentions anything different than 0F and 00 for first and 25th bytes.

Crcrozes commented 4 years ago

HI I changed the transmitter mode from multi-rotor to airplane mode. now I can fly sim without connection failing. 17 ms update rate. But interesting thing is that when I run terminal, I still get the "missing" signals like above. Very weird.

Thanks for the helps!

ardianet commented 3 years ago

Hi, I'm using the arduino nano attached to my TX (using your PWM to iBus code). At first the serial feeder read the ibus streams and also calibrated to sims perfectly. But after couple of minutes the serial feeder will go in failsafe. re-connect it could solve the problem. but again after couple of times doing the re-connect, serial feeder will stop reading the streams (failsafe). replug the USB didn't help. using arduino serial monitor(tweak the code to print the analogread for debugging) the stream is readed good.

Any clue what to look at?

Cleric-K commented 3 years ago

Does the TX led continue to flash after the problem? What does the failsafe message say - Timeout?

ardianet commented 3 years ago

Does the TX led continue to flash after the problem? What does the failsafe message say - Timeout?

Connected, Failsafe (Serial port read timeout),10 updates per second/100ms between updates
TX didn't give any LED sign (always in solid state).

ardianet commented 3 years ago

Does the TX led continue to flash after the problem? What does the failsafe message say - Timeout?

Hi, So I try to start all over again. Using your original arduino sketch, with only analogs for input. And it's doing fine.

Next I try using a receiver with PPM-out, mod your original sketch (add PPM to PWM converter to feed the ibus.write with the PWM values). At first, it was readed good with the serial feeder. But again after couples of time connect/disconnect the port, its start the failsafe-timeout again. While using Wdcossey's PPM to Ibus is quite jitter for the output.

What I noticed, once I have write simple code using standart analogRead() for checking my analog inputs (no code for converting it to iBus) then I connected it to the Serial feeder, and.. its readed good.. (iBus protocol selected). But again after couples of time connect/disconnect the port, its start the failsafe-timeout again.

So, again my target is using a PPM receiver. Any chance you would write/mod the code for PPM input? or any clue/workaround for it?

Regards. :)

Cleric-K commented 3 years ago

I didn't understand if the TX led of Arduino keeps flashing after the problem happens? The question is to find out if something happens at Arduino and it stops sending data or Arduino keeps sending valid data but vjsf has a problem.

Another way to test is to follow this procedure and dump the output. See if after few minutes it stops printing or something like that.

ardianet commented 3 years ago

I didn't understand if the TX led of Arduino keeps flashing after the problem happens? The question is to find out if something happens at Arduino and it stops sending data or Arduino keeps sending valid data but vjsf has a problem.

Another way to test is to follow this procedure and dump the output. See if after few minutes it stops printing or something like that.

Perhaps a bit late, but I want to thank you for making the feeder and also the iBus generator (arduino joystick). :)

And I think I've missread your point about "TX", it's mean TX Led on arduino, right...? :D The TX led is off btw.

But after quite a time, I got your sketch combined in the Arduino Bayang-RX sketch. And its working great. The odd thing is : that I have to choose(connect) with other protocol except iBus first(Kiss/Sbus/Multiwii).. then reconnect it with iBus selected, and it will display the analog value when stick moved. This procedure have to be done everytime I re-open the Serial Feeder app.

Drimir commented 3 years ago

Hello. Yes, there really is a problem with the 25th byte. 0F 79 D3 D8 35 01 08 E8 7E 81 05 2C 60 81 2C 58 C0 02 07 38 00 10 80 00 04 0F 79 D3 D8 35 01 08 E8 7E 81 05 2C 60 81 2C 58 C0 02 07 38 00 10 80 00 14 0F 79 D3 D8 35 01 08 E8 7E 81 05 2C 60 81 2C 58 C0 02 07 38 00 10 80 00 24 0F 79 D3 D8 35 01 08 E8 7E 81 05 2C 60 81 2C 58 C0 02 07 38 00 10 80 00 34 ... I didn't quite figure out how to fix this in the library, so I created a simulator and broadcast the copied data from the terminal to my device. And the following happens. The terminal normally reads data from the simulator and from the Futaba receiver, but the waveforms are of different length. the speed is 100000. So my device works with the simulator, but does not work with the Futaba receiver. As I understand it, everything can be due to the settings UART, where the microcontroller works as 8-N-1, and not as Futaba 8-E-2 ... The packet from Futaba is longer than from the simulator, and the terminal normally reads both. Tell me, could this be the reason? UART settings of my S.BAS reader and what to do with the 25th byte ... The length discrepancy starts already from the first byte of the header. An extra bit immediately appears on Futaba. 20210419_184558 20210419_184602 20210419_184632

Cleric-K commented 3 years ago

I've simply made it that the 25th byte is ignored in vjsf. I used to make sure it's 00 but it seems that Futaba uses it in some other unknown to me way, so I now allow any value there.

The speed of SBUS is really 100000bps. It's necessary to force your simulator at that speed if you want it to be truly SBUS compatible. The 8-E-2 is also critical.

Gilgamesh156 commented 3 years ago

Cleric-K I wanto take a moment to thank you for the amazing work you have done for the community, its absoultely amazing.

I am a complete noob and have just stumbled across this information, I am using a teensy frsky receiver connected to an Adruino Mega 2560, everything works fine, although there is a large amount of latency making it unusable, would you be able to shed any light on this issue?

Cleric-K commented 3 years ago

It's difficult to suppose what might be wrong. Do you have another Arduino (non-mega) to test with?

Gilgamesh156 commented 3 years ago

Thank you Cleric-K for the quick reply! :) Okay so turns out I had a spelling error in my original comment, it is not a teensy frsky receiver but a teeny frsky receiver "https://www.ebay.com.au/itm/184373563708" I ripped a receiver out of one of my fully functional quad's to test and I have determined that the receiver is the cause of the latency so it must be dodgy/faulty. Sorry for wasting your time mate :P