NickK

Well the 383 was shipped off on saturday, I check the royal mail - it arrived today at 11:38.. only to have a message today at 16:30 to say that it's in the post! Awesome service!

Just posted the 383L off for repair.. so hopefully I should have it back quickly :D

Last night I managed to trip up and take out the USB cable and the centre plastic pin inside the USB socket.. so I'll be arranging a repair trip for the 383L. Perfect conditions but ho-hum! The additional downside is that the 383L support will have to wait for it to be fixed but it does mean I can continue with the 16IC :D I've also just found out that there's an open source project that allows connection for my little Garmin Geko 301, a RS232 serial connection... GPS support :D But 16IC first!

In between returning from kickboxing and getting to bed I managed to spend an hour working on this. I've now got the first 17MB image transferred. I've still got additional work todo but it's a milestone in the project. :glasses1:

Many thanks to Sandrine putting up with my obsessive behaviour this weekend! For the first time, the ATIK 383L+ initialised itself with the characteristic click-click. The plan was to get the image downloaded for something to show.. however some stupid unwritten behaviour of Apple's USB implementation meant banging my head against the wall for two days straight trying to figure it out - that's sorted! :glasses1: So the camera initialises, chats and will initiate a download of the image.. the remaining work I have is just a bit of thread queue intercommunications debugging for the final download.. annoying because I had planned to have that done this weekend! I expect work to be hard this week and I think I will need to pay someone some attention.. so perhaps completed next weekend!

Getting there :D

This is the Xcode USB probe application. I thought I'd just give you a hint that it's slowly advancing ;)

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 change the topping for AOSX. I don't have to rewrite everything, just simply replace what I need and everything should function :D Next thing is to focus on getting it's first image..

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, so I can get those tested easily enough. Once we go alpha, I'll be looking for volunteers for the other cameras such as the 11000, 4000, 314 etc to try AOSX with a basic image capture 'example' application.

Should be here tomorrow.. but this was always on the cards although the filters will have to wait for now!

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!

The email reads: Now I hope that ATIK reply favourably!

Two options: 1) Have each user download the firmware from a running camera once - but this would require the user to be using windows. This would, naturally, mean that each user would legally be making a copy of 'software' that they're already using.. 2) Write my own 8051 controller firmware and opensource that too. This isn't new for me as I've written Blackfin based firmware (another more powerful controller chip).. Hmm let me think about it...

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). Thus if we take the firmware and provide it as part of AOSX support for ATIK cameras - it could place me and others in the legal firing line.. I'll ping ATIK an email but, given the zero response to my previous emails - I'm not expecting that ATIK will authorise it. Technically it's possible.

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 using a cypress chip in their dev sample code for USB development..). Now on windows, nebulosity uses the ATIK DLLs to interact with the atikhub driver which then interacts with the standard windows USB hub drivers.. well that's what the USB sniffer seems to think. It also shows a close similarity to the ye-olde protocol of the 16ic. Now the 16ic uses an FTDI serial and so it seems to be in 8bit hell (I'm assuming the PIC controller is 8bit too). Now usually as the PC has more cpu power it attempts to communicate in a more friendly form for the poor low power onboard processors.. it seems the 383 is no exception.. with the messages appearing in 16bit numbers - including the numbers that had appeared in 8bit previously. So given this... with a little jiggery pokery we should have some very basic control of the 383 soon..

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 been in flux. Also attached is a screenshot of David's EQMount app running against AOSX..

Currently the code base is going though some flux - specifically the interfaces. I'll blog a picture of the initial architecture which will help give some clarity.

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!

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 forward to get EQMOD or equivalent functionality ontop of AOSX. It's also come to my attention that Skywatcher are creating a PC interface to allow PC apps using Python to control their mounts. This is more of a curse than a blessing for software controlling the mounts as it complicates things when the normal user is never going to script python (not this doesn't have PEC or alignment capabilities) and application developers are not wanting play silly-bs (EQMOD needs stepper motor access to provide better PEC - this library hides this!). It doesn't help that the SW API is written in closed C#.. making it PC only.

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

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 has. I just so happen to have an FTDI USB<->D9 RS232 that will connect to the RJ11 serial socket on the controller as well as the EQDIR (Prolific chip) adaptor box. Currently have the EQ6 connected via FTDI to have a play using the ATIK test code. Only thing different is that the handset PC-Direct mode uses 9600 with no parity or stop bits (different to the ATIK which uses the bitbang mode of the FTDI to get decent transfer rates - although overkill for a mount!). Although it's possible to play further, my current priority is to finish the refactoring. Once that's done then I can play with additional transports (ie the prolific) and additional vendor plugins (ie the EQ6). Assuming there's not a break in the cloud :p

Although I can't work on this tonight, the EQDIR chip is confirmed as a Prolific Technology Inc. chip (a major competitor to FTDI). It's well known and should be straight forward to incorporate support. The only down side with the EQDIR device is that HiTechAstro have not configured a USB Manufacturer String, Product String or Serial Number String. This means we'll be matching on "Prolific Technology Inc."+"USB-Serial Controller"+NONE and so will not be able to differentiate between any Prolific-based devices without resorting to getting the user to manually configure which is which if they connect more than one Prolific device with the same identity. ATIK correctly configure the manufacturer, product and the serial number so it's possible to differentiate between an FTDI-based camera and an FTDI-based filter wheel then automatically sense which configuration to associate.

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 is far more object orientated - using a proper class hierarchy to share common functionality between the vendor plugin manager and the transport plugin manager. The USB Transport manager will handle the connection of the a USB device, offering it to the vendor plugin manager with the device name - allowing the vendor plugins to say "yes I support that device". It will do this via the plugin property file which allows some tweaking for the user but also means the only the plugins that are needed are loaded (Objective-C runtime cannot unload run-time loaded classes so having them all in memory and unused is a waste). The USB Transport is instantiated and the Vendor Plugin manager then loads up the plugins ready and away it goes as the device becomes available to the application.

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 thrown away, the initial bringing together and then the rework where the emphasis is more on development principles rather than getting the thing to work together. If you've developed for long enough then you know there's a gut instinct that something is 'beautiful' as a software design is like a sculpture. I've lost time due to work and a 6 hour round trip to pick up a lovely Pentax.

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 base out which will cope with cameras and webcams. Additionally I've been eyeing up a Vixen Sphinx SXD mount although this will have to wait for the short term - I'm currently contracting with a renewal in march. I'm looking for a permanent role, so once I'm settled the mount and support for it will appear quickly after!