Jump to content

Banner.jpg.b83b14cd4142fe10848741bb2a14c66b.jpg

AngryDonkey

Members
  • Posts

    452
  • Joined

  • Last visited

Posts posted by AngryDonkey

  1. A real shame that you had such trouble with your two Avalon Fast Linears as it is a great mount (when working as it should). Do you think that the problems with the second mount were down to the seller or Avalon (or did you buy direct)? What problems did you have with SGP? I've never had any issues with SGP (with the StarGo version of the linear). Maybe third time lucky?

    • Thanks 1
  2. 16 hours ago, JonCarleton said:

    Can an ASCOM server talk to an INDI server.

    Although the comms protocols might be similar, the fundamental philosophies behind each framework are quite different which will reduce compatibility e.g. ASCOM implements a fairly strict interface whereas INDI is a lot more free form. Also the way messages flow push/poll is different. I'm sure it could be done somehow (the now retired wIndi server did expose ASCOM devices to INDI I believe) but I'm not sure the benefits would outweigh the potential issues of working across two frameworks.

    1 hour ago, MCinAZ said:

    "Do Alpaca drivers work with ASCOM on Windows machines, and are vendors going to provide universal Alpaca drivers rather than ASCOM-specific drivers going forward?"

    Drivers need to be written for a specific system (Windows/Linux) so the Vendor will still need to write two drivers if targeting both Windows and Linux. For Windows however the 'normal' ASCOM driver can be exposed over Alpaca so it doesn't need a separate 'Windows Alpaca' driver. Not sure if Vendors will buy into this but there is certainly a market for RPi based devices at the scope end.

  3. 8 hours ago, oyabuns said:

    Yes, it was said that ASCOM Alpaca wouldn't be OS dependent. However, as far as I see the server module for Alpaca needs Windows + ASCOM framework to work.

    You only need the 'remote server'/'ASCOM remote' part if you want to use an existing Windows client (running on normal ASCOM) to connect to an Alpaca device driver (over the Alpaca API) or if you want an Alpaca client to connect to a regular ASCOM driver on a Windows machine. So it really only comes into play if you want to include some component running under the 'old style' ASCOM framework.

    I think the arrows in the diagram are a bit misleading, you can remove the entire left hand side of the diagram and it will still work i.e. you could have an Alpaca client running on Linux connect to an Alpaca driver running on the Raspberry Pi. Not sure what the rules are on posting links to other forums but if you look on cloudy nights and search for a recent thread called 'Raspberry Pi and Alpaca' there is a guy who has just done that i.e. developed a Linux client and RPi drivers via the Alpaca API. I don't think it is released yet but it shows what can be done.

    The problem at the moment of course is that there are very few (if any) Alpaca drivers and clients available at the moment. It's a bit of a chicken and egg situation and time will tell if it finds any traction... As has been said above, if you need something now (and you don't want to write your own drivers etc.) then its better to stick with the other suggestions. I also find the INDIGO framework to work quite well.

  4. 28 minutes ago, MarkAR said:

    I wouldn't bother, ASCOM is Windows. You need to look at Astroberry or INDI.

    This is not quite correct. ASCOM Alpaca does not require Windows nor does it need the original ASCOM framework to work. As a protocol I think it has a lot of potential, there is however very little support for it at present in terms of drivers and clients. Hopefully this will change...

    • Like 1
  5. I have an Avalon LFR and it has been superb.

    I currently use it with my mobile dual scope imaging setup which weighs around 18kg and it doesn't seem to cause it any issues. It has been reliable and tracking is good, it needs to be guided though (due to its design). I would definitely call it portable in size and weight. The only slight negative I have noticed is that it is susceptible to wind.

    Hope this helps!

  6. 28 minutes ago, gilesco said:
    3 hours ago, AngryDonkey said:

    I think that is a bit unkind.

    Don't misinterpret me, I'm not disparaging the software, nor am I a free software zealot. I was just putting forward my own experience with free software, and musing about the subscription model. I do actually have a subscription to APP for image processing, the pricing model is slightly different - you can opt to buy, with the threat that v2 will not be available to you, or rent and have free upgrades for the term of the subscription. I opted to rent for one year, and buy later if I dont feel v2 is going to (a) happen anytime soon and (b) will improve my results significantly.

    I only wrote this because you suggested that they are not trying to compete (and rely on the fact that people don't want to invest time in learning a new system). I don't think that is the case, on the contrary I think they do want to compete which is what all this is about I guess.

  7. 2 hours ago, gilesco said:

    It looks to me that they're taxing their existing customer base rather than trying to compete, as it is their existing customer base that see the cost (as in effort) of the new learning curve of trying to get Kstars/Ekos to work for them.

    However, if their existing customer base choose to make the jump, and they don't offer something new that isn't available elsewhere for free, then there will be less money for them to continue to develop the software, and the product will eventually dry up.

    I think that is a bit unkind. I love open source software (and contribute) but it is not the only way. Often in smaller projects there is a large user community but most of the actual work is done by very few people who either are happy to give their time for free or have some other revenue stream derived from the open source offering (e.g. Stellarmate). Sometimes they drop out or have to shift priorities and projects can also dry up. Not saying that that is the case with Ekos or NINA (on the contrary) but it can happen.

    If you have a good product and you support it well then there is nothing wrong with charging for it. I think SGP has been suffering a lot because it didn't have a steady income stream (one update that had to be paid for in 10 years) which meant that support was sometimes poor and features very slow to emerge. With the new subscription model you are paying for updates but more importantly a new kind of 'Premium Support' which was not available before. I think this will be welcome by many, especially in this game where most of the problems are combinations of many things, not easily disentangled.

    Personally I think SGP is a good product and if it comes with steady development and good support then I am happy to pay for it. Of course this is not for everyone, but that's absolutely fine. I tried Kstars/Ekos and it didn't work well for me at the time but that doesn't mean that its not a good product. I think its great that we have a choice.

    • Like 1
  8. 4 hours ago, tooth_dr said:

    I have to admit I dont know much about streaming, VLC etc.  This may be a post for another thread!  I'm currently using AllSkEye software with my Oculus.  I have the FTP settings to direct the latest image to my domain, and I open up the page on a web browser and I can see the latest image.  I wouldnt know where to start if it wasnt being done through AllSkEye camera, but it may indeed support the 120 now?

    Hi Adam, yes the ASI 120 is generally supported in AllSkEye. If it is an older version ASI 120 though it can sometimes be problematic because the driver for these cameras was never really fixed and seems to fail a lot with some setups. It is really dependent on your computer and USB cable though so still worth a try if you want to go down that route.

    Mike

    • Thanks 1
  9. Application settings are usually stored in folders associated to user accounts (where the logged in user can make changes). So disappearing settings could be related to that. For example if you run an app with elevated (admin) privileges, the user changes and different folders / settings are used.

  10. On 08/06/2020 at 17:47, tomato said:

    Yeah, the absence of the larger mono CMOS sensors is a problem (the ASI 6200 being the exception but it’s high end spend), that’s why the next camera spend for myself and @Tomatobro’s portable dark site rig will likely be a KAF 16200 CCD.

    I'm in a similar position. I would LOVE the new mono ASI 6200 but adding the wheel and filters (yikes!) it amounts to much more than I want to spend. So on a whim I've bought a (really cheap) second hand Moravian G3-11000 for my William Optics FLT 132. The KAI 11002 is a really old sensor now and looking at the quantum efficiency graph makes me weep but you know, if I think abut the awesome field of view and the complexities of a mosaic I would have to make otherwise I think it's not a bad decision, especially for LRGB.

    And Moravian is developing a camera similar to the ASI6200 so hopefully I will be able to reuse the filter wheel, guide camera and filters once they become available on the seocnd hand market (I am thinking a few year ahead :-))

    • Like 2
×
×
  • 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.