Hi,
two of the logs, and the text file, show the same basic error code coming from the ASCOM driver:
Code: Select all
Fujifilm SDK Error during 'XSDK_SetShutterSpeed (Bulb=0)'. SDK Result: -1, Last API Code: 1305, Last Error Code: 8193 (COMMUNICATION) (Communication Error/Timeout)
This looks very much like the PC has lost communication with the camera, so when trying to send it commands, an error happens. There are a number of possible causes for this (USB cable dislodged, camera gone to sleep, a bug somewhere in the ASCOM driver, etc). There's nothing I can do about this sort of issue, but the error above might mean something to the developer of the ASCOM driver and maybe they can advise further.
The third log is more interesting... SharpCap is getting frames from the driver, but deciding they are the wrong size and throwing them away.
Code: Select all
Warning 16:52:53.631405 #33 Dropping frame due to pixel count mismatch - 2d source array (6336x4182), source had 26497152 pixels, dest 25958400
Further up the log we can see that SharpCap is opening the camera and expecting frames that are 6240x4160 pixels
Code: Select all
Info 16:54:41.844795 #1 Starting Preview on Fujifilm Camera (Scdouglas) [X-M5], 6240x4160, Bayer_RGGB, 16bits in Live mode.
That combination of 6240x4160 gives the 25958400 pixels that SharpCap is expecting in the images that come from the camera, but the ASCOM driver is delivering bigger images (6336x4182).
Is 6240x4160 the default size of image offered to you when you connect to this camera in SharpCap, or is there a higher 6336x4182 option? If 6240x4160 is the default and maximum size then I think this comes down to an ASCOM driver bug - SharpCap reads the maximum size from 'CameraXSize' and 'CameraYSize' on the ASCOM driver (this is where the maximum size shown in SharpCap comes from). SharpCap will then set 'NumX' and 'NumY' on the ASCOM driver to those values when starting up the camera, and the images that come out should then all match that size, but the driver seems to be giving back more data. Again, I would suggest that this is something to be investigated by the ASCOM driver author.
cheers,
Robin