Anomaly in latest APCC Beta


Worsel
 

I installed the updated APCC beta that Ray provided.  It installed without issue (Win 10,21H2). 

I have the MGBoxv2 for GPS and environmental conditions.  The latter all work fine as far as feeding to APCC.

One oddity.  The GPS lat/lon are correct, but the elevation is just below 600m; whereas I am at 1800m.  This is just a curiosity on my part, since this is a fixed observatory and the GPS data already in APCC does not change.  Screenshot of GPS tab attached

Any thoughts?  Any other info that would be helpful?

Bryan


Steve C. Mitchell, Sr., O.D.
 

Funny side story here if you all don’t mind. I took a look at the screen shot Worsel posted and saw his coordinates and immediately thought, heck he’s not too far from my observatory. I’m near Lat 38 N and -94 long W, then it hit me….duh, he’s +107 NOT – 107 long, dummy!

So then I got curious as to just where heck is he? So with good old Google Maps and the coordinates I checked him out and found he is definitely not my next door neighbor, but actually, under my feet in China, somewhere near Ordos City in Inner Mongolia. Cool!

My Dad always told me when I was a little kid and digging holes in the back yard, “if ya keep on digging you’re going to end up in China.” Guess he was right! 8>)

I’m afraid I am no help on your original question, Worsel, just a crazy story.

 

Steve

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Worsel via groups.io
Sent: Friday, February 18, 2022 7:32 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Anomaly in latest APCC Beta

 

I installed the updated APCC beta that Ray provided.  It installed without issue (Win 10,21H2). 

I have the MGBoxv2 for GPS and environmental conditions.  The latter all work fine as far as feeding to APCC.

One oddity.  The GPS lat/lon are correct, but the elevation is just below 600m; whereas I am at 1800m.  This is just a curiosity on my part, since this is a fixed observatory and the GPS data already in APCC does not change.  Screenshot of GPS tab attached

Any thoughts?  Any other info that would be helpful?

Bryan


Ray Gralak
 

Hmmm.. 1800 vs 600 -- Feet to Meters?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Worsel via groups.io
Sent: Friday, February 18, 2022 5:32 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Anomaly in latest APCC Beta

I installed the updated APCC beta that Ray provided. It installed without issue (Win 10,21H2).

I have the MGBoxv2 for GPS and environmental conditions. The latter all work fine as far as feeding to APCC.

One oddity. The GPS lat/lon are correct, but the elevation is just below 600m; whereas I am at 1800m. This is just
a curiosity on my part, since this is a fixed observatory and the GPS data already in APCC does not change.
Screenshot of GPS tab attached

Any thoughts? Any other info that would be helpful?

Bryan


Worsel
 

No.   I AM at 1800m in western Colorado and it is 107W (which can also be -107E).  (Not Mongolia either)

Bryan


Worsel
 

Maybe I should dig that hole 1200m deep!

Bryan


Worsel
 

Note elevation difference when running both the MGBox app and APPC


Ray Gralak
 

No. I AM at 1800m in western Colorado and it is 107W (which can also be -107E). (Not Mongolia either)
MGBox returns 1856. APCC expects units to be feet, converts 1856ft to 565.7088m.

Let's check the math: There are .3048 meters/ft, so can you tell me the answer to:

1856 ft * .3048 m/ft = ???

I'm guessing the answer is about 565.7088. Is that right?

-Ray


 

hmmm

Bryan i wonder what would happen if you set the preference in MGBox V2 app to feet?



On Fri, Feb 18, 2022 at 8:55 PM Ray Gralak <iogroups@...> wrote:
> No.   I AM at 1800m in western Colorado and it is 107W (which can also be -107E).  (Not Mongolia either)

MGBox returns 1856. APCC expects units to be feet, converts 1856ft to 565.7088m.

Let's check the math: There are .3048 meters/ft, so can you tell me the answer to:

1856 ft * .3048 m/ft = ???

I'm guessing the answer is about 565.7088. Is that right?

-Ray









--
Brian 



Brian Valente


Worsel
 

Ray

I think you've got it.  The question is why does APCC expect the elevation in feet (and how does the user know that), rather than read the units that a 3rd party sensor provides?  The GPS Tab in the Help file does not mention this at all.  Point me in the right direction if possible


Bryan


Worsel
 

Brian:  Good point.  However, you can only set the system, e.g. metric or Imperial, not the specific units.  Here's the outcome

MGBox
Temperature  F or C
Pressure ALWAYS hectoPascals (as opposed to psi)
Humidity ALWAYS %
Elevation ft or m

APCC Test button on  Environmental Settings
Temperature ALWAYS C
Pressure ALWAYS mbar (1mbar = i hPA)
Humidity ALWAYS %

Elevation (on GPS Tab) ft or m

This suggests that MGBox does everything internally in metric and provides it to other apps in metric and the Imperial is only for the display.  This may be where I am mistaken.  Regardless of how the MGBox displays the data, APPC always displays it on Environmental settings in metric.  If MGBox provides my elevation as 1800 m, but APPC expects it in ft and converts it to 560 m, then my observations make sense.

I know I said it was just a curiosity for elevation, but the environmental conditions are important for model corrections, true?

Bryan


Ray Gralak
 

Bryan,

Nothing has changed in the APCC beta in regards to the expected units, which implies something changed in the new MgBox ascom driver, if that is what you have been using. So, are you sure that the MgBox is sending the correct value in meters?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Worsel via groups.io
Sent: Friday, February 18, 2022 9:11 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Anomaly in latest APCC Beta

Ray

I think you've got it. The question is why does APCC expect the elevation in feet (and how does the user know
that), rather than read the units that a 3rd party sensor provides? The GPS Tab in the Help file does not mention
this at all. Point me in the right direction if possible


Bryan


Worsel
 

Ray

I can't answer what it sends.  I can only say that it displays the correct elevation in feet when I select imperial and displays the correct elevation in m when I select metric.  Does ASCOM require a units parameter as well as a numeric parameter when passing data?

Is it possible that earlier versions of APCC assumed feet,when it was meters being passed, and I just did not notice the oddity?

Bryan


Worsel
 

Ray

Don't worry about it.  Let's just move on.  Thanks!

Bryan


Ray Gralak
 

Bryan,

I can't answer what it sends. I can only say that it displays the correct elevation in feet when I select imperial and
displays the correct elevation in m when I select metric. Does ASCOM require a units parameter as well as a
numeric parameter when passing data?
The elevation is not retrieved via an ASCOM interface. The data is extracted from an NMEA message from the device. What is displayed by the MgBox may not be what is emitted in the NMEA messages that APCC receives and parses.

Is it possible that earlier versions of APCC assumed feet,when it was meters being passed, and I just did not notice
the oddity?
The units have not changed in APCC any time recently. I used the feet to meter conversion as an example to show how the numbers correlate. I believe APCC expects meters in the NMEA messages, but I haven't had a chance to dig through the code yet.

-Ray


Dale Ghent
 

On Feb 19, 2022, at 06:43, Ray Gralak <iogroups@...> wrote:

The units have not changed in APCC any time recently. I used the feet to meter conversion as an example to show how the numbers correlate. I believe APCC expects meters in the NMEA messages, but I haven't had a chance to dig through the code yet.
The NMEA GGA sentence is what should be used for elevation. Fields 9 and 10 are relevant to elevation, with 9 being the altitude above mean sea level in meters, and field 10 denoting the unit, which is always "M" for meters.

Field 6 also should be used to know when to "trust" the data; with field 6 denoting the GPS fix quality:

0 = Fix not available
1 = GPS fix
2 = Differential GPS fix

Obviously you'll want to ignore the sentence for any purposes if the fix quality is 0.


Ray Gralak
 

Bryan,

I got a chance to look at the code and APCC retrieves GPS data from the MgBoxV2 via a command string command, not an NMEA as I had originally thought. From my own logs, the values returned from the MgBoxV2 end with an "M" to signify meters. For example "41M" indicates an elevation is 41 meters. If the return value from the MgBoxV2 does not end with the "M", then APCC will assume the value is in feet and multiplies the value by 0.3048, which may be happening.

So, take a look at your APCC logs. Search for "GetGpsAltitude" and see what value is being returned by the MgBoxV2 application.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Worsel via groups.io
Sent: Friday, February 18, 2022 10:10 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Anomaly in latest APCC Beta

Ray

I can't answer what it sends. I can only say that it displays the correct elevation in feet when I select imperial and
displays the correct elevation in m when I select metric. Does ASCOM require a units parameter as well as a
numeric parameter when passing data?

Is it possible that earlier versions of APCC assumed feet,when it was meters being passed, and I just did not notice
the oddity?

Bryan


Worsel
 

Ray

Thanks for pointing me at the log entry.  It appears the discrepancy is related to case...i.e. is 1856m the same or different than 1856M?

Log entry for 2/28/2022 UTC 04:34:26

--------
0542778 2022-02-18 21:34:27.318:      Debug,       PollMount, Elapsed time to Process: 2 msecs
0542779 2022-02-18 21:34:27.640:      Debug,         MGBoxV2, GetGPSLatitude = N038° 27' 28"
0542780 2022-02-18 21:34:27.640:      Debug,         MGBoxV2, GetGPSLongitude = W107° 49' 35"
0542781 2022-02-18 21:34:27.640:      Debug,         MGBoxV2, GetGPSAltitude = 1856m
0542782 2022-02-18 21:34:27.640:      Debug,         MGBoxV2, GetSattelitesUsed = 3
0542783 2022-02-18 21:34:27.640:      Debug,         MGBoxV2, GetGPSUTC = 04:34:26
0542784 2022-02-18 21:34:27.640:      Debug,         MGBoxV2, GetGPSFixType = 2D
-----------

Screenshots for same time


Ray Gralak
 

Yep, it looks like the author changed the output character to lower case. APCC's check is case-sensitive. I'll change the check to be case-insensitive in the next build. For now, you can of course just change the value in APCC's Sites table.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Worsel via groups.io
Sent: Sunday, February 20, 2022 7:17 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Anomaly in latest APCC Beta

Ray

Thanks for pointing me at the log entry. It appears the discrepancy is related to case...i.e. is 1856m the same or
different than 1856M?

Log entry for 2/28/2022 UTC 04:34:26

--------
0542778 2022-02-18 21:34:27.318: Debug, PollMount, Elapsed time to Process: 2 msecs
0542779 2022-02-18 21:34:27.640: Debug, MGBoxV2, GetGPSLatitude = N038° 27' 28"
0542780 2022-02-18 21:34:27.640: Debug, MGBoxV2, GetGPSLongitude = W107° 49' 35"
0542781 2022-02-18 21:34:27.640: Debug, MGBoxV2, GetGPSAltitude = 1856m
0542782 2022-02-18 21:34:27.640: Debug, MGBoxV2, GetSattelitesUsed = 3
0542783 2022-02-18 21:34:27.640: Debug, MGBoxV2, GetGPSUTC = 04:34:26
0542784 2022-02-18 21:34:27.640: Debug, MGBoxV2, GetGPSFixType = 2D
-----------

Screenshots for same time



Dale Ghent
 

The capital M is standard for denoting meter units in the NMEA GGA sentence, though. That is likely where it comes from here. 

On Feb 21, 2022, at 08:19, Worsel via groups.io <bryancashion@...> wrote:

Ray

Thanks.  I have sent a note to Astromi.ch indicating that M is actually not SI-compliant for meters.

Bryan


Worsel
 

That's interesting, Dale.  M is not SI-compliant for meters, but rather mega.

Bryan