×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Daft RA/Dec/Position Info In Kstars/Ekos

  • Posts: 60
  • Thank you received: 7
I'm getting some really daft figures and displays in my Kstars/Ekos:
Config: Mac Kstars/Ekos talking to IndiServer on RPI3 driving iEQ45 Pro mount.

Bsed in UK, used KStars to slew to Polaris and is sent the mount to point in the right direction and Indi Control Panel shows
2017-07-10T15:17:27: Slew complete, tracking... 
2017-07-10T15:17:18: Slewing to RA:  2:53:43 - DEC: 89:19:57

Yet Kstars shows the telescope pointing below the horizon (see attached screen capture), the Ekos panel shows a declination of 5965 deg and AL a bit wrong (see attached screen shot)

Sorry to be a nuisance with all there questions (guess I've just got to find the right button to press)

n.b. I've posted t this section as, if I try using Kstars/Ekos version on Ubuntu I get the same results). If it's any help I've added a verbose log for a slew (not the one from the screen shots but a slew to Polaris from a short distance away)




2017-07-10T15:44:04: Slew complete, tracking... 
2017-07-10T15:44:04: RES (110521#) 
2017-07-10T15:44:04: CMD (:GAS#) 
2017-07-10T15:44:03: RES (+3215970411587540#) 
2017-07-10T15:44:03: CMD (:GEC#) 
2017-07-10T15:44:03: RES (120521#) 
2017-07-10T15:44:03: CMD (:GAS#) 
2017-07-10T15:44:02: RES (+3215970413027010#) 
2017-07-10T15:44:02: CMD (:GEC#) 
2017-07-10T15:44:02: RES (120521#) 
2017-07-10T15:44:01: CMD (:GAS#) 
2017-07-10T15:44:00: RES (+3215970414466350#) 
2017-07-10T15:44:00: CMD (:GEC#) 
2017-07-10T15:44:00: RES (120521#) 
2017-07-10T15:44:00: CMD (:GAS#) 
2017-07-10T15:43:59: RES (+3215970415905770#) 
2017-07-10T15:43:59: CMD (:GEC#) 
2017-07-10T15:43:59: RES (120521#) 
2017-07-10T15:43:59: CMD (:GAS#) 
2017-07-10T15:43:58: RES (+3215970417345170#) 
2017-07-10T15:43:58: CMD (:GEC#) 
2017-07-10T15:43:58: RES (120521#) 
2017-07-10T15:43:58: CMD (:GAS#) 
2017-07-10T15:43:57: RES (+3225738218784580#) 
2017-07-10T15:43:57: CMD (:GEC#) 
2017-07-10T15:43:57: RES (120521#) 
2017-07-10T15:43:57: CMD (:GAS#) 
2017-07-10T15:43:56: RES (+3117815262801070#) 
2017-07-10T15:43:56: CMD (:GEC#) 
2017-07-10T15:43:56: RES (120521#) 
2017-07-10T15:43:56: CMD (:GAS#) 
2017-07-10T15:43:55: Slewing to RA:  2:53:43 - DEC: 89:19:57
Last edit: 6 years 8 months ago by Ian. Reason: Typo correction
6 years 8 months ago #17765
Attachments:

Please Log in or Create an account to join the conversation.

I saw the exact same problem 2 days ago with a friend of mine. I logged to his RPI3 to investigate and then compiled INDI from source so I can debug the problem, but then all the issues disappeared. So it looks like some build issue. Could you compile INDI on your system to confirm this?
6 years 8 months ago #17767

Please Log in or Create an account to join the conversation.

  • Posts: 60
  • Thank you received: 7
That might be stretching my technical abilities. Done a lot of C/C++ but all Windows/Mac in relevant SDKs (not much command line stuff and none Linux beyond copying commands to load/install). Not even sure what tools are included (it's UbuntuMate RPi not Raspbian).

Was the issue you saw with an iEQ45 Pro mount ?
6 years 8 months ago #17769

Please Log in or Create an account to join the conversation.

  • Posts: 60
  • Thank you received: 7
No idea if it's relevant but on checking something else briefly I noted an additional bad display in the Indi control Panel (related to the same figure)

I notice that this dialog has "Set" options for the RA and Dec. I'm not sure how these might affect things so I've not tried setting them (possibley confusing the issues)? Also if setting them might introduce other inaccuracies elsewhere. And I don't understand have a "set" value would be used by the system.
6 years 8 months ago #17772
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 60
  • Thank you received: 7
Managed a re-build of the basic Indilib (i.e. I've had to remove the SkySafari middleware from my profile as I've not re-built that). Unsure of previous version (installed using apt around 6 July and when I checked the date on initial indiserver executable it was 6 July 2017), but I downloaded and built source 1.4.1

Results are different but not right.
(Sorry about the big pics but they explain better than my text would)
Start at Polaris


Using Kstars, right click on Kocab and select slew (to it) and Kstars moves telescope cursor almost exactly in the wrong direction


Details after slew to Kocab completed


So this time it's the RA that is wrong.

Interestingly I then slewed back to Polaris (right click on Polaris in Kstars and select iEQ45 Pro->Slew) and Kstars shows the telescope crosshairs in the correct position but again, RA wrong.


I'm confident it's the new version as I checked the indiserver in /usr/bin (date and time) before I started, then checked again after re-bulid and

as well as it took me some time to get it to start (because I eventually established I had not re-built the SaySafari middle ware/driver and so that was an old version yet was being started by my profile - until I removed it and then all started fine).

Testing profile is iEQ45 Pro, CCD Simulator.

I did get a couple of warnings in the build but they were not relevant
/home/phobos/libindi/tools/compiler.c: In function ‘execute’:
/home/phobos/libindi/tools/compiler.c:635:34: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘int’ [-Wformat=]
         (void) sprintf (err_msg, "Bug! stack has %ld items",
I thought not relevant - human readable message
and
/home/phobos/libindi/drivers/focuser/nfocus.cpp: In member function ‘int NFocus::SendCommand(char*)’:
/home/phobos/libindi/drivers/focuser/nfocus.cpp:269:58: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘size_t {aka unsigned int}[-Wformat=]
    fprintf(stderr, "strlen(rf_cmd) %ld\n", strlen(rf_cmd)) ;
not relevant to me as I'm not using any focuser
Last edit: 6 years 8 months ago by Ian. Reason: iEQ45 - I meant iEQ45 Pro (corrected in post)
6 years 8 months ago #17809

Please Log in or Create an account to join the conversation.

Thanks for the details info, I'm going to login to a friend's system who has IEQ45 Pro as well and will check this problem out. If I can't resolve it there, please install TeamViewer at your end and we'll schedule a session so I can check the problem first hand.
6 years 8 months ago #17823

Please Log in or Create an account to join the conversation.

  • Posts: 60
  • Thank you received: 7
Fine, only thing is my internet speed Down 7,645 Kbps, Up 1,103 Kbps (called UK ADSL!). Let me know if the speed will be practical and if you want me to install TeamViewer (I've no experience of TeamViewer).

Unsure of current status but I seem to remember RPi's were mostly 32 bit (64 bit capable but OS's only 32 bit) so, if that is the case might it be a 32/64 bit issue ?

I checked the messages from the iEQ (decoded the position manually) and that looks good. Looked through the iEQ source decoding the position and that looks good though tracing the code back through the processing of that position and I get a bit lost without knowing the architecture.

Tested iEQ5 Pro directly connected to my Mac (Mac KStars version) and it's fine - so something about the RPi.
6 years 8 months ago #17826

Please Log in or Create an account to join the conversation.

  • Posts: 60
  • Thank you received: 7
Had a thought though no time to test it and I'm a bit rusty on some C/C++ lib functions but, strncpy where source is longer than the max chars to copy will not add a null terminator (from my possibly flawed memory). So, at line 1900 & 1901 in ieqprodriver.cpp (in function bool get_ieqpro_coords(int fd, double *ra, double *dec) where the text response from the mount is decoded, for both
strncpy(dec_str, response, 9);
strncpy(ra_str, response+9, 8);
 
int ieqDEC = atoi(dec_str);
int ieqRA  = atoi(ra_str);

where the driver responds "+321587041187540#” (response) (fixed format starting +, ending #)

the destination strings will not be null terminated so what the then immediately following atoi(dec_str); and atoi(ra_str); return will depend on what happened to be in the memory (or on the stack) allocated to dec_str and ra_str.
e.g. suppose lying in the free stack was qwerty123456789\0 in the area that then happens to get used as dec_str; then the strncpy(dec_str, response, 9); copies char 0-8 from +321587041187540# (the string returned from the iEQ) which would make dec_str[]=“+32158704456789\0” which would not be the correct vale (it should be dec_str=“+32158704”; but the previous data lying around and without a null string terminator being added by strncpy …

But the above is based on my probably flawed memory, but it would explain the inconsistent behaviour with different builds and actually could also be an issue on any systems (though I didn’t see it on my Mac, a lot would depend on what the application startup does initialising memory/stack and what happens to be on the stack) and it has just happened to emerge on the RPi and might explain why I initially saw the issue on the Dec and after building 1.4.1 say it on the RA.

Quite busy at the moment but if you think this might be the issue let me know and I’ll test a.s.a.p.
The following user(s) said Thank You: Jasem Mutlaq
6 years 8 months ago #17841

Please Log in or Create an account to join the conversation.

Can you try changing line 1883 to this:
char ra_str[16]= {0}, dec_str[16] = {0};

and recompile, does it make any difference?
6 years 8 months ago #17842

Please Log in or Create an account to join the conversation.

  • Posts: 60
  • Thank you received: 7
Just to "close-off" this thread (and after some PM correspondence), issue was in iEQ Pro drivers and could have affected all platforms but was only observed on RPi.

Source updated and issue appears fixed (unsure of release schedule for built releases)
6 years 8 months ago #17986

Please Log in or Create an account to join the conversation.

Time to create page: 1.347 seconds