Jump to content

vlaiv

Members
  • Posts

    13,265
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by vlaiv

  1. There are couple of conceptual flaws with the design. 1. Use of lens instead of small telescope It apparently uses 300mm F/6.3 lens to cut down costs. Better choice (and cheaper) would be something like 50mm ED F/4.8 SW finder. It would have more aperture, more transmission because of lack of massive central obstruction and mirrors. Furthermore, lens are optimized for both far and near. Simple design like that is bound to have spherical aberration for either far or near. My guess is that they optimized it for near since it is terrestrial lens. Astronomical telescopes are optimized for infinity. If you look at moon image in that article - you'll see that it is blurry. My guess is that it is down to spherical of the lens. 2. Use of the camera with 1.55µm pixel size. That is simply waaay over sampling for such a small aperture. Even if we take planetary / lucky type imaging with diffraction limited optics (which that lens is not) - it would take F/6 scope with such pixel size. That requires steady atmosphere and taking thousands of very short exposures.
  2. Yes, it looks like new model. Old model looked like this: Just short Vixen type slot with two bolts. I upgraded mine to this: Which looks rather similar to stock one that is delivered now. Yes, new one looks like it accepts both type of dovetails.
  3. Here is setup that I used on several occasions: it is 8" F/6 OTA that weighs at about 11Kg with 60mm guide scope and camera (total weight less than 15Kg but not far from it). Overall setup is quite heavy - it needed 3x5Kg counter weights to balance it out. I haven't used it for visual - but I did for imaging. While it worked for me for imaging - it is not something I would recommend to people to actually do. Planetary imaging is fine, but long exposure imaging is really pushing it. For visual - it will work ok as far as weight is concerned. Not sure what the damping time will be when focusing - but probably better since you have wooden tripod. In the mean time I modded my mount - it is now on Berlebach planet tripod - and it makes huge difference to stability. I also changed stock clamps for Vixen/Losmandy dual saddle from Geoptik. I added belt mod - not something that you'll need for visual though. First two mods - I would recommend. You already have wooden tripod - but also - put different clamp as well. Use Losmandy dovetail if you can - they are larger and more stable.
  4. I place mine so that it almost starts to cast shadow on sensor. I sometimes see edge of it starting to intrude on flats. Here are flats on two different occasions - shadow creeping in from the bottom in both cases is shadow of prism. It also shows where I place prism - along longer edge of the sensor - that gives me more room for it to be pushed towards optical axis.
  5. Visual or imaging? For imaging - you'd be surprised by the lack of difference. All those things that create better visual appearance - local contrast, better strehl / tighter PSF are simply overcome by use of wavelets and subsequent sharpening of images. That is the reason why we never can have as good view as images we produce with our scopes - and the reason why SCTs for example produce excellent planetary images although they have 33%+ CO.
  6. Never saw such stars, but it is not uncommon to have distorted stars at the edge of the field where OAG operates. Star to the right in above screen shot are closer to optical axis and still "concentrated" while those on the left are starting to show signs of field curvature and astigmatism. That is OAG fairly close to optical axis on 8" RC (about 10mm away from optical axis or so - it is part of FOV next to shorter side of 17.7 x 13.4 mm sensor).
  7. That second thing - ALPACA allows INDI/INDIGO devices to be identified / used as ASCOM devices. With INDIGOSky running on RPI4 I load Alpaca agent and define which INDIGO devices (mount, camera, etc) I want to expose over ALPACA interface (it is form of REST over HTTP for controlling devices). With ASCOM I can "create new device" - when I open any software that works with ASCOM devices and I open "device chooser dialog" (for example one that lists telescope mount ASCOM drivers installed in the system) - there is option to manually add or discover (auto discovery works good) remote ALPACA devices. With auto discovery - I already get my mount from INDIGO in the list - and I can connect that as if it was local ASCOM device as far as application is concerned. Both my SGP and Stellarium though it was regular ASCOM device connected directly to my windows machine - but in fact it was bridged by alpaca to RPI running INDIGO. If I install NINA - I'm sure it will also work with mount / camera in that same way.
  8. Yes, updated to Stellarium 0.21.2 which gave me ASCOM telescope plugin control and it was simple as choose, connect - select Vega and slew! And it went onto completely different part of the sky This is because apparently things were not synced at the beginning - but when I parked it / unparked - next slew went where it is supposed to go. It works. Simple as that. Next, I'll need to try my imaging camera and possibly build dark library that I'll use on next clear night (which could be this weekend - full moon and all)
  9. It works. I'm able to control mount from SGL (limited, park / unpark and things that SGL provides - next up will be stellarium and PHD2). There is auto discovery that works like charm - just needs to be enabled in Alpaca menu of ascom device chooser dialog. Have to go and do some errands now, but will try other stuff (including camera control) when I get back.
  10. Check out this thread that I started in parallel to this one:
  11. Found it! By default, Alpaca devices use port 11111, probably because that is default port of ALPACA remote server for windows (equivalent of Alpaca agent under INDIGO), but it should be using 7624 port of INDIGOSky web server. Just issued get on that url and got reply: Going to give it a try now.
  12. Depends how I image. So far, I've been doing it "in the field", but since I moved to a new house - I'll be doing that in the obsy once it is finished. That involved Windows 10 laptop and me being next the mount and all - that was setup with my regular Heq5 + serious scope and serious camera. I now want to do some light wide field imaging with AzGti in EQ mode + small sensor and fast lens, and I want to do it remotely to minimize fiddling in the dark in my back yard which is full of building material and scrap still (my house is having facade finished as we type ). All I want to do is take "grab&go" imaging setup and run one power cable. Everything else would ideally be remote. Hence all that RPI + INDIGO stuff. I already acquired that equipment and fiddled a bit with it before (last year and this spring) - but at the time INDIGO was not this far along as it is now - which opens up new possibilities that I want to exploit. Ideally - I want not to change my workflow too much - that means Windows station, but with remote capability. What I'm investigating now seems like ideal option. RPI4 loaded with INDIGO server that is ALPACA enabled and connecting remotely from my windows machine as if using ASCOM drivers locally. That will enable me to use SGP and PHD2 which I'm used at from the comfort of my study.
  13. Exactly as described - as remote station to control the mount and all. I'll be using AzGTI that is wifi connected (don't use cable for that), ASI178mcc that will be USB connected to RPI and guide camera ASI185 that is again USB connected to hub on ASI178. I could do some sort of elaborate long USB cable - but I don't want to complicate things and add more expense if I can make everything work as is with the gear that I have. I've installed ASCOM 6.5 platform and figured out how to use Alpaca agent and driver - just need to get them connected as they seem not to talk at the moment (I'm fairly certain it is some sort of firewall issue or wrong port or something).
  14. Actually - there is now Alpaca menu in telescope chooser dialog I'm trying to connect to RPI Alpaca device but so far failing. Could be that firewall or something is causing trouble. Will need to check it out.
  15. Ok, no idea how to get it running I loaded ALPACA agent on INDIGO, I exposed my mount thru it - and I now have no clue how to connect to it: I don't have any drivers that would be ALPACA remote mount or anything like that?
  16. Update performed and now to see how it all works
  17. So simple upgrade and nothing special - download and install over existing version as all other upgrades?
  18. RPI can't run windows os as far as I'm aware (yet - not sure if there are any plans to port it - or any version of it), so that sort of excludes dual windows setup in my case. As far as I can tell - Indigo has alpaca agent implemented - which should expose other devices drivers loaded in indigo as ascom alpaca devices on that particular RPI. In theory it should work - connecting from windows box (which I do have and run in my study) to out door RPI installation
  19. I want to use software that I'm already used to / paid - like SGP. As far as I understand, SGP won't connect directly to INDI/INDIGO drivers as it is build for ASCOM. I know that Alpaca is just another layer, but as far as I can tell - not really that "heavy" layer to be much of a concern - like in creating latency or whatever.
  20. I still need to figure out couple of things. Agents for example - do I need them running, or can I just use drivers remotely. Or rather - do I benefit from them running. It seems that I can go by just fine without using agents. Another thing is that ASCOM ALPACA thing. That sounds seriously good and the way forward. I wonder if it will actually work. Need to test it ASAP. Just afraid that if I install ASCOM 6.5 - I'll mess up my current installation of 6.3
  21. It's more than that - it is ASCOM alternative rather than just EQMod - EQMod is ASCOM mount driver for Synta/Skywatcher mounts. In fact - giving that it implements ALPACA protocol, INDIGO is addition to ASCOM ALPACA infrastructure (if it works - yet to be tested).
  22. If I understand this correctly - INDI on RPI + Kstars / Ekos on indoor device is pretty much the same setup as I'm planing on using with INDIGO - INDIGOSky on RPI + It's own imager (Ain imager / INDIGO imager) running on indoor machine. Alternative to this would be (and I'm hoping it will work) - INDIGOSky on RPI / ALPACA agent + ALPACA ASCOM 6.5 on indoor Windows machine + any ASCOM compatible software that I already have - like PHD2 / SGP. I know about RPI connectivity issues, and I'm planning to put dedicated AP outside as both mount and RPI4 use wifi connections (as I have them configured at the moment). I like the idea of INDIGO as I can use my mobile phone/web client in initial phase of setup: polar alignment and focusing (no motor focuser yet).
  23. At some point - I had exact same thought - but using laptop screen instead
  24. I thought so too and was surprised. Both imager and control panel app have been released as freeware for Windows platform: I actually downloaded, started imager app and connected to my RPI4 INDIGO server and moved mount with said applications.
×
×
  • 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.