Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

MCinAZ

Members
  • Content Count

    73
  • Joined

  • Last visited

Community Reputation

25 Excellent

About MCinAZ

  • Rank
    Nebula

Profile Information

  • Gender
    Not Telling
  • Location
    Northern Arizona
  1. What may be happening is that oaCapture is confusing the USB device for an external timing module (the Timer device shown in the list of dropdowns at the top of the screen), then waiting for a response it never receives. I'm certain that this can happen if a USB device which uses a Cypress USB/serial transceiver is connected when oaCapture launches. I don't know of a way to convince oaCapture to ignore the USB device, though perhaps James can suggest a workaround. There is a way to distinguish between a timer and other modules which may use the same USB/serial transceiver, but that remedy is not incorporated into 1.7.0. You might try connecting the USB cable for your mount after oaCapture is up and running. I know the program looks for a timer if connected when it launches, but I think it's necessary to rescan if the timer is connected after oaCapture is started. If the hang you describe is related to the situation I described above, starting oaCapture first may get you going.
  2. It appears that you can do what you'd like if you have installed ASCOM. https://docs.sharpcap.co.uk/3.2/#Filter Wheel Control
  3. Unless there's something in Mint 20 that's not in Mint 19, perhaps things would go more smoothly with the earlier release. Mint 19, like Ubuntu 18.04, will be fully supported for a while yet, which will allow time for the developers and package maintainers to catch up with all the new libraries. I've reinstalled since, but I'm pretty sure I had oacapture-1.7.0 and INDI/Ekos/KStars installed on this machine previously when I was considering a move from Mint to Ubuntu. That was an 18.04 installation. I didn't see any issues with library conflicts (though I have to say, I found KStars to be quite disappointing. But that's a rant for a different day.)
  4. So as not to hijack Dr_Ju_Ju's ASCOM-6.5 release thread, I'll start a new one. As stash_old noted, alpaca allows for operation across different machines and architectures. Beside CCDCEIL, Bob Denny reported in a recent YouTube video that OPTEC has networked focusers which are supported by alpaca. What's not clear to me is whether an alpaca driver works on a Windows PC under ASCOM. If not, i.e., a device running in a Windows environment would need an ASCOM driver, but in order for the same device to work in a Linux or MACos environment it would require a separate alpaca driver, then I don't see much future for alpaca. It's basically just doing what INDI set out to do 15 years ago. After all that time, I don't know of a single device which has a factory-supported INDI driver. While there are certainly INDI drivers for some hardware devices, virtually all were written by (usually unpaid) third parties. Few manufacturers will be willing to develop and support separate ASCOM and alpaca drivers so long as Windows/ASCOM dominate the amateur market. One of the other near-requirements for alpaca is that devices be interconnected through Ethernet rather than across USB. While this has many merits, the vast majority of existing hardware devices utilize USB, and I don't see that changing too quickly.
  5. An important question, alluded to by others, concerns your intended use of the telescope. If you will primarily be imaging, you will likely have enough room. For visual observing, it may be tight. Some scale drawings ought to help you see how things might fit. If things are a bit close up top, it may be advisable to lower the mount a bit. At worst this might cost you access to the horizon, though that's generally a simpler trade-off than going into a larger dome.
  6. Thanks to James for his ongoing efforts to support this very useful package. Entirely as a result of the discussion about the recently released 8 GB Raspberry Pi Model 4 started by stash_old on 05-26, I just happened to take delivery of one of those units last Friday. I've completed installation of oaCapture-1.7.0 under the official Raspberry Pi OS (formerly Raspbian) released 2020-05-27 from the packages on the Open Astro Project downloads page. A few notes which may be of use to anyone else installing in an environment where oaCapture has not been installed previously. First, there are some dependencies upon packages not included in the default Raspberry Pi OS distribution. These are listed below. Install in the order shown (there may be dependencies upon libqtcore4 for the other Qt packages). libcfitsio7 libhidapi-libusb0 libqtcore4 libqt4-network libqtgui4 Among the packages on James's download page, libqhyccd depends upon the QHY firmware, so you should install qhy-firmware_20.5.24-1_all ahead of libqhyccd_20.5.24-1_armhf. I installed libefwfilter_0.4.1022-1_armhf and libuvc_0.0.6-2openastro4_armhf, though I don't know if that's significant. Since I was missing a few packages on the first attempt, I had some broken packages but running the following command made everything happy: sudo apt --fix-broken install So far, I've only launched the program as a remote X application, but it came up quickly and looks to be functional. More testing with the cameras I have available to me (along with the mysterious Timer device) to follow. I'm particularly interested in seeing how things go with oalive and our collection of Canon DSLRs.
  7. I'll second the suggestion for stainless hardware, but be sure to apply anti-sieve to the threads before assembly or you'll likely be back in the same boat the next time you need to remove the fasteners. If it were me, I would go with button head socket cap screws.
  8. I've put piers into three different observatories, and none was more than about half a meter in diameter and perhaps 800 mm deep. These were isolated from the surrounding floor, but if you already have a concrete floor in place, I'd give that a go and worry about an isolated pier only if it proves necessary. For short focal length work where you can limit vibrations from people walking around during critical times, you'll almost certainly be fine. I've seen plenty of home observatories with a cubic yard of concrete underground. In almost all cases, the only benefits are to the concrete supplier and the owner's ego. What I find most amusing are the installations with literally tons of concrete supporting a mount on three 150 mm long pieces of 12 mm diameter threaded rod. Nothing says stability like putting a large, moving mass on a tuned structure.
  9. Do you have any way to see traffic between Ekos and the mount driver or between the driver and the mount?
  10. I note some mild correlation between darker green squares and my email exchanges with James. Not that I in any way make it a point to be a troublemaker, mind... :-)
  11. I've used FTOOLS (https://heasarc.gsfc.nasa.gov/ftools/) for this sort of thing in the past, though in a native Linux environment. Installation documentation mentions that you can run on Windows using Cygwin, or of course in a VM running Linux. There's also the CFITSIO library, which is very useful if you want to write your own code.
  12. At Lowell Observatory in northern Arizona, we have a number of Anker USB 3.0 hubs which have performed reliably in sub-zero C conditions. They look to be reasonably priced through our president's favorite mail order retailer.
  13. At Lowell's half-meter telescope, we've got a pair of 5 m USB 3.0 extenders which just barely reach from our computer shelf to the mount. One is dedicated to the mount itself, while the other is connected to a 12-port hub up by the telescopes. This works quite well, though we've seen issues with some devices if the extender is connected to a hub closer to the computer -- daisy-chaining USB hubs is generally not a good idea, so don't do that. The reason for so many ports is that we have two telescopes on the mount with several cameras along with focusers and other instruments. Not all will ever be operated simultaneously, however, so bandwidth isn't an issue. I had no previous experience with USB extenders, but so far I haven't seen any down side to using them.
  14. A variation of this has the motor and drive pinion on a pivoting plate attached to a fixed wall, with weights and/or springs used to provide engagement force. That makes for fixed wiring but still accommodates inconsistencies in the rack. There are generally three challenges associated with these types of drives. The first is start-up torque. If the motor spins up very quickly, the system can experience very large forces as the inertia of the roof is overcome. A high gear ratio which results in slower opening speed is probably the simplest solution, though in some cases DC motors are used and ramped-up to speed. If the gear drive doesn't allow for back drive (e.g., a typical worm drive), you also have to pay a bit of heed to ramp-down at the other end of travel. With a belt or spur gear reducer, you can probably get away with setting the limit switches such that the roof coasts closed approximately where you want it. A second concern is stalling during movement. If something jams, you want to be sure that some mechanism stops the motor before anything is damaged. As Stub noted, a fuse may be sufficient protection. This is always more of a concern with unattended operation since there probably won't be anyone around to hit the stop button if things start going wrong. Finally, loss of power or a drive failure needs to be considered. The last thing you want is the roof stuck open as weather is moving in. If there's a mechanism which allows override using a separate motor such as a surplus drill, that's a good start. But again, if there's a worm drive which may jam, you should probably consider options to disengage it entirely. This usually isn't too difficult with a pivoted mount if the contingency is considered during the design phase.
  15. Those latches look a lot like what I had in mind for my last build. I never found any at the time, but a pair of 6" C-clamps did the job. Not elegantly, but effectively, anyway.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.