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.



  • Content Count

  • Joined

  • Last visited

Community Reputation

409 Excellent

1 Follower

About halli

  • Rank
    Star Forming

Profile Information

  • Gender
  • Location
  1. Hi - if anyone is interested in the solution to this...... It was eventually solved by removing the Atik drivers specified above and installing the Atik Indi driver from the cloudmaker site ! This worked first time with the Atik EFW2 wheel...........
  2. Thanks Radek. I have checked my Atik drivers using the command you suggested with the following result:- ii indi-atik 2.1~201901081329~ubuntu16.04.1 amd64 INDI Driver for Atik cameras and filter wheels. ii libatik 2.2.4~201902271745~ubuntu16.04.1 amd64 Library for Atik Cameras. Looks like the library is the same but the driver is different to yours perhaps because its amd64 ? However they are not the most recent it seems ? Perhaps I should upgrade them to try and solve the problem, if so which command would do that ? Thanks again for your help with this
  3. Thanks for your responses Wim, Stash and Radek I am assuming that the problem is related to the Kstars/Ekos build and not the driver since it was the update to this that caused the problem. Dont think it is the EFW2 itself as the problem manifested when I updated to Kstars v3.1.0 - Jasem has stated that the build of the driver is incorrect in this version but since then has stopped responding ! Are you using V3.1.0 Radek ?
  4. Ok thanks very much for your response - do you know where this is located please ?
  5. Hi I have recently moved from Windows/Ascom to using Indi via Kstars/Ekos and Ubuntu. I found the raspberry Pi a bit underpowered for a full imaging rig and therefore installed Ubuntu on my Laptop together with Kstars/Ekos to improve performance. The system worked fairly well until Kstars was updated to v3.1.0 from 3.0.0 recently, unfortunately I found that my Atik EFW2 filter wheel driver kept crashing with v3.1.0. I raised this on the Indi forum and Jasem the Ekos maintainer said that the Atik driver had not been built properly on v3.1.0 and he was going to rebuild it. However since then no rebuilt driver has appeared and I am now stuck. I can now no longer use my rig as I cant change filters and am stuck with v3.1.0 that does not work with my Atik EFW2. I would have though this would affect all Atik wheel users who have updated to Kstars v 3.1.0 ! Is there anyone out there who has solved this problem and can help me move forward please ? Any help greatly appreciated ! Thanks in anticipation
  6. Nice info Stash - I like the 5v 3A DC convertor option. I may just get one of these as they are quite cheap - I have mains available in the garden but it would be quite useful for portability. I tend to use a mobile power bank for 5V power for things like powering a star adventurer and dew control bands instead of lugging a 12v battery around but it is not man enough for a Pi !
  7. Thanks Ken all good info. I had another session with the rig this afternoon taking images of my scope dust cover ! I was using Wifi this time and surprisingly I managed a fairly long image capture session and it was pretty stable. This is quite encouraging . I have normally used the powerline LAN extenders in the past for using team viewer with my laptop because the wifi is a bit weak at the bottom of the garden and the LAN was quicker. It looks like the Pi is able to connect and perform as normal even though the wifi signal is not that strong. It may be that the Pi was being upset by hanging 70 feet of copper power cable from its LAN port and the crashes were due to some form of noise spikes . Who knows, I guess time will tell but for now I will stick with the WIfi as the performance appears to be adequate for the moment. I have also found that the solver works fairly well at short exposure and high binning. This surprised me as I found that Astrotortilla was very fussy in this area and I needed to use the lowest gain with a longish exposure to get it to work. I would really like to get PHD2 working reliably and need to spend some time concentrating on getting the GPCAM to connect. I dont understand why I got it to work previously and now it doesn't want to know. It connects ok every time to Ekos and works on the internal guider so it is very frustrating. I have ordered the Pi recommended supply but fingers crossed the stability I experienced using wifi this afternoon will continue.
  8. Thanks Ken and Stash for your valued input - it is appreciated. I guess I will persevere and try a few things to try and improve performance. Firstly the PSU - I guess I will obtain the recommended Pi PSU just to rule this out - your UBEC idea also seems a good way forward Wrt the powered USB hub: The ZWO camera contains its own powered USB hub so I believe I fulfil this requirement - I only have one USB lead attached to the Pi so dont see how I can improve on this. Good thought on the use of the LAN using the same bus as the USB - I hadn't realised this. I think I can connect via wireless - just thought the LAN extension would be better even if using powerline - but it may not be. I will try it out with the wireless connection. I agree that using PHD2 externally is the best way forward for guiding as at least there is another bit of software which will maintain connectivity to the mount in the event of Kstars/Ekos crashing ( I am assuming !) . When this happens the EQmod mount normally disconnects, tracking is lost and the target drifts away from centre and needs to be realigned when it is restarted (very frustrating). In fact I was going to use PHD2 and managed to get it to work previously and the performance of the guiding was excellent. Unfortunately I couldnt get the GPCAM camera to connect to it during the last couple of nights hence I used the internal guider. The PHD2 performance was one of the things which spurred me on to put the effort in to getting the Pi set up to work as I felt that a Linux approach was better than windows for this type of real time control. I take the point about the importance of the network connection when using a client/ server approach with a separate Kstars instance on windows. I was trying to download the images to my desktop when using the windows Kstars (to save downloading them from the USB stick !) so that could have been a contributory factor I see you are both feeling as I that perhaps this is all too much for a Pi however there are a number of commercial boxes eg stellarmate, Atik Air, ASI air which appear to be based on the Pi ! Perhaps the software is better - who knows. Anyhow it was good to have the benefit of your experience and as a result I will make several adjustments to the way I am doing things and see what happens.
  9. So near and yet so far ! Ive just spent some time over the past two nights with clear skies playing around with Kstars/Ekos and the raspberry Pi controlling my kit. I thought I would share my experience. Firstly my imaging kit comprised a 130pds scope with ZWO ASI 1600mm-c , Atik EFW2, NEQ6 and Altair GPCAM for guiding. I have been able to connect the Pi via some TP-Link powerline LAN extenders from my garden to my home router. In order to do this I have found that you need to turn the WiFi permanently off - or at least I had to ! The Astroberry IP address needs to be obtained from the connected device table from the router. This can then be used in a browser to connect to the Astroberry image in the Pi . It appears to offer quite a stable remote connection. The ZWO has a USB hub and the EFW2 and GPCAM are connected to this with one USB connection from the ZWO to the Pi. The NEQ6 was conneccted using EQMOD over Bluetooth. I had previously spent some time ensuring all the kit connected to Ekos ok and was ready to be used in anger. I also plugged a USB stick into the Pi to save images on. My aim over the last couple of nights was to test the plate solver , guiding, and image capture capability of the rig using Kstars and Ekos. From a user perspective I found the control console approach of Ekos where all required functions for mount setup, control and image capture which were presented on a separate tab from a single entity and also their simplicity to be excellent. However the settings and config the INDI control panel offered sometimes overlapped with those of Ekos which was a little confusing. The integration of this within the Kstars planetarium was also a very good concept. However this also had a downside when it came to performance as highlighted below. Unfortunately I found real time performance of the system unreliable and patchy. Sometimes I could go through the astrometry solver, image preview, guider startup ( I used the internal guider) and image capture sequence without a hitch although this was the exception. I managed on one occasion to complete an image capture sequence of 20 LRGB images of M81 and M82. Usually however during the workflow Kstars/Ekos would crash and disappear without warning or some driver or another would crash or the Indi server would disconnect for no reason. All very frustrating ! I think some of it was my fault in pushing things a bit too hard and having too much going on at the same time - I guess the control console type presentation was a victim of its own success in this respect as it was all to easy to jump from one function to another . I felt the CPU in the Pi was perhaps operating at the edge of its capability when put under stress by going through some of the image capture routines. Certainly I was disappointed as I feel with things like they are it is not useable as a reliable controller of my imaging rig and wouldn't know how to put things onto a more stable footing. Certainly quite frequently the Kstars/Ekos software would crash in the middle of an imaging run and this was very frustrating - and as Ekos and Kstars are on one platform when they crash you loose everything ! My style is to set everything up to do an imaging run and then go to bed, so one thing that is paramount is reliability !! I also tried using Kstars/Ekos on windows on my desktop to interface to the Pi just operating as an INDI server rather than just using VNC over the LAN to perhaps reduce some of the load on the Pi and although I connected to everything pretty well - as far as real time performance - if anything this was even worse ! Not sure where to go from here with Ekos/Kstars - perhaps try and establish whether there is any pattern to the crashes, but they appeared pretty random to me. My rig isn't anything unusual and I dont think it was just my finger trouble. Even finger trouble shouldn't have caused software to just crash and close down. I really do not want to give up on this as it has so much potential for the user and is an excellent concept. I would really appreciate knowing what other people's actual experience is of using Kstars/Ekos on the Pi in anger for imaging - in order to judge whether there is something basically wrong with my approach and whether there is something I am overlooking. Sorry its a bit of a brain dump ...................
  10. Tried astrometry just recently using the Kstars/Ekos on the Pi with Astroberry and it worked fine with the offline solver now I have downloaded the missing 4211 index file ! I was using the CCD and telescope simulator with astrometry as aux However you need to configure your CCD resolution and pixel size as per your real CCD and also the telescope for aperture and focal length as Stash mentioned above or otherwise the range of index files chosen will be wrong.
  11. Thanks Stash I'll take a look at that. Understand what you say about testing and I agree - best not to waste more of clear skies than you need to ! The trouble I find with testing under clear skies is there is always a pressure to complete it and to get a full imaging rig up an running always seems to have its niggles which can delay things and then the clouds roll in ! Also its cold this time of year ............ I have been using a windows version of Kstars on my PC to remotely control the Pi but I noticed that release 3.0.0 of the windows version does not appear to allow offline solving for some reason which is a shame.
  12. Ah thats great thanks Radek I was wondering whether there was a command line for downloading it ! The reason why I was trying to fix the firefox browser was to use it to download the astrometry files .......... Hopefully I will try the offline solver out after I have performed the download soon - looks like there may be some clear skies in the next couple of days !
  13. sorry Radek crossed with your response - hopefully mine makes sense ? !
  14. Hi thanks all again for useful replies. I tried to use the offline solver in Astroberry the other night and it failed but I managed to get the online solver to work however. From Radek's response I can see I need additional files to solve for my 130pds which is 1.56 x 1.18 deg with my ZWO ASI 1600mm so I need to get the Fits index file 4211 as well as the ones which exist already. I guess I use the firefox browser to download the index files from https://web.archive.org/web/20180628212309/http://data.astrometry.net/4200/ and add them to the directory which Radek has nominated which the other files reside in. I also have a TS 71 refractor which is 2.92x2.21 so I will also need 4212 and 4213 I guess. Andy - if you are using Astroberry the Astrometry application is already included but I believe you need to select it in Ekos. It is used in the Alignment page in Ekos. Like me you will also need to download index file 4211 from the link I mentioned earlier to get your 150pds to work.
  15. Thanks for your responses very helpful. Just to let you know Andy your commands worked and I can now start firefox ! It took some concentration to enter the right syntax particularly trying to watch Eng vs Windies cricket at the same time..............!
  • Create New...

Important Information

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