hello I use the Goflight MCPPro when I activate fscrew flashing allle LED`s on MCPPro which does not bother so much. But if I issue the command set heading XXX or set IAS XXX during the flight, the settings will run in an infinite loop. You can not stop that. I also have the problem that V1, Acceleration Heigh and QNH are announced too early or completely wrong (QNH).
LUA is set to YES in the CFG.
These problems only occur with the Dash 8, but I do not have the problems with PMDG or Maddog X.
thanks for your help
Klaus

Edited July 17, 20187 yr by kdt

I had a similar problem with the "Set course" command, he just kept spinning it around forever, until I told him to "Cancel Last Command".  Same issue with altitude. I did not have LINDA set to YES though, will try with that and see if it makes a difference.  (I'm not using LINDA, but I am using some custom LUA scripts in FSUIPC and Spad.next). Additional problems I discovered were repeated calls of "1000 to go alt sel", V1 was called out at 50 kts (even though it was set to 117), and acceleration altitude was called almost immediately after takeoff even though correctly set to 1500 ft in my case, and multiple calls of "We're picking up some ice" but no ice warning and it was at low altitude at 30 degrees centigrade. 😕

Edited July 17, 20187 yr by DeCaf

the problem with "1000 to go Alt Sel" is solved in my opinion with the activation of LUA YES in the config.

Okay, so I tested with LINDA set to YES in the configuration. This "solved" two problems, namely that "1000 to go, ALT SEL" was no longer called (at all, even when it should be), nor the "Ice detected" callout. It also removed the callout for "Rotate" for some reason, however the V1 call was still there and at about 50 kts.

So the problems I'm having so far, with LINDA selected to YES are:

1. I cannot get the FO to start the engines if I use GSX for push-back. (This is documented I guess, but would be desierable)
2. V1 call occurs at the wrong time, seems to be around 50 kts (before the 80 kts call)
3. There is no call for "VR"
4. The call for Acceleration height occurs way too early (before "positive rate" last time if I recall correctly).
5. On one flight I never got the "positive rate" call, and then the FO does not respond to "Gear up".
6. I just cannot get the FO to recognize any call for the after takeoff flow, i.e. the very long sentence "Flaps 0, IAS 210, Climb Checklist To the line". I have even trained speech recognition for this particular phrase for about 45 minutes, so I can dictate  it fine, but for some reason FS2Crew interprets this as gibberish.  Perhaps it would be nice if I could give each of these commands separately?  "Set and Checked" "works" in a sense, but gives me IAS 160, which I guess I can live with.  (Saying "Set and checked again" makes the FO perform the same after takeoff flows again by the way).
7. Asking the FO to set IAS, heading, altitude or course results in an infinite loop of increasing (or decreasing) these values until I say "Cancel last command" and set it myself.

So in its present state I really can't use this product, considering it actually just increases my workload.  Is there any solution to these problems? 

As a side note I also have FS2Crew for PMDG 737NGX  and PMDG 777, and these works flawlessly.  Not sure why I'm having such problems with the Dash-8.

Edited July 17, 20187 yr by DeCaf

Okay, I did some investigation here. It seems that Spad.Next and in particular the Q400 module is the culprit here. 

I can run Spad.next without the Q400 module and then all issues above except for number 6 in the previous post are resolved. (it is still almost impossible to get the FO to recognize the "Flaps 0, IAS 210, Climb checklist to the line" for some reason. (I have no problems with any other commands).

So I guess there is a conflict between the Spad.next Q400 module and FS2Crew somehow, which is a real bummer. Personally I only have the radio panel, so I guess I will have to try and figure out if there is another way to set the frequencies on that except for via the Q400 module. Perhaps you guys who wrote FS2Crew have some insight there since you can ask the FO to set radio frequencies? Are they available via FSUIPC offsets or LVARS or something?

 

Edited July 17, 20187 yr by DeCaf

The problem is LINDA.

Linda interferes with FS2Crew.

There's a LINDA config option in FS2Crew.  Set it to Yes to mitigate some of the interference.

Cheers,

50 minutes ago, byork said:

The problem is LINDA.

Linda interferes with FS2Crew.

There's a LINDA config option in FS2Crew.  Set it to Yes to mitigate some of the interference.

Cheers,

As I mentioned, I don't use LINDA, and in my case turning off the Q400 module in Spad.next made everything work as it should (almost anyway), so in my case it is that module that interferes with FS2Crew. 

I'm working on finding a solution in Spad.next that doesn't use the Q400 module (but just uses normal LVAR's, and it's looking like it should be possible to replicate most if not all of the functionality for the Saitek radio panel anyway.

(And the LINDA option in FS2Crew didn't really solve anything for me except for silencing some callouts)

Edited July 18, 20187 yr by DeCaf

I still have LINDA CFG on YES and still have the problems mentioned above.
and i don´t use LINDA.
Greeting
Klaus

Edited July 18, 20187 yr by kdt

2 hours ago, kdt said:

I still have LINDA CFG on YES and still have the problems mentioned above.
and i don´t use LINDA.
Greeting
Klaus

Are you using Spad.next?

This problem appears to be really old as well. Found a post in Spad.next forums that seems to mention this from three years ago:
https://www.spadnext.com/forum/viewtopic.php?f=20&t=4157&p=43663#p43663

It suggests that perhaps FS2Crew doesn't wait for acknowledgement of commands which might interfere with the Q400 external event interface?  Is this something that could be the culprit?  

The Q400 external XML interface documentation states a procedure of waiting for acknowledgement after writing to/reading from the various XML variables, is this being adhered to by FS2Crew?

 

Hallo DeCaf, i don' t use spad.next.

Klaus

2 hours ago, kdt said:

Hallo DeCaf, i don' t use spad.next.

Klaus

So no LINDA, and no Spad.Next.  I'm guessing there is some other application controlling the MCPPro then? It seems every other application interferes with the operation of FS2Crew? Could it be that there is something in FS2Crew that is causing these problems that could be looked at?

So the only possible one would be the GoFlight Interface Tool. But in the matter I do not know myself.
But I'm typing on fscrew because as I mentioned above, the problem with PMDG and Maddog X does not occur.

Each FS2Crew is different, and it interfaces with each aircraft differently because each host aircraft is different.

In the case of the Maddog itself, there's an issue with some external hardware setups causing a conflict with parts of the program.

That's why we have the LINDA option for hardware that uses LINDA.  Spad next is something I'm not familiar with.

PMDG, Maddog are totally different, and that's why they don't have this issue.

 

 

But since we now have at least three other tools with which FS2Crew doesn't work it seems (Linda, GOFlight and Spad.next), wouldn't you consider investigating if there is something you can do in the FS2Crew implementation to remedy this?