Mike Blandford

I've checked the source code changes on Github. The only change between 1.3.2.67 and 1.3.2.68 is a one line addition to sort the above problem, so it should be safe to use. Mike

I've looked at the source code of the MPM for the Hitec protocol, and it appears to be handling the tuning in a different way. I've asked on the Multiprotocol thread on RCGroups about this. Mike

FrSky protocols, when used with a FrSky Tx module and FrSky receiver don't need fine tuning. Any Multiprotocol module using a protocol with the CC2500 RF chip (that includes FrSky protocols) do need fine tuning. I have several MPM modules (6 I think!) and they are all different, varying between -40 and +40 when using FrSky protocols. Mike

When I tried flying with self-level on (FrSky S6R) I found it very odd. I now have it set up using a 3-position switch. First position is disabled. Second position is "stab" mode, for use in windy/gusty conditions. Third position is self level, but only if both the ELE and AIL sticks are centred (within 2% of centre output). otherwise it is "stab" mode. This way you may have the self level function, but as soon as apply a control it gets turned off. Not quite the same no self level, but nearly! Mike

Looking at a schematic I have, the component is almost certainly an ESD protection device. If it isn't connecting then there should be no adverse effects. Early radios didn't have this component at all. Mike

The programmer to whom you are referring started working for FrSky over 2 years ago, so if openTx was going to have stopped development I reckon that would have already happened! I've also had contact with him regarding openTx (and erskyTx) over those 2+ years. Mike

Some useful information regarding modifying the configuration of the multiprotocol firmware. If you are likely to update your module firmware in the future, and you change the configuration, you need to repeat the changes when you download the updated firmware. The first item in _Config.h is: //#define USE_MY_CONFIG If you remove the "//" at the start of that line, then an extra configuration file ("_MyConfig.h") will be included after _Config.h. If you put all the changes you need in this file, which is yours and not updated with everything else, then every time you download to get an update you only need to change the one line in _Config.h (enable USE_MY_CONFIG). How to change an existing setting? Suppose you want the channel order to be EART instead of the default AETR. Just put two lines in your _MyConfig.h file: #undef AETR #define EART The first line removes the default setting and the second line creates the new setting. A slightly more complete version is: #ifdef AETR #undef AETR #endif #define EART This checks to see if AETR is defined before removing it, then defines the setting you need. I think we are up to version 1.3.2.61 of the multiprotocol firmware. A recent addition, for those who like modifying things, is to provide a CPPM signal to enable a module to be used as a wireless trainer in many FrSky radios. How to do this is documented on the multiprotocol Github site. Mike

For the STM CPU based MPMs, the ID is generated from the unique ID of the STM chip, so the hardware manufacturer doesn't matter. The STM ID is a 96-bit value, based on (among other items) the batch number, wafer number and wafer x-y coordinates. The 96-bit value is treated as 3, 32-bit values and these are XORed together to give the ID for the MPM that is used for most protocols, including FrSky. I believe the ID used for DSM protocols is obtained from the Cypress RF chip unique ID, so this should be globally unique. You can't know that your MPM ID (from the STM ID) is different from all other MPMs. Perhaps we should, at least, get the MPM to report the ID is has to the system firmware and display it so it would make it easy to check with anyone else with a MPM, less easy to check with an official ID from, say, FrSky, but you could clone a FrSky ID you already have. The older, AVR processor based MPMs just used a random number as the ID. Mike

Are you referring to the MPM implementation of FrSky V1 or FrSky themselves regarding random IDs. To my knowledge, FrSky have always unique IDs. Mike

This is a bit of a toss up. In actual fact, the MPM is NOT guaranteed to have a different ID from an official FrSky Tx/module. In fact, you can't be absolutely certain that all MPMs have different IDs. Because of that, you may be better off cloning an official FrSky ID you have on another Tx/module so you are guaranteed to have a different ID from everybody else, just don't use your cloned Tx at the same time! Mike

Not needed as all the RF chips have a programmable output level, just change the firmware to reduce the output power on the higher output chip. I think the problem is that RF signals are tricky to lay out on a PCB. You need to match the antenna characteristics to get the best power transfer. Having 4 separate RF chips being made to switch into a single amplifier and antenna is difficult, it is very easy to have losses so some chip outputs end up weaker than might be possible with a single chip. Mike

No I don't think so. I believe I had done the required tuning before doing that test. In any case, I definitely see lower RSSI values with the same receiver on a MPM (I have several) compared to a FrSky module. I don't know what power amplifier the MPM is using, but it may have a lower gain compared to the one FrSky use, and there may be more losses due to switching the RF signal between the four RF chips. The CYRF chip (used for DSM) is set to +4dbm power output while the CC2500 is set to +1dbm (the max possible), so the DSM output is likely to be double that of FrSky in the MPM. It is even possible that the DSM output exceeds 100mW! I don't know what the gain of the antenna on the MPM is. I've understood that FrSky use a 2db gain antenna. Mike

It is only those protocols that use the CC2500 RF chip. I virtually certain each of the 4 RF chips use their own crystal/oscillator. I don't know the accuracy of the frequencies for the other three RF chips and I haven't tested them and I don't think they have a fine tune facility. Mike

To give some background to all this. Both a Tx module and a Rx rely on a crystal oscillator to provide an accurate frequency reference. The exact frequency then used to transmit and receive is derived from this. It appears that FrSky modules and receivers use a crystal that is very accurate so any module works with any receiver. It also appears that the crystal in MultiProtcol modules, for the CC2500 RF chip, is less accurate, hence the requirement for fine tuning of the frequency. I don't know the accuracy of the crystal in the R168. One of my MultiProtocol modules needs a fine tune value of -40 and another needs +40. If I use the one that needs -40 with a setting of +40, then it won't bind or operate servos. If someone has both FrSky receivers and R168 receivers, and a MultiProtocol module, it would be useful to test the MPM with both receivers and see if you need the same fine tune value for all receivers. If you need a significantly different value for the R168, then I would suspect the R168 crystal is less accurate, and would question if it was good enough to use with a FrSky Tx module, more testing would be indicated. Mike

Yes, I've got most of the fuselage assembled. My F4 was narrow but F6 was OK. I've done the same as you for the rudder, just used 3/32 sheet instead of 1/16. WIng outer panels are done with top sheeting, ailerons in and hinged, one wing panel has a servo mounted for the aileron, flaps built (4 off!). The centre section is mainly ribs and spars, no sheeting. I stopped when looking into adding the retracts, then got sidetracked while I built a Warbirds Replicas Hurricane. That's been finished for some time, but I've had no chance to fly it. Mike

Schematics for boards up to V1.1 (in EAGLE format) are on the Github pages (go back up to DIY-Multiprotocol-TX-Module then follow STM PCB). I think you will find that link is for putting the CPU into internal bootloader mode. Looking at the board layout for V1.1, there is a reasonable amount of copper acting as a heatsink, so the thermal resistance should be better than 90 degC/W. Even from 12V, you are looking at a maximum of 700mW power dissipation from the 5V regulator. So 63 degC junction to ambient at 90 degC/W so OK to an ambient temperature of 62 degC and should be somewhat less. This is assuming a current drain of 100mA (max. specified). Mike

Really? 6 NiMh or 2 LiPo/Lion will be over 7V so that module isn't specified to work in many transmitters! The Taranis switches battery voltage to the external module connector. Mike

I'm watching with interest. I have one of these I've been building, but other things have stopped progress at present. I've had the plan, cowl and canopy for many years, and got the laser cut parts well pre-Sarik. I looking in to how to fit retracts. Mike

I haven't checked the components fitted to the Jumper version of the 4-in-1 module, but (from the original DIY design) the first voltage regulator is supposed to be an AMS1117-50 in a SOT223 package (5V, it is followed by a second regulator to give the 3.3V). With the current specified to be no more than 100mA, then the first regulator should be dissipating no more than around 500mW ((10V-5V) * 100mA). With a thermal resistance to ambient of 90 degC/W, this is only a temperature rise of 45 degC. With a maximum operating junction temperature of 125 degC, it should be good up to an ambient temperature (inside the module) of 80 degC. The thermal resistance may be less if there is a good copper area on the board to which the device is soldered. If they have skipped fitting this first regulator, then there will be a single regulator providing the 3.3V. This will be dropping 6.7V from 10V, so 670mW at 100mA. This will give a temperature rise of 60 degC, so OK up to an ambient temperature (inside the module) of 65 degC. If they have fitted different components or used smaller packages then these would need to be checked. Mike

Ace: When needing a new line, hold the shift key down while hitting return. Then you get single line spacing. Mike

Just got mine so printed some on A4 paper, I'll tape them on as I did the last one. As I only fly electric that should be fine. For information I use 14 point text, Arial Narrow font, and the text came out 4mm high and 48mm long. Mike

Short term workaround to move between pages or switch condensed/expanded, right click on the item and select open in new tab(or page). Mike

On these radios (FrSky Horus and similar) they use files on the SD card to store the radio and model data (not EEPROM). So if you have put a blank SD card in you won't have any such data. You need to copy the required files from your original SD card to the new one. I'm not sure what they are called as I use erskyTx not openTx, but I think there may be a directory in the root of the SD card called "Radio" that contains them, or at least the radio setup data. Mike

Posted by MattyB on 01/02/2021 14:26:15: However, the MPM does not transmit HH's original DSM2, but a reverse engineered version. Since there are multiple ways to comply with the new regs by tweaking duty cycle etc it is perfectly possible that what is transmitted by the MPM when it links to a DSM2 RX is legal. Since it is the reverse engineered version that is being certificated (along with all the others in the MPM) as compliant by the manufacturer, all is well from the perspective of the user. As such there is nothing illegal about buying or operating a Radiomaster TX in the UK or EU. Do I believe every protocol in the MPM complies with ETSI regs? I somehow doubt it, but since a) the manufacturer has assumed any risk there for purchasers and b) I will only be using Frsky and DSMX only I'm not too worried tbh. YMMV. I thought the reason why DSM2 doesn't comply with the ETSI regs is it doesn't frequency hop, nothing to do with duty cycle etc. Having just checked the MPM code, as far as I can see the implementation of FrSky D8 protocol does the same as the original FrSky D8, so as FrSky D8 doesn't comply with ETSI, neither does the FrSky D8 protocol on the MPM. Also, the MPM allows you to select FrSky D16 FCC, that doesn't comply with ETSI regs. Mike

David Hall 9: I don't know, I use erskyTx.firmware not openTx. I think erskyTx will work fine, but all my Receivers do provide RSSI so I haven't tested it. Geoff S: Sorry, no numbers. I've seen the reduced RSSI values in testing, but I only ever use FrSky modules for flying with FrSky protocol(s). Mike