PXX protocol

Aaghhh I try to repost:

Yes it works!!

All ch1-8 move in the right direction, but minor comments:
min 998 should be 1000
middle 1500= ok
max 2000= ok

bind from PXX works tried with three different codes.
EU and FCC, both seem to work.

Range test seem to work led go to green with every 10sec red flash. While in range check still connection is there, so assume it works.

Failsave not so sure I tested it with switching off my devo and watch the receiver in betaflight.



When in hold mode it move back 1-3 to neutral 1500. 5-8 stay at its position 2000in this case. Throttle 4 -moves down to 885

When in nopulse mode all channel 1-4 stay in last position.

But it seems when switching off TX it seem random in which mode it will activate,Nopulse or hold...

One other point channel 8 channels 7 also, has a glitch at power on deviation,so repower on Tx after Rx failsave. Channel start at 2000 and in blink of any become 1500 than move back to 2000. (the other channels direct start and stay at thegood value.)

It could be also bug Frsky, Bug Betaflight or a display bug configurator no idea.

That's good progress! See comments below, but summary is it seems to be working. Do you have a stereo plug for the trainer port so the R9M s.port output can be connected? If it's working there will be telemetry data.

I'll look at making a combined build but it'll be a few days.

Fernandez wrote: All ch1-8 move in the right direction, but minor comments:
min 998 should be 1000
middle 1500= ok
max 2000= ok

The channel scaling function is the same as used for FrskyX, and this was discussed during that development. Changing the low end will affect the high end. May revisit this later.

Fernandez wrote: Failsave not so sure I tested it with switching off my devo and watch the receiver in betaflight.

When in hold mode it move back 1-3 to neutral 1500. 5-8 stay at its position 2000in this case. Throttle 4 -moves down to 885

This sounds very much like betaflight failsafe behavior. Is the connection to the FC SBUS? If so I'd guess betaflight is noticing the SBUS failsafe bit and running the betaflight failsafe algorithm. Try turning off betaflight failsafe and see what the outputs do.

Be sure none of the mixers have an individual channel failsafe set (they should all be "None"). If these are set they will override the protocol option, except for RX.

Failsafe settings are sent to the R9M module every 9 seconds. So after any change to failsafe settings wait about 20 seconds before testing.

Fernandez wrote: When in nopulse mode all channel 1-4 stay in last position.

Not sure about this one, but may also be a betaflight response. See what happens with betaflight failsafe turned off.

Fernandez wrote: But it seems when switching off TX it seem random in which mode it will activate,Nopulse or hold...

Do you mean switching off the Devo or the power to the R9M or both? The manual doesn't say what would happen if the R9M is powered on with no PXX input.

Fernandez wrote: One other point channel 8 channels 7 also, has a glitch at power on deviation,so repower on Tx after Rx failsave. Channel start at 2000 and in blink of any become 1500 than move back to 2000. (the other channels direct start and stay at thegood value.)

It could be also bug Frsky, Bug Betaflight or a display bug configurator no idea.

Hard to say where something like this may come from. All the channels are handled with the same code in deviation so an issue affecting just 7 and 8 would be unusual. What do you see with 16 channels active?

Ok yes stupidyou are right !
The failsave going too 885 throttle etc, it is betaflight behaviour. Not sure what is difference between hold and nopulse.

So now I tried now unplugging battery from R9M and kept deviation ppx running, the recovery after failsave is correct direct all channel.
The channel 7 and 8 startup for fraction of second at 1500, then move to 2000 is a deviation boot up-thing, now confirmed. 8 or 16 channel it is the same.
(could be that is not related PXX and a general deviation bug.) What I can tell 7 & 8 are 3 position switches, with mixer at complex, while channel1-6 mixer is set to simple.


Edit extra test: Same model file, same PXX testbuild but now binded to Frsky XSR, ch7 and 8 direct correct value 2000 at boot, so yes is something link with PXX....




For the 3.5mm yes I use a stereo plugand have it wired, but I get no telemetry data in transmitter telemetry monitor. ( I assume rx Voltage and RSSI shouldbe visible always) I never used this Rx port, middle pin 3.5mm, is there possibility to test it, loopback test etc? This to ensure input pin is ok?
Is it possible to be able to set/control the power levels25mw 100mw 200mW 1Watt ? (I assume that std deviation Power setting not work for PXX and it need to be set into sub menu?)

Power levels are set with the standard deviation power setting in the model config. The top four deviation power levels correspond to the four levels in the R9M. There is conflicting information online about whether a re-bind is needed after changing power level.

Do you have an FTDI adapter? If so a dev build includes the TESTSER protocol which has a loopback mode that echos any data sent to it. Let me know if you'd like me to make a test build.

I'll see if I can duplicate the channel 7/8 behavior.

Hi HexFET, yes Ihave FTDI available if you have some instruction, like to test my input Rx line first.

On the glitch channel 7and 8,seemy update above, it seem yes related to the PXX,as same modelfile same build on XSR receiver boot the radio all is fine.

Test build test_serial (1f6db55) includes the protocol TESTSER. In the protocol options set the mode to Loopback and the rest of the serial settings as you wish to use. The defaults are fine: 115200,N,8,1. Connect the FTDI transmit to the plug ring, and the receive to plug tip. Use a serial program like Teraterm to connect to the USB serial port. Make sure the serial settings match those on the devo. Then any characters typed in the serial program should get echoed back and be displayed.

Hi HexFet, Ioaded the RX input tester firmware, but the tester protocol is missing.

Please download again - had a typo on the build line. Test build zip is updated (same build number).

thanks Hexfet, were should I see my FTDI send characters?
Any particular display menu to select? I see nothing.

Looping my FTDI RX-TX I see characters atterminal, so FTDI is ok.
My 3.5mm cable also tested is ok, so could be my TX (bad soldering cpu pinetc), or the tester firmware.
As I see no characters displayed from terminal in Devo.

Found another issue in the test build that caused TESTSER not to work. Please get the new test build.

There's no display on the transmitter. When the Loopback mode is selected it should behave just like looping the FTDI tx-rx.

If the loopback test works, the next test would be to have the FTDI RX connected to the R9M S.Port pin. Set the FTDI bit rate to 57600, no parity, 8 data, 1 stop. Need to verify the R9M output is normal and not inverted. If normal the serial output should be received by the FTDI.

Ah oh retry and I will connect Rx and Tx lines then on my ftdi….
let you know asap

Ok tester works I receive Hand also the characters send from terminal in loopback. So my u7e is ok and so is the 3.5mm plug...

Will now check the R9M smartport @FTDI

Hmm difficult to see, inverted or uninverted both looks like rubbish, although inverted probably better....
The data displayed is FTDI programmed to inverted

Tell me...
Btw this is empty sport data it comesout of Sport while Rx is not linked.

The second capture with hex display (the one with many "7E" values) looks promising. Was that captured with data normal or inverted?

Whichever it was, please capture again with the receiver bound and powered on. May make a difference in the output data. Please save the data to a file and post that as it will be easier to check for valid data.

Ah I am crazy,certainly this S-port is inverted as I programed flashed my R9M via Sport and used the same usb programmer tool as for the receivers...…


So I have to make a little mosfet inverter or can we invert the UART Rxline same as on F3 flight controller?

Unfortunately the processor can't invert the signal. You'll need to make an inverter for now. I might look at a soft serial implementation but not sure it could support the data rate.

The protocol_pxx test build is updated (7a2bc3d). There was a problem with the failsafe setting code. It's not exactly the same as for FrskyX. This may change the behavior you saw with the No Pulses failsafe setting.

Test build is updated (fe73771). Fixes for s.port telemetry.

Thanks for the data capture - very helpful. It has RSSI and Battery telemetry values in it. Is it correct that the second capture (with many 7E values) was made with inverted data settings on the FTDI? If so that means an inverter will be needed for deviation, at least for now.

Thanks Hexfet, I confirm the txt file recorded in last post was with the FTDI setting to inverted.

I am travelling, but can do more testing after wednesday.