Anyone using Stellarmate on a Pi 4?

[scotty38]

On 07/06/2022 at 03:38, OhNo said:

For me the StellarMate with the RPI is the answer. I shoot year round in Canada. Temps can range from +40C to colder tan -40C. My RPi stays out in the Obs 24/7/365 I would never take a computer put there in the cold. The Rpi handles it like a champ. And since I installed a ethernet cable to the Obs from the house, I can run rvrything but the dome open and close and it's rotation from the comfort of the couch! Point being the RPi runs on INDI, NINA uses ANSI. 3 options for a C?C system for the RPi or the PITA upkeep of ASNI drivers.....

 

I use StellarMate, I have used NINA, SGP and APT. While SM has it's faults, they aren't any worse than anything else. 

What do you mean NINA uses ANSI? Do you mean ASCOM? If you do I'd argue with your view of it being a PITA, it's pretty tried and tested and regardless you need drivers either way.

On top of that NINA will use native drivers for a lot of devices too so I think your view is off quite a bit.

[Stuart1971]

1 hour ago, scotty38 said:

What do you mean NINA uses ANSI? Do you mean ASCOM? If you do I'd argue with your view of it being a PITA, it's pretty tried and tested and regardless you need drivers either way.

On top of that NINA will use native drivers for a lot of devices too so I think your view is off quite a bit.

Absolutely, before moving to NINA 12 months ago, I was an avid user of the RPI4 and Stellarmate, for more than 2 years, and can tell you without doubt that NINA on a mini PC blows it out of the water for ease of use, reliability and of course it’s free, and constantly being developed, updated, and the support is superb too..

There is just no comparison, don’t get me wrong I liked the RPI, but would never go back to it, too many bugs, issues drop outs, lost nights of imaging….

[Len1257]

5 minutes ago, Stuart1971 said:

There is just no comparison, don’t get me wrong I liked the RPI, but would never go back to it, too many bugs, issues drop outs, lost nights of imaging….

I concur. Astroberry was fine when it worked. The issues I had were just so frustrating. Imaging time in the UK is scarce as it is, to lose it because of equipment flakyness is just not acceptable. NUC and NINA haven't skipped a beat since I switched.

[JonCarleton]

There is another option that I haven't seen discussed here.  You can just run the indiserver and drivers on the Pi and forget about running the imaging/guiding/planetarium software on the Pi.  Run the software on your local, in-house PC/Linux, PC/Windows, PC/Pi laptop or desktop using the drivers on the remote Pi.  The added advantage to this method is that you don't have to transfer the files from the scope Pi after the imaging session.  They are already on the local machine.

Setup goes like this:

Configure your Pi to connect to your WiFi (or hardwire ethernet) on boot.  Connect the Pi to your scope peripherals as usual (by this, I mean wiring, not software connectivity).

Install INDISERVER on the Pi with the drivers you need (instructions on indilib.org).  Configure the INDI drivers for your peripherals as necessary.

Install  or activate (if using Raspbian) openssh-server.  (NOTE:  You could skip this if you create a script to start indiserver with the appropriate drivers on boot).

Install the imaging/guiding/planetarium software on your local machine.  KStars/EKOS is a good choice, or CCDCiel/CarteDuCiel/PHD2.  

Configure your imaging/guiding/planetarium software to use the Pi IP address for the Pi instead of localhost.

To start a session:

SSH to the Pi and start indiserver with the appropriate drivers. (or skip this if you created an INDI startup script on the Pi as in the NOTE above)

Start your imaging/guiding/planetarium software on your local machine (can be Windows of Linux or Mac... as long as the imaging/guiding/planetarium software packages support INDI drivers).

DONE.  No RDP or VNC.  The imaging/guiding/planetarium software is running locally, so the only network traffic is the image transfer and commands from the controlling software packages.

This method also works with just a Pi3, but I prefer a Pi4 just due to the lack of USB3 ports on a Pi3.

Granted, I have understated the potential complexity for someone unfamiliar with Linux in setting up a Pi to boot with specific parameters, but the learning curve is not horrible and the setup is a one-time task to get past.  It is well worth the trouble for reliability and ongoing simplicity of operation once you have it properly configured.  This also takes a huge load off the Pi and allows it to be more efficient in operating the peripherals and keeping the WiFi more reliable.

 

 

Edited June 8, 2022 by JonCarleton

[StevieDvd]

The ZWO Asiair are based on a Linux and Indilib, though locked down and restricted to ZWO gear & some DSLR cameras.  I can actually run Stellermate or Astroberry on my Asiair and utilise the power ports with the updated indilib drivers.

How many users of the Asiair don't realise they are using a Linux system I wonder.

[Rallemikken]

23 minutes ago, StevieDvd said:

How many users of the Asiair don't realise they are using a Linux system I wonder.

Most of the world runs Linux, from milking robots in scottish cowsheds to helicopters on Mars. And all of the web, and most financial and military operations and equipment. It's industrial standard at its heart, the kernel. And open source. Qualified people keep an eager eye on the code.

[StevieDvd]

1 hour ago, Rallemikken said:

Most of the world runs Linux, from milking robots in scottish cowsheds to helicopters on Mars. And all of the web, and most financial and military operations and equipment. It's industrial standard at its heart, the kernel. And open source. Qualified people keep an eager eye on the code.

I was one of those. Our system ran on Unix machines and I was involved in the addition of support adding Linux and Windows (the new kids on the block back then)  to the hardware/software we ran on. Getting MSDOS 6.2 users to run the first Windows was fun.

[Stuart1971]

8 hours ago, JonCarleton said:

There is another option that I haven't seen discussed here.  You can just run the indiserver and drivers on the Pi and forget about running the imaging/guiding/planetarium software on the Pi.  Run the software on your local, in-house PC/Linux, PC/Windows, PC/Pi laptop or desktop using the drivers on the remote Pi.  The added advantage to this method is that you don't have to transfer the files from the scope Pi after the imaging session.  They are already on the local machine.

Setup goes like this:

Configure your Pi to connect to your WiFi (or hardwire ethernet) on boot.  Connect the Pi to your scope peripherals as usual (by this, I mean wiring, not software connectivity).

Install INDISERVER on the Pi with the drivers you need (instructions on indilib.org).  Configure the INDI drivers for your peripherals as necessary.

Install  or activate (if using Raspbian) openssh-server.  (NOTE:  You could skip this if you create a script to start indiserver with the appropriate drivers on boot).

Install the imaging/guiding/planetarium software on your local machine.  KStars/EKOS is a good choice, or CCDCiel/CarteDuCiel/PHD2.  

Configure your imaging/guiding/planetarium software to use the Pi IP address for the Pi instead of localhost.

To start a session:

SSH to the Pi and start indiserver with the appropriate drivers. (or skip this if you created an INDI startup script on the Pi as in the NOTE above)

Start your imaging/guiding/planetarium software on your local machine (can be Windows of Linux or Mac... as long as the imaging/guiding/planetarium software packages support INDI drivers).

DONE.  No RDP or VNC.  The imaging/guiding/planetarium software is running locally, so the only network traffic is the image transfer and commands from the controlling software packages.

This method also works with just a Pi3, but I prefer a Pi4 just due to the lack of USB3 ports on a Pi3.

Granted, I have understated the potential complexity for someone unfamiliar with Linux in setting up a Pi to boot with specific parameters, but the learning curve is not horrible and the setup is a one-time task to get past.  It is well worth the trouble for reliability and ongoing simplicity of operation once you have it properly configured.  This also takes a huge load off the Pi and allows it to be more efficient in operating the peripherals and keeping the WiFi more reliable.

 

 

This is all well and good, and I tried it for a while, till you have Wi-Fi issues between mount and indoor PC, then you have to start all over again, much better if the PC on the mount can do it all and not rely on network connections….but I get your point…👍🏼

[Rallemikken]

26 minutes ago, Stuart1971 said:

This is all well and good, and I tried it for a while, till you have Wi-Fi issues between mount and indoor PC, then you have to start all over again, much better if the PC on the mount can do it all and not rely on network connections….but I get your point…

Nope. This is going backwards. Running an INDI-server on a Pi, even an old Pi3, is piece-of-cake, but you need ethernet connection in order to get reasonable transfer speeds of your images from the rig/Pi to your indoor laptop/tower. And you get a stable connection as a bonus. Shouldn't be a problem, buy a 50m bundle, and mount the ethernet plugs yourself.

Can't see why everything need to be wireless, you need a powersource for the rig anyway. Why not roll out a network cable as well? The thought of running a complete KStars/Ekos/INDI session on a Pi has never struck me, the hardware is just to tiny and flimsy. I like to keep an eye on the subs as they roll in, maybe sort and delete along the way while KStars does it's things, and if I'm going to do all this over VNC it will put additional stress on a Pi, especially on the transfer bus. On the other hand, as a pure headless server on a cold night, it's great!

[JonCarleton]

I agree that ethernet is a more bullet-proof method in general. You may have noticed my "or hardwire ethernet" comment.  I also agree that stock Pi3 and 4 WiFi setups are generally fair to poor and somewhat unreliable.  When I do use Pi WiFi, I use a compute module 4 on a WaveShare board with an external WiFi antenna OR an external WiFi dongle on a stock Pi using a USB port.  I do not trust the "printed on the PC board" stock Pi WiFi antenna.

I also use an external TPLINK AC1200 external access point that is hardwired to my internal ethernet, mounted about 3 meters from the scope.  It is a bit overkill, but I don't have WiFi drop issues.  I don't trust home-use WiFi routers, especially to go through a wall.  Download speed for my setup runs 6-10 seconds for a 40G image.  I use 10 seconds as a download estimate for sequence calculations and session timing and always complete a sequence prior to my calculated estimate by a reasonable margin.

When I do use wired ethernet, I get about 5-8 seconds per download...and the occasional cable snag, and am therefore consigned to the fact there is no perfect answer.

Edited June 8, 2022 by JonCarleton

[Stuart1971]

9 hours ago, Rallemikken said:

Nope. This is going backwards. Running an INDI-server on a Pi, even an old Pi3, is piece-of-cake, but you need ethernet connection in order to get reasonable transfer speeds of your images from the rig/Pi to your indoor laptop/tower. And you get a stable connection as a bonus. Shouldn't be a problem, buy a 50m bundle, and mount the ethernet plugs yourself.

Can't see why everything need to be wireless, you need a powersource for the rig anyway. Why not roll out a network cable as well? The thought of running a complete KStars/Ekos/INDI session on a Pi has never struck me, the hardware is just to tiny and flimsy. I like to keep an eye on the subs as they roll in, maybe sort and delete along the way while KStars does it's things, and if I'm going to do all this over VNC it will put additional stress on a Pi, especially on the transfer bus. On the other hand, as a pure headless server on a cold night, it's great!

Well if it works for you great….until it doesn’t….been there done that with Wi-Fi and with Ethernet…..the latest RPI 4 with 4-8gb of ram is more than capable of running Kstars and indi, as it does not use up any resources at all really, and runs well, but as I say whatever works for you…..if it ain’t broke, then no need to fix, but mine broke so I fixed, and never looked back, NINA all the way for me now….👍🏼

[scotty38]

On 08/06/2022 at 23:53, Rallemikken said:

Nope. This is going backwards. Running an INDI-server on a Pi, even an old Pi3, is piece-of-cake, but you need ethernet connection in order to get reasonable transfer speeds of your images from the rig/Pi to your indoor laptop/tower. And you get a stable connection as a bonus. Shouldn't be a problem, buy a 50m bundle, and mount the ethernet plugs yourself.

Can't see why everything need to be wireless, you need a powersource for the rig anyway. Why not roll out a network cable as well? The thought of running a complete KStars/Ekos/INDI session on a Pi has never struck me, the hardware is just to tiny and flimsy. I like to keep an eye on the subs as they roll in, maybe sort and delete along the way while KStars does it's things, and if I'm going to do all this over VNC it will put additional stress on a Pi, especially on the transfer bus. On the other hand, as a pure headless server on a cold night, it's great!

You missed Stuart's point. You don't "need" wireless or ethernet to run NINA at the scope. Once it's running it's running, yes you can connect to it remotely to see what it's doing and you can do that over wireless or ethernet using RDP or whatever you fancy BUT if that connection breaks NINA and your imaging session just keeps on running no issue, that's what he was on about.....

Edited June 10, 2022 by scotty38

[gilesco]

40 minutes ago, scotty38 said:

You missed Stuart's point.

I think he got the point, but was making his own, there are a lot of voices in this thread - making valid standalone points about what works for them, all getting replies about what worked for them didn't appear to work for others.

Kstars / INDI, NINA / ASCOM - they all work, just use what fits your prior computer experience.