Mike Blandford

I have a model based on Wolfgang Matt's Superstar that I built and flew before 1982 with a HP61 for power. It is now electric powered and I still fly it. I have a "Unique Models" spitfire that I built in 1974. I never managed to fly it then I was trying to do it electric but an Astro Flight 25 (Ferrite) with 16 NiCd cells was too heavy. I have now flown it with a brushless/lipo setup. As I didn't like the foam wings with a straight leading edge (it just didn't look right), it now has a correct shape, built up wing, but the fuselage and tail is original. My WOT4 pre-dates 1997, first flown with an OS40 4-stroke (when I returned to model flying after a break), it is now electric and is still flown. I also have a scratch built model of 52" span, based on the Superstar design, that is regularly flown, I have pictures dated 2002 of that, and a scratch built electric glider, also with pictures dated 2002, that is airworthy, although I haven't flown it for a couple of years. Also an even smaller Superstar based scratch built model dated 2005. I had to build that one to replace a similar model that suffered a mid-air with a Laser powered Corsair. The collision was almost head on and the Laser just chopped my model up until the prop hit the NiCd power pack. Curiously the current model also suffered a mid-air, although this time it only lost half a wing panel and I managed to repair it. Mike

If you have two transmitters, bind each Rx to a different Tx, then if you turn the Tx bound to the RX8R off, the other Tx should then provide the control. If only one Tx available, bind the two receivers using different receiver numbers. If you then swap the receiver number on the Tx between the two, you should see one Rx lose signal and the other gain signal, but keep control of the servos. I believe the RX8R will use the data from the SBUS in if it misses a small number of packets (sent every 9mS), it may do so if only a single packet is lost. Given only 8 channels are sent in a single packet, and SBUS passes all 16 channels, it probably waits for a couple of packets to be missed. Mike

Even with a steerable tailwheel my BH mosquito was difficult to steer while taxiing (with larger wheels than in the kit as well). Because there is little airflow over the rudder, it isn't in the prop wash of either motor, I use separate channels for the two motors and have asymmetric thrust configured, enabled by a switch, so that while taxiing moving the rudder channel causes the motor on the inside of the required turn to slow down. Now it is very easy to turn on the ground. Mike

From things I've read, CH12 has to change much quicker than over 2 seconds, and CH3 (throttle) must be at -100%. Mike

What do you need help with for updating your D8 receivers? If I can improve the instructions I will do so. Mike

I've been using FrSky modules, radios and receivers for over 10 years, and all have been reliable, so I'm not sure why you don't trust them. My main Tx I use for flying is a Taranis X9D+. I've been using that for over 7 years and still working fine. Some 'planes are using D8 receivers that are quite a bit older than that. I have about 11 FrSky transmitters (I do firmware development for them and get sent them!). All are working. I would still recommend FrSky, particularly if bought from the UK FrSky dealer (T9HobbySport), as you get the full dealer backup if there are any problems (all radios might have a problem whatever the make). Telemetry sensors are relatively low cost, if required, and are easy to connect. While the RM TX16S uses the multi-protocol module, such modules are available for FrSky radios (even for the X20 if you add erskyTx as a "dual boot" alternative to ETHOS). One important thing about the multi-protocol module (MPM) is there is no manufacturer control of the "unique Identifier" for the Tx. This means more than one MPM could be using the same ID, and any ID used could also clash with the original manufacturer of any protocol being used (except Spektrum as that uses an ID from the RF chip). From my experience with the MPM (I have 7 I think), the output power when using the CC2500 RF chip (used by FrSky amongst others) is lower than original manufacturers. Mike

It seems that something changed between my X20 (pre-production I believe) and current production ones (possibly in the bootloader). This means erskyTx didn't work on all X20 radios. I've found the problem and fixed it so there is a new "r3" version posted here: https://openrcforums.com/forum/viewt...hp?f=7&t=13679. It is still a "work in progress", but support is in for external modules XJT-lite and MPM. This version also has some limited touch screen functionality (information for this on the above post). Because of the "Dual boot" capability, you may easily add this, but still use Ethos as before. Mike

The multi-protocol module can "map" your radio channels to other channels for transmission. This is done so you may use a "standard" channel order for your models, but then match specific requirements for different protocols. DSM, for example, does use TAER I believe. If you use something different (say AETR), then the MPM may be set to change the channel mapping when DSM is selected as the protocol. There is also a control bit that may be set in the data sent to the MPM that enables/disables this channel mapping. I don't know how openTx controls this bit. This function may well have been added since the version you had and the update, and be defaulting to allowing channel mapping (it is a "disable" mapping function so a default of 0 would allow mapping). Mike

I've had a report that erskyTx "doesn't work" on a X20S, unfortunately without any further detail. I only have a X20, is there anyone who could test on a X20S and report what "doesn't work"? Mike

Unfortunately no. As openTx has moved through updates, it has changed the structure of the model data. So trying to maintain a conversion to erskyTx hasn't been practical. Mike

If anyone wants to try it, I've posted an initial version of erskyTx for the X20 here: erskyTx for X20. Lots still to do, but it is functional using the external module bay including support for the multiprotocol module. What is neat, I think, is you may install erskyTx alongside Ethos as a "dual boot" system, so you may continue to use Ethos, but switch to erskyTx to use the multiprotocol module. FrSky are OK with me doing this as long as I don't publish the parts of the source code that would reveal the hardware design, which is fair enough. I haven't had any technical data on the X20, so things take a while to work out. I'm doing this by reading a disassembly listing of Ethos to work out the connections. I've just found out how to access the touch screen hardware, but adding touch processing may take a while. Mike

As I understand it: 1. You use electrical energy from a renewable source (wind, tide solar, as mentioned in the article). 2. This energy is then used to extract CO2 from the atmosphere and combine it with water to produce a hydro-carbon fuel, releasing Oxygen to the atmosphere. 3. This fuel is then burnt in an engine, combining with the Oxygen released in (2) to produce CO2 and water. Result: The renewable energy used in (2) was converted to fuel, then mechanical energy in the engine. The water and CO2 used in (2) ends up being released in (3). It is a "closed loop", the amount of CO2 remains unchanged, so this is referred to as "carbon neutral". Mike

For general information, this thread may be of interest: https://forum.alofthobbies.com/index.php?threads/universal-accst-firmware-is-coming.2252/ T9 are one of the Dealers included. With this firmware, you can forget about "is the Tx V1 or V2"? It just binds while also offering some extra features (like dual bind). Mike

The example I posted is for erskyTx (not openTx). For erskyTx, there is also a PC program (called eepskye) that may also help when looking at erskyTx (companion was forked from this). Both eepskye and erskyTx are available at http://www.er9x.com/ Mike

The unit I'm working on has a new RF module that supports ACCESS, ACCST D16 and D8, I believe this is the first ACCESS module to support D8. This is not yet a product that is available. MIke

I've asked FrSky about this. I'm working with them on something new (including Tx RF) that supports D8, but this item is legal in the EU (I assume does LBT, but a FrSky engineer has confirmed it is legal). Regarding firmware on the TX16S, and FrSky radios, there is also the option of using erskyTx. erskyTx is er9x updated for the ARM processors now in use. A manual for er9x is here: https://openrcforums.com/forum/viewtopic.php?f=5&t=6473 openTx was forked from er9x, so many things are similar in both. Many users find erskyTx easier to use than openTx as the menu system is "better". In passing, sticky throttle cut is built in as an option. As an example, here is the model setup main index screen (this is for the smaller display radios). You may easily see what is available, and quickly go to it. Mike

The multiprotocol module supports operating as a receiver to provide trainer mode. One solution to providing trainer functionality is to plug a MPM into the back of the TX16, and use it to receive the trainer data, while using the internal MPM for model control. I agree that trying bending the socket connection is worth trying as that is a solution I referenced earlier in the thread. Mike

I suggest trying the following (Use Ron's images above to help with the settings): Set the QX7 as "Slave/Jack". Set the TX16S as "Master/Jack". Connect the radios together using the MONO cable. On the TX16S find the "Trainer" screen that shows the CAL values (the third one of Ron's). These CAL values are the raw sticks from the Slave, are are always active, regardless of any other trainer settings. As you move the sticks on the QX7, these values should change. If they don't, then the signal is not getting to the TX16S, so try pulling the plug out of the TX16S slightly, and/or wiggling the plug a bit to see if it is just a poor connection and you can then get the values to respond. If you make sure any throttle safety is disabled on the QX7 then changing the throttle position makes it easy to see if fiddling with the plug in the TX16S has any effect, the throttle value will jump to a new position if the signal gets through. Mike

I also have problems posting here. I click on "Submit Reply", the "button" is greyed out and then nothing happens (I'm using Firefox). By opening the site in another tab and generally trying several times to make the post I can, eventually get the post done. Mike

I've just run a test using my QX7 and RMTX16 and a mono trainer cable. In my case, I'm running erskyTx on both radios, but I believe the general setup is similar to openTx. I tested with the QX7 as student/slave and the RMTX16 as teacher/master. I needed to power both radios on. In the trainer setup on the QX7, I set it to "Slave" so it sends CPPM data along the cable. I checked this was working by looking at the signal (on the mono connector at the other end of the cable) on a 'scope. I then plugged the cable into the RMTX16, and looked in the trainer setup. I set this to use "Jack PPM". In erskyTx, the first 4 received channel data values are shown on the trainer setup display. At this point, they were all 0.0 and didn't change when I moved the sticks on the QX7. I then very slowly pulled the plug out of the RMTX16, At a particular position with the plug slightly unplugged, the data did arrive and the sticks did then change the values. Pushing the plug fully back in and the values stopped changing. I've also just found that pulling the plug towards the left and front of the TX16 gets it working. It seems the RMTX16 does not work with my standard mono cable. I have just seen a reference elsewhere to someone needing to bend the contacts of the jack socket (specifically the third one from the top) to get a reliable connection. Possible a different jack plug would be mechanically slightly different and make a good connection. Mike

While the equations are valid when all you have is a resistance, an electric motor (brushed or brushless) is NOT just a resistor, it actually has inductance (coil of wire) as well as the back emf due to rotation. Quite simply, if all the power from your battery is being converted to heat then your motor will rotate perfectly OK and drive the propeller without needing the battery, so just take the battery out and go flying! Mike

The battery is forcing 20 Amps against the back emf. Hopefully you can agree the motor is providing some mechanical power to turn the propeller. So where is this power coming from? The answer has to be from the battery (otherwise we wouldn't need a battery!), so at least some of the electrical power from the battery is being converted into mechanical power, not all the electrical power is being converted to heat. All that remains Is to decide how much of the electrical power is converted to mechanical power and how much to heat. This is where the back emf comes in, if you see a "black box" with 20A flowing into it, and measure 10V across it, then you should conclude 200W is flowing into the "black box". In our case, the "black box" is the back emf, so 200W is flowing into the back emf, and this is the electrical power that is being converted to mechanical power. Mike

Peter: Perhaps think of it this way. The back emf is providing a voltage (a bit like a battery) but we are driving a current Into that voltage (like charging a battery). So, in my example, we have a point in the circuit where we see 10V and 20A, which is 200W. If that was a battery providing the 10V, we would be charging the battery with this 200W, instead the 200W is going "into" the back emf. But where is the back emf coming from? It is coming from the motor rotating, so the 200W is going into the rotation of the motor. If the motor is not rotating, then no back emf, so no output power. Mike

Ask by all means. I've been flying electric for over 40 years, I still have my Astro Flight, ferrite motor I first use that was powered from 16, sub-C, 1Ah cells. Mike

One other way of trying to bring the cells to balance is to charge each cell individually, through two connections of the balance lead (assuming you are able to make up a suitable cable). I would then suggest charging each cell at 1A (the balance connector won't handle high currents), and see if they then come up to 4.2V. Mike