Re: APPM with ASI6200 and TSX Imagelink - bogus image data

@Ray wrote:


  • First, this morning I tried the image Ray sent.  I still get the weird “Expose failed(1): StartExposureNumX Set – ‘1024’” – where 1024 was the image width.  It (something) is picking up the coded X width and misusing it, I think.


  • APPM reads values from the ASCOM camera driver when it connects. It sounds like you may have reconfigured the width of the CCD in the simulator without reconnecting APPM. Thus APPM tried to create a sub-frame at out of bounds coordinates.


Just tried again, started everything up fresh, it was set before I connected (I viewed but did not change). Same error.


    • I understand the argument that “simulator works, real driver doesn’t, must be the real driver”. 


  • Except, I’ve already stated that I have successfully taken ASCOM camera images from my ASI294MM (binned 2x or sub-framed) and FLI ProLine 16803 cameras. Luca posted he has taken ASCOM Camera images too.


  • I even posted a screen shot this morning of an image taken indoors this morning with the latest FLI ASCOM driver. I am willing to make a walk-through video this evening to prove it if you don’t believe me! J


Never in any of this did I mean to imply I don’t believe you.  But we are seeing different results, which means we are either running different software environments, or doing something differently.


Can we step away briefly from the simulator issue.  I went back to and tried the ASCOM driver for an ASI174MM camera I use for guiding.  It’s a much smaller frame (1936x1216).  I set it up in the simplest state, bin 1, connected via ASCOM and took an image – the image is all 32767. I loaded in Pixinsight and looked at statistics, the minimum and maximum are 32767 and 32768 (and some fractions, which is odd for integer data, implying a transformation somewhere).


I then disconnected from APPM, opened TSX, connected that same ascom driver in TSX with no changes in settings, took an image and got expected noise patterns (the cover is on the scope so no real image). This is the 32 bit TSX by the way, not 64 bit, and definitely ascom not native driver.


So a smaller frame, same manufacturer (all I have) works in TSX and not in APPM. I guess it’s possible TSX has done some special coding to work around ASI issues?   Except the same driver and same camera work in NINA (now that’s 64 bit and I have no idea how that works, maybe it’s the same driver name but different code?).


  • The problem with the large-pixel count ASI cameras is that full-frame images from that camera exhaust all of the available memory of APPM, which is a Win32 WinForms application. The question is why does the ASI ASCOM driver need 1GB of memory for a single 46MPixel monochrome image?!!


Ok, that’s a fair question, but clearly not one I can answer.  And lamenting how I wish ASCOM and vendors would join the 64 bit world won’t help either.  😊


But unless it’s being corrupted silently I do not see how that is causing such weird errors as the errant error message above, or the all grey returned image.  It’s not failing – it is getting an image, saving it on disk, the image is just garbage.


Out of curiosity I downloaded the latest ASCOM compliance checker, and ran it on the 6200 driver with camera connected:


Conformance test complete


No errors, warnings or issues found: your driver passes ASCOM validation!!


Again, I’ve been there, written drivers which were loaded with bugs, but could still pass compliance checks.  So this is not definitive by any means.  And the compliance check doesn’t give you a copy of the image.


Again, I have a workaround.  If you want to just let it go, please do with my thanks for your help.  I feel like I’m annoying you and that is not my intention.  If on the other hand you want more debugging info, let me know what I can provide. It’s cloudy and daylight so I have time, and lots of programming tools lying around.



Join to automatically receive all group messages.