Asobo A320 ILS frequency

[AlMassimo]

Hi John, after a lot of trial and errors I was finally able to get my OpenCockpits NAV radios to work using offsets 0350 and 311E for active and standby frequencies in BCD format. Now my NAV1 radio is working pretty well for VOR navigation. Using Asobo A320 I discovered that it doesn't use NAV1 active frequency for the ILS approach.

It uses the L var (L:FLIGHTPLAN_APPROACH_ILS) that is unset until the ILS approach is activated on the CDU. But this frequency is not set on the 0350 offset (that should be the active NAV1 frequency).

I could use it (I assigned it a custom offset in FSUIPC7.ini and in SIOC I can read it) but it's a 32 bit FLOAT number, and I don't know how to deal with it.

I would like to see this frequency on my radio display, by setting NAV1 active frequency = FLIGHTPLAN_APPROACH_ILS, but I have to convert it from FLOAT to integer (and then to BCD to store it in 0x0350 offset, but this is easy in SIOC with TOBCD function).

Have you any suggestion on how could I use and convert the FLOAT value ?

Maybe that I can read it in LUA and then convert it in integer and store in a custom offset, or directly into A:NAV1_ACTIVE_FREQUENCY. I'll try this way, don't know if LUA gives an error trying to read an Lvar that is not yet created by the simulator (unless I set an ILS approach this LVAR is not listed in LVARs window...)

[AlMassimo]

I am trying to test this code

function ILS_freq_set()
    ILS_freq = ipc.readLvar("FLIGHTPLAN_APPROACH_ILS") * 100
    ipc.writeSW(0XA020, ILS_freq)
end

event.offset(0xA014, "FLT", "ILS_freq_set")

 

[AlMassimo]

WOW it works! As soon as ILS approach is activated, on A014 I read an uncomprehensible (for me) number, but on A020 I read 10994 (should be 109.95...)

I see on MF that the frequency is 109.949999, I must round up the number in LUA. Now I want to transfer this on 0X0350 offset, and I can do that in SIOC.

[John Dowson]

Glad you answered your own question!

Not sure why you are reading the lvar value though...Presumably that is held in offset 0xA014, and so you can access that directly as a parameter of your event function.

[AlMassimo]

Yes, I'm a little bit into confusion, if I could read directly the float value in SIOC I could avoid the lua code.
I could also use the function
event.Lvar("lvarname", interval, "function-name")
so it would be
event.Lvar("FLIGHTPLAN_APPROACH_ILS", 100, "ILS_freq_set")
if I then could assign directly the value to
A:NAV ACTIVE FREQUENCY:1
all would be solved. But I find it hard to understand how to do that.
Let suppose I have "ILS_freq = ipc.readLvar("FLIGHTPLAN_APPROACH_ILS") * 100 + 0.001" = 10995, how should I feed this to
A:NAV ACTIVE FREQUENCY:1 in lua ?
I imagine the only way is this :
ipc.writeUW(0X0350, ILS_freq)
but on offset 0350 you write :
NAV1 frequency, 4 digits in BCD format. A frequency of 113.45 is represented by 0x1345. The leading 1 is assumed.
To remove the first 1 I could do this :
ILS_freq = ILS_freq / 10000
ILS_freq = (ILS_freq - math.floor(ILS_freq)) * 10000
This gives 995.
So I should assign 995 to offset 0350 ? But this is not in BCD format...
Do I have to convert it to BCD ?
I think there should be an easier way but I cannot see it...
 

[AlMassimo]

And this is the lua code that worked without need for custom offsets...
It took me a smoking brain, but seems to work

function ILS_freq_set()
    ILS_freq = ipc.readLvar("FLIGHTPLAN_APPROACH_ILS") * 100 + 0.001
    ipc.control(67251, ILS_freq * 10000)
end

event.Lvar("FLIGHTPLAN_APPROACH_ILS", 100, "ILS_freq_set")

control 67251 sets NAV1 frequency in hertz !

 

[John Dowson]

ok...whatever works for you...
This topic may be of interest - how to convert BCD to decimal in lua:

John

[AlMassimo]

Thanks, it's very useful!

Regarding my solution, when I removed the offset assignment in Fsuipc7.ini, the lua event stopped working.
When I restored the assignment
5=FLIGHTPLAN_APPROACH_ILS=FA014
the lua function
event.Lvar("L:FLIGHTPLAN_APPROACH_ILS", 500, "ILS_freq_set")
restarted working.
It looks strange to me because in lua code I don't use offset A014, but now the Lvar is recognized, otherwise not.
Is this the normal behaviour of Lvars in lua ? Or it depends from the fact that the Lvar is created AFTER launching lua ?

Anyway, it works!

I just would like to know if is there some way to use float variables 32 bit in SIOC, lua seems to have no problems in handling them...

 

 

[John Dowson]

11 minutes ago, AlMassimo said:

Regarding my solution, when I removed the offset assignment in Fsuipc7.ini, the lua event stopped working.
When I restored the assignment
5=FLIGHTPLAN_APPROACH_ILS=FA014
the lua function
event.Lvar("L:FLIGHTPLAN_APPROACH_ILS", 500, "ILS_freq_set")
restarted working.
It looks strange to me because in lua code I don't use offset A014, but now the Lvar is recognized, otherwise not.
Is this the normal behaviour of Lvars in lua ? Or it depends from the fact that the Lvar is created AFTER launching lua ?

No, lvars should be available regardless of whether you are adding them to an offset or not. They must be available before they can be added to an offset, otherwise you would get an error when trying to add them to an offset. So something else must be going on, although I have no idea what... Are you sure that this is not just a timing issue - you have to wait for lvars to be received and available before using. I suggest that you retry with the logging console open (and set Debug level logging for the WAPI), and then you can see when the lvars become available. Or, if it doesn't work (without the lvar being added to an offset), wait a short while and try again. It is really the FSUIPC7.log file that will tell you what is happening, with appropriate logging enabled.

11 minutes ago, AlMassimo said:

I just would like to know if is there some way to use float variables 32 bit in SIOC, lua seems to have no problems in handling them...

I have no idea, sorry - check your SIOC documentation. 

[AlMassimo]

16 hours ago, John Dowson said:

ok...whatever works for you...
This topic may be of interest - how to convert BCD to decimal in lua:

John

This clarify me that the conversion from BCD to decimal value is simply a conversion from hex to decimal... I didn't know that.
The vale for a frequency of 108.00 MHz is returned as 2048 from the offset 0x0350.
The Hex value corrisponding to 2048 is.... 800! That means, adding 10.000 (because the first 1 is implicit) = 10800.
So now I know how to deal with BCD numbers (if I understood correctly), but anyway in SIOC I found the function
FROMBCD that solved the problem, I'll do more testing to check if it correspond to hex conversion, seems weird.
 

[John Dowson]

2 hours ago, AlMassimo said:

This clarify me that the conversion from BCD to decimal value is simply a conversion from hex to decimal... I didn't know that.

No! That is certainly not the case...

2 hours ago, AlMassimo said:

The vale for a frequency of 108.00 MHz is returned as 2048 from the offset 0x0350.

Yes - 108.00 is 0x800 in BCD, which when read as an integer is 2048. So this is obviously not a straight conversion from hex to decimal.

2 hours ago, AlMassimo said:

The Hex value corrisponding to 2048 is.... 800! That means, adding 10.000 (because the first 1 is implicit) = 10800.

Yes, exactly! But, a simply a conversion from hex to decimal of 0x800 would be 2048, which is not the frequency...

But you seem to understand...but your initial statement certainly isn't true!

2 hours ago, AlMassimo said:

So now I know how to deal with BCD numbers (if I understood correctly), but anyway in SIOC I found the function
FROMBCD that solved the problem, I'll do more testing to check if it correspond to hex conversion, seems weird.

Ok - glad you found the function, that should make things easier.

John

[AlMassimo]

Well, let me try to explain my statement.
Let say you have a frequency of 115.30 (VOR of Tessera Venice). Removed the first (static, so unsignificant) 1, you have 15.30 or 1530 as a 4 digits number.
The BCD value (binary) would be : 1 5 3 0  =  0001 0101 0011 0000 that is stored in a 2 bytes offset 0x0350.
When I read it I get 5424. What is this ? I didn't know how to use it for my display. But after I read the post you enclosed, I discovered that
is the decimal conversion of the hex number 1530 (binary 0001010100110000).
So from what I can say, if the frequencies displayed on the radio panel (115.30) are regarded to as a HEX number (and not a decimal number
as I always considered) removing the first 1 you obtain the hex 1530 that (in my opinion) is stored in 0x0350, and if I read it in SIOC (as a decimal
as normally is done with all the offsets) I get 5424, that now has a precise meaning.

Anyway I'm not at all an expert of BCD format, so I don't insist on my theory...

On the other hand I'm still dealing with the float conversion, that is done automatically in lua when I assign the float value to a SW offset :
    ILS_freq = ipc.readLvar("FLIGHTPLAN_APPROACH_ILS") * 100
    ipc.writeSW(0XA020, ILS_freq)
In 0xA20 I read 10994 that means that FSUIPC got the float values from the LVar, but then stored is as an integer (word) value.
If I did not multiply by 100 I would have obtained 109, that is the int part of the float number.
This gave me the idea that is possible to use the assignment to a SW offset to obtain a number usable in SIOC, as a sort of conversion
from float to integer.
I only would like to know how you deal with float variables in FSUIPC, because I remember something like they are multiplied by 65536 x 65536
or something, so they are not stored as a "floating point" value, but can be easily read and converted to the exact value to be used in
other applications (like SIOC).
Maybe is not the case for this Lvar, or maybe I'm totally wrong about floating points variables in Fsuipc offsets (very very likely so).

 

[John Dowson]

30 minutes ago, AlMassimo said:

When I read it I get 5424. What is this ?

That is 0x1530 or binary  0001 0101 0011 0000 in decimal...

31 minutes ago, AlMassimo said:

I discovered that is the decimal conversion of the hex number 1530 (binary 0001010100110000).

Yes. But it is far easier to ignore the binary and use hexadecimal as it is far more obvious. To convert BCD 0x1530 to a decimal equivalent (i.e. NOT the decimal value of the hex number), you drop the 0x and convert the string "1530" to the int value 1530, then divide by 100 to ger the decimal value 15.30, then add 100 (as the leading 1 is always dropped when frequencies are held in BCD format) to get 115.30. 
If you have the frequency in decimal, you cannot just convert that to hex - you do the same in reverse, i.e. subtract 100 to get 15.30, multiply by 100 to get 1530, convert to a string to get "1530", prepend 0x to get the string "0x1530", then you can convert that to an integer/hex number to get 5424/0x1530.

But we are going in circles here...google can show you all you need to know about BCD format.

49 minutes ago, AlMassimo said:

In 0xA20 I read 10994 that means that FSUIPC got the float values from the LVar, but then stored is as an integer (word) value.

You multiplied the lvar by 100, to get a lua number 10994.0. The writeSW funcrion would convert that to an C/C++ integer.

50 minutes ago, AlMassimo said:

I only would like to know how you deal with float variables in FSUIPC, because I remember something like they are multiplied by 65536 x 65536
or something, so they are not stored as a "floating point" value, but can be easily read and converted to the exact value to be used in
other applications (like SIOC).

No! The offset area is just a memory address range. You can read/write whatever type you like, including floats (4 bytes), doubles (8 bytes) and strings (any length). That is why there are ipc.writeDBL and ipc.writeFLT (and read equivalents), as well as the various offset logging types - see page 14 of the Advanced user guide to see the types supported.

Quote

 

Some simvars that are floats are converted and stored as integers, but this is for historical reasons. The offset documentation should say if any conversion is necessary - although it doesn't specify the type (only the size). Usually the type is obvious, but in some cases not, when you should refer to the FS documentation for clarity. I will update the offset documentation to specify the actual type at some point... when I get time - I have been meaning yo do this for a while but get very little time for such things due to the amount of support requests....

Just remember that offsets are just memory addresses, and must be read as the same type and/or size as they were written.

[AlMassimo]

Thanks a lot John, your answers are always very instructive and detailed. I think it's all clear for me now.

I think I am now able to solve 99% of the things I needed to make my radios working again with MSFS 2020.
Most things are now already working, at least for Asobo A320 for the moment, by a mix of Fsuipc, Lua and SIOC,
maybe it's a little bit more complicated than what could be, but it's working.
Now I'll try to extend the study to FBW A320 and B747 etc.

Seems weird but I removed again the custom offset assignment in Fsuipc7.ini and again Lua script seemed to
ignore the variation in L:FLIGHTPLAN_APPROACH_ILS, while the same Lvar, read through the custom offset
it works... I get no errors in log file, I will try to increase the logging level as you suggested.
For sure Lua reads the Lvar, since it transfers it properly to 0xA020 offset as an integer as said before,
but apparently the event.Lvar seems not to react to changes in Lvar!

event.Lvar("L:FLIGHTPLAN_APPROACH_ILS", 500, "ILS_freq_set")

is this correct ? (I followed the manual). 500 should mean 2 times per second.
"L:" should be optional, but I don't understand exactly what you mean in the manual
about the difference in declaring with or without "L:".

The event with offset doesn't require an interval.  As soon as I activate the ILS approach
on CDU, the offset trigger the event and the Lvar is read and converted to integer,
and I see the frequency on the NAV panel.
Using event.Lvar (the only modification I do to the code) no action is triggered
when I activate the ILS approach, unless I call it after having assigned the Lvar to an offset,
even if I don't use that offset at all! It only seems to make the event.Lvar function to work...

I'll do more testing with event.Lvar and other Lvars not assigned to any offset and
see if they work.
 

[John Dowson]

23 minutes ago, AlMassimo said:

but apparently the event.Lvar seems not to react to changes in Lvar!

I will check this here.

30 minutes ago, AlMassimo said:

event.Lvar("L:FLIGHTPLAN_APPROACH_ILS", 500, "ILS_freq_set")

is this correct ?

That should be ok. But I should update that function really and remove the interval - this shouldn't be needed anymore.

32 minutes ago, AlMassimo said:

"L:" should be optional, but I don't understand exactly what you mean in the manual
about the difference in declaring with or without "L:".

You can declare with or without the "L:".

34 minutes ago, AlMassimo said:

Using event.Lvar (the only modification I do to the code) no action is triggered
when I activate the ILS approach, unless I call it after having assigned the Lvar to an offset,
even if I don't use that offset at all! It only seems to make the event.Lvar function to work...

This is what I don't understand - it should make no difference,

I will check this here.

John

[John Dowson]

The event.lvar function is working as expected here, with or without adding the lvar to an offset, and adding an lvar to an offset should not affect the event.lvar function in any way. Something else must be going on.

Can you turn on logging for lua plugins (turn off all other logging) and generate an FUIPC7.log file showing your issue (i.e. without adding the lvar to an offset) and attach that, together with your FSUIPC7.ini file and the lua plugin/file you are using. List the lvars before and after you test - so I can verify that the lvar you re using exists and that the value has also changed.

[AlMassimo]

Ok sure I'll do that this evening.

[AlMassimo]

Hi John,
I tested the lua code and obtained some apparently incoherent results. At first, having removed the Lvar assignment in Fsuipc7.ini, loaded the flight, configured the airplane for takeoff, then set the CDU for ILS approach and the event was triggered, and the ILS frequency was detected and transferred to NAV1 active frequency 0x0350, and this caused SIOC to immediately update the display on the NAV1 panel.

I was encouraged to add other code to my lua program in order to get also the ILS course value. Also this worked fine. I was confused.

Then I made another fly, same settings, but this time the frequency was not updated. I went to Fsuipc wasm menu and selected list lvars.
ILS frequency was 0 and all other Lvars were still 0. But in the same instant when I selected list Lvars suddendly the NAV1 display showed the ILS frequency!
I hit list Lvars again and this time all Lvars showed their values. Very strange they were still 0 the first time, because the plane was loaded many minutes before,
so all Lvars should have been loaded by then.
I enclose the Fsuipc.log file, so you can analyze and check what was wrong.

FSUIPC7.log

[AlMassimo]

Here is the lua code if you want to have a look at it

function ILS_freq_set()
    ILS_freq = ipc.readLvar("FLIGHTPLAN_APPROACH_ILS") * 100 + 0.001
    ipc.control(67251, ILS_freq * 10000)
end

function ILS_course_set()
    ILS_course = ipc.readLvar("FLIGHTPLAN_APPROACH_COURSE") + 0.001
    ipc.control(65716, ILS_course)
end

event.Lvar("FLIGHTPLAN_APPROACH_ILS", 500, "ILS_freq_set")
event.Lvar("FLIGHTPLAN_APPROACH_COURSE", 500, "ILS_course_set")

 

[John Dowson]

10 hours ago, AlMassimo said:

Then I made another fly, same settings, but this time the frequency was not updated. I went to Fsuipc wasm menu and selected list lvars.
ILS frequency was 0 and all other Lvars were still 0. But in the same instant when I selected list Lvars suddendly the NAV1 display showed the ILS frequency!
I hit list Lvars again and this time all Lvars showed their values. Very strange they were still 0 the first time, because the plane was loaded many minutes before,
so all Lvars should have been loaded by then.

This indicates that the lvar was not found on the initial scan. When you list the lvars, a re-scan is performed, and so the lvar becomes available. You need to increase the LvarScanDelay WASM ini parameter so that the scan is performed after the lvars gave been created. I suggest you change/set this to between 45 and 60 (seconds) if/when using complex aircraft. And don't do this in your Community folder WASM ini as that will be overwritten - use the WASM permanent storage area (see the Advanced User Guide, WASM section, for details).

 

[AlMassimo]

Hi John, apparently there is some issue in updating Lvars, that is solved only with a list Lvars.

Until I click on list Lvars (some) Lvars are not updated or not read at all.

I mean some because these

[LvarOffsets]
1=A320_Neo_MFD_NAV_MODE=UBA000
2=A320_Neo_MFD_Range=UBA001
4=BTN_TERRONND_ACTIVE=UBA005

are read correctly and they control the MFD display just after some seconds of delay from flight start (as set in wasm.ini)
other do not

 

 

 

[John Dowson]

Just now, AlMassimo said:

Hi John, apparently there is some issue in updating Lvars, that is solved only with a list Lvars.

Until I click on list Lvars (some) Lvars are not updated or not read at all.

See my previous comment...

[AlMassimo]

Ok I've seen your reply, I have currently 25, I can increase to 50 but after 25 many Lvars are read (and work) but when I do the first list Lvars they still apear 0 and change only on second list Lvars

 

[John Dowson]

Just now, AlMassimo said:

when I do the first list Lvars they still apear

This is because a rescan is performed when you list the lvars...
I don't like this really but was implemented upon a request from LINDA. I think I'll remove this automatic re-scan and make it dependent on an ini parameter.

 

[AlMassimo]

Done, wasm scan delay increased to 50, this takes a LOT of time before being able to control MDF display (before it was just after 25 secs and always worked, both MDF MODE and MFD RANGE. But this is not a big problem.
The problem is that this time ILS frequency was correctly read and set by LUA and displayed on radio panel BUT COURSE DID NOT.
I checked in console and lua did not detect any event connected to ILS COURSE.
Even this time, hitting list LVARS, immediately it was read and displayed... I think it would be great to do some LVARS rescan, let say once every 10 seconds, or even more, just to be sure to intercept also LVARS created during flight, as ILS frequency and course (they are not even listed before creating a plan with an ILS approach).

Just because I'm a little stubborn (or very stubborn) I'll try again to define these 2 lvars in Fsuipc7.ini and see if they worked again as they did yesterday, regardless of was scan delay or list Lvars command...