Mike Blandford

I started by building a Tx from a Remcon kit (while at university, I couldn't afford a ready made system). I got a different make of kit receiver (with lots of "delicate SCRs), bought some Sprengbrook servo mechanics and made servo amplifiers for them. I put that lot into a home designed and built 'plane and went flying! That was interesting as I wanted to use mode 2, and everyone a Beaulieu was mode 1. I got the 'plane in the air and kept it there (overcontrolling!), but one of the mode 1 pilots having seen it flew helped trim it out and got it straight and level, then I was OK. (I was a qualified (full size) glider pilot and had 30 hours in a Cessna 150 as well so I knew how to fly). Really satisfying to have built all the radio gear and designed the 'plane as well. Later I got the book above and built a Rx to give me a second Rx. I also replaces the SCRs in the first Rx with a 74L shift register and repeated that for the Microtrol Rx so I had 7 channels on both. I also rebuilt my servo amplifiers with 11 transistors instead of the normal 9. This give a much better drive to the servo motor. Having obtained the circuit diagram of the Sprengbrook Tx, I then built a custom Tx using that. I then got "distracted" by building my own computer (before you could buy one). After years away from the hobby, I returned needing 35MHz equipment so bought a Fleet Tx and built a couple of Micron receivers. I rebuilt my servo amplifiers using some NE543 ICs, and some ZN409s and restarted flying. I no longer need to buiild everything, so I write the firmware for computer Txs (er9x and erskyTx, which many prefer to openTx as it is easier to use), and some parts of the firmware in other RC things like the MPM module and the openXsensor. The book certainly helped with understanding how everything should work. Unfortunately, my copy disappeared at some point, I may have lent it out and never got it back. Mike Edited By Mike Blandford on 11/12/2020 23:19:08

Tried to do mine but got: "Profile Section Incomplete. Fields marked with asterisk (*) are required." I checked my profile and there is nothing marked with a asterisk on any of the tabs! Mike

Posted by Eric Robson on 26/11/2020 00:22:05: Hi Graham, I should have twisted Richards arm for a Tempest wing for my Seafury as they are very similar. It would have saved a lot of work and UHU POR. So they should be! The Fury started out as the "Tempest light fighter", and used the outer wing panels of the Tempest. Mike

I have a significant concern regarding multi-protocol modules.All radios have a unique ID used when binding. With the proliferation of multi-protocol modules, which use their own IDs you are no longer certain that your radio ID is unique, a multi-protocol module may be using the same ID. This means a multi-protocol module user could "shoot down" your aircraft (and/or you could "shoot down" their aircraft)! The ID used in the multi-protocol module does depend on which protocol it is using. There is a danger if a MPM and your radio share the same ID. If both transmitters are powered on, then when you power on your receiver, you don't know which Tx it will "lock on to", it could be either. If you have an electric powered model, and "the other" Tx is sending something other than low throttle on YOUR throttle channel, then your model's motor would start unexpectedly. If you power your Rx on before your Tx, then, in the above scenario, it would lock on to the other Tx, at least if you power your Tx on first, there is a (50%?) chance your Rx will lock on to your Tx. Mike

From my direct contact with FrSky, they have NOT ruled out open source firmware being ported to the X20 (I was asking about putting erskyTx on the X20). To an extent, FrSky have needed to protect their investment in development. Certain other companies are producing radios that are mainly hardware copies of FrSky radios, and also run openTx/erskyTx. All these radios also use the multiprotocol module. This module started life as a DIY module, mainly used by people who fully understand what using it meant. There is, however, a significant problem if using FrSky protocols on the multiprotocol module. The transmitter unique identifier (UID) needs to be unique(!) for all radios using a particular protocol (remember the problem Futaba had with this once). All FrSky radios do have a unique UID, but there is no control at all over the UID used in the multiprotocol module. Consequently, this means that a radio using a multiprotocol module and a FrSky protocol could easily have the same UID as your radio. This is similar to operating two, 35MHz radios on the same channel, they will interfere with each other, your receiver will think it is bound the "other" radio. Bertrand has been employed by FrSky for over a year and a half. As I understand it, he is writing most of the new OS. BTW, if you move to an ACCESS radio, and still have some D8 receivers you wish to continue using, I have firmware available that opearates in D16 mode on a D8 receiver, see here: **LINK** This also provides a number of features of the ACCESS protocol (e.g. dual transmitter binding, map receiver outputs to any channel, SPort or hub telemetry, auto protocol detection at binding (V1/V2, FCC/LBT). Mike

If the radio is changed to mode 1, then the physical trim switch that is your throttle trim becomes the elevator trim switch. I only fly electric, so I configure my throttle trim to simply act as two push buttons, one of which is set to an "instant trim" function, a single press and all the flight trims are set to the current control positions. Mike

The radio setup data is also kept on the SD card, openTx (and erskyTx) do not store any setup or model data anywhere else. Mike

I use a FrSky SxR on several models. In stabilise mode, it just makes the model feel larger, so is useful for smaller models in windy (gusty) conditions. In "auto-level" mode it normally makes the model fly quite differently and gets in the way. I configure the Tx so that if I have auto-level enabled (on a switch), as soon as I move either aileron or elevator off centre, auto-level is switched off. Mike

I posted that more to explain how some things work. I've seen people asking how to set up 3-position flaps on a 3-pos switch. My preferred way is to use a mix with a switch as the source, then set the three output positions in the output screen by adjusting the 2 endpoints and the sub-trim for the middle position. Mike

Another "one mix line" method that may help, or be of interest. A channel with no mix line defaults to 0% (centre position), but this may be changed by using the sub-trim in the outputs settings that moves the centre position. So set the sub-trim to -100% and then use a mix line of: +100% MAX switch(!SA^) With SA up, the mix line is ignored so the output is the -100% set by the sub-trim. With SA not up the mix line outputs +100%. Mike

The output of a mix with a 3-pos switch as input is: Switch up = -weight + offset Switch middle = 0 + offset Switch down = +weight + offset In all cases the output is limited by the endpoint settings. Using a weight of 200% and an offset of +100% gives: Switch up = -200 + 100 = -100 Switch middle = 0 + 100 = +100 Switch down = +200 + 100 = +300, but limited to +100 by the endpoint setting. With an offset of -100: Switch up = -200 + -100 = -300, but limited to -100 by the endpoint setting. Switch middle = 0 + -100 = -100 Switch down = +200 + -100 = +100 Just a single mix line, no curves. Mike

The first flash is involved, but I now include a bootloader so any updates are then easily possible without opening up the Rx. I also wonder about the RM Tx (and the Jumper ones), since they use a multi-protocol module that includes FrSky D8 and DSM2 protocols, neither of which are compliant with the current ETSI regs. Mike

The D8 protocol operates by the Tx sending data every 9mS, 3 times (27 mS elapsed time), then the Rx sends back the telemetry during the next 9mS, so the Rx doesn't use so much bandwidth. Depending on the actual transmit power, the Rx may well still be legal, it is the Tx that isn't. If you have D8 receivers and an ACCESS Tx, you might consider flashing the D8 (note not the V8) receivers with the firmware I've written for them that supports the D16 (X) protocol to be able to continue using them. See here: **LINK**. This firmware auto detects the specific protocol at bind time (FCC/LBT, V1/V2). Mike

I have a few available, see **LINK**: ServoReverser: allows a servo signal to be reversed, and/or to be slowed down. SPortToHub: poll SPort sensors and output hub protocol. SbusToPpm: 16 channel SBUS decoder. APM_Mavlink_to_FrSky: Convert Mavlink telemetry to FrSky, either SPort or Hub protocol. Note that most of these override standard Arduino libraries so I may have accurate control of timing. Mike

This is what we have: **LINK** It goes down to your chin, so does reasonably stop droplets. Mike

Bob, the requirement (as I understand it) is for a "face covering", not specifically a mask. A face shield qualifies so you might try one of those instead. My wife got us a couple of face shields that we use when food shopping, more comfortable than a mask and you can breathe more easily. Mike

Just wondering how stiff is the tailplane. If it is not stiff enough you could be suffering from "control reversal". Spitfires had an aileron reversal speed of 580mph. What this means is that above that speed applying aileron caused the wings to twist in the opposite direction (ailerons act like trim tabs) with the result the aircraft rolled in the opposite direction to that intended. Later Spitfires had stiffer wings. If the tailplane is not stiff enough then applying up elevator pushes the trailing edge of the fixed part of the tailplane down resulting in the tailplane as a whole applying pitch down. The harder you pull up elevator, the more the pitch down effect! Mike

I have erskyTx running on most of the radios that run openTx (I'm just sorting it for the RM TX16S). Note that erskyTx is offered by FrSky as an option for the X9Lite. erskyTx is much easier to navigate than openTx, while providing about the same flexibility (both were forked from er9x). When you go to set up a model, you first get this index page: From where you may easily see what is available to configure. So if you are having difficulty with openTx you might consider erskyTx. Mike

Posted by Phil Lockwood on 17/07/2020 16:05:08: John I don't understand "Bump" Mike The Taranis shows "Usb connected" on it's screen - from what I can gather, it is that "StM32 Bootloader" is missing on my computer and that is the problem. Mind yopu I don't know where its gone, everything was working fine up to the software crash. Trying to keep this all in one thread, so this quote is from the "other" thread. "Bump" is just a way of making a thread have a recent post, so it doesn't get missed. The Taranis has TWO bootloaders. One (STM DFU Bootloader) is built in to the processor, and is active if you connect the USB cable with the power OFF. The other is part of the flashed program, is active if you power the Taranis on holding the two horizontal trims inwards, and should connect showing as two hard drives. The "Usb connected" display shows when you power on using the trims, and displays when the firmware detects the 5V power from the USB connection. It doesn't indicate that data is actually working. So, please leave the Taranis off, use a known, good working USB cable (not just charging only cable), and connect the Taranis to the PC using the USB. You should get the PC sounding that a USB device has been connected, and have a "STM device in DFU mode" appear. if neither of these things happen, then you need to check the soldering of the small board inside the radio that connects the USB socket to the other board. To do this, remove the battery, then undo the 6 screws holding the back on and remove the back. Mike

Down the right of this web page you have a list of the "Latest Forum Posts". At the bottom of this list you have a link to "More Latest Posts. . .". Click on that, then look for you other thread entitled "Taranis Problem". Mike

I assume then you do not get the "USB device connected" tones on the PC. If so, then see my reply in your other thread. Mike

The "STM device in DFU mode" is the Taranis! (DFU stands for Device Firmware Update). Try plugging the Taranis in again and the PC should find it and reinstall it in Device manager. Mike

The USB connector is on a small board that is mounted at right angles to another board. It is quite likely a solder joint between these boards has fractured. Mike

The Taranis has two items of firmware, the operating system (openTx in your case but could be erskyTx), and the (internal) module firmware. If you update the Rx to V2.1.0, then you need to update the module firmware to V2.1 as well. If you do update the Tx module, you will need to update all your receivers to V2.1 as well. V1 module/receiver firmware is not compatible with V2.1 module/receiver firmware. The reason for the V2.1 firmware is a problem was found with the V1 firmware. Under certain conditions, the Rx could lose the radio link for up to 0.9 seconds, and during this time it may also cause one, or more, servos to move to full deflection. Since if this happens near the ground it could cause the model to crash, V2.1 has been released that fixes the problem. It could not be completely fixed by just changing the V1 firmware (although V1 can be made to lose the link for only a very short time and only have the servo glitch for that time (less than 0.1S). I have done that for the firmware I have that allows a D8 receiver to operate in D16 mode. Mike

Keith: I use audio reports so don't need to look at the Tx while flying. Most are enabled by a switch so I can turn them off. The one item I find most useful is capacity used. That way I know how much battery is left. Mike