F3A Encoder Firmware Version 2.2 for the GTS Encoder or a Pro Mini Strong

[Mike_K]

PPM_Enc_8ch_F3A_v2.2d.ino

(29.9 KiB) Downloaded 41 times

The F3A encoder firmware has had an overhaul and I've added two important features, a low-voltage alarm and a watchdog timer as well as some other minor alterations. The update does not require any hardware changes, it’s just software, though the low voltage alarm does require calibrating which is done at the same time as calibrating the joysticks, but more about that below.

My range of “LCD encoders” (the fully programmable encoders with 10 model memories) have had an adjustable low voltage alarm and a watchdog timer from the start and it was on my list for a while to add these features to the GTS range of encoders that run the F3A firmware. I thought the low voltage alarm would need additional hardware and during 2021 I designed a prototype GTS encoder board with a low voltage alarm. It used a zener diode to detect the low voltage and used a transistor to switch the signal. There were no spare inputs on a standard ATmega328P with F3A firmware, so I used an Atmega328PB processor, which is the same as a standard ATmega328P (and backwards compatible) but with two additional inputs and used one for the low voltage signal and the other for the 8-way DIP switch to enable/disable the low voltage alarm. It worked well but made the firmware incompatible with the standard GTS or Pro Mini Strong. Unfortunately, my PCB design had omitted a track from the zener to the translator and even though it was an easy fix to solder a wire between them, I lost a bit of interest. It also coincided with the “chip shortage” where I could get the standard Atmega328P, but not the PB version, so I decided not to pursue the idea further.

Fast forward to just after Christmas and on the project list was a low-voltage alarm board for a GTS encoder, a separate board which could be connected to the standard GTS (or Pro Mini Strong) encoder with a y-lead. I then remembered the experimentation I'd been doing with GG recoders, measuring the battery voltage to compensate for the timing as the battery voltage drops. It measured the battery voltage using the ATmega328P internal voltage reference and wondered if I could do the same with the F3A encoder firmware. After a few weeks of spare time, the low voltage alarm was working well and at the same time, I tidied up a few other “loose ends” and rolled them all into the update.

How is the low voltage alarm implemented? The ATmega328P has an internal voltage reference called Vbg or bandgap reference that is around 1.1V (the data sheet specifies the range of tolerances, but as we will calibrate against AVcc with a fully charged battery, it isn't important). The ADC can measure it referenced to AVcc (the 5V supply) and if the nominal 5V AVcc drops, the measured ADC value of Vbg increases. The only minor problem is that Arduino analogRead() can't read the Vbg (I just can't understand why Arduino analogRead doesn't let you read Vbg or the internal temperature sensor). This was easily overcome by writing my own analogIn() function, based on the analogRead() function, but allowing full functionality. If we assume that AVcc is 5.0V with a fully charged battery and Vbg is 1.1V, then we should get an ADC reading of around 1.1*1023/5= 225. When the AVcc drops to 4.9V we should read 1.1*1023/4.9= 229, not much of a change, but enough. As the ADC readings are a little unstable, I've used a ring buffer to average over 16 readings to stop spurious alarms. As there is a tolerance in both the ATmega Vbg and the 5V voltage regulator, you need to calibrate each encoder individually. I decided the easiest way was when you calibrate the joysticks, it saves the Vbg/ AVcc calibration value to EEPROM at the end of calibrating. So it's important to always use a fully charged battery when calibrating the joysticks and low voltage alarm to ensure there is a full 5V output from the regulator. I’ve set the alarm level when the ADC Vbg reading increases by 2% over the stored value which equates to AVcc dropping from 5.0V to 4.9V.

All my encoders use the AMS1117 voltage regulator, as do many Arduino clones including the DM More Pro Mini Strong. These regulators have a dropout voltage typically between 1.0V and 1.2V above the regulated voltage and when the Atmega measures Vcc 4.9V, the battery voltage would be between 5.9V and 6.1V which is approximately the absolute minimum voltage for a 2S lithium battery. With my LCD encoders, I prefer to have the battery alarm set higher, to 7.0V as it gives me a few percent charge left, but an alarm when the battery voltage is around 6V is better than no alarm at all. If the low voltage alarm sounds, you would need to land immediately, but it could save a crash. An Atmega328P will work OK down to 4.2V (5.2V battery voltage allowing 1V drop off the regulator), but at this battery voltage, you may do permanent damage to a lithium battery (if the voltage goes below 5.75V). Most 2.4GHz modules will work below this alarm level too.

So the low volt alarm is really only suitable for 2S Lipo, 2S Li-Ion or 6S NiMH, 3S lithium or 7S/8S NiMH will let the battery voltage drop to a level where it could damage the battery before the alarm sounds, but again it's better to have a late alarm and damage a battery than no alarm and crash a model.

How do you test the low voltage alarm, if only to recognise the alarm sounder? If you have a variable voltage output power supply, it's easy, but many modellers don't have one lying around. I found an easy answer, temporarily power the encoder with a fully charged 4S NiMH pack fresh off the charger, it's voltage should be just under 6.0V and the low voltage alarm sounder should go off either immediately or after a very short time as the NiMH battery voltage will quickly fall below 5.9V.

The watchdog timer is a safety feature most microcontrollers provide, when enabled, it has to be reset regularly in the program loop, if it isn't then the processor is reset. So if for some reason the processor should “lock up”, due to a voltage spike, rf noise etc it will reset in a matter of a few hundred milli-seconds. As it's there it makes sense to implement it.

I've also tidied up a couple of other features as I get the same few questions asked more than any other.

First “Why is the second aileron output on CH5 and not CH6 like a Spektrum?”

The F3A firmware isn't a Spektrum and gets used with many other brands of 2.4GHz modules such as FrSky, Futaba, 4-in-1multi-protocol, as well as LemonRx, Spektrum DM8 or OrangeRx, so it's hard to follow a standard channel order. I'm not too familiar with the Spektrum channel order beyond the first four channels, is there actually a defined order? I did use OrangeRx modules (now all replaced with LemonRx modules) and had a box full of Spektrum AR500 receivers and they need the second aileron output to be on CH5, so initially I did the F3A output order to suit my receivers!

I've changed one of the options for CH5-CH8 to include one with Aileron on CH6.

Next, I often get asked, how do I change an elevon mix to have a different elevator percentage rather than the default 50:50 or 75:25? You can now define the elevator % before compiling (or if buying a GTS encoder, just as for a custom mix ratio).

I've changed the start-up sounder “chirp” so that I can easily distinguish between V2.1 and V2.2 firmware.

I’ve also had a few people say they can’t get the range-check feature working (where it automatically waggles the ailerons, so you can put down the transmitter and walk away holding the model to see what the range is single-handed). The are two points. The switch operation needs to be three complete on-off cycles of the gear switch ie, on-off, on-off, on-off (not on-off-on). Also, each switch cycle had to be completed in 0.3 seconds, I felt that I was going to damage the switch operating it so quickly, so I’ve altered the timing so each switch operation can now be within 0.6 seconds which I find much easier to accomplish and not so harsh on the switch, but quicker than you would ever operate the gear switch for retracts.

The wiring is identical to previous versions of the F3A encoder, I'll get around to doing the documentation soon.

Finally, I've tested exhaustively on the bench with Lemon Rx, FrSky and 4-in-1 multiprotocol modules, but with the weather in the UK I have not actually test-flown it, but if it works OK on my bench for hours, it should be OK in the air.

[stuart mackay]

Great stuff, Mike, some really worthwhile developments there!
Look forward to trying one out soon!