Date   

Re: Connecting ASIAIR Pro to a CP4 - Mach1

Lee Decovnick
 

Ok, thanks .I'll work on the USB to ASI AIR Pro connection. I'll check to  see If I have  an honest to goodness FIDI chip cable. I have an iPad, which I could use in place of the Windows emulation.


AP1100/CP4 and NINA

Michael 'Mikey' Mangieri
 

I recently decided to try N.I.N.A. as a possible replacement for SGP which I have used for years.  Was wondering if the AP community has any issues with using NINA with respect to meridian flips, CW-UP slews, and such?


Re: Losing Communications with the Mount

Donald Gaines
 

Hi Christopher,
My computer has no RS-232 (Serial I think) ports, just USB.  Would the 15’ serial cable that comes with the 1100GTO mount along with the Astro-Physics Serial to USB converter, provide the same performance and reliability as the RS-232 you mention below?
BTW, Observatory Engineer.....in Hawaii.....you must really enjoy going to work!
Thanks,
Don Gaines


On Thursday, May 6, 2021, Christopher Erickson <christopher.k.erickson@...> wrote:
TCP is more reliable than UDP if there are a bunch of lost packets on your network for some reason. Bad cable someplace, congestion, etc.In other words, TCP can hide a network problem that UDP does not. If UDP doesn't work, it is worthwhile trying to find out why and fixing it.

Also check your Ethernet cable lengths. Any cable over 100m can cause timeouts, retransmission congestion and packet loss.

Mixing different brands and vintages of Ethernet switches can sometimes cause problems. Different vintage Ethernet transceiver chips, different protocol capabilities, etc.

Get rid of any old Ethernet hubs.

Home made cables can have various issues due to bad crimps, crossed pairs, etc.

Check all cable connectors & sockets for oxidation, corrosion, bent pins, etc.

Make sure there is only one DHCP server on your network.

Always use Ethernet instead of WiFi, when you can.

The most robust and reliable mount communications option of all is RS-232 to a real serial port on your observatory computer. Second-best option is USB. Third is Ethernet and last place goes to WiFi. Ethernet is less reliable than USB because Ethernet and TCP use connectionless, multi-point protocols that make any device-to-device communications more vulnerable to disruption by a multitude more things. Also, most USB connectors are total, unreliable cr*p.

Wireshark is a free, open-source network diagnostic tool that can give you insights into your network. It is very powerful and does have a bit of a learning curve.

PingPlotter is a great, simple diagnostic tool that can be used to track down network congestion and packet loss in your network and your Internet connection.

Make sure you aren't suffering from duplicate IP addresses on your network. The WiFi and Ethernet ports MUST have different IP addresses from each other. Same goes for every single device port on your network.

If you have smart Ethernet switches that let you lock Ethernet ports to soecific, lower protocol speeds, try lowering them all to 10 or 100 MBPS and see if your network problems go away. Could be an auto-negotiation incompatibility issue between the switch and your CP4. Also if you have a smart switch, check its port statistics for clues.

I hope this helps.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Wed, May 5, 2021, 2:35 PM Ray Gralak <iogroups@...> wrote:
> Also, the mount stops tracking when communications starts failing.
> If it was just a communications failure
> between the computer and the mount, wouldn’t the mount continue to track?

When APCC is in use, its Safety Park feature will cause the mount to stop tracking if the mount does not receive regular messages from APCC.

So, that the mount stopped tracking indicates that communication failed in some way.

-Ray


> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of alex
> Sent: Wednesday, May 5, 2021 3:41 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] Losing Communications with the Mount
>
> I had already upped the timeout to 200ms, so I’ll try 400ms.  The mount is directly connected to a switch in my
> observatory.  The only other thing plugged into that switch is my UniFi WiFi access point, which is mounted in
> the observatory.  My computer (a piggy backed eagle 2) is the only thing using that access point, so
> communications is Eagle2 -> AP -> Switch -> Mount.  Said switch is backhauled to my house’s main switch,
> and the only traffic between the house and the observatory is my Mac connecting to the Eagle2 using Microsoft
> Remote Desktop. The Remote Desktop connection to the eagle has been rock solid.
>
> I had pings repeating from my wired Mac in the house, and when the problem happens, the pings start failing
> and stay failing until the mount is power cycled, at which point the pings start working again. APCC re-
> establishes communications once the mount is power cycled with no other intervention on my part.
>
> Also, the mount stops tracking when communications starts failing.  If it was just a communications failure
> between the computer and the mount, wouldn’t the mount continue to track?
> Communications failed again as I was writing this response.  The mount was parked at the time.  I had bumped
> the timeout to 400ms and switched to UDP before hand.  Pings to the mount’s hard wired ethernet IP address
> is failing, but curiously I can ping the mount’s WiFi IP address, though if I disconnect from the mount in APCC
> and try connecting it via that WiFi address, it still get’s no response from the mount.  Again, a few seconds after
> power cycling the GTOCP4, everything is working again.
>
> I’ll try snaking a USB cable down from the Eagle 2 to the mount and try that as backup or perhaps the primary.
> If that also fails, then I’ll pop open the GTOCP4 and check the daughter board seating.
>
> Alex
>
>







Re: Losing Communications with the Mount

 

All good advice from Christopher. Adding on to this,

 

Try increasing your timeout even more. 400ms is high for serial, and is fine for just ethernet on it’s own, but can be on the low side for wifi connections. Additionally, can you send us a picture of the setup? Sometimes a problem might not be obvious from the description alone. After that, checking all of your cables, even the power for the ethernet switch, is a good thing to do.

 

Liam

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Christopher Erickson
Sent: Thursday, May 6, 2021 1:27 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Losing Communications with the Mount

 

TCP is more reliable than UDP if there are a bunch of lost packets on your network for some reason. Bad cable someplace, congestion, etc.In other words, TCP can hide a network problem that UDP does not. If UDP doesn't work, it is worthwhile trying to find out why and fixing it.

 

Also check your Ethernet cable lengths. Any cable over 100m can cause timeouts, retransmission congestion and packet loss.

 

Mixing different brands and vintages of Ethernet switches can sometimes cause problems. Different vintage Ethernet transceiver chips, different protocol capabilities, etc.

 

Get rid of any old Ethernet hubs.

 

Home made cables can have various issues due to bad crimps, crossed pairs, etc.

 

Check all cable connectors & sockets for oxidation, corrosion, bent pins, etc.

 

Make sure there is only one DHCP server on your network.

Always use Ethernet instead of WiFi, when you can.

 

The most robust and reliable mount communications option of all is RS-232 to a real serial port on your observatory computer. Second-best option is USB. Third is Ethernet and last place goes to WiFi. Ethernet is less reliable than USB because Ethernet and TCP use connectionless, multi-point protocols that make any device-to-device communications more vulnerable to disruption by a multitude more things. Also, most USB connectors are total, unreliable cr*p.

 

Wireshark is a free, open-source network diagnostic tool that can give you insights into your network. It is very powerful and does have a bit of a learning curve.

 

PingPlotter is a great, simple diagnostic tool that can be used to track down network congestion and packet loss in your network and your Internet connection.

 

Make sure you aren't suffering from duplicate IP addresses on your network. The WiFi and Ethernet ports MUST have different IP addresses from each other. Same goes for every single device port on your network.

 

If you have smart Ethernet switches that let you lock Ethernet ports to soecific, lower protocol speeds, try lowering them all to 10 or 100 MBPS and see if your network problems go away. Could be an auto-negotiation incompatibility issue between the switch and your CP4. Also if you have a smart switch, check its port statistics for clues.

 

I hope this helps.


-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

 

On Wed, May 5, 2021, 2:35 PM Ray Gralak <iogroups@...> wrote:

> Also, the mount stops tracking when communications starts failing.
> If it was just a communications failure
> between the computer and the mount, wouldn’t the mount continue to track?

When APCC is in use, its Safety Park feature will cause the mount to stop tracking if the mount does not receive regular messages from APCC.

So, that the mount stopped tracking indicates that communication failed in some way.

-Ray


> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of alex
> Sent: Wednesday, May 5, 2021 3:41 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] Losing Communications with the Mount
>
> I had already upped the timeout to 200ms, so I’ll try 400ms.  The mount is directly connected to a switch in my
> observatory.  The only other thing plugged into that switch is my UniFi WiFi access point, which is mounted in
> the observatory.  My computer (a piggy backed eagle 2) is the only thing using that access point, so
> communications is Eagle2 -> AP -> Switch -> Mount.  Said switch is backhauled to my house’s main switch,
> and the only traffic between the house and the observatory is my Mac connecting to the Eagle2 using Microsoft
> Remote Desktop. The Remote Desktop connection to the eagle has been rock solid.
>
> I had pings repeating from my wired Mac in the house, and when the problem happens, the pings start failing
> and stay failing until the mount is power cycled, at which point the pings start working again. APCC re-
> establishes communications once the mount is power cycled with no other intervention on my part.
>
> Also, the mount stops tracking when communications starts failing.  If it was just a communications failure
> between the computer and the mount, wouldn’t the mount continue to track?
> Communications failed again as I was writing this response.  The mount was parked at the time.  I had bumped
> the timeout to 400ms and switched to UDP before hand.  Pings to the mount’s hard wired ethernet IP address
> is failing, but curiously I can ping the mount’s WiFi IP address, though if I disconnect from the mount in APCC
> and try connecting it via that WiFi address, it still get’s no response from the mount.  Again, a few seconds after
> power cycling the GTOCP4, everything is working again.
>
> I’ll try snaking a USB cable down from the Eagle 2 to the mount and try that as backup or perhaps the primary.
> If that also fails, then I’ll pop open the GTOCP4 and check the daughter board seating.
>
> Alex
>
>






Re: AP1600 w/AE manual #Absolute_Encoders

Dhaval
 

Thanks George! I shouldn't even have bothered!! Thanks for keeping it simple.

Dhaval


Re: Losing Communications with the Mount

Christopher Erickson
 

TCP is more reliable than UDP if there are a bunch of lost packets on your network for some reason. Bad cable someplace, congestion, etc.In other words, TCP can hide a network problem that UDP does not. If UDP doesn't work, it is worthwhile trying to find out why and fixing it.

Also check your Ethernet cable lengths. Any cable over 100m can cause timeouts, retransmission congestion and packet loss.

Mixing different brands and vintages of Ethernet switches can sometimes cause problems. Different vintage Ethernet transceiver chips, different protocol capabilities, etc.

Get rid of any old Ethernet hubs.

Home made cables can have various issues due to bad crimps, crossed pairs, etc.

Check all cable connectors & sockets for oxidation, corrosion, bent pins, etc.

Make sure there is only one DHCP server on your network.

Always use Ethernet instead of WiFi, when you can.

The most robust and reliable mount communications option of all is RS-232 to a real serial port on your observatory computer. Second-best option is USB. Third is Ethernet and last place goes to WiFi. Ethernet is less reliable than USB because Ethernet and TCP use connectionless, multi-point protocols that make any device-to-device communications more vulnerable to disruption by a multitude more things. Also, most USB connectors are total, unreliable cr*p.

Wireshark is a free, open-source network diagnostic tool that can give you insights into your network. It is very powerful and does have a bit of a learning curve.

PingPlotter is a great, simple diagnostic tool that can be used to track down network congestion and packet loss in your network and your Internet connection.

Make sure you aren't suffering from duplicate IP addresses on your network. The WiFi and Ethernet ports MUST have different IP addresses from each other. Same goes for every single device port on your network.

If you have smart Ethernet switches that let you lock Ethernet ports to soecific, lower protocol speeds, try lowering them all to 10 or 100 MBPS and see if your network problems go away. Could be an auto-negotiation incompatibility issue between the switch and your CP4. Also if you have a smart switch, check its port statistics for clues.

I hope this helps.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   


On Wed, May 5, 2021, 2:35 PM Ray Gralak <iogroups@...> wrote:
> Also, the mount stops tracking when communications starts failing.
> If it was just a communications failure
> between the computer and the mount, wouldn’t the mount continue to track?

When APCC is in use, its Safety Park feature will cause the mount to stop tracking if the mount does not receive regular messages from APCC.

So, that the mount stopped tracking indicates that communication failed in some way.

-Ray


> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of alex
> Sent: Wednesday, May 5, 2021 3:41 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] Losing Communications with the Mount
>
> I had already upped the timeout to 200ms, so I’ll try 400ms.  The mount is directly connected to a switch in my
> observatory.  The only other thing plugged into that switch is my UniFi WiFi access point, which is mounted in
> the observatory.  My computer (a piggy backed eagle 2) is the only thing using that access point, so
> communications is Eagle2 -> AP -> Switch -> Mount.  Said switch is backhauled to my house’s main switch,
> and the only traffic between the house and the observatory is my Mac connecting to the Eagle2 using Microsoft
> Remote Desktop. The Remote Desktop connection to the eagle has been rock solid.
>
> I had pings repeating from my wired Mac in the house, and when the problem happens, the pings start failing
> and stay failing until the mount is power cycled, at which point the pings start working again. APCC re-
> establishes communications once the mount is power cycled with no other intervention on my part.
>
> Also, the mount stops tracking when communications starts failing.  If it was just a communications failure
> between the computer and the mount, wouldn’t the mount continue to track?
> Communications failed again as I was writing this response.  The mount was parked at the time.  I had bumped
> the timeout to 400ms and switched to UDP before hand.  Pings to the mount’s hard wired ethernet IP address
> is failing, but curiously I can ping the mount’s WiFi IP address, though if I disconnect from the mount in APCC
> and try connecting it via that WiFi address, it still get’s no response from the mount.  Again, a few seconds after
> power cycling the GTOCP4, everything is working again.
>
> I’ll try snaking a USB cable down from the Eagle 2 to the mount and try that as backup or perhaps the primary.
> If that also fails, then I’ll pop open the GTOCP4 and check the daughter board seating.
>
> Alex
>
>







Re: 1100GTO PEC question

Pete Mumbower
 

Good to know Rolando! This mount is truly amazing, guiding and point really are fading into the background and now the OTA/camera/and seeing are becoming my new problems!

Cheers,
Pete


Re: 1100GTO PEC question

Roland Christen
 

When you disconnect the worm gear, you are not changing the worm position in the gearbox. So, no problem. PE curve will stay synchronized to the worm angle. You can move the main worm wheel around to any position that you like and engage the worm gear in that new position. It does not affect the PE curve.

Rolando

-----Original Message-----
From: Pete Mumbower <pmumbower@...>
To: main@ap-gto.groups.io
Sent: Wed, May 5, 2021 9:17 pm
Subject: [ap-gto] 1100GTO PEC question

HI everyone,

Quick newbie question about the PEC on my new 1100GTO mount. If I use the lever to quickly disengage the RA/DEC for balancing the mount, does that effect the PEC at all? I tried to disengaged and reengaged both axis on the hash marks, but does the PEC know where the the worm is in relation to the worm wheel or does that not really matter a whole lot on these precision mounts?

Thanks!
Pete

--
Roland Christen
Astro-Physics


1100GTO PEC question

Pete Mumbower
 

HI everyone,

Quick newbie question about the PEC on my new 1100GTO mount. If I use the lever to quickly disengage the RA/DEC for balancing the mount, does that effect the PEC at all? I tried to disengaged and reengaged both axis on the hash marks, but does the PEC know where the the worm is in relation to the worm wheel or does that not really matter a whole lot on these precision mounts?

Thanks!
Pete


Re: Losing Communications with the Mount

Ray Gralak
 

Also, the mount stops tracking when communications starts failing.
If it was just a communications failure
between the computer and the mount, wouldn’t the mount continue to track?
When APCC is in use, its Safety Park feature will cause the mount to stop tracking if the mount does not receive regular messages from APCC.

So, that the mount stopped tracking indicates that communication failed in some way.

-Ray


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of alex
Sent: Wednesday, May 5, 2021 3:41 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Losing Communications with the Mount

I had already upped the timeout to 200ms, so I’ll try 400ms. The mount is directly connected to a switch in my
observatory. The only other thing plugged into that switch is my UniFi WiFi access point, which is mounted in
the observatory. My computer (a piggy backed eagle 2) is the only thing using that access point, so
communications is Eagle2 -> AP -> Switch -> Mount. Said switch is backhauled to my house’s main switch,
and the only traffic between the house and the observatory is my Mac connecting to the Eagle2 using Microsoft
Remote Desktop. The Remote Desktop connection to the eagle has been rock solid.

I had pings repeating from my wired Mac in the house, and when the problem happens, the pings start failing
and stay failing until the mount is power cycled, at which point the pings start working again. APCC re-
establishes communications once the mount is power cycled with no other intervention on my part.

Also, the mount stops tracking when communications starts failing. If it was just a communications failure
between the computer and the mount, wouldn’t the mount continue to track?
Communications failed again as I was writing this response. The mount was parked at the time. I had bumped
the timeout to 400ms and switched to UDP before hand. Pings to the mount’s hard wired ethernet IP address
is failing, but curiously I can ping the mount’s WiFi IP address, though if I disconnect from the mount in APCC
and try connecting it via that WiFi address, it still get’s no response from the mount. Again, a few seconds after
power cycling the GTOCP4, everything is working again.

I’ll try snaking a USB cable down from the Eagle 2 to the mount and try that as backup or perhaps the primary.
If that also fails, then I’ll pop open the GTOCP4 and check the daughter board seating.

Alex


Re: Losing Communications with the Mount

 

Hi Alex

in my experience TCP is a more reliable protocol than UDP

i had similar timeout issues, switched to TCP and it was resolved for me

On Wed, May 5, 2021 at 3:40 PM alex <groups@...> wrote:
I had already upped the timeout to 200ms, so I’ll try 400ms.  The mount is directly connected to a switch in my observatory.  The only other thing plugged into that switch is my UniFi WiFi access point, which is mounted in the observatory.  My computer (a piggy backed eagle 2) is the only thing using that access point, so communications is Eagle2 -> AP -> Switch -> Mount.  Said switch is backhauled to my house’s main switch, and the only traffic between the house and the observatory is my Mac connecting to the Eagle2 using Microsoft Remote Desktop. The Remote Desktop connection to the eagle has been rock solid.
 
I had pings repeating from my wired Mac in the house, and when the problem happens, the pings start failing and stay failing until the mount is power cycled, at which point the pings start working again. APCC re-establishes communications once the mount is power cycled with no other intervention on my part.
 
Also, the mount stops tracking when communications starts failing.  If it was just a communications failure between the computer and the mount, wouldn’t the mount continue to track?  When the mount is in this mode, the GTOCP4’s power light is on and the ethernet activity lights continue to flicker.
 
Communications failed again as I was writing this response.  The mount was parked at the time.  I had bumped the timeout to 400ms and switched to UDP before hand.  Pings to the mount’s hard wired ethernet IP address is failing, but curiously I can ping the mount’s WiFi IP address, though if I disconnect from the mount in APCC and try connecting it via that WiFi address, it still get’s no response from the mount.  Again, a few seconds after power cycling the GTOCP4, everything is working again.
 
I’ll try snaking a USB cable down from the Eagle 2 to the mount and try that as backup or perhaps the primary.  If that also fails, then I’ll pop open the GTOCP4 and check the daughter board seating.
 
Alex
 



--
Brian 



Brian Valente


Re: Losing Communications with the Mount

Alex
 

I had already upped the timeout to 200ms, so I’ll try 400ms.  The mount is directly connected to a switch in my observatory.  The only other thing plugged into that switch is my UniFi WiFi access point, which is mounted in the observatory.  My computer (a piggy backed eagle 2) is the only thing using that access point, so communications is Eagle2 -> AP -> Switch -> Mount.  Said switch is backhauled to my house’s main switch, and the only traffic between the house and the observatory is my Mac connecting to the Eagle2 using Microsoft Remote Desktop. The Remote Desktop connection to the eagle has been rock solid.
 
I had pings repeating from my wired Mac in the house, and when the problem happens, the pings start failing and stay failing until the mount is power cycled, at which point the pings start working again. APCC re-establishes communications once the mount is power cycled with no other intervention on my part.
 
Also, the mount stops tracking when communications starts failing.  If it was just a communications failure between the computer and the mount, wouldn’t the mount continue to track?  When the mount is in this mode, the GTOCP4’s power light is on and the ethernet activity lights continue to flicker.
 
Communications failed again as I was writing this response.  The mount was parked at the time.  I had bumped the timeout to 400ms and switched to UDP before hand.  Pings to the mount’s hard wired ethernet IP address is failing, but curiously I can ping the mount’s WiFi IP address, though if I disconnect from the mount in APCC and try connecting it via that WiFi address, it still get’s no response from the mount.  Again, a few seconds after power cycling the GTOCP4, everything is working again.
 
I’ll try snaking a USB cable down from the Eagle 2 to the mount and try that as backup or perhaps the primary.  If that also fails, then I’ll pop open the GTOCP4 and check the daughter board seating.
 
Alex
 


Re: MGBox V2 Driver

Keith Olsen
 

You are correct Brian.  I got a response from Matt at Astromi and he said the ASCOM driver is the same for all MGBox models.   

I did find my problem.  I had somehow downloaded an old version of the MGBox Windows Application so I could not change from Serial to ASCOM connection.  Once I downloaded the correct version I was able to change to an ASCOM connection and all works great now.

FYI, I can have both the MGBox Windows Application running and APCC at the same time with no problem.  I can start either one first it doesn't matter.


Re: Connecting ASIAIR Pro to a CP4 - Mach1

Arvind
 

I have successfully used the CP4 with ASIAIR Pro a few nights in the past, and have gone through polar alignment, GoTo, guiding, etc without any issues.

Use the USB port from ASIAIR Pro <-> CP4.

I don't know if the laptop/iPad makes any difference since the software is eventually running on the raspberry pi. The client software is purely for display.


On Wed, May 5, 2021 at 7:29 AM Lee Decovnick <ursa@...> wrote:
Hi all,

This is my first post, though I’ve been a long time Mach 1 (CP3) owner and I just bought a second used Mach 1 (CP4) for my wife. We shoot astrophotography two weeks a year on the Modoc Plateau, 50 miles east of Mt. Shasta.

The ASI Air Pro mount interfaces is pretty basic, which is fine as she moves up from shooting the Milky Way with a DSLR into using the ASI CMOS cameras.
So far I have had tried Ethernet and USB and Wi-Fi to talk to the ASI Air Pro, nothing.  I can see the GTO WiFi network ,but no handshake with the ASI.  But I loaded the FIDI driver and at 9600 baud, the RS232 serial port does connect, but drops out often.

I’m running the ASIAIR Pro App on a Windows 10 machine ( larger screen) - rather than an iPad - using Blue Stacks emulation..a pretty nifty set up. I do not have APCC loaded on my Window machine, do I need to do so?

Am I aiming for a bridge too far? I’m accustomed to simply shooting  astrophotography just using my hand controller for the GOTO’s and I have no tracking problems with 2-3 minutes subs without PremPro. I polar align in the field with a RAPAS. Easy-peasy.

Suggestions and comments welcome.

Lee
Walnut Creek,Ca





Re: MGBox V2 Driver

 

I am fairly certain it is the same driver and app



On Wed, May 5, 2021 at 11:49 AM Keith Olsen <keitholsen@...> wrote:
Hi Brian thanks for responding,

I see the V2 Firmware but I don't see the V2 ASCOM driver, I only see what appears to be the MGBox Ascom Driver(not V2).  I did download and install it but it does not work with the V2 box.   In the selection box for the driver in APCC it only shows the MGBox driver(not V2) and pressing the Test button shows bad data.

Keith



--
Brian 



Brian Valente


Re: Connecting ASIAIR Pro to a CP4 - Mach1

Kenneth Tan
 

You can testflight the latest asi air pro firmware with phd multi star guiding. Just installed mine. Yet to try it though 🤣

Kenneth

On Thu, 6 May 2021 at 02:03, Kevin Cook <kvc3509@...> wrote:
Hi Lee - I was always "old school" with my Mach 1 (CP3), using the RAPAS to polar align, the hand controller to find targets, and then a variety of software programs to manage the image capture.  Some of us are slow to catch on to new technology, but the ASIAIR Pro is getting me there.  I am successful getting it to talk to the mount, control slews to targets, do the plate solving, etc.  For me, since my mount does not have integral wi-fi, I simply do a wired connection from the mount's RS232 port into one of the ASIAIR's USB's ports.  That has been a reliable connection method for me.  I then have the ASIAIR communicating wirelessly to my Samsung 10-inch Android tablet.  My only real remaining frustration with this setup is with the guiding - the simplified version of PhD on the ASIAIR does not have many means of fine-tuning your guiding, and I am pretty sure I did better using the real PhD2 with a laptop.  But with moderate focal lengths (AP130 f/6 and shorter), the ASIAIR guiding has been good enough.    Kevin (Tucson AZ)


Re: MGBox V2 Driver

Keith Olsen
 

Hi Brian thanks for responding,

I see the V2 Firmware but I don't see the V2 ASCOM driver, I only see what appears to be the MGBox Ascom Driver(not V2).  I did download and install it but it does not work with the V2 box.   In the selection box for the driver in APCC it only shows the MGBox driver(not V2) and pressing the Test button shows bad data.

Keith


Re: Connecting ASIAIR Pro to a CP4 - Mach1

Kenneth Tan
 

Best to use  the usb 2 cable from the gtocp4 to the usb port of the asi air pro. The wifi of the ASI air pro (Rasberrypi4) is weak and directional. They do sell a wifi repeater that works well. 
If you are using the serial to USB converter, this can be rather fussy. Has to be a FTDI chip. 
I use an iPad and it works fine.

Kenneth

On Wed, 5 May 2021 at 22:29, Lee Decovnick <ursa@...> wrote:
Hi all,

This is my first post, though I’ve been a long time Mach 1 (CP3) owner and I just bought a second used Mach 1 (CP4) for my wife. We shoot astrophotography two weeks a year on the Modoc Plateau, 50 miles east of Mt. Shasta.

The ASI Air Pro mount interfaces is pretty basic, which is fine as she moves up from shooting the Milky Way with a DSLR into using the ASI CMOS cameras.
So far I have had tried Ethernet and USB and Wi-Fi to talk to the ASI Air Pro, nothing.  I can see the GTO WiFi network ,but no handshake with the ASI.  But I loaded the FIDI driver and at 9600 baud, the RS232 serial port does connect, but drops out often.

I’m running the ASIAIR Pro App on a Windows 10 machine ( larger screen) - rather than an iPad - using Blue Stacks emulation..a pretty nifty set up. I do not have APCC loaded on my Window machine, do I need to do so?

Am I aiming for a bridge too far? I’m accustomed to simply shooting  astrophotography just using my hand controller for the GOTO’s and I have no tracking problems with 2-3 minutes subs without PremPro. I polar align in the field with a RAPAS. Easy-peasy.

Suggestions and comments welcome.

Lee
Walnut Creek,Ca





Re: MGBox V2 Driver

 

https://www.astromi.ch/downloads/

it's listed on the left

On Wed, May 5, 2021 at 11:36 AM Keith Olsen <keitholsen@...> wrote:
Does anybody know where I can find the driver for the MGBox V2.   Their web site only has the MGBox driver and not the V2 driver.

I tried contacting them and no response yet.

Thanks,

Keith



--
Brian 



Brian Valente


MGBox V2 Driver

Keith Olsen
 

Does anybody know where I can find the driver for the MGBox V2.   Their web site only has the MGBox driver and not the V2 driver.

I tried contacting them and no response yet.

Thanks,

Keith

1481 - 1500 of 79807