2021 replies to this topic

[Astro Andy]

Got it, my mistake. From version 8.20, if the GPS module is not connected, the GPS screen is not displayed.

If you add fake (offline) GPS coordinates it will appear I believe.

[mimmo]

More photos of the first unit from post #1 above, showing the MUSB (Mount-USB) Select switch, the WiFi Mode switch, a BN-180 GPS receiver piggybacked on top, and general views all around.  All leftover protruding header pins have been clipped flush.

 

Note that I have applied a bit of Kapton (electrical) tape between the ESP32 board and the GPS module, to avoid short-circuiting anything.  There's also a small bit of doubled-sided tape there to hold it in place until the heat-shrink step later on.

 

1.jpg 2.jpg 3.jpg 4.jpg 5.jpg

 

On that last photo, the switch to the right side of the RJ12 jack is the WiFi mode switch.  DOWN is for "direct connect", and UP is for Access Point mode.  This switch can be toggled on-the-fly.

 

The switch on the left side of the RJ12 jack is the MUSB (Mount-USB) Select switch.  DOWN is for normal operation, where the USB port shows debug information etc., and UP is for MUSB mode.  The setting must be selected prior to power-on.

 

Next step is to blob a bit of hot-melt glue around the two switches for mechanical reinforcement, and then encase it in some clear heat-shrink tubing.  Photos to follow.

Hello, great work.....

[mlord]

The assembly instructions on the HBG3 site have now been updated with better information about where/how to mount a GPS receiver directly to the HBG3 PCB.  The old method of sticking it over the 3.3V regulator area should not be used -- the regulator and other components sometimes overheat when placed there.

[mimmo]

Good morning mlord, does the gps module, for hbg3, have to be only the beitian bn180 type? or you can also use the neo6m module. the signals should be the same or not......
Thank you

[mlord]

I only test the HBG3 design and firmware with Beitian GPS receivers, using the latest UBLOX chips.  Future versions of the firmware may include specific features for those.  Eg. A-GPS support.

 

Any of the Beitian BN/BE series will be fine.  Get a larger sized one if your enclosure has space -- the bigger antennas give faster fixes.

Edited by mlord, 21 May 2024 - 06:27 AM.

[mimmo]

I only test the HBG3 design and firmware with Beitian GPS receivers, using the latest UBLOX chips.  Future versions of the firmware may include specific features for those.  Eg. A-GPS support.

ok

[fuadramsey]

HBG3 box mount and nunchuck mount for Celestron Evolution

 

I modified a couple brackets to mount the HomeBrew 3 Box (Luca) to the Nexstar Evolution bracket behind the controller, as well as added a clip for the Nunchuck holder to go on the base of the HD8 handle. Now you have a place to store your HBG3, controller and nunchuck without cable wrap that is easy to remove.

 

Thanks to those people for creating them! 

 

 

Here's the Thingiverse link : https://www.thingive...m/thing:6635435

 

Everything:

 

Controller + HBG3 mount -HBG3 base mount slides on and off.

 

3D Parts

Edited by fuadramsey, 24 May 2024 - 03:59 PM.

[nexStar2008]

I have a question about cordwrap. I have a Nexstar GPS 8, I have enabled the cordwrap function I believe on the HBG3 (set cordwrap.override 1 -> save -> reset) but it does not appear as an option in CPWI mount settings, nor does it seem to work for my scope. The option is on my hand control, but again does not seem to work properly, maybe I am just misunderstanding how this should work, Is there something I am missing with regard to the HBG3 or the Nexstar GPS scopes?

 

Thanks!

[mlord]

I have a question about cordwrap. I have a Nexstar GPS 8, I have enabled the cordwrap function I believe on the HBG3 (set cordwrap.override 1 -> save -> reset) but it does not appear as an option in CPWI mount settings, nor does it seem to work for my scope.

One might first do a bit of research as to exactly what "cordwrap" means for Celestron gear.  The option is misnamed -- it actually should be called "anti-cordwrap", because when enabled it tries to prevent cords from wrapping around the tripod.

 

Next, one might search this very thread for the meaning of the HBG3 "cordwrap.override" settings:  https://www.cloudyni...post&p=12889208

 

   set cordwrap.override 0    ## always turn CORDWRAP OFF

   set cordwrap.override 1    ## always turn CORDWRAP ON

   set cordwrap.override      ## leave CORDWRAP alone

 

After doing "save" and "reset", this setting remains in effect across resets and power-cycles until changed again by the user.  Any attempts to change it by the hand-controller, or CPWI or an app, will be overridden unless the third option above was used.

 

The existence of a "cordwrap" function on the mount depends upon the firmware version of the mount/MC.  See here for information about Nexstar-GPS firmware versions:  https://nexstarsite....GPSFirmware.htm

 

If the mount/MC firmware does not have cordwrap support, then neither will the software (CPWI) or the hand-controller (HC).  Note that the original (V1,V2) Nexstar-GPS HC is unlikely to have this feature, but a V4/V5 HC normally does support cordwrap.

 

Finally, the cordwrap feature does not normally work at all until after doing a sky alignment of some kind.  I don't recall whether or not the HBG3 setting is able to bypass that restriction or not.

Edited by mlord, 25 May 2024 - 06:02 AM.

[scopewizard]

Cordwrap is in CPWI 2.5.5 mount settings if available for the mount.

You have to be connected to the mount to manage it.

 

CGX type mount have software and hard stop limits therefore that feature is not relevant.

[nexStar2008]

Cordwrap is in CPWI 2.5.5 mount settings if available for the mount.

You have to be connected to the mount to manage it.

 

CGX type mount have software and hard stop limits therefore that feature is not relevant.

That's the thing I don't understand, there is clearly a cordwrap setting on my Nexstar GPS HC (v2.2) that allows me to set cordwrap, but it does not appear in CPWI when connected and aligned as it should be either with HBG3 or without I have the latest MC(4.6) I believe.

I just found this on the Celestron website:
 

First, check which version you have in the menu under Utilities – Version. If the MC (motor control) number is 5.13 or less, you need to upgrade the firmware using Celestron’s MCupdate program. Newer versions correct a problem with the cordwrap prevention feature and allows you to successfully set up cordwrap for your scope.

So it appears there is an issue with mounts versions lower than MC 5.13 (I have 4.6) Is there anyway to overcome this with the HBG3? Can I trick CPWI into thinking I have MC 5.13? Do we know what the issue is? Can I remove my HC (I can't upgrade beyond 2.2) from the scope and just update my MC to 5.13? Sorry for all the questions, but would be cool to find a way to work around this issue if I can.

Thanks for the reply

Edited by nexStar2008, 25 May 2024 - 12:06 PM.

[mlord]

..it appears there is an issue with mounts versions lower than MC 5.13 (I have 4.6) Is there anyway to overcome this with the HBG3? Can I trick CPWI into thinking I have MC 5.13? Do we know what the issue is? Can I remove my HC (I can't upgrade beyond 2.2) from the scope and just update my MC to 5.13? Sorry for all the questions, but would be cool to find a way to work around this issue if I can.

Please ask all of these questions in a new/different thread.  At this point you are discussing Nexstar-GPS firmware  and not the HBG3.  (no, the HBG3 will not fake the firmware version for you here).
 

[nexStar2008]

Please ask all of these questions in a new/different thread.  At this point you are discussing Nexstar-GPS firmware  and not the HBG3.  (no, the HBG3 will not fake the firmware version for you here).
 

I read things like this from you a couple of years ago about "faking the Mount" and it makes me wonder if my Nexstar-GPS is currently operating as if it were a CPC in CPWI with the HBG3, why not fake the MC version? I'll poke around with the code and see what happens...

 

https://www.cloudyni...2#entry11636683

[mlord]

I read things like this from you a couple of years ago about "faking the Mount" and it makes me wonder if my Nexstar-GPS is currently operating as if it were a CPC in CPWI

That code from two+ years ago has long been improved upon.  CPWI will even TELL YOU that it knows it is talking to a Nexstar-GPS mount now.
 

[nexStar2008]

That code from two+ years ago has long been improved upon.  CPWI will even TELL YOU that it knows it is talking to a Nexstar-GPS mount now.
 

Ok, a bit of an update. I dug around the code a bit and managed to spoof the MC version (to 5.14), however, this didn't help me gain access to the cordwrap prevention setting in CPWI for my NXGPS. So I decided to spoof the model to a CPC. CPWI sent a a few commands that aren't available on my mount, so I was going through one by one (faking the responses) but got kind of stuck. CPWI wouldn't handshake with the mount, would just stop sending commands for ALT/AZM without really giving me any indication as to why. The focuser would handshake and that was all that would communicate between HBG3 and CPWI, no gps, no mount, just the focuser lol. Oh well, that's enough for now, maybe I will revisit in the future. I am pretty sure CPWI relies on the model, or a combination of model/MC version to display cordwrap prevention setting. Either way, I had fun. The hack_response_pkt function is very handy  

[mlord]

Ok, a bit of an update. I dug around the code a bit and managed to spoof the MC version (to 5.14) ..  I decided to spoof the model to a CPC.

Hey, well done! 

I'm always happy to see people hacking away and learning more about the code and the mount protocol!

 

Here is the (very old) code from v4.9, which I think was the last version to emulate a CPC for the Nexstar-GPS, before things got fixed to just treat the Nexstar-GPS as a Nexstar-GPS instead.  I doubt this will help, because the real issue in your case is likely just missing CORDWRAP from your firmware version or something, but you can capture a trace and we'll see:

static uint16_t hack_response_for_compatibility (byte *data, uint16_t len)
{
  if (data[0] != 0x3b || len < 6 || data[2] != 0x10)
    return len;
  // MC_GET_MODEL 1-byte response from a GPS-8 mount: {0x3b,0x04,0x10,0x20,0x05,0x01,0xc6}:
  // SkyPortal expects a 2-byte response to MC_GET_MODEL (0x05).
  if (len == 7 && data[0] == 0x3b && data[2] == 0x10 && data[4] == 0x05) {
    if (verbose) Serial_printf("Translating MC_GET_MODEL response\n");
    data[1] += 1;
    data[6] = 0x89;  // emulate a CPC mount.  (was: data[6] = data[5];)
    data[5] = 0x11;  // emulate a CPC mount.  (was: data[5] = 0;)
    insert_checksum(data, ++len);
    return len;
  }
  // MC_GET_MAX_RATE response from a GPS-8 mount: {0x3b,0x03,0x10,0x20,0x23,0xaa}:
  // SkyPortal expects a 1-byte response to MC_GET_MAX_RATE (0x23):
  if (len == 6 && data[0] == 0x3b && data[2] == 0x10 && data[4] == 0x23) {
    if (verbose) Serial_printf("Translating MC_GET_MAX_RATE response\n");
    data[1] += 1;
    data[5] = 0x00;  // return 00 for MC_GET_MAX_RATE, same as Evolution mount
    insert_checksum(data, ++len);
    return len;
  }
  // Emulate MC_GET_MAX_SLEW_RATE for NexstarGPS, using response data from an Evolution mount:
  if (len == 6 && data[0] == 0x3b && data[2] == 0x10 && data[4] == 0x21) {
    if (verbose) Serial_printf("Emulating MC_GET_MAX_SLEW_RATE response\n");
    data[1] += 4;
    data[5] = 0xa0;
    data[6] = 0x11;
    data[7] = 0x94;
    data[8] = 0x54;
    len += 4;
    insert_checksum(data, len);
    return len;
  }
  return len;
}

 

[mlord]

Here is the (very old) code from v4.9 .. I doubt this will help, because the real issue in your case is likely just missing CORDWRAP from your firmware version

Perhaps you could just use "normal" firmware in the HBG3, connect over Serial for debug purposes, issue the 'v' command there to trace all communications.. and then use WiFi or BT for CPWI's connection.  I'd like to see if CPWI ever tries to query for CORDWRAP, and if so, what response the mount gives in return.  If it's just a case of "wrong format" or something, then THAT we CAN fix in the HBG3 firmware!

 

The Nexstar-GPS appears to have had CORDWRAP support from very early on, so it could just be a protocol tweak is needed, as already done now for the GET_MODEL command.

Edited by mlord, 27 May 2024 - 09:23 AM.

[nexStar2008]

 

Hey, well done! 

I'm always happy to see people hacking away and learning more about the code and the mount protocol!

 

Here is the (very old) code from v4.9, which I think was the last version to emulate a CPC for the Nexstar-GPS, before things got fixed to just treat the Nexstar-GPS as a Nexstar-GPS instead.  I doubt this will help, because the real issue in your case is likely just missing CORDWRAP from your firmware version or something, but you can capture a trace and we'll see:

Thanks for providing that, very helpful. After playing around with the code I have a much deeper appreciation for what you have created here (and in a relatively short amount of time!) One glaring difference I see is that you are emulating a CPC Deluxe (0x1189) whereas I was emulating the CPC XLT? I believe with (0x09). I will have a go with the 0x1189 and see what happens. I will post a trace of my results this time.
 

I am sure my mount firmware supports cordwrap, I can set MC_ENABLE/DISABLE_CORDWRAP on or off, poll it  with MC_POLL_CORDWRAP and it responds with either ff or 00, and it responds with -180 for MC_GET_CORDWRAP_POS. So it is there, the real question for me is if CPWI handles the cordwrap functionality, or does it just send the commands to enable/disable it and rely on the mount to handle it (which does not appear to work properly on my NXGPS). Hopefully it is the former. I will have another go at it and get back to you. Thanks again for the code and a nudge to keep going.

[nexStar2008]

Perhaps you could just use "normal" firmware in the HBG3, connect over Serial for debug purposes, issue the 'v' command there to trace all communications.. and then use WiFi or BT for CPWI's connection.  I'd like to see if CPWI ever tries to query for CORDWRAP, and if so, what response the mount gives in return.  If it's just a case of "wrong format" or something, then THAT we CAN fix in the HBG3 firmware!

 

The Nexstar-GPS appears to have had CORDWRAP support from very early on, so it could just be a protocol tweak is needed, as already done now for the GET_MODEL command.

I will do that for sure,
CPWI does indeed query for CORDWRAP, I will get back to you in a bit with my verbose / traces. Thanks.

[mlord]

CORDWRAP is implemented in the mount firmware.  CPWI, the HC, the other apps, can merely enable, disable, or query it.  But the mount itself is normally the thing doing the policing.

 

It doesn't have to be like that -- software could easily monitor mount rotation and do the cordwrap policing itself, since it already does keep track of the mount rotation after alignment.   But it does not do the policing.

[nexStar2008]

Here is my trace for connecting to CPWI with normal firmware. You can see CPWI does indeed query for CORDWRAP. Not sure if something is missing or if the responses are ok though.

 

12:48:49.831 -> vverbose=1
12:49:22.938 -> BT: CONNECTED mode AUX
12:49:25.808 -> routing[5]: SW (20) on bt_rx
12:49:25.808 -> 000080449 auxbus_tx: 3b 03 20 10 fe cf 					[SW     -> AZM   ] GET_VERSION
12:49:25.855 -> 000080457 auxbus_rx: 3b 05 10 20 fe 04 06 c3 				[AZM    -> SW    ] Version: 4.6
12:49:25.950 -> 000080552 auxbus_tx: 3b 03 20 11 fe ce 					[SW     -> ALT   ] GET_VERSION
12:49:25.950 -> 000080560 auxbus_rx: 3b 05 11 20 fe 04 06 c2 				[ALT    -> SW    ] Version: 4.6
12:49:25.997 -> 000080616 auxbus_tx: 3b 03 20 10 05 c8 					[SW     -> AZM   ] GET_MODEL
12:49:25.997 -> 000080625 auxbus_rx: 3b 04 10 20 05 01 c6 				[AZM    -> SW    ] Model: Nexstar-GPS
12:49:25.997 -> Translating MC_GET_MODEL response
12:49:26.088 -> 000080710 auxbus_tx: 3b 03 20 10 41 8c 					[SW     -> AZM   ] MC_GET_NEG_BACKLASH
12:49:26.088 -> 000080720 auxbus_rx: 3b 04 10 20 41 00 8b 				[AZM    -> SW    ]
12:49:26.182 -> 000080790 auxbus_tx: 3b 03 20 11 41 8b 					[SW     -> ALT   ] MC_GET_NEG_BACKLASH
12:49:26.182 -> 000080798 auxbus_rx: 3b 04 11 20 41 00 8a 				[ALT    -> SW    ]
12:49:26.228 -> 000080849 auxbus_tx: 3b 03 20 10 fc d1 					[SW     -> AZM   ] MC_GET_APPROACH
12:49:26.228 -> 000080859 auxbus_rx: 3b 04 10 20 fc 00 d0 				[AZM    -> SW    ]
12:49:26.276 -> 000080912 auxbus_tx: 3b 03 20 11 fc d0 					[SW     -> ALT   ] MC_GET_APPROACH
12:49:26.322 -> 000080920 auxbus_rx: 3b 04 11 20 fc 01 ce 				[ALT    -> SW    ]
12:49:26.369 -> 000080975 auxbus_tx: 3b 03 20 11 38 94 					[SW     -> ALT   ] MC_ENABLE_CORDWRAP
12:49:26.369 -> 000080985 auxbus_rx: 3b 03 11 20 38 94 					[ALT    -> SW    ]
12:49:26.416 -> 000081055 auxbus_tx: 3b 06 20 11 3a c0 00 00 cf 			[SW     -> ALT   ] MC_SET_CORDWRAP_POS
12:49:26.463 -> 000081071 auxbus_rx: 3b 03 11 20 3a 92 					[ALT    -> SW    ]
12:49:26.558 -> 000081161 auxbus_tx: 3b 03 20 10 01 cc 					[SW     -> AZM   ] MC_GET_POS
12:49:26.558 -> 000081170 auxbus_rx: 3b 06 10 20 01 00 00 00 c9 			[AZM    -> SW    ] MC_GET_POS   0.000
12:49:26.605 -> 000081224 auxbus_tx: 3b 03 20 11 01 cb 					[SW     -> ALT   ] MC_GET_POS
12:49:26.605 -> 000081232 auxbus_rx: 3b 06 11 20 01 00 00 00 c8 			[ALT    -> SW    ] MC_GET_POS   0.000
12:49:26.698 -> 000081303 auxbus_tx: 3b 03 20 10 01 cc 					[SW     -> AZM   ] MC_GET_POS
12:49:26.698 -> 000081311 auxbus_rx: 3b 06 10 20 01 00 00 00 c9 			[AZM    -> SW    ] MC_GET_POS   0.000
12:49:26.744 -> 000081366 auxbus_tx: 3b 03 20 11 01 cb 					[SW     -> ALT   ] MC_GET_POS
12:49:26.744 -> 000081375 auxbus_rx: 3b 06 11 20 01 00 00 00 c8 			[ALT    -> SW    ] MC_GET_POS   0.000
12:49:26.837 -> 000081433  focus_rx: 3b 03 20 12 fe cd 					[SW     -> FOCUS ] GET_VERSION
12:49:26.837 -> 000081440     bt_rx: 3b 07 12 20 fe 07 10 24 54 3a 			[FOCUS  -> SW    ] Version: 7.16.9300
12:49:26.885 -> 000081527  focus_rx: 3b 03 20 12 2c 9f 					[SW     -> FOCUS ] MC_GET_LIMITS
12:49:26.932 -> 000081534     bt_rx: 3b 0b 12 20 2c 00 00 00 00 00 00 ea 60 4d 		[FOCUS  -> SW    ]
12:49:26.978 -> auxbus_tx: pkts_max=2
12:49:26.978 -> 000081598    gps_rx: 3b 03 20 b0 fe 2f 					[SW     -> GPS   ] GET_VERSION
12:49:26.978 -> 000081605     bt_rx: 3b 05 b0 20 fe 02 00 2b 				[GPS    -> SW    ] Version: 2.0
12:49:26.978 -> 000081614  focus_rx: 3b 03 20 12 01 ca 					[SW     -> FOCUS ] MC_GET_POS
12:49:27.024 -> 000081621     bt_rx: 3b 06 12 20 01 00 75 30 22 			[FOCUS  -> SW    ] MC_GET_POS 30000
12:49:27.024 -> 000081665    gps_rx: 3b 03 20 b0 37 f6 					[SW     -> GPS   ] GPS_LINKED

Here specifically, It looks odd, I don't think it should be using ALT, it should be AZM. This may be the source of the problem in that CPWI is trying to set the cordwrap position using ALT instead of AZM. See below:
 

12:49:26.369 -> 000080975 auxbus_tx: 3b 03 20 11 38 94 					[SW     -> ALT   ] MC_ENABLE_CORDWRAP
12:49:26.369 -> 000080985 auxbus_rx: 3b 03 11 20 38 94 					[ALT    -> SW    ]
12:49:26.416 -> 000081055 auxbus_tx: 3b 06 20 11 3a c0 00 00 cf 			[SW     -> ALT   ] MC_SET_CORDWRAP_POS
12:49:26.463 -> 000081071 auxbus_rx: 3b 03 11 20 3a 92 					[ALT    -> SW    ]

When I query the mount using AZM and ALT here is the result. Notice that Cordwrap enabled responds fine to either AZM or ALT, but when I try to get Cordwrap position, only AZM responds correctly with the info.
 

13:10:22.873 -> send AZM 0x3b001337525 auxbus_tx: 3b 03 e2 10 3b d0 					[HBG3   -> AZM   ] MC_POLL_CORDWRAP
13:10:22.873 -> 001337535 auxbus_rx: 3b 04 10 e2 3b 00 cf 				[AZM    -> HBG3  ]
13:10:41.605 -> send AZM 0x3c001356245 auxbus_tx: 3b 03 e2 10 3c cf 					[HBG3   -> AZM   ] MC_GET_CORDWRAP_POS
13:10:41.605 -> 001356254 auxbus_rx: 3b 06 10 e2 3c 80 00 00 4c 			[AZM    -> HBG3  ] MC_GET_CORDWRAP_POS -180.000
13:11:51.619 -> send AZM 0x38001426262 auxbus_tx: 3b 03 e2 10 38 d3 					[HBG3   -> AZM   ] MC_ENABLE_CORDWRAP
13:11:51.619 -> 001426271 auxbus_rx: 3b 03 10 e2 38 d3 					[AZM    -> HBG3  ]
13:11:58.450 -> send AZM 0x3b001433093 auxbus_tx: 3b 03 e2 10 3b d0 					[HBG3   -> AZM   ] MC_POLL_CORDWRAP
13:11:58.450 -> 001433103 auxbus_rx: 3b 04 10 e2 3b ff d0 				[AZM    -> HBG3  ]
13:12:13.226 -> send AZM 0x3c001447862 auxbus_tx: 3b 03 e2 10 3c cf 					[HBG3   -> AZM   ] MC_GET_CORDWRAP_POS
13:12:13.226 -> 001447872 auxbus_rx: 3b 06 10 e2 3c 80 00 00 4c 			[AZM    -> HBG3  ] MC_GET_CORDWRAP_POS -180.000
13:12:44.951 -> send ALT 0x3b001479590 auxbus_tx: 3b 03 e2 11 3b cf 					[HBG3   -> ALT   ] MC_POLL_CORDWRAP
13:12:44.951 -> 001479598 auxbus_rx: 3b 04 11 e2 3b ff cf 				[ALT    -> HBG3  ]
13:13:42.861 -> send ALT 0x3c001537494 auxbus_tx: 3b 03 e2 11 3c ce 					[HBG3   -> ALT   ] MC_GET_CORDWRAP_POS
13:13:42.861 -> 001537502 auxbus_rx: 3b 06 11 e2 3c c0 00 00 0b 			[ALT    -> HBG3  ]

Let me know what you think. Cheers.

 

Edited by nexStar2008, 27 May 2024 - 05:20 PM.

[mlord]

Well spotted.  The protocol documentation for the Nexstar-GPS says to use the AZM MC for that.  There's no mention of what might happen if ALT is instead used.   So we could try having the HBG3 change ALT to AZM for the CORDWRAP stuff (including the responses, which need to be changed back to ALT).

 

Other users have in the past reported CPWI cordwrap not working when expected, on various mounts.  This would explain that finally!

 

I'll code up a workaround.

Edited by mlord, 27 May 2024 - 02:08 PM.

[mlord]

Here we go.  This version works:   hbg3.ino.v8.46g.txt   320.71KB   17 downloads

 

This is the buggy/uncorrected CPWI on my Evolution mount, where SW refers to "SoftWare" (CPWI):

 

000032754 auxbus_tx: 3b 03 20 11 38 94                       [SW     -> ALT   ] MC_ENABLE_CORDWRAP
000032762 auxbus_rx: 3b 03 11 20 38 94                       [ALT    -> SW    ]

 

000032803 auxbus_tx: 3b 06 20 11 3a c0 00 00 cf              [SW     -> ALT   ] MC_SET_CORDWRAP_POS
000032813 auxbus_rx: 3b 03 11 20 3a 92                       [ALT    -> SW    ]

 

And here is the trace with the new HBG3 firmware, fixing CPWI's ALT/AZM confusion:

 

000014802  original: 3b 03 20 11 38 94                       [SW     -> ALT   ] MC_ENABLE_CORDWRAP
000014817 auxbus_tx: 3b 03 20 10 38 95                       [SW     -> AZM   ] MC_ENABLE_CORDWRAP

000014826 auxbus_rx: 3b 03 10 20 38 95                       [AZM    -> SW    ]
000014836 rewritten: 3b 03 11 20 38 94                       [ALT    -> SW    ]

 

000014896  original: 3b 06 20 11 3a c0 00 00 cf              [SW     -> ALT   ] MC_SET_CORDWRAP_POS
000014913 auxbus_tx: 3b 06 20 10 3a c0 00 00 d0              [SW     -> AZM   ] MC_SET_CORDWRAP_POS

000014923 auxbus_rx: 3b 03 10 20 3a 93                       [AZM    -> SW    ] MC_SET_CORDWRAP_POS -153.281
000014935 rewritten: 3b 03 11 20 3a 92                       [ALT    -> SW    ]

 

One can see above that the HBG3 is now rewriting the command to go to AZM instead of ALT, and then rewriting the response to appear to come from ALT instead of AZM (to keep CPWI happy).

 

This is not likely to matter with the Evolution mount -- a single processor handles both ALT/AZM Motor Controller functions.  But most other Celestron mounts have individual Motor Controller chips, one for each of AZM and ALT, and for those I suspect this is just plain broken functionality with CPWI.  This new HBG3 code should "fix" that now.

 

The SkyPortal app appears to correctly use AZM for everything, and I expect SkySafari to be the same (not tested though).

Edited by mlord, 27 May 2024 - 02:32 PM.

[mlord]

EDIT:  Updated the HBG3 sketch in the above post to v8.46g now, so that it continues to correctly work around a different CPWI cordwrap bug.  They really had their "A-Team" working that day, I guess.  Or Not! 

 

Cheers

Edited by mlord, 27 May 2024 - 02:04 PM.

[nexStar2008]

One can see above that the HBG3 is now rewriting the command to go to AZM instead of ALT, and then rewriting the response to appear to come from ALT instead of AZM (to keep CPWI happy).

 

This is not likely to matter with the Evolution mount -- a single processor handles both ALT/AZM Motor Controller functions.  But most other Celestron mounts have individual Motor Controller chips, one for each of AZM and ALT, and for those I suspect this is just plain broken functionality with CPWI.  This new HBG3 code should "fix" that now.

 

The SkyPortal app appears to correctly use AZM for everything, and I expect SkySafari to be the same (not tested though).

Great news, Cordwrap prevention now works correctly on my NexStar GPS 8 when using CPWI. The button is still not displayed in CPWI (to enable/disable) but that seems to be a CPWI thing and nothing to do with the HBG3. Thanks for the fix on this Mark, awesome job.

Here is the new trace when launching CPWI (note I tested on v8.46e v8.46g)
 

18:00:32.293 -> BT: CONNECTED mode AUX
18:00:35.290 -> routing[5]: SW (20) on bt_rx
18:00:35.290 -> 000806788 auxbus_tx: 3b 03 20 10 fe cf 					[SW     -> AZM   ] GET_VERSION
18:00:35.336 -> 000806797 auxbus_rx: 3b 05 10 20 fe 04 06 c3 				[AZM    -> SW    ] Version: 4.6
18:00:35.431 -> 000806894 auxbus_tx: 3b 03 20 11 fe ce 					[SW     -> ALT   ] GET_VERSION
18:00:35.431 -> 000806902 auxbus_rx: 3b 05 11 20 fe 04 06 c2 				[ALT    -> SW    ] Version: 4.6
18:00:35.478 -> 000806960 auxbus_tx: 3b 03 20 10 05 c8 					[SW     -> AZM   ] GET_MODEL
18:00:35.478 -> 000806969 auxbus_rx: 3b 04 10 20 05 01 c6 				[AZM    -> SW    ] Model: Nexstar-GPS
18:00:35.478 -> Translating MC_GET_MODEL response
18:00:35.571 -> 000807050 auxbus_tx: 3b 03 20 10 41 8c 					[SW     -> AZM   ] MC_GET_NEG_BACKLASH
18:00:35.571 -> 000807058 auxbus_rx: 3b 04 10 20 41 00 8b 				[AZM    -> SW    ]
18:00:35.619 -> 000807100 auxbus_tx: 3b 03 20 11 41 8b 					[SW     -> ALT   ] MC_GET_NEG_BACKLASH
18:00:35.619 -> 000807109 auxbus_rx: 3b 04 11 20 41 00 8a 				[ALT    -> SW    ]
18:00:35.667 -> 000807162 auxbus_tx: 3b 03 20 10 fc d1 					[SW     -> AZM   ] MC_GET_APPROACH
18:00:35.713 -> 000807172 auxbus_rx: 3b 04 10 20 fc 00 d0 				[AZM    -> SW    ]
18:00:35.760 -> 000807225 auxbus_tx: 3b 03 20 11 fc d0 					[SW     -> ALT   ] MC_GET_APPROACH
18:00:35.760 -> 000807233 auxbus_rx: 3b 04 11 20 fc 00 cf 				[ALT    -> SW    ]
18:00:35.808 -> 000807269  original: 3b 03 20 11 38 94 					[SW     -> ALT   ] MC_ENABLE_CORDWRAP
18:00:35.808 -> 000807280 auxbus_tx: 3b 03 20 10 38 95 					[SW     -> AZM   ] MC_ENABLE_CORDWRAP
18:00:35.808 -> 000807289 auxbus_rx: 3b 03 10 20 38 95 					[AZM    -> SW    ]
18:00:35.808 -> 000807295 rewritten: 3b 03 11 20 38 94 					[ALT    -> SW    ]
18:00:35.856 -> 000807346  original: 3b 06 20 11 3a c0 00 00 cf 			[SW     -> ALT   ] MC_SET_CORDWRAP_POS
18:00:35.904 -> 000807360 auxbus_tx: 3b 06 20 10 3a c0 00 00 d0 			[SW     -> AZM   ] MC_SET_CORDWRAP_POS
18:00:35.904 -> 000807377 auxbus_rx: 3b 03 10 20 3a 93 					[AZM    -> SW    ] MC_SET_CORDWRAP_POS -153.281
18:00:35.904 -> 000807386 rewritten: 3b 03 11 20 3a 92 					[ALT    -> SW    ]
18:00:35.951 -> 000807432 auxbus_tx: 3b 03 20 10 01 cc 					[SW     -> AZM   ] MC_GET_POS
18:00:35.951 -> 000807441 auxbus_rx: 3b 06 10 20 01 d7 e6 df 2d 			[AZM    -> SW    ] MC_GET_POS -56.388
18:00:36.045 -> 000807515 auxbus_tx: 3b 03 20 11 01 cb 					[SW     -> ALT   ] MC_GET_POS
18:00:36.045 -> 000807523 auxbus_rx: 3b 06 11 20 01 07 6f 92 c0 			[ALT    -> SW    ] MC_GET_POS  10.457
18:00:36.091 -> 000807583 auxbus_tx: 3b 03 20 10 01 cc 					[SW     -> AZM   ] MC_GET_POS
18:00:36.091 -> 000807593 auxbus_rx: 3b 06 10 20 01 d7 e6 df 2d 			[AZM    -> SW    ] MC_GET_POS -56.388
18:00:36.185 -> 000807646 auxbus_tx: 3b 03 20 11 01 cb 					[SW     -> ALT   ] MC_GET_POS
18:00:36.185 -> 000807654 auxbus_rx: 3b 06 11 20 01 07 6f 92 c0 			[ALT    -> SW    ] MC_GET_POS  10.457
18:00:36.280 -> 000807742  focus_rx: 3b 03 20 12 fe cd 					[SW     -> FOCUS ] GET_VERSION
18:00:36.280 -> 000807749     bt_rx: 3b 07 12 20 fe 07 10 24 54 3a 			[FOCUS  -> SW    ] Version: 7.16.9300
18:00:36.326 -> 000807826  focus_rx: 3b 03 20 12 2c 9f 					[SW     -> FOCUS ] MC_GET_LIMITS
18:00:36.373 -> 000807834     bt_rx: 3b 0b 12 20 2c 00 00 00 00 00 00 ea 60 4d 		[FOCUS  -> SW    ]
18:00:36.419 -> 000807892  focus_rx: 3b 03 20 12 01 ca 					[SW     -> FOCUS ] MC_GET_POS

 

I may have another bug that can be worked out regarding slew limits (again this does not work in CPWI for me) I will gather some info before I post about it though! Slew limits are working fine, disregard this!

Cheers

Edited by nexStar2008, 27 May 2024 - 03:37 PM.