Jump to content

NLCbanner2024.jpg.2478be509670e60c2d6efd04834b8b47.jpg

JamesF

Members
  • Posts

    31,960
  • Joined

  • Last visited

  • Days Won

    182

Everything posted by JamesF

  1. Indeed they are. However some (but not necessarily all) of the vendors of cameras manufactured by Touptek, and there are quite a few even just in the field of astronomy, use different USB vendor and product IDs. Actually it is even worse than that, as some use their own IDs for some cameras and Touptek's for others which can result in some surprising behaviour. For instance, at least one of the Altair-branded cameras is no longer supported by the Altair SDK (it used to be in older versions), but is recognised by the current SDKs provided by Touptek for several other brands and works perfectly when used that way, though the SDK will tell you it's a completely different camera. It's possible that the older Altair SDK used to recognise and work with some Opticstar-branded cameras, too. On my development system where I usually have all the SDKs installed at the same time, at least one camera I have is recognised as four different brands (with a different camera name in each case). It doesn't make for an easy time debugging problems... James
  2. With Astroberry everything you need should already be installed, so the output of lsusb is definitely the place to start with this one. James
  3. You either need all the packages from INDI installed (in theory oacapture should just use those if they're present) or to install the libaltaircam package that I provide (from the same place as the oacapture package). The rules file is not always called exactly the same name unfortunately, but if you have INDI installed or libaltaircam then it should be present somewhere on your system. If you do have one of the two installed then the output of lsusb would be useful. There are some Altair cameras that are no longer supported, but I'm not aware that the GP0130 is one of those. I did bodge a workaround for at least one of the affected cameras by patching Altair's library at execution time which certainly means the god of software engineering won't be letting me into heaven when the time comes. It's possible I might need to check that still works if you're using an RPi and have an affected camera. James
  4. Ah, I can see what the problem is there. Some of the camera manufacturers have been rather casual with their use of USB Vendor IDs. The Altair camera is actually the first device in the output of lsusb. I wonder if "MCS" actually originally meant "Mallincam Sky". Anyhow, as a temporary workaround you could try adding this line to the end of /lib/udev/rules.d/70-altair-cameras.rules: SUBSYSTEM=="usb", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0d80", TAG+="uaccess" You'll need to reboot or run "udevadm control --reload-rules" as root and then reconnect the camera after making the change. James
  5. It is indeed interesting. I've generally used UMi when I wanted an estimate of limiting magnitude, but I'll try to give this one a go some time. Sadly however I think the major limiting factor these days is my eyes :( James
  6. Very disappointing I was hoping to see a good landing at last. James
  7. In this case though I can't see mention of the launch here: https://www.spacex.com/launches/index.html My experience is that the launch shows up there even if they don't have a video stream ready to go yet. James
  8. Is there no coverage from Space-X for this one? I can't find anything on their site. I'm watching NASA Spaceflight at the moment. James
  9. Those of us of a certain age will readily recall the expression "Please allow 28 days for delivery" :) James
  10. Hugin is free, but I've not used it for astro work (other than creating a background for Stellarium) so I've no idea how well it might work for you. James
  11. Mint is effectively Ubuntu with a different set of clothes, so I'm not sure why one would work and not the other. Very odd. Is the DMK41 also the FireWire model, or USB? And do you get any errors when you try to catpure data using it? James
  12. I don't think this can be a configuration problem then. As far as the configuration is concerned there should be no difference between the device being connected at boot time or reconnecting later on. That the RPi crashes when the camera is reconnected makes it sound like it could be some sort of hardware issue, but I thought those were all ironed out now. Probably my next step would be to remove all the QHY packages from the RPi and try powering down and reconnecting the PoleMaster again. If that still crashes the RPi then it does look like an OS/hardware issue. If it doesn't cause a crash then we'll need to find a way to debug what's going on somehow. James
  13. I've had this problem and I may well have posted here about it, but for the moment I'm totally unable to recall how I resolved it. I'll see if I can find the relevant thread and let you know. James
  14. Hmmm. I wonder if the PoleMaster isn't being correctly configured when it is plugged in and then the QHY library is failing because it can't talk to the camera? Could you give me the output of "lsusb" with the camera plugged in, please? Thanks, James
  15. Hmmm. Segmentation faults are never good :( I wonder what's going on there. The "Open QHYCCD error" is a message from the QHY library rather than oacapture or oalive. At the moment the only thing that occurs to me is that the application doesn't have permission to open the USB device for the camera. Could you try unplugging and re-connecting the camera, and perhaps if that doesn't work rebooting the RPi? If that doesn't work then some deeper digging may be required. James
  16. Give oacapture a whirl. I think I've tested it with a Grasshopper and I've tested FireWire cameras, but not a FireWire Grasshopper that I recall. If it doesn't work then I'll try to fix it for the next release. You shouldn't need any drivers other than what is supplied with the OS or the application. It needs a little more work to support live streaming, but I think most of what is required is there. https://www.openastroproject.org/downloads/ James
  17. It appears to work fine for me on an Intel Core i5 machine with 16GB RAM. There appear to be very few external dependencies and they're very common ones, so I doubt you're missing any of those. I think the first thing to check would be that your CPU supports the AVX instructions. You should be able to do that just by running: $ grep avx /proc/cpuinfo If that produces any output then it looks like you should be ok for that. If it doesn't then you'll probably need copies of the tensorflow libraries that don't require AVX support. James
  18. Presumably if you buy from TS you'll have to pay shipping, duty, VAT and admin fees on top of the purchase price which could inflate the total cost to something closer to Altair's price. And then if there are any problems that mean shipping it back there's a bundle of fun going through the customs stuff again in both directions. In the case of Astroshop you may need to confirm the actual price with them. My understanding was that for purchases of this sort of value the retailer doesn't charge VAT and you have to pay it yourself on delivery, yet their price claims to be inclusive of VAT. It could be that they're just quoting the EU sale price in sterling and haven't caught up with the post-Brexit changes yet (or don't think it's worth their while to do so). James
  19. I can't help you with Windows 10 I'm afraid, as I don't use Windows at all unless it's totally unavoidable. I believe the camera does still work on Linux and therefore should work with a Raspberry Pi, for instance, but that doesn't help you much :( James
  20. I can try it here if that would be helpful. Probably would be useful if you gave me the exact link you downloaded from, just so we can be certain that I'm running exactly the same thing. James
  21. Ah, yes, that looks like it is the reason. There are a few more details here: https://github.com/tensorflow/tensorflow/issues/24642 It looks like a workaround is possible if you build the tensorflow stuff yourself. Or possibly it can be installed from MacPorts. It appears that v1.15 is available for Snow Leopard from MacPorts, so perhaps it will also be available for 10.11? James
  22. I'm not certain, but it looks as though it may well "just work" if you can find a suitable version of python for El Capitan and then follow the instructions on the github page for the project. James
×
×
  • 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.