SBUS support about vjoyserialfeeder HOT 47 CLOSED

Great, thanks!

Better start a new thread.

from vjoyserialfeeder.

Hi, thanks for your suggestion!

Few days ago we started doing some work in very similar lines with Drone Mesh. I don't have sbus capable transmitter so I prepared several tasks for him to do some testings and send me dump files.

I sent him a minimal sketch:

#define txPin 1
#define sbusPin 3

void setup() {
  pinMode(txPin, OUTPUT);
  // sbusPin should be INPUT by default
}

void loop() {
  // simply write to the txPin the opposite of what we read at the sbusPin
  digitalWrite(txPin, !digitalRead(sbusPin));
}

That is - simply invert the signal and write it out the UART. And it worked ... kind of ...

Even before we started testing I was not that concerned about the inversion, rather than the fact that SBUS uses baud rate of 100 000bps. This is not a standard baud rate and I was wondering even if the UART converter will be able to set such a rate. For example, the hardware RS232 com port on my PC refuses to set up such a rate - Windows API throws error.

USB UARTs I've tested don't throw error but I don't know if they really set that rate correctly.

Drone Mesh did the tests, sent me the dump files (as received on the PC) and in general they look ok, but now and then there are garbled bytes or sometimes even missing.

So what I was worried about seemed to have come true.

I asked DM to attach the oscilloscope - one channel before inversion, the other after, but he is quite busy and hasn't done so yet. I just wanted to make sure that 1/ the software inversion really works (I don't see why it shouldn't) 2/ If the receivers really sends at 100k bps - one bit should be exactly 10μsec if so.

Fortunately he promised he'll send me his old QX7 and then I'll be able to do the tests myself.

If it really turns out that USB UART chips have trouble setting non-standard baud rates my other idea was something like what you sent me above - to read with softserial at 100k bps (the library will need a little modification because not only it is inverted but the framing is 8-E-2) and then send them at 115200 out the hardware uart. Alas here I also anticipate a problem - from what I've seen through the net softserial can hardly go beyond 57 600 bps.

If that also fails the only reliable way would be to use some other hardware with at least 2 hw uarts (teensy or smthg).

The other part is easy, I have the SbusReader partly prepared.

Do you have sbus transmitter? It can take two weeks till I get the qx7. If you have some hardware you may try some test if you want.

from vjoyserialfeeder.

I have everything you want, even more ;)

• Teensy 3.2
• dozen arduino: nano, mini, even i think mega with 2 uart (one for usb and one for tx/rx pads)
• qx7 with xm+ and rxsr

I hope I can help ;)

edit: If we use teensy we can use the board as a virtual joystick, vjoy is not needed.

from vjoyserialfeeder.

Great! Thanks, man.

So, I've pushed a sbus branch (82e5a6a) with some sample code. You'll have to select the SBUS protocol and enter 100000 for baud rate.

If we get lucky it may turn out that the whole issue was caused by the program we used for the dumping. I played a little with an arduino and set it as Serial.begin(100000); and in windows I was reading the data alright at 100k. So maybe the problem is not with the baud rate but simply by bad dumping. But let's see.

Let's first try with the sketch I sent you in the previous post. You should connect the SBUS to pin 3 on the arduino (or change it to whatever you want).
If that does not work as a last resort we can try this one:

#define SBUS_PIN 3
#define TX_PIN 1

uint8_t sbus_bit, tx_bit, tx_bit_inv;
volatile uint8_t *sbus_reg, *tx_reg;
  
void setup() {
  sbus_bit = digitalPinToBitMask(SBUS_PIN);
  sbus_reg = portInputRegister(digitalPinToPort(SBUS_PIN));
  
  tx_bit = digitalPinToBitMask(TX_PIN);
  tx_bit_inv = ~tx_bit;
  tx_reg = portOutputRegister(digitalPinToPort(TX_PIN));

  pinMode(TX_PIN, OUTPUT);
}

void loop() {
  cli(); // disable interrupts
   while(1) {
     // use our own loop

     if(*sbus_reg & sbus_bit)
      // sbus is high, so write low to tx
      *tx_reg &= tx_bit_inv;
     else
     // sbus low -> tx high
      *tx_reg |= tx_bit;
   }
}

This one I haven't tested at all, I've just seen that it compiles. This is the fastest thing I could think of for reading a port and writing the inverse to another.

Thank you! Let's see if we get some luck this time :)

from vjoyserialfeeder.

Of course. Maybe I'll have time tonight to make some tests. But I'm sure, I'll have time on the weekend.
Thanks.

from vjoyserialfeeder.

Thank you. Take your time.

Btw it might be the case that the original sketch (with digitalRead/Write) is in fact not fast enough. I did some tests and the loop time is about 6.7μsec which could be quite insufficient since one bit is 10μsec. Some of the time it might work but in other times aliasing problems might occur - which makes sense in the face of the dumps.

I measured the second sketch and the loop time is about 762 nanoseconds - this should have much better chance of following the input signal I hope (numbers are for 16Mhz atmega328p).

from vjoyserialfeeder.

I managed to test with both code. I use arduino nano atmega328p, qx7s (opentx 2.2.1) and r-xsr.

The first (digitalWrite&read): lot of "resyncing" in the console and totaly random value presented on the ui :S. screenshot1, screenshot2

Second (bitMask&portregister): only ONE "resyncing" in the console (I think the initial one) and everthing looks good on the ui. screenshot3 Values were between 0% and 81%, moved as i moved the sticks ;) But only between center and top of the stick move are detected, like that maybe it is a config issue in my transmitter, I'm trying find out!

edited: I set 50% weight and 50 offset to all channels on the transmitter (just like on direct usb connection) Now the values changing between 0-81% on all the way of the stick move not just the halfway. I recalibrated the vjoy joystick in liff off and I'm playing ;)

from vjoyserialfeeder.

Outstanding! That's great news! :)
Thank you very much for your efforts.

So we nailed it. Seems I've overestimated the speed of the Arduino when I was writing the first sketch. Should have done the simple math back then and we could have saved some wandering.

The first several "resyncing"s are normal. Since the receiver is dumping data all the time, in most cases when we start reading we fall somewhere inside a frame. Resyncing shifts the buffer byte by byte until it aligns with a proper frame. From then on there shouldn't be problems.

About the numbers: I've no clue what frsky should be sending. IBUS sends 1000 for min and 2000 for max (assuming stock config in the transmitter). AFAIK these are reminiscence of PWM/PPM where the pulses vary between 1000 and 2000 μsec.

Seems users will have a choice - either change it on the transmitter as you did, or setup each axis in the feeder, settings the correct min/center/max.

So for SBUS we have three solutions:

1. Some soldering to get the uninverted output (https://oscarliang.com/uninverted-sbus-smart-port-frsky-receivers/) and then usb uart.
2. Using hardware TTL inverter (ready made like https://hobbyking.com/en_us/zyx-s-s-bus-connection-cable.html?___store=en_us or self made) and then usb uart.
3. Using arduino

I'll document all three but I really think the arduino method will be the most preferred since a nano is dirt cheap.

I have several commits already with some small improvements. Tomorrow I guess I'll push them on master + the sbus. I guess Drone Mesh will want to do a video on arduino+sbus. I'll tell him that it is thanks to you that we made the progress.

Thanks again!
And happy flying ;)

from vjoyserialfeeder.

It was my pleasure!

from vjoyserialfeeder.

I've pushed some stuff on the sbus branch. Nothing critical, just some features to make the things more complete - serial framing can be customized, MultiWii request rate can be customized. The docs are somewhat updated. It's almost ready for release.

from vjoyserialfeeder.

I find one interesting method in CF/BF sbus code: sbus_channels.c sbusChannelsReadRawRC maybe this mapping and scaling can help us too to get 0-100% without any configuration on the transmitter.

from vjoyserialfeeder.

Cool, I'll take a look when I'm at the pc (writing from phone). Can you tell me, when you create a new model at the transmitter with default settings, what are the INPUT raw values for min, max and center?

from vjoyserialfeeder.

from vjoyserialfeeder.

Great!
I've implemented it. SBUS can now be configured (Setup button). The OpenTX prescaler is active by default. If needed for some reason (from what I've seen maybe futaba sends 1000-2000 values?) the raw values in the frames can be used.

from vjoyserialfeeder.

Hi , i didnt really read Github here since i am a new user for something like 10 days.
And i was pissed with the need for a flight controller or a drone with a battery.
Since i have many different arduino laying around , and an X8R wich came in the package with my radio.

I have been writing some code for Sbus wich is 100% ok and tested , it work with arduino and send the data as MSP formated , took less than 1ms after frame is received , to process / convert / checksum / and send as MSP to computer at 230400 bps to get it there Asap.

For the "correct" way to send Sbus to Computer via Arduino WITHOUT processing , i think this is the better approach as it use "Serial" class wich treat the bit timing correctly , it just read 1 byte and resend it immediately.

(might be errors i write it by memory)

#include "SoftwareSerial.h"

SoftwareSerial softser(10, 11, true);

void setup() {
softser.begin(100000);
softser.setTimeout(10);
Serial.begin(230400);
Serial.setTimeout(10);
}

void loop() {
if (softser.available()) {
Serial.write(softser.read());
}

//probably not even needed if we dont send anything back from pc to arduino
if (Serial.available()) {
softser.write(Serial.read());
}

}

it send it faster than it receive , so there might not be serial buffer issue here
not really tested it should work , i used hardware serial with uninverted signal on my "processing" sketch as it is definitely proved to be more stable than softserial

and for my full processing code , have a look , it is not polished yet , but it work very well :

from vjoyserialfeeder.

#define SBUS Serial1
//#define TIME //comment to disable Frame Time output on pin 13
#define BLINK //comment to disable Led Blink on Sbus Data

byte SbusBuffer[30]; // actually 25 but to be sure
word Channel[20];
byte ChannelHalf[40];
byte SbusIn = 0;
byte SbusInPrev = 0;
byte count = 0;
byte count2 = 0;
byte Checksum = 0;
byte LightBlink = 0;
byte BeginPacket[5] = {0x24, 0x4D, 0x3E, 0x20, 0x69}; // 0x24 = $ / 0x4D = M / 0x3E = > / 0x20 = 32 / 0x69 = 105

void setup() {
pinMode(13, OUTPUT);
digitalWrite(13,0);
SBUS.begin(100000, SERIAL_8N2);
SBUS.setTimeout(5);
Serial.begin(500000);
Serial.setTimeout(5);
}

void loop() {

if (SBUS.available()) {
SbusIn = SBUS.read();
// Sbus frame detection (end with 0x00 , start with 0x0F) , then reset count
if (SbusInPrev == 0x00 && SbusIn == 0x0F) {
count = 0;
}
SbusInPrev = SbusIn;
SbusBuffer[count] = SbusIn;
count++;

#ifdef TIME
// to measure frame duration with Osciloscope (actually frame is 3ms then 6ms pause)
// turn on light at the begining of packet (time to read with osciloscope before processing)
if (count == 1) {
digitalWrite(13,1);
}
// turn off light before end of packet (time to read with osciloscope before processing)
if (count == 24) {
digitalWrite(13,0);
}
#endif

// if for any reason the counter get flooded reset it (55 = 2 data frame + margin)
if (count > 55) {
count = 0;
}
}

// RUN CHANNEL PROCESSING AND SENDING ONLY IF BUFFER IS FULL
if (count == 25 && SbusInPrev == 0x00 && SbusIn == 0x00) {

#ifdef TIME
  digitalWrite(13,1); // activate light at the begining of processing
#endif
#ifdef BLINK
  LightBlink++;
#endif
count = 26; //avoid running the processing again if we have not received a new frame (ie : reseting count)
Channel[0]  = ((SbusBuffer[1] | SbusBuffer[2] << 8) & 0x07FF) + 0x1FC;
Channel[1]  = ((SbusBuffer[2] >> 3 | SbusBuffer[3] << 5) & 0x07FF) + 0x1FC;
Channel[2]  = ((SbusBuffer[3] >> 6 | SbusBuffer[4] << 2 | SbusBuffer[5] << 10) & 0x07FF) + 0x1FC;
Channel[3]  = ((SbusBuffer[5] >> 1 | SbusBuffer[6] << 7) & 0x07FF) + 0x1FC;
Channel[4]  = ((SbusBuffer[6] >> 4 | SbusBuffer[7] << 4) & 0x07FF) + 0x1FC;
Channel[5]  = ((SbusBuffer[7] >> 7 | SbusBuffer[8] << 1 | SbusBuffer[9] << 9) & 0x07FF) + 0x1FC;
Channel[6]  = ((SbusBuffer[9] >> 2 | SbusBuffer[10] << 6) & 0x07FF) + 0x1FC;
Channel[7]  = ((SbusBuffer[10] >> 5 | SbusBuffer[11] << 3) & 0x07FF) + 0x1FC;
Channel[8]  = ((SbusBuffer[12] | SbusBuffer[13] << 8) & 0x07FF) + 0x1FC;
Channel[9]  = ((SbusBuffer[13] >> 3 | SbusBuffer[14] << 5) & 0x07FF) + 0x1FC;
Channel[10] = ((SbusBuffer[14] >> 6 | SbusBuffer[15] << 2 | SbusBuffer[16] << 10) & 0x07FF) + 0x1FC;
Channel[11] = ((SbusBuffer[16] >> 1 | SbusBuffer[17] << 7) & 0x07FF) + 0x1FC;
Channel[12] = ((SbusBuffer[17] >> 4 | SbusBuffer[18] << 4) & 0x07FF) + 0x1FC;
Channel[13] = ((SbusBuffer[18] >> 7 | SbusBuffer[19] << 1 | SbusBuffer[20] << 9) & 0x07FF) + 0x1FC;
Channel[14] = ((SbusBuffer[20] >> 2 | SbusBuffer[21] << 6) & 0x07FF) + 0x1FC;
Channel[15] = ((SbusBuffer[21] >> 5 | SbusBuffer[22] << 3) & 0x07FF) + 0x1FC;

//separate 2 byte channel to 1 byte , for checksum and printing
for(count2 = 0; count2 < 16; count2 ++){
ChannelHalf[count2 * 2] = lowByte(Channel[count2]);
ChannelHalf[count2 * 2 + 1] = highByte(Channel[count2]);
}

((SbusBuffer[23]) & 1 )      ? Channel[17] = 2047 : Channel[17] = 0 ;
((SbusBuffer[23] >> 1) & 1 ) ? Channel[18] = 2047 : Channel[18] = 0 ;

//failsafe
if ((SbusBuffer[23] >> 3) & 1) {
  Channel[16] = 0; //failsafe
}
else {
  Channel[16] = 1; //normal
}

Serial.write(BeginPacket, 5);
Serial.write(ChannelHalf, 32);
Checksum ^= 0x20; // length
Checksum ^= 0x69; // message type
Checksum ^= ChannelHalf[0];
Checksum ^= ChannelHalf[1];
Checksum ^= ChannelHalf[2];
Checksum ^= ChannelHalf[3];
Checksum ^= ChannelHalf[4];
Checksum ^= ChannelHalf[5];
Checksum ^= ChannelHalf[6];
Checksum ^= ChannelHalf[7];
Checksum ^= ChannelHalf[8];
Checksum ^= ChannelHalf[9];
Checksum ^= ChannelHalf[10];
Checksum ^= ChannelHalf[11];
Checksum ^= ChannelHalf[12];
Checksum ^= ChannelHalf[13];
Checksum ^= ChannelHalf[14];
Checksum ^= ChannelHalf[15];
Checksum ^= ChannelHalf[16];
Checksum ^= ChannelHalf[17];
Checksum ^= ChannelHalf[18];
Checksum ^= ChannelHalf[19];
Checksum ^= ChannelHalf[20];
Checksum ^= ChannelHalf[21];
Checksum ^= ChannelHalf[22];
Checksum ^= ChannelHalf[23];
Checksum ^= ChannelHalf[24];
Checksum ^= ChannelHalf[25];
Checksum ^= ChannelHalf[26];
Checksum ^= ChannelHalf[27];
Checksum ^= ChannelHalf[28];
Checksum ^= ChannelHalf[29];
Checksum ^= ChannelHalf[30];
Checksum ^= ChannelHalf[31];
Serial.write(Checksum);
Checksum = 0x00;

#ifdef TIME
  digitalWrite(13,0);
#endif

}

#ifdef BLINK
if (LightBlink == 33) {
digitalWrite(13,1);
}
if (LightBlink >= 66) {
digitalWrite(13,0);
LightBlink = 0;
}
#endif

// emptying serial buffer , not sure if necessary missing information on that , better safe than sorry
if (Serial.available() > 0) {
Serial.read();
}

}

from vjoyserialfeeder.

Well, thank you for your hard efforts ... but did you read our dialog with @fape above? The SBUS solution is already implemented using this sketch and the code at sbus branch (it supports SBUS protocol alongside IBUS and MultiWii). I'll publish binaries these days.

The Softserial solution at 100 000 bps is impossible on Uno/Nano (they are not fast enough) - that's why we created the optimized inverter.

For your full MSP code I see you use Serial1, so you should be using Mega or something?

from vjoyserialfeeder.

Yes i read your conversation , i wasnt aware of that before writing MSP sketch a few day ago.

Yes i use a Mega , this work very nice , not a single variation in any bit and the added latency of less than 1ms is fully ok.
(failsafe set to "Hold" in radio and turn radio Off , it allow the receiver to send the same frame as if the radio was on , but you are assured that it will not change due to stick jittering)

For the softserial , yes i extendely tried it for the past hour , and it always produce inconsistency in the bit too often (even with a mega , and even with a hardware inverting (transistor 2n3904 with 1k resistor))

I just saw you sketch , i dont quite fully get it but i understand the principle , no library , no serial , no baud rate , just invert and parse , smart !
could never have writting it , beyond my arduino skill

from vjoyserialfeeder.

i installed SharpDevelop , load vJoy project , run it.
Get a bunch of "index outside boundarys" when runing in Sbus mode (MSP dont do that ) either compiled or inside Sharpdev.
and intermitent channel reading ( dont even get enough to have actual "ms")
(of course sbus connected directly to pin 3 , or any other pin and changed definition)

What can i do ?
(will try to make test about it but not conviced about my skill).

edit : forgot to run a test with RealTerm with your sketch
setting 100000 even 8 2
getting the nice 25 byte starting with 0x0F and ending with 0x00 0x00 , no jitter wathsoever
(having seen those a lot i can tell they are ok and moving accordingly to channels)

from vjoyserialfeeder.

I have not tried the latest changes yet. But as far I as see, there is no big change that may break something. I'll get back to you after I find time for testing ;)

from vjoyserialfeeder.

@fape OK, Thank you!

@tfoutfou I don't know what the problem might be with the "index ..." exceptions. Let's first try this:
I've uploaded a binary: here
Please try with it, just to make sure there's no problem with the compilation on your side.
If the problem is still there we'll have to debug somehow. Can you save the hex dumps from RealTerm to file?

from vjoyserialfeeder.

Same behaviour with your binary.
dont get the message "The index is outside the bounds of the table.", in french it is (L'index se trouve en dehors des limites du tableau.)
only get the message in the debug output of SharpDev , seem normal.

Here is the input from the serial , perfectly fine , (almost all channel at center expect 1 , 10 and 12)

0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000
0FE5031FF8C0073EF0810F7CE00306F880913DF0810F7C0000

25 byte as expected , starting with 0F and ending with 0000
and so on for megabits if i dont move the stick , without a single error , the serial input is not the problem i am pretty sure.

Let me explain the behaviour more in detail :

the program run "fine" , expect the update rate seem slowish (each time there is an index error in the background maybe)
the value in the channels are fines and moving with the stick but :

-the channel monitoring is flickering from blank to showing data (since it is kind of skipping data , same behaviour as if you unplug serial from RX)

-the status bar at the bottom is not updating and skipping packet , and showing :

"connected , 0 channels , 0 updates per second / & ms between updates" 50%ish off the time
and going back and forth to
"connected , 16 channels , 0 updates per second / & ms between updates" 30%ish of the time
and
"connected , 16 channels , 110 updates per second / 9 ms between updates" 20%ish of the time

dont get this kind of error with MSP and my sketch , it run smooth and constant near 111hz and 9 ms , and never showing 0 channels and/or empty data

from vjoyserialfeeder.

Interesting...
May I ask you to do a change in the source code?
In SharapDevelop go to MainForm.cs line 278
there you'll see:

System.Diagnostics.Debug.WriteLine(ex.Message);

Please change it to:

System.Diagnostics.Debug.WriteLine(ex);

I'm pretty sure this is the line which prints the error. With this change it will give us a little more details about where exactly the exception occurs.

Thank you!

from vjoyserialfeeder.

ok , done , i get thousand of this reapeating when connected :

System.IndexOutOfRangeException: L'index se trouve en dehors des limites du tableau.
à vJoySerialFeeder.SerialReader.SerialBuffer.get_Item(Int32 index) dans c:\vJoySerialFeeder-sbus
vJoySerialFeeder\SerialReader.cs:ligne 50
à vJoySerialFeeder.SbusReader.ReadChannels() dans c:\vJoySerialFeeder-sbus
vJoySerialFeeder\SbusReader.cs:ligne 67
à vJoySerialFeeder.MainForm.BackgroundWorkerDoWork(Object sender, DoWorkEventArgs e) dans
c:\vJoySerialFeeder-sbus\vJoySerialFeeder\MainForm.cs:ligne 274

and a few : "resyncing" at the beginning wich seem perfectly normal when i look at line 69 of SbusReader.cs
(not a single "resyncing" for 5 minutes of test after that , this confirm good capture of serial input right ?)

from vjoyserialfeeder.

Let's see now... I've pushed something, I hope it works. Look at the serial_fix branch.
You can either check it out with git or simply copy paste the contents of SerialReader.cs - whichever you find easier.

Please build it and see if the index... errors are gone.
Thank you.

from vjoyserialfeeder.

Nice job , it seem to work fine this time , no more flickering in the channel monitor or the status bar .

and also no error in the debug output of Sharpdev

Thanks

from vjoyserialfeeder.

Great news!
Thank you very much for helping me track this bug down.

In my experience the Read serial operation always returned the whole frame in one or maximum two calls. But it seems that it depends on the uart drivers, kernel buffering etc - in your case some frames have to be read in more than two passes. The code was not prepared to deal with this.

About the invert sketch: It does effectively digitalWrite(TX_PIN, !digitalRead(SBUS_PIN)).
In the Atmel microcontroller pins are represented as bytes in memory (called Port Registers) and the individual bits represent the state of a given pin. digitalWrite/Read have to convert the Arduino pin number to the correct port register address and bit number every time they are called. Our sketch converts them only once (caches them) and then simply reads and writes the bits.
See hardware\arduino\avr\cores\arduino\wiring_digital.c in your Arduino folder for the source of digitalWrite/Read.

Thanks again for your time and efforts!

from vjoyserialfeeder.

Thanks, i already figured out how the sketch work , it is beyond my actual skill to do direct port manipulation because i dont know how the command work and i think the documentation is less easy to found , but i kind of understand it , nice way to gain time.
(basically raw reading of one pin , and output the inverted same thing on the other pin , no baud rate involved or anything else)

Ok i see for the read operation , could it be because of your program issued the read command to fast and thus reading only what was in the computer buffer and not an entire frame because serial at 100000 bps is kind of "slow" ?

(i just try to understand with my limited brain , lol)

from vjoyserialfeeder.

Ok i see for the read operation , could it be because of your program issued the read command to fast and thus reading only what was in the computer buffer

Yes that is perfectly possible. But the reasons could be many. There's a whole stack of layers between the electrical signal and the Read operation.

When you call Read() you tell it how many bytes of data you would like to read - but by design the function is free to return less bytes than requested. So if I request 25 bytes and some bytes arrive, the UART driver may decide "that's enough, send them!" instead of waiting for the whole 25. I'm just speculating, but really there are so many things going on in the kernel that we can't be sure.

In my experience there's a big difference between the different USB UARTs - or maybe the biggest difference is in the way their windows drivers are written.
For example I have PL2303HXD USB cable which causes about 10% CPU usage, which is outrageous!
My nano clone has CH340 uart which causes cpu about 2-3%.

from vjoyserialfeeder.

I tested both: the latest sbus branch and I cherry-picked the serial_fix commit to sbus.
Everything works as expected in both cases.
All channel move between 1000-2000/0-100% with default settings on opentx (weight 100, offset 0)
Great work. Thanks!

from vjoyserialfeeder.

Thank you guys!
Your help has been invaluable.
The v1.2 release is up.

Now I'll close this issue, but I'll be happy to hear anyone's ideas or troubles.

Happy flying :)

from vjoyserialfeeder.

Hi all, I'm trying to connect the R-XSR FRSky receiver. I have tried both using the uninverterad pin (that can be found on the receiver) with a clean Nano, the uninverted SBUS signal connected to TX1 on the Nano. And then also the normal (inverted SBUS signal) connected to D03 pin with the uninvert sketch on the Nano. I do see a lot of "I/O-blinks" on the led on the Nano (in both cases). But nothing get's trough to the vJoySerialFeeder. I can also see things coming in on the Arduino "Serial Monitor" (though it's only "garbage" because I don't know the bitrate. :). Have I forgotten something?

from vjoyserialfeeder.

Hi,
can you double check the port settings. Click Port Setup button. They should be
100000 bps, 8 data bits, even parity, 2 stop bits.

If that's correct, we can try dumping some of the incoming serial data, but let's first see this.

from vjoyserialfeeder.

Hi again, I'm not sure where to set this? In Windows (on the COM-port)? The closest I can select there is 115200... In the Arduino software I cant find the port settings? What am I missing? :)

from vjoyserialfeeder.

Are you sure you are using the latest release?
https://github.com/Cleric-K/vJoySerialFeeder/releases/tag/v1.2

You should see this:

from vjoyserialfeeder.

Ok, latest version of vJoySerialFeeder downloaded (again, just to be sure). I'm using this sketch, it's compiles and uploaded to a Arduino Nano V3.0:

"Uppladdning färdig." = Upload complete.
So the sketch works and is uploaded ok to the Arduino.
The connection look like this to my Receiver:

The yellow cable is connected to the uninverted SBUS pad on the receiver.
Then in vJoySerialFeeder I have this now:

When I connect it looks like this, no data is coming in to the monitor:

Then on the Arduino and on the receiver the leds looks ok.
The white led on the Arduino flashes very fast. And the green on the R-XSR shows that all is ok (bind and receiving):

If I connect and monitor in the Arduino software, I do see lot's of stuff coming in:

But it's only garbage of course because the baud rate is "wrong" in there. :)
Ok... That's all I can think of... Is there anything else I need to do or change?

from vjoyserialfeeder.

Ok, that's strange. We'll have to look into the actual data.

Please download: https://sites.google.com/site/terminalbpp/

Start it and set it up like this.

The goal is to take some hex dump of the serial data. It does not have to be much - just click Connect, preferably generate some input and after several seconds disconnect it. Then attach here the log file (that you chose from the StartLog button).

Thank you!

from vjoyserialfeeder.

Ok, here you go. :)
20180405220107.log
FYI, as soon as I hit "connect" the data starts to poor in. I don't actually need to even connect to the transmitter... Also it states "Frame Error" where you have "Rx OK" in my window.

from vjoyserialfeeder.

For some reason the data is incorrect. Normal SBUS frames look like this:
0F E5 03 1F F8 C0 07 3E F0 81 0F 7C E0 03 06 F8 80 91 3D F0 81 0F 7C 00 00
They are always 25 bytes in length, the first byte is always 0F and and the last always 00.

When you look through the dump you should look for a 0F byte and then, 25 bytes later there should be 0F again - the beginning of next frame (and 00 before it - the end of the first frame). Of course 0F can appear inside the frame as normal data so not every 0F is start of a frame. (counting in the dump can be helped by the fact that there are 16 bytes in a row).

There is no such pattern in your dump. One of the reasons could be that (I'm just guessing) the UART convertor of the Arduino is unable to set the correct baud rate. What UART chip does your arduino use? The Uno and Nano I have tested are chinese clones and use the CH340 chip which works fine.

Do you have anything else to use as UART converter? another arduino? FTDI?

You can try again the inverted method (with invert sketch) and make dump again.

I really have no clue at this point what the reason can be. If you have time you can try different stuff and check the dump if it shows the correct patterns.

from vjoyserialfeeder.

I know this is improbable but just in case - any chance that you have switched the receiver to CPPM mode? (manual says switching is done with holding a f/s button for 4sec)

from vjoyserialfeeder.

Here's a simple way to narrow down where the problem stems from. Flash this sketch to your arduino:

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);
}

You don't need your receiver connected to the arduino.
It simulates SBUS source with a single channel which is changing linearly.
Check out the dump, also check out if you can connect with vJSF.

If it does not work - it means there is something wrong with the UART adapter - it can't read 100k baud rate correctly. If it works - the problem should be sought somewhere with the receiver.

from vjoyserialfeeder.

Ok, thank you for really digging in to this!
First. You where right. I did have the Receiver in CPPM mode. I guess it happened when I rebound it to test this out. Still it did not work when I switched (same result) on either of the Arduinos.

So, then I tested you SBUS Simulator sketch and it worked on both my Nano and the Uno.

This means It's the receiver that's giving me troubles. :)
I'll see if I can find an old FC to connect it to so I can actually see if it's working or not (maybe I broke it?).
The Transmitter receives Telemetry just fine, so it's not completely broken at least. :)

Again thank you for helping out!
I'll keep you posted. But now, it's bedtime here. :)

from vjoyserialfeeder.

Hi again, after a good nights sleep. I started fresh.

First I flashed the latest firmware on to to the receiver.

I remembered that I had prepared this receiver (months ago) to be mounted in a quad with the SmartPort feature enabled. That got me thinking. The yellow (slightly thicker cable) is actually connected to the uninverted SmartPort pad! So I then tested to use the normal SBUS-pin and the "invert-sketch" (I think I already tested that yesterday...) so, still no go.

So then I googled a bit and found that the uninverted SBUS pad is actually the pad just beside the uninverted SmartPort pad. So I soldered a new cable to the uninverted SBUS pad, cleaned the Nano and... Yes, worked!

So this is how it looks now:

And I'm now using the "correct" uninverted SBUS pad (blue cable):

All good, 5-6 ms delay from stick to sim is fantastic!

Thank you for all your help, the software you have written to accomplish this and the patience you have had with me! It's highly appreciated!

from vjoyserialfeeder.

Alright! I'm glad it worked out at the end.

(just for info: the update time is not delay. There is no way to know how long the frame has travelled before it is read at the serial port. The numbers show the time between individual frames)

I'm almost ready to release new version with some new feature like failsafe, trigger buttons, Lua scripting , linux support and other stuff ... (it's in the prerelease branch.
I have implemented support for SBUS failsafe but I have no way to test it (I don't have sbus receiver at this time). If anyone is willing to test here's a binary https://www.dropbox.com/s/xfjoiooca9yv09m/Release.zip?dl=0

If the transmitter is disconnected the statusbar of vjsf should say "... Failsafe (SBUS Failsafe...).
If one wants to use the native failsafe (configured through the transmitter), in the SBUS Setup the Use SBUS Failsafe option should be checked.

If anyone can test these two mode I'll be very grateful.

from vjoyserialfeeder.

Hi again! Ok, I have tested the new version.
When I disconnect the transmitter, I do get "fail safe". However if I turn it on again. It does not recover.
https://photos.app.goo.gl/GOY1KMm2rFpA3uLv1

Do I have to do something else?

from vjoyserialfeeder.

Aah, yes. It was a simple mistake.
Can you try now? Same dropbox link, I've updated it.

from vjoyserialfeeder.

Yes! It works, good work!. :)
Can I wish stuff here, or shall I post another "feature-request" thread? :)

from vjoyserialfeeder.