just turned of phd2 and the speed of kstar is back to normal again. so fairly confident it is the link between phd2 and kstar causing the problem.
on the rpi4, which is where the phd2 is running on, things are smooth and responsive. so i donot think the rpi/phd 2 is the problem.
also just to reiterate, the it gets slow progressively, i.e. after restarting kstar, things will run smoothly for a couple of hours before grinding to a hault.
i run indiserver on my rpi4 and kstar on the desktop. the two communicate over wifi. the link usually is about 100 mbps.
I am having an odd issue with kstar for a while now. once kstar has been started, it seems to be using more and more cpu with time. after 3 hours it gets so sluggish that i have to close kstar and start a new instance. indiserver runs flawlessly. was wondering what the cause could be. guiding is done on phd2, however kstar is connected to the PHD2 and gets guiding updates for dithering purpose. so all it should be doing is sending an exposure request and poll it every second to update the timer.
does anyone know why i am having this issue. also does anyone know how to stop kstar from getting guiding frames - this is the only think that can be considered as intensive. maybe it could be moved to a different thread so that it does not slow down the gui or the connection between kstar and the indiserver.
Have you noticed that the frames there is 1 frame lag between when you capture using PHD2? i.e. the frame being presented by the driver after nth exposure is actually what was taken during the (n-1)th exposure?
I noticed it before after optimizing my mount to remove DE backlash the impact it has on calibration data is throwing off my guiding.
my experience with the SV305 has been poor as of late. it kept crashing whenever phd2 lost the star.
turns out it has some issue somewhere in the software and subframe. i am not entirely sure which software. but phd2 crashes whenever the guide star is lost. phd2 does not have subframe active. but according to gdb, whenever a star is lost, the frame received by phd2 is that of a smaller size equivalent to a subframe which makes it crash.
I think it is ekos trying to interfere somewhow. so i don't connect to phd2 from ekos anymore and all seems good.
if anyone has any idea why i am having this issue, please do let me know.
I have been having some issues with the stability of the SV305 with the device requiring power cycle. always on 12 - bit, never tried 8 - bit., and lately it was progressively getting worse with weird earthing issue and the rpi4 refusing to boot up when it is connected to the raspberry pi. turns out, the issue was the supplied usb cable. I had a spare cable and using that seemed to have sorted all problems for now.
thx8411 wrote: Hi,
I also own an iEQ30 Pro, and you don't need an ST4 camera for PEC record. Using serial pulses works nice for me.
I did many tests in "real conditions" (on Mars) these days. No more "Gain settings" issues. Pull Request on it's way...
Thanks again Sarwar.
Sorry to be so late. Clouds, clouds, clouds.... One month of clouds...
I'm waiting for an SV305 Pro sample from SVBony, in order to fix the driver.
Thanks for the fix. I noticed it as well and came over to report it, inly to find this thread
I'll try the new release.
I have noticed something else as well. I do not think it has been reported.
Not sure if I should open a new thread or just say it here, but i have noticed that after running a capture session for a few hours, kstar becomes very sluggish. The exposure times updates once every 10 seconds, progressively getting worse. Clicking something takes a minute for it to respond. Htop says that kstar has 100pc utilisation over one core. Not sure why. Only way out is to kill kstar and start it again. The problem does not reappear after that, but only when running kstar for the first time after a system reboot. I had similar experience every night since updating to the aug 2020 release.
I have kstar running on my desktop with 6c12t, 16 gb ram. Indiserver is running remotely in rpi4 running astroberry.
Yes. Smoothly guiding at .5-.7 rms.
I have a f3.4 scope and with 2x2 binning @ 1.5 sec, I get enough stars to plate solve.
Why not use pulse guiding, its better than st4.
Sorry to butt in.
but i did something similar last week and so started reading the thread. Interesting discussions.
Since you are using raspberry pi4, have you though about using astroberry-diy focuser? I have not used this module, but from what i can gather going over the code, if requires one to hook up a motor driver to the pi, and use the indi-astroberry-focuser to control it. This driver allows you to select which GPIOs the motor driver is connected to. so i imagine it is a matter of getting a DRV8834/DRV8834/A4988/A4988 and hocking up the cables properly.
I did it somewhat differently, in that I had the motor driver, drv8825 in my case, connected and fpga and connected that to the indi by using a indi_fpga_focuser derived from the above-mentioned indi module. Please see the screenshot.
"I should probably mention that I run Linux Ubuntu everywhere I can, including the Pi, laptop and desktops."
i wish more would ditch windows and apple for linux. it is so much better compared to 10/20 years ago.
thx8411 wrote: Hello,
Thanks for your help Sarwar. I didn't notice this behavior.
It's great !
I will look deeply at your patch and do some testing this week-end.
Does it work for all targets (amd64, arm, etc.) ?
yes, i have it running.
you would need to recompile the code. if you are unsure how to do it, i recommend doing it manually for the time being - till they update the indi repository.
Whilst the OEM is working on their SDK, this workaround may be useful to mitigate the issue:
dlwmacgregor wrote: Interesting.
I'm using a Raspberry Pi 4B with the latest release of Astroberry.
All other settings have no errors.
Yes. multiple power resets of both camera and Pi.
Probably best to wait until SVBONY replies to thx_8411.
Sarwar wrote: Gain control works just fine.. probably just needs a few millisecond of sleep. I say so because it happens only when the camera is connected for the first time, i.e. from a power cycle or powering it up for the first time.
diff --git a/indi-sv305/sv305_ccd.cpp b/indi-sv305/sv305_ccd.cpp index 457db530..fd51d4d9 100644 --- a/indi-sv305/sv305_ccd.cpp +++ b/indi-sv305/sv305_ccd.cpp @@ -340,6 +340,7 @@ bool Sv305CCD::Connect() pthread_mutex_unlock(&cameraID_mutex); return false; } + usleep(0.1 * 1e6); // get camera properties status = SVBGetCameraProperty(cameraID, &cameraProperty);