ADF - Always No Signal

I am trying to implement a custom coded ADF solution for our Dash 7, this to be more specific:

While the frequency selection part appears to work correctly, the Behaviours debug is showing a constant 0 for ADF SIGNAL:1, I have no idea why.

The ADF ANT switch that you can see on the above screenshot uses the following code:

<Component ID="DHC7_ADF_Switch_ADF_ANT_1" Node="ADF_Switch_ADF_ANT_1_Pilot">
<UseTemplate Name="ASOBO_GT_Switch_Code">
<ANIM_NAME>ADF_Switch_ADF_ANT_1_Pilot</ANIM_NAME>
<ANIM_CODE>(L:ADF_Switch_ADF_ANT_1_Pilot, Bool) 100 *</ANIM_CODE>
<LEFT_SINGLE_CODE>(L:ADF_Switch_ADF_ANT_1_Pilot, Bool) ! (&gt;L:ADF_Switch_ADF_ANT_1_Pilot, Bool)</LEFT_SINGLE_CODE>
</UseTemplate>
<UseTemplate Name="ASOBO_GT_Update">
<FREQUENCY>4</FREQUENCY>
<UPDATE_CODE>
(L:ADF_Switch_ADF_ANT_1_Pilot, Bool) (&gt;B:NAVCOM_ADF_Mode_ADF)
</UPDATE_CODE>
</UseTemplate>			
</Component>

The switch moves and my assumption is that the value of L:ADF_Switch_ADF_ANT_1_Pilot is getting passed on to B:NAVCOM_ADF_Mode_ADF.

I could not find anything in the SDK for setting ADF and BFO, I assume that using B:NAVCOM_ADF_Mode_ADF and B:NAVCOM_ADF_Mode_BFO is the correct way of setting these. I’ve seen that the default ASOBO ADF templates mostly use B:NAVCOM_ADF_ADF_ANT_MODE_TOGGLE_Push and I assume this is due to the fact that they are geared towards a push button rather than a switch.

I’ve also noticed that some of the default aircraft, such as the Cessna 152 and Cessna 172 Classic are using B:NAVCOM_ADF_Mode_ADF and B:NAVCOM_ADF_ADF_ANT_MODE_TOGGLE_Push, yet this seems to make absolutely no difference, the ADF signal seems to always be captured, regardless of ANT or ADF mode being active. So either these switches are purely cosmetic, or there is a bug in the ADF implementation.

Could you please confirm the correct methodology we should be using for this type of ADF switch?

Jerome

@FlyingRaccoon

Sylvain could you kindly assist with this please.

Thanks and regards,

Jerome

Hello @PILOTSdev

I had a quick look at your package and it seems the problem comes from your frequency update code:

<UseTemplate Name="ASOBO_GT_Update">
	<FREQUENCY>4</FREQUENCY>
	<UPDATE_CODE>
		(L:ADF_1_Frequency_100KHz, Number) 100 * (L:ADF_1_Frequency_10KHz, Number) 10 * (L:ADF_1_Frequency_1KHz, Number) + + (&gt;L:ADF_ACTIVE_FREQUENCY_1, kHz)
					
		(L:ADF_ACTIVE_FREQUENCY_1, kHz) (A:ADF ACTIVE FREQUENCY:1, Khz) != and if{
		    (L:ADF_ACTIVE_FREQUENCY_1, Frequency ADF BCD32) (&gt;K:ADF_ACTIVE_SET)
		} 
	</UPDATE_CODE>
</UseTemplate>

The K event is never sent when using your knobs.
I would suspect the “and” in your if test is not needed?

Let me know if that solves your problem.

Regards,
Sylvain

@FlyingRaccoon

Good evening Sylvain,

Unfortunately that also does not solve the problem, the ADF is still totally INOP. You are quite right though that the “and” is not needed, and I have removed it, but the ADF still won’t work, the ADF1 needle is showing absolutely no movement for NDB frequency 328 at LESO.

Could it be that there is a bug with K:ADF_ACTIVE_SET and it doesn’t actually work? Most of the ADF templates seem to use an HTML event that swaps between the active and standby frequency, I have not come across any template in the SDK that actually makes use of K:ADF_ACTIVE_SET.

I just tried a new test, I changed the above code to:

<UseTemplate Name="ASOBO_GT_Update">
	<FREQUENCY>4</FREQUENCY>
	<UPDATE_CODE>
		(L:ADF_1_Frequency_100KHz, Number) 100 * (L:ADF_1_Frequency_10KHz, Number) 10 * (L:ADF_1_Frequency_1KHz, Number) + + (&gt;L:ADF_ACTIVE_FREQUENCY_1, kHz)
	</UPDATE_CODE>
</UseTemplate>

After that I created a test code for the ADF | ANT switch :

<Component ID="DHC7_ADF_Switch_ADF_ANT_1_Pilot" Node="ADF_Switch_ADF_ANT_1_Pilot">
<UseTemplate Name="ASOBO_GT_Switch_Code">
<ANIM_NAME>ADF_Switch_ADF_ANT_1_Pilot</ANIM_NAME>
<ANIM_CODE>(L:ADF_Switch_ADF_ANT_1_Pilot, Bool) 100 *</ANIM_CODE>
<LEFT_SINGLE_CODE>(L:ADF_Switch_ADF_ANT_1_Pilot, Bool) ! (&gt;L:ADF_Switch_ADF_ANT_1_Pilot, Bool)</LEFT_SINGLE_CODE>
</UseTemplate>
<UseTemplate Name="ASOBO_GT_Update">
<FREQUENCY>4</FREQUENCY>
<UPDATE_CODE>
(L:ADF_Switch_ADF_ANT_1_Pilot, Bool) if{ (L:ADF_ACTIVE_FREQUENCY_1, Frequency ADF BCD32) (&gt;K:ADF_ACTIVE_SET) } els{ 444 (&gt;K:ADF_ACTIVE_SET) }
</UPDATE_CODE>
</UseTemplate>			
</Component>

Here also absolutely nothing happens, the ADF1 needle never moves.

As a further check, I also mapped A:ADF ACTIVE FREQUENCY to L:CHECK_ADF_ACTIVE_FREQUENCY1 using the code below:

<Component ID="DHC7_CHECK_ACTIVE_ADF_FRQ1">
<UseTemplate Name="ASOBO_GT_Update">
<FREQUENCY>60</FREQUENCY>
<UPDATE_CODE>
(A:ADF ACTIVE FREQUENCY:1, KHz) (>L:CHECK_ADF_ACTIVE_FREQUENCY1, KHz)
</UPDATE_CODE>
</UseTemplate>
</Component>

It shows the frequency as 328 if I use the dials to change it to that, but the ADF1 needle always remains still.

Is there a minimum power requirement for the ADF to work? I just can’t think of what is causing this issue, it’s all very strange.

Best regards,

Jerome

Hello @PILOTSdev

After removing the “and”, I originally tested it at PADU with frequency set to 283.
I was able to hear the morse code and the needle moved, although not necessarily showing the correct azimuth.

I just checked it at LESO, frequency 328 and I have both the morse code and the needle moving:

Does the NDB shows on the world map with the correct frequency?
Also double check the simvars with SimvarWatcher to confirm the correct frequency is used and the NDB ident is correctly read.

Regards,
Sylvain

ON an ADF related issue, it seems that the short/medium range of an ADF, wrt Altitude, is not modeled even closely to that of Real World.

ie Sitting on the ground at KDCA, one should be able to pick up the DCA NDB that is only a few miles away, but in MSFS, this does not happen till one has taken off, and gained a few hundred feet in altitude.

While I admit, I have not tried this myself in RL, I would be most surprised if this was not the case for propagation at such a short range, for these NDB 100’s of kHz frequencies. (ie DCA = 332 kHz)

A little further testing in MSFS, indicates, that while the ADF signal strength does vary by Range, it variation by relative altitude seems to be either on or off, as even at close range, when the signal strength is high, as the Plane altitude lowers to that of the NDB, with a high signal strength, the signal strength is suddenly set to zero, which is a very crude, and inaccurate simulation of what should really be happening.

ie One should be able to get a relatively strong signal strength, from the DCA NDB, when sitting at the ground at KDCA and hence a valid ADF needle deflection.

Maybe a crude approximation, inherited from FSX, but probably not in keeping with what is expected and seen with the simulation accuracy of MSFS.in most other areas of the sim.

@FlyingRaccoon

Hi again Sylvain,

Thanks for your help and I am happy to see the ADF actually seems to work for you. Unfortunately on my PC and on another test PC installation, unrelated to my location and with a different username too, it is just not working at all, I have no idea why.

PADU using SimvarWatcher:

LESO using SimvarWatcher:

To make sure there is no outside interference my Community folder is completely empty apart from the Dash 7.

As you can see, I get absolutely no ADF signal at both PADU and LESO.

I thought that maybe the navigation data on my PC could be corrupt, but if I use the default Cessna 172 at both PADU and LESO, the ADF works without any issue.

How is it possible that the ADF is completely functional on your PC and completely non-functional on 2 other PCs?

Is there anything else you could think of for me to check?

Best regards,

Jerome

Hello @PILOTSdev

Can you check on the SU14 flighting version?

There has been a fix on SU14 addressing the fact ADF needed a CIRCUIT_MARKER_BEACON circuit to be powered for the ADF to work properly.
It would just switch ON/OFF otherwise.

I checked on SU13 and this happens on your aircraft.
So you can check it’s working properly on the SU14 flighting version and you can also add a CIRCUIT_MARKER_BEACON circuit to your aircraft for it to work on SU13.

Let me know if that solves the problem.

Regards,
Sylvain

@FlyingRaccoon

Hallelujah!

That was it and finally brought the ADF to life, it’s now working as intended after I added that circuit!

Sylvain, thank you very much for your help in resolving this issue!

Should that CIRCUIT_MARKER_BEACON circuit be removed after SU14 is officially released, or can it be left without any weird side effects?

Best regards,

Jerome

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.