Problems with COM-Frequency assignments with FSUIPC

[jonas_llubi]

Hello, 

i am new on this forum so i will shortly introduce myself. 

My name is Jonas and i have a little "Single-Pilot" A320 HomeCockpit with some original modules and some selfmade panels.

For the connection with MSFS2020 i am using MobiFlight and the software "IOCModules" from OpenCockpits. 

 

I have the plug-and-play version of the A320-Radio from OpenCockpits and i am using the "IOCModules" software to use it with MSFS2020. I have the problem that when i change the frequency there for example to 122.805, the frequency on the A320 is 122.800. For a reason the last "5" digit is ignored. I contacted OpenCockpits regarding this and they think, that this is a communication error with FSUIPC. 

 

Maybe some of you know this issue and could help. 

Thanks a lot 

Jonas

[jonas_llubi]

I think it is related to: 

 

[John Dowson]

36 minutes ago, jonas_llubi said:

I have the plug-and-play version of the A320-Radio from OpenCockpits and i am using the "IOCModules" software to use it with MSFS2020. I have the problem that when i change the frequency there for example to 122.805, the frequency on the A320 is 122.800. For a reason the last "5" digit is ignored. I contacted OpenCockpits regarding this and they think, that this is a communication error with FSUIPC. 

What offset are you using for the COM frequency? For COM1, there are two offsets (for the active frequency):
   0x034E:  COM1 frequency, 4 digits in BCD format. A frequency of 123.45 is represented by 0x2345. The leading 1 is assumed.
   0x05C4: Active COM1 frequency in Hz (32 bit int)

For 8.33KHz frequencies, you need to use offset 0x05C4, not 0x034E (as that does not support 8.33KHz spacing). Check which offset you are using. You can also use FSUIPC's offset logging facilities to check what these offsets hold.
You can also check offset 0x0B47 which will tell you which frequency spacing mode is being used (25KHz or 8.33KHz).

There are similar offsets for COM2 and standby - see the Offset Status document for details

5 minutes ago, jonas_llubi said:

I think it is related to: 

Yes, the same issue - but that user was already using offset 0x05C4.

What A320 model are you using?  Check what frequency spacing mode is supported. In the Asobo A320, I see this:
     5469 Monitor IPC:034E (U16) = 0x1870
     5469 Monitor IPC:05C4 (U32) = 118705000
     5469 Monitor IPC:0B47 (U8) = 1

and in the FBW A320 (Development branch) this:
     185610 Monitor IPC:034E (U16) = 0x1870
     185625 Monitor IPC:05C4 (U32) = 118705000

And when I change to 122.805, this:
   450344 Monitor IPC:034E (U16) = 0x2280
   450344 Monitor IPC:05C4 (U32) = 122805000

So FSUIPC is holding the correct values for these aircraft.

Please check those offsets for your aircraft model. If they are holding the correct values, then you need to go back to OpenCockpits. If they are not holding the correct values, then maybe the aircraft isn't setting the COM ACTIVE FREQUENCY simvar correctly. You can either report this to the aircraft developer, or check to see if they use an lvar to hold the correct 8.33KHz spacing - if so, you can add this lvar to an offset and use that.

Cheers,

John

   

 

[jonas_llubi]

Hi @John Dowson

thanks a lot for your detailed informations. I will check that asap. I also think that FSUIPC stores the right data. How can I read the offset values in the logging? 
 

Thanks a lot! 
 

Jonas

[John Dowson]

4 minutes ago, jonas_llubi said:

How can I read the offset values in the logging? 

As I  said, using the facilities provided (Log->Offsets).

Please read the user manual!

John

[ark1320]

12 hours ago, John Dowson said:

You can also check offset 0x0B47 which will tell you which frequency spacing mode is being used (25KHz or 8.33KHz).

John, When and how are offsets 0x0B47 and 0x0B48 updated in order to indicate the current com frequency spacing? Is there a way to force those offsets to update? For example, GPS units often "contain" the Com radios, and you can select the number of frequency digits to be used. If after loading the plane you switch the number of frequency digits, do you have to manually update offsets 0x0B47 and 0x0B48?

Thanks,

Al

[John Dowson]

13 hours ago, ark1320 said:

When and how are offsets 0x0B47 and 0x0B48 updated in order to indicate the current com frequency spacing?

They do not indicate the current com frequency setting, they indicate if the avionics in the current aircraft support 8.33 or 25 KHz, and will be set when the aircraft is loaded.

John

[ark1320]

5 hours ago, John Dowson said:

They do not indicate the current com frequency setting, they indicate if the avionics in the current aircraft support 8.33 or 25 KHz, and will be set when the aircraft is loaded.

John

Yes, that's what I meant by the current com freq spacing  (channel spacing) --  8.33 or 25 KHz. 

Thanks,

Al

[Abt]

With MSFS 2024 the problem persists.
I wrote the fourth email to OpenCockpit to let them know, that their IOCModules, which drives the PnP-radios and the Multi-Radios, uses 034E and gives wrong values in the sim.
I also gave them the UL to this thread.
These radios are not usable for about at least two years, or I think never for 5KHz steps.

[jonas_llubi]

6 hours ago, Abt said:

With MSFS 2024 the problem persists.
I wrote the fourth email to OpenCockpit to let them know, that their IOCModules, which drives the PnP-radios and the Multi-Radios, uses 034E and gives wrong values in the sim.
I also gave them the UL to this thread.
These radios are not usable for about at least two years, or I think never for 5KHz steps.

Good evening @Abt,

(good) to hear that you have the exact same problems with the module. To be honest i'm very angry about the situation and i'm confused that the module is still on sale in the OpenCockpit-Store. Thats really nothing to deal with. On top of that its not possible to use the board with their software "SIOC" without a proper manual etc. 

I also wrote a lot of emails with no response from them. A year ago i got the response, that FSUIPC is the problem and that they are in contact with the owner of FSUIPC - that turned out to be a statement without background. 

Maybe there is a chance that we write a email together? 

 

Thanks a lot and have a great evening

 

Jonas

[Linguini]

Hi @jonas_llubi, @Abt. I share you frustration with this. In fact, I spent the last 6 hours vibe coding an AI-assisted solution for a SIOC script that correctly handles the COM1/2 active/standby frequencies for both 25kHz and 8.33kHz frequencies.

I also changed the logic so that it truly does work as a slave device, in that if MSFS changes the frequency itself (or another app like BATC etc does) then the updated frequency will appear in the panel, and it won't keep overriding MSFS.

Limitations:

• It's really nasty code, made with the assistance of AI. Works with MSFS2020, but not yet tested for MSFS 2024.
• The SIOC script also doesn't appear to work for the Nav radios. I based it off the originally provided SIOC scripts from opencockpits (I'm not sure if I can share it openly with you, but there is no copyright notice on the original), and that original script doesn't work for Nav radios in MSFS2020 either. For me, the COM 1/2 radios were much more important. I can revisit the NAV modes later perhaps.
• In testing, the display does sometimes go black, and the panel appears to fail. To fix it, you have to just press the "Reload" button in the SIOC utility. I changed the logic so that it always initialises with the active COM1/2 frequencies from MSFS so that it doesn't reset anything if you have to restart multiple times in the middle of a flight.

I hope it works as a stop-gap until something better comes along though!

Edit:

• The NAV VOR and ADF radios don't work, but the ILS mode frequency and course values do work!

If you're interested, let me know and I can send the script to you privately.

 

Linguini

 

Edited Monday at 04:35 PM by Linguini

[Linguini]

There's no copyright claim on the original script, so I've uploaded my version of it here... Original file courtesy of Manolo Velez.

You'll need to open this in the SIOC utility.
 

1. Open SIOC.exe
2. Choose "Edit Script"
3. Files -> Import TXT (and select this attached file)
4. Save As... (it'll compile as an .ssi file)
5. Once compiled you may need to click the "Reload" button in the man SIOC utility window.
6. All done! (hopefully)

I'm a novice when it comes to this stuff, so I'm afraid I can offer no support.

(See latest version below...)

Edited Tuesday at 04:24 PM by Linguini
removed older download

[jonas_llubi]

14 hours ago, Linguini said:

There's no copyright claim on the original script, so I've uploaded my version of it here... Original file courtesy of Manolo Velez.

You'll need to open this in the SIOC utility.
 

1. Open SIOC.exe
2. Choose "Edit Script"
3. Files -> Import TXT (and select this attached file)
4. Save As... (it'll compile as an .ssi file)
5. Once compiled you may need to click the "Reload" button in the man SIOC utility window.
6. All done! (hopefully)

I'm a novice when it comes to this stuff, so I'm afraid I can offer no support.

Radio_Airbus_RMP_slave_8.33.zip 7.12 kB · 1 download

Hi @Linguini,

thank you so much for sharing your results here with us! 🙂 

I will test it as soon as possible. I’m very excited because I didn’t become it to work. 
 

A huge thank you

Jonas

[Linguini]

Here's a modified version of the SIOC script (v1.1) where I've removed a bunch of debug code that was left in. I've not had SIOC crashes with this version (yet!)

Radio_Airbus_RMP_slave_8.33_v1.1.zip