Ken Self replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 1 month ago

In ReadScopeStatus line 509:
else if(x>1 && y>1)
newTrackState = SCOPE_SLEWING;
should be
else if(x>1 || y>1)
newTrackState = SCOPE_SLEWING;

Read More...

Ken Self replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 1 month ago

here's my log from last night. You can see the solve at 21:42:28 then the mount slews. The motion state polled is m55 and when it returns to state m10 the next exposure is taken
One thing puzzles me. In your log at 20:50:19 there is a message: Avalon StarGo : "[INFO] Slew is complete. Tracking... "
My version of the code does not issue any such message
In the equivalent position in my log at 21:42:32.530 you see that message is not issued.
That message is in the version of ReadScopeStatus in stargo_work branch.

Read More...

Ken Self replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 1 month ago

Its odd that there are so few debug messages being logged. There should be a huge number of debug messages as each time the mount is polled (usually once per second) you should get at least 3 or 4 debug messages. These are the ones that indicate the motion state of the mount.

Read More...

Ken Self replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 2 months ago

Can you send me the debug log which has this behaviour?

Read More...

Ken Self replied to the topic 'Toupcam driver feedback' in the forum. 2 months ago

I've been playing around with Trigger mode for single images. Got it working (sort of) but I seem to have created a memory leak.

Read More...

Alfred thanked Ken Self in topic Improving guiding performance 2 months ago
Ken Self replied to the topic 'Improving guiding performance' in the forum. 2 months ago

Its a bit of a dark art. The aim of guiding is to correct the periodic error in RA and any drift on both axes. The problem is that it is obfuscated by the seeing which is broad spectrum. What you want to avoid is "chasing the seeing". This is basically when you correct for deviations in the guide star caused by seeing. It doesn't help your images because the seeing is not correlated across the field of view. So correcting seeing deviations on the guide star could lead to worse results on other parts of the image.
Adjusting the guiding parameters should be done mainly to differentiate between the long period mount and drift errors from the shorter period seeing.
Now lets say you can perfectly guide out all the drift and PE and your mount is otherwise free of issues like cable drag, sinking tripod, random vibrations, backlash etc.. What you see then on the guide graph is the seeing which can vary rapidly and randomly and cannot be guided out.
But of course no mount is perfect and you can get much better improvements from addressing those mechanical issues which are also difficult/impossible to guide out due to their randomness. For this you can use the guiding data to help diagnose your mechanical issues.

Read More...

Ken Self replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 2 months ago

I've added a fix for this issue. Had to remove the read wait so there is no timeout and also add a short delay between setting RA and Dec guide rates to prevent overunning StarGo.
It's now in the PR

Read More...

Ken Self replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 2 months ago

Looking at my notes it looks like X21nn and X20nn commands do not receive any response from the mount hence the timeout error. Minor change to the code to tell it to not expect a response but we should probably follow up with X22 to confirm the change was applied

Read More...

Ken Self replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 2 months ago

I wrote a simple Python app for testing the StarGo. It lets you send a command and reports the response. It puts in the leading ":" and trailing "#" on each command and has a Stop button in case the mount slews out of control. Also calculates LST for rough checking of mount position vs RA
You need to hard code the serial port. works (for me) on both Windows and Linux.
So you type in the command and click send then see what gets returned. Or you can type them into Minicom with the : and #
You should check these commands:
GR (get RA)
GVP (Get manufacturer - should be Avalon)
GVN (Get firmware version)
GVD (Get firmware date)
X38 (get park status)
X34 (Get motion status)
X590 (Get current RA and Dec)

The last 3 commands are made on every poll of the mount (typically every second) so are very important.
Your mount was not responding to these. It seems to have stopped responding after one of the handshake commands. Some of these handshake commands are "mystery" commands issued by the Windows StarGo application. So it could be they apply only to the M-Uno or a specific firmware version.

Another possibility is the timeout period might be too short. It is set at 2 seconds which should be plenty but who knows.

Read More...

Ken Self replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 2 months ago

Can you send the driver log file?

Read More...

Ken Self replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 2 months ago

You might want to look at my pull request as well. I've ironed out a lot of the issues with the driver and I've been using it successfully for several sessions now.
I didn't do anything with the joystick control but the latency issue should be resolved. One outstanding issue is that sometimes it seems to revert to pulse guiding with pulses timed in the code. But this does not appear to work at all and causes calibrations in PHD2 to fail. It is resolved by clicking the Use Pulse Guiding button even if it already shows pulse guiding enabled. I need some spare time to test it more thoroughly to confirm if StarGo responds at all to these commands and if not that section of code should be deprecated.

Read More...

Ken Self replied to the topic 'Plate solving giving wrong results' in the forum. 2 months ago

SOLVED!! (excuse the pun)
Altering the ANSVR config to return J2000 coordinates fixed the issue. I must have set it to JNOW once when messing around with SGP on Windows.

Read More...

Eric thanked Ken Self in topic Plate solving giving wrong results 2 months ago
Ken Self replied to the topic 'Plate solving giving wrong results' in the forum. 2 months ago

Looks like JNOW is an ANSVR config option which is why I couldn't find it in the astrometry.net API documentation. I'll see how to switch it off an hopefully then the solves will work.

Read More...

Ken Self replied to the topic 'Plate solving giving wrong results' in the forum. 2 months ago

TallFurryMan wrote: Looking at the log, it seems to me we're dealing with an API change here:

[2018-09-12T21:59:09...][     org.kde.kstars.ekos.align] - "{\"jobs\":[62],\"processing_finished\":\"1\",\"processing_started\":\"1\",\"user\":\"0\",\"user_images\":[]}"
[2018-09-12T21:59:09...][     org.kde.kstars.ekos.align] - "{\"status\":\"success\"}"
[2018-09-12T21:59:09...][     org.kde.kstars.ekos.align] - "{\"dec\":\"-14.816192073\",\"epoch\":\"JNow\",\"orientation\":97.5146272814133,\"parity\":1,\"pixscale\":1.96562592485983,\"ra\":\"296.199887826\",\"radius\":0}"

RA/DEC seem to be returned in JNow here.
-Eric

As far as I understand it, astrometry.net returns only J2000 coordinates. I've not found any option to return JNOW coordinates.
I tested again today on another target and Ekos consistently puts the target some 15' off centre in RA. I then switched to Astrotortilla using the same engine and it correctly centred the object.

What I suspect now is that the J2000 to JNOW conversion is being applied twice. Astrometry.net returns RA of 19h43m44s as J2000 which converts to JNOW of 19h44m48s which is the value in the log (296.199887826 degrees). A further J2000 to JNOW conversion is then applied to 19h44m48s which results in 19h45m50s as shown in the next part of the log. 1m of RA corresponds to 15 arcminutes which is the error I am seeing.

Read More...

Ken Self replied to the topic 'Re:Plate solving giving wrong results' in the forum. 2 months ago

TallFurryMan wrote: That may sound stupid and I do not suggest it could be the case in your test, but I need to mention that I had very weird results when I forgot to suspend guiding while plate-solving. Guiding corrections actually offset the mount model. PHD2 has an option to disable guiding while the mount slews, the internal guider does not.

-Eric

I was using PHD2 but guiding was off. I re-ran the platesolve under controlled conditions.

Read More...

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!