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. 🙂

5 hours ago, JamesF said:

Mostly what comes out of this I think is that I'm really not happy with the alt adjusters on the mount

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?

37 minutes ago, david_taurus83 said:

Quick question, is the entire RPi OS stored on the SD card? For example, if I wanted to flip between Stellarmate and back to APT via Indigosky, then I'd only need another SD card for Indigo? Each time the card is swapped the settings and configurations are all ready to go?

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.

10 hours ago, Star101 said:

I took this image tonight. As soon as I saw it I was thinking....That's not going to plate sol.....and before I could finish my thoughts SGP using Planewaves Platesolve2 solved it

Impressive lol.

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

6 hours ago, david_taurus83 said:

The mount and focuser keep fighting over the same port.

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 ?

16 hours ago, RexOr said:

our open source, open hardware Linux driven camera, as it has been adopted by a number astronomy projects at this point… most of which we’re not allowed to talk about unfortunately

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/

16 hours ago, RexOr said:

more affordable camera (budget sensor) called AXIOM Micro

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.

On 10/07/2019 at 21:46, StarDodger said:

Yes they both work on the latest Stellarmate, which is 18.04..

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

4 hours ago, discardedastro said:

Ekos+KStars runs on my laptop, not the RPi.

The Pi runs INDI Web Manager at boot, which then allows KStars/Ekos to automatically start indiserver remotely. It is absolutely invisible from an end user perspective, once it's all set up, but the absolute minimal Pi setup is:

• Install indi and all the required drivers, as well as indi-web
• Set up indi-web to start on boot (for this purpose I use a systemd unit file, which enables the systemd daemon to look after indi-web and restart it if it crashes)
• Connect Ekos to the Pi, whereupon Ekos will use indi-web to start indiserver with the drivers configured in Ekos

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 🙂

4 minutes ago, StarDodger said:

I don’t understand when running in this mode, why the Indi web manager is even mentioned as it’s just invisible...  you never actually have to see, start or have anything to do with it, when running Kstars / Ekos....

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 🙂

12 hours ago, StarDodger said:

it works without a monitor no dummy plug needed, and it works on the rpi 3 and 3b+ without a dummy plug too....so not sure why you needed one, but it will only show a max res of full HD and not the 4K that the rpi4 does now output.....

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 🙂 

1 minute ago, StarDodger said:

Well, have got a major hurdle with the rpi4, the 4K resolution will not work headless over VNC, only when there is a monitor attached..

Without a monitor 1920x1080 is the Max...so that’s  a deal breaker for me, as I wanted to use the rpi4 and try and run Kstars from it..but that ain’t gonna work..  

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.

22 minutes ago, david_taurus83 said:

One thing I cant seem to find is a save button after i configure my profile. Eg. Camera gain and offset need to be 139 and 60 respectively, 16 bit enabled,  focuser needs direction reversed etc, but if I shut down and start up again everything appears to revert to a default setting? Potential for mistake here unless theres a way of saving once and for all.

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.

13 hours ago, han59 said:

The time lost is the time between the exposures for downloading the image via USB and saving it to the memory card

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

12 hours ago, pete_l said:

option to create a RAMDISK and save the image there

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.

Do they still have cows in Yorkshire (Leeds) - a sight now becoming rare as Hen Harriers - Sheep everywhere LOL