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: www.indilib.org/forum/general/6576-pi4-u...erference.html#50509
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.
Read More...
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.
www.amazon.com/CanaKit-Raspberry-Power-S...-USB-C/dp/B07TYQRXTK
Read More...
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:
Read More...
Just calculate the predicted temperature drop from the weather forecast and schedule timed refocusing sessions accordingly and you should be fine.
Read More...
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?
Jo
Read More...
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.....
Read More...
That would match my experience. As I wrote, to me it seems it is architecture specific. I am using the same version of Ubuntu MATE on my miniPC (Zotac) and on my RPi4.
I also use x11vnc on both computers for connection. The installations are identical in virtually all respects.
Keyboard repeat works on the miniPC and I have the keyboard repeat issue ONLY on the Pi4.
I had it fixed once in MATE Tweak and repeat was working fine for the session, but it reverted after restart.
I simply have not felt like it was worth spending the time to figure out where in the configuration files this is determined and what I can do to make the change permanent, but if someone else knows, please let us know.
Read More...
Ha! That would solve it for me, since I am using x11vnc.
Where do I set that parameter in x11vnc?
Jo
Read More...
Don't know, I have to try it out. I suspect that sending the read/write data back and forth is what is filling up the journal.
I could also write a script that purges the journal every 10 min or so, but that would be a crutch.
There must be better solutions.
Read More...
What happens when you call ForceOverwrite by adding -f to the end of your ./install.sh command?
It may take out your entire installation, but then again, living dangerously makes life more interesting...
Read More...
Have the same problem with my independent Ubuntu MATE installation on the RPi4. It seems to be architecture specific. The next best thing to get around it is to hold down Ctrl while you use the left or right arrows and the cursor will jump for ~10 steps at a time. That nearly abolishes the issue for me.
Read More...
I agree, it does a fantastic job! But it is too resource intensive to be used on a Pi4 simultaneously with KStars. So image files residing on the Pi4 need either to be accessed through the network (which in my case caused the journal to fill up with 70 GB within a couple of hours and then the Pi4 froze), or one has to set up rsync on the Pi4 to mirror the image files in real time to a remote network drive.
That is probably what I am going to do, just haven't gotten around to it yet.
Read More...