peterjc
Migrate astropysics --> astropy
Migrate code from astropysics to successor satrapy which has now reached v1.0
Wondering if you ever decided to do the migration? I've been looking at the code but Python is not really my area so not sure what I would need to alter.
No technical reason - I've just not had time to tinker with this, and have barely used the telescope - hopefully once our children are a bit older I'll get back to it.
I've had a, "interesting" time figuring out Python and giving a go at getting this to work with astropy. In fact I am I think all the way at the point where I have it correct but when I connect to Sky Safari Plus 7, it goes through, gets info then disconnects in Sky Safari (python script thinks it is ok) although looking at 2488 degrees in that output maybe I still don't have the astropy stuff correct. Everything is in the fork I made of your project if you are curious.
Processing ':St+5140#' Command ':St', argument '+5140' Error with :St+51d40# latitude: Cannot parse first argument data "" for attribute ra Command ':St', sending '0' Processing ':Sg35140#' Command ':Sg', argument '35140' Error with :Sg351d40# longitude: Cannot parse first argument data "" for attribute dec Command ':Sg', sending '0' Processing ':SG-01.0#' Command ':SG', argument '-01.0' Local site timezone now -1.0 Command ':SG', sending '1' Processing ':SG-01.0#' Command ':SG', argument '-01.0' Local site timezone now -1.0 Command ':SG', sending '1' Processing ':SL22:57:48#' Command ':SL', argument '22:57:48' Requested site time 22:57:48 (TZ -1.0), new offset -1s, total offset -1s Effective site date/time is 2022-01-23 23:57:48.546640 (local time), 2022-01-23 22:57:48.546867 (GMT/UTC) Command ':SL', sending '1' Processing ':SC01/23/22#' Command ':SC', argument '01/23/22' Requested site date 01/23/22 (MM/DD/YY) gives offset of 0 days Effective site date/time is 2022-01-23 23:57:48.597357 (local time), 2022-01-23 22:57:48.597577 (GMT/UTC) Command ':SC', sending '1Updating Planetary Data# #' Processing ':GR#' alt 0.7364696897183051 az 0.32560018147626457 Command ':GR', sending '00:04:05#' Processing ':RS#' Command ':RS', no response Processing ':GD#' alt 6.240148157794611 az 4.87558243585766 angle: 43.426638705069934 fraction: 0.7869743984392699 degress: 2488.0 RA 00:26:06# (0.11388 radians), dec -248809:47# (-43.42664 radians) angle: 43.426638705069934 fraction: 0.7869743984392699 degress: 2488.0 Command ':GD', sending '-248809:47#' Processing ':Q#' Command ':Q', no response
I hope you find tinkering with technology as fun as the astronomy side - this might take some effort.
Looking back at my blog post, I was using SkySafari v4.0.1 back then (7 years ago in Jan 2014), so it is possible that SkySafari interprets the protocol a little differently now? i.e. Back then it might have been more relaxed about any deviations from the protocol I was making?
Or, as you suggest, it could be a mismatch on the Python astronomical libraries doing non-sensical calculations.
I'm new on the astronomy side and so far have only been able to use the Telescope once to stare at the moon which got me hooked already :-) I have the code now working for Slewing. If my numbers are correct or not I am not sure. The current error is if I hit "align" in Sky Safari and try to align to an object it crashes as the equaltorial_to_alt_az function has wrong values but I can bounce the module all around and Sky Safari seems to react. Processing on the Pi Zero WH is slow so I may try it on my Pi 4 8GB to see if that makes a difference. Thanks to your project and code though I am understanding a lot more about "how" it all works and reading degrees and all of that.
Well I thought I had it, I did a 30sec screen recording of Sky Safari Plus 7.0 when the connection happens. I'm apparently not understanding the whole calculations or I simply did not implement something correctly. Results I'm assuming that screen change is not the right perspective?
Which telescope are you telling Sky Safari that you have? Have you tried a few as they behave slightly differently and slightly different commands get sent.
Start from the top,
Processing ':St+5140#'
Command ':St', argument '+5140'
Error with :St+51d40# latitude: Cannot parse first argument data "" for attribute ra
Command ':St', sending '0'
Processing ':Sg35140#'
Command ':Sg', argument '35140'
Error with :Sg351d40# longitude: Cannot parse first argument data "" for attribute dec
The command map dictionary maps those to:
":St": meade_lx200_cmd_St_set_latitude,
":Sg": meade_lx200_cmd_Sg_set_longitude,
However, neither is happy. My guess would be astropy.coordinates.SkyCoord does not like this input? I was using astropysics.coords.AngularCoordinate there, so perhaps that isn't the right alternative in astropy?
I was using your settings to start but I will try other ones as well - had not considered that, thanks!
This morning I actually noticed in the
":St": meade_lx200_cmd_St_set_latitude, ":Sg": meade_lx200_cmd_Sg_set_longitude
that I'm not sure I did any real updates there, I was going to check those tonight after work. I think I even added it to my todo.md file.
Astropy is powerful but also a bit over engineered I think sometimes.
Couldn't resist, just checked and yes I'm not doing the proper conversion with Astropy there, the try err block basically was handling it though so never noticed and did not pay attention in the output.
I think I am getting closer. If I understand the code correctly once I hit connect in Sky Safari, the following two functions get called.
FUNCTION meade_lx200_cmd_St_set_latitude - passed value: +5140 FUNCTION meade_lx200_cmd_Sg_set_longitude - passed value: 35140
the values being passed in though the latitude matches but the longitude is completely wrong. The full debug from start to connecting...
Checking Configuration Connecting to sensors... Connected to MPU9250 sensor Opening network port... FUNCTION parse_hhmm FUNCTION parse_hhmm FUNCTION parse_hhmm FUNCTION parse_hhmm FUNCTION parse_hhmm FUNCTION parse_sddmm FUNCTION parse_sddmm FUNCTION parse_sddmm FUNCTION parse_sddmm FUNCTION parse_hhmm FUNCTION parse_sddmm FUNCTION radians_to_hms FUNCTION radians_to_hms
Starting up on 192.168.86.42 port 4030 Processing ':St+5140#' Command ':St', argument '+5140' FUNCTION meade_lx200_cmd_St_set_latitude - passed value: +5140 Command ':St', sending '1' Processing ':Sg35140#' Command ':Sg', argument '35140' FUNCTION meade_lx200_cmd_Sg_set_longitude - passed value: 35140 Local site now latitude +51d40, longitude 351d40 Command ':Sg', sending '1' Processing ':SG-01.0#' Command ':SG', argument '-01.0' FUNCTION meade_lx200_cmd_SG_set_local_timezone - passed values: site_tz = -01.0 Local site timezone now -1.0 Command ':SG', sending '1' Processing ':SG-01.0#' Command ':SG', argument '-01.0' FUNCTION meade_lx200_cmd_SG_set_local_timezone - passed values: site_tz = -01.0 Local site timezone now -1.0 Command ':SG', sending '1' Processing ':SL22:22:56#' Command ':SL', argument '22:22:56' FUNCTION meade_lx200_cmd_SL_set_local_time - passed values: 22:22:56 Requested site time 22:22:56 (TZ -1.0), new offset 0s, total offset 0s FUNCTION debug_time - site_tz -1.0 FUNCTION site_time_local_as_datetime - site_tz -1.0 FUNCTION site_time_gmt_as_datetime FUNCTION site_time_gmt_as_epoch FUNCTION site_time_gmt_as_datetime FUNCTION site_time_gmt_as_epoch Effective site date/time is 2022-01-26 23:22:56.658149 (local time), 2022-01-26 22:22:56.660129 (GMT/UTC) Command ':SL', sending '1' Processing ':SC01/26/22#' Command ':SC', argument '01/26/22' FUNCTION meade_lx200_cmd_SC_set_local_date - passed values: 01/26/22 Requested site date 01/26/22 (MM/DD/YY) gives offset of 0 days FUNCTION debug_time - site_tz -1.0 FUNCTION site_time_local_as_datetime - site_tz -1.0 FUNCTION site_time_gmt_as_datetime FUNCTION site_time_gmt_as_epoch FUNCTION site_time_gmt_as_datetime FUNCTION site_time_gmt_as_epoch Effective site date/time is 2022-01-26 23:22:56.713266 (local time), 2022-01-26 22:22:56.715174 (GMT/UTC) Command ':SC', sending '1Updating Planetary Data# #' Processing ':GR#'
Do you recall where the value is coming from that is being passed into the command from the telescope? That 351*40 is blowing my mind. It could be because I messed up another value but the functions all being called up to this point some correct.
FUNCTION meade_lx200_cmd_St_set_latitude - passed value: +5140 Command ':St', sending '1' Processing ':Sg35140#' Command ':Sg', argument '35140' FUNCTION meade_lx200_cmd_Sg_set_longitude - passed value: 35140 Local site now latitude +51d40, longitude 351d40
From memory SkySafari (or other clients) start by telling the telescope where it is. Some GoTo telescopes have their own GPS, but this was rare when the protocol was designed. SkySafari would know the position from the iOS location services (perhaps pretty exact GPS, but at least a good guess - certainly good enough for finding the moon or getting the visible part of the celestial sphere about right).
I would start by checking your own location as latitude/longitude (e.g. use Google Maps), and then make sure the strings the Python code receives are about the same, and then look at how they are being interpreted in the Python code. Obvious potential mistakes are sign errors and North vs South for Latitude, or East vs West for longitude.
I may need to put this aside for a week or so then look again, I should be seeing something totally different. Longitude 8.33500 no clue where this is finding the 351 value - will maybe take a look at the Sky Safari side and see if I can see something there or a change the LX200 protocols.
The perspective/screen of Sky Safari jumps all over the place as if the values are jumping eractically from one extreme to another. It's possible with Astropy some of the math is not required in the alt_az_to_equatorial?
FUNCTION alt_az_to_equatorial - actual values: ra 4.906959035779865 - dec -0.12529272564088567 FUNCTION alt_az_to_equatorial - actual values: ra 5.705811927991121 - dec -0.2685587555830068 FUNCTION alt_az_to_equatorial - actual values: ra 6.05825076135398 - dec -0.2923727888350321 FUNCTION alt_az_to_equatorial - actual values: ra 0.15035517998866865 - dec -0.25484069778244123 FUNCTION alt_az_to_equatorial - actual values: ra 0.4378421902937326 - dec -0.22571091432518617 FUNCTION alt_az_to_equatorial - actual values: ra 0.6687224615932523 - dec -0.18638351681985768 FUNCTION alt_az_to_equatorial - actual values: ra 0.9406634036803876 - dec -0.18057505980703245 FUNCTION alt_az_to_equatorial - actual values: ra 1.3600532749398022 - dec -0.19879488006946985
Without moving the sensor it seems the values are somehow quite varying. Could the
return ra % (pi*2), dec
Not be needed as astropy is calculating the radians already? Or could all the math not really be necessary as astropy is handling it differently?
I've probably hit my limit on this, I'm lacking the basic astronomy side of the knowledge I think. The code is there if you do find some time to tinker.
It does sound like something is off - it was a long time ago now, but fighting with units sounds familiar. I wanted to use radians as the internal value (mathematician style), but the various protocols have their own expectations.
Could also be the module I am using. But at this stage I'm just spinning my wheels. I'm going to go play with astropy and python some more and hopefully understand all of it better to maybe try again.
OK I tried one more thing, I was getting OBS time as an object instead of simply a date time in UTC format. I tried that, let it run and it did after a bit start to slow down in terms of the Sky Safari perspective changing. But either the math is still wrong regardless of the obstime or the module is too sensitive?