Jump to content

Banner.jpg.b83b14cd4142fe10848741bb2a14c66b.jpg

NickK

Members
  • Posts

    3,804
  • Joined

  • Last visited

Blog Entries posted by NickK

  1. NickK
    Just a simulation at the moment, however attached is a non-cooled integration so I can see what can be done with fast video-like integration.
    27x30 second exposures with registration, no guiding, no polar alignment and no cooling (for extra noise!) and sigma integration.. so I picked a nondescript, but darkish part of the sky (straight up to minimise light polution.

    It bodes well with 9Boo being the brightest and some nice mag 13-15 in there running at 670mm f/6.38.. binnign 2x2 would make for even easier finding (faster download and brighter target).
  2. NickK
    So the app has nice scrolly shifts to the windows but it has occurred to me that those that don't use a trackpad/laptop will be limited in the gestures which means buttons to navigate..
    A restructure later.. and the app code is looking nicer. When i have the chance to get the camera and laptop in the same room we may see a video of it's first image capture..
  3. NickK
    For the goods:
    I've been squirrelling away on the commute to bring the test application up to a respectable level. I feel that it's basically usable in order to allow people to test the drivers by simply trying it! Although I've tried the drivers on all the main forms of camera, you always get differences appearing in real life when people attempt to use software and hardware with their own computers.
    So this will allow people to have some fun whilst my attention, rather like the eye of sauron, moves back towards AOSX and integrating this for the beta series of releases.
    It's been interesting experience, at one point I had two 11000 monos, 320E, 383L, Titan, 16IC, EFW2 and 4000 carcass on the table..
    Anyway.. for now - back to reality!
  4. NickK
    V3 (latest), here in this post:
    So the next question is what next..

    So basically the app will get some additional features to exercise the cameras (and yes you'll be able to set up a sequence of shots).
    When will I add filter wheel support in the sequence?
    Well after the driver is running.. I'll be putting some focus back into AOSX itself with the driver becoming a camera module, the filter wheel will also be supported and anyone can then use it :)
    I've been talking to Craig Stark (of PHD and Nebulosity fame) who is interested and along with EQMac's OZDave (on this very forum) who has been participating in AOSX development.. it's looking good.
  5. NickK
    So I'm 99% on the alpha release.. I still have some daylight photos to take for the manual (demonstrating sub-framing etc) and two 'todo' list entries. I hope to have this done tomorrow.. The 4000/11000 support I've not manage to get a photo yet (I'll worry about that post alpha).
    I've tried compiling OpenPHD unfortunately the 3rd party package it uses for it's GUI doesn't compile on 10.8.. only 10.6.. so I'll let Craig tackle that headache.
  6. NickK
    Well.. at least to support ye-olde 3.3 fully! (3.3 is basically like DX11.. the latest is something like 4.2..) - supposedly it runs 3.2 but I'm not convinced.. I can see the logic of avoiding 4.x as it's too new and a mess...
    Which basically means that the only thing buying a higher end graphic GPU in an apple is that it goes faster by clock speed and number of pipelines.. nothing about using the (now standard) features available - a PC and linux have more advanced graphics sub-systems!
    I'm having to use OpenCL to render 3D volume visualisations rather than OpenGL!
    Oh.. yes.. it is astronomy related ;)
  7. NickK
    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.
  8. NickK
    I took an image directly using the Mac last night with the 383 (the PC was still performing guiding using the 16IC and controlling the mount as it was the end of a late session).
    This is a raw image with all the dead pixels, the refractor aberrations and no processing..
    Here's a link to the raw 17.1MB 16 bit TIFF of the Bear Paw Galaxy
    You may want to do some curves to pull out the target(s).
  9. NickK
    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..
  10. NickK
    So I've spent a few days on the ATIK support over the wet & cloudy weekend after a little break (including SGL7)..
    The productive points:
    * EFW2 support should be simple - I'm happy with the research on that part.
    * The final refactoring/restructuring of the ATIK driver library is in full swing - after which a large portion of testing!
  11. NickK
    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!
  12. NickK
    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.
  13. NickK
    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!
  14. NickK
    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!
  15. NickK
    So what's next :D
    I'm going to create a little test application to support a sub-set of the cameras for people to test and give feedback on (not an image capture app!).
    Just need to sweet talk Sandrine into giving me a an evening or two..
  16. NickK
    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.
  17. NickK
    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.
×
×
  • 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.