PMDG_NGX_SDK.h and FSUIPC offsets

[shorthauler]

Dear Community,

I am trying to rewrite an EPIC script that works for the standard FSX planes, sending offsets to control various values. My script is sending the values itself. It does not simply send increments ("turning the knobs").

Looking at the PMDG_NGX_SDK.h, my impression is that the events only "turn knobs", but I have not found events to send values. Only the offsets in the section "MCP direct control seem to send direct values. Is this correct?

I am looking for a way to send NAV and COMM radio frequencies to the NGX.

Best,

Holger

[Pete Dowson]

9 minutes ago, shorthauler said:

Looking at the PMDG_NGX_SDK.h, my impression is that the events only "turn knobs", but I have not found events to send values. Only the offsets in the section "MCP direct control seem to send direct values. Is this correct?

Sorry, I don't actually have the PMDG aircraft and I don't know the SDK at all except that I mapped the read-out data to offsets. You really need PMDG support.

10 minutes ago, shorthauler said:

I am looking for a way to send NAV and COMM radio frequencies to the NGX.

I'm pretty sure the default radio controls will work. I don't know any add-on aircraft which implements radios separate from those built in -- all sorts of things like ATC, on-line flights, etc, wouldn't work if the radios weren't the ones simulated in FS. PMDG just build the graphics round them in the gauges.

Pete

 

[shorthauler]

Thanks, I have opened a thread there:

http://www.avsim.com/topic/499158-pmdg-ngx-sdkh-and-fsuipc-offsets/

Thanks also for the detail about the radios. The NGX radios are a bit peculiar insofar as it is always the same interface, but you have to chose which radio is being set:

http://www.b737.org.uk/communications.htm

This is why I suspected that with the offsets you can only turn the knob but not set a specific frequency directly, but let's see about the answers.

 

Best,

Holger

[ckovoor]

Dear Holger,

I fly the PMDG B738 NGX and have constructed my own hardware MCP+EFIS for it. I recently also constructed my own hardware Universal Radio Panel and am able to use it with the NGX without any modification. My hardware is based on Arduino Megas.

Here is a screenshot of the B738 NGX radio panels in flight:

And here is my radio panel which I am using to emulate it:

As far as the NGX is concerned, absolutely no modification was necessary to my hardware/software to manipulate the COM and NAV frequencies, ACTIVE and STANDBY. As Pete surmised, all the default radio controls do in fact work with this airplane, and I was able to manage the frequencies entirely with the standard FSX/FSUIPC offsets and controls. (There is a problem with ADF2 and both ADF STANDBY frequencies, however, in that I have not been able to find where PMDG stores those.)

On 12/6/2016 at 4:53 PM, shorthauler said:

The NGX radios are a bit peculiar insofar as it is always the same interface, but you have to chose which radio is being set:

From my screenshot, this does not appear to be so. Each radio has its own control knobs.

 

On 12/6/2016 at 4:53 PM, shorthauler said:

This is why I suspected that with the offsets you can only turn the knob but not set a specific frequency directly, but let's see about the answers.

Again, from the NGX panel screenshot, you will see that you do in fact need to turn knobs to increment/decrement the COM and NAV frequencies, and do not set specific frequencies directly through a common keypad.

Finally, if your only requirement is to set the frequencies (values) directly through a keypad-like device (though that is not how the PMDG version works), you would need to write to the standard FSUIPC offsets:

0x034E, "UW", com1_freq
0x311A, "UW", com1_sby
0x3118, "UW", com2_freq
0x311C, "UW", com2_sby

0x0350, "UW", nav1_freq
0x311E, "UW", nav1_sby
0x0352, "UW", nav2_freq
0x3120, "UW", nav2_sby

Regards,

Chakko.

[shorthauler]

Thank you, this works. What are you using for ADF1, if I may ask?

And for course? Do you send the five digit event value to FSX?

I am wondering if FSUIPC and EPIC only accept four digits.

Best,

Holger

[Pete Dowson]

3 hours ago, shorthauler said:

I am wondering if FSUIPC and EPIC only accept four digits.

FS and FSUIPC handle frequencies xxxx.x (1234.5) , but there are many add-on radio stacks which only support 4 digits. For the PFC serial port stacks, I had to use one of the other ADF buttons to switch between displaying (and adjusting) the xxxx (1234) and xxx.x parts (234.5).

Pete

 

[ckovoor]

8 hours ago, shorthauler said:

.......What are you using for ADF1, if I may ask?

And for course? Do you send the five digit event value to FSX?

(1) For ADF1:

-- adf1 (active) display

adf1f_main = ipc.readUW(0x034C)
adf1f_frac = ipc.readUB(0x0356)
adf1f_upper = ipc.readUB(0x0357)

and:

-- adf1 (active) selector
    ipc.control(65666,1)
    ipc.control(65648,1)
    ipc.control(65667,1)
    ipc.control(65649,1)
    ipc.control(65668,1)
    ipc.control(65650,1)
    ipc.control(66453,1)
    ipc.control(66454,1)

I think you would plan to write to the offsets, rather than use the FSX (incremental) controls that I have.

I could not access ADF1 SBY nor indeed ADF2 ACT or ADF2 SBY, and PMDG has not provided any information about these.

 

(2) For COURSE:

-- course display

0x6520, "UW", "MCP_Course1"
0x6522, "UW", "MCP_Course2"

-- course 1 selector
   ipc.control(70008,8192)
   ipc.control(70008,16384)

-- course 2 selector
   ipc.control(70041,8192)
   ipc.control(70041,16384)

I do not know whether it is possible to write to the COURSE offsets, as they might be read-only. As you can see I used the incremental controls supplied.

Regards,

Chakko.

[Pete Dowson]

4 hours ago, ckovoor said:

I do not know whether it is possible to write to the COURSE offsets, as they might be read-only.

None of the PMDG offsets are writeable -- they are just readouts for display. You have to use the controls they provide.

Pete

 

[shorthauler]

Gents,

Is it possible that I am mixing offsets and controls?

I have a file called EPICINFO5.CFG that lists all the offsets (four digits) that my hardware us writing to. 

I have replaced them with the five digit values provided by PMDG. But this is probably a mistake, isn't it?

I am also using the Level D 767 where the only thing I had to do to continue using my hardware was to replace the "native" offsets with those that are specific to the 767 and Leeksicon.

I imagined this to be the same with the PMDG values.

Best, 

Holger 

 

[Pete Dowson]

18 minutes ago, shorthauler said:

Is it possible that I am mixing offsets and controls?

I have a file called EPICINFO5.CFG that lists all the offsets (four digits) that my hardware us writing to. 

I have replaced them with the five digit values provided by PMDG. But this is probably a mistake, isn't it?

Yes, it certainly is.

"Offsets" are hexadecimal numbers in the range 0000-FFFF which represent positions inside FSUIPC memory which contains data. You can normally read all of them, and write most of them. Writing to them usually makes some actions happen -- FSUIPC detects the write and determines what to do about it by the offset value. The PMDG offsets aren't writable -- they only provided a way of reading all their data so it could be displayed.

"Controls" (also known in FS as "Events" or even "Key Events", are numbers representing an action, a request to be passed. The assignments you make in FSUIPC or in FS, whether for keys or buttons, are to controls. They don't represent any data specifically, but a thing to be done or set. They can provide data (via the parameter).

I think pretty much all of the PMDG cockpit switches and dials have their own assigned custom control numbers.

24 minutes ago, shorthauler said:

am also using the Level D 767 where the only thing I had to do to continue using my hardware was to replace the "native" offsets with those that are specific to the 767 and Leeksicon.

That's because Lekseecon was programmed to do this, to interpret the offsets for you.

25 minutes ago, shorthauler said:

I imagined this to be the same with the PMDG values

No. PMDG did things differently. It wasn't until later versions of the 737NG that you could do anything like now -- no custom controls, no data readouts. The stuff they did later and published in the SDK was an eventual concession to cockpit builders and the like.

But I still don't believe it's the right path to take for full hardware implementations of cockpit controls. I use a flight model with no cockpit at all. My cockpit support is external, via Prosim737 at present -- it used to be Project Magenta. There's also SimAvionics.

Pete

 

[shorthauler]

Thanks for confirming that I was indeed on the wrong track. I remember events like sending pulses, but can they also send values? I am mainly thinking about the course selector.

Best,

Holger

P.S.: What I like about EPIC is that the values are first generated within EPIC and only then sent to FSX. For example, I have mechanical encoders with only 9 detents, but I "taught" EPIC to read how fast they are turned, and when they are turned quickly, they generate a high value quicker. This is generated within EPIC and only then sent to FSX via EPICINFO5. Very practical. Also, FSX is not overwhelmed by a large number of inputs within a short period of time.

[Pete Dowson]

19 minutes ago, shorthauler said:

I remember events like sending pulses, but can they also send values? I am mainly thinking about the course selector.

Yes, of course. That's what the parameter is for.

20 minutes ago, shorthauler said:

What I like about EPIC is that the values are first generated within EPIC and only then sent to FSX. For example, I have mechanical encoders with only 9 detents, but I "taught" EPIC to read how fast they are turned, and when they are turned quickly, they generate a high value quicker. This is generated within EPIC and only then sent to FSX via EPICINFO5.

Yes. All the drivers I've written, for FlightLink EPIC stuff many years ago, and for all the PFC stuff a little more recently, does this. Whether you encode for fast and slow separately (it isn't needed for some types of values), it is always best to display locally immediately, send values at sensible periods to the sim (certainly not faster than it can display), and also ignore values sent for display from the Sim until the user has stopped turning the dial for a while (1/2 to 2/3rds second in my experience). This applies even to the fine encoders I have.

Pete

 

[shorthauler]

Peter, could you tell me in which document I should be reading up on these issues and what would be a good keyword to look for? I went through the User Guide and the guide for advanced users, looking for anything on "controls", but no success, or I missed it.

Best,

Holger

[Pete Dowson]

18 minutes ago, shorthauler said:

Peter, could you tell me in which document I should be reading up on these issues and what would be a good keyword to look for? I went through the User Guide and the guide for advanced users, looking for anything on "controls", but no success, or I missed it.

Sorry, what "issues"?  And how can you search for the word "controls" and not find that in many places throughout?

Pete

 

 

[shorthauler]

Apologies for not being sufficiently precise. Instead of "issues", I should have written "topic". With "controls" I meant "controls" as in "events" (the five digit numbers). I searched the User Guide and the guide for advanced users. I was hoping to find some examples for how to script.

 

Best regards,

Holger

[Pete Dowson]

Sorry, again it isn't clear. What do you mean by 'script'?

If you mean Lua plugins, there are documents and examples supplied, and the functions involving controls do say controls. A complete list of all FSX and P3D controls is also included.

Pete

 

 

[shorthauler]

I am still on EPIC, so I would need to modify my EPICINFO5.cfg and maybe also the FSUIPC.ini

I know that you are not working on EPICINFO5 anymore, but since it was also working with FSX, I thought I would find some information.

Best,

Holger

[shorthauler]

I will check whether it is possible to interface LUA between EPIC and FSX, i.e. EPIC would be talking to LUA like it is to Leeksicon for the LVD763, and LUA would then talk to FSX directly. With my current setup, EPIC talks to EPICINFO5 and EPICINFO5 talks to FSX.

 

Does this make sense to you?

Best,

Holger

[Pete Dowson]

50 minutes ago, shorthauler said:

Does this make sense to you?

Well, yes, you could write a Lua replacement for EPICINFO, doing the serial port reading and interpreting the results and sending the relevant data back similarly. At least, I have a vague recollection that EPIC interfaced via a normal serial COM port (or an emulating driver like the FTDI ones, these days). There are quite comprehensive COM facilities in the FSUIPC Lua libraries, and I would have thought these would cope. But it sounds like a it could be a lot of programming.

I'm afraid i remember nothing of EPIC these days. Sorry I can't be of more help.

Pete