JamesF

That's a shame, MIchael. They've been quite helpful to me, though they have been a little vague about some details which may be down to language issues. Hence my digging for a few more details here. If it's a very early model then I don't think the latest firmware would work anyhow. I seem to recall that the latest version I could upgrade my V1 wheel to was v2.2.0 whereas the latest firmware release is 3.3.0. The description of the firmware file sounds as I'd expect though. I believe the (downloadable) user manual explains how to do the upgrade. I think there is some weird thing where you have to upgrade to v1.9.9 first if you don't already have v2.0.0 or later, but other than that it was straightforward. Should it still not work, Ian King may still have some of the replacement V2 PCBs in stock which I'd expect to fix it unless the motor has failed. Mine wasn't expensive and just required the two motor wires unsoldering from the original board and soldering back to the new one. It's a bit fiddly because they're very close together, but otherwise ok. If you're not sure about doing it yourself then perhaps we can sort something out by talking to Ian and posting the bits to me. Just don't expect it back next day Or perhaps there's someone closer who could do the soldering job. The V2 upgrade has the bonus of moving all the electronics inside the wheel, so you don't need the specific Xagyl cable -- any standard USB to mini USB cable will do. James

Ah, fair enough. I think there has to be some sort of associated EEPROM for a serial number to be present. If you have a pre-production model then I guess it's entirely possible the EEPROM isn't there. James

Bah It seems that 0403:6015 is another generic FTDI VID/PID, not specific to Xagyl. Your 525 wheel doesn't have a serial number at all, Robin? James

That's a bit unkind if it happens to be some other device that the user doesn't want you fiddling with I'm tempted by the argument that if a device should not be messed about with then some other application should have it exclusively locked, but wilfully sending data that might be regarded as invalid to an unknown device goes against the grain a bit. None of which means I won't resort to that option if all else fails James

Just come across an example where this might happen. The Atik 16-series cameras use an FTDI serial interface, so they would also appear as /dev/ttyUSBx. If such a camera and a Xagyl filter wheel were connected you'd not know which device node was which device, other than by scanning the USB device tree or asking the user. And each time they plug them in it might change. James

Aha! Just found some documentation on the FTDI website saying that hardware manufacturers should either obtain a device-specific PID for their product from FTDI, or use the default FTDI VID/PID of 0403:6001 with a unique serial number for each device (though the wording leaves it unclear as to whether that means each individual device or each different type of device). So it may be that all 0403:6015 devices can be relied upon to be Xagyl filter wheels and i'll just have to see how it goes with the V1 wheels with the USB->serial converter in the cable. Perhaps there's some sort of common range of serial numbers for that version even if they're not the same. James

I think it was the motor driver circuitry that died. I can still connect to the FTDI part using my old cable and send it commands that don't involve the carousel, but the motor wouldn't turn at all even under zero load. I want the VID/PID because I can then make a half-decent attempt at identifying exactly which device node is the serial interface for the wheel. It's possible that an astro-imaging pc may have a number of devices with USB->serial converters connected and if I can scan the USB bus and find the one which is a filter wheel then I know exactly which device to open without relying on the user configuring it, or even on it being the same device node each time. James

I am running Linux, yes. What I have discovered thus far is: As I originally had it, with the FTDI USB->serial converter in the cable (what Xagyl call the V1 5125), the FTDI converter gave a VID/PID of 0403:6001 and also a serial number of A4008T44. I'm told the serial number may not be unique, but may be set by FTDI on a per-application basis (eg. all V5125 wheels may have the same serial number). When my V1 PCB died I replaced it with a V2 PCB. In the V2 model Xagyl moved the FTDI chip inside the wheel so it can use a standard USB cable. At the same time the VID/PID has changed to 0403:6015 and the serial number to DA001CEZ. I gather there's also a V3 5125 PCB as well, so I'm half-expecting the details for that to have changed and perhaps there's no reason for the 8125 and the 5200 wheels to have the same values either. James

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