Verification of accuracy

[LovatoTomas]

Hi, I have several boards, but none that support true doubles. I modified my telescope with an Arduino to be a goto system, but many times it's even wrong by one degree. I wanted to understand if the reason is only the inaccuracy due to the float - double or if something else.
I would like to buy Arduino Giga (arm m7 with double support) but first I would like to ask you if you can run the code of example 3 (slightly modified) with these parameters (coordinates of Jupiter on the indicated datetime/location):

#include <SiderealPlanets.h>

// Need the following define for SAMD processors
#if defined(ARDUINO_SAMD_ZERO) && defined(SERIAL_PORT_USBVIRTUAL)
#define Serial SERIAL_PORT_USBVIRTUAL
#endif

SiderealPlanets myAstro;

void setup() {
Serial.begin(9600);
delay(2000); //SAMD boards may need a long time to init SerialUSB
Serial.println("Sidereal Planets Coordinate Conversion Functions");
myAstro.begin();
Serial.println("\nBecause these conversions are dependent on both time and location,");
Serial.println("those values have to be set first.");
myAstro.rejectDST();
myAstro.setTimeZone(-3);
myAstro.setLatLong(myAstro.decimalDegrees(46,55,0), myAstro.decimalDegrees(31,0,0));
myAstro.setGMTdate(2023,7,30);
myAstro.setLocalTime(23,0,0);
Serial.print("Latitude: ");
myAstro.printDegMinSecs(myAstro.getLatitude());
Serial.println("");
Serial.print("Longitude: ");
myAstro.printDegMinSecs(myAstro.getLongitude());
Serial.println("");

Serial.println("Now convert RA/Declination to Azimuth/Altitude coordinates");

myAstro.setRAdec(myAstro.decimalDegrees(2,46,2.7), myAstro.decimalDegrees(14,45,32.5));
Serial.print("Right Ascension ==> ");
myAstro.printDegMinSecs(myAstro.getRAdec());
Serial.println("");
Serial.print("Declination ==> ");
myAstro.printDegMinSecs(myAstro.getDeclinationDec());
Serial.println();
myAstro.doRAdec2AltAz();

Serial.println("And the Results are:");
Serial.print("Azimuth==> ");
myAstro.printDegMinSecs(myAstro.getAzimuth());
Serial.println("");
Serial.print("Altitude==> ");
myAstro.printDegMinSecs(myAstro.getAltitude());
Serial.println("\n");

Serial.println("And we can take the Azimuth/Altitude, and compute RA/Dec:");
myAstro.doAltAz2RAdec();
Serial.print("Right Ascension ==> ");
myAstro.printDegMinSecs(myAstro.getRAdec());
Serial.println("");
Serial.print("Declination ==> ");
myAstro.printDegMinSecs(myAstro.getDeclinationDec());
Serial.println();
}

void loop() {
while(1); //Freeze
}

My results are:

Sidereal Planets Coordinate Conversion Functions
Because these conversions are dependent on both time and location,
those values have to be set first.
Latitude: 46:55:0.00
Longitude: 31:0:0.00
Now convert RA/Declination to Azimuth/Altitude coordinates
Right Ascension ==> 2:46:2.70
Declination ==> 14:45:32.50
And the Results are:
Azimuth==> 128:23:54.00
Altitude==> 47:42:23.84
And we can take the Azimuth/Altitude, and compute RA/Dec:
Right Ascension ==> 2:46:2.69
Declination ==> 14:45:32.49

But the results should be (only AltAz is wrong):

Sidereal Planets Coordinate Conversion Functions
Because these conversions are dependent on both time and location,
those values have to be set first.
Latitude: 46:55:0.00
Longitude: 31:0:0.00
Now convert RA/Declination to Azimuth/Altitude coordinates
Right Ascension ==> 2:46:2.70
Declination ==> 14:45:32.50
And the Results are:
Azimuth==> 129:34:14.60
Altitude==> 48:13:20.50
And we can take the Azimuth/Altitude, and compute RA/Dec:
Right Ascension ==> 2:46:2.69
Declination ==> 14:45:32.49

I need a correct AltAz- RAdec conversion and vice versa because my telescope has an altazimuth mount while stellarium (with the lx200 protocol) works with RAdec.
If you can run this code with a board that supports real doubles and give me feedback, you'd be doing me a huge favor.
Thank you!

[DavidArmstrong]

Hi Tomas, Running your sketch on my SAMD51 processor, I get nearly the same results you see on your system: Sidereal Planets Coordinate Conversion Functions Because these conversions are dependent on both time and location, those values have to be set first. Latitude: 46:55:0.00 Longitude: 31:0:0.00 Now convert RA/Declination to Azimuth/Altitude coordinates Right Ascension ==> 2:46:2.69 Declination ==> 14:45:32.49 And the Results are: Azimuth==> 128:23:47.31 Altitude==> 47:42:20.89 And we can take the Azimuth/Altitude, and compute RA/Dec: Right Ascension ==> 2:46:2.70 Declination ==> 14:45:32.49 Your implementation of the sample sketch looks correct, so I don't know offhand why there would be an error here. When I get some time, I'll review the associated functions and let you know if I see any errors. Dave

…

On Sun, Jul 30, 2023 at 2:38 AM Tomas Lovato ***@***.***> wrote: Hi, I have several boards, but none that support true doubles. I modified my telescope with an Arduino to be a goto system, but many times it's even wrong by one degree. I wanted to understand if the reason is only the inaccuracy due to the float - double or if something else. I would like to buy Arduino Giga (arm m7 with double support) but first I would like to ask you if you can run the code of example 3 (slightly modified) with these parameters (coordinates of Jupiter on the indicated datetime/location): #include <SiderealPlanets.h> // Need the following define for SAMD processors #if defined(ARDUINO_SAMD_ZERO) && defined(SERIAL_PORT_USBVIRTUAL) #define Serial SERIAL_PORT_USBVIRTUAL #endif SiderealPlanets myAstro; void setup() { Serial.begin(9600); delay(2000); //SAMD boards may need a long time to init SerialUSB Serial.println("Sidereal Planets Coordinate Conversion Functions"); myAstro.begin(); Serial.println("\nBecause these conversions are dependent on both time and location,"); Serial.println("those values have to be set first."); myAstro.rejectDST(); myAstro.setTimeZone(-3); myAstro.setLatLong(myAstro.decimalDegrees(46,55,0), myAstro.decimalDegrees(31,0,0)); myAstro.setGMTdate(2023,7,30); myAstro.setLocalTime(23,0,0); Serial.print("Latitude: "); myAstro.printDegMinSecs(myAstro.getLatitude()); Serial.println(""); Serial.print("Longitude: "); myAstro.printDegMinSecs(myAstro.getLongitude()); Serial.println(""); Serial.println("Now convert RA/Declination to Azimuth/Altitude coordinates"); myAstro.setRAdec(myAstro.decimalDegrees(2,46,2.7), myAstro.decimalDegrees(14,45,32.5)); Serial.print("Right Ascension ==> "); myAstro.printDegMinSecs(myAstro.getRAdec()); Serial.println(""); Serial.print("Declination ==> "); myAstro.printDegMinSecs(myAstro.getDeclinationDec()); Serial.println(); myAstro.doRAdec2AltAz(); Serial.println("And the Results are:"); Serial.print("Azimuth==> "); myAstro.printDegMinSecs(myAstro.getAzimuth()); Serial.println(""); Serial.print("Altitude==> "); myAstro.printDegMinSecs(myAstro.getAltitude()); Serial.println("\n"); Serial.println("And we can take the Azimuth/Altitude, and compute RA/Dec:"); myAstro.doAltAz2RAdec(); Serial.print("Right Ascension ==> "); myAstro.printDegMinSecs(myAstro.getRAdec()); Serial.println(""); Serial.print("Declination ==> "); myAstro.printDegMinSecs(myAstro.getDeclinationDec()); Serial.println(); } void loop() { while(1); //Freeze } My results are: Sidereal Planets Coordinate Conversion Functions Because these conversions are dependent on both time and location, those values have to be set first. Latitude: 46:55:0.00 Longitude: 31:0:0.00 Now convert RA/Declination to Azimuth/Altitude coordinates Right Ascension ==> 2:46:2.70 Declination ==> 14:45:32.50 And the Results are: Azimuth==> 128:23:54.00 Altitude==> 47:42:23.84 And we can take the Azimuth/Altitude, and compute RA/Dec: Right Ascension ==> 2:46:2.69 Declination ==> 14:45:32.49 But the results should be (only AltAz is wrong): Sidereal Planets Coordinate Conversion Functions Because these conversions are dependent on both time and location, those values have to be set first. Latitude: 46:55:0.00 Longitude: 31:0:0.00 Now convert RA/Declination to Azimuth/Altitude coordinates Right Ascension ==> 2:46:2.70 Declination ==> 14:45:32.50 And the Results are: Azimuth==> 129:34:14.60 Altitude==> 48:13:20.50 And we can take the Azimuth/Altitude, and compute RA/Dec: Right Ascension ==> 2:46:2.69 Declination ==> 14:45:32.49 I need a correct AltAz- RAdec conversion and vice versa because my telescope has an altazimuth mount while stellarium (with the lx200 protocol) works with RAdec. If you can run this code with a board that supports real doubles and give me feedback, you'd be doing me a huge favor. Thank you! — Reply to this email directly, view it on GitHub <#8>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACGQKIMWKMY3RK46MRGPWLXSYTQ7ANCNFSM6AAAAAA25CNZMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[LovatoTomas]

Thank you.
In particular, I only use the AltAz to RaDec conversion (because my telescope has an Altazimuth mount, while Stellarium requires data in RaDec).

I often notice that there is an inaccuracy of about one degree between what I observe and what Stellarium measures. If I calibrate the telescope on a particular object, then I move it adds inaccuracies. But if I go back to the same initial object (even doing several rounds) everything is correct, so I'm sure the reason is not the hardware.

As in the proof I sent you, it really seems like a conversion problem from AltAz to RaDec, because instead if you convert RaDec-AltAz-RaDec the result returns to the original one, so that part of the code should be revised (in my opinion).

[DavidArmstrong]

It sounds like what you are stating is that Stellarium also shows this same 1 degree difference, same as the SiderealPlanets doRAdec2AltAz() routine. I trust Stellarium, and so if it is reporting similar results, that would make sense. I also noticed that in your routine you are using setLocalTime() to set the time, with the time at 2300. That's suspiciously close to the end of the day, particularly with the time zone difference of -3, and the date set by setGMTdate(). So I'm wondering if the GMT date used is off by one day. If I set: myAstro.setGMTdate(2023,7,31); I magically get: And the Results are: Azimuth==> 129:35:10.69 Altitude==> 48:13:44.72 Which is very close to what you are expecting. Dave

…

On Mon, Jul 31, 2023 at 11:21 PM Tomas Lovato ***@***.***> wrote: Thank you. In particular, I only use the AltAz to RaDec conversion (because my telescope has an Altazimuth mount, while Stellarium requires data in RaDec). I often notice that there is an inaccuracy of about one degree between what I observe and what Stellarium measures. If I calibrate the telescope on a particular object, then I move it adds inaccuracies. But if I go back to the same initial object (even doing several rounds) everything is correct, so I'm sure the reason is not the hardware. As in the proof I sent you, it really seems like a conversion problem from AltAz to RaDec, because instead if you convert RaDec-AltAz-RaDec the result returns to the original one, so that part of the code should be revised (in my opinion). — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACGQKODQEPQ3O4LSWMBQG3XTCN7NANCNFSM6AAAAAA25CNZMI> . You are receiving this because you commented.Message ID: ***@***.***>

[yoshiwars]

I just wanted to comment on the hardware part. On my scope, I have experienced the same thing where it is off moving from one object to another but returning comes back exact. I made a calibration to get averages of how far the discrepancy and then using it as a multiplier in counting the steps made. Its not perfect but on my Binocular mount it gets the object into the view usually.

It seems to me that the issue is the motors and gearing I am using is not exactly as the specs declare. Also the backlash on my motors is about a degree which means some rotation is lost if I am switching directions.

Here is my code for reference:
https://github.com/yoshiwars/Arduinoscope

[LovatoTomas]

Thank you so much for your replies.
I will do some more tests with Stellarium.

However, I have no doubts about the hardware part because I don't have an error offset that adds up as I turn, but if I calibrate on a star, then I make one or more complete turns (even 20, all clockwise or counterclockwise) the pointer returns precisely to the starting star.
I only get errors when I don't do complete turns (which is weird using incremental encoders).
Thank you all.

[LovatoTomas]

Hi, sorry if I don't write much but it's a busy period. I'm trying to configure example 3 for Italy (Rome, where I currently live) but I can never get the expected result. I think I'm having some difficulty because of the DST. Could you show me how you would configure example 3 in my case? Thank you all!

[DavidArmstrong]

Hi Tomas, First of all, I apologize for taking this long to get back to you. Life is crazy at times. Anyway, since I don't know how you are attempting to modify Example 3 for Rome, Italy, I went ahead and tried to do the needed modifications for you. The time zone offset should be 2 hours, and DST should be enforced for this time of year. I'll attach a variation of Example 3 that may work for you. It compiles, but is otherwise untested. So it may or may not work for you. Dave

…

On Sun, Sep 10, 2023 at 6:00 AM Tomas Lovato ***@***.***> wrote: Hi, sorry if I don't write much but it's a busy period. I'm trying to configure example 3 for Italy (Rome, where I currently live) but I can never get the expected result. I think I'm having some difficulty because of the DST. Could you show me how you would configure example 3 in my case? Thank you all! — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACGQKOGNUTHV5GLV46CFFTXZW2WLANCNFSM6AAAAAA25CNZMI> . You are receiving this because you commented.Message ID: ***@***.***>

[LovatoTomas]

Hi David,
thanks for your help. I can't find your attached code though...

However, I also tried in the past with the settings you suggest (timezone +2 and DST activated) but I get strange results. Starting from the code I paste below, based on Rome and Jupiter, on 2023-10-01 at 11.00 pm, I tried to deactivate and activate the DST, and also change the timezone from +2 to +1, but the result in Alt/Az that I get is always the same...

Code:

#include <SiderealPlanets.h>

// Need the following define for SAMD processors
#if defined(ARDUINO_SAMD_ZERO) && defined(SERIAL_PORT_USBVIRTUAL)
#define Serial SERIAL_PORT_USBVIRTUAL
#endif

SiderealPlanets myAstro;

void setup() {
  Serial.begin(9600);
  delay(2000); //SAMD boards may need a long time to init SerialUSB
  Serial.println("Sidereal Planets Coordinate Conversion Functions");
  myAstro.begin();
  Serial.println("\nBecause these conversions are dependent on both time and location,");
  Serial.println("those values have to be set first.");
  myAstro.setDST();
  myAstro.setTimeZone(2);
  // Location = Rome, Italy - 41.89332 12.48293
  myAstro.setLatLong(41.89332, 12.48293);
  myAstro.setGMTdate(2023,10,01);
  myAstro.setLocalTime(23,0,0);
  Serial.print("Latitude: ");
  myAstro.printDegMinSecs(myAstro.getLatitude());
  Serial.println("");
  Serial.print("Longitude: ");
  myAstro.printDegMinSecs(myAstro.getLongitude());
  Serial.println("");
  
  Serial.println("Now convert RA/Declination to Azimuth/Altitude coordinates");
  // Focus on Jupiter: RA/Dec according to stellarium web --> 02h 49m20.2s   +14°48'41.4"
  // Focus on Jupiter: Alta/Az according to stellarium web --> 095°42'50.6"   +28°43'22.9"
  myAstro.setRAdec(myAstro.decimalDegrees(2, 49, 20.2), myAstro.decimalDegrees(14, 48, 41.4));
  Serial.print("Right Ascension  ==> ");
  myAstro.printDegMinSecs(myAstro.getRAdec());
  Serial.println("");
  Serial.print("Declination  ==> ");
  myAstro.printDegMinSecs(myAstro.getDeclinationDec());
  Serial.println();
  myAstro.doRAdec2AltAz();
  
  Serial.println("And the Results are:");
  Serial.print("Azimuth==> ");
  myAstro.printDegMinSecs(myAstro.getAzimuth());
  Serial.println("");
  Serial.print("Altitude==> ");
  myAstro.printDegMinSecs(myAstro.getAltitude());
  Serial.println("\n");
  
  Serial.println("And we can take the Azimuth/Altitude, and compute RA/Dec:");
  // Focus on Jupiter: Alta/Az according to stellarium web --> 095°42'50.6"   +28°43'22.9"
  // Focus on Jupiter: RA/Dec according to stellarium web --> 02h 49m20.2s   +14°48'41.4"
  myAstro.doAltAz2RAdec();
  Serial.print("Right Ascension  ==> ");
  myAstro.printDegMinSecs(myAstro.getRAdec());
  Serial.println("");
  Serial.print("Declination  ==> ");
  myAstro.printDegMinSecs(myAstro.getDeclinationDec());
  Serial.println();
}

void loop() {
  while(1); //Freeze
}

Output of code:

Sidereal Planets Coordinate Conversion Functions

Because these conversions are dependent on both time and location,
those values have to be set first.
Latitude: 41:53:35.95 
Longitude: 12:28:58.55 
Now convert RA/Declination to Azimuth/Altitude coordinates
Right Ascension  ==> 2:49:20.19 
Declination  ==> 14:48:41.40 
And the Results are:
Azimuth==> 140:56:37.84 
Altitude==> 57:42:23.62 

And we can take the Azimuth/Altitude, and compute RA/Dec:
Right Ascension  ==> 2:49:20.19 
Declination  ==> 14:48:41.40 

Stellarium screenshot (coords, time and location):

[fpkon]

Hi David,
thank you for this helpful code.

I tried to reproduce Tomas' issue and got the same results. I went through your code and figured out that the GMTtime variable in the setGMTtime() function is not updated, when only the GMThour was changed in setLocalTime(); GMThour is changed in setLocalTime() and then passed as hours to setGMTtime(), so the if statement in line 290 is true, if minutes and seconds stay the same. Then there is no update of GMTtime in line 307.
Therefore doRAdec2AltAz() and doAltAz2RAdec() got the wrong information from getLocalSiderealTime().

I am not sure about the side effects of just commenting the if statement, you have the better overview!

Best,
Ralf

[DavidArmstrong]

I revisted the definition of setGMTtime(), particularly the sanity checking that is done at the start of the routine. So I ran a test with the first redundancy check bypassed, so that setLocalTime() calling setGMTtime() would not cause the suspected side effect.
When I run the attached routine above, I get a completely different output now for the Azimuth and Altitude:

`Sidereal Planets Coordinate Conversion Functions

Because these conversions are dependent on both time and location,
those values have to be set first.
Latitude: 41:53:35.95
Longitude: 12:28:58.54
Now convert RA/Declination to Azimuth/Altitude coordinates
Right Ascension ==> 2:49:20.20
Declination ==> 14:48:41.39
And the Results are:
Azimuth==> 85:35:33.17
Altitude==> 17:31:35.56

And we can take the Azimuth/Altitude, and compute RA/Dec:
Right Ascension ==> 2:49:20.20
Declination ==> 14:48:41.39 `

So something is still resulting in an incorrect result for Azimuth and Altitude.
However, the patch done to setGMTtime() still needs to be done, so I'll push that out today.

[DavidArmstrong]

I think I found the final discrepancy. The original routine that was quoted had this statement:
myAstro.setDST();

I see much better results if I instead replace that one line with this:
myAstro.rejectDST();

Now the output looks almost identical to what Stellarium shows:
`Sidereal Planets Coordinate Conversion Functions

Because these conversions are dependent on both time and location,
those values have to be set first.
Latitude: 41:53:35.95
Longitude: 12:28:58.54
Now convert RA/Declination to Azimuth/Altitude coordinates
Right Ascension ==> 2:49:20.20
Declination ==> 14:48:41.39
And the Results are:
Azimuth==> 95:43:23.42
Altitude==> 28:42:28.22

And we can take the Azimuth/Altitude, and compute RA/Dec:
Right Ascension ==> 2:49:20.20
Declination ==> 14:48:41.39 `

[fpkon]

Hi David!

Thanks for your reply!

I think I found the final discrepancy. The original routine that was quoted had this statement: myAstro.setDST();

I see much better results if I instead replace that one line with this: myAstro.rejectDST();

Now the output looks almost identical to what Stellarium shows: `Sidereal Planets Coordinate Conversion Functions

Because these conversions are dependent on both time and location, those values have to be set first. Latitude: 41:53:35.95 Longitude: 12:28:58.54 Now convert RA/Declination to Azimuth/Altitude coordinates Right Ascension ==> 2:49:20.20 Declination ==> 14:48:41.39 And the Results are: Azimuth==> 95:43:23.42 Altitude==> 28:42:28.22

And we can take the Azimuth/Altitude, and compute RA/Dec: Right Ascension ==> 2:49:20.20 Declination ==> 14:48:41.39 `

Yes, I can confirm these results!

Rome is on longitude 12.5° E and in time zone 1. When you adjust for daylight saving, there is a difference of +2 relative to GMT. Tomaso set the timezone 2, so already compensated for daylight saving and therefore, for correct results, it should state rejectDST().

myAstro.setDST(); myAstro.setTimeZone(1);
myAstro.rejectDST(); myAstro.setTimeZone(2);

deliver the same correct results for Rome and October, 1st.

[fpkon]

I am not so deep in your code as you, I am just wondering, if the trouble starts when you change the GMThour variable already in your setLocalTime() function in line 315.
Maybe you could make those time zone and daylight saving compensations only to the local hours variable first, like

hours = hours - TimeZoneOffset; 
if (useDST) hours = hours-1;
return setGMTtime(inRange24(hours), minutes, seconds);

Then you are not passing already the changed GMThour to the setGMTtime() function and your redundancy check should deliver reasonable results and your critical GMTtime decimal variable you use for all the RADec<->AltAz conversions is updated at least once in line 301.