100 replies to this topic

[telfish]

Why not just use an ASIAIR pro? An all in one solution. Weight next to nothing. 

[gdsolz]

Why not just use an ASIAIR pro? An all in one solution. Weight next to nothing. 

I did consider buying the upcoming ASIAIR Pro but some features that were critical to me would not work with it.

 

The ASIAIR Pro is not compatible with every camera. If some new astrocamera ever comes out from another company that ASI, I'm worried it will end up in the "not supported" list in the coming years. However, for those that already have a ASI branded camera, the ASIAIR Pro is an interesting device.

Edited by gdsolz, 11 January 2020 - 08:14 PM.

[Gyroman]

Why not just use an ASIAIR pro? An all in one solution. Weight next to nothing. 

The ASIAIR Pro looks like another nice solution but like everything else, it leaves the computing power at the scope and you're looking for the best way to connect to that.

 

This solution if it works essentially only has a USB hub at the scope.

 

Also, I can only assume the ASIAIR Pro will be entirely proprietary.  You use the software that's installed with it and have few or no other options.

 

I love Sharpcap, its works great and has a tremendous set of tools, for now I want to keep using it.  However this solution should allow me to use SGP, APT or whatever tool set I desire as long as I have access to the ports.  My software choices are not limited by the device.

 

Also, this will cost less than $150 for the Pi, Case, SD Card, Power Supply and software, half the price of the ASIAir Pro.

 

For me I'm really hoping this works for all those reasons but everyone has their own wants and desires.

[sbradley07]

I've been following this thread with great interest, and like others, would be interested in more results from full imaging sessions.  This solution is functionally not that much different than just running INDI server on a pi connected to the scope and running your session from an INDI client remotely connected; the INDI server manages the usb connected devices and makes them available to the client over the network.  The big difference with gdsolz's solution is that those devices are available to any application, so you are free to choose whatever imaging software you want.  (There are other differences I know...I'm just using INDI somewhat metaphorically)

 

Still, the architecture makes the network the critical component of the whole solution.  If you've got a strong, reliable one, this solution is ideal.  Over ethernet, this solution is a no brainer!  But if it's somewhat sketchy or bandwidth-constrained wifi, it could be problematic; a dropped port (or worse, a client crash) would ruin a session.  So I'd love to hear more real world results using this set up.  I'm going to get the trial version and take it for a spin.  

[telfish]

The ASIAIR Pro looks like another nice solution but like everything else, it leaves the computing power at the scope and you're looking for the best way to connect to that.

 

This solution if it works essentially only has a USB hub at the scope.

 

Also, I can only assume the ASIAIR Pro will be entirely proprietary.  You use the software that's installed with it and have few or no other options.

 

I love Sharpcap, its works great and has a tremendous set of tools, for now I want to keep using it.  However this solution should allow me to use SGP, APT or whatever tool set I desire as long as I have access to the ports.  My software choices are not limited by the device.

 

Also, this will cost less than $150 for the Pi, Case, SD Card, Power Supply and software, half the price of the ASIAir Pro.

 

For me I'm really hoping this works for all those reasons but everyone has their own wants and desires.

Not really, the computing power is at the tablet not the scope. The Pi at the scope just runs a limited firmware.

[sbradley07]

Not really, the computing power is at the tablet not the scope. The Pi at the scope just runs a limited firmware.

This is not true.  Almost all of the computing is done on the ASIAir.  The tablet is not running the camera, focusing, guiding, plate-solving, etc.  It is allowing you to interact with and control the software on the device.

Edited by sbradley07, 11 January 2020 - 10:21 PM.

[telfish]

This is not true.  Almost all of the computing is done on the ASIAir.  The tablet is not running the camera, focusing, guiding, plate-solving, etc.  It is allowing you to interact with and control the software on the device.

Not as It has been described to me but whatever.

[ccs_hello]

ASIair (or ASIair Pro) is a completely different approach (traditional doing majority of the work on the mount-side computer) than what this thread is talking about (a USB protocol "RELAY" solution).

Let's not hijack this thread.

[alphatripleplus]

Everyone, please note that we can compare alternative solutions with that proposed by the OP, as long as we do not drift off into a discussion of just the alternatives, without reference to OP's Raspeberry Pi wireless solution. Thanks.

[sbradley07]

Gdsolz, I’ve done some initial testing and I gotta say, I am getting more on board with VirtualHere…though not necessarily for the use-case you initially describe. 

 

I actually run with a Raspberry pi and Intel NUC at my scope (permanent setup).  I was a computer geek before this AP hobby, so I am always tinkering with hardware, software, networking, etc.  When I’m imaging at home, I mostly use NINA on the NUC, sometimes SGP.  Stellarmate is on the pi, and that’s for imaging on-the-go, but I keep it out there to keep it up to date and test new releases.  I’ve always had the problem of easily switching my one set of equipment between the two imaging platforms; you guessed it, I have to physically swap usb cables…though I have a KVM switch to make this a little easier.

 

But VirtualHere solves this problem very neatly.  I installed VH Server on the Pi, and connected all my equipment to it.  I then installed the VH Client on the NUC, connected the port (only one port allowed in the trial version) for my Nikon, and had NINA connect the camera.  Worked like a charm!  Now I can test my equipment with both platforms without having to physically intervene at the scope. 

 

Since I only have the trial version, I can’t really stress test it to see how robust it will be from a bandwidth perspective.  Might have to drop the $50 for the full version ;-)

[gdsolz]

Gdsolz, I’ve done some initial testing and I gotta say, I am getting more on board with VirtualHere…though not necessarily for the use-case you initially describe. 

 

I actually run with a Raspberry pi and Intel NUC at my scope (permanent setup).  I was a computer geek before this AP hobby, so I am always tinkering with hardware, software, networking, etc.  When I’m imaging at home, I mostly use NINA on the NUC, sometimes SGP.  Stellarmate is on the pi, and that’s for imaging on-the-go, but I keep it out there to keep it up to date and test new releases.  I’ve always had the problem of easily switching my one set of equipment between the two imaging platforms; you guessed it, I have to physically swap usb cables…though I have a KVM switch to make this a little easier.

 

But VirtualHere solves this problem very neatly.  I installed VH Server on the Pi, and connected all my equipment to it.  I then installed the VH Client on the NUC, connected the port (only one port allowed in the trial version) for my Nikon, and had NINA connect the camera.  Worked like a charm!  Now I can test my equipment with both platforms without having to physically intervene at the scope. 

 

Since I only have the trial version, I can’t really stress test it to see how robust it will be from a bandwidth perspective.  Might have to drop the $50 for the full version ;-)

Yeah, that's the whole idea, you have access to all the ports on every device you own on the network. You can decide to do the imagine on the devices on the scope or choose to do it remotely. Earlier today I made some test, everything works but I have yet to test if the small delay introduced by the wifi affect guiding. I'm in Canada near Ottawa so it's mostly a mix of freezing rain, snow and clouds for the upcoming days. If signal is not strong enough, I can always add a USB 3.0 5db wifi antenna to the PI.

[StarmanDan]

If I were to install VH on my stellar mate would I be able to interchange using my gear between OS's? At home I prefer to use windows but in the field I like stellar mate as I don't need to bring a laptop.

[gdsolz]

If I were to install VH on my stellar mate would I be able to interchange using my gear between OS's? At home I prefer to use windows but in the field I like stellar mate as I don't need to bring a laptop.

It should work, that is indeed another possible use-case of VirtualHere. Although it's a proprietary solution, someone with a better understanding of programming might be able to integrate it (I'm positive that it's based on usblib)

Edited by gdsolz, 13 January 2020 - 06:41 PM.

[sbradley07]

If I were to install VH on my stellar mate would I be able to interchange using my gear between OS's? At home I prefer to use windows but in the field I like stellar mate as I don't need to bring a laptop.

This is exactly the scenario I described four posts back.  I use the Stellarmate OS on a Pi 4...I am not using the Stellarmate device, which is Pi 3.  If you have the device, I cannot comment on the performance you will get running VH on it.  Either way, VH will run on the same device you have Stellarmate installed on.  But you only need to run VH when you are using Windows.  When you're in the field, you'd just use Stellarmate as normal.

[hcf]

I tried something like sbradley07 tonight.

 

I have an arm64 box running armbian on which I use gphoto2 for image acquisition, and lin_guider to guide.  I downloaded the Virtual Here server for arm64 and ran it side by side with everything (not a separate boot). I then forwarded one port (as allowed in the free version), the Canon DSLR port to Windows, and used DigiCamControl on Windows to take pictures. So DigiCamControl sees the DSLR connected to USB, but in reality goes over the VH client on Windows to the armbian box VH server to the DSLR.  My network is not optimized, running 2.4 Ghz (mix of N and G) so speeds are slow, RAW file transfer took some time. But it worked.

 

My hope is, if I can get the DSLR ASCOM drivers for my DSLR working on Windows, I could use SharpCap on my desktop inside the house connecting to the camera, with everything else running on the armbian box at the mount. 

 

Virtual Here has optimized versions of the server for many arm processors, but those are only available under a license, so that might help speed things up too.

 

[Noah4x4]

The benefit of this project is that I could put a small, compact, internal (HAT) battery powered Raspberry Pi 4 at my scope and replace my heavier, bulkier Intel NUC and it's very heavy 19v battery. This is all about weight reduction at scope for me, and not about technology achievement. It's worth me investing £100 in Pi gear to see if it works for me.

 

The problem with threads like this is they soon become confusing because advanced users start competing for an award for best further innovation before the rest of us have even grasped the basics. Can somebody please bring this back down to simple levels? I currently use twin Intel NUCs and Microsoft Remote Desktop and could write a step by step guide to get a novice using that technique within an hour without them ever knowing how it works.. To me Raspberry Pi/Linux might as well be a foreign language. I need similar guidance. 

 

I get how the Raspberry Pi acts merely as a USB Server/WiFi hub and how data is transferred to be processed on a laptop indoors. But how does a Rasberry Pi novice get started with this project? How do you autorun Virtualhere on boot up? I have no desire to learn Linux or become a Pi Geek. I would welcome simple "how to" instructions that might allow me to get this up and running in under an hour. 

[ccs_hello]

TL; DR

 

Sorry finally got some free time to talk about it.

 

USB, due to its "so universal", has a few corner cases throughout its history.

Some of the issues got us the amateur astronomers that are fairly will known.  So certainly need to be answered before declaring victory.

 

A. Power related

Some astro gears are USB-powered.  In Pi 3/4, etc. its USB ports can only supply juice the Pi board itself is being supplied (typically a 5V 2A power supply.)   This is why ASIair Pro goes extra mile to redo its USB ports to get it to supply extra juice when needed.

 

B. General USB gears related

Some USB gears using the same USB controller with the same USB HID.  This happens the most on USB-serial port.  The USB host side has to somehow remember the matching (the order of port enumeration) such that the order/mapping is correct. 

 

C. Isochronous transfer mode USB with double enumeration

This topic I had stated many times in the past and usually is the gotcha heart sunk disappointing moment.

I.e., many USB 2.0 astrocameras and guidecams are using the most basic Cypress EZUSB-FX2 USB controller and operate it in USB high-speed (480Mbps)  isochronous transfer mode.

Any USB-protocol relay solution has to find a way to tackle that and make it "somewhat" work with the driver.

Some simply falls on its face and some working.  

<--  TEST TEST TEST

 

C1. sub case of (C )

In the past, some had noticed by running two of such devices over the same conduit (USB cable), the relay solution does not work.  Some even found out that by mixing a heavily used isochronous mode device with regular traffic type causes the former to fail.

 

D. non-dedicated traffic channel (wired IP Ethernet or WiFi) vs. dedicated channel (USB cable, or USB repeater cable)

This is physical reality.  USB 2.0 High speed is 480 Mbps.  Some USB methods can tolerate lower speed as choked channel but isochronous mode is very sensitive.  In astrocamera case, it is bursty (need attention when it is needed or buffer overflow happens and software falls on its face.)

Planetary astrocam will stream all the time and will chew the bandwidth as much as it can.

USB 3.x Super Speed (most often seen is 5 Gbps, now getting into 10 Gbpgs and 20 Gbps) will be even worst when time comes .(Luckily, most of the USB3 astrcams I have seen have built-in buffer and stay away from isochronous mode.  Hope it stays that way.)

 

Now if using WiFi, the bandwidth will not always that high (type of WiFi spec it uses and how congested the air is) and can stop at times.

In IP-based wired Ethernet (not just the 4 twisted-pair of wires as pure transport), it is subject to other traffic on that same network so symptom mentioned above may happen.

 

Sorry for a load of tech discussions.  Just try o explain what is underneath and why USB long haul solution is not that trivial.

If V.H. works in all cases, good for them and do report back to the community here.

[beammeup]

I connected 2 laptops with Virtualhere, both laptops connected to high speed 5ghz router.

On laptop 1,  I connected a ZWO ASI224MC camera, got around 30fps in Asiair (ASISTUDIO) with USB 2.0 and 65fps with usb3.0,

I got the same result (fps) with Sharpcap (on laptop 1 with camera connected on USB port on laptop 1).

 

On the other laptop (connected with Virtualhere server/client) the speed was very disappointing, only about 2fps.

Unless I am missing something it's not really the solution that I am looking for.

Edited by beammeup, 28 January 2020 - 11:08 AM.

[Gyroman]

I connected 2 laptops with Virtualhere, both laptops connected to high speed 5ghz router.

On laptop 1,  I connected a ZWO ASI224MC camera, got around 30fps in Asiair (ASISTUDIO) with USB 2.0 and 65fps with usb3.0,

I got the same result (fps) with Sharpcap (on laptop 1 with camera connected on USB port on laptop 1).

 

On the other laptop (connected with Virtualhere server/client) the speed was very disappointing, only about 2fps.

Unless I am missing something it's not really the solution that I am looking for.

For the vast majority of my EAA the exposures are at least 1 second long and quite often 10-15 seconds.  For EAA or astrophotography use I'm not sure that fast frame rates are necessarily needed.  Obviously this would be entirely different story for most planetary work.

 

I have all the equipment here, just haven't found time to put it together and test.  Won't know for sure until I try.

[myzsot]

I hope I'm not terribly off-topic, I had the same issue (wireless setup) but went a different route. 

In my opinion, the Raspberry is never going to be able to achieve the same performance as a miniPC or a laptop, not when you are running your camera in 150+ FPS. I started to build my own solution (inspired of course from the internet) which I call tote computing.

Requirements/constraints I followed:

- both on-site and wireless control

- mainly used for my backyard, AC power is not an issue

- simple assembly before imaging

- relatively low weight (not a permanent setup)

 

The setup consists of:

- cheap laptop (I5 + 8GB RAM) + SSD swap

- 7 port USB3 powered USB hub: connects the main imaging camera, the mount and the focuser

- AstroZap dew shield controller

- Pegasus Astro 12V/10A power supply: to power the mount and the dew shield

- 4 GFCI protected outlets

 

I am using TeamViewer to control the whole thing remotely. I am attaching a picture, maybe it inspires some of you...

Attached Thumbnails

• 

[gdsolz]

I like the tidyness of your setup. One box for everything is very conveniant to carry.

 

The Raspberry Pi is not meant to be a replacement for a computer, but rather a bridge. Having USB 3.0 on the Pi 4 and using VirtualHere makes it interesting for a truly wireless solution. 

 

I'm still working on the project but the temperature have been pretty bad these few past weeks, it's either covered by cloud or -20C (-31F) outside :/

 

I recently bought a QHY163M + Filters and it's seems to be working through virtual here without issues. I haven't tested planetary but for regular long exposure it transfers the picture correctly.

Edited by gdsolz, 01 February 2020 - 04:43 PM.

[TelescopeGreg]

I like the tidyness of your setup. One box for everything is very conveniant to carry.

 

The Raspberry Pi is not meant to be a replacement for a computer, but rather a bridge. Having USB 3.0 on the Pi 4 and using VirtualHere makes it interesting for a truly wireless solution. 

 

I'm still working on the project but the temperature have been pretty bad these few past weeks, it's either covered by cloud or -20C (-31F) outside :/

 

I recently bought a QHY163M + Filters and it's seems to be working through virtual here without issues. I haven't tested planetary but for regular long exposure it transfers the picture correctly.

Actually, I find the Pi very adequate for running everything I use locally.  It can be used in a split system (INDI on the Pi, User Interface stuff on a laptop), but I use CCDciel, PHD2, and ASTAP all locally on the Pi, with INDI of course under it all.  Serves all my needs at the present.  I was using a Pi-3B, but just upgraded to a 4gb Pi-4B with the Astroberry Server 2.0 release.

 

That said, I often use a laptop as a VNC client to the Pi, and it could definitely use some protection from the dew.  For simple nights, I use either a tablet or my cell phone as the VNC client, and they get turned off and put in a pocket once things are launched.

[myzsot]

I should have mentioned this in my original post: I'm pretty sure that the RPi4 is able to handle (almost?)everything for deep sky photography, my setup is dedicated to lunar photography though. Even the CoreI5+8GB RAM laptop is fully loaded when taking very high frame rate videos. The RPi would not stand a chance as a computer or bridge either.

[ccs_hello]

My own post #42 stated TL;DR so I should make this post short...

 

In brief, isochronous transfer mode of certain imagers (span across at least a 10-year period that most of the USB2 imagers are using that) is the main challenge.

 

In post #46, OP said he is using QHY163M.  Note that this one is USB 3 cam and has internal 128MB buffer, thus no longer fall under the same category I mentioned above.

 

Also note that earlier there was a post mentioning many of us are not doing high frame rate as in planetary imaging thus (reasonably) long exposure would not caused the issue.

My response is: it depends.  In many USB2 without frame buffer implementations, the image read-n-transfer operations cannot be slowed down.

I.e., even at the low frame rate (say once every 2 seconds), isochronous transfer mode can cause imaging session failure (abrupt end).

Why is that?  If not be special design, the image sensor readout will still be fast and simply cannot be slowed down/stopped at will (no frame buffer at disposal.)

Think the scenario is similar to an Interstate highway with both the maximum and minimum speed limit with no yield lane and no passing.

Then there is a game that a car will have to enter this one-lane highway entrance every 2 seconds, but the car must not be slower than 45 miles/hour no matter what.

Edited by ccs_hello, 02 February 2020 - 01:43 PM.

[giorgio_ne]

The VirtualHere approach has been mentioned in the past here on CN:

https://www.cloudyni...sb-over-ip-hub/

and

https://www.cloudyni...r/#entry6789537

 

With the advent of the more powerful RPi 4 last summer things should run much smoother than in 2015.

I’m going to try this ASAP. I’m a fan of INDI on Raspberry Pi but its overall stability is still a concern for me.

Regards,

Giorgio

 

PS

Moravian Instruments also sells a similar gadget although is not a WiFi one.

https://www.gxccd.co...roduct&page=857

Edited by giorgio_ne, 02 February 2020 - 07:12 PM.