Comm Power Circuits in Black Square Products
-
What's actually showing in the COM entries at the top of the SayIntentions window when you're in the powered-down PMDG? COM1 is a greyed out frequency number? Or it says OFF instead of a frequency?
-
(It's a separate topic from circuit power, but the COM RECEIVE:1 variable always shows as true/1 even when a zero is sent to COM1_RECEIVE_SELECT, unlike COM RECEIVE:2 which works like you'd expect with sending 1 or 0 to COM2_RECEIVE_SELECT.
SayIntentions appears to be reading COM RECEIVE:1 (and presumably COM RECEIVE:2), since it recognizes turning off COM2 receive but always shows COM1 receive as on even when it's off, in e.g. the Starship. (There are newer (I assume, because of the EX naming) variables called COM RECEIVE EX1:1 and COM RECEIVE EX1:2 which actually do work as expected and COM RECEIVE EX1:1 turns on and off depending on sending 1 or 0 to COM1_RECEIVE_SELECT. But SI doesn't seem to be looking at that currently.)) -
What's actually showing in the COM entries at the top of the SayIntentions window when you're in the powered-down PMDG? COM1 is a greyed out frequency number? Or it says OFF instead of a frequency?
@Magenta-Line said in Comm Power Circuits in Black Square Products:
What's actually showing in the COM entries at the top of the SayIntentions window when you're in the powered-down PMDG? COM1 is a greyed out frequency number? Or it says OFF instead of a frequency?
Both comm frequencies are shown. Com 1 is in green and Com 2 is in grey, however I cannot hear Com 1 (or Com 2) until the volume knob is depressed on the radio panel. Perhaps it is doing it via volume manipulation instead of turning it "off" since when the knob is depressed, with the advanced settings on I can also change the volume by rotating the knob.
I see similar behavior with vPilot in that the active TX frequency is always marked RX as well (but did not have a controller nearby to test whether I could hear anything).
-
Just adding my two cents: I’ve noticed that the SI app is forcing COM1 RECEIVE to stay ON. For example, if I switch to COM3 RECEIVE ON / COM3 MIC ON and manually turn COM1 RECEIVE OFF, after a few seconds the SI app turns COM1 RECEIVE back on again.
If I close the SI app, this behavior stops completely and only COM3 RECEIVE/MIC remains ON. So it does seem the issue is coming from the SI app after all.
-
@jmarkows said in Comm Power Circuits in Black Square Products:
Perhaps it is doing it via volume manipulation
Ah if they set the starting volume to 0, then that'd work since that aspect is working in SI. But unless the volume gets set back to 0 when you turn the power to the radio off, SI will keep talking after you've shut down the plane. Also means SI will ignore electrical failures.
I went and tested BeyondATC a bit more. It does monitor CIRCUIT COM ON (both 1 and 2, independently): anything that breaks that (e.g. pulling a circuit breaker) will silence that radio, so that's good...but...it turns out BATC has the opposite problem from SI: it doesn't monitor the receive settings at all, whereas SI at least understands COM2 receive being off.
Of course BATC is weird regarding COM2 anyway, because it only lets you use it for ATIS/ASOS/AWOS. If you have COM2 on something other than a weather reporting frequency, it treats COM2 as off. -
Just adding my two cents: I’ve noticed that the SI app is forcing COM1 RECEIVE to stay ON. For example, if I switch to COM3 RECEIVE ON / COM3 MIC ON and manually turn COM1 RECEIVE OFF, after a few seconds the SI app turns COM1 RECEIVE back on again.
If I close the SI app, this behavior stops completely and only COM3 RECEIVE/MIC remains ON. So it does seem the issue is coming from the SI app after all.
@hangar_101 said in Comm Power Circuits in Black Square Products:
if I switch to COM3 RECEIVE ON / COM3 MIC ON and manually turn COM1 RECEIVE OFF, after a few seconds the SI app turns COM1 RECEIVE back on again.
Now that I haven't seen.
Although in the process of trying to replicate it, I found something interesting. if you turn both comm1 and comm2 receive off in the Starship, SI will show as active (green) only whichever radio is selected as the transmitter. So setting transmit to comm2 causes SI to show COM1's frequency in grey.
Looking at COM RECEIVE:1 and COM RECEIVE:2 in Simvar Watcher, sure enough, they're set to 1 if that radio is set to transmit, regardless of whether it's set to receive. So my understanding about COM RECEIVE:1 and COM RECEIVE:2 being different was incorrect; it's the transmit selection that's causing it.But there doesn't seem to be an MSFS function to set transmit to com3?EDIT: Alright I see now, if you send the control PILOT_TRANSMITTER_SET with a value of 2 (0 = com1, 1 = com2, so 2 is presumably com3) then SI briefly shows both com1 and com2 freqs greyed out (which made me happy for a few seconds) before automatically switching com1 receive on (though not com1 transmit). What in the world?
-
@hangar_101 said in Comm Power Circuits in Black Square Products:
if I switch to COM3 RECEIVE ON / COM3 MIC ON and manually turn COM1 RECEIVE OFF, after a few seconds the SI app turns COM1 RECEIVE back on again.
Now that I haven't seen.
Although in the process of trying to replicate it, I found something interesting. if you turn both comm1 and comm2 receive off in the Starship, SI will show as active (green) only whichever radio is selected as the transmitter. So setting transmit to comm2 causes SI to show COM1's frequency in grey.
Looking at COM RECEIVE:1 and COM RECEIVE:2 in Simvar Watcher, sure enough, they're set to 1 if that radio is set to transmit, regardless of whether it's set to receive. So my understanding about COM RECEIVE:1 and COM RECEIVE:2 being different was incorrect; it's the transmit selection that's causing it.But there doesn't seem to be an MSFS function to set transmit to com3?EDIT: Alright I see now, if you send the control PILOT_TRANSMITTER_SET with a value of 2 (0 = com1, 1 = com2, so 2 is presumably com3) then SI briefly shows both com1 and com2 freqs greyed out (which made me happy for a few seconds) before automatically switching com1 receive on (though not com1 transmit). What in the world?
@Magenta-Line I’ve opened a ticket with SI explaining the situation. Let’s see what they come back with.
-
I made a Lua script for FSUIPC7 that sets the active frequency to a dummy frequency when COM CIRCUIT ON is off, and restores it to the previous frequency when COM CIRCUIT ON is on, for COM1 and COM2 separately. (Initially I tried using SI's start/stop ATC keybind, muting the whole SI app, changing COM volumes, and changing COM receive selection, but changing the frequency worked out the best.)
Requires the payware version of FSUIPC7 to run.
com1_power_offset = 0x66DE -- A:CIRCUIT COM ON:1 com2_power_offset = 0x66DF -- A:CIRCUIT COM ON:2 com_active_hz = {} com_active_hz[com1_power_offset] = 0x05C4 com_active_hz[com2_power_offset] = 0x05C8 RADIO_SET_HZ = {} RADIO_SET_HZ[com1_power_offset] = 67240 RADIO_SET_HZ[com2_power_offset] = 67242 stored_frequency = {} stored_frequency[com1_power_offset] = nil stored_frequency[com2_power_offset] = nil dummy_frequency = 111000000 function check(power_offset,power_status) if power_status == 0 then stored_frequency[power_offset] = ipc.readUD(com_active_hz[power_offset]) ipc.control(RADIO_SET_HZ[power_offset],dummy_frequency) else if stored_frequency[power_offset] then --script is meant to be run before radios are first turned on, but check just in case ipc.control(RADIO_SET_HZ[power_offset],stored_frequency[power_offset]) end end end event.offset(com1_power_offset,"UB","check") event.offset(com2_power_offset,"UB","check") -
I opened a ticket with SI on this also.
For me, it wasn't doing this a couple weeks or so ago and doesn't do it when the SI app is closed.
Must be they are turning com1 back on in MSFS due to tickets with people that don't know how it works.X-Plane 12 works perfectly, I can switch mics and turn off radio receivers without the com1 receiver coming back on after a few seconds with the SI app connected.
