Omegon veTEC 571 Camera

dtiazlovas
Posts: 7
Joined: Sat Aug 13, 2022 11:51 am

Omegon veTEC 571 Camera

#1

Post by dtiazlovas »

Hello,

I'm very new to this forum but after upgrading from my ZWO533 to the Omegon 571C camera I've noticed a few issues using it in SharpCap and perhaps someone can help. Now it's hard to say which problems are due to the drivers or because of SharpCap so feel free to point that out if you have such information. I'm using latest version of SharpCap and also Omegon drivers (not touptek).

First problem is quite simple - SharpCap does not detect the camera natively. I can only use the camera through the ASCOM driver. I've tried different capture software and native driver works there (although I have not tested it for long). Hard to say if there is any difference in camera performance but I'm guessing there might be.

Second issue is related to the way camera reacts to exposure changes. My ZWO cameras would immediately stop an exposure when it's duration was changed. Omegon camera tries to "extend" the current exposure. It sounds like a good thing, but I'm certain it sometimes confuses the driver and it starts dropping frames. I'm not 100% sure these things are connected but it looks to me like they are. Sometimes only reconnecting the camera resolves this problem.

Third problem is a bit smaller but I guess can mention it. When using the "RGB24" output in SharpCap (for 16 bit depth) and saving it as TIFF, the files are only 8 bit. There seems to be no such issue with FITS files.

Would be great to hear any ideas about these issues I'm having.

Regards,
Dmitrijus Tiazlovas
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Omegon veTEC 571 Camera

#2

Post by admin »

Hi,

the fact that you can only use this camera with the ASCOM driver (or the DirectShow driver if the camera has one) is expected - SharpCap does not have native support for Omegon cameras (the same goes for other brands that are basically rebadged Touptek cameras - Explore Scientific, RisingSky, etc).

I don't expect the symptoms you describe relating to changing exposure with ASCOM cameras - SharpCap attempts to stop the exposure in progress when the exposure value is adjusted (if the current exposure is more than 2.5s long - for shorter exposures it doesn't bother). So, what should happen is that the current exposure in progress should be cancelled and then a new one should start with the new exposure. Now it's always possible that this isn't working quite as it should (or that the ASCOM driver is getting confused by the cancellation requests).

There is an option in the 'Logging' settings to turn on extra logging of camera hardware communications. Enabling this, then opening the camera and experimenting, then sending me the log may help me track down what the actual problem is.

cheers,

Robin
dtiazlovas
Posts: 7
Joined: Sat Aug 13, 2022 11:51 am

Re: Omegon veTEC 571 Camera

#3

Post by dtiazlovas »

Thanks for the reply,

I've added a small log with a couple these extended exposures. Quite a few errors in there, especially "After ...ms, camera is reporting not exposing and image not ready." Sounds like the issue I'm getting. At any rate, the images do come through eventually most of the time.
Attachments
Log_2022-08-13T20_04_00-17036.zip
(30.51 KiB) Downloaded 59 times
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Omegon veTEC 571 Camera

#4

Post by admin »

Hi,

thanks for providing the log - very helpful.

From the log I can see that when you run a longer exposure, after about 10s the ASCOM driver stops reporting that the camera is in the 'exposing' state and reports that it is in the 'idle' state instead. SharpCap will then wait up to 10 additional seconds for the ASCOM driver to report that it has an image ready in order to read that image, but that isn't happening, so SharpCap assumes the image has been lost and tries capturing the next frame (which the same seems to happen to).

This looks like an ASCOM driver bug to me, at the very least with the incorrect reporting of the idle state after 10 seconds of a longer exposure. It's possible that the exposure *is* carrying on in the background and would finish if SharpCap waited long enough - if this is the case then you would probably find exposures up to around 18-19s would work OK and those longer would fail.

Here is an selection of the log highlighting the change from the exposing to idle state about 10s after the start of a 20s exposure. The '...'s replace multiple duplicated lines of things like repeated checks on the camera state.

Code: Select all

Verbose	20:04:20.458132	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Starting get_CameraState()
Verbose	20:04:20.459108	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Completed (returned cameraIdle) get_CameraState()
Verbose	20:04:20.463014	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.StartExposure :: Starting StartExposure(1, True)
Verbose	20:04:21.212770	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.StartExposure :: Completed (returned null) StartExposure(1, True)
Verbose	20:04:21.213661	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Starting get_CameraState()
Verbose	20:04:21.213661	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Completed (returned cameraExposing) get_CameraState()
...
Verbose	20:04:22.332462	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Starting get_CameraState()
Verbose	20:04:22.332462	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Completed (returned cameraExposing) get_CameraState()
Verbose	20:04:22.532936	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_ImageReady :: Completed (returned True) get_ImageReady()
Verbose	20:04:22.532936	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_ImageReady :: Completed (returned True) get_ImageReady()
Verbose	20:04:22.873735	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.StartExposure :: Starting StartExposure(20, True)
Verbose	20:04:23.061224	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.StartExposure :: Completed (returned null) StartExposure(20, True)
Verbose	20:04:23.062200	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Starting get_CameraState()
Verbose	20:04:23.062200	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Completed (returned cameraExposing) get_CameraState()
Verbose	20:04:23.072942	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Starting get_CameraState()
...
Verbose	20:04:33.236838	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Starting get_CameraState()
Verbose	20:04:33.236838	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Completed (returned cameraExposing) get_CameraState()
Verbose	20:04:33.309243	#1 	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Starting get_CameraState()
Verbose	20:04:33.309243	#1 	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Completed (returned cameraIdle) get_CameraState()
...
Info   	20:04:34.241273	#22	After 11179ms, camera is reporting not exposing and image not ready.													in BufferFrame SharpCap.Cameras.ASCOM.NewCameraProxy.GrabFrame(CancellationToken token)
...
Verbose	20:04:43.490724	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Starting get_CameraState()
Verbose	20:04:43.490724	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Completed (returned cameraIdle) get_CameraState()
Warning	20:04:43.490724	#22	ASCOM camera is no longer exposing (cameraIdle) and has not signaled image ready, assuming frame lost					in BufferFrame SharpCap.Cameras.ASCOM.NewCameraProxy.GrabFrame(CancellationToken token)
Verbose	20:04:43.490724	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.StartExposure :: Starting StartExposure(40.0000003993621, True)
Verbose	20:04:43.674897	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.StartExposure :: Completed (returned null) StartExposure(40.0000003993621, True)
As it stands, this isn't something I can fix in SharpCap. It would be worth checking to see if there are alternative or updated ASCOM drivers available, otherwise you may need to report this as a bug to your vendor.

Sorry not to be of more help,

Robin
dtiazlovas
Posts: 7
Joined: Sat Aug 13, 2022 11:51 am

Re: Omegon veTEC 571 Camera

#5

Post by dtiazlovas »

it was in fact after 10 seconds that I would modify exposure to a longer one 20s -> 40s -> 80s. I can see that StopExposure is done (returns false?), and camera goes in to "Idle" shortly after. So I'm guessing StopExposure is not working. I will try contacting Omegon support and also maybe use "older" driver they provide. Also so far this is only an issue when live exposure changes is possible so more or less in LiveStacking, which I like to use :(

Code: Select all

Verbose	20:04:23.061224	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.StartExposure :: Completed (returned null) StartExposure(20, True)
...
Verbose	20:04:33.216790	#1 	Camera : SharpCap.Cameras.ASCOM.CameraProxy.StopExposure :: Starting StopExposure()
Verbose	20:04:33.236838	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_ImageReady :: Starting get_ImageReady()
Verbose	20:04:33.236838	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_ImageReady :: Completed (returned False) get_ImageReady()
Verbose	20:04:33.236838	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Starting get_CameraState()
Verbose	20:04:33.236838	#22	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Completed (returned cameraExposing) get_CameraState()
Verbose	20:04:33.309243	#1 	Camera : SharpCap.Cameras.ASCOM.CameraProxy.StopExposure :: Completed (returned null) StopExposure()
Verbose	20:04:33.309243	#1 	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Starting get_CameraState()
Verbose	20:04:33.309243	#1 	Camera : SharpCap.Cameras.ASCOM.CameraProxy.get_CameraState :: Completed (returned cameraIdle) get_CameraState()
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Omegon veTEC 571 Camera

#6

Post by admin »

Hi,

I think it's more that StopExposure doesn't actually give a result, so the code that records the start/end of the call puts 'returned null' in. So, I don't think that StopExposure is failing.

That starts to make a bit more sense - the camera is going idle because of stop exposure (which I hadn't spotted in the log), but SharpCap is waiting another 10 seconds. Let me see if I can do something about that.

cheers,

Robin
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Omegon veTEC 571 Camera

#7

Post by admin »

Hi,

I looked at this again and I think I understand what is going on properly now.

A little background...

ASCOM provides two ways to cancel an exposure

* StopExposure - the exposure should be ended early, an image of the data gathered so far should be produced
* AbortExposure - the exposure should be ended early and any image data discarded

ASCOM drivers can say which of these they can do (CanAbortExposure, CanStopExposure) - they can implement one, none or both.

In this case, your ASCOM driver is claiming it can implement StopExposure, so SharpCap uses that in preference to AbortExposure. However the behaviour of the driver after SharpCap calls StopExposure is actually what is expected from calling AbortExposure. This causes SharpCap to wait up to 10 seconds for the stopped exposure image to become available before starting the next frame.

If that's correct then the ASCOM driver developers need to either fix StopExposure so that it produces the image as expected, or change the driver so that it reports that it cannot stop exposures, which will make SharpCap use AbortExposure instead.

cheers,

Robin

PS. SharpCap currently also waits 10s when using AbortExposure, but I have just fixed that and the change will be in an update later today.
dtiazlovas
Posts: 7
Joined: Sat Aug 13, 2022 11:51 am

Re: Omegon veTEC 571 Camera

#8

Post by dtiazlovas »

I have done some more testing and a bit of imaging and have a couple observations about the biggest problem that I've had - camera stops producing images.

* first, when I unplug the camera during an exposure (both power and usb) it still continues to "expose" :shock: Seems that the driver is not providing the information that camera has disconnected. I'm not aware if this is something that ASCOM driver can do directly or the software has to determine it by itself but I can provide logs with this situation if necessary.

* the main issue I was still unable to reproduce artificially, but it pops up quite often when imaging. Sharpcap will expose an additional 60 seconds (to -60s in progress bar) and declares the frame as dropped. This is quite different from the previous problem, when it just waits 10 seconds. I now think it is probably due to some USB problems. I thought before that it was connected to me messing with camera settings but I now realize that it is not. I've had it happen randomly after a couple dozen identical exposures. Sadly this is difficult to reproduce so not sure when I could have logs for that.
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Omegon veTEC 571 Camera

#9

Post by admin »

Hi,

it's the job of the ASCOM driver to report to SharpCap that the camera connection has been lost. Normally the method to do this would be to raise a not connected error (https://ascom-standards.org/Help/Develo ... eption.htm) for any request SharpCap sends to the ASCOM driver after the camera is lost. I guess this is not happening, so SharpCap has no way to tell that the camera is gone.

With the additional 60s before the frame is dropped you are hitting a SharpCap imposed timeout for the capture of a frame from the camera - SharpCap will wait the expected exposure and an additional 60s (to allow for readout from slow cameras) and then assume that the frame capture has failed. This will be a result of the camera staying in the 'exposing' state beyond the expected length of the exposure and never signalling that an image is ready.

Unfortunately the problem is that it is relatively easy for a manufacturer to write an ASCOM driver that works correctly when everything goes to plan. It is much harder for them to think of and deal with all the error situations that can arise in the correct way. In fact a lot of ASCOM drivers have basically no error handling of any sort, meaning that the behaviour when something goes wrong becomes very unpredictable :(

cheers,

Robin
deep_space_dave
Posts: 2
Joined: Wed Jul 06, 2022 11:09 am

Re: Omegon veTEC 571 Camera

#10

Post by deep_space_dave »

Hi Robin,

Any plans to ever add Touptek based cameras? Maybe even a generic Touptek native driver using their SDK? I see that NINA has the drivers integrated already and have all of the features available but I rather use SharpCap for most of my captures when using my Omegon branded Touptek camera.

Thanks,
Dave
Post Reply