JamesF

No idea what this means for the business -- perhaps they don't think a shop is worth having any more and they're moving entirely online (wouldn't exactly be surprising), but I noticed a "For Sale by Auction" sign outside when I drove past today. It does look as though it's only the shop premises that are for sale though, not the adjoining house (assuming that belongs to Kieron too). James

Are you just getting a bare board, or case/PSU etc. as well? James

Oh, I agree that it should "just work". In this case I imagine that whoever maintains that driver has not had time to make the necessary changes to the code (or perhaps they're no longer able to and the driver is unmaintained). Without looking more into the state of the ACM driver it might also be possible to create a udev ruleset that makes a predictable device name (eg. /dev/arduino) so any unplugging and replugging wouldn't matter. It's a workaround again and requires a bit of faffing about, certainly. Not exactly what you want the less technical user to have to do. I have a nagging feeling that Win7 does actually have some incarnation of a similar problem in the way it assigns COM port numbers. My recollection from of using EQMOD is that unplugging and replugging the mount can cause the COM port number to increase and fairly quickly one reaches the point where the preconfigured drop-down in EQMOD doesn't cover a large enough range, at which point you have to go and fiddle with something in the Windows configuration to reset it. James

As a workaround you may find that once the Arduino has been unplugged, if you run (as root) # modprobe -r cdc_acm then as long as there are no other ACM devices connected the kernel module will be removed and then reloaded automagically once the Arduino is replugged and it should start at ttyACM0 again, saving the requirement for a reboot. I've not tried this to check it works, but it's certainly worth a go. James

Yes, I've done that sort of thing myself to get my UPS to always connect with the same device name, for instance. What I don't like about it from an astro point of view though is that it's way outside the comfort zone of the average user, who doesn't want to be editing udev rules files and really, really doesn't want to get involved in debugging them when they don't work for some reason. What most people really want, I suspect, is to just install a package and have it work without needing to know, for instance, whether installing a udev rules file will just get picked up automagically or if they'll need to force systemd to reload the udev config, or why the system sees their mono Skyris camera and that works without a problem whereas the colour one doesn't at all. It's very hard to achieve that level of simplicity however, though until software authors do I think Linux-based astro is going to remain quite niche. (And then there's OSX, where there seems to be a certain level of expectation that the user should just need to drag your installable package to their location of choice and run it and it should all "just work" James

The only thing that immediately springs to mind is that perhaps you have an x86 VM and the indi-asicam package is only 64-bit (or the other way around)? Either that or it just can't find the indi-asicam package. James

Each USB device can have a serial "number" (actually just a string of characters), so in theory at least you could have as many devices as you like with the same VID and PID and still be able to tell them apart by the serial number. I get the impression that the feature is not widely used however, despite being a far more reliable way of identifying specific devices. Perhaps because it makes the manufacturing process more expensive? If the devices are never unplugged then they may always appear at the same position in the USB device tree which might offer an alternative means of identification. libudev is quite handy for walking the device tree on Linux if you need to do so. Should anyone have any other nice generic ways to uniquely identify individual instances of identical products connected over USB I'd love to hear them because it would be quite a handy thing to be able to do. James

Sounds like a doddle then. Should be done by the end of the evening James

And as regards writing a driver, I'd suggest that it's far less pain and much more portable to write a user-space driver layered on top of libusb than to attempt to do anything at a lower level. It's not like there's a huge performance issue here. Could be useful to plug the device in and see what device class the USB layer thinks it is. It might be something really simple. For example, the SX filter wheels turned out to be HID devices and there's already an open source library to do all the HID interface stuff (libhidapi) which takes away a load more work. And as a bonus it means the code will usually run unmodified on OSX as well as Linux. James

To be honest I think it's pretty clear compared with a lot of legalese. And if it weren't safe I'm sure we'd have seen an awful lot of Europeans who have reverse-engineered systems for the purposes of creating open-source software (including myself, potentially) get sued already. James

Here's a reference: https://en.wikipedia.org/wiki/Reverse_engineering#European_Union James

I'm fairly sure that's not enforceable in Europe. As far as I recall there's a European Directive that effectively enshrines in law the user's right to reverse engineer software and those rights can't be taken away by the EULA. James

Indeed. My recollection is that DistroAstro is based on Mint which is in turn based on Ubuntu. James

Having just read the entire thread... OSX is indeed UNIX-like under the hood. The UI hides pretty much everything for most users, but for developing oacapture I use it from the command line (usually logged in remotely) just like I do for many Linux machines. Apple actually have a long history of producing hardware running UNIX-like operating systems. Twenty-odd years ago I even ported a large COBOL development system to the Motorola 68030-based Mac II (I think?) running some flavour of UNIX. My current preferred Linux distribution is Mint, running the MATE desktop. I just can't get on with Unity. In fact I used Fedora for a long time until they switched to GNOME3, which wouldn't allow me to do a load of stuff I wanted, so then moved to Ubuntu until they switched to Unity which made me jump to Mint. I'm sure Unity works for lots of people though. The way I use a desktop machine is probably quite atypical. People say the learning curve for Linux is so steep, but actually I don't think it's any significantly different for Windows. For most people however the Windows learning curve has been stretched out over many years and they expect to reach the same level of competence with Linux in a matter of days if they decide to switch. I think one of the advantages of the Mint distribution where the newcomer is concerned is that it does try very hard to make everything "just work" as far as possible. There are still areas where it's not as strong as it could be though. For example, I have to configure my particular model of mouse by editing a file manually. James

It's so cloudy here this morning that if someone asked me to point to the Sun I'd have serious trouble getting any more accurate than "up". James

Yes, it appears to get worse as the day goes on here. No chance of hanging about for a while early on either as there's a load of school stuff going on. James

Yes, I've just been looking myself. Most depressing James

In case anyone was interested, that one is linked from here: https://sites.google.com/site/astroblue1/astronomie/brico-utiles James

They look interesting, certainly. I might have to try a couple in the workshop. James

I think that's really pretty good. I have always wondered if the Lifecam might work well on bright targets. I think we know now James

It does look like a very nice bit of kit. I love that they cut the teeth for the belt drive into the focuser knob, too. Not that I've actually got around to motorising my (old model) Steeltrack yet, but it's a smart idea. James

Here is probably as good a place to start as any: http://www.rmg.co.uk/whats-on/exhibitions/astronomy-photographer-of-the-year James

Congratulations to you both on the prize. There are some outstanding images entered this year by the looks of the winners and runners-up. James

I'll have to give that some thought. However, Steve Richards (steppenwolf) has a thread running at the moment about completely automating his dome observatory, so there may well be information there that would set you on the right track. I think I'd definitely go for separate motors for the two shutters though. Trying to combine the two might look very nice but is quite likely to be asking a lot in terms of engineering. Gonzo has some very neat lid openers on his remote observatory here: http://stargazerslounge.com/topic/198091-a-remote-unmanned-pico-observatory/page-8 Even just one of those might work for opening the lower section? James

And it even comes with lots of handy little shelves inside for eyepieces or electrical kit James