Jump to content

Banner.jpg.b83b14cd4142fe10848741bb2a14c66b.jpg

SVBony 305 CCD First Impressions


Recommended Posts

I have a SVBony 105 and found it to be a reasonable CCD, especially for the price.  A bit hard to focus initially, but not horrible results overall.  So, I bought the 305.....

I run under Linux on my desktops, laptops and Raspberry Pi4, which runs the telescope.  USUALLY, Linux is pretty good about finding USB devices and setting them up without additional drivers.  The 105 was immediately recognized and automatically setup as a V4L device (Video for Linux). This makes a device more or less universally usable with almost any Linux image capture software.

This was NOT the case with the 305.  While Linux saw the USB connection, it could not recognize the device.  That's the bad news.  The good news is that the manufacturer is ahead of this and has a special Linux version of AstroDMx_Capture available for download that seems to be a fairly feature-rich piece of capture software.  Once installed (laptop, desktop and Pi), it works well with the 305 CCD and the image quality is far superior to the 105...as it should be.

This may mean, I suspect, that it will be a while before there is an INDI driver for the 305 CCD.  Also, any limitations found in the AstroDMx_Capture software will be limitations one will have to live with for lack of options.  Both the 105 and 305 come with a little disk full of Windows drivers and software for the two CCDs.  I do not run Windows and their application is beyond the scope of this discussion.

I will try to post some images from the 305...IF EVER IT STOPS RAINING IN NW GEORGIA!  I do take full responsibility for the terrible viewing conditions in my area.  It was never like this before I bought a decent telescope.

 

 

  • Like 4
Link to comment
Share on other sites

The 105 and 205 cameras are UVC as far as I'm aware and therefore probably are supported by indi_webcam.

To the best of my knowledge, the 305 is not.  I've discussed the possibility of an SDK with them and whilst they do talk about one being available for one particular capture application I think it's built-in and designed specifically for that purpose, so perhaps not really an SDK in the more widely understood sense.  In fact when I asked (a couple of weeks back) they suggested that I might define what functionality was required in a more generic SDK.  I've not had time to do that yet, but I imagine it would take a while for them to do properly anyhow.

James

Link to comment
Share on other sites

I would have to agree that what is currently working and available is a hard patch to a specific application (AstroDMx_Capture).  It has that sort of "let's change these parameters, add this bit and recompile to get it out there" feel.  I'd love to get my hands on a SDK for that camera. 

I spent 30 years as a utility programmer, writing all sorts of equipment automation and automated network "stuff."  Now I am retired, and feel that I might enjoy writing some things from time to time once I get my level of understanding of all the fiddly bits relating to telescopes up to an appropriate level.  The Arduino and Pi motor controller bit is straight-forward enough, and I've done a lot with audio, but not so much video other than some streaming web setups.

Edited by JonCarleton
Link to comment
Share on other sites

3 hours ago, Cornelius Varley said:

Just to correct you on a technical point. Neither camera ]has a CCD (Charged Coupled Device) sensor. Both use a CMOS (Complementary Metal Oxide Semiconductor) sensor.

Ah, absolutely right!  I should have remembered this, as I had to clean a bug off the sensor on the 105 when I received it.  I saw then that it was a CMOS sensor.  Perhaps I've been watching too many videos about USB cameras with CCD's and my mind got stuck.  I claim newbie-ism as a defense!

Edited by JonCarleton
Link to comment
Share on other sites

To be honest you don't really need to do much that's particularly clever with video as it comes off astro cameras.  Mostly it's a case of reassembling a group of USB transfer buffers into a single blob that represents the frame data and either pushing it to a callback provided by the application or sticking it in a ring buffer until it is requested.  That needs to be interleaved with sending a few control messages to change camera settings etc. and you're pretty much done.  There can be a bit more complexity if the driver is responsible for timing the exposure, but even that isn't too hard.

James

Link to comment
Share on other sites

Good!  I've been playing with the motor controls on focus and pointing.  Once I get comfortable with that, I suppose video is next.  Although, there seems to be more of a need for someone to clean up post-processing in Linux than image capture presently...SV305 excepted.  And I say this, having only done a cursory skimming of the software out there currently available.  There seem to be a lot of individual, single-job post-processing utilities that people may script together, but nobody seems to have combined them into a package as has been done in the Windows arena.  

Link to comment
Share on other sites

Image capture does seem to be getting better coverage these days, certainly.  When I started on oacapture there was very little that worked across a range of the newer cameras, and even less that was open source.  Compiling a list of what's available for capture and processing might be quite useful to illustrate where the gaps are.  Perhaps Radek has done something like that for Astroberry.

James

Link to comment
Share on other sites

IMO  =Its pretty simple 

If there is a SDK for the range and is popular then Indi has a driver.

Hence ZWO and QHY range of camera's are well catered for -  plus GPhoto2 for DSLR's plus many other camera's.  OK specific versions may not be specified - especially the very newly released one or very old versions.

I would say DSLR's are the ones missing out as GPHOTO is backward engineered for Canon ,Sony etc - Although I read Sony are releasing a SDK for some of their camera's and hope to incorparate many more - just need others to follow I guess.

List of ones supported are here https://www.indilib.org/devices/cameras.html

Post-processing software - depends what you want but GIMP is a large free well used image processor. Plus of course you can use your images on other O/S !

Then there is Indigo which if you have a Apple "XYZ" uses some very good non free bits of software very familiar to many e.g. PIXINSIGHT https://pixinsight.com/examples/index.html .                 http://indigo-astronomy.org and http://www.cloudmakers.eu

Link to comment
Share on other sites

I am a GIMP fan, but I have to say that the words "Pain and Suffering" come into play with the stacking process in GIMP.  Oh yes, GIMP supports it, but stacking is a VERY manual process with many complex steps in GIMP.  Currently, I am using RegiStax6 under wine (Windoze emulator) and final touch-up with GIMP native Linux.  Much less effort.

Edited by JonCarleton
Link to comment
Share on other sites

We =finally= got a decent night that wasn't below freezing or raining or socked-in with clouds.  Of course, it was a full moon (nearly), so that limited things a bit, but I was able to try the SV305.  Overall, I am very pleased with the camera.  It is, as advertised, a major upgrade to the SV105 I originally purchased.  I'll post some images once I get up to speed on the software.

UNFORTUNATELY, one is limited to AstroDMx_Capture for imaging as the only software currently supporting the SV305.  The SV105 was a V4L-compatible camera and worked with just about any software.  More unfortunate than that, there is no version of AstroDMx_Capture able to run on a Pi that supports the SV305.  There -is- a Pi version (32 bit) of AstroDMx_Capture that supports all sorts of cameras EXCEPT the SV305.  Apparently, the support for the SV305 is only available in the 64 bit versions of AstroDMx_Capture, and there is yet to be a Pi 64 bit version of the software.  Since I use a Pi4 as a telescope focus and pointing controller via INDI, this is fairly tedious and annoying.  It means running one USB cable I was hoping to avoid.

Link to comment
Share on other sites

I corresponded with the folks at AstroDMx_Capture recently.  They are very actively developing the platform, and if Svbony cooperates, may have a Pi version working with the SV305 sooner than later.  It is, at the very least, not a dead issue.  They also mentioned future INDI hooks, so perhaps that is a software package to watch.  I liked the user interface and it worked well with the X64 AMD-based Linux laptop I used with the SV305.

I don't know what's wrong with Canonical.  They just can't seem to get something going with the Raspberry Pi4.  Their solution so far is to install X64 Ubuntu Server, then add a desktop after a complete server install with all the junk you really don't want running in background.  I tried it.  A very inelegant and ultimately unstable solution.  It is a shame to have to run a 32 bit OS (eg: Raspbian) on a 64 bit platform for the sake of stability.

Edited by JonCarleton
Link to comment
Share on other sites

10 hours ago, JonCarleton said:

I corresponded with the folks at AstroDMx_Capture recently.  They are very actively developing the platform, and if Svbony cooperates, may have a Pi version working with the SV305 sooner than later.  It is, at the very least, not a dead issue.  They also mentioned future INDI hooks, so perhaps that is a software package to watch.  I liked the user interface and it worked well with the X64 AMD-based Linux laptop I used with the SV305.

I've also exchanged some emails with SVBONY now suggesting what functionality needs to be provided by a proper SDK.

10 hours ago, JonCarleton said:

I don't know what's wrong with Canoical.  They just can't seem to get something going with the Raspberry Pi4.  Their solution so far is to install X64 Ubuntu Server, then add a desktop after a complete server install with all the junk you really don't want running in background.  I tried it.  A very inelegant and ultimately unstable solution.  It is a shame to have to run a 32 bit OS (eg: Raspbian) on a 64 bit platform for the sake of stability.

I wonder if they think 64-bit ARM work on the RPi  doesn't have the market to be worth the time at the moment.

James

Link to comment
Share on other sites

On 13/03/2020 at 07:28, JamesF said:

I've also exchanged some emails with SVBONY now suggesting what functionality needs to be provided by a proper SDK.

I wonder if they think 64-bit ARM work on the RPi  doesn't have the market to be worth the time at the moment.

James

No, there is enough chatter and complaint in the forums for Canonical to know that their X64 Ubuntu Mate product is "down" with respect to the Pi4 and the only option for the Pi4 in X64  mode is Ubuntu Server.  There was originally a problem with even that running, and Canonical fixed it after a user pointed out the specific issue and a recommended fix.  It will run Ubuntu Server in X64 mode, but it gets wonky when you try to add a desktop on top of Server.  The key, as far as the SV305 is concerned is for Svbony to provide/release a 32 bit SDK for the camera, then it will at least run in Raspbian.  It is unclear presently whether the X64 version of AstroDMx_Capture will run in a ARM X64 environment, even if there was a stable instance available.  A X64 ARM version of the software has not been released.

Link to comment
Share on other sites

  • 1 month later...
On 14/03/2020 at 14:51, JonCarleton said:

No, there is enough chatter and complaint in the forums for Canonical to know that their X64 Ubuntu Mate product is "down" with respect to the Pi4 and the only option for the Pi4 in X64  mode is Ubuntu Server.  There was originally a problem with even that running, and Canonical fixed it after a user pointed out the specific issue and a recommended fix.  It will run Ubuntu Server in X64 mode, but it gets wonky when you try to add a desktop on top of Server.  The key, as far as the SV305 is concerned is for Svbony to provide/release a 32 bit SDK for the camera, then it will at least run in Raspbian.  It is unclear presently whether the X64 version of AstroDMx_Capture will run in a ARM X64 environment, even if there was a stable instance available.  A X64 ARM version of the software has not been released.

Hi @JonCarleton I too took a punt with the SV305 and have been using with it under Windows via Sharpcap and been impressed with its imaging ability but like you also have a Pi4 currently running  KStars/EKOS PHD I hoped I may somehow be able to use the SV305 in. Did you ever make any progress?

Link to comment
Share on other sites

I only use linux.  Currently, I use AstroDMx_Capture on an Linux Ubuntu laptop with a LONG USB cable out to the scope.  The Pi4 runs raspian currently and is the indiserver that runs telescope control (SynScan) and focus (Waveshare HAT focuser). with ind/Ekos/Kstars.  So far, I have only heard that there is progress coming from the author of AstroDMx_Capture and SVBONY, but the date of a fix isn't set in stone yet.

What I think we are looking for is some 32bit version of AstroDMx_Capture that will run in Raspbian OR some integration with indi by either SVBONY or AstroDMx_Capture.  I have a version of 64bit Ubuntu working on my Pi4B, but I haven't tested it yet with the 64bit AstroDMx_Capture and SBVONY305, as I expect the new release this week (today=2020-05-07).

 

  • Thanks 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.