×

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

Bi-monthly release with minor bug fixes and improvements

skysensor2000PC -Error reading RA/DEC not in .logs

  • Posts: 56
  • Thank you received: 6
UPDATE - after another debug autoguide session - maybe found culprit/bug in SS2K driver - needs a check.

I still didn't get past a minute of good auto guiding but I noticed that the below mentioned .log entry artefact only applies to DEC guide adjustments.
Also noticed my guiding calibration seems to struggle with last step (DEC- South), so I'm thinking it might be linked to source of the repeated error *Error Reading RA/DEC*, since the log appears to report only hours and minutes in DEC (h:m:s in RA) and therefore cannot output in seconds of DEC. Indeed to test this I tried to force a guide to move to say DEC 80:30:25 and can confirm output in EKOS and INDI panels shows is h.m.00 only i.e. 80:30:00 and 80:31:00.

extract showing DEC value 87?44 i.e. no seconds but RA show h.m.s
2017-01-09T20:10:47: VAL [5.255]
2017-01-09T20:10:47: RES <05:15.3>
2017-01-09T20:10:47: CMD <#:GR#>
2017-01-09T20:10:46: VAL [87.7333]
2017-01-09T20:10:46: RES <+87�44>

Maybe somebody with better knowledge of logging and driver could check this?

Thanks
Andrew

original
My setup is as follows, I'm trying to debug to get first autoguide session:-

Client side LAN Ubuntu 16.10, linux 4.8.0-34
Kstar 2.7.2 Kstars-bleeding 5:16.12

Server wifi Raspberrypi 2 - Raspbian jessie 4.4.34 v7 with powered USB hub
Indi Library 1.3.1 (sudo indiserver -vvv indi_gphoto_ccd indi_sx_ccd indi_lx200ss2000p)
Orion Optics 200mm F/4 SN with GP-DX mount
Skysensor2000pc, serial/USB converter
Canon 60Da
Vixen 60mm F/7
Lodestar x2 autoguide cable into SS2k

This is a new setup, all works fine except autoguiding and the need to run indiserver as root to control the Canon.

I'm now debugging the autoguider. It's nearly working, 2-3" errors for 1 minute then aborted. Trying to rule out latency errors I'm trying Rapid Guide with autoguide cable between Lodestar and SS2K.

But my question is related to "Error Reading RA/DEC". It appears randomly in INDI control panel, sometime 2-3 per minute.

I attach .log but I only see errors in the INDI control panel, maybe it's hidden in log i.e. strange character in RES which also appears on client control panel as RES <+88�27> could this be the issue?

Once I manually Sync/Track the error appears much less i.e. every few minutes.

I don't think it's an important error at least not for autoguiding but can I resolve it?
My logs and INDI control panel shows UTC timestamp is that normal?

I'd welcome any assistance.
Hopefully then I can complete a first light session using this great piece of software.

Andrew.
Last edit: 7 years 2 months ago by Andrew. Reason: updated status.
7 years 2 months ago #13651
Attachments:

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

  • Posts: 105
  • Thank you received: 23
Hi,

Like any LX200 compatible device, the SS2000PC can use high or low precision coordinates. It looks like yours is set to low precision. This can be changed using the ':U#' command if I remember correctly.

The "Error Reading RA/DEC" messages occurs in the driver for another mount that I have been working tool. The ´funny´character you see in the declination value is a character code for a degree sign and is perfectly normal. In the case of the Pulsar driver I could eliminate the error messages by rewriting the code sending and receiving the LX200 commands.
7 years 2 months ago #13776

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

Even though I do not think the "low precision" format is the problem, I edited the code so that it tries to toggle to high precision format if possible. The Ekos Guide log would be more interesting in this case to know what's going on. Please enable Ekos logging for guide module next time you attempt it.
7 years 2 months ago #13786

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

  • Posts: 56
  • Thank you received: 6
Thanks camiel and jasem for feedback.
It's been windy but clear here so not ideal for tight guiding but I continued with some tests to rule out variables, here's an update.

I tried starting server with -vvv option and enabled verbose logging, it created client Ekos log and server log both attached following a kind of dummy session i.e. startup, track/sync to target, plate solve, guide calibration ending in guide fail. So then I did some guiding movements N,S,E,W to ty to check instructions are being followed.

On first read logs are a bit overwhelming but I guess they will mean more to you. I noted several things during session
a. On screen, I could see a high precision RA/DEC stream, like 12 decimals in the server SSH window
b. in the Ekos log at about 19:37 calibration fails (typical state)
c. but at 19:40 I got calibrated, but this soon loses track and fails after about 2 mins (typical)

So, after i tried adjusting guide variables without success. exposure, reticle, guiderate 0.5/1.33, rapid on/off, RA only etc etc - no success.
It seems in general from the logs that guide instructions are being sent and acted on. As I noted before when I do a simulated guide by manually hitting NSEW buttons I can see movement on screen (star moves), in client and server panels RA/DEC output moves and this is confirmed in the log. See around 23:32 guide south movement is shown albeit to low precision (but as you say this is just output not calcs which appear to be done on high precision):-

2017-01-16T23:32:29.605 - DEBG - SkySensor2000PC : "RES <-01�50> "
2017-01-16T23:32:29.628 - DEBG - SkySensor2000PC : "VAL [-1.83333] "
2017-01-16T23:32:30.612 - DEBG - SkySensor2000PC : "CMD <#:GR#> "
2017-01-16T23:32:30.686 - DEBG - SkySensor2000PC : "RES <05:40.7> "
2017-01-16T23:32:30.711 - DEBG - SkySensor2000PC : "VAL [5.67833] "
2017-01-16T23:32:30.740 - DEBG - SkySensor2000PC : "CMD <#:GD#> "
2017-01-16T23:32:30.777 - DEBG - SkySensor2000PC : "RES <-01�51> "
2017-01-16T23:32:30.802 - DEBG - SkySensor2000PC : "VAL [-1.85] "
2017-01-16T23:32:31.751 - DEBG - SkySensor2000PC : "CMD <#:GR#> "
2017-01-16T23:32:31.839 - DEBG - SkySensor2000PC : "RES <05:40.7> "
2017-01-16T23:32:31.863 - DEBG - SkySensor2000PC : "VAL [5.67833] "
2017-01-16T23:32:31.882 - DEBG - SkySensor2000PC : "CMD <#:GD#> "
2017-01-16T23:32:31.920 - DEBG - SkySensor2000PC : "RES <-01�51> "
2017-01-16T23:32:31.946 - DEBG - SkySensor2000PC : "VAL [-1.85] "
2017-01-16T23:32:32.921 - DEBG - SkySensor2000PC : "CMD <#:GR#> "
2017-01-16T23:32:33.029 - DEBG - SkySensor2000PC : "RES <05:40.7> "
2017-01-16T23:32:33.055 - DEBG - SkySensor2000PC : "VAL [5.67833] "
2017-01-16T23:32:33.082 - DEBG - SkySensor2000PC : "CMD <#:GD#> "
2017-01-16T23:32:33.107 - DEBG - SkySensor2000PC : "RES <-01�51> "
2017-01-16T23:32:33.128 - DEBG - SkySensor2000PC : "VAL [-1.85] "
2017-01-16T23:32:34.312 - DEBG - SkySensor2000PC : "<HaltMovement> "
2017-01-16T23:32:35.011 - DEBG - SkySensor2000PC : "CMD <:Qs#> "
2017-01-16T23:32:35.035 - DEBG - SkySensor2000PC : "Movement toward South halted. "

SO, assuming for now the guide algorithm is working correctly (can you check?) with my setup - I see about 1.3sec between capture and receive guide frame, the guide exposure being 1 sec. I decided to rule out any lag in the network and moved Ekos/indi onto the Pi/Ubuntu at the observatory and ran in local mode.

I also setup openPHDs on the server and ran that directly - I got calibration and guided for 2-3 mins, >4" errors which is to be expected windy, no PEC, no darks etc. It showed orthogonal axis error so I changed Skeysensor guide mode to X-Y (was RaDec) - was better.
I ran Ekos/indi and got calibrated , again 2 mins then lost guide. I ran out of time and didn't setup logs but it looks more promising.

I'll test the server/local setup correctly tonight, check everything and send the logs. Hopefully this will prove local setup working at least.

Aside from not getting guiding working the whole setup is working very well, impressive.
Andrew.
7 years 2 months ago #13906
Attachments:

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

I noticed there is an issue in Declination. is the declination drive working fine? No cable or anything that restricts its movement? Any mechanical issues?
7 years 2 months ago #13936

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

  • Posts: 56
  • Thank you received: 6
UPDATE 2 - sorry for lengthy post.

I've been working this debug on the Skysensor forum based on Jasem's feedback pointing to an equipment fault (dec motor). I've returned since the root cause again points towards the SS2k driver. Here's the outline logic why:-

I stripped the whole system down looking for electro-mechanic faults, checked each connector/contact, tested for breaks etc but no luck in finding the culprit. I took the motors apart, re-greased mount, adjusted the encoder nuts etc, switched motors but no obvious pointers like broken wires.

So with hope I put it all to the test again. Starting with Raspberry Pi with indiserver; goto, slew, track all fine. Calibrated guiding in indi, great, but lost guide each time at random point with West drift. I could restart guiding by stopping the West drift using the Centering buttons in the indi panel, but each new guide was broken by West drift.

Next I tried PHD on the pi with INDI drivers but with same failure mode.

Next I plugged the USB hub (Lodestar, Skysensor, Canon) into a laptop/ubuntu and ran the whole series of tests again INDI/EKOS first, then PHD and PHD providing guide frames to indi/ekos - same failures with west drfit killing the guide but otherwise everything working fine.

So two different softwares, two PC hardwares with same failure mode. In both setups I tried various software settings and also tried both the ST4 autoguide port and guide via skysensor. By this time I'd also ticked off some other failure candidates like the USB serial convertor (seems OK) and found from PHD logs that polar alignment was OK (sub-minute) but with a large dec backlash (whih could be adjusted).

As desperate last step went back to Windows system that worked for many years on the same laptop/usb hub using PHD/Ascom ss2k driver and BANG, first time calibration then several guide sessions of ~0.3 rms guiding over 10mins. I can just tell that the system is solid and working correctly and would guide all night. I also tested with Astroart both using ascom skysensor drivers.

For me the above seems to point to the indi ss2k driver, it is one item that changed that I can't cross test. I attach
a failed guide log from indi session and pose some questions:-

In log file I see each guide instuction to move (CMG <:M_#>) is followed by a halt (CMD <:Qw#>) :-
CMD <:Mw#>
.....
CMD <:Qw#>
but sometimes the "halt West" is missing and it seems to be associated with a dual-axis guide - see log_20:53:35 @ 2017-02-20T21:47:03.42 and shortly after this guiding is lost (West drift).

a. I guess this sequence is only required for Dec corrections but thought it worth cross checking, could it be source of my troubles, dual-axis guide?

b. What is the correct lodestar binning setting for lodestar when guiding, is it 2x2?
I wondered if somehow the image changed to hires or 1x1 thus causing a misreading of guide corrections.

c. As a test, would guiding in indi work with a LX200 driver?

Any further assistance to resolve this would be appreciated otherwise I'll have to return to the dreaded Windows and a laptop!

AB

PS I attached kstars log since it was easier for me to read let me know if you need a different log or more details.
7 years 1 month ago #14677
Attachments:

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

1. If you have Lodestar, why are you using LX200 to guide?!!
2. Yes optimal Lodestar binning 2x2
3. From log, you can see almost no motion from N/S commands, but good motion from W/E, this is why calibration failed when it tried declination.
7 years 1 month ago #14679

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

  • Posts: 56
  • Thank you received: 6
Thanks Jasem, to answer you question:-
1. Lodestar is the new component in this system so initially I tried direct autoguide via ST4 port but it failed and started this whole hunt. Actually I understood it was best to use drivers rather than ST4 autoguide , I got that from PHD best practice, do you recommend ST4 autoguide for indi/ekos? I've been using lx200ss2kpc driver and only asked about lx200 as possible way to test my setup and the lx200ss2kpc driver.

I'll correct my dec backlash by adjusting gears and try all tests again based on your feedback.
Andrew.
7 years 1 month ago #14701

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

ST4 is the recommended way to guide in ALL platforms as far as I know since you are not encumbered by serial port delays. Mount aka pulse guiding should only be used as a last resort.
7 years 1 month ago #14702

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

  • Posts: 472
  • Thank you received: 165
PHD2 best practices guide recommends pulse-guiding (openphdguiding.org/PHD2_BestPractices.pdf):
• Use ASCOM pulse-guiding instead of ST-4 guiding if mount supports it
• Get the benefits of one less cable and better logging/diagnostics

Serial port delays shouldn't really matter when doing multiple second guide exposures anyway. I've used both, now using pulse guiding to get rid of the extra cable, haven't noticed any particular difference otherwise.
7 years 1 month ago #14707

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

  • Posts: 105
  • Thank you received: 23
Hi,
I have used a setup of a ss2000pc and an SBIG camera for several years in the past. I've always used an ST4 cable between the camera and the ss2000pc. This worked without problems. I think that the pulse-guiding that is referred to in the openphd documentation is the kind that is build into the controller. The ss2000pc does not support pulse-guiding commands.
Best regards,
Camiel
7 years 1 month ago #14728

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

  • Posts: 56
  • Thank you received: 6
thanks everyone,

So if I understand the various inputs here :with my setup using the ss2kpc driver will not work since the controller doesn't accept the commands.The only option for guiding is to use the autoguide ST4 port. I'll try this again next clear night.

But why was a ssk2pc driver created if it cannot guide, what advantage does have over say a LX200 driver?

Andrew.
7 years 1 month ago #14745

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

Time to create page: 1.210 seconds