stash_old

My experience and personal opinions todate using non Wifi DSLR's :- 1. Can you control a dslr camera via Wifi - answer no if its doesn't have in built Wifi or an add-on Wifi module or similar.(e.g. Linux Gphoto2 plus RPI). All the other methods ,I know of,use USB/Serial tethering. 2. The only transparent(using existing software) way of Wifi DSLR control via std manufacture's supported firmware for non Wifi featured DSLR's is using VirtualHere - but you would still need something like Linux/Android attached via USB/Serial on the camera. As far as I know ,via my trials, this is the only route that supports ANY std camera control software - e.g. APT. CONS :- A). it can be very slow (download and Live view) due to the 2.4 ghz Wifi and central processor (works using a RPI Zero W ) but I have not tried it on a RPI4 if that is available (RPI3b+ wasn't supported last ime I looked!). B). Still need a "WiFi Box" attached to the DSLR via USB/Serial. C). Cant say it worked 100% of the time. D) Not free. $49 PRO's:- A). It is supposed to work on most OS (Windows,Linux,Android,OS X) B). APT/BYE Digicam all work - tried them. C). No feature loss - if your software gave you the feature before it should still work - hence "transparent" 3. Using Gphoto2 works, still requires a "Wifi Linux box, but it is reversed engineered (very well) so will never be as perfect as (well one hopes) the manufacturer's own software. CONS:- A). Does support the newest camera's but is not very far behind. B). Will not work with your existing software (as of today) - e.g APT etc C). May not support all features in your camera firmware - Low Noise setting, Mirror Lock and a few others on some camera's cause problems and have to be disabled. D). You need to use either Indilib or Indigo on the Linux box as there is no GUI (Modern) software. E). Only works on Linux but the client GUI can be else where -e.g. Indigo can use most Web Explorers. PRO's A). It is very reliable - subject to the whims of Wifi,OS etc 4. Expensive IMO modules like Cam Ranger/Canon WFT range etc 5. "hacked" modules - DslrController stick or hacked TP-Link router 6. DIY shutter control. NOTE I did say non Wifi enabled DSLR. If someone has found a better solution that is reasonable in price please share. 🙂

There you have to heart of the problem - and the Kstars/Ekos blurb says something about making "fine adjustments" - no chance with the prehistoric adjusters on SW mounts 🙂. Plus using a DSLR doesn't help in my case on Ekos! IMO Sharpcap is still better than Ekos option for Polar alignment which doesn't (well I couldn't find a way) allow you to zoom in/out the area very much. But the Ekos one does at least use the mounts movement in RA.

Without Kstars/Ekos loaded what does gpsmon or xgps client utility say when loaded - you may have to install gpsmon or xgps. The utilities act as GPSD clients so if GPSD is running correctly they will show he correct GPS time/position - note getting a 2d or 3d fix indoors can be very difficult but time normally comes up fast. Try another test only start up PI without GPS gadget plugged in ,then insert the dongle ( i am assuming USB but you dont say what GPS you are using!) and start one of the GPSD clients and see what,if any, info you get. Also "dmesg" is your friend check the output to see if there are any errors with GPSD and/or your dongle The problems I encounter were to do with "USBAUTO" conflicting with other serial USB devices - hence some people use Udev rules to fix a name - in essence Udev creates a fixed name for the device no matter which port you plug the device in. As you "pay" for Stellarmate support drop a line to Jasem if you haven't already done so 🙂 Plus did you read this https://www.indilib.org/forum/ekos/3562-can-t-get-gps-dongle-to-work.html Sorry if you know all this already 🙂

For those brave fellows and those who run client server Indi/Ekos - so Indiserver on the RPI4 and Kstars/Ekos on a client (a laptop running Linux) then this might be of some help but be aware they are problems it seems at this moment in time. https://jamesachambers.com/raspberry-pi-ubuntu-server-18-04-2-installation-guide/

But is he going to release the O/S without the Indi / Stellarmate for everyone else who does not use Stellarmate?

Yes normal set ups are, but you would have to shutdown , change the SD card and then reboot. It should be possible to add Indigo (i.e. Indigo_server) to your Stellarmate and get Indigo server to load using a different port then 7624. So long as you dont start Indi_server and Indigo_server at the same time you could leave the ports at default (7624). But using 2 SD cards is the easier/safer way to do it - One for Stellarmate(ubuntu) and one for RPI Buster for Indigosky/Indigo.

Thats the East Midlands Easyjet to Tenerife plane - Solved LOL 🙂 Platesolving ignores what it considers not to be stars ! It is a good piece of software(Platesolve2) but ASPS is better,IMo, when you dont know where you are and far from where you thought you were!

look at the 2nd hand kit - mostly far better value and normally a good selection at this time of year. Most astro people take care of their kit 🙂

There is a simply test to prove if the HEQ5 and Usb/Serial is working and compatible. 1. Download the SW Synscan App Pro - no install just unzip. 2. Connect up kit - just mount and Lynx cable ( hope this isn't a prolific chip they are a pain or can be 🙂 ) 3. Start Synscan App - first time loaded you will have to input your location(lat/Long) - doesn't matter where for test. 4. Click "Settings" 5. Next screen click "Connect Settings". 6. Next screen click "Serial" tab at the top and enter the com port numeric (I assume its 3 from what you say but check via Windows Device manager) 7. Click "Back" on top left. 8. Screen shown will have "Connect" at the top - click this button. If this works then cable / mount is OK. If not double check the device is not got a warning (!) next to it on Device Manager - it will also tell you the com port number. Nothing will work if the driver has the (!) next to it. May need driver downloading and setting up to remove (!). https://www.sony.co.uk/electronics/support/articles/00122116

Try and create a Udev rule - So long as you can tell the difference (what does "lsusb" say) between the devices. I guess this is what "serial assistant tries to do" (not having used Stellarmate 🙂 ) This might help https://www.indilib.org/forum/stellarmate/5194-problem-with-persistent-usb-link-in-stellarmate-i-think.html If you cant tell the difference between the 2 devices (as shown by lsusb) then you may have to buy another USB/Serial cable BUT using a different chip. OR get more Techie with something like this set of things to try https://askubuntu.com/questions/49910/how-to-distinguish-between-identical-usb-to-serial-adapters or see if this script helps you do it manually https://github.com/rlancaste/AstroPi3/blob/master/udevRuleScript.sh

So what's the position now ? Still problems or cured ?

Not very "open" then Plus it seems that this is not so new and the older kickstarter project was criticised as it was 2 yrs over due https://www.cinema5d.com/axiom-open-source-cinema-camera-unveils-new-design-and-recording-solutions/ And what is affordable ?

Using everything on the PI (4 or 3b etc) is great for many situations - for example so long as the PI keeps on working loosing a RDP doesn't matter it carries on and is great if you do "in the field" Astronomy. However the PI (and even the RPI4) has many limitations , as one would expect for £70, especially one - it doesn't and cannot compete again a flown blown i7 16mb Sata connected SSD in terms of performance - anyone says different is mad. But then again you would be paying £500+ for the privilege. I still laugh at people who spend many thousands on Astro kit and then £70 on a PI. That said its brilliant piece of hardware for a low price and will do the "job" nicely. How you use it is a personal preference and "one size fits all" doesn't apply. IMO ,when not in the field, the Client / Server approach has many Pro's especially if you have 1gb local nework and connect wired not wirelessly for the reasons stated above about he RPI's limitations. The best bit with Indi/Indigo is you can easily change how you work - Ascom at present (even with Alpaca) does not really provide this client/server flexibility and Alpaca is unproven (and not very well supported by Manufacture's) at this time.

Unfortunately thats not quite true - It only works with some AP/Routers and has to be fiddled with to get Ubuntu 18.04.2 to connect. Its basically the problem of Country codes and the Ubuntu Mate version of RPI-CONFIG not having the option to set the country code. As I say it appears that it depends on your AP/Router hardware. None of this occurs when using Raspian (or other flavours inc Ubuntu Mate 16.04).

Check your site location details (lat/long) in EQMOD - this gives the same non descriptive error when they are invalid. they have to be in he correct format

Seems like a good simple straight forward plan to me - do something similar except minus the Web Manager( i just start Indiserver with required drivers via a script), the same. But when I am doing Wide field or in a "field" I just use the RPI in stand alone mode with all software running and RDP. Interestingly Indigo has a web service built into the Indigo server! You are correct there are pro's and con's with any set up - even Ascom 🙂

I never do use it so I will bow to your greater knowledge of Indi Web Manager. 🙂

Not running Ekos/Kstars on the RPI -just Indiserver from the command line or using the Laptop to start Indiserver via Web Manager. Indiserver can be started using various methods (so long as kit is connected first and switched) - Thats what "systemd" can do which is what I think is implied here but might be wrong. Can also just use a simple .sh file which starts when the Desktop loads which contains a line for example "indi_server -v -m indi_ccd indi_focus etc" - using the correct driver names of course. If the same kit is used each time it works well in my experience. Can also use SSH to start up a script without Desktop being used (Ubuntu/Raspbian etc server no Desktop)- saving resources- used a lot (well I do) when using multiple RPI and "chaining" - very simple and efficient resource usage. Each to his/her own 🙂

Well std Indi on Std Ubunu mate didn't on many h/w set ups including RPI, well documented problem - only Raspbian worked . Not bothered trying since as the dummy means no changes in software parameters can effect the RDP no matter which version of RDP you use - maybe a fix was applied 🙂

Dummy HMDI plug - hint - £4 on ebay works on RPI3 and Windows and Linux - for me

If you are running Kstars from another PC then you must make sure you can ping the address you use in the "REMOTE" section of EKOS else you won't be able to connect to the Indi_server at all. Also make sure you are on the same network and try the IP address of Stellarmate instead of name in case name res is not working or you are not using the same DNS settings. Again PING is your friend.

There are (were) 2 saving points but they save different things. 1. Ekos Profile - where you define WHAT is connected for a given named profile AND 2. Indi settings - saved under the Indi devices under the "main" (haven't got my stuff loaded so from memory) tab which you have to do for each device. And if you run everything on the RPI you dont loose anything if you just remotely connect via RDP/VNC - not used SM web interface so cant say but one would assume so unless it starts the server again on connection.

Maybe using a SSD via the USB3 may improve saving times and possible Solving times. BUT at the moment you can't(lat time I looked) boot from USB on RPI4. Still good to get comparison. Note transfer 108mb fits image file from RPI3 to AMD64 takes under 10 secs over 100mb network - as a straight copy and paste. I am not sure but transfering data between Indi and a client maybe faster than Indigo even though they use the same protocol but Indi I believe use a different compression method

RPI Forum did tests on Zram and others and found very little gain by using such options - although my testing on a Zero(w) did show some improvement.