Mike Blandford

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

The file "UNISXR.pdf" I referred to above details how to handle the calibration with UNI firmware, it does NOT use the same method as FrSky, but is actually much simpler. You perform the calibration, mounting configuration and servo limit settings all in a quick and simple process using a LUA script on the Tx. I do the gain settings etc. from the LUA script normally used o the Tx. I have trouble with the Freelink software, it falls foul of my antivirus! I'll check if I can make that work. Mike

We need some more information. 1. Have you successfully used S6R or S8R receivers before? 2. Have you recently updated the firmware on the receivers? 3. Have you carried out the "Self Check" procedure on each receiver. 4. Have you set all the parameters available, e.g. gains, setting ch5 and 6 to AUX? 5. What Tx and firmware are you using? Mike

Yes! Specifically, you will need to do the levelling process AND re-enter all the enable, Aux and gain settings. Check the file UNISXR.pdf in the second post of the linked thread. It is worth noting the existing settings before flashing (if you haven't already flashed it!). Mike

UNI, ACCST firmware also provides VFR, and is available for the G-RX8. In the case of UNI, the VFR value sent provides the number of valid frames received out of the last 100 frame times. It is a "rolling" value (as a new frame is due, the value for 100 frames earlier is discarded) so is always up to date. With ACCST the frame time is 9mS (7mS for ACCESS). I don't know what method FrSky use to calculate their VFR value. RSSI is sent every other frame, so if a few frames are missed together, you may get a RSSI warning. VFR would only drop by the few missed frames. Depending on your Tx and firmware, you may be able to display the VFR value when in range check mode (or set up a voice output to report it). This would enable you to compare RSSI and VFR while doing a range check. When testing UNI (by several people), it was felt that VFR was OK down to around 60%. Both RSSI and VFR are useful. If you are close to losing signal, then RSSI will frequently be low, even though VFR is still quite high. If VFR is frequently low, then you are probably suffering from interference or the Rx antennae are masked. On a recent flight (with UNI on a S8R) I heard one RSSI warning, the log file (1 second intervals) shows RSSI was under 50 for 4 seconds. During this time VFR didn't drop below 87, and was above 96 for almost all the flight. On two other flights the same day, with the same model, one never had a VFR below 95 and the other had just two values below 96 (89 and 91). While the logging was only at 1 seconds intervals, 100 frames at 9mS spacing is 0.9 seconds so low values of VFR won't have missed being logged. Mike

My Archer plus R10+ binds to an MPM (FrSkyX2) without any problems. In general Archer plus receivers do bind to the MPM as long as the MPM firmware is sufficiently recent (I fixed a bug in the MPM a while ago). I just checked using 1.3.3.33 on the MPM. Mike

An aeroplane is flying at 40kts into a 40kt headwind and is 1 foot off the ground (a runway). What is its kinetic energy? The aircraft now lands so it is on the ground, stationary, facing into the 40kt wind, what is its kinetic energy now? Mike

Kinetic energy is calculated using the ground speed. It doesn't matter whether the moving object is on the ground or flying. If the mass is the same and the ground speed is the same then the kinetic energy is the same. An aircraft moving at a constant airspeed through air moving at some, non zero, speed WILL have more kinetic energy when travelling downwind than when travelling into wind. If an aircraft changes direction from into wind to down wind it WILL have to gain kinetic energy and if it changes from down wind to be into wind it WILL have to lose kinetic energy. Mike

I don't believe you may discount kinetic energy changes when turning. When flying downwind and aeroplane does have more kinetic energy than when flying into wind (even if the airspeed is less than the wind speed. You cannot have negative kinetic energy as the expression for it involves a velocity squared term. The answer to my simple question above is as the airspeed is increased the lift generated increases so the aircraft increases in height. Mike

OK, simple question: An aircraft is flying straight and level at a constant speed and angle of attack. With no other changes, the airspeed is increased, what happens? Mike

Sorry but the inside of the Galaxy is a somewhat different problem. The kinetic energy of the model is based on the velocity. The model velocity is the sum of the velocity of the Galaxy and the velocity of the model relative to the Galaxy. The relative velocity is positive when the model is flying towards the nose and negative when flying towards the tail. As it turns the model's kinetic energy will reduce. The question is where does the "lost" kinetic energy go? Mike

An aeroplane travelling downwind has a certain amount of kinetic energy, which is related to ground speed. On turning into wind the ground speed becomes reduced, so the kinetic energy is also reduced. The "lost" kinetic energy needs to go somewhere and gets turned into potential energy, appearing as an increase in height. Mike

That description almost certainly pre-dates the existence of UNI firmware. Only UNI firmware does tuning at the Rx end. If using UNI, use the method I described above. Mike

The crystals used by FrSky for the RF devices on both Tx modules and receivers have a tight tolerance. As a result they always work well together. There is some slight variation, and UNI firmware on the Rx does tune the frequency used on the Rx to match the Tx to get the absolute best performance. The frequency tolerance of the crystals used by RadioMaster (and others) on the multi module is much less tight, requiring the use of the tuning function on the Tx to bring them into alignment (I need a setting of -40 on one module and +40 on another!). In my opinion, multi modules (used with FrSky) should be tuned to match the frequency used by FrSky modules. This may be done by tuning to any FrSky receiver running FrSky firmware. The tuning should then be OK for all FrSky receivers. While UNI firmware will tune to multi modules that are a long way off tune, the module is then using hopping frequencies that are off from where they should be. If only UNI firmware receivers are available, bind to a receiver, use the UNI statistics script to find what the receiver has detected for the tuning, then set the tuning on the Tx to the negative of this value, then bind again and check the UNI tuning value is close to 0. UNI firmware also monitors the packet transmission rate from the Tx and synchronises with it. If the signal is lost for about 0.9 seconds, then failsafe is entered. With FrSky firmware, the Rx then enters a searching mode trying to find the signal again. This can take half a second or more. UNI firmware, being still in sync with the Tx, follows the hopping frequency sequence for another 4 seconds, so regains the signal quickly. After this time, synchronisation cannot be guaranteed so UNI also enters searching mode. Mike

The heating of NiCd and NiMh batteries while charging is confused by the fact that the chemical reaction of NiCd while charging is endothermic (cools down) while that for NiMh is exothermic (heats up). Both will, of course, heat up once fully charged if a charging current is still present. Mike

The processor chip that is used in some receivers (by FrSky now and, I believe, Spektrum now) is specified to operate down to 1.9V (RF section, actual processor 1.8V). Add on whatever the LDO voltage is (likely less than 0.5V) and the Rx should continue operating down to less than 2.5V. As a receiver, it will only take a small current, but if sending telemetry the current draw will be higher, up to 100mA. Mike

In the second post of the thread from where you downloaded the UNI firmware, there is a file "Universal ACCST Guide.pdf". This included the details of how to activate the Rx. Mike