i can confirm this works. i also had to update jSerialComm-1.3.11.jar in ./lib/ to the latest version.
tested using 178MM, using a Rock 5b with an NVMe drive. i could get 30 fps capture rate at 30096x2080 resolution, which is the stated max at 14 bit with USBTraffic:100. but not very stable, but runs stably enough at 26 fps (USBTraffic 85).
I could not get the HiighSpeed/HardwareBin working properly on it though -- this is the 8-bit recording. i updated the asi drivers to the latest, no use.
Read More...
have we had a resolution to this. i am having the same problem with asi178mm, no issue with asi290mm. indi_asi_ccd 2.0, interface 6, asi driver 1,16,3.0
Read More...
quick update.
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.
Read More...
Hello
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.
Read More...
HI Thx8411
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.
Cheers
Read More...
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.
Read More...
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.
Read More...
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.
Best regards,
Blaise
Thanks. Glad I could help in the slightest way.
Yes the skies have been poor lately in oxfordshire as well. but did get some clear skies yesterday and the day before. And the camera did stop responding on both nights after some use. Not entirely sure. logs show time out to calls. Restarting driver/indiserver did not help - had to power cycle the camera. Not entirely sure if it is the hardware or the driver to be honest. It has been cold, but i donot suspect that was the case. Did you notice just timeouts to calls made by the driver?
Read More...
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.
Read More...
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.
@gingerbreadassassin
Why not use pulse guiding, its better than st4.
Read More...
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.
github.com/rkaczorek/astroberry-diy/
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.
github.com/rsarwar87/indi-3rdparty/tree/master/indi-fpgafocuser
github.com/rsarwar87/CmodA7-SkyTracker
PS:
"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.
Read More...
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.) ?
Best regards,
Blaise
Hi
No worries. I only tested it on arm7 and amd64. but the patch should not break the code for already supported targets.
It is on my list of things to do, but one thing that needs checking is if the patch introduces old frames (i.e. frame from n-1 shot, where n is the current shot number) being served. If that is the case, we need to also retrieve the frame when calling SVB_EXPOSURE.
Thanks
Read More...
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.
Read More...
@thx,
Whilst the OEM is working on their SDK, this workaround may be useful to mitigate the issue:
github.com/rsarwar87/indi-3rdparty/commi...1f23ab3f43b6fe2563f3
Read More...
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.
Okay i was able to reproduce your error:
there is what needs to work around the device done to get to the error (or in my case why i did not see the error)
1. connect to device.
2. capture a 1 second shot
3. change gain - now it will work.
see screenshot for confirmation. I took a picture between 16:01:15 and 16:01:25 - I suppress those logs in the source.
From briefly looking at it, the issue it seems is with INDI and not the SDK. I have expanded the log, and you can see that the value it is trying to assign is zero, which is an invalid entry. so it fails. however, once the first frame has been taken, it seems the correct value is being passed. strange indeed.
Read More...