Mike Blandford

I'm adding a note, about the bind button being pressed at the end of binding, to the guide. Was that the reason for your problems, or is there something else I should add? Mike

When binding normally, how are you doing it? In particular, are you holding the bind button pressed until binding completes? If so, then the Rx will see the bind button activated after binding, and this invokes a feature that erases the bind of the "other" Tx. Normally you do this, if required, by pressing the bind button after binding completes. To bind, I start the Rx in bind mode (power on with bind button pressed), and see the Rx has the red LED on, but blipping off every half a second (it is changing protocol when it blips). Then start the Tx binding. Mike

No they don't have to be on the same protocol. Does the problem happen with both transmitters? Call them A and B. If you bind A first, then B, A is the "other" Tx so should bind when in bind mode and you power on the Rx. If you bind B first, then A, B is the "other" Tx so should bind when in bind mode and you power on the Rx. Mike

I've just flashed a X6R with V57 and tested it. It works correctly. I first bound a X9D+ (my early prototype) using V2EU. The X6R did have some trouble binding the red LED was blipping, then held solid for a bit so it saw the X9D but didn't receive enough valid frames to continue binding, so continued blipping then the red LED held solid for a time (Rx was doing the tuning part) then the green LED came on as it did the bind and finally the red LED went off and the green LED flashed indicating bind OK. Power cycling the Rx and taking the Tx out of bind mode gave control of a servo OK. Then I bound the X6R to a X9LiteS, running ACCESS in ACCST mode, V2EU again. THis bound very quickly, and again, after power cycling the Rx and turning off bind on the Tx I had control of a servo. Turned off the X9LIteS and the Rx, Powered up the X9D+ and put it in bind mode. As soon as I powered the Rx it completed binding (red LED on, green comes on for a short time, then red off and green flashing. I swapped back to the X9LiteS, then repeated with the X9D+ and it worked again. Did you try with the Tx at different distances? Just move the Tx further away and power the Rx on again. Mike

Please confirm the revision of firmware you have on the X6R (Reported using the "Stats" script). Then I can run more tests using the same firmware. I just tested using a X8R (but currently running firmware with some changes since the last release) with 4 different Tx modules, and dual bind worked every time. When you power the Rx on, it looks for a bind packet from the "other" Tx for just a short time. If it sees a bind packet, then the green LED turns on (with the red already on). Sometimes this bind is sensitive to how far away the Tx is. You might try with the Tx very close, 50cm away and 1m away. If this bind is going to work, it will happen almost immediately. With V2 EU LBT, a normal packet looks very similar to a bind packet and causes the green LED to come on when looking for a bind packet, even if it is not a bind packet. Mike

UNI sends back a telemetry value of VFR (Valid Frame Rate). This is sometimes a better indication of link quality than RSSI. RSSI is just the received strength of received packets, but if a packet is missed RSSI doesn't change. VFR indicates how many of the last 100 packets that should have arrived actually did. So you could have a RSSI of 70 (Good) but a VFR of only 40 (bad) indicating a problem. UNI also fixes a few telemetry oddities where you may get incorrect values occasionally (I've seen "wild" values for altitude from a vario sensor). Otherwise you might consider whether you could use any of the other features of UNI: Ability to configure the SBUS output as a servo output (so the X6R can have 7 servo outputs). Ability to configure individual servo outputs to be 9mS or 18mS rate. Ability to map any servo output to any channel. Mike

Just checking you are following the correct procedure. The Rx is only bound to one Tx at a time. To swap, you need to bind to the other Tx. This is done by setting the other Tx into bind mode, then switch the Rx on. The Rx should then rebind, then you need to power the Rx off and on and take the Tx out of bind mode. Mike

First versions of the firmware did not have a bootloader. December 2019 I added a bootloader. January 2021: "I did a small change to the bootloader, to fix a problem when needing to bind with certain links fitted. One link could cause the Rx to stay in the bootloader." So there are two versions of the bootloader. The bootloader is included in the .bin file. For a first flash of a receiver, or to change the bootloader, you need to flash using the original instructions that include shorting the two pads on the Rx. After that, you may flash using AvrDude and a serial adapter, you cannot flash from the Tx. If you flash with AvrDude, and you have a different bootloader on the Rx, you will get a verification error. You may ignore this error. The update on post #640 includes the later bootloader, there is a version with the earlier bootloader on post #638. So if you have the bootloader already on a Rx, you still need to use the serial adapter method, not the Tx. If you get a verify error, you probably have a mismatch of the bootloader. You may either just ignore the error, or flash the file with the "other" bootloader in it, or go back to shorting the pads and flash the file with the new bootloader. Mike

I wrote the firmware for the D8R receivers first, then ported it to the D16 receivers when it became "UNI". I have since added changes made when testing UNI back into the D8R firmware, the file is on post #640 of the RCG thread "FrSky D16 firmware for D8 receivers". I added a note on the first page earlier today pointing to that post. Yes to "UNI" tuning to the Tx during binding, this has been in the D8 version for some time, so tuning a MPM should not be needed. Mike

The code returned by the Rx is a 12-digit code, two lines above the 888888. The 888888 is where you enter the code from the dealer to activate the Rx. What Tx and what firmware are you running (erskyTx/Ethos/openTx/edgeTx)? Are you binding with telemetry enabled (you need to bind before running the activation script). Mike

I suspect most of us have suffered a "rapid unplanned disassembly", which is apparently what happened 😁 Mike

I'm looking at the Arduino version but I talked to "mstrens" and he has added FBUS to the Rasberry version. Mike

I just checked with an original 9X (not 9XR) as slave to a Taranis Plus. All works, but the slave MUST have the RF protocol set to PPM as this is the protocol sent on the trainer jack socket. Mike

First checking the radios. You have a Taranis (not plus) running erskyTx and a 9XR (not 9XR-PRO) running er9x. What versions of firmware are you running? Mike

Do the cables run straight between the connectors, or are the connectors offset? Mike

I have an early Jumper T16 that had major problems with the internal ribbon cables. I have got the newer, gold cables, but I still get problems occasionally. I don't know if later units have been changed mechanically, but on mine, the two connectors for some of the ribbon cables are not lined up, causing a sideways force on the cables. This results in the cables twisting in the connector, and causes one connection in the ribbon cable to touch two positions in the connector. When this happens a switch or a button makes a second switch or button appear to change at the same time. It would be useful to know if recent T16s have the connectors in alignment. Unless you want a big, colour screen, or a touch screen, you might consider the FrSky Taranis QX7 (£117.52 from T9) or the X9Lite (£92.24 from T9). Either of these may have a MPM module added. The MPM project is an open source, DIY project. The "unique ID" in the MPM is not something controlled by the manufacturer, and in particular, cannot be guaranteed to be different from another manufacturer. So if you use a protocol from another manufacturer, you have no certainty it wont be the same as that on an "official" transmitter/module. Mike

As long as the file you are flashing has "sm" (for sub-master) in the filename, then just flash it an then activate it, so just go straight to 57. We have stopped releasing "update only" files (they had "u" in the filename). Mike

There is nothing on the sensors daisy chain, both 3-pin connectors are connected together. A Y-lead will work fine. Mike

I usually fly with telemetry so I get battery voltage, RPM, current, and mAh used. This makes interesting reading when logged. It tells me that the flight duration is significantly dependant on the use of the throttle stick (!). Looking at a typical log file for a model using a 12x6 prop and power supplied by two, 4-cell, 3000mAh lipos in parallel (so 6000 mAh) I see at the start take off I hit 59.9A at 15.4V (actually limited in the ESC to 60A, a FrSky neuron) and 10570 RPM. This drops to 53.2A at 10800 RPM 3 seconds later. I then see, shortly after take off, I reduce the throttle to 65%, and see 28.5A at 9540 RPM and 15.7V, dropping to 23A at 9940 RPM and 16V. So compared to static at the start of takeoff (922 watts) I'm flying with just 600 RPM less, but at a little over a third of the current (368 watts). I see for much of the flight, I'm at between 55% and 65% throttle and somewhere in the 20-25A, 300-350 watt area and 9000 RPM, with more power for aerobatics. This particular flight lasted 8 minutes and used 2900 mAh, so just under half the battery capacity. If I had used full throttle for much of the flight, I would have been running at 45-50A, so the flight would have only been around 4 minutes for the same capacity used. At the end of this flight, the battery showed 15.2V, so 3.8V per cell. For this model I use the capacity used rather than a timer to know when to land! Mike

Ethos is not a development of either openTx or EdgeTx, although, as Peter says, the main developer was the the main developer of openTx (he is now a FrSky employee). Ethos is only available for FrSky transmitters with colour screens and ACCESS protocol RF modules. It is very flexible and is not like "traditional" system, just includes some features so it is easier for "traditional" system users to get started with it. Mike ErskyTx developer and UNI receiver firmware developer.

I've just fixed an obscure bug on the RX8R-PRO (caused by undocumented timer functionality in the specific processor used ). The symptom was one of the servo pulses output on servo output 6, 7, 8, or the SBUS pin (if a servo output), very occasionally was too long by 940uS. V59 for the RX8R-PRO, with this fixed, is now posted. Mike

I just checked binding to a very old FrSky V8R4 receiver from a TX16S, all worked correctly. I do, however have some questions over the performance of the MPM (Multi Protocol Module). I've been testing FrSky receivers running UNI firmware. This has the advantage that they report VFR (how many of the last 100 packets were received OK), total missed packets and individual hopping channel performance. With an X9LiteS running ACCESS in ACCST mode (V2LBT), and old external XJT module (V1FCC) and a QX7 with internal XJT module (V2LBT), VFR is 100% and total lost packets remains at 0. The receiver is a X8R. With the RMTX16S internal module set to FrSKYX FCC and two other external MPM also set to FRSKYX FCC, bound to the same X8R, the total lost packets increases (some with CRC errors) and VFR drops to 98/99%. The individual hopping channels also show some are not working 100% of the time. Yes I have done the frequency tuning although for this test it is not really needed as the Rx auto tunes to the Tx at bind time. It seems the MPM hardware has problems with some hopping frequencies. As a further note on the general use of the MPM, there is no regulation of the modules unique ID, particularly compared to original manufacturers. This may lead to two transmitters having the same "unique" ID. Also, not all protocols support "Model Match" (Receiver number) directly in the protocol. For those protocols the feature is simulated by modifying the "unique ID". This means one MPM may then be using the unique ID of another MPM. Mike

Is anyone using an openXsensor who would like it to work with FrSky FPort or FBUS? I've just got one working with FPort1. Mike

I've used rectangular tubes made from 1/32" balsa. Mike

I've just posted an update to v58 for the RX8R-PRO (UNI_rx8rpro_58sm.zip). This should fix the problem (which was specific to the RX8R-PRO, it is OK on other receivers). It also includes the SPort polling rate reduction if too much data is being submitted on the SPort. Mike