Negative Altitude

[yoshiwars]

Hello,

I am not sure if I am not doing it correctly or if something is off. I seem to only get negative altitude from this library. Here is a simple example and the output: `#include SiderealPlanets myAstro;

double lat = 33.835289; double lon = -117.914497; double elevation = 22;

void setup() { // put your setup code here, to run once: Serial.begin(115200); myAstro.begin(); myAstro.setTimeZone(-8);

myAstro.setGMTdate(2022, 01, 31); myAstro.setGMTtime(6, 10, 0);

myAstro.setLatLong(lat, lon); myAstro.setElevationM(elevation);

myAstro.setRAdec(myAstro.decimalDegrees(6, 45, 8), myAstro.decimalDegrees(-16, 43, 26));

Serial.println(myAstro.doRAdec2AltAz());

Serial.print("Local Time: "); Serial.println(myAstro.getLT());

Serial.print("Altitude: "); Serial.println(myAstro.getAltitude());

Serial.print("Azimuth: "); Serial.println(myAstro.getAzimuth());

}

void loop() { // put your main code here, to run repeatedly:

}`

Output: 1 Local Time: 22.17 Altitude: -41.86 Azimuth: 82.22

Any help would be appreciated Thank you!

[DavidArmstrong]

I repeated your sketch, with slight modifications, and I am able to get a positive altitude by using a different time of day:

`#include // Need the following define for SAMD processors

if defined (ARDUINO_ARCH_SAMD)

define Serial SerialUSB

endif

SiderealPlanets myAstro;

double lat = 33.835289; double lon = -117.914497; double elevation = 22;

void setup() { // put your setup code here, to run once: Serial.begin(9600); delay(2000); //SAMD boards may need a long time to init SerialUSB myAstro.begin(); myAstro.setTimeZone(-8); myAstro.rejectDST();

myAstro.setGMTdate(2022, 01, 31); myAstro.setGMTtime(6, 10, 0);

myAstro.setLatLong(lat, lon); myAstro.setElevationM(elevation);

myAstro.setRAdec(myAstro.decimalDegrees(6, 45, 8), myAstro.decimalDegrees(-16, 43, 26));

Serial.println(myAstro.doRAdec2AltAz());

Serial.print("Local Time: "); Serial.println(myAstro.getLT());

Serial.print("Altitude: "); Serial.println(myAstro.getAltitude());

Serial.print("Azimuth: "); Serial.println(myAstro.getAzimuth());

Serial.println(""); myAstro.setGMTtime(12, 10, 0); Serial.println(myAstro.doRAdec2AltAz()); Serial.print("Local Time: "); Serial.println(myAstro.getLT());

Serial.print("Altitude: "); Serial.println(myAstro.getAltitude());

Serial.print("Azimuth: "); Serial.println(myAstro.getAzimuth());

Serial.println(""); myAstro.setGMTtime(18, 10, 0); Serial.println(myAstro.doRAdec2AltAz()); Serial.print("Local Time: "); Serial.println(myAstro.getLT());

Serial.print("Altitude: "); Serial.println(myAstro.getAltitude());

Serial.print("Azimuth: "); Serial.println(myAstro.getAzimuth());

Serial.println(""); myAstro.setGMTtime(0, 10, 0); Serial.println(myAstro.doRAdec2AltAz()); Serial.print("Local Time: "); Serial.println(myAstro.getLT());

Serial.print("Altitude: "); Serial.println(myAstro.getAltitude());

Serial.print("Azimuth: "); Serial.println(myAstro.getAzimuth()); }

void loop() { // put your main code here, to run repeatedly:

}`

Gives:

`1 Local Time: 22.17 Altitude: 39.31 Azimuth: 184.65

1 Local Time: 4.17 Altitude: -12.46 Azimuth: 258.07

1 Local Time: 10.17 Altitude: -72.47 Azimuth: 13.62

1 Local Time: 16.17 Altitude: -6.40 Azimuth: 105.86

`

[yoshiwars]

How strange, I plugged in your exact code yet I get significantly different output: `1 Local Time: 22.17 Altitude: -59.34 Azimuth: 63.17

1 Local Time: 4.17 Altitude: 12.75 Azimuth: 120.46

1 Local Time: 10.17 Altitude: 32.44 Azimuth: 213.21

1 Local Time: 16.17 Altitude: -32.36 Azimuth: 270.84 ` I am using an Arduino Mega 2560, if that could be the difference? Thank you for your time!

[DavidArmstrong]

The other issue that is currently being reported on this Library is of a similar nature - it is also on a Mega 2560 specifically that is causing a problem. I'll quote what I wrote there:

I examined the code again, and see that there are no Mega-specific sections to it. In other words, the exact same code is being compiled and run on the Mega as on my SAMD board. It's just a different variation of the GCC complier that is doing the actual compilation. So whatever is messing this up on the Mega is specific to that compiler build. I do know that a big difference between ARM and Atmel processors is the handling of double vs. float. Quoting from https://forum.pjrc.com/threads/44011-Teensy-3-2-Maths-compatablity-with-Mega-2560 here:

"On AVR platforms, double is the same as float (i.e. 32-bit floating point). On ARM platforms, double is 64-bits and float is 32-bits."

While this doesn't seem like it should cause a problem as big as seen here, I can't rule it out. Without the two processors side-by-side to do comparisons, I can't easily find where the Mega GCC is going wildly different, compared to the SAMD GCC implementation.

For the other issue, I'm starting with doing some print statements to compare the SAMD and Mega outputs. However, since I don't own a Mega board, I have to wait for the other person to run the exact same test on their system. I may end up having to do the same thing here. Yet I suspect the two issues are probably different manifestations of the same thing. Let me see if I can track down the other one first, to see if that helps with this issue that you are seeing. Of course, if you have a SAMD board, in addition to your Mega, that would help too. We will just have to be patient on this.

[DavidArmstrong]

I definitely found one issue, which is now fixed in version 1.1.1 of the library. When the Arduino Library manager updates with the new release, go ahead and test it out to verify if it resolves this issue for you. (And yes, it is something subtly specific to the Mega processor as compared to the SAMD boards that I use.)

[yoshiwars]

I manually installed your latest version and now your sketch from earlier is giving me the same output. I will try it out in my telescope code and will let you know. Just in case it doesn't work, what specific board are you using? I could switch boards if I have to, although I need one that can handle 3 Serial connections at the same time.

Thank you so much!

[yoshiwars]

I think it is working now although in my code it is wrong. I suspect this is an issue on my end, when I plug in values into a simple sketch like we used earlier I am getting close enough numbers that I can compare with Stellarium.

My telescope code is dynamically entering the time and location from a GPS and then over bluetooth syncing what object I have selected in Stellarium. Must be an issue in there.

If I could make a suggestion, having a method for getting the GPS coordinates out could be useful. I can fork over the code and add it my own for now.

Thank you again for all the assistance and this wonderful library.

[DavidArmstrong]

FYI - I am using a Sparkfun Redboard Turbo for my development and testing. It is based on the Arduino Zero design, and uses the same SAMD ARM processor (32-bit). I know Adafruit makes a similar board as well. The SAMD processor does allow defining more than the standard two UART interfaces, via the SERCOM functionality. My test setup has three UART interfaces: SerialUSB, Serial1, and a Serial2 that I created from SERCOM. Another possibility is using Teensy 4.0/4.1, which also allows more than the standard two UART interfaces. (It is also much faster, and has hardware double float support as well.)

As far as getting the GPS coordinates, I figured that GPS specific handling is outside the scope of the library. (And I didn't think that reading back the Longitude and Latitude provided to the library was a needed function, since that can be recorded by the user externally.)

[yoshiwars]

No worries, I just forked it for myself and added this little bit to get it out: double SiderealPlanets::getLatitude(){ return decLat; }

//Get Longitude double SiderealPlanets::getLongitude(){ return decLong; }

Since the object is global for me, and my GPS handling is its own separate function, it was easier for me to get the GPS I am at out of the SiderealPlanets object. Thanks for the help.

[DavidArmstrong]

I noticed that this issue was still open. Even though it hasn't been updated in over a year, on reflection I've decided to take yoshiwars recommendation to include functions for getLatitude() and getLongitude(). These will be put into release 1.2.0 today.

[DavidArmstrong]

Added changes in as Release v1.2.0. Closing issue now.