Jump to content

Banner.jpg.b83b14cd4142fe10848741bb2a14c66b.jpg

  • entries
    90
  • comments
    91
  • views
    51,542

About this blog

The blog also contains updates as I go about AOSX - a mechanism to allow application developers and vendors to quickly and easily develop within OSX for Apple Macs. http://sourceforge.net/projects/aosx/

Entries in this blog

Update 383+ and the mac..

Progress has slowed due to both the new job and getting engaged :eek: However I'd thought I'd give an update none-the-less :D Within the limits of NDAisms.. The development is progressing steadily. After spending time working through the Artemis library sources, I now have the basic building blocks in place. Firstly the firmware now downloads to the camera and I'm currently integrating with ATIK's library. It's a bit like changing the strawberry jam in a victoria sponge cake to blackberry. Then
NickK

NickK

1

ATIK & AOSX is on!

Thanks to Steve & co at ATIK, we should have good support for ATIK cameras on AOSX :D :hello2: Steve, under NDA, has allow me access to the source code to develop support for the ATIK camera range. The resulting runtime AOSX plugin will then be useable freely for ATIK owners. When AOSX source becomes public, the AOSX ATIK plugin source will remain closed. Naturally ATIK will have the source so If I get hit by a bus then all is not lost! I have the popular 383L+ and 16ic along with the EFW2,
NickK

NickK

0

ATIK responds!

A quick post to say we've had a response from ATIK. They're happy to work with us under NDA - obviously we need to see the details of the NDA however I see this working out like their currently free-to-use drivers for Windows with the AOSX plugin being available for people to use through AOSX. I'll keep you updated!
NickK

NickK

0

A possible sticking point for ATIK support in AOSX..

I've been playing with the 383L+ again for a couple of hours and one aspect may be a sticking point of ATIK support in AOSX - the copyright of the CCD firmware. In short, each time the ATIK driver initialises the ATIK high speed cameras, it downloads a small application that runs on the 383L's 8051 microcontroller. I'm assuming this firmware is written by ATIK, or at least not by Cypress, and therefore I suspect this would be copyrighted to ATIK (although no copyright is present in the code). Th
NickK

NickK

1

AOSX and 383L+ looking through the keyhole

Well it's cloudy.. and what do we do when it's cloudy? That's right - we probe USB devices.. The 383L+ seems to be: a) using a non-standard USB vendorId b) doesn't seem to support VCPs (virtual serial ports) c) doesn't have the same USB-bus chatter as a FTDI et al.. d) transfer speed well over serial.. indicating block speed. So they're using a USB block device to give them high speed communications.. bets on the very popular Cypress chips (just so happens that Apple give a USB block example us
NickK

NickK

0

Q:Why private intially? A:Shifting AOSX architecture

Rather than continue in stating that AOSX is progressing nicely, I thought I'd illustrate the framework using a picture (attached). The picture depicts the initial framework, since then David and myself have been working through aspects. Although the overall structure has remained very close, the finer detail has changed. You can see two client applications connected in to an AOSX service application. The AOSX service supports plugins for vendor and transports. It's these interfaces that have be
NickK

NickK

0

code merges in place.

We've progressed quickly in merging code into the new codebase. Currently there's been work around the plugin system, firewire support and the client-service communication along with firewire camera support. It's looking like we'll soon have firewire, QSI and ATIK support in place and SW EQ6 mount support. We have the protocols for SBIG however we will not be able to test SBIG without a camera. There's still some way to go, however there's been some real progress this week!
NickK

NickK

2

Moving forward :)

Well all has been a little quiet - I blame the end of the contract and possibly the new gf.. However now have a new laptop winging it's way to me to replaced my dodo, along with a new job and a offer of help developing AOSX! I'm spending this week merging the AOSX versions together before I put the code up on the repository and we start pushing forward with development. I've spent time looking through EQMOD and although we don't have access to the EQ control DLL sources, it should be straight fo
NickK

NickK

0

AOSX progresses with USB plugins...

After an uneventful week, a few days of clear nights - I'm dodging tonight's clear night (possible cold ahead of a job interview).. AOSX is now start taking the plugin of USB devices again after the refactoring. It's slow.. but I'm getting there! Unfortunately with the interview looming the next few nights will be revision nights. :/ However this weekend seems like a good shot to get more done :D
NickK

NickK

0

EQ6

My NEQ6 Pro (EQ6 SynScan) arrived today. I spent the entire evening playing with it and setting up the polar scope.. The controller is whizzy and easy to use.. however at the back of the manual are the RS232 protocol commands :D (much joy and merriment!) Also, it seems SW wish users to interface through the SynScan using PC Direct mode as they supply an RS232 cable for the SynScan that will plug into a USB<->RS232 cable. It seems this doesn't have the 12V lines that the mount D9 connector
NickK

NickK

1

EQ6 & EQDIR ordered so expect this in AOSX

Just a quick update this morning. Yesterday, as part of my imaging setup, I ordered a EQ6 SynScan and a EQDIR. This gives me the option of both running with the FTDI USB<->serial chip (used by the ATIK 16ic and the ATIK filterwheel) and writing a transport plugin that will be available to all vendor plugins to support the EQDIR chip (I'm assuming this will either be FTDI or another popular and easily supported chip). I'm concentrating on the restructured plugin manager at the moment which
NickK

NickK

1

Another weekend on AOSX..

I'm sure you thrilled to learn that AOSX is progressing with the redesign. Principally the work refactors (tech speak for rework/design) the communications and the class hierarchy for the plugin management/plugins so that each class is now considerably smaller and more focused on doing it's specific job. Yes this means a delay however it also means the code base is smaller and easier to maintain. From experience it always take three attempts to get something right.. the prototype/test that is th
NickK

NickK

0

Welcome!

Well I thought I'd blog the AOSX development to keep people aware it's still progressing nicely. My general approach to AOSX has been todo test projects and bring the knowledge into the main AOSX project. This has worked well, although I rethink for the internal communications has seen a rework of the code between the application and the service. It's not a massive change but it's cleaner and certainly more beautiful as an architecture. I've given myself a target for the end of Feb to get a code
NickK

NickK

0
×
×
  • 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.