×

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

Bi-monthly release with minor bug fixes and improvements

Indiserver WiFi option for Synscan Goto?

  • Posts: 90
  • Thank you received: 12
Jon,

I don't really understínd what do you mean by "Java point and sync driver", can you elaborate it a litle bit more detail?

A few days ago I had a clear enough night to take some pictures, targeted M42. I've used my small Virtuoso mount with a SW50ED mini scope (250mm focal length), and the ASI178MC camera.
First I've followed the normal alignment procedures: solve&sync to different parts of the sky. Starting around Polaris (as always), solve one to the east, then gradually going to south (Orion is at the south meridian this time). At first the tracking was terrible, even 1 sec expoes had star trails.
Then I have disconnected EKOS and INDI and restarted the driver. After reconnect (thanks to the latest modification in the driver) it take on the correct position of the scope on the sky, Kstar has shown the scope just where it was before the driver restart (of course idle, not tracking now), so I just issued a goto (small movement, but start tracking) and done solve&sync. The sync issue come up at the second or third solve as usual, but I had M42 in the FOV enough, and this time I got rather good tracking. I was able to capture 20 sec exposures.
I started imaging with 20 sec expos. Some images were almost perfect, others not so good. After a while it started to drift in some direction leaving star trails. Sometimes it stopped or even reversed, drifting in the other way.
So I did a disconnect and restart again. The same result. All in all I was able to get 138 of 20 sec good enough pictures (before M42 went behind the house) with 3 or 4 restarts.
So it seems that only one solve&sync after a fresh driver restart gives better tracking than taking many all over the sky. It is not clear why it is so. In theory the tracking should be more and more precise after taking more and more syncs. But it does not appears to be so.
It is also unclear what causes a good tracking to start slowly drift in a random direction. But it seems the SoftPEC procedure as written on the Virtuoso driver page is not helping, the tracking is not precise enough to even make the measurement procedure written there (I did this imaging session with SoftPEC disabled).

By the way, during this session I used the EKOS mount control pad to put my target in the center of FOV (when the solve&sync was unable to do so), and it worked, no strange issues occured.
Actually the EKOS mount control pad uses the same method to control the driver as the joystic does. So don't expect the joystic to do any better job than the EKOS pad. These are exactly the same. It is just that sometimes the joystic is more convinient to use, especially during visual inspections. My advise is that don't spend on an expensive joystic, just by the cheapest game pad you can find. It will do the same as INDI does not take andvantage of the precisity of the joystic, it just basically use it as a 4 way hat switch.

Here is a bad one:


Here is a good one:


And here is the final stacked (corped) version:
3 years 2 months ago #66006
Attachments:

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

So why is the tracking terrible in this driver? it needs faster updates? smoother speed adjustments? or the problem is elsewhere?
3 years 2 months ago #66007

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

  • Posts: 90
  • Thank you received: 12
I wish I knew!
3 years 2 months ago #66008

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

  • Posts: 90
  • Thank you received: 12
Obviously tracking with Alt/Az is inheritelly much more complicated than tracking with EQ.
For an EQ mount you have polar alignment, and if it is right in theory you only need to rotate the RA axis at a correct speed, right?
For Alt/Az there is no equivalent thing. You have to have your mount level (Az axis vertical, and Alt axis horizontal) in the first place, but still the tracking software (be it the INDI driver or Synscan) still have to consider your exact position on the globe and the exact time. Any inprecisity in that would cause poor tracking.
So far I thought that the alignment procedure is for comensationg for these inperfectments. So by syncing to many stars it could deduce how much the Alt and the Az axis is inclined to the perfect direction (which is maybe the same as having an error in your geo location, I bet). I have a feeling that I could have read these estimated angle errrors from the driver somehow, but I cannot find it anywhere. All I see is that a sync operation adds an offset to the coordinates around the part of the sky it is made. But it will be not enough I'm afraid.
3 years 2 months ago #66009

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

  • Posts: 90
  • Thank you received: 12
And one more thing: all this misalignments does not explains the phenomea I have had last time (and many times before): after having a good tracking something goes wrong and starts to drift in a direction. The direction and drift speed seems to be random, and changing in time.
I think having the scope not perfectly level or otherwise badly aligned should cause a constant drift at a given target on the sky, at least for a while (which 'while' is measured rather in hours then minutes...)
No explanation.
3 years 2 months ago #66011

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

  • Posts: 215
  • Thank you received: 16
@knro:

I will try your suggestion of clearing the alignment model and report back. I too have experienced good and bad tracking nights. By the way, this also occurs with the indi_synscan_telescope driver and the SynScan App or HandUnit. One time all is perfect, the next it sinks away. No rhyme or reason.

@gubi:

First of all, AWESOME image!! I have exactly the same camera, but don't seem to have the same FOV. How is that possible? Do you have some kind of reducer?

I also had a good night of tracking. So much so, I had to turn guiding off, as it was over-correcting from a very stable track. I also landed on 20 seconds for a target exposure (very unusual to get tracking that good). I picked a dim target, then I got clouds and it went behind a tree (and the dog ate my homework). Someone told me that objects with "IC" prefixes means that you probably won't. (IC= I SEE) See attached.

Interesting that your startup is similar to mine, excepting that I start West instead of East after unpark. My target area is SW-SE due to obstructions (trees) and I have to setup in the front yard for North targets. Either way, I unpark, then Goto/Solve my way, step at a time, to my target area. Usually 3 or 4 stops from North to South.

I built a little quick and dirty Java indi client that does only two things (beyond connecting to indiserver). It will send Sync XML and Slew XML and receive the feedback. It is just easier for me to do something quick in Java. It isn't a program as much as chunks of code in NetBeans, but it more or less proved to me that the driver isn't malfunctioning in and of itself. There must be something lacking in the communication between the driver and the alignment module in Ekos. Some variable that is being looked at in Ekos that maybe does not exist or is not properly updated in the driver that Ekos relies upon. My little Java thing doesn't check anything. It just sends the commands and receives the feedback (no errors, by the way). It is meant just as a test for me. I fully intend to try Jasem's clearing process next.
3 years 2 months ago #66014
Attachments:

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

  • Posts: 215
  • Thank you received: 16
Oh...and a last gasp: When the tracking is very good, as it was last night, I =must= turn guiding off. It will over-correct otherwise. Oddly enough, I can get RMS rates in the ranges of .2 to .4 if there is a little drift, but when there is no drift, guiding can't keep its hands in its pockets and I end up with tiny circles made from the faint stars as it corrects around the center point.
3 years 2 months ago #66015

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

  • Posts: 90
  • Thank you received: 12
This horshead is by FAR better than the best I was ever able to make.

For the FOV: I used a small scope, 250mm focal length (not diameter, that is 50mm), so this is small magnification. But this camera has small pixel pitch, but relatively large sensor (as being 6 MP), so I get nearly the same FOV as I get with the large scope, and a DSLR.

Here is the same M42 from a year ago, with the large scope, and a Nikon D7000 DSLR, 106 times 4 sec expo (I cannot remember, but most probably it was tracked by the Synscan handcontroller):
3 years 2 months ago #66018
Attachments:

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

  • Posts: 215
  • Thank you received: 16
Gubi,

Hmmm., I think I like the new one best. The previous version is still better than mine ever was, though. Well done on both.

I really need to use darks and flats. Noise is a big part of my issue with good images. I also think I am using too much gain. What gain setting do you use with that camera?
3 years 2 months ago #66021

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

  • Posts: 90
  • Thank you received: 12
I don't think dark or flat helpson noise. Darks helps on hot pixels or other permanent sensor faults, but do not help on random noise. Flat helps on uneven field, which may help when you try to supress the noise floor, but not on the noise itself. These ones are made without dark or flat. The old one was ISO6400, the new one is gain 200. I think 200 is the max usable gain with this camera, as you can see the raw images are quite noisy. The only thing helps on noise is having many many pictures. 100 at minimum, but more is better. I usually make 200, but not all usable.
3 years 2 months ago #66025

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

  • Posts: 215
  • Thank you received: 16
I had been using 255 (the max auto-gain setting) with shorter exposures and getting a LOT of noise. I used 150 with the 20 second exposures to better effect. I agree that 200 is a good max number for that camera.

Star Tools manual "says" that they use Darks and Flats in their noise reduction algorithm. Siril agrees with you on the use of darks and flats. I haven't used them much up to now, but some folks swear they are priceless. Your image, however, proves the "data is king" rule.

I typically try for 200 subs. Often, I get that many, but with a good number of throw-aways. Rotation is also an issue, but I don't see myself ever bothering with a rotator. I just crop.
3 years 2 months ago #66054

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

  • Posts: 90
  • Thank you received: 12
Hmm, I can set gain up to 400, but at that gain it generates soo much noise, I don't it is usable, at least i would need several thousands of light framses to avarage that out.

Do not beleave in any "magical" algorithm that removes noise with dark or flat or anithing else. Dark is removed from every frame, right? No random noise (in the light frame) can be eliminated by removing a static "dark" frame! It can eliminate anything that is permanent on your sensor, such as hot pixels. But nothing that is random in nature. Similar storry with light frames. It can eliminate faults like pathces from dust on the sensor or vignetting, but not random noise.
I have experimented with dark and flat frames but i don't see that dramatic effect.

Rotation is an inevitable issue, I agree, and there are parts of the sky where it is more paiful (zenit) and there are parts where it is not so painful (lower part at the southern sky). I deal with it by crop. Just as with the migration during tracking. And as we anyways need to crop to the middle of the frame, vignetting is not as much an issue.
3 years 2 months ago #66063

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

Time to create page: 0.566 seconds