Jump to content
The simFlight Network Forums

Recommended Posts

Posted

That's the standard older spacing and is supported ok I think (will check the offsets later today as I need them for my Upper cockpit).

.  The newer spacing is 8.33 isn't it? None of my hardware radios support that, but there are separate offsets for those which I will check too.

Pete

 

Posted
6 hours ago, Pete Dowson said:

That's the standard older spacing and is supported ok I think (will check the offsets later today as I need them for my Upper cockpit).

.  The newer spacing is 8.33 isn't it? None of my hardware radios support that, but there are separate offsets for those which I will check too.

Pete

 

Yes, the newest spacing is 8.33KHz and is mainly used in Europe. 

I see in FSUIPC6 for P3D4/5 there are now offsets 0C54 to 0CD0 for COMS 1/2 which are simply described as 32 bit integers. So maybe for a frequency like 123.245 MHz you can simply write the six digit number without the decimal point. I will experiment with that. In the past I have used offsets like 034E which apparently will only accept 4 digits in BCD format.

Thx,

Al

Posted
50 minutes ago, ark1320 said:

I see in FSUIPC6 for P3D4/5 there are now offsets 0C54 to 0CD0 for COMS 1/2 which are simply described as 32 bit integers. So maybe for a frequency like 123.245 MHz you can simply write the six digit number without the decimal point.

I think you mean offsets 05C4 to 05D0, which are documented clearly to be in hz, so 123.245 would be 123245000.

BTW it looks like MSFS can be switched between 25khz and 8.33 modes, but possibly that depends on the aircraft and the radios fitted.

Pete

 

Posted
18 minutes ago, Pete Dowson said:

I think you mean offsets 05C4 to 05D0, which are documented clearly to be in hz, so 123.245 would be 123245000.

BTW it looks like MSFS can be switched between 25khz and 8.33 modes, but possibly that depends on the aircraft and the radios fitted.

Pete

 

Yes, saw my mistakes just before your post came in. I tried ipc.writeUD(0x05CC, 123245000) for standby COM1 with the C152 in MSFS but it didn't work -- Simconnect or MSFS bug I assume.

Thanks,

Al

Posted
27 minutes ago, ark1320 said:

Yes, saw my mistakes just before your post came in. I tried ipc.writeUD(0x05CC, 123245000) for standby COM1 with the C152 in MSFS but it didn't work -- Simconnect or MSFS bug I assume.

Try setting the active instead. I've not had a chance to try them all yet.

The active BCD16 values work okay with my VFR cockpit so possibly that aircraft is set for 25khz spacing. My hardware only has older radios.

Pete

 

Posted
52 minutes ago, ark1320 said:

Yes, saw my mistakes just before your post came in. I tried ipc.writeUD(0x05CC, 123245000) for standby COM1 with the C152 in MSFS but it didn't work -- Simconnect or MSFS bug I assume.

Offsets 0x05C4, 0x05C8, 0x05CC & 0x05D0  are no longer writeable. in MSFS, so for read only. Its not a bug unfortunately, but stated as read-only in the SDK documentation. The FUIPC7 offset status documentation documents these in red for writeable, i.e. not working.

Posted (edited)

The COM_RADIO_SET and COM2_RADIO_SET controls only accept BCD with 4 digits, so it doesn't seem possible to directly set 8.33kHz spaced frequencies via simconnect at the moment. I'll report to Asobo.

There are new sim variables which give the frequency spacing used. I have added these at offsets 0x0B47 (COM1) and 0x0B48 (COM2) - available in the next build update/release. These are also settable. 0 indicates 25kHz spacing, and 1 8.33kHz spacing.

Edited by John Dowson
BCD with 4 digits not 5
Posted
4 hours ago, John Dowson said:

The COM_RADIO_SET and COM2_RADIO_SET controls only accept BCD with 5 digits, so it doesn't seem possible to directly set 8.33kHz spaced frequencies via simconnect at the moment. I'll report to Asobo.

John,

I assume the  COM_RADIO_SET 5 BCD digits for 25KHz spacing will not include the frequency's leading 1 digit (so the same idea as currently for the 4 BCD digit NAV frequency case) -- correct?

Thx,

Al 

Posted
30 minutes ago, John Dowson said:

No, you need the 1 - that's why it's 5 BCD digits rather than 4.

In that case I don't see how you can specify a 25 Khz spaced com freq like 123.475.  For 25KHz spacing the 6th digit can either be 0 or 5 unless I'm not understanding something (00, 25, 50, or 75 for the last two digits). Seems you need to specify 6 digits total for 25Khz spacing.

Al

Posted
6 hours ago, John Dowson said:

Ah, sorry - there's also COM1/2 Radio Hz Set, which uses a 4 byte integer. That's what the offsets actually use. I'll do some more tests.

Hi John, no problem, I appreciate all the hard work on FSUIPC7! 

I've tried those COM1/2 Radio Set events without any luck so far.

BTW, is there any difference from a Simconnect or sim point of view between using an offset for COM STBY RADIO SET like ipc.writeUD(0x05CC, 123455000), and using a control event like ipc.control( 66371, 123455000) , or are these two instructions processed identically by the 'system'?

Thanks,

Al

Posted
6 hours ago, ark1320 said:

I've tried those COM1/2 Radio Set events without any luck so far.

These events work, with BCD16 format (2 bytes), with the leading 1 removed. These are the same controls used by offsets 0x034E (COM1) and 0x3118 (COM2). With BCD16 format, you can set 25kHz spaced frequencies but not 8.33kHz spaced ones. For 25kHx frequencies, you don't need the 5 digit (or 3rd dp), as, for example, setting this to 0x1802 would set the frequency to 118.025, as can be seen by reading offset 0x05C4.

The 8.33kHz spaced frequencies were previously settable via the 32bit int offsets (e.g. 0x05C4 for COM1 active, etc). These used additional controls (e.g.  COM1 Radio Hz Set) imported from the guages that no longer exist in MSFS. It therefore does not seem possible to directly set 8.33kHz spaced frequencies at the moment. I will raise this with Asobo.

6 hours ago, ark1320 said:

BTW, is there any difference from a Simconnect or sim point of view between using an offset for COM STBY RADIO SET like ipc.writeUD(0x05CC, 123455000), and using a control event like ipc.control( 66371, 123455000) , or are these two instructions processed identically by the 'system'?

Writing to an offset either triggers a control or can update a sim variable, depending upon the offset (and is distinguished by Ok-SimC and Ok-SimE in the offset documentation). Using lua, sending the control directly rather than going via offsets would be slightly faster as it sends the control directly and by-passes the offset monitoring, but they would result in the same action (i.e. control being sent) when that offset uses events/controls to update.

John

Posted
5 hours ago, John Dowson said:

These events work, with BCD16 format (2 bytes), with the leading 1 removed. These are the same controls used by offsets 0x034E (COM1) and 0x3118 (COM2). With BCD16 format, you can set 25kHz spaced frequencies but not 8.33kHz spaced ones. For 25kHx frequencies, you don't need the 5 digit (or 3rd dp), as, for example, setting this to 0x1802 would set the frequency to 118.025, as can be seen by reading offset 0x05C4.

Ah, I see now. Assuming 25KHz spacing, the frequency's 2nd decimal place digit determines what the 3rd decimal place digit HAS to be -- clever!

Thanks,

Al

Posted (edited)

Could it be an idea to have two sets with attributes: One read-only with all decimals (3?), and one read-and-write with the limited number of decimals (2?)?


Off-topic:
Anyone that have an issue inside MSFS with COM1-increments? I use COM1 with carry over, and it is incrementing between 5 or 15kHz.... and also both increment and decrement increases the values!
(But this has nothing to do with FSUIPC, and I guess this is a MSFS-issue as I do the increments/decrements using joystick-mappings for this)

Edited by KalleKanin
Posted
3 hours ago, KalleKanin said:

Could it be an idea to have two sets with attributes: One read-only with all decimals (3?), and one read-and-write with the limited number of decimals (2?)?

Thats not up to us. We use what is provided by the SDK. Currently they only provide 2 byte BCD format (4 digits), which is enough for 25KHz spacing, Its the 4byte 32 bit integers (in Hertz) that are currently not available, which is the issue.

3 hours ago, KalleKanin said:

Anyone that have an issue inside MSFS with COM1-increments? I use COM1 with carry over, and it is incrementing between 5 or 15kHz.... and also both increment and decrement increases the values!

This is a know issue and has been reported to Asobo - please see 

The increment value depends on the frequency and frequency spacing.

John

 

Posted
4 hours ago, John Dowson said:

Thats not up to us. We use what is provided by the SDK. Currently they only provide 2 byte BCD format (4 digits), which is enough for 25KHz spacing, Its the 4byte 32 bit integers (in Hertz) that are currently not available, which is the issue.

This is a know issue and has been reported to Asobo - please see 

The increment value depends on the frequency and frequency spacing.

John

 

Ah, thanks for the clarification and tip about the bug!

Keep up the good work!
Looking forward to buy the official version!

  • 5 months later...
Posted
17 hours ago, klarson18 said:

Has the 8.33khz become available yet?

This has been available for a while, using the Com Radio Set Hz (+ equivalent for COM2 and COM3 + standby), and also via offsets 0x05C4, 0x05C8, 0x05CC & 0x05D0.
There  are also offsets 0x0B47 and 0x0B48 for the com1/2 spacing mode.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.