|
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.
|
|
|
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.
|
|
|
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.
--
|
|
|
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.
--
--
|
|
|
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.
--
--
|
|
|
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.
--
--
|
|
|
Thanks, Brian. I'll try disabling wifi altogether. I can see how that can be a problem (race condition within RDP, perhaps) for connecting over RDP. In fact, the Beelink is connected over wifi to my home network ( 192.168.1.0/24) since I'm doing these tests in my backyard but the wired ethernet goes to the standalone travel router ( 192.168.8.0/24).
Greg, thanks. I'll try static IP on the mini PC next as you suggest. FWIW I'd do static and not DHCP from the mini PC side as you've suggested, _and_ do static assignment on the router side to prevent the router from reusing that IP for another client (say my phone/iPad/..).
On Sun, Nov 27, 2022 at 5:41 PM Brian Valente < bvalente@...> wrote: 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.
--
--
--
|
|
|
>>> I can see how that can be a problem (race condition within RDP, perhaps) for connecting over RDP
Actually the problem is a setting within Windows and Beelink computers that prevents wifi and ethernet from being used together (I know! crazy)
so if one is active, the other one will be disabled. If you want to fix this, just PM me and I can send you details on how to fix it.
I spent too much time with Beelink support and studying on my own, i don't want you to go through that ;)
On Sun, Nov 27, 2022 at 7:38 PM Arvind < base16@...> wrote: Thanks, Brian. I'll try disabling wifi altogether. I can see how that can be a problem (race condition within RDP, perhaps) for connecting over RDP. In fact, the Beelink is connected over wifi to my home network ( 192.168.1.0/24) since I'm doing these tests in my backyard but the wired ethernet goes to the standalone travel router ( 192.168.8.0/24).
Greg, thanks. I'll try static IP on the mini PC next as you suggest. FWIW I'd do static and not DHCP from the mini PC side as you've suggested, _and_ do static assignment on the router side to prevent the router from reusing that IP for another client (say my phone/iPad/..).
On Sun, Nov 27, 2022 at 5:41 PM Brian Valente < bvalente@...> wrote: 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.
--
--
--
|
|
|
Rafa
So, please tell us what you think of the matchup; 10um v AP
I have an 1100 AE coming and I am currently using a GM 2000. Should I settle for less than, more than, equal to performance? By the way, I use model creator. I hope I can ease into this workflow.
|
|
|
Hi Brian -- that's actually interesting. I was looking up something along those lines earlier (how to disable wifi whenever I plug in ethernet -- apparently it's a new feature in Windows). I had no idea Beelink did something like that behind the scenes. Thank you so much for sharing this piece of info! Definitely turning off wifi in this case and going with a static IP over wired ethernet.
Hi Rafa, Performance is not the differentiator in this class
Any observable or reported difference in performance between A-P & 10u (and add Planewave while we're at it) is more likely to arise from user error in setup. Including some obvious ones -- like flexure, or being extremely out of PA, or using an outdated model (say you re-do PA after building a model or any other non-trivial physical movement after the model is built). The other source of differences could be if the mount needs servicing, though it should be rare in this class for a new mount.
Since you're using ModelCreator with 10u, I assume that you're on MS Windows already. In that case, I'd encourage you to focus on capacity, features (CW up, meridian flip (or not..)), portability & shippability, product support, community support, mechanical serviceability, product availability for purchase, resale value and the like. I have only used MW4 and felt APPM to be a piece of cake.. I haven't used ModelCreator, so it's hard for me to compare that with APPM. Curious to hear your thoughts once you get the A-P mount.
Best wishes.
On Mon, Nov 28, 2022 at 5:22 AM Rafa < rafa@...> wrote:
So, please tell us what you think of the matchup; 10um v AP
I have an 1100 AE coming and I am currently using a GM 2000. Should I settle for less than, more than, equal to performance? By the way, I use model creator. I hope I can ease into this workflow.
|
|
|
