GPS String ID of Next Waypoint

[ark1320]

Could someone please confirm that Offset 60A4, GPS String ID of next waypoint, works in P3Dv4.5 or P3Dv5.1.  I can get Offset 6048 (or 60EC), GPS Distance to next waypoint, and Offset 6081, String ID of previous waypoint, to work  But not Offset 60A4.  I get no response at all as if the code won't run, even if I test for a nil response. The simple test code I'm using (that does work with offset 6081) is:

 next_waypt = ipc.readSTR(0x60A4,10)
if next_waypt == nil then
    next_waypt = "NIL"
end    
ipc.writeSTR(0x3380, next_waypt);             
ipc.writeSW(0x32FA, 3);                                                 
ipc.sleep(3000)

The next waypoint for this test is just a VOR, or an airport ICAO code, so the actual waypoint String ID is 4 characters max.

Thanks for any ideas,

Al

FSUIPC ver 6.0.12

[ark1320]

To follow up a bit on the post above, if I run the test script below as shown, nothing is displayed at all, so it seems the ipc.readSTR(0x60A4, 10) at the second line is replacing the "ID Test_1"  from the first line with an unprintable character of some kind. If I comment out the second line, ID Test_1 is displayed as expected.

If in the orignal scirpt as shown I just uncomment the third line, ID Test_2 is displayed as expected, so the script does run with the second line active.

If I replace the second line with

next_waypt_info = ipc.readDBL(0x6048)    --distance to next GPS waypoint

the correct distance value to the next waypoint is displayed. So FSUIPC6 does "know" what the next waypoint is.  The flight plan I 'm using for these test is simply KCOS to KDEN (about 65 NM), so KDEN is the "next waypoint".

So it seems to me FSUIPC6 may have a bug that is preventing it from accessing the sim GPS next waypoint ID info for some reason, or maybe that info is not available in P3D ver4.5 or ver 5.1 (although GPS WP_NEXT ID is a listed sim variable), and so what ends up in offset 0x60A4 is an unprintable character of some kind. Maybe?

Thanks for any ideas,

Al

EDIT: Offset 0x60A4,  GPS String ID of next waypoint, does work in MSFS with FSUIPC7.  So perhaps there is a bug in FSUIPC6 (or P3D)?

next_waypt_info = "ID Test_1"
next_waypt_info = ipc.readSTR(0x60A4, 10)    -- GPS ID next waypoint
-- next_waypt_info = "ID Test_2"
if next_waypt_info == nil then
    next_waypt_info = "NIL"
 elseif next_waypt_info== "" then
    next_waypt_info = "EMPTY"
end    
ipc.writeSTR(0x3380, next_waypt_info)
ipc.writeSW(0x32FA, 5)
ipc.sleep (5000)

 

[Pete Dowson]

12 hours ago, ark1320 said:

it seems the ipc.readSTR(0x60A4, 10) at the second line is replacing the "ID Test_1"  from the first line with an unprintable character of some kind.

Not an unprintable, it'll just be a null string (i.e. one consisting only of the terminating zero, represented by "" in code).

12 hours ago, ark1320 said:

So it seems to me FSUIPC6 may have a bug that is preventing it from accessing the sim GPS next waypoint ID info for some reason, or maybe that info is not available in P3D ver4.5 or ver 5.1 (although GPS WP_NEXT ID is a listed sim variable)

All of the GPS data is treated exactly the same, simply reading the values via the Sim Var ("GPS WP NEXT ID" in this case). There's no separate code paths for any of them, it is simply a table listing the variables requested from SimConnect (only to be supplied on change), and the offset into which they are to be placed.

Haven't you tried Monitoring the offset to see if it ever changes? When one associated with a SimVar is monitored in this way, FSUIPC also lists the SimVar name and raw value received, when anything is received.

I can check here, see what I get, if you tell me exactly what you are doing. Which default aircraft?  Perhaps it would be quicker if you attach a flight file saved at the time you are checking this, and also the the plan file.  But please with a default aircraft -- I have no addon aircraft on my test system.

Pete

 

 

 

[John Dowson]

I took a look at the code for this as well, and its just a direct copy from the simvar to the offset, as Pete says. So if its empty, we are getting an empty value/string through from SimConnect for that simvar. The code in FSUIPC6 and FSUIPC7 is the same for this offset. Try logging the offset in both FSUIPC6 and FSUIPC7 and compare the output.
 

[ark1320]

I've been doing some more testing in P3Dv5. It seems the problem described above is related to the use of a third party GTN750 -- the RealityXP unit in this case.

If I load an aircraft, even an addon a/c, and enter a flight plan using the sim's flight plan planner without activating the GTN750, the 0x60A4 Offset (GPS WP NEXT ID) works as expected with my little test script below.  But if I activate the plane's GTN750 after using the sim's flight planner, then the test script fails. What I don't understand is why when the script fails there is no response at all (not even the 'green bar" appears) since as you can see from the test script I check for nil, and "", and 0 responses.

Thanks for the help,

Al

next_waypt_info = ipc.readSTR(0x60A4, 10)    -- GPS ID next waypoint
if next_waypt_info == nil then
    next_waypt_info = "NIL"
 elseif next_waypt_info == "" then
    next_waypt_info = "EMPTY"
 elseif next_waypt_info == 0 then
	next_waypt_info = "ZERO"
end    
ipc.writeSTR(0x3380, next_waypt_info)
ipc.writeSW(0x32FA, 5)
ipc.sleep (5000)

 

[John Dowson]

Maybe try logging the value of next_waypt_info after reading it to see what it contains, and/or having a final 'else' to set to "UNKNOWN" .

[ark1320]

1 hour ago, John Dowson said:

Maybe try logging the value of next_waypt_info after reading it to see what it contains, and/or having a final 'else' to set to "UNKNOWN" .

Good idea!

If I program in the else set to "UNKNOWN" , I do get UNKNOWN displayed.

Without the else set to "UNKNOWN", the log shows this when using the statement  next_waypt_info = ipc.readSTR(0x060A4, 10)

 3557031 KEYDOWN: VK=88, Waiting=0, Repeat=N, Shifts=2
  3557187 LUA: "C:\Users\Al\Documents\Prepar3D v5 Add-ons\FSUIPC6\Modules\TestScript.lua": killed
  3557250 .. This key is programmed in FSUIPC6 'Keys' options
  3557297 WRITElua 3380,  11 bytes: 00 00 00 00 00 00 00 00 47 48 00                 ........GH.
  3557359 WRITElua 32FA,   2 bytes: 05 00      

If I change the readSTR() to allow for 40 characters instead of just 10 [ ipc.readSTR(0x060A4, 40)  ] the log shows this:

 3705375 WRITElua 3380,  41 bytes: 00 00 00 00 00 00 00 00 47 48 3D A2 E5 78 43 40  ........GH=..xC@
  3705375                                            74 E6 5F C3 8A 28 5A C0 53 F6 ED 08 66 34 A7 40  t._..(Z.S...f4.@
  3705375                                            00 00 00 00 00 00 00 00 00                                         .........
  3705437 WRITElua 32FA,   2 bytes: 05 00                                                                               ..

I don't know what to make of all this, I will try talking to RealityXP to see if they have any ideas why the GTN750 is impacting the "GPS WP NEXT ID" sim variable, or maybe just FSUIPC6's access to the sim variable.

Al

 

                                    ..

[Pete Dowson]

1 hour ago, ark1320 said:

But if I activate the plane's GTN750 after using the sim's flight planner, then the test script fails. What I don't understand is why when the script fails there is no response at all (not even the 'green bar" appears) since as you can see from the test script I check for nil, and "", and 0 responses.

The reason is that the null string ("") is used to clear the 'green bar' display prematurely.  It mean there is nothing to display. The facility being used in FS cannot display a "nothing green bar" -- what would be the point? 

If you want it to display the null waypoint you need to put it into some context, like "Next waypoint = ..."

Pete

 

[ark1320]

4 minutes ago, Pete Dowson said:

The reason is that the null string ("") is used to clear the 'green bar' display prematurely.  It mean there is nothing to display. The facility being used in FS cannot display a "nothing green bar" -- what would be the point? 

If you want it to display the null waypoint you need to put it into some context, like "Next waypoint = ..."

Pete

 

For test purposes I was just trying to check for ("") as a possible response and if found display "EMPTY".  But from the log file info above, it doesn't seem the response is ("").

Thanks,

Al

[ark1320]

I looked at the Avar (A:GPS WP NEXT ID, string) with a test window for variables that I use when writing XML code. After loading a simple flight plan using the P3D flight planner, the Avar did hold the correct next waypoint ID, and the test Lua script worked.  When I then turned on the GTN750, the waypoint ID in the Avar changed to "GARMN". If I then loaded the GTN750 with the same flight plan as I had set up using the sim's flight planner, the Avar once again held the correct next waypoint ID, but the Lua script accessing offset 0x60A4 failed as described in posts above. Apparently offset 0x60A4 was not updated with the next waypoint ID after "GARMN" was replaced with the correct waypoint in the Avar.  With the aircraft sitting on the runway I then changed the next waypoint a few times using the GTN750 and the Avar changed correctly each time, but offset 0x60A4 did not get updated, at least not with a printable value as the test script repeatedly failed, and the log file for ipc.writeSTR() repeatedly showed strange characters as detailed above.  So perhaps there is a simconnect update issue of some kind once the GTN750 is active?

Thanks,

Al

[Pete Dowson]

14 hours ago, ark1320 said:

For test purposes I was just trying to check for ("") as a possible response and if found display "EMPTY".  But from the log file info above, it doesn't seem the response is ("").

Where are you seeing that? "" is a null string, meaning it consists only of a zero. "" is just the way of writing it as a string in a programming language like Lua.

It is might be that SimConnect supplied a "" (i.e. just a zero), or that it just didn't supply anything for that value because it hasn't changed. Offsets which haven't received values are zero. We could tell which is the case if you Monitored the offset (60A4) as a string (ASCIIZ), as I suggested. Seems you've not done that yet?

12 hours ago, ark1320 said:

So perhaps there is a simconnect update issue of some kind once the GTN750 is active?

Possibly.  You'd need to talk to the producers of that addon.

Pete

 

[ark1320]

16 hours ago, Pete Dowson said:

It is might be that SimConnect supplied a "" (i.e. just a zero), or that it just didn't supply anything for that value because it hasn't changed. Offsets which haven't received values are zero. We could tell which is the case if you Monitored the offset (60A4) as a string (ASCIIZ), as I suggested. Seems you've not done that yet?

Below is what I get when I monitor offset 0x60A4 with FSUIPC logging. HGO was the initial next waypoint ID based on the flight plan I initially loaded via the P3D4 flight planner. I also monitored the Avar (A:GPS WP NEXT ID, string) in my XML test window.  When I first activated the GTN750, the Avar changed from HGO to GARMN. Using the GTN750 flight plan page,  I first loaded HGO as the next waypoint (same as in the P3D4 flight planner) and then in succession changed the next waypoint to three different waypoints using just the GTN750. Each time I did this the Avar  (A:GPS WP NEXT ID, string) changed to the correct next waypoint ID. However, I don't see any such changes in the FSUIPC6.log file below (which hopefully I set up correctly).

So would a reasonable conclusion be Simconnect is not seeing the Avar change for some reason?

Al

 

    82797 Planned flight from KCOS to KDEN
    82797 C:\Users\Al\Documents\Prepar3D v4 Files\VFR City Of Colorado Springs Mun to Denver Intl.pln
    87156 Monitor IPC:60A4 (AsciiZ) = [3]"HGO"
    87156 Monitor IPC:60A4 (U8) = 72
    87156 SimRead: 60A4="GPS WP NEXT ID"
            STR8: "HGO"
    95141 Monitor IPC:60A4 (AsciiZ) = [0]""
    95141 Monitor IPC:60A4 (U8) = 0
    95141 SimRead: 60A4="GPS WP NEXT ID"
            STR8: ""
   153781 ### Mode: PAUSE on

 

[ark1320]

 

Al

 

11 hours ago, Pete Dowson said:

On 2/5/2021 at 12:01 PM, ark1320 said:

For test purposes I was just trying to check for ("") as a possible response and if found display "EMPTY".  But from the log file info above, it doesn't seem the response is ("").

Where are you seeing that? "" is a null string, meaning it consists only of a zero. "" is just the way of writing it as a string in a programming language like Lua

 

I thought "" represented an Empty string that I could test for from https://www.lua.org/manual/5.1/manual.html  where it said:

string.len (s)

Receives a string and returns its length. The empty string "" has length 0.

Even though I was not checking length, this suggested (to me at least) that you could check to see if a response string was empty by testing for "".

Also, in the FSUIPC Lua Reference document for ipc.display() it says  "To remove a display prematurely, send a null string (“”). So again I thought I could check for "".

The code below does display NULL, so checking for a null or empty string by testing for "" does seem to work. Or maybe I misunderstand the point you are making.

val = ""
if val == "" then
    str_val = "NULL"
 else
   str_val = "NOT NULL"
end  
ipc.writeSTR(0x3380, str_val)
ipc.writeSW(0x32FA, 5)
ipc.sleep (5000)

Thanks,

Al

[Pete Dowson]

16 hours ago, ark1320 said:

So would a reasonable conclusion be Simconnect is not seeing the Avar change for some reason?

Yes. Seems that the GTN750 software is using that variable internally and not setting it into the correct SimVar. Are the other variables all A: types? I know K: is used for Key Events (== FSUIPC 'controls') and H: isfor HTML, but what does A: stand for? I'm not familiar with the Gauge SDK at all.

Whatever, I think you need to ask the GTN750 producers why that value isn't known to SimConnect.

15 hours ago, ark1320 said:

Even though I was not checking length, this suggested (to me at least) that you could check to see if a response string was empty by testing for "".

Also, in the FSUIPC Lua Reference document for ipc.display() it says  "To remove a display prematurely, send a null string (“”). So again I thought I could check for "".

The code below does display NULL, so checking for a null or empty string by testing for "" does seem to work.

Yes, though I would check it by:

if string.byte(str_val) == 0

because the documentation for string.len(str_val) says it counts 'embedded zeros' too. I assume string.len works for you because the first an only character is zero, so it isn't truly "embedded", but to be it isn't a definite what of saying this.

Pete

 

 

[ark1320]

6 hours ago, Pete Dowson said:

Are the other variables all A: types? I know K: is used for Key Events (== FSUIPC 'controls') and H: isfor HTML, but what does A: stand for? I'm not familiar with the Gauge SDK at all.

An Aircraft variable (Avar) is a P3D variable usually associated with a particular Key Event. For example, the Avar (A:GPS DRIVES NAV1, bool) is the XML variable that toggles in response to the Key Event (K:TOGGLE_GPS_DRIVES_NAV1), also known as FSUIPC control 66375.

Thanks for all the feedback,

Al

[Pete Dowson]

17 hours ago, ark1320 said:

An Aircraft variable (Avar) is a P3D variable usually associated with a particular Key Event. For example, the Avar (A:GPS DRIVES NAV1, bool) is the XML variable that toggles in response to the Key Event (K:TOGGLE_GPS_DRIVES_NAV1), also known as FSUIPC control 66375.

Aha. So it is another internal variable like L:vars. But in your GPS ID case there wouldn't be a Key Event, whereas for A:GPS DRIVES NAV1 there's the SimConnect variable "GPS DRIVES NAV1". With the names being identical in that case I'd have thought the A: variables were more associated with SimVars than Key events?

The same should apply to your A:GPS WP NEXT ID which has the identical name to the SimVar "GPS WP NEXT ID".  I expect only the makers of the GTN750 add-on will be able to clarify why that A: value visible for their add-on via SimConnect.

Pete

 

[ark1320]

5 hours ago, Pete Dowson said:

I expect only the makers of the GTN750 add-on will be able to clarify why that A: value visible for their add-on via SimConnect.

Pete

I sent a message to RealityXP who provides the RXP GTN750. If I learn anything to shed light on the situation I'll report back here.

Al

[Pete Dowson]

40 minutes ago, ark1320 said:

I sent a message to RealityXP who provides the RXP GTN750. If I learn anything to shed light on the situation I'll report back here.

Okay. Thanks!

Pete

 

[ark1320]

On 2/8/2021 at 9:05 AM, Pete Dowson said:

Okay. Thanks!

Pete

 

Hi Pete,

I have not heard directly back from RXP (GTN 750 provider) yet. However, I was told on FSDev that making the GTN work requires 'hacking' into the P3D sim code, and that's why every time P3D is updated, the GTN code has to be updated as well.

And in response to another issue on the RXP forum, the RXP developer said:

"The RXP GTN is at least exporting all essential simvars necessary for direct interfacing if needed, although it also includes a technology to overriding the default simvars so that the GTN output data is transparently feed into the simvars other gauges are reading".

While I don't understand all the implications of this,  I have to wonder if the default simvar GPS WP NEXT ID is being overriden by the GTN but is not being "transparently fed" into the simvar that FSUIPC accesses?

I'm still hoping to get a direct response to the PM I sent RXP.

Al

 

[John Dowson]

3 minutes ago, ark1320 said:

I have to wonder if the default simvar GPS WP NEXT ID is being overriden by the GTN but is not being "transparently fed" into the simvar that FSUIPC accesses?

But the simvar that FSUIPC uses is the GPS WP NEXT ID! It is this simvar that is not holding the correct string/value. Maybe they use their own lvars instead?

 

[ark1320]

1 hour ago, John Dowson said:

But the simvar that FSUIPC uses is the GPS WP NEXT ID! It is this simvar that is not holding the correct string/value. Maybe they use their own lvars instead?

 

But when I monitor (A:GPS WP NEXT ID, string) with an XML test window it always holds the correct value when the GTN 750 GPS changes the next waypoint. So for some reason FSUIPC is not getting accesses to this variable. I wonder if there is a simvar table that FSUIPC accesses that is suppose to hold copies of variables like (A:GPS WP NEXT ID, string) and it is this table that is not getting updated because of the GTN750 coding.

Hopefully I'll get some details when RXP responds to my PM.

Al

[John Dowson]

15 minutes ago, ark1320 said:

But when I monitor (A:GPS WP NEXT ID, string) with an XML test window it always holds the correct value when the GTN 750 GPS changes the next waypoint. So for some reason FSUIPC is not getting accesses to this variable. I wonder if there is a simvar table that FSUIPC accesses that is suppose to hold copies of variables like (A:GPS WP NEXT ID, string) and it is this table that is not getting updated because of the GTN750 coding.

How are you monitoring that value? The FSUIPC knows nothing about 'S' values (or 'L'. 'H', K', etc). That's gauge code syntax. FSUIPC offsets are (mainly) based upon simulator variables, i.e. those you can request via the SDK. The variable lists accessible for this are published, one being 'GPS WP NEXT ID'.

As I said, FSUIPC just receives that value from SimConnect and populates the offset accordingly. The problem is that the valur we receive from SimConnect is not correct. That must be due to the model not updating this correctly. Maybe the GTN750 you are using is not populating the generic P3D data variables for this and its using its own internal variables (lvars or local variables).

John

[ark1320]

1 hour ago, John Dowson said:

How are you monitoring that value?

I have a XML gauge test window that I use when writing XML gauge code. It monitors the values of gauge Avars and Lvars. I've been told by a developer on FSDev that there is no difference between an Avar and a simulation variable with the identical name because the simulation variable is just the Avar that has been made available though SimConnect.  But while the Avar (GPS WP NEXT ID in this case) is definitely being updated correctly, what's being communicated through SimConnect to FSUIPC is not. Why not is what I hope to find out from RXP.

Al

[John Dowson]

1 hour ago, ark1320 said:

But while the Avar (GPS WP NEXT ID in this case) is definitely being updated correctly, what's being communicated through SimConnect to FSUIPC is not. Why not is what I hope to find out from RXP.

Thanks for the clarification.  Please update if/when you get a response.

John

[ark1320]

22 hours ago, John Dowson said:

Thanks for the clarification.  Please update if/when you get a response.

John

Hi Pete and John,

Below in blue is basically how I explained the situation to Jean-Lua, the RXP GTN750 developer, and below in green is his response. I don't know how to answer his question about how FSUIPC knows to update an offset value. He is trying to help and any info you can provide me to pass back to him will be appreciated.

Thanks,

Al

Part of my statement to RXP:

So SimConnect is the communication interface between the sim and FSUIPC. When FSUIPC reads a value via SimConnect it saves that value to a specific FSUIPC memory location, what FSUIPC calls an "Offset". My Lua script simply reads the value in that "FSUIPC" memory location. So in the case of the variable (A:GPS WP NEXT ID, string), FSUIPC gets the current value from SimConnect and stores it in "Offset" 0x60A4. The value in this location is suppose to be updated any time SimConnect sees the value of  GPS WP NEXT ID change. But for some reason, it seems that once the GTN750 is turned on, SimConnect can no longer see the value of the variable GPS WP NEXT ID. Before the GTN750 is turned on, SimConnect does see the value of GPS WP NEXT ID and the Lua script which reads the associated FSUIPC offset works correctly.

Response from RXP:

Now I see what you mean with SimConnect.

The question therefore is: how does FSUIPC gets notified the value changes?

If they're not polling often, and they are relying on SimConnect telling them, there is no way in the current implementation because the RXP code is interposing between consumers and the simulator so that it is in fact "shadowing" the underlying value.

In other words, as long as you're asking the simulator for the variable value, it will always work. But if you're waiting for an event telling you it has changed, this will not be triggered because underneath the override, the FS code is still running its own internal update and value code.

Which begs the question how did they implement their code reading simvars using SimConnect and updating their internal table of values exposed via their "offsets" with regard to values changing automatically and especially this one.

This also begs the question whether the level at which we're shadowing the simvar is low level enough into the FS code. I believe it is very low level indeed but it might be SimConnect is using its own alternate path to accessing the data and exporting it. One way to answer this would be you using SimConnect directly instead of FSUIPC in order to cross check whether this is working. I suspect it will but I might be wrong.