Jose Corazon replied to the topic 'Dubious drift graphics' in the forum. 5 days ago

Installed and looks like it is now remembering and restoring the last used exposure time.

Thanks Jasem!


Jose Corazon replied to the topic 'Dubious drift graphics' in the forum. 6 days ago

hy wrote: Jo, If I'm not mistaken, I think you can save the exposure times for different filters in the filter settings control that pops up from a button near the top of the capture tab, and it's also accessible on the filter tab, just to the right of the filter menu. The 2nd column is exposure time in seconds.

Thanks Hy!
Yes, I know that option and it works fine for a monochrome camera with a filter wheel. No problem there and I have the times set accordingly. But I do not see that option when I am using a one shot color camera, like the ASI1600MC or the ASI183MC. In those cases the filter settings option is greyed out and I cannot change the default 0.5s value. I forgot to mention that I was referring to narrowband filters when using a color camera. That also and most commonly applies to filters like the Optolong L-eNhance or a Tri-Band or Quad-Band filter, which are commonly used with OSC cameras.


Jose Corazon replied to the topic 'Dubious drift graphics' in the forum. 6 days ago

While we're at it, I had figured out how to save the binning in the guide module, but I am still at a loss how to save the default exposure time in the focus module. That exposure time will always default back to 0.5 s and when you forget changing that, it will not result in a satisfactory autofocus run when using a narrowband filter.
Can that also be set so it remembers the last preferred exposure time? 0.5 s is too short for most purposes, 2s at least makes more sense.
Thanks for thinking about it.


dmsummers wrote: @rishigarrod: Just popping prior post on issues between USB3 and Wifi at 2.4Ghz. It's not clear whether you're using the Pi4's USB3 ports, and you didn't say whether your wireless is using 2.4Ghz. If yes to both, it's most likely that you are experiencing RF interference. This has nothing to do with SM 1.5. It's solely a function of Pi4's USB3 close proximity to the internal wifi antenna. See this prior post for details and workable solutions:
FWIW, after adding a direct ethernet cable from laptop to Pi4 (lured by speed improvement), I'd never go back to wireless now unless it was an absolute emergency ! Clear skies...

p.s. For Jo, I'll note that although power supply can be a problem (lots of prior posts on poor power issues), when it's Pi4, USB3, and wifi at 2.4Ghz, it's almost certain to be RF interference (and NOT power). Similar symptoms though, so it can be very confusing. Folks need to take note as they migrate to Pi4 with USB3 since 2.4Ghz wireless is everywhere, and people don't necessarily think to take action to switch over to 5Ghz.

Thanks, Doug! I had forgotten about the WiFi interference problem. Never had it, since it felt natural to connect via 5 GHz only. 2.4 GHz WiFi is just too slow. About 6 times slower.
Anyway, just to let everyone know not to give up on the internal WiFi of the Pi4. It works great on 5 GHz and it is not weak at all.


rishigarrod wrote: Last night I had to position my mount slightly further away from the house which meant that my wifi connection from my laptop running Kstars and INDI on the Pi was not strong.
I lost connection a few times and focussing was impossible (too long required for the download).

I had an old Airport Express (mini router/Access point) which I have now connected directly to the Pi with a cable. Seems to have solved my wireless woes.
I think the Pi wireless access point is very weak and only really seems to work if you are within a couple of metres.

That honestly baffles me. I imaged again last night and my rig is ~60ft away from the WiFi extender I am using for coverage in my backyard. So definitely not ideal conditions, with distance, extender and all.
Nonetheless, the INTERNAL 5GHz WiFi of the Pi4 never had any trouble whatsoever with that constellation.
I get consistent connection speeds of ~ 390 Mbs, which makes for a very snappy response via VNC. I am running KStars on the Pi4 directly.
I can only wonder whether the poor connection many people here are describing is the result of either a subpar power supply that cannot pull the Amps the Pi4 needs to run at full speed, or whether it is somehow related to the OS. I am using Ubuntu 18.04 as my OS on the Pi4.
Maybe the key is the power supply. I am using the one that came with the Canakit when I originally ordered the Pi4. Rated to 3.5 Amps.


Jose Corazon replied to the topic 'For those with focus issues' in the forum. 2 weeks ago

universalmaster wrote: Thanks for the reply.

The (1) dot is what I would call close to focus. HFR ~1.7 and "perfect" focus may be like 1.3-ish.

There is no backlash compensation in FCUSB, as far as I know, do it should be off.

There is a "reverse direction" switch in the FCUSB tab. Could that mess with the algorithm? (maybe the motor is always turning the wrong way?)

The more stars the better in the image, when using full field?

I'll try again and report back. Thanks for making this happen in the first place :-)

I have attached an image of NGC 3793 and its friend, to show that it is not "all work and no play". I feel that everything is continuously improving at the moment :-)

That is a beautiful picture, Soren!

Regarding the FCUSB and the AccuFocuser/analog DC motor focuser: I basically use the same system, although the motors I just got from Amazon for $15, so cheaper than the (now discontinued) AccuFocuser system.
It works beautifully in my hands, but there are a few things to consider.
I think the main issues you are facing results from the differential load on the motor due to the weight of the camera/filter wheel. That means the motor will move faster in the outward direction than the inward direction.
But that can easily be fixed. This is the way how I did it:

1) Note the position on the focus tube where your telescope is in focus.
2) Then attach a rubber band or a string with a spring to the telescope and the other end to the focuser tube.

3) Next, you move the telescope into a 60 degree vertical position, so that you have average gravity force pulling on the tube.
4) Loosen the clutch screw, so that the tube now moves freely
5) Add or remove rubber bands until the tube is in equilibrium at the focus point, i.e. it neither is being pulled inside by too much force from the rubber bands and neither does it slide out.

That pretty much equalizes the force the motor has to work against when moving the tube inwards and outwards and now the timed movements will be approximately equal. That will dramatically improve the ability of any of the algorithms to find focus. Basically, the principle is no different from balancing the mount. You want to minimize the strain on the motors there as well.

A couple of other things that I find important:

1) Do not make the steps the motor moves too small. If they are smaller than the variability of the HFR, the algorithm will have trouble calculating the V-curve.
2) Hy suggests using SEP, which is definitely better than the Gradient algorithm you are using. However, for some reason I find that the Centroid Algorithm works best for me, closely followed by SEP.
3) I just use Full Field, without Autostar.

Unless there was a change in the code recently that may have caused these problems, this methods works beautifully for me. Here another screenshot showing the quality of the V curve using Hy's Linear algorithm:


Jose Corazon replied to the topic 'ZWO EAF' in the forum. 2 weeks ago

Just calculate the predicted temperature drop from the weather forecast and schedule timed refocusing sessions accordingly and you should be fine.


Jose Corazon replied to the topic 'Aborting PHD2 guiding during autofocus' in the forum. 2 weeks ago

Doesn't the focus module automatically suspend guiding when it is being called?
At least that is what always happens when I am using the autofocuser.
What am I missing here?


Jose Corazon replied to the topic 'Ubuntu MATE now works on Raspberry Pi4' in the forum. 2 weeks ago

I am not sure whether there is really anything substantially different between the official Ubuntu MATE support now and the prior install from the server and sequential updates. I suspect the outcome is pretty much the same.
I did it the old fashioned way, starting from the server and sequentially building up the system and my system is also quite stable now. No reason for me to switch that I can see.
But I am looking forward to hearing the experience others might have.

Of course, by now the official Ubuntu system is 20.04.....