|
Re: 1100AE -- first time with APCC/APPM.
Hi Arvind
It may be related to your beelink trying to connect with both wifi and ethernet at the same time. You have to change a few settings in order for that to work and not 'hang up' (i.e., what's really going on is it may be connected via wifi and block ethernet port). Not sure if you ever connected your Beelink to another network but that could gum it up. If you never use the Beelink wifi you could also disable wifi on the beelink to avoid it completely
On Sun, Nov 27, 2022 at 5:05 PM Arvind < base16@...> wrote: Thanks for that pointer, Brian. I'll look into this 'Create Virtual Ports first' checkbox next time. I don't recall if I had that one selected on the Setup screen. You're right -- I have APCC & the driver all setup with IP & REST API, so I just want to silence the Virtual Ports related alerts. This is a very minor issue, all things considered, but I will be happy to see this go away.. so I'm going to check it out next time around :-)
On the topic of Beelink - the randomness in being able to remote-in so far has been limited to situations when I have the PC setup out in the backyard without a monitor, keyboard, and mouse. I can remote in using RDP in the order of 50% of the time (ie, statistically random) without an attached monitor. Once logged in (with or without a monitor), everything after that point is trouble-free with the Beelink.
My setup:
The 5v USB-powered router [1] is connected to Jackery's USB port (or sometimes Pegasus' USB ports) and is powered up first. The mini PC [2] is powered by the Pegasus (and sometimes directly to Jackery 110v power plug) and is connected using a wired ethernet cable into a LAN port on the router. The router has a static IP assigned to the mini PC, and the PC correctly obtains this using DHCP. My iPhone/iPad/MacBook/Windows Laptop connects over WiFi to the same router.
Upon powering up the mini PC I'm able to see it show up on the router's 'CLIENTS' page as a wired connection with the expected IP address assigned to it. Meaning it should be reachable (note to self.. next time I'll do a ping test at this point). When I open up "RD Client" app from iPhone/iPad or the "Microsoft Remote Desktop" app from Macbook, at this point, I sometimes get through and sometimes get an error while initiating a RDP connection to the mini PC. The error code I remember getting last night was "0x204" from the RDP. The reason I'm looking at Beelink vs Mele right now is I wonder if Beelink gets "stuck" during bootup depending on the kind of peripherals attached to it and sometimes decides it should require a monitor before completing the bootup (?? not entirely sure.. and hard to debug because the moment I attach a monitor the problem consistently goes away). Another thing to test for myself for next time around: perhaps I should do wireless from mini PC into the travel router and remove the cat5e cable.
[1] GL.iNet GL-MT1300 (Beryl) VPN Wireless Little Travel Router
On Sun, Nov 27, 2022 at 3:50 PM Brian Valente < bvalente@...> wrote: PS
Sorry i should have clarified:
assuming you are using REST API and not virtual ports, and you want the virtual ports to "go away" forever, you can disable the 'create virtual ports first' checkbox on the Setup tab
Hi Arvind
>>> Except for the part where it keeps trying to do something with virtual ports upon start up even though I have selected "None"
make sure to disable 'create virtual ports' on the main screen
>>>I have a Windows laptop (that I'd purchased solely for the purpose of astronomy) so last night I installed everything on it (ascom, v2 driver, apcc, ..) so in case my Beelink gave me issues one more time I figured I'll at least use the laptop instead of giving up for the night.
What issues are you having with the Beelink? if it's connectivity, are you trying to use it with both ethernet (perhaps to the mount) and wifi (perhaps RD app)?
On Sun, Nov 27, 2022 at 3:39 PM Arvind < base16@...> wrote: NOT SPECIFIC TO A-P: --------------------------------
My only interaction with MS Windows is from astronomy in the last 1½ years or so. As such, this first section of the email might not resonate with many people so you may choose to skip to the next A-P specific section. After days of frustration with MS Windows remote desktop issues, I managed to get things working long enough to try modeling on 1100ae last night. Even last night, I was able to connect alright twice, but twice I couldn't. Reliability score for this mini-PC mess is close to zero for me.
Picture of the source of frustration (Pegasus ultimate, beelink 12v PC running MS Windows 10, wireless router -- with its bright white light covered up). The Pegasus is powered by jackery car plug 12v 10a source, and the Pegusus in turn powers both the mini PC & the wireless router. Mount is connected to the router over wired ethernet from CP4; no USB from CP4. Power for the mount comes from a dedicated battery. Skipping over the imaging train details as they're not relevant.
I have a Windows laptop (that I'd purchased solely for the purpose of astronomy) so last night I installed everything on it (ascom, v2 driver, apcc, ..) so in case my Beelink gave me issues one more time I figured I'll at least use the laptop instead of giving up for the night.
I'm about to try the Mele mini PC to rule out any hidden bios level issues from the Beelink.. it's possible that Beelink, or perhaps the one I have, is what's causing the unreliable access issues.
A-P specific section: -----------------------------
I've been testing APCC indoors for a few days now. The software is very well documented so after some very minimal trial and error I got the driver talking to APCC using rest API, and APCC talking to the mount using IP address, avoiding virtual or real serial ports.
The APCC UI is extremely busy but I am hoping I don't need to touch it again now that I have it working. Except for the part where it keeps trying to do something with virtual ports upon start up even though I have selected "None" in all the dropdowns under the "Virtual Ports Management" section in APCC, clicked "Delete All" and also did the "Delete Residual Virtual Ports". Beyond being annoying the virtual port related alerts on startup don't appear to prevent normal operation of APCC since I'm using REST API, so I'll leave APCC as-is for now. The recent video from Brian helped me configure the REST API option in APCC -- so thank you for that video, Brian!
The APPM interface is much more streamlined and intuitive, I suppose it's much newer than APCC app. The only source of improvement, if not already possible, is in APPM -> "Plate Solve Settings". The X & Y arc-sec/pixel could be calculated by asking for focal length and aperture (or f-ratio) of the OTA. Combined with acquiring the pixel size from the camera driver, it should be possible to fill that cell with reasonable default values. Note that APPM already connects to the camera driver in the "Run" tab, so the pixel size info should be obtainable already. This is such a small change, but likely helps users prevent a source of user error so figured I'll mention it here. Right now, in my case, it had "1" in both those cells, and I had to change them to "2.3" arc-sec/pixel.
In terms of actual workflow, similar to my GM1000, I did not polar-align the mount beyond eyeballing the RA axis to have it roughly pointing to Polaris. I then built a 18pt custom model just to test the waters. For those who are familiar with MW4 app for 10u, the experience should be similar.. select points, then for each point, slew scope, settle, acquire image, platesolve, and calculate error (and show it on the screen). Finally after all the points have been mapped, it prompts you if you want to add this model to APCC; whereas with 10u you send it to the mount computer directly.
Very pleased with the overall workflow for building the model with APCC+APPM.
I took a few unguided test shots at Tadpole Nebula at 2-, 3-min subs and noticed perfectly round stars when I opened up Nina's "Aberration Inspector" tool to look at the centers & corners on the image. Note that the imaging train is my 2400MC & fsq106 at f/5, so not the most demanding but my goal was not to stress test the tracking accuracy (that's a given, with A-P mounts).
I then powered up PHD2, went through the wizard to add the mount, specified it has encoders, and calibrated and guided with 3sec exposures. The guiding was comparable to what I get without modeling but with just polar-alignment (.3-.5 RMS) but note that this is only 18pt all sky model so I wasn't expecting anything better. Next time around I might test out 50 or 80pt just to see if/how that improves in my seeing conditions.
Overall pleased with everything expect for the MS Windows based frustration. I'd most likely continue some more experiments in my backyard, especially with the newer Mele mini PC instead of the Beelink. This mount proves to be the best of both worlds -- best guided performance, and a way to go unguided if one wants to do so. TBD how the first-light would go for a truly portable setup (away from home..) --- will post once I get a chance to do that one of these days.
--
--
|
|
|
Re: 1100AE -- first time with APCC/APPM.
You might try changing windows machine to a static IP (in place of DHCP) and creating an RDP client to point to that IP address
Ethernet cable is better
I have a NUC but use to have similar issues until I did that. I still have a touch screen monitor in the car just in case as all my imaging is portable
On Mon, 28 Nov 2022 at 12:05 pm, Arvind < base16@...> wrote: Thanks for that pointer, Brian. I'll look into this 'Create Virtual Ports first' checkbox next time. I don't recall if I had that one selected on the Setup screen. You're right -- I have APCC & the driver all setup with IP & REST API, so I just want to silence the Virtual Ports related alerts. This is a very minor issue, all things considered, but I will be happy to see this go away.. so I'm going to check it out next time around :-)
On the topic of Beelink - the randomness in being able to remote-in so far has been limited to situations when I have the PC setup out in the backyard without a monitor, keyboard, and mouse. I can remote in using RDP in the order of 50% of the time (ie, statistically random) without an attached monitor. Once logged in (with or without a monitor), everything after that point is trouble-free with the Beelink.
My setup:
The 5v USB-powered router [1] is connected to Jackery's USB port (or sometimes Pegasus' USB ports) and is powered up first. The mini PC [2] is powered by the Pegasus (and sometimes directly to Jackery 110v power plug) and is connected using a wired ethernet cable into a LAN port on the router. The router has a static IP assigned to the mini PC, and the PC correctly obtains this using DHCP. My iPhone/iPad/MacBook/Windows Laptop connects over WiFi to the same router.
Upon powering up the mini PC I'm able to see it show up on the router's 'CLIENTS' page as a wired connection with the expected IP address assigned to it. Meaning it should be reachable (note to self.. next time I'll do a ping test at this point). When I open up "RD Client" app from iPhone/iPad or the "Microsoft Remote Desktop" app from Macbook, at this point, I sometimes get through and sometimes get an error while initiating a RDP connection to the mini PC. The error code I remember getting last night was "0x204" from the RDP. The reason I'm looking at Beelink vs Mele right now is I wonder if Beelink gets "stuck" during bootup depending on the kind of peripherals attached to it and sometimes decides it should require a monitor before completing the bootup (?? not entirely sure.. and hard to debug because the moment I attach a monitor the problem consistently goes away). Another thing to test for myself for next time around: perhaps I should do wireless from mini PC into the travel router and remove the cat5e cable.
[1] GL.iNet GL-MT1300 (Beryl) VPN Wireless Little Travel Router
On Sun, Nov 27, 2022 at 3:50 PM Brian Valente < bvalente@...> wrote: PS
Sorry i should have clarified:
assuming you are using REST API and not virtual ports, and you want the virtual ports to "go away" forever, you can disable the 'create virtual ports first' checkbox on the Setup tab
Hi Arvind
>>> Except for the part where it keeps trying to do something with virtual ports upon start up even though I have selected "None"
make sure to disable 'create virtual ports' on the main screen
>>>I have a Windows laptop (that I'd purchased solely for the purpose of astronomy) so last night I installed everything on it (ascom, v2 driver, apcc, ..) so in case my Beelink gave me issues one more time I figured I'll at least use the laptop instead of giving up for the night.
What issues are you having with the Beelink? if it's connectivity, are you trying to use it with both ethernet (perhaps to the mount) and wifi (perhaps RD app)?
On Sun, Nov 27, 2022 at 3:39 PM Arvind < base16@...> wrote: NOT SPECIFIC TO A-P: --------------------------------
My only interaction with MS Windows is from astronomy in the last 1½ years or so. As such, this first section of the email might not resonate with many people so you may choose to skip to the next A-P specific section. After days of frustration with MS Windows remote desktop issues, I managed to get things working long enough to try modeling on 1100ae last night. Even last night, I was able to connect alright twice, but twice I couldn't. Reliability score for this mini-PC mess is close to zero for me.
Picture of the source of frustration (Pegasus ultimate, beelink 12v PC running MS Windows 10, wireless router -- with its bright white light covered up). The Pegasus is powered by jackery car plug 12v 10a source, and the Pegusus in turn powers both the mini PC & the wireless router. Mount is connected to the router over wired ethernet from CP4; no USB from CP4. Power for the mount comes from a dedicated battery. Skipping over the imaging train details as they're not relevant.
I have a Windows laptop (that I'd purchased solely for the purpose of astronomy) so last night I installed everything on it (ascom, v2 driver, apcc, ..) so in case my Beelink gave me issues one more time I figured I'll at least use the laptop instead of giving up for the night.
I'm about to try the Mele mini PC to rule out any hidden bios level issues from the Beelink.. it's possible that Beelink, or perhaps the one I have, is what's causing the unreliable access issues.
A-P specific section: -----------------------------
I've been testing APCC indoors for a few days now. The software is very well documented so after some very minimal trial and error I got the driver talking to APCC using rest API, and APCC talking to the mount using IP address, avoiding virtual or real serial ports.
The APCC UI is extremely busy but I am hoping I don't need to touch it again now that I have it working. Except for the part where it keeps trying to do something with virtual ports upon start up even though I have selected "None" in all the dropdowns under the "Virtual Ports Management" section in APCC, clicked "Delete All" and also did the "Delete Residual Virtual Ports". Beyond being annoying the virtual port related alerts on startup don't appear to prevent normal operation of APCC since I'm using REST API, so I'll leave APCC as-is for now. The recent video from Brian helped me configure the REST API option in APCC -- so thank you for that video, Brian!
The APPM interface is much more streamlined and intuitive, I suppose it's much newer than APCC app. The only source of improvement, if not already possible, is in APPM -> "Plate Solve Settings". The X & Y arc-sec/pixel could be calculated by asking for focal length and aperture (or f-ratio) of the OTA. Combined with acquiring the pixel size from the camera driver, it should be possible to fill that cell with reasonable default values. Note that APPM already connects to the camera driver in the "Run" tab, so the pixel size info should be obtainable already. This is such a small change, but likely helps users prevent a source of user error so figured I'll mention it here. Right now, in my case, it had "1" in both those cells, and I had to change them to "2.3" arc-sec/pixel.
In terms of actual workflow, similar to my GM1000, I did not polar-align the mount beyond eyeballing the RA axis to have it roughly pointing to Polaris. I then built a 18pt custom model just to test the waters. For those who are familiar with MW4 app for 10u, the experience should be similar.. select points, then for each point, slew scope, settle, acquire image, platesolve, and calculate error (and show it on the screen). Finally after all the points have been mapped, it prompts you if you want to add this model to APCC; whereas with 10u you send it to the mount computer directly.
Very pleased with the overall workflow for building the model with APCC+APPM.
I took a few unguided test shots at Tadpole Nebula at 2-, 3-min subs and noticed perfectly round stars when I opened up Nina's "Aberration Inspector" tool to look at the centers & corners on the image. Note that the imaging train is my 2400MC & fsq106 at f/5, so not the most demanding but my goal was not to stress test the tracking accuracy (that's a given, with A-P mounts).
I then powered up PHD2, went through the wizard to add the mount, specified it has encoders, and calibrated and guided with 3sec exposures. The guiding was comparable to what I get without modeling but with just polar-alignment (.3-.5 RMS) but note that this is only 18pt all sky model so I wasn't expecting anything better. Next time around I might test out 50 or 80pt just to see if/how that improves in my seeing conditions.
Overall pleased with everything expect for the MS Windows based frustration. I'd most likely continue some more experiments in my backyard, especially with the newer Mele mini PC instead of the Beelink. This mount proves to be the best of both worlds -- best guided performance, and a way to go unguided if one wants to do so. TBD how the first-light would go for a truly portable setup (away from home..) --- will post once I get a chance to do that one of these days.
--
--
|
|
|
Re: 1100AE -- first time with APCC/APPM.
Thanks for that pointer, Brian. I'll look into this 'Create Virtual Ports first' checkbox next time. I don't recall if I had that one selected on the Setup screen. You're right -- I have APCC & the driver all setup with IP & REST API, so I just want to silence the Virtual Ports related alerts. This is a very minor issue, all things considered, but I will be happy to see this go away.. so I'm going to check it out next time around :-)
On the topic of Beelink - the randomness in being able to remote-in so far has been limited to situations when I have the PC setup out in the backyard without a monitor, keyboard, and mouse. I can remote in using RDP in the order of 50% of the time (ie, statistically random) without an attached monitor. Once logged in (with or without a monitor), everything after that point is trouble-free with the Beelink.
My setup:
The 5v USB-powered router [1] is connected to Jackery's USB port (or sometimes Pegasus' USB ports) and is powered up first. The mini PC [2] is powered by the Pegasus (and sometimes directly to Jackery 110v power plug) and is connected using a wired ethernet cable into a LAN port on the router. The router has a static IP assigned to the mini PC, and the PC correctly obtains this using DHCP. My iPhone/iPad/MacBook/Windows Laptop connects over WiFi to the same router.
Upon powering up the mini PC I'm able to see it show up on the router's 'CLIENTS' page as a wired connection with the expected IP address assigned to it. Meaning it should be reachable (note to self.. next time I'll do a ping test at this point). When I open up "RD Client" app from iPhone/iPad or the "Microsoft Remote Desktop" app from Macbook, at this point, I sometimes get through and sometimes get an error while initiating a RDP connection to the mini PC. The error code I remember getting last night was "0x204" from the RDP. The reason I'm looking at Beelink vs Mele right now is I wonder if Beelink gets "stuck" during bootup depending on the kind of peripherals attached to it and sometimes decides it should require a monitor before completing the bootup (?? not entirely sure.. and hard to debug because the moment I attach a monitor the problem consistently goes away). Another thing to test for myself for next time around: perhaps I should do wireless from mini PC into the travel router and remove the cat5e cable.
[1] GL.iNet GL-MT1300 (Beryl) VPN Wireless Little Travel Router
On Sun, Nov 27, 2022 at 3:50 PM Brian Valente < bvalente@...> wrote: PS
Sorry i should have clarified:
assuming you are using REST API and not virtual ports, and you want the virtual ports to "go away" forever, you can disable the 'create virtual ports first' checkbox on the Setup tab
Hi Arvind
>>> Except for the part where it keeps trying to do something with virtual ports upon start up even though I have selected "None"
make sure to disable 'create virtual ports' on the main screen
>>>I have a Windows laptop (that I'd purchased solely for the purpose of astronomy) so last night I installed everything on it (ascom, v2 driver, apcc, ..) so in case my Beelink gave me issues one more time I figured I'll at least use the laptop instead of giving up for the night.
What issues are you having with the Beelink? if it's connectivity, are you trying to use it with both ethernet (perhaps to the mount) and wifi (perhaps RD app)?
On Sun, Nov 27, 2022 at 3:39 PM Arvind < base16@...> wrote: NOT SPECIFIC TO A-P: --------------------------------
My only interaction with MS Windows is from astronomy in the last 1½ years or so. As such, this first section of the email might not resonate with many people so you may choose to skip to the next A-P specific section. After days of frustration with MS Windows remote desktop issues, I managed to get things working long enough to try modeling on 1100ae last night. Even last night, I was able to connect alright twice, but twice I couldn't. Reliability score for this mini-PC mess is close to zero for me.
Picture of the source of frustration (Pegasus ultimate, beelink 12v PC running MS Windows 10, wireless router -- with its bright white light covered up). The Pegasus is powered by jackery car plug 12v 10a source, and the Pegusus in turn powers both the mini PC & the wireless router. Mount is connected to the router over wired ethernet from CP4; no USB from CP4. Power for the mount comes from a dedicated battery. Skipping over the imaging train details as they're not relevant.
I have a Windows laptop (that I'd purchased solely for the purpose of astronomy) so last night I installed everything on it (ascom, v2 driver, apcc, ..) so in case my Beelink gave me issues one more time I figured I'll at least use the laptop instead of giving up for the night.
I'm about to try the Mele mini PC to rule out any hidden bios level issues from the Beelink.. it's possible that Beelink, or perhaps the one I have, is what's causing the unreliable access issues.
A-P specific section: -----------------------------
I've been testing APCC indoors for a few days now. The software is very well documented so after some very minimal trial and error I got the driver talking to APCC using rest API, and APCC talking to the mount using IP address, avoiding virtual or real serial ports.
The APCC UI is extremely busy but I am hoping I don't need to touch it again now that I have it working. Except for the part where it keeps trying to do something with virtual ports upon start up even though I have selected "None" in all the dropdowns under the "Virtual Ports Management" section in APCC, clicked "Delete All" and also did the "Delete Residual Virtual Ports". Beyond being annoying the virtual port related alerts on startup don't appear to prevent normal operation of APCC since I'm using REST API, so I'll leave APCC as-is for now. The recent video from Brian helped me configure the REST API option in APCC -- so thank you for that video, Brian!
The APPM interface is much more streamlined and intuitive, I suppose it's much newer than APCC app. The only source of improvement, if not already possible, is in APPM -> "Plate Solve Settings". The X & Y arc-sec/pixel could be calculated by asking for focal length and aperture (or f-ratio) of the OTA. Combined with acquiring the pixel size from the camera driver, it should be possible to fill that cell with reasonable default values. Note that APPM already connects to the camera driver in the "Run" tab, so the pixel size info should be obtainable already. This is such a small change, but likely helps users prevent a source of user error so figured I'll mention it here. Right now, in my case, it had "1" in both those cells, and I had to change them to "2.3" arc-sec/pixel.
In terms of actual workflow, similar to my GM1000, I did not polar-align the mount beyond eyeballing the RA axis to have it roughly pointing to Polaris. I then built a 18pt custom model just to test the waters. For those who are familiar with MW4 app for 10u, the experience should be similar.. select points, then for each point, slew scope, settle, acquire image, platesolve, and calculate error (and show it on the screen). Finally after all the points have been mapped, it prompts you if you want to add this model to APCC; whereas with 10u you send it to the mount computer directly.
Very pleased with the overall workflow for building the model with APCC+APPM.
I took a few unguided test shots at Tadpole Nebula at 2-, 3-min subs and noticed perfectly round stars when I opened up Nina's "Aberration Inspector" tool to look at the centers & corners on the image. Note that the imaging train is my 2400MC & fsq106 at f/5, so not the most demanding but my goal was not to stress test the tracking accuracy (that's a given, with A-P mounts).
I then powered up PHD2, went through the wizard to add the mount, specified it has encoders, and calibrated and guided with 3sec exposures. The guiding was comparable to what I get without modeling but with just polar-alignment (.3-.5 RMS) but note that this is only 18pt all sky model so I wasn't expecting anything better. Next time around I might test out 50 or 80pt just to see if/how that improves in my seeing conditions.
Overall pleased with everything expect for the MS Windows based frustration. I'd most likely continue some more experiments in my backyard, especially with the newer Mele mini PC instead of the Beelink. This mount proves to be the best of both worlds -- best guided performance, and a way to go unguided if one wants to do so. TBD how the first-light would go for a truly portable setup (away from home..) --- will post once I get a chance to do that one of these days.
--
--
|
|
|
Re: 1100AE -- first time with APCC/APPM.
PS
Sorry i should have clarified:
assuming you are using REST API and not virtual ports, and you want the virtual ports to "go away" forever, you can disable the 'create virtual ports first' checkbox on the Setup tab
Hi Arvind
>>> Except for the part where it keeps trying to do something with virtual ports upon start up even though I have selected "None"
make sure to disable 'create virtual ports' on the main screen
>>>I have a Windows laptop (that I'd purchased solely for the purpose of astronomy) so last night I installed everything on it (ascom, v2 driver, apcc, ..) so in case my Beelink gave me issues one more time I figured I'll at least use the laptop instead of giving up for the night.
What issues are you having with the Beelink? if it's connectivity, are you trying to use it with both ethernet (perhaps to the mount) and wifi (perhaps RD app)?
On Sun, Nov 27, 2022 at 3:39 PM Arvind < base16@...> wrote: NOT SPECIFIC TO A-P: --------------------------------
My only interaction with MS Windows is from astronomy in the last 1½ years or so. As such, this first section of the email might not resonate with many people so you may choose to skip to the next A-P specific section. After days of frustration with MS Windows remote desktop issues, I managed to get things working long enough to try modeling on 1100ae last night. Even last night, I was able to connect alright twice, but twice I couldn't. Reliability score for this mini-PC mess is close to zero for me.
Picture of the source of frustration (Pegasus ultimate, beelink 12v PC running MS Windows 10, wireless router -- with its bright white light covered up). The Pegasus is powered by jackery car plug 12v 10a source, and the Pegusus in turn powers both the mini PC & the wireless router. Mount is connected to the router over wired ethernet from CP4; no USB from CP4. Power for the mount comes from a dedicated battery. Skipping over the imaging train details as they're not relevant.
I have a Windows laptop (that I'd purchased solely for the purpose of astronomy) so last night I installed everything on it (ascom, v2 driver, apcc, ..) so in case my Beelink gave me issues one more time I figured I'll at least use the laptop instead of giving up for the night.
I'm about to try the Mele mini PC to rule out any hidden bios level issues from the Beelink.. it's possible that Beelink, or perhaps the one I have, is what's causing the unreliable access issues.
A-P specific section: -----------------------------
I've been testing APCC indoors for a few days now. The software is very well documented so after some very minimal trial and error I got the driver talking to APCC using rest API, and APCC talking to the mount using IP address, avoiding virtual or real serial ports.
The APCC UI is extremely busy but I am hoping I don't need to touch it again now that I have it working. Except for the part where it keeps trying to do something with virtual ports upon start up even though I have selected "None" in all the dropdowns under the "Virtual Ports Management" section in APCC, clicked "Delete All" and also did the "Delete Residual Virtual Ports". Beyond being annoying the virtual port related alerts on startup don't appear to prevent normal operation of APCC since I'm using REST API, so I'll leave APCC as-is for now. The recent video from Brian helped me configure the REST API option in APCC -- so thank you for that video, Brian!
The APPM interface is much more streamlined and intuitive, I suppose it's much newer than APCC app. The only source of improvement, if not already possible, is in APPM -> "Plate Solve Settings". The X & Y arc-sec/pixel could be calculated by asking for focal length and aperture (or f-ratio) of the OTA. Combined with acquiring the pixel size from the camera driver, it should be possible to fill that cell with reasonable default values. Note that APPM already connects to the camera driver in the "Run" tab, so the pixel size info should be obtainable already. This is such a small change, but likely helps users prevent a source of user error so figured I'll mention it here. Right now, in my case, it had "1" in both those cells, and I had to change them to "2.3" arc-sec/pixel.
In terms of actual workflow, similar to my GM1000, I did not polar-align the mount beyond eyeballing the RA axis to have it roughly pointing to Polaris. I then built a 18pt custom model just to test the waters. For those who are familiar with MW4 app for 10u, the experience should be similar.. select points, then for each point, slew scope, settle, acquire image, platesolve, and calculate error (and show it on the screen). Finally after all the points have been mapped, it prompts you if you want to add this model to APCC; whereas with 10u you send it to the mount computer directly.
Very pleased with the overall workflow for building the model with APCC+APPM.
I took a few unguided test shots at Tadpole Nebula at 2-, 3-min subs and noticed perfectly round stars when I opened up Nina's "Aberration Inspector" tool to look at the centers & corners on the image. Note that the imaging train is my 2400MC & fsq106 at f/5, so not the most demanding but my goal was not to stress test the tracking accuracy (that's a given, with A-P mounts).
I then powered up PHD2, went through the wizard to add the mount, specified it has encoders, and calibrated and guided with 3sec exposures. The guiding was comparable to what I get without modeling but with just polar-alignment (.3-.5 RMS) but note that this is only 18pt all sky model so I wasn't expecting anything better. Next time around I might test out 50 or 80pt just to see if/how that improves in my seeing conditions.
Overall pleased with everything expect for the MS Windows based frustration. I'd most likely continue some more experiments in my backyard, especially with the newer Mele mini PC instead of the Beelink. This mount proves to be the best of both worlds -- best guided performance, and a way to go unguided if one wants to do so. TBD how the first-light would go for a truly portable setup (away from home..) --- will post once I get a chance to do that one of these days.
--
|
|
|
Re: 1100AE -- first time with APCC/APPM.
Hi Arvind
>>> Except for the part where it keeps trying to do something with virtual ports upon start up even though I have selected "None"
make sure to disable 'create virtual ports' on the main screen
>>>I have a Windows laptop (that I'd purchased solely for the purpose of astronomy) so last night I installed everything on it (ascom, v2 driver, apcc, ..) so in case my Beelink gave me issues one more time I figured I'll at least use the laptop instead of giving up for the night.
What issues are you having with the Beelink? if it's connectivity, are you trying to use it with both ethernet (perhaps to the mount) and wifi (perhaps RD app)?
On Sun, Nov 27, 2022 at 3:39 PM Arvind < base16@...> wrote: NOT SPECIFIC TO A-P: --------------------------------
My only interaction with MS Windows is from astronomy in the last 1½ years or so. As such, this first section of the email might not resonate with many people so you may choose to skip to the next A-P specific section. After days of frustration with MS Windows remote desktop issues, I managed to get things working long enough to try modeling on 1100ae last night. Even last night, I was able to connect alright twice, but twice I couldn't. Reliability score for this mini-PC mess is close to zero for me.
Picture of the source of frustration (Pegasus ultimate, beelink 12v PC running MS Windows 10, wireless router -- with its bright white light covered up). The Pegasus is powered by jackery car plug 12v 10a source, and the Pegusus in turn powers both the mini PC & the wireless router. Mount is connected to the router over wired ethernet from CP4; no USB from CP4. Power for the mount comes from a dedicated battery. Skipping over the imaging train details as they're not relevant.
I have a Windows laptop (that I'd purchased solely for the purpose of astronomy) so last night I installed everything on it (ascom, v2 driver, apcc, ..) so in case my Beelink gave me issues one more time I figured I'll at least use the laptop instead of giving up for the night.
I'm about to try the Mele mini PC to rule out any hidden bios level issues from the Beelink.. it's possible that Beelink, or perhaps the one I have, is what's causing the unreliable access issues.
A-P specific section: -----------------------------
I've been testing APCC indoors for a few days now. The software is very well documented so after some very minimal trial and error I got the driver talking to APCC using rest API, and APCC talking to the mount using IP address, avoiding virtual or real serial ports.
The APCC UI is extremely busy but I am hoping I don't need to touch it again now that I have it working. Except for the part where it keeps trying to do something with virtual ports upon start up even though I have selected "None" in all the dropdowns under the "Virtual Ports Management" section in APCC, clicked "Delete All" and also did the "Delete Residual Virtual Ports". Beyond being annoying the virtual port related alerts on startup don't appear to prevent normal operation of APCC since I'm using REST API, so I'll leave APCC as-is for now. The recent video from Brian helped me configure the REST API option in APCC -- so thank you for that video, Brian!
The APPM interface is much more streamlined and intuitive, I suppose it's much newer than APCC app. The only source of improvement, if not already possible, is in APPM -> "Plate Solve Settings". The X & Y arc-sec/pixel could be calculated by asking for focal length and aperture (or f-ratio) of the OTA. Combined with acquiring the pixel size from the camera driver, it should be possible to fill that cell with reasonable default values. Note that APPM already connects to the camera driver in the "Run" tab, so the pixel size info should be obtainable already. This is such a small change, but likely helps users prevent a source of user error so figured I'll mention it here. Right now, in my case, it had "1" in both those cells, and I had to change them to "2.3" arc-sec/pixel.
In terms of actual workflow, similar to my GM1000, I did not polar-align the mount beyond eyeballing the RA axis to have it roughly pointing to Polaris. I then built a 18pt custom model just to test the waters. For those who are familiar with MW4 app for 10u, the experience should be similar.. select points, then for each point, slew scope, settle, acquire image, platesolve, and calculate error (and show it on the screen). Finally after all the points have been mapped, it prompts you if you want to add this model to APCC; whereas with 10u you send it to the mount computer directly.
Very pleased with the overall workflow for building the model with APCC+APPM.
I took a few unguided test shots at Tadpole Nebula at 2-, 3-min subs and noticed perfectly round stars when I opened up Nina's "Aberration Inspector" tool to look at the centers & corners on the image. Note that the imaging train is my 2400MC & fsq106 at f/5, so not the most demanding but my goal was not to stress test the tracking accuracy (that's a given, with A-P mounts).
I then powered up PHD2, went through the wizard to add the mount, specified it has encoders, and calibrated and guided with 3sec exposures. The guiding was comparable to what I get without modeling but with just polar-alignment (.3-.5 RMS) but note that this is only 18pt all sky model so I wasn't expecting anything better. Next time around I might test out 50 or 80pt just to see if/how that improves in my seeing conditions.
Overall pleased with everything expect for the MS Windows based frustration. I'd most likely continue some more experiments in my backyard, especially with the newer Mele mini PC instead of the Beelink. This mount proves to be the best of both worlds -- best guided performance, and a way to go unguided if one wants to do so. TBD how the first-light would go for a truly portable setup (away from home..) --- will post once I get a chance to do that one of these days.
|
|
|
1100AE -- first time with APCC/APPM.
NOT SPECIFIC TO A-P: --------------------------------
My only interaction with MS Windows is from astronomy in the last 1½ years or so. As such, this first section of the email might not resonate with many people so you may choose to skip to the next A-P specific section. After days of frustration with MS Windows remote desktop issues, I managed to get things working long enough to try modeling on 1100ae last night. Even last night, I was able to connect alright twice, but twice I couldn't. Reliability score for this mini-PC mess is close to zero for me.
Picture of the source of frustration (Pegasus ultimate, beelink 12v PC running MS Windows 10, wireless router -- with its bright white light covered up). The Pegasus is powered by jackery car plug 12v 10a source, and the Pegusus in turn powers both the mini PC & the wireless router. Mount is connected to the router over wired ethernet from CP4; no USB from CP4. Power for the mount comes from a dedicated battery. Skipping over the imaging train details as they're not relevant.
I have a Windows laptop (that I'd purchased solely for the purpose of astronomy) so last night I installed everything on it (ascom, v2 driver, apcc, ..) so in case my Beelink gave me issues one more time I figured I'll at least use the laptop instead of giving up for the night.
I'm about to try the Mele mini PC to rule out any hidden bios level issues from the Beelink.. it's possible that Beelink, or perhaps the one I have, is what's causing the unreliable access issues.
A-P specific section: -----------------------------
I've been testing APCC indoors for a few days now. The software is very well documented so after some very minimal trial and error I got the driver talking to APCC using rest API, and APCC talking to the mount using IP address, avoiding virtual or real serial ports.
The APCC UI is extremely busy but I am hoping I don't need to touch it again now that I have it working. Except for the part where it keeps trying to do something with virtual ports upon start up even though I have selected "None" in all the dropdowns under the "Virtual Ports Management" section in APCC, clicked "Delete All" and also did the "Delete Residual Virtual Ports". Beyond being annoying the virtual port related alerts on startup don't appear to prevent normal operation of APCC since I'm using REST API, so I'll leave APCC as-is for now. The recent video from Brian helped me configure the REST API option in APCC -- so thank you for that video, Brian!
The APPM interface is much more streamlined and intuitive, I suppose it's much newer than APCC app. The only source of improvement, if not already possible, is in APPM -> "Plate Solve Settings". The X & Y arc-sec/pixel could be calculated by asking for focal length and aperture (or f-ratio) of the OTA. Combined with acquiring the pixel size from the camera driver, it should be possible to fill that cell with reasonable default values. Note that APPM already connects to the camera driver in the "Run" tab, so the pixel size info should be obtainable already. This is such a small change, but likely helps users prevent a source of user error so figured I'll mention it here. Right now, in my case, it had "1" in both those cells, and I had to change them to "2.3" arc-sec/pixel.
In terms of actual workflow, similar to my GM1000, I did not polar-align the mount beyond eyeballing the RA axis to have it roughly pointing to Polaris. I then built a 18pt custom model just to test the waters. For those who are familiar with MW4 app for 10u, the experience should be similar.. select points, then for each point, slew scope, settle, acquire image, platesolve, and calculate error (and show it on the screen). Finally after all the points have been mapped, it prompts you if you want to add this model to APCC; whereas with 10u you send it to the mount computer directly.
Very pleased with the overall workflow for building the model with APCC+APPM.
I took a few unguided test shots at Tadpole Nebula at 2-, 3-min subs and noticed perfectly round stars when I opened up Nina's "Aberration Inspector" tool to look at the centers & corners on the image. Note that the imaging train is my 2400MC & fsq106 at f/5, so not the most demanding but my goal was not to stress test the tracking accuracy (that's a given, with A-P mounts).
I then powered up PHD2, went through the wizard to add the mount, specified it has encoders, and calibrated and guided with 3sec exposures. The guiding was comparable to what I get without modeling but with just polar-alignment (.3-.5 RMS) but note that this is only 18pt all sky model so I wasn't expecting anything better. Next time around I might test out 50 or 80pt just to see if/how that improves in my seeing conditions.
Overall pleased with everything expect for the MS Windows based frustration. I'd most likely continue some more experiments in my backyard, especially with the newer Mele mini PC instead of the Beelink. This mount proves to be the best of both worlds -- best guided performance, and a way to go unguided if one wants to do so. TBD how the first-light would go for a truly portable setup (away from home..) --- will post once I get a chance to do that one of these days.
|
|
|
Re: First night out with the 1100-AE
Stuart
Wow!! Nice test shot! Great that your 1100-AE worked so well!
Hi all,
I wanted to share how my first night out with my new 1100-AE went. I meant to just do this as a test to see how well the tracking performed, but it was working so well I let it go for about 5 hours of exposure. 113x 180 second shots of the Spider Nebula and surrounding field with the Stowaway and an IMX410 color camera.
https://www.astrobin.com/542tg4/
I had attached my guide scope to try a guided run, but silly me didn't realize how unnecessary that ended up being. Aligned with RAPAS (not even calibrated yet), then a quick 50 point dec arc model was all that was needed. Only had to throw away a few frames and that was only because of passing clouds. Every frame had identically round stars. I can't believe how well this mount works.
-Ken
|
|
|
First night out with the 1100-AE
Hi all, I wanted to share how my first night out with my new 1100-AE went. I meant to just do this as a test to see how well the tracking performed, but it was working so well I let it go for about 5 hours of exposure. 113x 180 second shots of the Spider Nebula and surrounding field with the Stowaway and an IMX410 color camera. https://www.astrobin.com/542tg4/I had attached my guide scope to try a guided run, but silly me didn't realize how unnecessary that ended up being. Aligned with RAPAS (not even calibrated yet), then a quick 50 point dec arc model was all that was needed. Only had to throw away a few frames and that was only because of passing clouds. Every frame had identically round stars. I can't believe how well this mount works. -Ken
|
|
|
Re: First night with the Mach 2
Andrew, glad to hear you sorted the dec encoder issue. That's one impressive turnaround time for a fix by A-P!
Awesome!
My heart skipped a beat seeing the pool! Totally understand your needs though.
Doing a model is super easy. You'll love it.
|
|
|
Re: Park 2: Saddle Knobs Up or Down?
Thank you Mike.
Its good to know I wasn't out to lunch on what I have been doing, and good to find out ways to improve. I thought about it last night while cloudy and see how with larger and heavier telescopes, pre attaching the rings to the mount becomes more important.
Cheers!
Christopher
|
|
|
Re: First night with the Mach 2
Awesome!
My heart skipped a beat seeing the pool! Totally understand your needs though.
Doing a model is super easy. You'll love it.
|
|
|
Re: Park 2: Saddle Knobs Up or Down?
M Hambrick
Hi Christopher I have a two-scope system with a 180EDT (big & heavy) in a side-by-side arrangement with a Tele-Vue Pronto (small & light). I always have the mount (1100GTO) in Park-2 per Roland's recommendation. I have found that the 180EDT is easier to attach when the dovetail plate and rings are already attached to the saddle plate. The rings are open with the hinges up. In this situation it really doesn't really matter which way the dovetail knobs are oriented, but in my case they are down. Like you, I keep the dovetail and rings attached to the smaller scopes and load them dovetail and all into the saddle. In this case, I have found it easier to do this when the dovetail knobs are up. Here is a picture with everything attached. I always start out with just the OTA when attaching the scopes, and then add the cameras, etc. after the scopes are attached. To attach the 180, I have to use a folding stair. I use slings to hold the scope while I climb the stair. I would add another suggestion. It is worth spending some time setting up your system indoors to find the balance points. For any given visual or imaging system, the balance points will not change too much, so once you have figured out where to position the counterweights and dovetail plates, you can set it up the same way every time. It also helps to record this information somewhere, especially if you have multiple setups. Mike 
|
|
|
Re: First night with the Mach 2
Andrew Burwell
Here's the setup. I'm aware this expensive setup is next to a swimming pool. After hearing about that person on here who's mount blew over, it makes me a little nervous. Though I can't imagine having it outside during 30-60mph gusts. In a few months this will all be moved to an observatory. Until then, this is the best spot on the yard for imaging.  
|
|
|
First night with the Mach 2
Andrew Burwell
Technically it's my second night. I had a hardware issue with my DEC encoder which had to get sorted out back at AP. But they were fast, and had the mount back to me in less than a full week. It's been storming here for the last 6 days, and I finally got it out. I have the Takahashi Epsilon 200 on it, and I'm guiding since I've not built a model. After a PA routine with Nina, down to 1 deg of error, it's guiding very well. One of these days I'll get a model going, but want to work out the kinks first. Monitoring right now for the meridian flip. Hopefully that will go smooth. 
|
|
|
Re: Mach1 strange noise when DEC slewing North
Make sure that you have not turned on the Reverse DEC Output After Meridian Flip setting in the PHD "brain".
Rgrds-Ross
|
|
|
Park 2: Saddle Knobs Up or Down?
When loading my OTA with the mount (Mach 1) in Park 2, I've always wondered if it makes a difference if the saddle locking knobs are UP or DOWN. I usually keep the dovetail and rings attached to my OTA (a 130EDT, so longish) so usually have the knobs UP as I have the OTA cradled in my two arms, can engage the dovetail into the saddle fixed side, then reach around w one hand to tighten the saddle knobs while still cradling the OTA. Then I read a couple of notes where Roland recommends loading the rings and dovetail into the saddle first without the OTA ( https://ap-gto.groups.io/g/main/message/75334 and https://ap-gto.groups.io/g/main/topic/newbie_question_on_balancing/37390207?p=Created%2C%2C%2C20%2C1%2C0%2C0&jump=1 ). Loading w or w/o OTA aside, does it make any difference? I assume not as it all gets flipped around depending upon which side of the meridian one is pointing. Related, if loading an OTA when in Park 2 into open rings like the hinged rings I have, does it matter if the hinge side of the rings are down or up? When loading that way I usually have the ring hinges on the down side because it feels safer to me (flip the ring up and engage the locking knob) Note that I usually load the OTA in Park 2 without attachements like the camera, etc, swing it to Park 3 to attach the extras, then swing it back to Park 2 position to adjust DEC balance. All of this is with the mount off and using the clutches. I see in the above threads that some recommend loading everything on the OTA then loading that into the rings in Park 2 position. That seemed heavier. Thoughts appreciated. Thanks Christ
|
|
|
Re: Mach1 strange noise when DEC slewing North
SharpCap was showing about 15 arcseconds polar alignment error. I ran PHD2 guiding assistant after that and before imaging. The log shows 2.8 arc-min PA error and recommended 680ms DEC backlash compensation.
|
|
|
Re: Mach1 strange noise when DEC slewing North
the DEC line would just go right off the chart. Sounds like very bad polar alignment. With good polar alignment the stars won't drift in Dec, so PHD2 would only occasionally send a guide pulse.
PHD2 also has a routine for checking Dec backlash, and you need to run this before every session just to make sure everything is working ok. In fact, run the entire wizard routine so you know what the mount is doing.
Roland
-----Original Message-----
From: john.hobbs@...
To: main@ap-gto.groups.io
Sent: Sat, Nov 26, 2022 5:39 pm
Subject: Re: [ap-gto] Mach1 strange noise when DEC slewing North
Thanks Roland. I will be re-greasing it this coming week. The mount would move north during guiding, but the DEC adjustments being sent by PHD2 couldnt keep up and the DEC line would just go right off the chart. This occured right after a meridan flip. Prior to the flip, guiding was fine. I am hoping that the loose motor is related, but wont get a chance to test it for at least a week according to the weather.
-- Roland Christen Astro-Physics
|
|
|
Re: Mach1 strange noise when DEC slewing North
Thanks Roland. I will be re-greasing it this coming week. The mount would move north during guiding, but the DEC adjustments being sent by PHD2 couldnt keep up and the DEC line would just go right off the chart. This occured right after a meridan flip. Prior to the flip, guiding was fine. I am hoping that the loose motor is related, but wont get a chance to test it for at least a week according to the weather.
|
|
|
Re: Mach1 strange noise when DEC slewing North
That's not an unusual sound for that gearbox when the pinions and gear teeth are dry. It appears to me that you also need to re-grease the worm as well as the spur gears.
When you say it won't guide when tracking north, are you saying that the mount won't move in Dec in the North direction? Check to make sure that the setscrew on the spur gear on the end of the worm is tight. If it's loose it won't reverse properly.
Roland Christen
-----Original Message-----
From: john.hobbs@...
To: main@ap-gto.groups.io
Sent: Sat, Nov 26, 2022 10:52 am
Subject: [ap-gto] Mach1 strange noise when DEC slewing North
My Mach1 mount started making a strange noise when DEC is slewing North. Besides just being noisy, it now will not guide when the object is tracking north. I have re-meshed the DEC worm gear according to old procedure. The foremost spur gear is not too tight as I am able to turn it with my fingers fairly easily. Any help is appreciated. Video located here https://www.youtube.com/shorts/b0gZ4MHYMYg
-- Roland Christen Astro-Physics
|
|
|
