Mike Blandford

How was the model memory copied? Unless you read the entire EEPROM from T1 and wrote that to T2, I assume you used companion to do the copy, in which case, companion could be performing some changes during the copy. You could try reading the model from T2 and copying it back to T1. Or use companion to read the EEPROM from T1, copy the model to an empty slot, delete the original model then move the copy back to the original position and write the EEPROM back to T1. Mike

My test was done after I just flashed openTx and had it create a new EEPROM, so the model I used was a completely new model. On those transmitters that do not bind, are you using a new model? If not, it may be some setting left in the model is causing a problem for LR12. Mike

There have been two releases of V2 firmware for the XJT module, 2.01 and 2.10. I just tested both on a X9D+ and both bind to my L9R. I'll see if I can put openTx 2.3.15 onto the X9D+ to see if that is a problem. Mike Edit: Tried openTx 2.3.15 and binding to my LR9 works fine (module at 2.1.0 EU).

I just tested a X9D+ with V2-EU firmware on it and it binds to a L9R without problem. I did need to select the correct protocol, not D8 or D16, in my case it is LRP, but I'm using erskyTx firmware not openTx. Mike

If you go back a page from the linked post, there is a description of how I built the tail. I think the clear film came Hobbyking. I as mentioned in the description I put a coat of Prymol on the film first, then paint went on with no problem. I finished with a coat of spray, matt varnish. Aileron servos are by the ailerons, see the picture 6 posts after the linked post. MIke

You might like to see how I did the tail feathers on mine, see here: https://forums.modelflying.co.uk/index.php?/topic/37723-who-wants-a-warbird-replics-hurricane/&do=findComment&comment=706536 Mike

Files are here: https://forum.alofthobbies.com/index.php?threads/uni-receiver-firmware-release-files-universal-accst-d16.3270/ Latest is V83, so the required file is UNI_x8r_83sm.frk, in the file UNI_all_V83sm.zip at the above location. Changes: UPDATE to version 83. Support S6R/S8R. Fix the problem that the failsafe servo pulse period was set specifically for each Tx. The failsafe periods are now specific to the Rx. Fix a bug on RX8R and RX8R-PRO where when using SBUS-IN and the main Rx loses signal, the servo outputs may freeze until channel 1 changes. Mike

What firmware and revision do you have on the Horus? What should happen is you set the external RF mode to MULTI, the type to DSM, and the sub-type to AUTO. Next start the Rx in bind mode, then select BND on the Tx. The Rx should bind, and send back the specific DSM mode and number of channels to the Tx that then sets the correct parameters. You may need to try the Tx at different distances from the Rx for this response to be received, it is only sent once, so if missed, the bind doesn't complete properly. There have been some receivers that won't bind unless the throttle channel is low enough (even needing a specific value). With the MPM, depending on the firmware flashed, it may be doing channel mapping. DSM expects to see TAER. The MPM may be accepting AETR and automatically changing this to TAER when DSM is selected. If the channel mapping is off, then you would need to configure your mixes to send TAER. As a suggestion, you could try creating a new model, and set all of the first 4 channels to output throttle, making sure they all are then at -100%. Now try binding using AUTO. Having looked at a pdf manual I note it says "make sure your channels don't exceed 100% when binding". Now 100% on DSM is 80% on the Horus, so a second test, with all channels set to throttle, is to set the limits of all 4 channels to 80%, then try binding again. Mike

I can confirm UNI firmware is available for the G-RX8. Using the XJT is a very good idea for FrSky protocols, rather than the MPM. All Tx modules have a "Unique ID", that is used when binding so that the bound Rx only responds to that Tx module. FrSky modules have a "Unique ID" that is allocated by FrSky, so all FrSky modules are unique. The MPM has a "Unique ID" (for FrSky protocols) that is derived from an ID in the processor. So, while this ID is probably different from the ID of other MPMs, it is NOT guaranteed to be different from official FrSky IDs. This means that if you use a FrSky protocol on the MPM and operate at the same time as a user of a FrSky module, it is possible both will have the same ID. Archer Plus receivers only work with the V2 version of ACCST. Mike

I'd also vote for looking at the "BBC Micro-bit". As well as the simple "block" programming method, it is also possible to progress to other methods, eventually using the arduino IDE and writing in "real" code (c/C++). Mike

I just did a test using a FrSky stabilising Rx. 1. Mount the stabiliser at right angles to the expected orientation. This swaps the aileron and elevator gyro controls. 2. Configure the stabiliser in v-tail mode. 3. Connect the rudder servo to the rudder output and the elevator servo to the aileron output. 4. On the Tx send the elevator control to the aileron channel. Check the operation of the rudder servo, it should move to correct yaw and move to provide rudder movement towards the higher wing when rolling, so "corrects" for both yaw and roll! If the servo corrects for one, but moves in the wrong direction for the other, then put the rudder servo on the elevator output. You may need to configure the stabiliser to reverse the servo operation (if the servo now moves in the wrong direction for both). If the stabiliser has the ability to adjust the gain for individual corrections, then you may have different amounts of corrective movement caused by yaw and roll. Mike

Please answer questions 3 and 4 from my previous post. If you don't do the "self check" you will not have "taught" the receiver how far the servos are allowed to move. This could explain the elevator only moving one way. If you don't set channel 5 and channel 6 to AUX, then these will act as second aileron and elevator outputs. Mike

On my S6R, inside there is a pad labelled P6. This has the SBUS signal from the processor. However, when used, the SBUS signal is inverted, so to use SBUS on the S6R you will need to provide an external inverter, even if you configure the SBUS to be a seventh servo signal. You also have the option of using the SPort signal as FBUS. Provided any sensors you use support FBUS (e.g. ADV sensors), you also get all 16 servo channels. I'm not sure, but I believe the openXsensor project provides servo signals when operating in FBUS mode, as well as providing sensor data. Mike

I think there might be a place on the PCB of the S6R where you may connect a wire to get SBUS. I do generate the SBUS signal. My only S6R is in a model, I'll need to pull it out and have a look! Mike

1. No, Using the UNI-SXR script does the required calibration, auto-level position and the servo limit settings, nothing else needed for those. 2. A long press of "EXIT" should end the scripts. Mike