HELIOS A10c Radio Fix

[RoboPhred]

I started playing around with the source to HELIOS, and made a bit of progress on bringing back VHF AM/FM radio freq functionality.

 

The relevant bits are under https://github.com/Gadroc/helios/tree/master/Helios/Interfaces/DCS/A10C/Functions

and are named VHFRadioEncoder

 

VHFRadioEncoder1: xx0.000

VHFRadioEncoder: 00x.000

VHFRadioEncoder3: 000.x00

VHFRadioEncoder4: 000.0xx

 

The code connects these to devices 139 through 142 respectively.

 

I started trying to map the new values over, and managed Encoder4 just fine.

However, on starting on encoder 1, I get values that repeat before the numbers do...

 

Input : DCS Value
03: 0.40
04: 0.50
05: 0.60
06: 0.70
07: 0.80
08: 0.90
09: 0.00
10: 0.10
11: 0.20
12: 0.30
13: 0.40
14: 0.50
15: 0.60

 

Notice how at 9 it rolls over, and the values 13 through 15 are the same as for values 3 to 5.

I have not tried sending values yet, and I do not know what values the repeated numbers will resolve back to.

 

In order to get full control of the radios, this will need to be overcome. I am at a loss on this part, as this is the only approach I know of to set the frequency from scripts.

 

 

Read-only access however is looking a lot more shiny. As an experiment, I modified the Exports.lua generated by HELIOS to return the actual frequency in the same way it reads the UHF repeater frequency:

 

-- VHF AM
local vhf_am = string.format("%.03f", GetDevice(55):get_frequency()/1000000)
SendData(139, vhf_am);
SendData(140, vhf_am);
SendData(141, vhf_am);
SendData(142, vhf_am);

 

I also disabled entries 139 to 142 in the "gEveryFrameArguments" object found above it.

With this in place, I modified HELIOS to calculate the frequency correctly, and was able to fix the display. It is even possible to throw some math at the problem and perform these corrections inside Exports.lua, essentially backporting the data to what HELIOS expects.

Unfortunately, this will not fix the rotary encoders, and attempting to change frequency from HELIOS will still result in strange behavior.

 

 

Can anyone shed some light on where these device argument values come from? Is this internal to the engine, or are the arguments for these devices defined in lua somewhere?

[Capt Zeen]

hello RoboPhed

 

Your solution to get the correct numbers taking the AM frequency directly fron the device 55, only works if the selector of the AM radio is in MANUAL mode. if you change to other position, like presets, then the values obtained from the device 55 are differents and the numbres changes.

In the cockpit, the numbers are mechanics, so they dont change when you switch to a presets frequency.

 

In my export.lua i get the freq from the device55 only if we are in manual mode on the selector, then i change the freq based on the position of the cockpit rotarys.

In that way, when i switch to presets for example, i get the same numbers as the cockpit, and not the "actual" AMfreq from the device55 ( the presets one)

 

 

On the other hand, there is a way to make the inverse maths to pass from the helios rotarys to the export. but the problem width that is you need to check every output form helios to "see" if this is a freq rotary, and this take time.

For that reason i ended width the solution to change the rotarys by buttons

[RoboPhred]

Thanks for the feedback! I am in the process of building a few bits of hardware for a homepit, and its been interesting trying to figure out how to pull data out of this game.