I’m attempting to set up Pix Racer and Mission Planner (or QGroundControl) to work with my Futaba 6EX and R6203SB in a conventional CCPM helicopter and unfortunately Mission Control reports that I have a bad Channel1 and QGroundControl advises me to turn the Tx on! Clearly my PixRacer hardware is not seeing the SBUS output from my R6203SB. The SBUS output is connected to RCIn and I have confirmed the SBUS signal is present on the Rx output (by oscilloscope) yet still have this problem. (Conventional PWM servos work if I plug one into one of the three PWM output channels on the R6203SB - so I know my radio is working).
Does anyone have any suggestions as to what I might have not done or set up wrongly please?
Ok, so if I connect my 6 Channel R606FS receiver (that being a conventional pwm rx with 6 separate servo channels) via a ppm encoder to RCIN, PixRacer/Mission Planner can see my radio signals/stick positions so clearly PixRacer/Mission Planner are set up to receive a PPM Sum signal not S.BUS.
Does anyone know how to connect an s.bus rx to PixRacer please, and is there any software setup required? The documentation implies that you connect S.BUS to RCIn, but I can’t find anything about software setup. Any suggestions would be much appreciated. Many thanks.
They definitely work fine with Sbus. At one time I had 3 of these FC’s flying all on Frsky stuff with Sbus. Still one alive today with typical Sbus out/RCIN.
Hi Dave, thanks for responding, I’m going nuts here!
PixRacer V1.0 and I have two of them. I didn’t want to try the second one as it was BNIB but have now, and it (doesn’t) works the same!
This documentation (Radio Control Systems — Copter documentation) appears quite clear…in that S.BUS is compatible and that Ardupilot autodetects the protocol…except that it doesn’t in my case! Clearly I haven’t blown the port up as it reads a PPM Sum signal ok.
My understanding is that FRSky uses a different port, I THINK because FRSKy is inverted wrt Futaba.
No, same port for RC. It does have a dedicated port for telemetry. Try using a serial port with RCIN protocol (23). I know nothing about Futaba but you could try the RCx_OPTIONS to invert the RX pin. But that might not work. Fact is these PixRacers are OLD stuff.
All very much appreciated Dave, thank you. I’m away today but will give it another go tomorrow.
Yes, old stuff, I bought them ooh, approx 10 years ago but stopped flying for various reasons. I’m now back and as I have them, I thought why not, they appear very capable.
I am using nearly the same FUTABA system together with my ESP32 based FC and it works fine.
But the SBus protocol is not a standard classical UART protocol.
SBus is using 100.000 Baud which is not a normal rate and the data are also inverted.
The new and actual FCs can deal with this but I am not sure if all old FCs are able to invert the signal SW controlled. I had read from some old FCs using a special SBus input instead of the normal RCin. The difference in this case is an additional HW inverter from SBus in to RCin.
So you can also check if a HW inverter between your receiver and RCin will help .
Hm, I don’t will say that it won’t work as i don’t know how the SBus implementation really is. If an F4 is using not a HW uart but a SW uart for this function it will be possible to work.
I’m not confident I have found the correct parameter to invert the signal…
Full parameter list - RC - RC_Options - (Set Bitmask) - Allow Switch Reverse…is the only one that comes near but it doesn’t sound right, so I’m assuming I’m wrong! (doesn’t fix my problem anyway!). Any suggestions please?
It occurs to me also that the online documentation I am using is presumably for the latest revision of the hardware (ie R15 and not the V1.0 that I have), Whether there is any difference in this area is therefore difficult to determine but it could be that the claim that it autodetects the protocol may not be correct for my version of the board.
That’s a good idea for investigation purposes, I’ll get to it, I surely have an invertor somewhere!
It’s not good from the installation point of view though, as it’s extra hardware/connections that I am hoping to avoid. I have a pwm encoder which works with pixracer and my 6channel pump receiver but that’s an extra bundle of wires and connectors (OK it’s MUCH worse than your single invertor idea!).
I’ll also write to the manufacturers I think and see if they’ve any ideas.
I have still not managed to include an inverter in the RC In circuitry…been busy/haven’t got an inverter to hand etc but I have ordered some and am still awaiting their arrival. If I Get anywhere with this, I’ll update the thread, but I am gradually losing patience with PixRacer/MissionPlanner as it is fighting me every inch of the way.
Since we last discussed, I have been using my ppm encoder (which works well) and despite the extra dangling wires, I have been able to make some progress with setting the machine up, but it has been a struggle.
I currently have two main problems:
I can’t connect MP using the built in Wifi Module
Once everything is set up, and with the artificial horizon responding correctly to the orientation of the helicopter and the system armed, the servos move when I command them to and the motor spools up but, the FC doesn’t move the servos in response to changes in orientation of the airframe…which is a rather fundamental failure!
I have searched for both problems and have found a number of links to the first problem Not that my problem is resolved) but not for the second one. As that has nothing to do with the title of this thread, I’ll raise another problem to see if anyone can help!
