Mike Blandford

The larger motor has larger magnets so a stronger magnetic field. To achieve the same kv value, it will therefore require fewer turns of the wire, so a shorter length of wire. Since there is also more space available for the wire turns, the wire is thicker. Shorter and thicker wire means less resistance so less loss. Using the same battery and propeller, the larger motor will spin a bit faster as more of the power from the battery will reach the propeller. Since both motors have the same kv, the same current will produce the same torque. To spin the propeller faster will require more torque, so more current. I would estimate (using Motocalc) a 5% increase in RPM and a 10% increase in current. Mike

No, that is not the setting I'm referring to. It is in the "HARDWARE" menu as "BATT CALIB". This calibrates openTx to display the correct battery voltage. You need to check this whatever battery you are using. Mike

Fully charged you should see more than 7.2V, more like 8 or more. If the battery is dropping 0.7V, but started at 8V, it would still be 7.3V. There is a setting to make the value you see match the battery. You need to measure the battery voltage, with the Tx on, and adjust the displayed value to match. Either the battery is poor or this setting is incorrect. Mike

I went gliding through the CCF Cadets (RAF section). Didn't have to pay anything. I did the basic course 23 dual winch launches, followed by the 3 solo launches to get a gliding licence!. I was then lucky enough to be offered the advanced course, so had 14 more dual launches and 16 solo launches. I remember trying to see just how slow the glider would stay flying, it got very quiet at 28 knots (open cockpit), I recall normal flying speed was 35 knots. I got a flying scholarship later so had 30 hours of power flying at no cost, and a set of "wings" for my uniform, still got the wings! Mike

Did you use the Web page to flash the firmware? What is the problem with LUA, does the ESC just not respond? I noticed that the web configurator is from a site called FETtec. FETtec appear to make various hardware, including ESCs, together with the firmware for them. We should be able to find out what the update protocol is! Mike

I would expect to connect the STK to the SPort signal for an upgrade. Looking at the instructions (I don't have a Neuron II) it doesn't look clear where the green connection goes! Mike

The STM8S003F3 is a: Value line, 16-MHz STM8S 8-bit MCU, 8-Kbyte Flash memory, 128-byte data EEPROM, 10-bit ADC, 3 timers, UART, SPI, I²C so it is a processor, not just a timer. My guess is the 4 empty pads are used when programming the device. To see if the connectors are likely to be for servos, check (using a multimeter) to see if the 3 pins closest to the board are connected together, and the next row up are also connected together. Also of the 4, empty pads at the end of the board, 1 is surrounded by a lot of copper. This is a ground plane, so that pad is also ground. See if that is connected to the bottom row of pins. Mike

I just use a "flight mode" for landing where I have the model trimmed with some up elevator for a slow glide with power off. Makes it quite easy to do a slow approach. Just throttle back, let the speed drop off, then engage the flight mode and I get a stable, slow approach. I even have it configured so that if I open the throttle more than 20% the flight mode is turned off. Mike

ErskyTx is available for the TX16S, maybe you would find that easier. It includes a specific menu for dual (actually triple) rates. Mike

Bertrand had more than one employment offer from R/C manufacturers at the time he moved to FrSky, so I would expect him to have a proper, employment contract or he would not have left his previous job. I am in contact with him, I've also helped with some programming problems and bug fixes. The upcoming feature "Play Sequence" is also the result of me asking for something like the "Voice Alerts" I have in erskyTx to be added to ETHOS. I also wonder if support for the MPM was added to ETHOS partly because support for the MPM is in erskyTx and ran on the X20. I find it interesting that the Archer Plus receivers support ACCST as well as ACCESS, and even auto-detect FCC/EU. Anything to do with the UNI firmware for older receivers, that auto-detects ACCST binding, being available? One main problem with new FrSky transmitters is developers need an actual transmitter to test on. In the past, FrSky have provided these free. I have at least 12, FrSky transmitters and I've only bought 2 of them, one of which is an X9Lite for which I was sent the money! I could look at the X18, but I would need to buy one and I have rather a lot of transmitters already! I do now have tools and knowledge that should make working out the hardware of new Txs easier and quicker. Then if the hardware module for a new Tx "looks" the same as other Txs, porting open source firmware may then follow quickly. My understanding is that FrSky have not ruled out having open source firmware on some transmitters in the future. Mike

FrSky have not released any hardware details on the X20 to the open source community. I have managed to work out most of the required information, and have ported erskyTx to the X20. It may be run as a "dual boot" system so it is easy to swap between ETHOS and erskyTx. erskyTx on the X20 does support the MPM with telemetry. For those who don't know erskyTx, openTx was forked from er9x/erskyTx, and many things a similar in both, although many erskyTx users prefer the menu system of erskyTx. I haven't, yet, sorted using the internal module in Tandem mode, so it only operates on 2.4G at present (ACCST and ACCESS). Recently I moved all the hardware specific code into a binary module so all the processor connections are not visible in the source code. This module will be made available to the EdgeTx developers. I understand they are intending to work on the X20 at some point. Mike

UNI firmware for the R-XSR is now in beta test. It all appears to work fine, I just need to add the CPPM support. Mike

Just checking you have tried three different tuning values (-40, 0 and +40) and all 5 possible FrSky protocols: FrSky D, FrSky X-D16, FrSky X-LBT(EU), FrSKyX2-D16 and FrSkyX2-LBT(EU). (For FrSky D you would need to short channel outputs 7 and 8 together on the Rx). Mike

The multiprotocol module (MPM), as used in the TX16S, is known to use crystals that have a poor frequency tolerance. As a result binding to a good quality receiver, with a good frequency tolerance crystal, doesn't always work as the Tx is too far off frequency. In the protocol menu is a "tuning" option to adjust the Tx MPM frequency for some protocols (FrSky is one of them). Try changing this to -40 or +40 and then binding to the RX8R (I have MPMs that need this much tuning, some +40 some -40). Once you get the Rx bound, you then need to find the "best" value for the tuning. Have a search for tuning the MPM to find how to do this. Mike

Try this: https://www.pdfdrive.com/the-art-of-electronics-e33411099.html Mike

I still cannot see any chamfers or grooves in that connector. I assume you problem at the retract controller is it only has a 2-way socket so a servo extension won't plug in. My suggestion then is to swap the existing 2-way housing for a 3-way housing from a servo extension lead, and put the 2-way housing on the end of the extension. Look at the existing plug and you can see 2 tabs that are retaining the crimps in the housing. Using a pin, gently lift each tab up and pull the crimp out. Repeat this with the plug on the end of the extension. Then just push the crimps into the "other" housings. Mike

It does look like just a 2-way version of a standard servo plug. A JST power connector has chamfered corners on one side and a groove down the middle on the same side so it is polarised. It should plug into a standard servo extension lead, just need to take care with the polarisation. Mike

OK, even with the FrSky firmware you only need to hold the button pressed while powering on, then you may release it (typically after 0.5 to 1 second). Mike

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