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.

sgl_imaging_challenge_banner_30_second_exp_2.thumb.jpg.7719b6f2fbecda044d407d8aba503777.jpg

psamathe

Members
  • Content Count

    183
  • Joined

  • Last visited

Community Reputation

114 Excellent

About psamathe

  • Rank
    Star Forming

Profile Information

  • Location
    World
  1. Seriously consider joining a local astronomy club. You actually have 2 (maybe 3) very nearby which are excellect active clubs. Norwich Astronomical Society http://www.norwichastro.org.uk has club nights every Friday (which happen even if weather is not up to much) - it has its club house and observatories near Seething (just south of Norwich). Breckland Astronomical Society http://www.brecklandastro.org.uk is based in Great Ellingham a couple of miles west of Attleborough (short distance down A11 from Norwich). Has club nights on Tues at its observatory/club house as well as talks some Fridays. Both clubs are excellent and very active and are bound to have similar scopes available to those you are considering and would happily let you look through and discuss, etc. Also an excellent way to learn from others, etc. Membership is pretty cheap/ There is also a astronomical club north of Norwich but I don't know much about it (I have heard it does not have a permanent base/observatory but that is just what people have commented so may not be the case). Ian
  2. In fact, thinking further from my previous post, using multiple RPis if you use a non-root RPi for Indi image capture and cable it to the root Indi server you could then use a completely separate Wifi link (network/channel/completely isolated) back to the client for image downloading (via a background FTP/SAMBA/whatever). i.e. root RPi A is the root Indi server talking to RPi B (image capture) through a cabled network link and maybe RPi C doing Rapid guide. RPi B the image capture would store images on the local SD and have it's Wi-fi enabled (as well as the cable to RPi A) and the Wi-Fi talking to different Access point/different SSID/different RF channel and the client would then download the captured images directly from RPiB local storage using FTP/SAMBA/whatever. That way you are leaving the RPi A root server Wi-fi link clear for real/near-realtime command communications. The Indi architecture is really very flexible. an
  3. I've always thought that local storage on the RPi for transfer "at a later date" need not actually mean much of a delay. I've thought the setup of e.g. FTP to transfer those locally stored image files (on the RPi) back to a client could be implemented as a background process. e.g. every 30 secs run a script/application that checks the RPi image directory and then transfers those images back to the client. The transfer could (if need be) be throttled so that only part of the Wi-fi/network bandwidth is used. Thus the image collection/storage on the RPi is not delayed and the transfer back to the client is not "next day" and is not disrupting more real/near-real time processes. (I could see it pretty easy to do programming a transfer app, but I am also told that Linux has good support for throttling things as well) Ian
  4. I have read something about "Rapid Guide" in Indi - where the Indi drivers do the processing to select/read the position of the guide star and only pass back the position to the client (rather than the guide camera entire images). This would help where Wi-fi/network bandwidth is an issue but not if USB bandwidth is a problem. But like you say, RPis are cheap so if USB bandwidth is a problem a 2nd RPi is easy - given the architecture of the Indi server allowing drivers to be distributed/daisy chained. I am impressed with the architecture Indi had adopted in this regard. Ian
  5. I'm hoping I've missed something in the announcement because if I haven't there seems some "rather poor" reporting going on. For example, I understood the planet was detected through doppler shifts from the star which gave the minimum mass of the planet of 1.3 Earth masses. But that is a MINIMUM because we have no idea about the inclination of the orbit. Yet even on space.com that gets reported as "... is about 1.3 times more massive than the Earth". To me with scientific disciplines it is rather important to get the facts right (you stand no real chance if things just get distorted giving the impression more is known that actually is). Simplifying reports for public consumption is a great skill - the report(er) needs to simplify things and explain complex ideas without distorting or exaggerating. But just missing out "at least" or "minimum" seems just bad reporting. And the space.com then goes on to say about it being likely it is tidally locked but why not on a 3:2 resonance ? What worries me about poor reporting (particularly from scientific focused publishers) is that the less specialised press then often base their further simplified (and even less accurate) reports on those so you end up with poor reporting being based on poor reporting being based on poor reporting ... But maybe I've missed something in the announcements. Ian
  6. Does your local library have superfast broadband. If they do, and if you want to download the plate solving files for local plate solving, maybe some time spent in the local library (my own local library allows you to use theirWiFi & internet free (provided you are registered as a library user)). Ian
  7. Re: 2 I stuck with Raspbian as that is what I started with. Considered switching to Ubuntu Mate then wondered why when Raspbian seems to work and I'm really only interested in the Indi Server, not what it is running on (i.e. as it was working fine on Raspbian, if it aint broke don't fix it). Unsure if I've got the question on what you are after but: Setup RPi and connect to WiFi/network (can be done from Raspbian GUI) Follow the Indi instructions on installing Indi server on RPi. I strongly recommend the Indi Web Manager (see my post above) Install Kstars/Ekos on the client Start the Indi Server (using Indi Web Manager which specifies which drivers you want) Start Kstars/Ekos and connect to Indi Server on RPi Your running! (and problems then there is a lot of info from the Ekos logging/debug options from the Indi Control Panel) Then use and decide where you want to go with regard to other clients, hardware, etc. (that is the nice thing about IndiServer/Kstars/Ekos being free) Note that there are simulator drivers for most things which means your Indi Server does not even need to be connected to real hardware for you to play/test. simulators are pretty good. Depending on how far you take playing with the similators you might want to download the Guide starts catalogues to get a better simulation sudo apt-get install gsc Really a matter of having a play. If you want to start plate solving, and you want to use local solving you will need some massive downloads (given your slow internet connection - probably many nights) http://indilib.org/about/ekos/alignment-module.html (but you either do the downloads using a slow internet connection of you use it online and have a slow plate solving as you have a slow upload of your images to be "solved". You may come across a few hiccups but rather than try and foresee those hiccups and answer all potential problems, maybe have a play and ask when you get stuck. again, the simulators are excellent as they allow you to eliminate a load of potential problems and get things working incrementally (i.e. if it works with the simulators and not with your mount/camera/etc. then you have already narrowed down the problem a lot. Do ask (others here probably know far more than me as I'm a novice) but also there are lots of answers on the Indi site and in their forum - worth a good search. I did on one occasion ask a question on their forum and they were very very helpful and responsive (as I was facing a big problem - which turned out to be a real weirdo the developers were not aware of). Ian
  8. I fing the Indi Web Manager http://indilib.org/support/tutorials/162-indi-web-manager.html very useful when running the RPi headless - far far easier than using SSH and the command line to start the Indi Server. Plus it in effect lists the drivers available on the RPi. Very easy and straightforward to install and load (remember to do the bit in the explanation to change config files to auto-start it). Ian
  9. I have seen others with heater strip directly behind the plastic front end of the SCT (heater strip running under dovetail. Struck me as a good place as it can be left fitted so less likely to suffer damage from being fitted, removed, wrapped-up, bent a bit more, stored, etc. Never tried it. Being a novice, is this the best place to use the heater band on an SCT as I never tried it as I thought the plastic could insulate the corrector plate from getting any heat and the heat is going to warm the tube away from the corrector plate as much (or more) than where you actually want the heat. Ian
  10. I used to fit shield over heater (with the fitting issues) but was then told (by somebody with loads of experience) that the normal way is to fit the heater on the outside of the shield. Ian
  11. It is true ... in theory. I've never seen mine run above 300 even with perfect coverage. What I did find with my RPi3 was: my normal WiFi network is only 5GHz (2.4 is not as good). So I had to setup a few additional Access Points at 2.4 GHz (PRi3 only runs at 2.4). Initially I had those 2.4GHz Access Points set to 802.11n with 802.11b/g compatibility and I could only get 20MHz channels which limited max speed to 75. So I reconfigured the 2.4 Access Points to be 802.11n only and got wide channels and then speed went up to 150 Mbps. But those speed measurements are from my laptop NOT my RPi3. Higher speeds need more antennae and I doubt the RPi3 has a lot of antennae - which will means the higher speeds will not be achievable. I suspect that getting a higher speed to your RPi3 will be useful if you are imaging as the image download time will load the network (particularly on e.g. DSLR megapixels). As previously mentioned there are things you can do to get round that limit (e.g. local image storage on the RPi and "Rapid Guide" (or whatever it was called)) - but I've not tried any of that so am just repeating what I've read. (At least that is my understanding and my observations). Ian
  12. Also a couple of threads on UKAI from an admin trying Indi on RPi http://ukastroimaging.co.uk/forums/index.php?board=117.0 Ian
  13. Re: battery capacity: 100A/Hr leisure battery will be quite heavy and something of a challenge for most to carry very far. You will also probably not get the full capacity out of the battery in real world use (i.e. as the battery discharges so the voltage will drop ... Re: Laptop power: Much depends on your laptop and accessories availability. For my laptop I've purchased a car cigarette lighter power supply for the laptop (https://www.amazon.co.uk/gp/product/B00ETB0DRQ). It was pretty cheap and works well. But it is dedicated to the laptop so if I change my laptop then that adaptor will no longer be the right one (except in my case it's a Mac so almost certainly would continue to work - it works on both my Mac laptops one 8 yrs old). If there is such an adaptor available at reasonable price then it is very convenient. If not then you'll need an inverter and your normal mains psu. Inverters can be cheap but you probably get what you pay for and remember that being outdoors in damp dewy nights with 240v needs thought and care. Ian
  14. I have an app on my iPhone called Observer Pro which seems to do what you are after https://itunes.apple.com/gb/app/observer-pro-astronomy-planner/id462392803?mt=8 but only for DSOs. Nice visibility graphs (best time of day, best time of year, visibility, etc.) Ian
  15. I don't know but if not I'd have thought it's just a matter of running separate clients each connecting to the imager of a different Indi server (and those clients could presumably be on the same computer in different virtual machines). Or maybe some way of running separate instances on Kstars/Ekos or a "lighter weight" image capture app (supporting Indi) for the different imagers whilst the main RPi/client controls the single mount. I'd have thought running more than one imager would add a significant level of complexity (maybe more user complexity) as it's not just more than one imager but also more than one filter wheel (each of which needs to be associated with its imager) and more than one focuser (again needing associating with it's imager) and then you'd need multiple scheduled (given that Ekos now includes a scheduler), etc., etc. If it were me I'd be going for the multiple clients and one imager per server (excl. auto-guider imager) - if only to keep the usability more straightforward. But, I don't know Indi's capabilities in this regard so about are my thoughts and guesses. Ian
×
×
  • Create New...

Important Information

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