Date
1 - 20 of 22
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).
|
|
|
|
Hmmm.. 1800 vs 600 -- Feet to Meters?
toggle quoted messageShow quoted text
-Ray
-----Original Message-----
|
|
|
|
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
|
|
|
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) --
|
|
|
|
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
|
|
|
|
Bryan,
toggle quoted messageShow quoted text
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-----
|
|
|
|
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
|
|
|
|
Bryan,
I can't answer what it sends. I can only say that it displays the correct elevation in feet when I select imperial andThe 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 noticeThe 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 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.
|
|
|
|
Bryan,
toggle quoted messageShow quoted text
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-----
|
|
|
|
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 
|
|
|
|
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.
toggle quoted messageShow quoted text
-Ray
-----Original Message-----
|
|
|
|
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:
|
|
|
|
Worsel
That's interesting, Dale. M is not SI-compliant for meters, but rather mega.
Bryan
|
|
|