JamesF

I'm after finding out what USB vendor ID and product ID are reported to the OS when it is plugged in, and also what serial number the FTDI chipset reports. Hopefully it should be easy to find out in Windows from the Device Mangler or from dmesg in Linux. I was under the impression these were the same for all their filter wheels, but I've just replaced the PCB in mine and they're completely different, which means more research is required so I stand a chance of being able to support them with my capture application. As soon as I can find a Windows machine to plug mine into i'll find out exactly where the details show up. James

I think the 12.5mm must be very popular with the people who have them. Since they went out of production I've seen less than a handful for sale used. Same with the 18mm come to think of it. The shorter focal lengths seem to come up more often. James

No, I don't think so either. As far as I'm aware it was just 5, 6, 7, 9, 12.5 and 18mm. James

Baader Genuine Orthoscopics. Orthotics is what you put in your shoes (other than feet) And yes, they are those. The new Baader Classic Orthos are apparently very similar, though manufactured in China rather than Japan (I believe) and in a different range of focal lengths. I have a feeling that the longest focal length BCO isn't even strictly an orthoscopic eyepiece, but I may well be wrong there. They also have a slightly different design to the top and eyecups. The story goes that Baader lost their manufacturer in Japan due to the tsunami and then took a very long time finding someone in China who could produce replacements which may not be to exactly the same spec as regards glass and coatings. How much of that you believe is up to you The BCOs are by all accounts decent eyepieces for the money. The BGOs are still held in good regard however, at least by people who don't need glasses for observing. The shorter focal lengths have eye relief measured in Planck lengths. James

I appreciate that it's horses for courses, but I find neither the Ethos nor the Delos range particularly compelling. I personally find too wide a field of view distracting and the Nagler is about as far as I want to go in that respect. I don't yet feel the need for the longer eye relief of a Delos either, which for me doesn't really leave enough on its side of the scales to balance the extra cost over a Nagler. That doesn't mean I think they're not good eyepieces. I just don't really think they're for me. I am still looking out for longer focal length Naglers when they come up second hand though (pretty rarely, it seems), so my case is not yet complete. Not sure where I'll find room for too many more though James

And since we're on the subject of BGOs, Naglers and Pans, here's the current contents of my own eyepiece case. Apologies for the poor photo. I'll try to get a better one at some point. James

I like all the BGOs, but the longer focal lengths (18mm, 12.5mm and 9mm) are really lovely eyepieces to use in my opinion. James

I can't recall off the top of my head which machine I tested on, but I'm not sure it matters in terms of memory or processor power. I think it probably has far more to do with the quality of the USB chipset and in particular how well it handles data flow when the bus is close to saturation. I'd guess it was probably the Acer laptop I use for imaging which is an i3-370 with 3GB RAM, but doesn't have that hot a USB subsystem. James

I have to differ on this. I find the USB3 camera is more stable than the USB2 model, even on a USB2 port. James

Thank you for the information I shall pass it on. James

Ah, excellent. Just the answer I was looking for I'm exchanging emails with someone at the moment who is having trouble getting the QHY5L-II colour to work on Linux. Do you know which OS release and which version of oacapture you used for that image? Or, alternatively, are you able to confirm that the current release definitely works for you with the colour camera? (Even if you don't get a meaningful image -- just knowing it runs and gets something off the sensor would be good.) I'd really like to support as many cameras as possible. Sadly I can't justify buying all of those I'd like to support unless they happen to come up for a fair price used. The colour QHY5L-II is one that hasn't come up yet... James

That looks excellent. Well done. That was with the colour version of the camera? James

It does strike me that performance with TIFF or FITS files may degrade as the capture period increases because of the increasing time to create new directory entries in the filesystem for new files. If you're thinking about capturing thousands of files or more, it may be sensible to add an option to split the output files into subdirectories with smaller numbers of files in each. James

I've just tried the version of oaCapture that will be released in the next few days. On my Core i5 desktop with 12GB RAM and a very average hard disk using the USB3 ASI120MM-S with a capture size of 320x240 (the total number of pixels has to be a multiple of 1024) I get around 225 fps writing the output as either an AVI file or individual TIFF files over a period of ten seconds. I've not tried on my MacBook (which has an SSD), though I suspect that it won't be much different as I don't that much greater a frame rate when the frames aren't being stored. James

It's on my list of things to do to support FITS, Mike. It can jump up the priority list now I don't believe it should be too hard if I use one of the existing libraries. I'll try to get some performance numbers later today. It strikes me that neither TIFF nor FITS are ideal for high data rate images because of the overhead due to opening and closing lots of files (perhaps more so on a traditional hard disk than SSD). It might however be possible to write unmodified data to AVI or SER files and post-process that to FITS. It would certainly be interesting to see the difference in performance. James

I will have to come back and read through this properly when I have the time it deserves. Nice to see you back, Qualia James

I have a similar 2500 litre (about 730 US gallon, I think) tank that I'm turning into an anaerobic digester. The walls really aren't very thick at all. Only a few millimetres. I suspect that once you start destroying the integrity of the form it will lose much of its strength. I guess the six million dollar question is whether you can restore that more cheaply than building the observatory another way. James

It's an intriguing idea. I think you may find that once you cut the top off the tank that it loses much of its inherent strength however. For example, in one piece the sides will resist deforming sideways relatively well. Take the top off however and they'll probably wobble all over the place. You may well need to take measures to reinforce the new lip of the "wall" so it will carry the weight of the top and the hardware required to allow the dome to rotate. Cutting a door in the side may weaken it further. I don't think that means the idea won't work, just that it may need a little more consideration James

For the time being I think I'm going to ignore it, Nick It looks as though there's a problem with FireWire cameras that I want to get sorted and I'm in the middle of improving the recording profile management. Once that's done I'll get another release out, especially as I need to do one to sort out support for the ASI USB3 cameras. After that I want to work on filter wheel support and whatever else is necessary to allow me to move to using it for RGB imaging of Jupiter on its return in late Autumn/early Winter. I also want to think about support for the Lodestar and the modifications required to create an all-sky cam/meteorcam version. Even without oaCapture I seem to have 101 other projects on the go at the moment, so lots of new stuff is just having to go at the end of the queue James

Something to aspire to Using the Mak with an ASI120 you can probably go to 400x400 on Jupiter if your tracking is good. That should be plenty big enough. The other planets will all be smaller. James

Ah, right. Planetary may well be ok anyhow, as you can probably come down to at most 640x480 if your tracking is good (unless you're using a C14, perhaps . Lunar is going to be more troublesome though, unless you're just targeting specific features. James

That does make it sound like the disk is likely to be the problem. Did you have a particular target in mind for capture, or was this just for experimentation for the time being? James

I have a couple of Aspire One netbooks and have managed to capture useful data for an image of Jupiter with it. Either the hard disk or its interface do seem to be quite sluggish on these small netbooks though. What camera are you using for capture and at what resolution? James

It's been a quiet few weeks what with the children being off school and us going abroad for a holiday, but now I'm home again and got through all the stuff that inevitably seems to build up whilst we're away I've settled down to some more work on oacapture. I've added the small amount of support required for the new USB3 ASI120 cameras, which was pretty trivial to be honest. Looks like it could be an interesting camera, especially for solar/lunar imaging. Nice high frame rates at full resolution. Then rather than working on my own code I've been twiddling someone else's. Quite a few other people's, in fact. It turns out there are three of us who had taken an open source UVC library and extended it (myself to support the TIS cameras), so I've been merging all of those changes together to fold back into the original author's code. I did have an ulterior motive however. Now I'm all done bar one required bugfix for an issue that was already in the UVC library, and I've written some code to convert YUYV and similar video format frames to RGB, I've added support for the MS Lifecam. That's now working on Linux (though it probably already would have done via the V4L2 interface), but should also now work on OSX. As soon as I have the code cleaned up a little I'll give it a go. It may also be that I can support the Xbox camera on OSX, once I can work out exactly what format it is using to transfer the image. OSX support for the Lifecam and Xbox cameras doesn't of itself sound that exciting, but it will mean that there is a cheap native astro-imaging option for OSX. And let's face it, by the time you've sold your firstborn and bought a new MacBook there's not much cash left for anything else The support for video format frames also takes me one step closer to one day perhaps supporting the SPC900 on OSX. I've also made a few UI changes that allow the various control panels to be docked either at the top or the right of the display, or even dragged off as separate windows altogether. Hopefully that should help a bit on small displays. It's also possible to hide all the controls so only the captured image is displayed, giving the largest amount of screen available to help with focusing on low resolution displays. James

Well, I pretty much finished support for my Firefly MV this evening, dropped the sources on my MacBook and they built and ran first time without errors so I'm quite happy with that. Pending some regression testing and a couple of small bugs to look at I think it might be time to start looking at another release. James