ark1320 Posted September 10, 2020 Report Posted September 10, 2020 Are than any plans for FSUIPC7 to support the 25KHz Com spacing that many of the planes in MSFS2020 use? Thanks, Al
Pete Dowson Posted September 10, 2020 Report Posted September 10, 2020 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
ark1320 Posted September 10, 2020 Author Report Posted September 10, 2020 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
Pete Dowson Posted September 10, 2020 Report Posted September 10, 2020 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
ark1320 Posted September 10, 2020 Author Report Posted September 10, 2020 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
Pete Dowson Posted September 10, 2020 Report Posted September 10, 2020 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
John Dowson Posted September 10, 2020 Report Posted September 10, 2020 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.
John Dowson Posted September 10, 2020 Report Posted September 10, 2020 I'll check further if its possible to set via events/controls - I think I checked this previously but it wasn't working, but I'll check again. If not working, I will report to Asobo on this issue.
John Dowson Posted September 16, 2020 Report Posted September 16, 2020 (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 September 17, 2020 by John Dowson BCD with 4 digits not 5
ark1320 Posted September 16, 2020 Author Report Posted September 16, 2020 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
John Dowson Posted September 16, 2020 Report Posted September 16, 2020 (edited) No, you need the 1 - that's why it's 5 BCD digits rather than 4. Later: not correct. its BCD with 4 digits, leading 1 removed. Edited September 17, 2020 by John Dowson corrected
ark1320 Posted September 16, 2020 Author Report Posted September 16, 2020 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
John Dowson Posted September 16, 2020 Report Posted September 16, 2020 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.
ark1320 Posted September 17, 2020 Author Report Posted September 17, 2020 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
John Dowson Posted September 17, 2020 Report Posted September 17, 2020 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
ark1320 Posted September 17, 2020 Author Report Posted September 17, 2020 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
KalleKanin Posted September 25, 2020 Report Posted September 25, 2020 (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 September 25, 2020 by KalleKanin
John Dowson Posted September 25, 2020 Report Posted September 25, 2020 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
KalleKanin Posted September 25, 2020 Report Posted September 25, 2020 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!
klarson18 Posted March 14, 2021 Report Posted March 14, 2021 Has there been any recent updates to this? Has the 8.33khz become available yet?
John Dowson Posted March 15, 2021 Report Posted March 15, 2021 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.
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now