ATIK OSX Drivers R1.00 & Example App

[NickK]

Looking at the application - it does use auto stretch if it's enabled. It should really just take what values are present at the start. 

It would explain the noise. Alternatively - what PSU are you using?

[NickK]

The new update is progressing - for the technically minded - I'll be using an OpenGL based view.. for the non technically minded, it's what they use for computer games so should be able to keep up with fast cameras and support some of the additional image displays I want to provide..

[NickK]

Getting there .. OpenGL now working - still got some additional work:

So with this new found display, I can do pretty much anything - including wrapping the image around a teapot!

The down side is that the GPU gets used (so not the most battery efficient!), however the idea is this has a far wider ability in displaying processing and will happily deal with high frame rates.

[NickK]

Found the memory leak from the ExampleApp - caused originally by my fighting with ARC (self memory allocation system). Now there's no requirement to explicitly release buffers.. (hint for developers: @autorelease still being required for some OSX routines with ARC..)

I've also upped the handling and it works nicely with the 383L too.

Still todo:

* scroll & zoom - this shouldn't affect speed

* tidy up (including experimental)

Happy with the speed so far.. it's support resolution up to 4096x4096 at 50 frames/sec at least… which is beyond the LCD display capability and the Titan's..

[NickK]

I thought I'd upload a example video of the new OpenGL display whilst it's light and I can get an image out of the A80Mf:

http://www.youtube.com/watch?v=zKL46HFPDIU&feature=youtu.be

This isn't optimised yet and still needs a few tweaks but it's quick… very quick. .. unfortunately at 800mb.. it's taking a while to upload

[NickK]

Releasing R1.08 Example App

The majority of this release is switch to OpenGL to display - this is a run and play app for 10.8+ without any need to install drivers as they're baked into the app.

Get the standalone ExampleApp here (no drivers required): ExampleApplication.zip

You'll note the slider sub window is missing now but at the same time the window displays far faster with large images (not tile filling effect). I have some more additions and optimisations but I wanted to get this version out now for people to play with.

Please note - the Experimetals such as FFT/static stack are not working with the new OpenGL system however.. that will be shorted shortly..

The R1.08 Drivers (app developers only)

Modern Drivers framework: ATIKOSXDrivers.framework.zip

Legacy Drivers (requires Modern Driver framework): ATIKOSXLegacyDrivers.framework.zip

There's an important legacy fix for the guide port in R1.08 (both drivers and ExampleApp) that prevents a crash.

[NickK]

So the example app has a minor issue with scaling.. I will not say how much fun I have with OpenGL+NSScrollView and convertRectToBacking that works one minute then not the next…. note it doesn't impact the drivers or the saved images..

[NickK]

I have a fix for the scroll and scale in the ExampleApp (no driver changes this time) - also I've optimised the GPU upload. The Titan at 15fps is using 120% CPU (that's download and display).

R1.11 ExampleApp: ExampleApplication.zip

The example app also now includes a 383L test shot for this version (hence the 16MB). I'll remove this in the next version but for now.. have a play.

The initial image update is know about and disable of reticule too but the main thing is scrolling, GPU usage

[NickK]

Fixed the capture crash caused by the recent OpenGL changes, fixed a legacy post processing issue in the drivers.

Release 1.13 ExampleApp: ExampleApplication.zip

I've left the 17MB 383L test shot in the example app for the time being hence the size of the app.

R1.13 for the developers only:

Modern Driver framework: ATIKOSXDrivers.framework.zip

Legacy Driver framework (requires Modern Driver): ATIKOSXLegacyDrivers.framework.zip

Release notes

// 1.08 Legacy guide port issue now fixed

// 1.09 Craig - Added kArtemisExtensionKeyFIFO & hasProgrammableFIFO for Bob's legacy 285.

// 1.10 Craig - Added runtime search path @loader_path/../Frameworks to allow defined dynlib loading

// 1.11 Release for ExampleApp only - with fixed OpenGL scaling and direct memory copy texture usage.

// 1.12 Titan only precharge fix now calculating correctly & switched to old ClearCCD+force amp off after exposure.

//      Removed a couple of printf statements in the post processor.

//      ExampleApp now update correctly on first image capture without needing to scroll/resize to cause the update.

//      Legacy camera driver now uses a debugging test before readccd debug print out block

//      ExampleApp now has FIFO HID control for legacy cameras

// 1.13 Cameras now can create their relevant post processor, addition of virtual API abstracts implementation. Fixes 285 using non-legacy post processor.

//      ExampleApp no longer crashes at the end of a capture set.

You'll note the change to use the dynamic library version of the FTDI 2XX library. With the compilation options you can either have the FTDI 2xx library in library frameworks directory - or - install the library into your application's framework directory.

[chrisecurtis]

Dear Nick,

thanks for all your work on this.

I am keen to get my Atik 320e OSC working on my macbook air and am using the latest version of Nebulosity with beta support from your driver. Craig asked that I post my experience here.

In Nebulosity (which I think is running your 1.0 framework) things work pretty much as expected but there are three problems:

1. HUGE amp glow - I think you know about that

2. Cooling does not seem to be working, or if it does, the camera is not reporting its temperature correctly. It just shows as 9.99C

3. I have had a number of random crashes while recording series of exposures. Some work fine (I have captured several series of 50 exposures of 30 seconds and some several minute single exposures). Sometimes, the camera keeps generating and saving frames, but these are empty. Very occasionally, there is a hard crash requiring shut down and restart. As I am fairly newly returned to Nebulosity, it is possible that I am doing something stupid, but only seeing this sort of thing in relation to the camera.

At Craig's suggestion, I have tried your example application. The latest one crashes (with a report) EVERY time the camera tries to download. I can't even preview. If I try to capture a series, there is a long delay, then the camera reports exposing, then the crash report as soon as the exposure ends.

Version 1.05 of the example application works for me. The tiffs do not show any amp glow (tried indoors) and things seem to work reliably. I will give it a go under the stars later on tonight.

Computer is MBA 13 inch (late 2013) running latest Mavericks.

Hope this is helpful. Happy to send reports and images if that would help.

Thanks again for all your work.

[chrisecurtis]

Sorry, meant to add - no apparent response to setting temperature in 1.05 either.

[NickK]

Have you tried the R1.13 Example App - this will see if you get the same issues (temperature etc)?  There was a fix, along time ago, in the temperature calculation. 

I am working with Craig on the Nebulosity update to the later R1.15 drivers - just slightly delayed with some DIY (replacing radiator, repositioning the CH pipes, adding underfloor heating, replacing toilet, and laying a tile floor) to keep the mrs happy..

The current R1.15 list release note are:

// 1.13 Cameras now can create their relevant post processor, addition of virtual API abstracts implementation. Fixes 285 using non-legacy post processor.

//      ExampleApp no longer crashes at the end of a capture set.

//      RELEASED

// 1.14 Added PostProcessor calculation of histogram,average and min/max if requested. Requires one less scan of image data as we're doing that anyway.

// 1.15 Added Artemis 285 as ART-285, including image to ExampleApp - TestLegacyCamera appears as 285 not 16IC now.

//      Added 100ms delay for data read when FIFO disabled for Legacy driver

//      ExampleApp code tidy around the OpenCL prototypes

//      Modern cameras - existing driver amp behaviour corrected - amp was enabled, only to be possibly switched off on reading the CCD.

//      Some Modern cameras - Amp left on after preview mode exposure switches off.

//      * Supporting cameras - addition of keArtemisExtensionKeyDisableAmpOnCCDRead extension to force CCD amp off for maximum linear readout.

//      All Cameras now ensure amp is disabled on camera startup by default, amp is enabled only when required.

//      Titan read now has option of providing disabled amp read for long expsures (more linear and less noise but less sensitive).

So you can see I've been working on the amp side of things - allowing control for spectrograph use.

[NickK]

At Craig's suggestion, I have tried your example application. The latest one crashes (with a report) EVERY time the camera tries to download. I can't even preview. If I try to capture a series, there is a long delay, then the camera reports exposing, then the crash report as soon as the exposure ends.

Hmm, I may have to upgrade to Mavericks after all. I assume that was R1.13? Could you provide the exception report? (you should be able to cut and paste it - just PM it to me). The same driver is used for Nebulosity.

I get to test on the main models of camera - Titan, 383L (related to 4xx series in the driver), 4000 (11000 related). So I'd be very interested to see if there's any issues. I've been known to wander around SGL borrowing camera time during the day for testing I tried Helen's 400 OSC previously and it seemed fine so I'm very interested to know.

[NickK]

So using the R1.13 Example App seems to work correctly with the 320E (phew!) - I'll report back to Craig on that.

[NickK]

Sorry for the delay.. the next will now be R1.16.. with ATIK One 6.0 support I'll also put together an update development guide to go over the new features etc and extensions..

// 1.13 Cameras now can create their relevant post processor, addition of virtual API abstracts implementation. Fixes 285 using non-legacy post processor.

//      ExampleApp no longer crashes at the end of a capture set.

//      RELEASED

// 1.14 Added PostProcessor calculation of histogram,average and min/max if requested. Requires one less scan of image data as we're doing that anyway.

// 1.15 Added Artemis 285 as ART-285, including image to ExampleApp - TestLegacyCamera appears as 285 not 16IC now.

//      Added 100ms delay for data read when FIFO disabled for Legacy driver

//      ExampleApp code tidy around the OpenCL prototypes

//      Modern cameras - existing driver amp behaviour corrected - amp was enabled, only to be possibly switched off on reading the CCD.

//      Some Modern cameras - Amp left on after preview mode exposure switches off.

//      * Supporting cameras - addition of keArtemisExtensionKeyDisableAmpOnCCDRead extension to force CCD amp off for maximum linear readout.

//      All Cameras now ensure amp is disabled on camera startup by default, amp is enabled only when required.

//      Titan read now has option of providing disabled amp read for long expsures (more linear and less noise but less sensitive).

//      Removed Titan (only) alpha limiting 4x4 binning

//      ExampleApp no longer crashes on disconnect (and reconnects) - ARC was releasing the imager instance.

//      ExampleApp reticule (spiderweb!) now displays depending on tickbox.

// 1.16 ATIK One 6.0 support added

So in the meantime here's example app R1.15: ExampleApplication.zip

It still has the 17MB test image for now, but I swear I'll remove it for 1.16!

[NickK]

Release R1.22

Main driver changes:

* ATIK One 6.0 support including filter wheel (tested )

* Enhancements to all camera amplifier handling

* Titan 4x4 binning restriction left from alpha release removed

* Filters are now labeled 1..n rather than 0..(n-1) to simplify things.

ExampleApp:

* Bugfixes and Enhancements, a lot more stable, removed the 17.1MB test image

So in short there's a world of difference and this represents a good checkpoint for the drivers.

For anyone

Example App (OSX10.8+ standalone, no drivers required, just run): ExampleApplication R122.zip

For the application developers

Modern Drivers for developers (OSX 10.8+): ATIKOSXDrivers.framework.zip

Legacy Drivers (requires modern drivers, OSX10.8+): ATIKOSXLegacyDrivers.framework.zip

Detailed release notes

// Vers Description of change

// ---- ----- - -

// 1.00 First full release

// 1.01 Craig - fix for old ART 429 interleaving bug

// 1.02 Chris - fix for missing 16IC-C PID

// 1.03 Added icons to Example App for older cameras so they dont appear as blanks, also has driver set names such as 16IC-C instead of "MiniART".

// 1.04 Titan modes are held off camera and the gain/offset are not written back into the EEPROM.

// 1.05 Abort will now wait up to one second (or exit of abort - whichever is fastest)

//      Craig - Exposed ATIKDeviceDisconnectedException

//      Craig - New specific camera support modes added to modern driver.

//      James@FLO - IC24 - Bugfix for amp being left on before ClearCCD on long exposures!

//      HSC - amp always switched off at the end of an exposure

//      Drivers nolonger use usleep but timing implementation.

// 1.06 Syncronisation for 10.6.8 build that now uses dynamic lib.

// 1.07 ImageFrame.h build issue on 10.6.8 build

// 1.08 Legacy guide port issue now fixed

//      RELEASED

// 1.09 Craig - Added kArtemisExtensionKeyFIFO & hasProgrammableFIFO for Bob's legacy 285.

// 1.10 Craig - Added runtime search path @loader_path/../Frameworks to allow defined dynlib loading

// 1.11 Release for ExampleApp only - with fixed OpenGL scaling and direct memory copy texture usage.

// 1.12 Titan only precharge fix now calculating correctly & switched to old ClearCCD+force amp off after exposure.

//      Removed a couple of printf statements in the post processor.

//      ExampleApp now update correctly on first image capture without needing to scroll/resize to cause the update.

//      Legacy camera driver now uses a debugging test before readccd debug print out block

//      ExampleApp now has FIFO HID control for legacy cameras

// 1.13 Cameras now can create their relevant post processor, addition of virtual API abstracts implementation. Fixes 285 using non-legacy post processor.

//      ExampleApp no longer crashes at the end of a capture set.

//      RELEASED

// 1.14 Added PostProcessor calculation of histogram,average and min/max if requested. Requires one less scan of image data as we're doing that anyway.

// 1.15 Added Artemis 285 as ART-285, including image to ExampleApp - TestLegacyCamera appears as 285 not 16IC now.

//      Added 100ms delay for data read when FIFO disabled for Legacy driver

//      ExampleApp code tidy around the OpenCL prototypes

//      Modern cameras - existing driver amp behaviour corrected - amp was enabled, only to be possibly switched off on reading the CCD.

//      Some Modern cameras - Amp left on after preview mode exposure switches off.

//      * Supporting cameras - addition of keArtemisExtensionKeyDisableAmpOnCCDRead extension to force CCD amp off for maximum linear readout.

//      All Cameras now ensure amp is disabled on camera startup by default, amp is enabled only when required.

//      Titan read now has option of providing disabled amp read for long expsures (more linear and less noise but less sensitive).

//      Removed Titan (only) alpha limiting 4x4 binning

//      ExampleApp no longer crashes on disconnect (and reconnects) - ARC was releasing the imager instance.

//      ExampleApp reticule (spiderweb!) now displays depending on tick box (updates on next exposure).

// 1.16 ATIK One 6.0 support added, removed 17.1MB 383L test image for the test camera.

// 1.17 Bugfix for Modern drivers w.r.t the changes done in 1.16.

// 1.18 Bugfix for Modern drivers for One.

// 1.19 Bugfix for Modern drivers for One testing.

// 1.20 Filters are now labelled 1..n rather than 0..(n-1) by the drivers for EFW and the One.

// 1.21 Created 10.6.8 file set in 10.8+ project meaning no more rework on the 10.6 to keep in step as it's one code base.

// 1.22 RELEASE (10.6.8 release will have the same number)

 

Note the ATIK One filter wheel will now appear as a separate device from the manager but with the same location. The unique identifier is the camera identifier+"-Filters". When the camera disconnects, the filter wheel will also automatically disconnect.

 

 

So what next?

Apart from sorting out some legacy camera (Artemis 295 and 429), any bug fixes that need doing and an update on the developer guide… I have a couple of ideas that are progressing as the ExampleApp is already getting some internal restructuring to support them..

[chrisecurtis]

Good and bad news, I am afraid, with the Atik 320e.

Good news. App does not crash - at all. Camera is recognised (though a filter wheel comes up as well, and I do not have one). Preview worked properly. I was able to capture 10 x 1 second sequence without problems, more than once. All working well. Amp appears to be properly off and cooler seems to be on.

Bad news. Attempt to capture 10 x 30 second sequence failed. Camera disconnects at end of first 30 second period (icons disappear from app). Have to re-set folder and sequence. Same thing happens. ATIKOSXDrivers.log reports "signalling abort exit" and "abort exit signalled" each time that happens.

Have posted ATIKOSDrivers.log to the private conversation.

[NickK]

Hi Chris - can you pass over the log file, I think the forum post has swallowed your PM.

The abort signalling is part of the timing mechanism, in fact it's indicating that all is well and shouldn't impact the USB connection. However I'll look into the disconnects.

The resetting of the folder is because the camera has been removed and the filter wheel looks like the 320 returns non zero data - I'll know meow once I have the logs.

[chrisecurtis]

Have managed to get first part of log into the private messenger. It would not let me post the whole log: too big, I think.

I think what I posted shows some 1 second exposures without disconnect and at least one 30 second exposure with a disconnect.

I thought the set-up disappearing was a by-product of the disconnect. The app reconnects the camera correctly, but is obviously "starting again".

If I have time, I will try exposures between 1 and 30 seconds to see when disconnects start happening.

Thanks for all your work on this.

Chris

[NickK]

I've sent you a new binary with a fix - although nothing explicity indicates why kIOReturnNotResponding occurs - looking at the old OSX open sourced code for the USB IO interface, this is a catch all that can be triggered by buffer under runs - so I've make a logical leap that it's the driver asking for more data (one USB packet infact) than the camera will supply. OSX then is a bit inconsistent and I think when the camera doesn't ack (as there's no additional data), then OSX works normally but once in a blue moon OSX throws it's toys out the pram rather than returning buffer under run or timing out as it should do.

OSX has a history of rejecting devices coded like that when linux and windows work quite happily (apple's own WiFi and trackpads threw this same error code in the past).. fingers crossed (this is working on the 383L and I'm just trying the 4000 etc which seem to working well).. Once we've confirmed it fixes your issue I'll do a full set of automated regression tests and then release.

[OzDave]

Are you guys sure that Mavericks is not playing havoc with the timing of things? It ruined all my astro apps doing any form of real time delays until I switched off app nap for each app.

Given Nick appears not to run Mavericks yet, he probably hasn't seen the massive issues app nap can cause. And it seems the problems are related to timing in some way.

So I'd try disabling app nap for the test app and repeat the tests you were doing.

Nick, if app nap is the cause then you'll need to do some changes to the way timers are used in the code. I've been recoding EQMac to deal with this so have some experience if you need advice.

David

Sent from my iPhone using Tapatalk

[NickK]

That is a good point - Chris is using 10.9. Also it's possible that AppNap would affect long exposures. USB is host initiated so some operations require time between interactions to minimise pinging etc (which burns CPU time and defeats the purpose!). It's looking like I'll have up upgrade begrudgingly - considering the number of bugs introduced with 10.9.. that's a hard decision.

The change I made is working well - I'm also attempting to optimise the time a flush takes if the camera doesn't respond (i.e. when you restart the app). This really only seems to affect the 4000/11000 which can have a little bit of a wait until they appear; the good side is that they will always appear (dependability is good for remote apps!).. 

[NickK]

Chris has updated me - the USB change has nailed the 320 problem - so that's good. The other cameras are happy - but I'll do a full set of tests once I have the chance next week during a cloudy spot

[NickK]

Well here at SGL9 I managed to borrow an ATIK One 6.0 whilst it was cloudy to test with the OSX drivers. I'm impressed, lovely camera

Youtube video using the ExampleApp and OSX drivers:

Artistic supervision with Jon Hicks - using quarter frame sub-framing (testing you understand!):

Later a gap in the clouds allowed for some solar and the moon appeared in the daylight sky:

Nothing like dogfooding - I've recoded the 320 fix - it appeared that it caused a problem with the Titan after about 1000+ frames with a timeout causing a delay of 30 seconds.. the new code has worked flawlessly on the One, Titan etc. Here's my titan image using just solar film at 3350mm fl which is below dawes limit (hence slightly soft), 100 exposures stacked and aligned:

[NickK]

It was cloudy yesterday.. detoxing at SGL9 and with the cameras working well I ended up working on the basic stacking with the OpenGL display.. that now works, I have some improvements that have occurred to me this morning but the initial system looks very promising.