35 replies to this topic

[nother]

Hello EAA community!

 

As ASCOM Alpaca and the ASCOM Remote Server improved a lot especially with the latest ASCOM platform version 6.6, I gave it a try and I would like to share with you my experience.

Another driver for this project was the fact that my mini PC, that is mounted at my telescope is (by design) not the fastest one (especially due to its size), but it still has to do all the CPU and RAM heavy stuff (Sharpcap, drivers, planetarium software like Stellarium, plate solving, ...).

So instead of replacing it with a better, faster, new one, I thought about on how to move the CPU/RAM consuming software part to the much faster observation PC or laptop.

 

(before I continue: setups with linux based mini PCs (often Raspberry Pi) like ASI air or Stellar Mate are out of scope of this article)

 

So here is my evolution of EAA setups, I think most of you will know and have one of them in place too:

 

A. simple wired connection

 

- scope equipment is connected to a local PC via USB cable

- an USB extender cable or dedicated device might be used to extend the distance between scope and computer/laptop

- all the required software (Sharpcap, Stellarium, ...) runs on the PC the equipment is connected to

 

- pros:

• most simple and beginner friendly setup
• no need for a scope PC
• the used observation laptop is usually powerfull enough to handle all the software in use 

- cons:

• you need cables between scope and observation laptop
• USB extender might cause issues and instable connections
• fast/professional USB extender devices might be quite expensive

 

 

B. network based remote setup

 

- scope equipment connected to a mini PC mounted near or on top of the telescope

- a laptop or PC connects to the desktop of the mini PC via Remote Desktop (mstsc) or Teamviewer (or VNC, or ....)

- all the required software like Sharpcap, Stellarium (...) needs to run on the mini PC

 

- pros:

• no cables between observation pc and telescope
• observation pc can be easily replaced
• clean cable management on the telescope when mini PC is mounted directly on it
• no issue with instable network connection as the mini PC will continue its work even when the observation pc will loose its connection
• remote connection does not need high wifi bandwidth (will therefore also work with slower 2,4GHz wifi connections)

- cons:

• limited hardware ressources of the mini pc whilst running a lot of different software (high CPU load, high RAM usage) ... think about live stacking and plate solving
• you need a monitor, mouse and keyboard at hand in case you cannot connect to the mini PC

 

 

 

C. "real" remote setup using ASCOM Alpaca

 

- equipment still connected to a mini PC on top of the telescope

- the only software running on the mini PC is "Ascom Remote Server"

- all the EAA software runs on the observation PC / laptop

- ASCOM Alpaca "extends" the local drivers on the mini PC (scope, cam, focuser, ...) to the observation PC / laptop as if they were installed locally there

 

- pros:

• mini PC not anymore the limiting factor for the EAA software in terms of avaible hardware ressources (CPU, RAM)
• "Ascom Remote Server" software not very CPU/RAM consuming
• you can still keep your old mini PC for some more years / no need for a replacement
• it's cool
• you see the original uncompressed Sharpcap picture and not a compressed version of the desktop on the mini PC like in B.

- cons:

• you need a fast and stable wifi connection (5GHz recommended, at least 100MBit/s (better 200MBit/s, depending on camera resolution)) as a lot more data (especially camera picture data) needs to be transfered
• you still need a monitor, mouse and keyboard in case you cannot connect to the mini PC over the network
• not for beginners (you need to have some network knowledge and you need to have some ASCOM experience (diagnostics, profile explorer, ...)

 

And here a screenshot of the setup as it is running: On the right side you can see the desktop of the mini PC running Ascom Remote Server. On the left side you can see Sharpcap installed on a PC at my home, that has no camera attached to it, but that has access to the camera on the scope PC via Ascom Alpaca. You can also see that it's connected to the focuser and the mount... also via Alpaca.

 

(bigger version: https://abload.de/im...pc_alp03jj3.jpg)

 

In case you want to ride the Alpace too, then I am happy to help

 

 

Edited by nother, 16 February 2022 - 01:58 PM.

[BrentKnight]

Great article.  I just got most of this stuff setup on my rig.  I don't do the whole thing on my home PC, it's more of a hybrid mode.  I keep SharpCap running on the mini, but I run SkySafari, SkyTools on the home PC.  This still frees up resources on the mini, but the planetarium and planning software runs much, much better now and I don't have to worry about dropped connections dropping my session.

 

Having used my system all three ways, Remote/AlpacaScope feels like magic!

[GaryShaw]

Thanks for all this effort Nother!  Pretty interesting.

 

1.  Does the Alpaca way allow simultaneous use of other software on the scope side cpu….such as browsers, Maximdl, Stellarium, etc ? Would one be able to also simultaneously be connected to the main camera from both Sharpcap and Maximdl? 
 

2.  Since I’ve been operating under your B. scenario, my scope-side pc is the more powerful cpu ( a headless Intel Nuc) and inside I have just an old work PC laptop. Under your scenario C., I’d be placing all the cpu and memory demand on the old laptop which would bog it down so I’d need to replace the laptop.

 

3. Another issue I’d face is ‘ yet another sw app‘ to learn to use and trouble shoot. Over the past year or so, I’ve had to confront, figure out and setup : Sharpcap, Maximdl, Stellarium, NINA, AIJ, Hops, PHD2…- no biggy for younger minds but actually quite a lot for me. The prospect of adding Alpaca Server to the list when everything is already working well definitely lacks appeal. 
 

For a lot of us, these issues are a definite ‘con’ that’s missing from your list - no criticism intended, just an observation. I do like the idea of viewing uncompressed image data when observing via EAA but for my photometric work with variables and exoplanet transits, it’s immaterial. 
 

One factor you might comment on is the availability of instructional materials/ tutorials on setting up and using the Alpaca ASCOM Remote Server. 
 

Thank you for all your efforts doing such a great job of  communicating all the above!

Gary

[aiken999]

interesting setup! I had thought of doing B but went the ASIAIR route instead. Its OK but i much prefer just using Sharpcap. Off and on issues with ASIAIR! Are you just using home WIFI with ALPACA? Do you experience drop out issues? What are you using for your on Scope PC? My current setup uses ethernet connection to ASIAIR and a Slate travel router, works great and is really stable and fast. 

Mike

[Xio1996]

Hi Nother!

 

Thank you for the post. I use a collaborative system. Outside in the cold sits an i5 laptop with CPWI, SharpCap and of course Remote Server. On the inside of the house sits an AMD desktop with the planetarium and planning software communicating with the Remote Server. Connection is over a powerline ethernet connection of 300-360Mbps, only one power/communication connection from the house. I do like Alpaca, very easy to setup and allows the delegation of tasks between the devices. Being lazy, I also use OneDrive as a shared file system between the two PCs. Microsoft Remote Desktop so that I can control the i5 laptop.

 

You could use a single PC with USB (or USB to fibre to USB) then you don't need Alpaca at all. Computing power is fairly cheap. So I share the load, with what I have and Alpaca works really well. I have to say it has been rock solid. The single point of failure usually turns out to be me :-)

 

Have fun

[steveincolo]

interesting setup! I had thought of doing B but went the ASIAIR route instead. Its OK but i much prefer just using Sharpcap. Off and on issues with ASIAIR! Are you just using home WIFI with ALPACA? Do you experience drop out issues? What are you using for your on Scope PC? My current setup uses ethernet connection to ASIAIR and a Slate travel router, works great and is really stable and fast. 

Mike

Just FYI in case you didn’t know already:  you can use SharpCap for live stacking in conjunction with the ASIAir for taking images.  This could be a good way to overcome the limitations of ASIAir Live stacking.  

[bmcclana]

I tried this on ASCOM Remote/Alpaca 6.5  a while back and Camera control and image transfer wasn't working very well. 

 

I did an indoor trial a few days ago on 6.6 and it did seem much improved. So I have been in the process of updating an old Intel compute stick to try it again. 

 

I have been playing around indoors throughout the day today, and image transfer is still a big bottleneck. even on a 2Mp camera, there is around a 2-3s overhead for the image to make it back to my "remote" laptop.  I also have a 20Mp 183 sensor so the big raw images seem to be too much for my little stick. I have about a 10s delay for every frame for the little stick to download the image from the camera and hand it off, then the network transfer is around 4-5s on my wireless connection.  Transfer speeds are peaking up in the 200-300Mbps.  This is on a very minimal stick computer with a 2GHz Atom processor and only 2GB RAM.  a better computer seems to remove that long processing step, but best case i was still seeing a 2-3s delay every frame. some of this is probably just ASCOM since it is slower even when directly connecting the camera to the imaging computer.

 

 

In the mean time, I have been using setup B above with the addition of the ASCOM remote server running on the telescope side computer which let me use Skysafari 7 on my phone as my planetarium app.   This has been working great. 

[ZepHead]

Great write up Christian!  This is EXACTLY what I'm doing now, with the exception that I'm still using my dedicated imaging laptop to run the Alpaca Remote Server.  I will soon be getting a mini PC, but I now know that I don't need to break the bank for an i7 CPU and 16 GB of RAM.  

 

It's soooooo nice to sit in my office and control everything remotely.

[nother]

Thank you very much for all your feedback and questions!

Instead of just answering them in the thread, I'll also add those information to the initial article, so that later readers don't have to go through all the posts.

Unfortunately I can't edit the post anymore.

 

I just got most of this stuff setup on my rig.  I don't do the whole thing on my home PC, it's more of a hybrid mode.  I keep SharpCap running on the mini, but I run SkySafari, SkyTools on the home PC.  This still frees up resources on the mini, but the planetarium and planning software runs much, much better now and I don't have to worry about dropped connections dropping my session.

Good point: A Hybrid setup of course can make sense as some ASCOM drivers might also not be as feature rich as the original drivers (e.g. for the PegasusAstro Powerbox or EQMod).

 

 

1.  Does the Alpaca way allow simultaneous use of other software on the scope side cpu….such as browsers, Maximdl, Stellarium, etc?

 

1a. Would one be able to also simultaneously be connected to the main camera from both Sharpcap and Maximdl? 
 

2.  Since I’ve been operating under your B. scenario, my scope-side pc is the more powerful cpu ( a headless Intel Nuc) and inside I have just an old work PC laptop. Under your scenario C., I’d be placing all the cpu and memory demand on the old laptop which would bog it down so I’d need to replace the laptop.

 

3. Another issue I’d face is ‘ yet another sw app‘ to learn to use and trouble shoot.

 

4. One factor you might comment on is the availability of instructional materials/ tutorials on setting up and using the Alpaca ASCOM Remote Server. 
 

to 1) Sure, as long as you don't overload the PC, you can run whatever you want. Outsourcing software from the scope PC with the help of the Ascom Remote Server helps to free up some ressources.

to 1a) What works better than before is the simultaneous connection to the mount, in my case with Stellarium and Sharpcap. What I didn't test yet are parallel connections to the camera. I'll update you on this.

to 2) In that case it does not make sense to move the load away from the more powerfull device, but as I said: In my case the scope PC is the "old" one lacking ressources.

to 3) Your are absolutley right! I'll add this point as an additional "con" as it adds complexity.

to 4) That's a valid point too and to be honnest: My journey was more like try'n'error instead following a plan/manual. But if there's enough interest, I can go more into details regarding setting up the Remote Server and the Alpaca connections.

 

 

Are you just using home WIFI with ALPACA? Do you experience drop out issues? What are you using for your on Scope PC?

The Wifi setup is not final, but I have here a new Mikrotik router with 5GHz wif  I want to configure as a bridge between my scope and my home network or (when I am in the field) to my observation laptop independently of any home network.

 

This is the mini PC I am using:

 

 

The CPU is a 2016 model

 

 

Edited by nother, 17 February 2022 - 01:39 PM.

[nother]

I tried this on ASCOM Remote/Alpaca 6.5  a while back and Camera control and image transfer wasn't working very well. 

 

I did an indoor trial a few days ago on 6.6 and it did seem much improved. So I have been in the process of updating an old Intel compute stick to try it again. 

 

I have been playing around indoors throughout the day today, and image transfer is still a big bottleneck. even on a 2Mp camera, there is around a 2-3s overhead for the image to make it back to my "remote" laptop.  I also have a 20Mp 183 sensor so the big raw images seem to be too much for my little stick. I have about a 10s delay for every frame for the little stick to download the image from the camera and hand it off, then the network transfer is around 4-5s on my wireless connection.  Transfer speeds are peaking up in the 200-300Mbps.  This is on a very minimal stick computer with a 2GHz Atom processor and only 2GB RAM.  a better computer seems to remove that long processing step, but best case i was still seeing a 2-3s delay every frame. some of this is probably just ASCOM since it is slower even when directly connecting the camera to the imaging computer.

 

 

In the mean time, I have been using setup B above with the addition of the ASCOM remote server running on the telescope side computer which let me use Skysafari 7 on my phone as my planetarium app.   This has been working great. 

The major difference between Remote Server in version 6.5 and the one in 6.6 is that the protocol for the picture payload transfer for camera ascom drivers changed to a way more effecient and stable on. But there is still no (and never be) compression of the data. So it takes its time to transfer the data.

Even a wired 100MBit/s connection can transfer roughly only 10MByte/s meaning that a 20MB picture needs at least 2s. Add some Wifi encryption overhead and some delay to open and close the API connection and it's way more than 2 seconds. I think CPU and RAM should not be a limiting factor as long as both is not peaking to 100% anyway. But a pc with only 2GB might be overloaded already with only running Win10 although it's within the "minimum requirements" specs. 

 

I will provide some updates on transfer times and delays when I finished the configuration of the 5GHz 433MBit/S wifi connection.

[bmcclana]

I'm pretty sure it is more than just transfer time. 

 

if I watch the cpu usage and network traffic while I'm watching the exposures in sharpcap, I see an exposure start, and then finish, then the CPU on the stick increases moderately for several seconds, then it goes even higher at the same time the network traffic kicks on. the actual network transfer only takes 4-5s for my images. 

 

The images are 16 bit raw 20 megapixel files, so the raw fits/pngs are usually 90-100MB, so transferring at 200Mbps, 4-5s makes sense for the actual data transfer. 

 

Its the lag time between the exposure finishing and the network transfer beginning that is the real bottleneck on the little stick computer.

 

the Cpu is an ATOM x5-Z8330 1.44GHz.  I'm pretty sure it is the equivalent of a toaster compared to a newer mobile CPU.  a quick benchmark search shows it is about 1/3 as powerful as the one you referenced.

 

... probably time for me to upgrade....

[CA Curtis 17]

I use a mini-pc at the rig to control everything and connect remotely via WiFi with a GL.iNET 750-EXT router, also know as the Slate.  This has worked perfectly for me over the last year plus while out in the field.  I connect to the mini-pc with my laptop to see what is going on and to make changes using the laptop as a terminal connected via Team Viewer.   If the weather is cold I can go inside my RV and still maintain a reliable connection to the mini-pc while warm and cozy. 

 

I recently set up the Slate in Extender or Repeater mode at home to connect to the mini-pc in my backyard observatory using my home wireless network from anywhere in my house.  Since I have an Ethernet cable to my observatory I only did this to see if it worked and it worked great.

 

So, having seen a number of threads where folks are asking what they need to set up a wireless connection and how to do it, I created a video to show how it is done using the Slate.  I am not suggesting this is a better method than the OPs suggestion of using Alpaaca, just a different way that also works.  If you are interested in a wireless setup or are having issues setting one up you may find this video helpful https://www.youtube....h?v=r17v2D5MDnU

 

Best Regards,

Curtis

[bmcclana]

I tried my setup outside and while functional, it wasn’t very usable.

I’m going to try again with my more powerful scopeside computer to see you much it helps.

I may try this stick computer again with a different 2Mp camera to see if that works any better.

[BrentKnight]

Curtis,

 

I wanted to watch your video, but I get this screen when trying...

 

 

 

 

[scopewizard]

I have tried Alpaca and it did worked fine except for the slow download of the image.

My only concern was the need to run the laptop for the entire imaging session.

 

On most reported setup issues, the loss of wifi connection is often the number one problem.

With everything within a minipc on the mount, power requirement is very low.

If I loose wifi remote connection on my laptop, the session on the minipc carries on. I can reconnect or wakeup from sleep mode my tablet or laptop once in a while to see if all is well.

The minipc operates using about 6 watts or 0.5 amps@12 vdc, a laptop requires a lot more power, some as much as 45 watts or almost 4.0 amps@12vdc.

 

At a remote location with no power source, one will require extra batteries powerful batteries as a power source.

 

With my setup, I only require a single power source located at the mount.

My Samsung tablet using RDP can last for over 6 hours if I leave it on, in sleep mode, 3 nights of imaging if awake for 5 mins every hours. 

 

To me I see good and bad for both systems. One needs to adopt the system they trust.

[CA Curtis 17]

Curtis,

 

I wanted to watch your video, but I get this screen when trying...

 

Error with youTube.jpg

Brent

 

Sorry about that.  I had to edit the video and it is back up now.

 

Regards

Curtis

[Noah4x4]

Just a point of wider technical information regarding the stated Cons of Option B...

In Windows 10 Pro Remote Desktop, the level of RemoteFX compression is managed by a setting that can be changed in Group Policies found under Computer configuration > Administration templates > Windows components > Remote Desktop Services > Remote Desktop session host > Remote Desktop Environment > configure compression for RemoteFX data.

The default high level of compression is designed to prevent a commercial network with many users from becoming choked by the data from a single user. This concern isn't relevant on your personal WAN, so if your computers are powerful enough and your WiFi network offers 100Mbps or higher, you can, in effect, turn it off. Unrestricted data will then fly across your WAN.

I have no difficulty in option B even with uncompressed 4K UHD screen data transmission, but this was the tip that unlocked it, and why I recommend a eighth generation i7 with 16Gb RAM and 5Ghz WiFi to support this. If prepared to NOT unlock RemoteFX compression and suffer the default high level of compression, then you can inevitably get away with lesser computing and communications power. I have not seen a route to control this feature in TeamViewer or any other RDP application, which is why I think Windows 10 Pro Remote is worth its £110 price, plus it is so easy to configure.

EDIT.
It is true that if your scope side computer running 'headless' won't connect to your network you might need a monitor, mouse and keyboard on hand to diagnose issues. But once correctly configured to a sufficiently powerful network, I don't find this an issue. What I do is set-up two networks to auto connect. The primary is my 5Ghz WAN and the secondary is my mobile phone as a 'hot spot'. If there is ever an issue with my WAN, I can instead connect the two computers via my phone. Of course, until you enable "allow others to connect" its hot spot will be inoperative. Provides an easy solution when you need to take a diagnostic look at settings and your regular WAN won't place nicely, like after an annoying Windows or Security update switches something off or restores a setting back to its default, or if you have a change (like change or router). .

Edited by Noah4x4, 20 February 2022 - 08:00 PM.

[natlion]

I have a similar setup as the OP -- with a NUC at the scope running the Alpaca Server and a wired ethernet connection to the house. I was trying for a couple of days to get SharpCap talking to the Alpaca devices -- to no avail. Finally figured out that SharpCap does not make the Alpaca Chooser available, so there is no way to set up the remote devices in SharpCap.

 

Solution was to use APT to choose the devices which sets up the devices properly in ASCOM -- after that, SharpCap can then access all the Alpaca connected devices. At this point I went into the ASCOM profile explorer and renamed my new Alpaca connected devices to names that indicated that they were network devices (not local) so that when I use SharpCap to connect, I am picking the proper devices.

 

Hopefully someday soon SharpCap will implement the ASCOM Chooser, or ASCOM will bring back a standalone Alpaca device configuration tool, but until then this is a workaround.

[bmcclana]

I have a similar setup as the OP -- with a NUC at the scope running the Alpaca Server and a wired ethernet connection to the house. I was trying for a couple of days to get SharpCap talking to the Alpaca devices -- to no avail. Finally figured out that SharpCap does not make the Alpaca Chooser available, so there is no way to set up the remote devices in SharpCap.

Solution was to use APT to choose the devices which sets up the devices properly in ASCOM -- after that, SharpCap can then access all the Alpaca connected devices. At this point I went into the ASCOM profile explorer and renamed my new Alpaca connected devices to names that indicated that they were network devices (not local) so that when I use SharpCap to connect, I am picking the proper devices.

Hopefully someday soon SharpCap will implement the ASCOM Chooser, or ASCOM will bring back a standalone Alpaca device configuration tool, but until then this is a workaround.

Correct sharpcap doesn’t use the ASCOM chooser. But you can setup the alpaca devices using the ASCOM diagnostics program to do the alpaca discovery and setup the dynamic clients just as you described with APT.

I have also been renaming the devices using the profile explorer. Otherwise it is a bit of guessing which is local and which is network.

I have intended to put a feature request in the sharpcap forum to use the ASCOM chooser for cameras and hardware for just this reason.

[natlion]

Correct sharpcap doesn’t use the ASCOM chooser. But you can setup the alpaca devices using the ASCOM diagnostics program to do the alpaca discovery and setup the dynamic clients just as you described with APT.

I have also been renaming the devices using the profile explorer. Otherwise it is a bit of guessing which is local and which is network.

I have intended to put a feature request in the sharpcap forum to use the ASCOM chooser for cameras and hardware for just this reason.

Ran into same issue with N.I.N.A., this time with the filter wheel. Once again, used APT to set up the Alpaca device on the indoor PC, then it was available to N.I.N.A. Did not know that the ACSOM diagnostics had a menu link to the Alpaca Chooser -- but I see that now. It is pretty hidden, just sayin'...

[alphatripleplus]

Moderator Note:

 

Let's please keep the focus on using Alpaca to do remote EAA  rather than  with NINA or other traditional AP imaging software. Thanks.

[bhalkett]

...

And here a screenshot of the setup as it is running: On the right side you can see the desktop of the mini PC running Ascom Remote Server. On the left side you can see Sharpcap installed on a PC at my home, that has no camera attached to it, but that has access to the camera on the scope PC via Ascom Alpaca. You can also see that it's connected to the focuser and the mount... also via Alpaca.

 

(bigger version: https://abload.de/im...pc_alp03jj3.jpg)

 

In case you want to ride the Alpace too, then I am happy to help

...

Hi Christian,

 

I decided to give this a try based on what I saw you were doing here and during the last Messier Marathon.  I have an ASI533MCP--same as you I believe. I've notice that while connected to the camera through ACSCOM Alpaca the Brightness (offset) and color balance functionality is not available.  This is a bit of an issue for me.  Have you noticed this?  If so do you know of a workaround? Also, have you notice any other functionality missing while using ASCOM Alpaca?

 

Thanks! 

[bmcclana]

Hi Christian,

 

I decided to give this a try based on what I saw you were doing here and during the last Messier Marathon.  I have an ASI533MCP--same as you I believe. I've notice that while connected to the camera through ACSCOM Alpaca the Brightness (offset) and color balance functionality is not available.  This is a bit of an issue for me.  Have you noticed this?  If so do you know of a workaround? Also, have you notice any other functionality missing while using ASCOM Alpaca?

 

Thanks! 

I don't think this is Alpaca specifically, just ASCOM vs the native drivers.   if you connect using ASCOM to a camera locally the same limited controls are available compared to the native support in Sharpcap. 

[bhalkett]

I don't think this is Alpaca specifically, just ASCOM vs the native drivers.   if you connect using ASCOM to a camera locally the same limited controls are available compared to the native support in Sharpcap. 

I think we have a terminology thing going on here.  It's my understanding that ASCOM has split.  Classic ASCOM is not ASCOM COM and ASCOM Alpaca.  I believe when I say ASCOM Alpaca and you say ASCOM were are basically saying the same thing as long as we are talking about version 6.6.  I'm definitely not referring to ASCOM Remote Server.

 

I would find this difficult to use for EAA without the Brightness/Offset and color balance functionality regardless if it's local or running remote.

[MarMax]

Great article.  I just got most of this stuff setup on my rig.  I don't do the whole thing on my home PC, it's more of a hybrid mode.  I keep SharpCap running on the mini, but I run SkySafari, SkyTools on the home PC.  This still frees up resources on the mini, but the planetarium and planning software runs much, much better now and I don't have to worry about dropped connections dropping my session.

 

Having used my system all three ways, Remote/AlpacaScope feels like magic!

 

I don't think this is Alpaca specifically, just ASCOM vs the native drivers.   if you connect using ASCOM to a camera locally the same limited controls are available compared to the native support in Sharpcap. 

It sounds like if you want the maximum control of the camera you need to run SharpCap on the mini-PC with the Alpaca configuration. So does this defeat the ability to use an older/slower mini-PC?

 

Is a mini-PC with a Celeron J4125(up to 2.7GHz) and 8GB DDR4 RAM enough to run SharpCap at the mount with APS-C or smaller sensors if everything else is on the remote laptop?