Date   

second attempt: meridian management with mach2 please...help

Andrea Lucchetti
 

Hi,
I am trying one more time to stimulate a discussion on the topic.
My previous thread didn't get a single comment so I suspect the manual is not that clear: I though it was my fault but it seems that this is a topic at least not very interesting if not intimidating :-)

I will try to simplify things compared to my previous post:
I have a Mach2 and it is going to be used in the field, no fixed set up.

I'd like to know what is the simplest meridian management  set up to be used with APCC Pro and the Mach2.
I don't need any complex management, only things like:
-to allow for 45 min tracking in the west before meridian flip, about 45 min east tracking (less important) 
-prevent slewing near the meridian

After having read many, many times the manual, I am still confused 
I wonder if setting only the AE limits it is enough for me . in this case it would be nice to know how to set the "Meridian panel" in APCC:

I assume I don't need to set "meridian delay"
I assume I don't have to touch the "meridian tracking limits/hour angle panel"
I assume I don't need to flag "enable Meridian Tracking limits" in "Operation" panel, because in the help I read: "DO NOT use any other method for setting a meridian delay while you are using the meridian limits.  When properly configured, the APCC meridian tracking limit logic will maintain the correct meridian delay in the system."
 


Thank you very much in advance,
Andrea
 


Re: 2021 production plans for the 1600GTO?

jose.mtanous
 

Good to hear that! Perfect timing to start saving!

Cheers,

José


locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Bill Long
 

I do know it "has recovery" but its not good enough. Its not reliable enough for people to depend on. Smart development teams write and code around those things, which is likely what A-P is doing to ensure that USB upgrades work properly. To assume otherwise shows your lack of Enterprise production development experience nd/or your ignorance to SRE principles which literally bleed out in Silicon Valley. Maybe go take a bath in town and go learn something more than lines of code.

I am not some shmuck and you should stop acting like I am. I have made some of the software you likely use, or others you do business with use, to ensure they have the best experience possible. I have used NINA and I think its a good piece of software I hope you folks work on with vigor. Don't get high on the dragon though and come into discussions like this with an assumption of the high ground. Real world applications trump your paper logic. 

I am glad A-P understands that and is working on real solutions and not just from paper specs and BS.


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
Sent: Tuesday, November 24, 2020 12:28 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
 


> On Nov 24, 2020, at 2:44 PM, Bill Long <bill@...> wrote:
>
> One more thing...
>
> "What you're doing is taking a single example of a particular device's bad or faulty implementation of a USB protocol and holding it up as if it were a problem with the protocol design itself."
>
> No, what I saying is that you cannot have a production environment be assumed to be clean of such actors. If they exist and can influence the environment in they way I suggested, that puts you in a compromised situation for updating critical components like firmware. Vectors are my point here, not the minutia of the protocol.

And such devices are replaced or repaired and life carries on. So what's the problem? It's the year 2020, not 2002. USB implementation is a well-known and well-learned practice among component manufacturers and such problems are very much the exception, not the rule. Certainly nothing to get all bent out of shape over the mere mention of USB on mailing list. And if a faulty device does happen? The world doesn't come crashing down; it's replaced. In the end, don't buy junk.

I cannot tell you how many times I've encountered people who complain about failed downloads from their ZWO camera when they're using that god awful flat USB cable that ZWO has chosen to include with their cameras. I cannot recall one instance where them replacing that cable with a quality one didn't fix their issue. The decision by ZWO to include this design was bad, to put it lightly, because it is a design that completely omits the RFI rejection qualities of a properly constructed cable. Was this the fault of USB itself? No. It was the fault of a vendor who either did not adequately test or appreciate the problems posed by the design they chose. These are the kinds of "problems with USB" that the typical person is going to encounter.

> This goes for PCI(e), ethernet, SAS, SPI, i2c - you name it, it requires it.
>
> Sure, but at least you have handshaking and retry logic in the TCP/IP stack (v4 or v6). You dont have that same level of session rety logic in USB at all. Thats my point. Lossy tech that is known to be faulty and easy to break is not something to build realiability on. Period.

I'm surprised you don't know this, but USB does have an error detection and recovery component to its protocol, and always has. This topic is covered in some detail by one Washington-based developer of a popular operating system, among other things:

https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-hardware%2Fdrivers%2Fusbcon%2Fhow-to-recover-from-usb-pipe-errors&amp;data=04%7C01%7C%7C6dc4a78d7d4b4964518c08d890b787aa%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637418465207838323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Sf4Zrs6snxKO4hF5N7htZLF560wqnTPU6lUXUIL07EQ%3D&amp;reserved=0

and, specifically on the topics of STALL and CLEAR signaling:

https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fmicrosoft-usb-blog%2Fhow-to-recover-from-usb-errors-part-1%2Fba-p%2F270707&amp;data=04%7C01%7C%7C6dc4a78d7d4b4964518c08d890b787aa%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637418465207848320%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=y3OwlgBarlmXu02dnVtvu17%2BYmfeOomAeI%2FnW9pryaE%3D&amp;reserved=0

As you might gather from the progression of the remediation steps, things get more drastic if the previous steps fail to return the session to a stable state. This is like TCP, which you pointed out, which has a retry process as part of its design (handshaking is not relevant to error recovery in TCP; it exists only to set up a session between two endpoints.) Failed retries eventually progress to harsher error states, culminating in the forced termination of the connection. Isochronous USB transfers would be analogous to UDP; which is why both are preferred for time-domain sensitive applications that cannot withstand the very expensive recovery methods that TCP imposes for missing or out of order packets (and out of order packets is not something that should never be encountered on a USB bus anyhow.)

The point is, USB is not "lossy". It is a stateful protocol, and like any stateful protocol it tries its best to deliver the data it is tasked with carrying.

/dale








locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Dale Ghent
 

On Nov 24, 2020, at 2:44 PM, Bill Long <bill@outlook.com> wrote:

One more thing...

"What you're doing is taking a single example of a particular device's bad or faulty implementation of a USB protocol and holding it up as if it were a problem with the protocol design itself."

No, what I saying is that you cannot have a production environment be assumed to be clean of such actors. If they exist and can influence the environment in they way I suggested, that puts you in a compromised situation for updating critical components like firmware. Vectors are my point here, not the minutia of the protocol.
And such devices are replaced or repaired and life carries on. So what's the problem? It's the year 2020, not 2002. USB implementation is a well-known and well-learned practice among component manufacturers and such problems are very much the exception, not the rule. Certainly nothing to get all bent out of shape over the mere mention of USB on mailing list. And if a faulty device does happen? The world doesn't come crashing down; it's replaced. In the end, don't buy junk.

I cannot tell you how many times I've encountered people who complain about failed downloads from their ZWO camera when they're using that god awful flat USB cable that ZWO has chosen to include with their cameras. I cannot recall one instance where them replacing that cable with a quality one didn't fix their issue. The decision by ZWO to include this design was bad, to put it lightly, because it is a design that completely omits the RFI rejection qualities of a properly constructed cable. Was this the fault of USB itself? No. It was the fault of a vendor who either did not adequately test or appreciate the problems posed by the design they chose. These are the kinds of "problems with USB" that the typical person is going to encounter.

This goes for PCI(e), ethernet, SAS, SPI, i2c - you name it, it requires it.

Sure, but at least you have handshaking and retry logic in the TCP/IP stack (v4 or v6). You dont have that same level of session rety logic in USB at all. Thats my point. Lossy tech that is known to be faulty and easy to break is not something to build realiability on. Period.
I'm surprised you don't know this, but USB does have an error detection and recovery component to its protocol, and always has. This topic is covered in some detail by one Washington-based developer of a popular operating system, among other things:

https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/how-to-recover-from-usb-pipe-errors

and, specifically on the topics of STALL and CLEAR signaling:

https://techcommunity.microsoft.com/t5/microsoft-usb-blog/how-to-recover-from-usb-errors-part-1/ba-p/270707

As you might gather from the progression of the remediation steps, things get more drastic if the previous steps fail to return the session to a stable state. This is like TCP, which you pointed out, which has a retry process as part of its design (handshaking is not relevant to error recovery in TCP; it exists only to set up a session between two endpoints.) Failed retries eventually progress to harsher error states, culminating in the forced termination of the connection. Isochronous USB transfers would be analogous to UDP; which is why both are preferred for time-domain sensitive applications that cannot withstand the very expensive recovery methods that TCP imposes for missing or out of order packets (and out of order packets is not something that should never be encountered on a USB bus anyhow.)

The point is, USB is not "lossy". It is a stateful protocol, and like any stateful protocol it tries its best to deliver the data it is tasked with carrying.

/dale


locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Bill Long
 

One more thing...

"What you're doing is taking a single example of a particular device's bad or faulty implementation of a USB protocol and holding it up as if it were a problem with the protocol design itself."

No, what I saying is that you cannot have a production environment be assumed to be clean of such actors. If they exist and can influence the environment in they way I suggested, that puts you in a compromised situation for updating critical components like firmware. Vectors are my point here, not the minutia of the protocol.

This goes for PCI(e), ethernet, SAS, SPI, i2c - you name it, it requires it. 

Sure, but at least you have handshaking and retry logic in the TCP/IP stack (v4 or v6). You dont have that same level of session rety logic in USB at all. Thats my point. Lossy tech that is known to be faulty and easy to break is not something to build realiability on. Period. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Bill Long <bill@...>
Sent: Tuesday, November 24, 2020 11:37 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
 
Test it as I suggested. You'll see what I mean. Thanks for the diatribe about the protocol though. We can talk about NTLM and Kerb next if you would like and how what is on paper is not how it works in the real world. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
Sent: Tuesday, November 24, 2020 11:33 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
 

You don't seem to want to go into any detail other than referencing some vague notion.  USB2 devices are no different than any other in this area. Devices with bad-actor USB logic are going to cause the issues just like a bad-actor device on any kind of bus is going to cause, including ethernet, and I certainly have some camp fire stories from there.

What you're doing is taking a single example of a particular device's bad or faulty implementation of a USB protocol and holding it up as if it were a problem with the protocol design itself. At the least, this is a misunderstanding. Any bus technology is reliant upon its constituent devices operating within the defined electrical and protocol specifications that define its standards in order to maintain a stable environment. This goes for PCI(e), ethernet, SAS, SPI, i2c - you name it, it requires it. Some bus designs do provide either electrical or protocol-based isolation of such faulty components, but these methods are not really common in practice and have other consequences which are often undesirable.


> On Nov 24, 2020, at 2:18 PM, Bill Long <bill@...> wrote:
>
> The reset event can cause issues with connected devices that are USB2 protocol. You are talking about ideal situations, real world situations on the bus are different. You can test this yourself. Write a bad actor driver that issues constant resets and see what happens.
>
> Dont ask me how I know this though. 😉
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
> Sent: Tuesday, November 24, 2020 11:09 AM
> To: main@ap-gto.groups.io <main@ap-gto.groups.io>
> Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
>
>
> I think you've misunderstand what "USB bus reset" signaling is. Bus resets happen only between the host and a device. Other devices on the same controller are not a party to such an event. Bus resets are normal components of USB host->device signaling and signal the device to enter a quiescent state. These events are largely abstracted away and masked by higher levels of any modern USB stack, and are not bad things.
>
> In my experience, USB problems are almost always the result of poor cabling quality, noisy operating environments (which poor cabling will exacerbate), or mechanical failure of a connector. Overburdening of bus power can also present itself as a "USB problem" in the case where a user connects too many devices that draw more power than the bus can provide. This is why the recommendation for quality powered hubs, versus unpowered hub, is always made.
>
>
> > On Nov 24, 2020, at 1:49 PM, Bill Long <bill@...> wrote:
> >
> > It takes one bus reset call from a connected device to cause problems. You know this.
> >
> > From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
> > Sent: Tuesday, November 24, 2020 10:45 AM
> > To: main@ap-gto.groups.io <main@ap-gto.groups.io>
> > Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
> >
> >
> > I've had no problems with USB that can't be traced to a bad or poorly-designed cable. USB is fine so long as you know its limits.
> >
> > > On Nov 24, 2020, at 12:56 PM, Bill Long <bill@...> wrote:
> > >
> > > If they want to update the mount, they will either need serial ports on the machine (not likely) or ethernet. USB is not recommended for reasons I am sure you know as a developer.
> > >
> > > USB to ethernet adapters are not advised for the same reason USB connections themselves are not advised to update the mount as needed. So while your solutions here solve the usage short-term, the better advise to the user is to have more of a long term solution to the problem at hand.
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>







locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Bill Long
 

Test it as I suggested. You'll see what I mean. Thanks for the diatribe about the protocol though. We can talk about NTLM and Kerb next if you would like and how what is on paper is not how it works in the real world. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
Sent: Tuesday, November 24, 2020 11:33 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
 

You don't seem to want to go into any detail other than referencing some vague notion.  USB2 devices are no different than any other in this area. Devices with bad-actor USB logic are going to cause the issues just like a bad-actor device on any kind of bus is going to cause, including ethernet, and I certainly have some camp fire stories from there.

What you're doing is taking a single example of a particular device's bad or faulty implementation of a USB protocol and holding it up as if it were a problem with the protocol design itself. At the least, this is a misunderstanding. Any bus technology is reliant upon its constituent devices operating within the defined electrical and protocol specifications that define its standards in order to maintain a stable environment. This goes for PCI(e), ethernet, SAS, SPI, i2c - you name it, it requires it. Some bus designs do provide either electrical or protocol-based isolation of such faulty components, but these methods are not really common in practice and have other consequences which are often undesirable.


> On Nov 24, 2020, at 2:18 PM, Bill Long <bill@...> wrote:
>
> The reset event can cause issues with connected devices that are USB2 protocol. You are talking about ideal situations, real world situations on the bus are different. You can test this yourself. Write a bad actor driver that issues constant resets and see what happens.
>
> Dont ask me how I know this though. 😉
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
> Sent: Tuesday, November 24, 2020 11:09 AM
> To: main@ap-gto.groups.io <main@ap-gto.groups.io>
> Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
>
>
> I think you've misunderstand what "USB bus reset" signaling is. Bus resets happen only between the host and a device. Other devices on the same controller are not a party to such an event. Bus resets are normal components of USB host->device signaling and signal the device to enter a quiescent state. These events are largely abstracted away and masked by higher levels of any modern USB stack, and are not bad things.
>
> In my experience, USB problems are almost always the result of poor cabling quality, noisy operating environments (which poor cabling will exacerbate), or mechanical failure of a connector. Overburdening of bus power can also present itself as a "USB problem" in the case where a user connects too many devices that draw more power than the bus can provide. This is why the recommendation for quality powered hubs, versus unpowered hub, is always made.
>
>
> > On Nov 24, 2020, at 1:49 PM, Bill Long <bill@...> wrote:
> >
> > It takes one bus reset call from a connected device to cause problems. You know this.
> >
> > From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
> > Sent: Tuesday, November 24, 2020 10:45 AM
> > To: main@ap-gto.groups.io <main@ap-gto.groups.io>
> > Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
> >
> >
> > I've had no problems with USB that can't be traced to a bad or poorly-designed cable. USB is fine so long as you know its limits.
> >
> > > On Nov 24, 2020, at 12:56 PM, Bill Long <bill@...> wrote:
> > >
> > > If they want to update the mount, they will either need serial ports on the machine (not likely) or ethernet. USB is not recommended for reasons I am sure you know as a developer.
> > >
> > > USB to ethernet adapters are not advised for the same reason USB connections themselves are not advised to update the mount as needed. So while your solutions here solve the usage short-term, the better advise to the user is to have more of a long term solution to the problem at hand.
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>







locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Dale Ghent
 

You don't seem to want to go into any detail other than referencing some vague notion. USB2 devices are no different than any other in this area. Devices with bad-actor USB logic are going to cause the issues just like a bad-actor device on any kind of bus is going to cause, including ethernet, and I certainly have some camp fire stories from there.

What you're doing is taking a single example of a particular device's bad or faulty implementation of a USB protocol and holding it up as if it were a problem with the protocol design itself. At the least, this is a misunderstanding. Any bus technology is reliant upon its constituent devices operating within the defined electrical and protocol specifications that define its standards in order to maintain a stable environment. This goes for PCI(e), ethernet, SAS, SPI, i2c - you name it, it requires it. Some bus designs do provide either electrical or protocol-based isolation of such faulty components, but these methods are not really common in practice and have other consequences which are often undesirable.

On Nov 24, 2020, at 2:18 PM, Bill Long <bill@outlook.com> wrote:

The reset event can cause issues with connected devices that are USB2 protocol. You are talking about ideal situations, real world situations on the bus are different. You can test this yourself. Write a bad actor driver that issues constant resets and see what happens.

Dont ask me how I know this though. 😉

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@elemental.org>
Sent: Tuesday, November 24, 2020 11:09 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO


I think you've misunderstand what "USB bus reset" signaling is. Bus resets happen only between the host and a device. Other devices on the same controller are not a party to such an event. Bus resets are normal components of USB host->device signaling and signal the device to enter a quiescent state. These events are largely abstracted away and masked by higher levels of any modern USB stack, and are not bad things.

In my experience, USB problems are almost always the result of poor cabling quality, noisy operating environments (which poor cabling will exacerbate), or mechanical failure of a connector. Overburdening of bus power can also present itself as a "USB problem" in the case where a user connects too many devices that draw more power than the bus can provide. This is why the recommendation for quality powered hubs, versus unpowered hub, is always made.


On Nov 24, 2020, at 1:49 PM, Bill Long <bill@outlook.com> wrote:

It takes one bus reset call from a connected device to cause problems. You know this.

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@elemental.org>
Sent: Tuesday, November 24, 2020 10:45 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO


I've had no problems with USB that can't be traced to a bad or poorly-designed cable. USB is fine so long as you know its limits.

On Nov 24, 2020, at 12:56 PM, Bill Long <bill@outlook.com> wrote:

If they want to update the mount, they will either need serial ports on the machine (not likely) or ethernet. USB is not recommended for reasons I am sure you know as a developer.

USB to ethernet adapters are not advised for the same reason USB connections themselves are not advised to update the mount as needed. So while your solutions here solve the usage short-term, the better advise to the user is to have more of a long term solution to the problem at hand.













locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Bill Long
 

The reset event can cause issues with connected devices that are USB2 protocol. You are talking about ideal situations, real world situations on the bus are different. You can test this yourself. Write a bad actor driver that issues constant resets and see what happens. 

Dont ask me how I know this though. 😉 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
Sent: Tuesday, November 24, 2020 11:09 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
 

I think you've misunderstand what "USB bus reset" signaling is. Bus resets happen only between the host and a device. Other devices on the same controller are not a party to such an event. Bus resets are normal components of USB host->device signaling and signal the device to enter a quiescent state. These events are largely abstracted away and masked by higher levels of any modern USB stack, and are not bad things.

In my experience, USB problems are almost always the result of poor cabling quality, noisy operating environments (which poor cabling will exacerbate), or mechanical failure of a connector. Overburdening of bus power can also present itself as a "USB problem" in the case where a user connects too many devices that draw more power than the bus can provide. This is why the recommendation for quality powered hubs, versus unpowered hub, is always made.


> On Nov 24, 2020, at 1:49 PM, Bill Long <bill@...> wrote:
>
> It takes one bus reset call from a connected device to cause problems. You know this.
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
> Sent: Tuesday, November 24, 2020 10:45 AM
> To: main@ap-gto.groups.io <main@ap-gto.groups.io>
> Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
>
>
> I've had no problems with USB that can't be traced to a bad or poorly-designed cable. USB is fine so long as you know its limits.
>
> > On Nov 24, 2020, at 12:56 PM, Bill Long <bill@...> wrote:
> >
> > If they want to update the mount, they will either need serial ports on the machine (not likely) or ethernet. USB is not recommended for reasons I am sure you know as a developer.
> >
> > USB to ethernet adapters are not advised for the same reason USB connections themselves are not advised to update the mount as needed. So while your solutions here solve the usage short-term, the better advise to the user is to have more of a long term solution to the problem at hand.
>
>
>
>
>
>
>
>
>







locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Dale Ghent
 

I think you've misunderstand what "USB bus reset" signaling is. Bus resets happen only between the host and a device. Other devices on the same controller are not a party to such an event. Bus resets are normal components of USB host->device signaling and signal the device to enter a quiescent state. These events are largely abstracted away and masked by higher levels of any modern USB stack, and are not bad things.

In my experience, USB problems are almost always the result of poor cabling quality, noisy operating environments (which poor cabling will exacerbate), or mechanical failure of a connector. Overburdening of bus power can also present itself as a "USB problem" in the case where a user connects too many devices that draw more power than the bus can provide. This is why the recommendation for quality powered hubs, versus unpowered hub, is always made.

On Nov 24, 2020, at 1:49 PM, Bill Long <bill@outlook.com> wrote:

It takes one bus reset call from a connected device to cause problems. You know this.

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@elemental.org>
Sent: Tuesday, November 24, 2020 10:45 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO


I've had no problems with USB that can't be traced to a bad or poorly-designed cable. USB is fine so long as you know its limits.

On Nov 24, 2020, at 12:56 PM, Bill Long <bill@outlook.com> wrote:

If they want to update the mount, they will either need serial ports on the machine (not likely) or ethernet. USB is not recommended for reasons I am sure you know as a developer.

USB to ethernet adapters are not advised for the same reason USB connections themselves are not advised to update the mount as needed. So while your solutions here solve the usage short-term, the better advise to the user is to have more of a long term solution to the problem at hand.








locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Bill Long
 

It takes one bus reset call from a connected device to cause problems. You know this. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
Sent: Tuesday, November 24, 2020 10:45 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
 

I've had no problems with USB that can't be traced to a bad or poorly-designed cable. USB is fine so long as you know its limits.

> On Nov 24, 2020, at 12:56 PM, Bill Long <bill@...> wrote:
>
> If they want to update the mount, they will either need serial ports on the machine (not likely) or ethernet. USB is not recommended for reasons I am sure you know as a developer.
>
> USB to ethernet adapters are not advised for the same reason USB connections themselves are not advised to update the mount as needed. So while your solutions here solve the usage short-term, the better advise to the user is to have more of a long term solution to the problem at hand.









locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Dale Ghent
 

I've had no problems with USB that can't be traced to a bad or poorly-designed cable. USB is fine so long as you know its limits.

On Nov 24, 2020, at 12:56 PM, Bill Long <bill@outlook.com> wrote:

If they want to update the mount, they will either need serial ports on the machine (not likely) or ethernet. USB is not recommended for reasons I am sure you know as a developer.

USB to ethernet adapters are not advised for the same reason USB connections themselves are not advised to update the mount as needed. So while your solutions here solve the usage short-term, the better advise to the user is to have more of a long term solution to the problem at hand.


locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Bill Long
 

That would be great. Lots of error correction checking required. USB is flaky. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Roland Christen via groups.io <chris1011@...>
Sent: Tuesday, November 24, 2020 10:28 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
 
We are working on a utility that will allow updating the mount via USB. Available shortly. Our software engineer demonstrated it last night.

Rolando



-----Original Message-----
From: Bill Long <bill@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Tue, Nov 24, 2020 11:56 am
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

If they want to update the mount, they will either need serial ports on the machine (not likely) or ethernet. USB is not recommended for reasons I am sure you know as a developer. 

USB to ethernet adapters are not advised for the same reason USB connections themselves are not advised to update the mount as needed. So while your solutions here solve the usage short-term, the better advise to the user is to have more of a long term solution to the problem at hand.


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
Sent: Tuesday, November 24, 2020 9:02 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
 


> On Nov 24, 2020, at 11:31 AM, Harold <hfm5022@...> wrote:
>
> My six year old HP laptop is beginning to have some reliability problems, in researching a replacement I noticed most laptops do not include an Ethernet port. Should I restrict my purchases to only models with Ethernet or are there other ways to resolve the issue?

Lack of a built-in ethernet interface should not constrain your search for a new laptop. You can still connect to a CP4/CP5 wirelessly or over USB. If you wish to continue using hardwire ethernet on a laptop that lacks its own built-in interface, you can get a cheap and effective USB to ethernet adapter.

Example:
https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amazon.com%2Fdp%2FB00YUU3KC6%2F&amp;data=04%7C01%7C%7Ccfff6926cd5a4752ea2908d8909acea6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637418341847357446%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bj9cv9FWavPqkask16gePExbH3E8%2BMUZMV5WQ2hrunQ%3D&amp;reserved=0

/dale





--
Roland Christen
Astro-Physics


locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Roland Christen
 

We are working on a utility that will allow updating the mount via USB. Available shortly. Our software engineer demonstrated it last night.

Rolando



-----Original Message-----
From: Bill Long <bill@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Tue, Nov 24, 2020 11:56 am
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

If they want to update the mount, they will either need serial ports on the machine (not likely) or ethernet. USB is not recommended for reasons I am sure you know as a developer. 

USB to ethernet adapters are not advised for the same reason USB connections themselves are not advised to update the mount as needed. So while your solutions here solve the usage short-term, the better advise to the user is to have more of a long term solution to the problem at hand.


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
Sent: Tuesday, November 24, 2020 9:02 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
 


> On Nov 24, 2020, at 11:31 AM, Harold <hfm5022@...> wrote:
>
> My six year old HP laptop is beginning to have some reliability problems, in researching a replacement I noticed most laptops do not include an Ethernet port. Should I restrict my purchases to only models with Ethernet or are there other ways to resolve the issue?

Lack of a built-in ethernet interface should not constrain your search for a new laptop. You can still connect to a CP4/CP5 wirelessly or over USB. If you wish to continue using hardwire ethernet on a laptop that lacks its own built-in interface, you can get a cheap and effective USB to ethernet adapter.

Example:
https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amazon.com%2Fdp%2FB00YUU3KC6%2F&amp;data=04%7C01%7C%7Ccfff6926cd5a4752ea2908d8909acea6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637418341847357446%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bj9cv9FWavPqkask16gePExbH3E8%2BMUZMV5WQ2hrunQ%3D&amp;reserved=0

/dale





--
Roland Christen
Astro-Physics


locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Bill Long
 

If they want to update the mount, they will either need serial ports on the machine (not likely) or ethernet. USB is not recommended for reasons I am sure you know as a developer. 

USB to ethernet adapters are not advised for the same reason USB connections themselves are not advised to update the mount as needed. So while your solutions here solve the usage short-term, the better advise to the user is to have more of a long term solution to the problem at hand.


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Dale Ghent <daleg@...>
Sent: Tuesday, November 24, 2020 9:02 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO
 


> On Nov 24, 2020, at 11:31 AM, Harold <hfm5022@...> wrote:
>
> My six year old HP laptop is beginning to have some reliability problems, in researching a replacement I noticed most laptops do not include an Ethernet port. Should I restrict my purchases to only models with Ethernet or are there other ways to resolve the issue?

Lack of a built-in ethernet interface should not constrain your search for a new laptop. You can still connect to a CP4/CP5 wirelessly or over USB. If you wish to continue using hardwire ethernet on a laptop that lacks its own built-in interface, you can get a cheap and effective USB to ethernet adapter.

Example:
https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amazon.com%2Fdp%2FB00YUU3KC6%2F&amp;data=04%7C01%7C%7Ccfff6926cd5a4752ea2908d8909acea6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637418341847357446%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bj9cv9FWavPqkask16gePExbH3E8%2BMUZMV5WQ2hrunQ%3D&amp;reserved=0

/dale





Re: 2021 production plans for the 1600GTO?

Roland Christen
 

Yes, we plan to make a new run of 1600 mounts next year.

Rolando



-----Original Message-----
From: jose.mtanous <jmtanous@...>
To: main@ap-gto.groups.io
Sent: Tue, Nov 24, 2020 11:04 am
Subject: [ap-gto] 2021 production plans for the 1600GTO?

Hi,

Next year I am planning to get a 150+ lbs class mount, my first option is a 1600GTO.

Are there any plans to produce a new 1600GTO batch in 2021?

Regards,

José

--
Roland Christen
Astro-Physics


2021 production plans for the 1600GTO?

jose.mtanous
 

Hi,

Next year I am planning to get a 150+ lbs class mount, my first option is a 1600GTO.

Are there any plans to produce a new 1600GTO batch in 2021?

Regards,

José


locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Dale Ghent
 

On Nov 24, 2020, at 11:31 AM, Harold <hfm5022@gmail.com> wrote:

My six year old HP laptop is beginning to have some reliability problems, in researching a replacement I noticed most laptops do not include an Ethernet port. Should I restrict my purchases to only models with Ethernet or are there other ways to resolve the issue?
Lack of a built-in ethernet interface should not constrain your search for a new laptop. You can still connect to a CP4/CP5 wirelessly or over USB. If you wish to continue using hardwire ethernet on a laptop that lacks its own built-in interface, you can get a cheap and effective USB to ethernet adapter.

Example:
https://www.amazon.com/dp/B00YUU3KC6/

/dale


locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Roland Christen
 

Ethernet is not required for full mount control. The mount will accept all commands from various external programs with just a USB connection.

Rolando



-----Original Message-----
From: Harold <hfm5022@...>
To: main@ap-gto.groups.io
Sent: Tue, Nov 24, 2020 10:31 am
Subject: Re: [ap-gto] Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

My six year old HP laptop is beginning to have some reliability problems, in researching a replacement I noticed most laptops do not include an Ethernet port. Should I restrict my purchases to only models with Ethernet or are there other ways to resolve the issue?

--
Roland Christen
Astro-Physics


locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Pete Mumbower
 

I am assuming you have WIFI still working. If so, just plug the mount Ethernet port into any of the WiFi router's available Ethernet ports and then the mount and laptop should be on the same network.


locked Re: Mach2GTO Update GTOCP5 – Version P02-07 #Mach2GTO

Harold
 

My six year old HP laptop is beginning to have some reliability problems, in researching a replacement I noticed most laptops do not include an Ethernet port. Should I restrict my purchases to only models with Ethernet or are there other ways to resolve the issue?

5461 - 5480 of 79807