I am using the indi-sv305 driver on both a pi3 and pi4 with good success. I am not using Ekos, rather just PHD2 for guiding, local Astrometry.net for plate solving and AstroDMx_Capture for imaging. No issues. I used sudo apt install indi-sv305 after first adding the ppa per the INDI instructions for the pi3, but had to download and compile from github for the pi4. The only compile issues I saw were warning error messages that were not important. Some C programmers will use variables in functions where the sizes don't match if they know the data in the variable will never exceed the limits in runtime. It is a tiny bit sloppy on the compile side, but causes no real runtime error.
Just FYI, I am very happy with the performance of the SV305 as a guide camera on a 240mm x 60mm guide scope binning 4X4. Nice, crispy stars that plate solve with local Astrometry.net in about 15 seconds and make PHD2 very happy.
Sometimes, if you have messed about a bit, your camera may end up on /dev/video1 or some other number besides video0. This can be caused by something else already on video0, restarting indiserver or some other operation involving video devices. Usually, a reboot will reset things and your first instance of the indiserver calling the indi_sv305_ccd will put it on /dev/video0. If that is not the case, then you might have to change the configuration or find whatever is grabbing /dev/video0 first and move it.
I haven't had any luck with indi_raspistill yet. It still barks on startup. Correct me if I am wrong (because it doesn't work with the HQ camera either), but indi_rpicam is for the original Pi camera, not the new HQ, correct?
AstroDMx_Capture was updated to version 0.78.3 yesterday to add support for the newly-repaired SVBONY305 SDK. There were problems in the initial release of the SVBONY305 SDK that plagued both the indi driver and...well...realistically anyone who was trying to support the camera. AstroDMx_Capture added support for the 305 for its PI 32 and 64 bit distros. They have supported the camera with INTEL/AMD 32 and 64 bit for sometime now. I use the 64bit AMD version under UBUNTU on my laptop with a SVBONY305 and have had good success. I do plan to begin using the Pi4 64-bit version now that it is available.
There is a thread on the development of the indi driver here: indilib.org/forum/wish-list/6373-indi-dr...html?start=120#58858 (that I see you have found, so this is for others seeking similar info).
The existing indi driver does work, but it has a few minor issues. One would hope the new working SDK will provide a means to correct those issues without a complete rewrite.
@wmarchewka: git checkout thx8411_sv305_2
Ah...apparently, I am not getting the right build candidate. I'll try again this weekend.
Still cannot compile for aarch64 (Pi4):
CMake Error at libsv305/CMakeLists.txt:40 (message):
Your architecture isn't suppored
Cannot compile for armfh (Pi3):
Apparently limited in CMakeLists.txt:
# Limit SVBONY to x86 architecture now
if (CMAKE_SYSTEM_PROCESSOR MATCHES "x86_64" OR CMAKE_SYSTEM_PROCESSOR MATCHES "i[3-6]86")
option(WITH_SV305 "Install SVBONY SV305 Camera Driver" On)
option(WITH_SV305 "Install SVBONY SV305 Camera Driver" Off)
Thank you. My setup is a stock SkyWatcher 250P Goto Dobsonian. I have a home-built waveshare HAT focuser and use the indi_skywatcherAltAzMount driver for the GOTO. Nothing special...lots of short exposure subs, stacking with Siril and finish in GIMP.
I will test with Pi3 and Pi4 this week.
I hope your wife recovers rapidly and wish you good luck and patience with your new-found avocation as a daycare venue.
Works pretty well on X86_64. I haven't had a good compile on arm64 or armhf yet. It is possible there has been some uploads I haven't been aware of yet.
Oh...by the way...from your previous iteration of the indi_sv305_ccd driver:
I had a "brain in the off position" error. My original testing was on an X86_54 Ubuntu laptop. It originally compiled there, and I had been testing with my guide scope on a tripod. The Skywatcher 250P is driven by a Pi4, now running the (beta) Raspbian verson for that machne as follows:
jon@piscope:~ $ uname -a
Linux piscope 5.4.51-v8+ #1326 SMP PREEMPT Fri Jul 17 10:58:13 BST 2020 aarch64 GNU/Linux
jon@piscope:~ $ lscpu
Byte Order: Little Endian
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Vendor ID: ARM
Model name: Cortex-A72
CPU max MHz: 1500.0000
CPU min MHz: 600.0000
Flags: fp asimd evtstrm crc32 cpuid
It would be nice to run it there, but not mandatory. I have started testing on the Laptop version, and it compiles without issue (again).
OK, I'm going to have to quit saying that I plan to use the scope on a "particular" evening. Yesterday afternoon, it was hot but cloudless, so I set the scope out in the shade to acclimate. By twilight, when I went out to collimate, massive thunderstorms moving in from the NW. Lightening everywhere. So, I packed it in. Somehow the weather KNOWS when I plan ahead.
I agree, best to repair one that nearly works than to "Frankenstein" a new one from bits and pieces of others. I wish I could be of some help. I can, and will of course, make the changes you suggest and recompile and test, but my abilities with C or C++ are very limited. I could probably emulate the driver in Java or even assembler, but that would be worse than useless.
Is there some way to do more logging to perhaps find what indi_skywatcherAltAzMount is locking up? And yes, I have see that business where it starts a severe drift at certain targets.."parts of the sky." I think the two things that I find most annoying are having to restart when it gives up moving the scope and when you Sync and it goes into that "drift into oblivion" mode that only another Goto can cure.
Trying again tonight....no PHD2, and maybe Ekos plate solving.
I'm still having problems. I did install a guide scope, but last evening, when I was try to align it, the indi_skywatcherAltAzMount driver would just stop working. It always went like this:
1. Goto target (close but no cigar).
2. Use either "hand controller simulator" or Indi Control Panel->Motion Control North/SouthEastWest to try and center the target.
3. Two or three adjustments and it just stops moving the scope. The only cure was a complete powerdown and restart. I had to go back to the indi_skywatcherAltAzSimple to complete my guider alignment.
Note that this was a fresh compile from a git yesterday morning running on the new 64 bit Raspberry Pi OS on a Pi4 aarch64. Last time, I was using Ubuntu Server aarch64 20.04, and didn't have this particular problem. But there were no errors in the compile. I also tried to get PHD2 to connect and the only INDI driver it liked was the indi_synscan_telescope driver. It "couldn't see" the other two drivers during the connect routine. Ekos, can, though.
I plan to try either Ekos or PHD2 plate solving as soon as I can get things stable again. While indi_skywatcherAltAzSimple has never given me any operational issues, its tracking is too wobbly for photos.
Hmmm....the dreaded "Your architecture isn't supported message from my Pi this time in the attempted compile of libsv305. This is the new aarch64 version of Raspbian (beta) on the Pi4. I think last time I used the Ubuntu Server 20.04 on the Pi.
What are you compiling on? (Nice shot of jupiter!)
Very nice Saturn! Nice area shot too!
That is a more astronomy-friendly area than around here. We are more "woodsy" and trees block the horizon at every compass point. I can't view anything below about 35 degrees, and that's from a second floor deck.
Does this mean your latest version is ready for me to try to break?
I tried using indi_skywatcherAltAz mount last evening, but "crashed and burned" (pilot-speak for failure). It drove the scope smoothly, but I couldn't hit a target on GOTO...close, but not close enough. Also, it wouldn't hold a target. Drift made it impossible to use. Sync seemed to have no effect. I get a feeling that using it with a guide scope, constantly correcting and holding position, is the ticket.
This may sound odd, but highly appropriate: We got frustrated and decided to use the Tablet with Synscan. In a navigation error (heading for the wrong fuzzy gray area after a near miss GOTO) trying for the Angelfish Cluster, we ended up at the "Dumbbell Nebula." Perhaps that is the default. If one fails to operate the scope properly, one ends up at the dumbbell.