The Official Armortek Forum - World leader in one sixth scale metal kits

To illustrate how OpenTX works and what it means by Physical and Logical Inputs and Outputs, here are two ways of viewing them (using OpenTX Companion):

The physical controls on the radio (sticks, pots, sliders, switches) capture control inputs.


The receiver outputs signals to the model via the software: in the Armortek motion pack, the four main receiver channels control four motors (servos), two for drive and one each for elevation and turret traverse. In OpenTX, this is how it looks on the INPUTS page.


The software determines how those motors behave to give you the logical outputs you select eg drive forward/reverse, turn, traverse the turret, elevate the gun.


In OpenTX this is done in the MIXER page.


The OUTPUTs page simply provides for setting limits, reversing motors or servos and trimming


Other functions such as sound and lights can be assigned to any physical input and can be adjusted. With a rotary encoder, for example, OpenTX can be made to recognise which position the encoder has selected and play the corresponding special sound. Other functions such as barrel smoke, lights or flash can be combined, such that all of them operate with one press of the momentary switch of the rotary encoder.

Like so much in RC, OpenTX was originally intended for model aircraft. It's worth remembering that OpenTX describes the four stick directions as AIL, ELE. THR, RUD. These are assigned to specific sticks according to the MODE selected. In the above, the radio is setup to drive on the right stick, with the turret functions on the left. The MODE is set up in the RADIO SETUP page, in this case as MODE 2 (RUD, THR, ELE, AIL). To make it less confusing for our tank models, it's worth assigning more meaningful labels to the four main inputs, which is done in the INPUTS page. So: THR becomes ELEVation, RUD becomes TRAVerse, ELE becomes DRIVE and AIL becomes TURN. (In practice, the right stick controls the two drive motors but to the user, it controls driving and steering).

Fantastic writeup, Stephen!
Thank you so much for taking the time to do this. I know trying to write something reasonably understandable takes a LOT of time.
Now that you have broken it down into manageable chunks, it sounds quite logical and doable.

You mention lights. Does that mean that the outputs are not just servo outputs - they can be on/off, flashes etc? Even PWM to dim a LED or control a motor with the right electronics?

How about failsafes?

Christoffer thanks for the kind words.

Lights; yes, you would set up ON/OFF using a LOGICAL SWITCH, which creates a condition which is TRUE when a selected physical switch is in a certain position. You would then add a SPECIAL FUNCTION which performed an action whenever the LOGICAL SWITCH is TRUE. I can show that below with my Sound/Recoil/Barrel Smoke combination. In the MIXERS page, you can also select a SLOW rate and a DELAY, which I've done for the barrel smoke to trigger it slightly after the main armament sound and recoil fires.

Failsafe: 3 modes available of which only one is really suitable for us: CUSTOM allows predefined positions to be set. For us, setting the sticks to central will stop the model if signal is lost. The other two modes are HOLD, which holds the last received positions (watch the model disappear into the sunset) and NO PULSES, which stops data transmission - it' intended for use with flight controllers. In addition to the FAILSAFE, telemetry equipped receivers such as the X8R generate an RSSI signal (Received Signal Strength Indicator), presented as a value between 0 and 100. A low signal threshold can be set to trigger an audible alarm.

I should have mentioned above that it's possible when setting up a new model that the sticks don't operate in the way expected, if for example, the motor terminals have been reversed. If you don't want to change the physical setup, this can be easily sorted in OpenTX. In the MIXERS page, the setup drives both motors in the same direction with up and down stick and in opposite direction with a sideways input. If the stick is moved towards a corner, the signals to the two motors are combined and a moving turn will result. To set this up, in the MIXERS page, one value is set in the opposite direction to the other three eg one turn value is set to -100. This has the effect of reversing the command when steering but not when driving. If the sticks aren't set up correctly, it's a simple matter of changing which WEIGHT is set to a minus value. This can all be tested in Companion before setting it up in the model.

There is also a channel reverse option in the OUTPUTS page but if this is used for one of the two motor channels, it will apply to both DRIVE and TURN, which is probably not what is required.

HEALTH WARNING - this stuff can seriously mess with your mind.

Combining functions in OpenTX. This just illustrates some of the clever stuff OpenTX can do beyond the simple basis setup. It illustrates the use of LOGICAL SWITCHES and SPECIAL FUNCTIONS.

Physical Setup: I wanted to trigger my main armament sound, recoil, barrel smoke and laser all on one switch. The sound and recoil are standard Armortek/Benedini, operated by a 12 position rotary encoder/momentary switch on the TX. The rotary switch can be easily installed in the Taranis X9D Plus Tx but it needs to be carefully calibrated, using the calibration routine (LONG PRESS MENU, PAGE to scroll through RADIO SETUP pages, in CALIBRATION, ENTER to start. Follow the on-screen prompts).

OpenTX setup: in the CHANNEL MONITOR screen (short press PAGE to cycle through the three MAIN VIEWS), the output values of each of the twelve rotary encoder positions are shown. Note the value for playing the main armament firing sound. (The value will be expressed as a percentage, in the range -100 to +100). In this case, the main armament sound plays with the rotary encoder in Position 3, with a value of -50. This value is output when the momentary switch is pressed and returns to the nil value of +100 when released.

LOGICAL SWITCHES create a set of conditions for the switch to be TRUE. An example: the LOGICAL SWITCH is TRUE if PHYSICAL POT S3 (the Rotary Encoder) is outputting a value of -50 (ie playing the main armament sound). SPECIAL FUNCTIONS can then operate on a LOGICAL SWITCH to make something happen, in this case fire the Barrel Smoker by switching Channel 5 (barrel smoker and fans) to ON for as long as the momentary switch is pressed. So we're now combining the sound and smoker channels to operate off one switch when one specific sound is played.

LOGICAL SWITCHES can be chained to set up a more comprehensive set of conditions, eg that the rotary encoder IS playing the main armament sound and IS NOT playing any other sound. A single LOGICAL SWITCH would work in this case but there is a possible issue with the encoder, which might not always output precisely the same value. I also wanted to make sure the barrel smoke never fires if I mis-select the sound. The extra insurance is done in two ways. Firstly the LOGICAL SWITCH can be set to be TRUE for an approximate value rather than a precise one (instead of a=x, a~x). Secondly, some extra LOGICAL SWITCHES can be chained to set conditions which are TRUE when any other value is played. This may look a bit complicated but like a lot of things in OpenTX, Companion can test the solution until it's correct.


To decode each of these lines:

A - Establishes a LOGICAL SWITCH which is TRUE when the rotary encoder outputs position 1 (value -84) or less (a<x)
B - Establishes a LOGICAL SWITCH which is TRUE when the rotary encoder outputs position 2 (value -67) AND LOGICAL SWITCH 1 is not active
C - Establishes a LOGICAL SWITCH which is TRUE when the rotary encoder outputs a value greater than -35, ie is playing any other sound (AND LO1 is not TRUE)
D - Establishes a LOGICAL SWITCH which is TRUE when the rotary encoder outputs a value which is approximately -50 (AND LO1 is not TRUE) ie plays our selected sound, main armament firing.

Note that each successive LOGICAL SWITCH supersedes the previous one.

BINGO - our sound can now play and trigger the smoker, after setting up the SPECIAL FUNCTION in line E

E - SF1 OVERRIDES CH5 whenever LOGICAL SWITCH 4 is TRUE ie it sends a signal to the relays which operate the vape box and fans which generate and pump smoke down the barrel. Smoke will pump for as long as the sound is selected by the momentary switch. I've also got a small red laser in the barrel which runs off the smoker fan relay. OVERRIDE might seem a bit confusing - what it really means is that it will send a command via that channel whatever the previous condition may have been.

I mentioned a few posts ago installing an FrSky current sensor into my setup. I've now done some further work with OpenTX using a .lua script to calculate battery capacity remaining in mAh. Lua is a high level, relatively simple programming language used to get the operating system to do stuff. In this case, I've used the output of the current sensor to create a virtual current consumed sensor, which can then be read against time elapsed and the battery capacity to calculate battery capacity remaining.

Although the script I used is intended for the small capacity LiPo batteries in model aircraft, it's not that difficult to adapt it to read Ah instead of mAh. I've set up a reserve of 20% of battery capacity and the sensor will generate a verbal warning at each 10% mark, down to the reserve limit at which point it will sound the Last Post.....

Once implemented, I've got a two position switch assigned to change from a simple, highly visible readout, for use during a running session, to a more detailed view to use afterwards.

On the detailed view below, the readings include capacity remaining as a percentage and a mAh figure, the current draw in real time and the maximum figure seen, the cumulative mAh consumed, the instantaneous and minimum voltage values and the battery capacity.


This is the simple view:


And this is my primary telemetry screen:


There is one shortcoming to fix, if I can either steal an answer from someone more clever or strain the neurones a bit further. Model aircraft tend to make one flight per battery charge. It therefore doesn't matter that the script dumps its data when the RX is switched off. It can be made to write to the data log but unless the script can be made to read that value as the new starting point, you won't get the cumulative figure we need, since we run several times between charges. I can see in theory how to do it in OpenTX but that's a far cry from actually doing it. Nevertheless, this is a very useful addition which takes the guesswork out of "will I have enough power to get back to the car and load the model before it conks out?"

Have sent you an email

Adrian.

Job done, thanks to Adrian and his coding magic. We've been poring over the entrails of the .lua script to generate battery capacity remaining. It was written with model aircraft in mind. Model aircraft batteries are recharged after a single flight, so there is no need for the data to be persistent when the power is switched off. In the end, Adrian has done a fairly comprehensive re-write and we now have a solution which is perfect for our tank needs. The data is kept between running sessions and can be manually reset when the battery is recharged by updating one simple data field in OpenTX. Result!

This is now the first telemetry screen:


The battery capacity remaining page can be toggled between a simple view, useful while running:


...and a more detailed view, with some very useful data for later analysis:


VFAS - battery voltage is an instantaneous readout of the voltage, which gives an indication of battery condition. In conjuction with Min (voltage) the voltage drop can be calculated, which is a good indicator of the long term health of the battery (lower the better). The voltage drop increases with internal resistance, which is a measure of the age of the battery and how it's been used.

Battery capacity remaining is self-explanatory. The original script deducted a 20% reserve but we've stripped it out, thinking it's better to have an absolute value, so you know where you stand. This value is persistent when power is switched off and has to be manually reset when the battery is recharged.

The data on the right relate to power consumption:

mAh is the power consumed since the system was last turned on - it resets when power is switched off.

Curr and Max are the instantaneous and maximum values of current flow. The latter is a very useful figure to know when considering battery choice, particularly with the newer LiFePO4 types. With these, the cheaper batteries tend to have a lower maximum Amp limit before the BMS cuts in. Typically, the high end batteries such as Tracer have values such as 30A max continuous and 60A peak for 10mS. For my Cent, I'm seeing a max peak current of 10A on flat surfaces, 6A continuous at full throttle. So there is plenty in reserve. It will be interesting to see how those figures vary with running uphill or on rough surfaces/grass.

The script will now retain data when you switch off between runs. It will need a manual reset when the battery is recharged, by entering the full capacity of the battery in the Global Variables page under GV9:


This has taken a lot of head scratching, particularly by Adrian but the result is everything we wanted and shows how OpenTX radios can start to do things other beers can't refresh. Thanks Adrian. I'm now thinking of simulating gun jump when the main armament fires.......

Adding Gun Jump.


The great thing about OpenTX is the ability to programme new functions and combinations of functions which add to the realism of the model. I've now added a feature which simulates gun jump (the tendency of the barrel to jump upwards in elevation as the barrel recoils). On the real thing, this is a very small angular displacement but since this is a simulation for effect, I've exaggerated the effect. Another great feature of OpenTX is that you can tune the values to adjust the effect. I started with a fifteen degree jump and toned it down to 10 degrees.

This is setup to operate from one switch. So, with the rotary encoder, the main armament firing sound is selected. When the associated momentary switch is pressed: the firing sound plays, the gun recoils (and now jumps after a 0.5 sec delay), the barrel smoke puffs and the small laser in the barrel fires. The smoke lasts as long as the momentary switch is held open. The other features are all timed to function automatically.

This only needed an extra Logical Switch to be added, which is TRUE when the Logical Switch controlling the other features is TRUE. This new Logical Switch is then allocated to the Rotary Encoder/Momentary physical switch, using a Special Function. This Special Function is set to override the elevation channel which is usually controlled by the left stick. The momentary elevation and return amount is set in this function. It took about thirty seconds to programme, once I'd worked out how to do it. Any new setup like this can be tested and adjusted in the OpenTX Companion simulation before committing it to the radio/model.

I've uploaded a short video to YouTube to show this feature here:

For people like me, who perhaps struggle a bit to follow the technical aspects of your Tx programming, that video speaks volumes. It seems there is no end to what you can achieve and that gun jump is magic.
Well done.
Kevin

I like that I like that a lot, maybe a little less jump but it's almost there! I don't know of anyone else managing to recreate this effect.
So next would be a little track jump as well? This would need to be directional of course?


You will need to click on the little round photo to see what I have been up to.
Regards Phil.

Awesome !!! Stephen
So when can I drop my Taranis off for a download?
Sorry Phil
I say no to track jump. It'll never look right on a broadside shot
Great looking truck though.

Good morning Stephen

That is great, taking it all to a new level, thank you for sharing.
I had better get programming to catch up.

Liam

6th June also marks another anniversary of note.

To quote the Australian War Memorial:

Today marks the anniversary of the battle of Binh Ba, one of Australia’s most significant engagements in the Vietnam War.

On 6 June 1969, two Australian armoured vehicles travelling north from the 1st Australian Task Force base at Nui Dat were fired on from the village of Binh Ba.

Two South Vietnamese Regional Force platoons were sent to investigate, but were forced to withdraw after coming under heavy fire.
Australian Task Force ready reaction force was dispatched: an under-strength infantry company from D Company, 5th Battalion, The Royal Australian Regiment; a troop of armoured personnel carriers of B Squadron, 3rd Cavalry Regiment; and a troop of Centurion tanks from 1st Armoured Regiment.

The Australians faced a formidable force of regular North Vietnamese Army troops from 1 Battalion, 33 NVA Regiment. During the battle one Australian was killed and 10 wounded. Four Centurion tanks were damaged by enemy RPG fire. The majority of the Australian wounded were tank commanders and crewmen. The tanks suffered losses but undoubtedly saved many infantry lives.

The battle was a decisive victory for the Australians and the regiments involved were later awarded battle honours.

Read more: https://www.awm.gov.au/articles/blog/BinhBa50

ARN169064, callsign 22B, Phuoc Me

CPL Barry Bennier, Commander, wounded in action
TPR David Hay, Operator, wounded in action
TPR Peter Matushka, Gunner, wounded in action
TPR Billy Morris, Driver - remained with the tank

During the two days of Binh Ba, the Australians lost one killed in action and ten wounded in action, the majority of whom were tank crewmen. The North Vietnamese forces lost over one hundred.

Great write-up from Stephen on the Taranis.

I would suggest toning down the "gun jump". The gun would not or should not move in relationship to to the turret except in length. It was more a visual effect caused by the hull rocking to help absorb the recoil. Much more noticeable to crews such as Stephen, due to change of sight picture, than to an observer watching from the side, which is what I was on many firing camps with Chieftain, Challenger 1 & Challenger 2. Any "jump" remaining after gun run-out was caused by the hull not rocking back to its original position.

Also question for Stephen, why did you decide to go with turret control on left stick ? Both John & I have our transmitters set for turret control on right stick as more natural for us. On CH, CR1 & CR2 powered traverse & elevation were done using the right hand, firing controls were operated with the left hand.

I am not suggesting Stephen is wrong, everyone should set up their controls as best suit them to have maximum control of their model. Just curious why he chose what he did.

Mark

I'm right handed and have the motors on the right stick as I find I have better fine control with that hand, which is important for driving.

Elevation and traverse is probably only used for less than 5% of the time when using the model, so no problem using the left hand for that.

I do have one customer who uses left stick for driving and it always confuses the heck out of me when using his tanks.

Adrian.