2035 replies to this topic

[dlwmacgregor]

I guess I never noticed it because I never use the HC and CPWI together.

All I know is, when I started up CPWI the Cordwrap indicator was OFF and so I set it ON.

If I then disconnect and exit CPWI and go back in, it is OFF again.

So I figured it was working, unlike before where it was always OFF nomatter what I did

 

But the bug fix is good so I'll implement it.

[mlord]

Here is v7.9 of the Arduino ESP32 source code for this project:  hbg3.ino.v7.9.txt   219.06KB   29 downloads

• New NVRAM setting for "cordwrap.override" to override hand-controller, CPWI, etc.  0/1 forces OFF/ON, blank does nothing.
• Workaround for CPWI sending bad MC_POLL_CORDWRAP commands.
• Change MC CORDWRAP opcode names to match the AUX Protocol document.
• Implement push-and-hold for OLED_MODE button to cycle DewControl "aggression" values for channel-0.
• GPS: New NVRAM setting for "disable.gps": leaves built-in GPS running, but not responding on AUX bus.
• GPS: emulate the GPS_GET_RCVR_STATUS command.

Again, nothing earth-shattering.  But anyone using CPWI might appreciate the bug-workaround for the CORDWRAP setting. 

 

Oh, and for an HBG3 Dew Controller, the OLED now shows the temperature offset (aka. "aggression") for each channel.  If one now presses and holds the D4 button while viewing that screen, the offset will slowly cycle through the ten possible settings for channel-0.  This will enable me to more easily adjust the dew heater "in the field" at tonight's local star party!

 

EDIT:  The flashable binary and huge Arduino .ZIP/.TGZ packages have also now been updated to include this version.

Edited by mlord, 20 August 2023 - 10:52 AM.

[Frisk]

Oooh. Ok. Now you've got me.  I'll be able to turn off the GPS and use it on my CPC. Might take me a while to get to it but I will definitely update.

[mlord]

Oooh. Ok. Now you've got me.  I'll be able to turn off the GPS and use it on my CPC. Might take me a while to get to it but I will definitely update.

For CPWI, SkySafari, etc.. the HBG3 GPS would already be used instead of any built-in one, no problems.   But for a hand-controller, yeah, you'll want to disable the HBG3 GPS or unplug the built-in one to avoid conflicts.
 

Edited by mlord, 19 August 2023 - 03:00 PM.

[scopewizard]

Well, it turns out that CPWI still has this "buggered up" in 2.5.2 at least.

When CPWI starts up, it issues this command for MC_POLL_CORDWRAP:

 

    3b 04 20 10 3b 01 xx

 

Which happens to be incorrect (BUG!).  The proper command, expected by the mount, is this:

 

    3b 03 20 10 3b xx

 

The extra 01 byte sent by CPWI confuses my Evolution mount, causing it to give an incorrect response in return, which CPWI then interprets as "CORDWRAP IS ENABLED" even though it isn't actually enabled.

 

I'm going to see what happens if I have the HBG3 "fix" the command from CPWI.  Will update in a few minutes..

 

Note:  Anyone can see this happening for themselves.  Use the hand-controller to turn CORDWRAP "OFF".  Then fire up CPWI, connect, and look at the "configure mount" settings.  It will show CORDWRAP as "ON".

On my CGX without HC attached, in CPWI,  with the cord wrap off, it stays off on connection and if it is set to on in CPWI, on connection it is on.

I don't know if I am wrong here but was told that CPWI settings override HC settings when plugged in HC or USB.

My HC settings are different than those in CPWI. While imaging, no HC attached and visual no CPWI used.

Edited by scopewizard, 19 August 2023 - 04:12 PM.

[mlord]

The cordwrap setting is something local to the "controller", just like alignment is local to the "controller".  Be that a hand-controller or CPWI.  A command is sent to the mount to query it though, and when setting it on/off a couple of commands are sent.

 

The effect of CPWI sending a bad command will depend upon the mount firmware.  So perhaps the CGX doesn't do exactly the same thing as the Evo here.

Edited by mlord, 19 August 2023 - 05:51 PM.

[mlord]

On my CGX without HC attached, in CPWI,  with the cord wrap off, it stays off on connection and if it is set to on in CPWI, on connection it is on.

I don't know if I am wrong here but was told that CPWI settings override HC settings when plugged in HC or USB.

My HC settings are different than those in CPWI. While imaging, no HC attached and visual no CPWI used.

As far as I can tell from tracing CPWI messaging, CPWI does NOT change the CORDWRAP setting from whatever it finds as the current value, until one goes into the "configure mount" menu and changes it there.

 

On start-up, CPWI queries the current setting (with a bad/corrupted message that the HBG3 now "fixes"), but does not attempt to apply any new setting.

 

If one is using the HBG3, and wants to apply a global setting for CORDWRAP, then use the serial/telnet interface of the HBG3 and one of these commands, followed by "save" and then "reset":

 

   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.

 

EDIT:  Actually, using "1" here isn't 100% optimal.  Ideally, the HBG3 should get the current motor position, and then set the CORDWRAP position to that +/- 180degrees.  But then it would also have to monitor for MC_SET_POS commands and so forth.  A lot of extra code and complexity for what is intended as a modest feature.

 

So.. it doesn't do that.  CORDWRAP will be whatever the mount defaults it to (180degrees?), and somewhat random as to which starting position it will be relative to.  But it will still work, and prevent no more than one full revolution before reversing direction.  Not ideal, but practical. 

Edited by mlord, 20 August 2023 - 04:04 PM.

[BarryBrown]

Got my HBG3 assembled. Serial debug info shows all subsystems are working!

 

....and there's a hurricane blocking my view of the skies.

[mlord]

Here is v7.10 of the Arduino ESP32 source code for this project:   hbg3.ino.v7.10.txt   220.24KB   26 downloads

• Allow settling time before loopback existence test for auxrelay bus
• Give Relay devices a different bus address than regular HBG3: makes testing easier.
• Split DEV_ESP32 into DEV_HBG3 and DEV_RELAY.
• Show degrees for MC_GET_POS and CORDWRAP commands.

This release got prompted by my building a a new HBG3-Relay device here, and then testing it with a regular HBG3 plugged into the Relay side.   I wanted the BLUE BLINK auxtest stuff to work on both types, and this necessitated assigning the Relay a new, unique bus address:  DEV_RELAY (0xe4)

 

Then I noticed that the Relay was sometimes coming up as a "non Relay", which is a Bad Thing™.  On power-up/reset, every HBG3 does a loopback test on the auxrelay UART to see if the extra hardware is present for it or not.  If the loopback test succeeds, the HBG3 switches to "HBG3-Relay" operation, otherwise it remains a normal "HBG3".

 

The issue was that it was doing the loopback test too soon, while other devices on the bus were still initializing and "making noise".  So now it waits until a 1/4 second after power-on before doing the test, and does a much quicker version of the test as well.

 

The final status, HBG3 or HBG3-Relay, is also now shown on one of the OLED screens.

Edited by mlord, 22 August 2023 - 12:17 PM.

[mlord]

[regarding resistors between AUX ports on the SE mounts]

I won't be able to check things on the Evo for a while yet

Okay, I just remembered this and so grabbed the ohm-meter.  All four AUX ports on the Evo are directly wired together, with no resistors between them.  So very different from the SE --> we've always known the Evo was more tolerant of accessories, and now we know why! 

Edited by mlord, 22 August 2023 - 08:06 PM.

[b079]

I've got to imagine there's a reason they went with such high ohm resistors. It seems all the accessories are fine without them. I wonder if they could be bypassed safely. My main concern would be if the mount aux needs it for some reason. Either way, it seems like overkill for most purposes.

[mlord]

It is very likely for the Evo to have current-limiting resistors of some kind between the AUX signals and the CPU chip itself.  I haven't traced far enough to see what values they use for that, but the designer would have been especially foolish not to have them.

 

There may be something protecting the RX pin of the UART port at the CPU, and similar protection for the BUSY-IN signal to the CPU.  The TX and BUSY-OUT signals are already protected by the 74HCT(2G)125 chip, same as in the HBG3 and the hand-controllers.

 

On the SE, those 47K ones might be all that there is, so bypassing them wouldn't be wise unless one simply relocated them, one per signal, to be only between the PIC (CPU) and AUX ports.

Edited by mlord, 23 August 2023 - 07:59 AM.

[mlord]

Here is v7.11 of the Arduino ESP32 source code for this project:  hbg3.ino.v7.11.txt   221.12KB   31 downloads

• Reduce bt_is_active timeout from 15 to 10 seconds.
• Show 0x3c packet data when using "trace ssaa".
• Use "HBG3" instead of "HomeBrew" in most places.
• If auxrelay_detected, then Use 'r' instead of 'v' prefix in VERSION everywhere.
• Disable Dew Control if auxrelay_detected (pin conflicts).
• Tidy up auxtest output, and better align print_packet() output.
• Tweak/speed-up auxrelay detection logic.
• Rename "auxrelay_[rt]x" to "relay_[rt]x" for print_packet() output.

So.. mainly house-keeping. 

 

As usual, the .ZIP/.TGZ Arduino archives have also been updated, linked at https://rtr.ca/hbg3/

 

A copy of the SiLabs cp210x USB-Serial driver is also now included in the .ZIP archive for MS-Windows users -- it still need to be installed (once) from that file though.  Linux users needn't fuss, as Linux has the driver built-in, as with most other USB-Serial drivers.

 

 

[Frapeno]

Does anyone here care about the "Cord Wrap" setting?  As-in, wanting to force it either on or off, regardless of what the hand-controller and/or CPWI try to do?

 

I'm adding code to manage this inside the HBG3.

And I'm also looking for suggestions of anything else one might want for convenience or otherwise.

 

Cheers

Wondering if can add any animation into Oled display, like a "planet .GIF", before the display show up the main status, just once when connect to the mount , turn it ON.

[mlord]

Here is v7.12 of the Arduino ESP32 source code for this project:  hbg3.ino.v7.12.txt   222.04KB   29 downloads

• Workarounds for CPWI sending bad MC_GOTO_DONE commands (aka. MC_SLEW_DONE).
• Improve focus_debug output.

I was poking at the Focuser controls in SkyPortal, SkySafari, and CPWI today, and noted that ALL of them are horrible.  Eg. SkyPortal, when attempting to adjust the focuser by one step, "-1", actually sends two command to the Focus Motor:  one command to do -501, and another to then do +500, for a net result of "-1".. the hard way.  Ugh.

 

So.. while attempting various unsuccessful workarounds for this behaviour, I then noticed that CPWI has yet another bug: it is sending invalid MC_GOTO_DONE commands to both the Focus Motor and the ALT/AZM motors.  The result being that the HBG3's internal Focus Motor support wasn't fully working with CPWI.

 

So.. added workarounds for that, and also now have the HBG3 "fix" those bad commands just in case something else cares about them.  This is important enough that a new release is warranted, thus v7.12.

 

Anyone using a Focus Motor, Celestron or HomeBrew, needs to update to this version immediately.  Others can do as they like. 

[Frisk]

I wonder if Celestron is seeing how many bugs they can introduce just to see if you can find clever solutions.

[Frapeno]

Battery monitoring?

Also maybe animation into Display, like a "planet .GIF" once powered up, after then show up current menu status. 

[mlord]

I wonder if Celestron is seeing how many bugs they can introduce just to see if you can find clever solutions.

I strongly suspect they don't have a protocol analyzer like the HBG3 (or like the Celestron AUX Bus Scanner).  If they did, they'd be able to test their stuff better.

 

Also maybe animation into Display, like a "planet .GIF" once powered up, after then show up current menu status.

You said that already.  No need to keep repeating it.

Edited by mlord, 24 August 2023 - 09:10 PM.

[mlord]

I have added a breadboard tutorial for the Smart 2X Dew Heater add-on to the HBG3 over in the Dew Controller thread, here:  https://www.cloudyni...5#entry12899787

[jproehl]

A problem has appeared in my HBG3. While the focuser function still works on the nunchuck controller for the Celestron Focus motor (but it seems more intermittent than before), the nunchuck joystick no longer slews either my Evolution or CPC mounts. However, if I hold down both buttons to switch it into Slew only mode alone, the slew control returns.  I'm running v7.12 on the HBG3. Ideas??

[mlord]

A problem has appeared in my HBG3.

That all sounds like normal operation to me, except for the "intermittent" part.  While in "slew" mode, you can hold just the "C" button and it will instead mange the Focus Motor.

 

Cheers
 

[jproehl]

That all sounds like normal operation to me, except for the "intermittent" part.  While in "slew" mode, you can hold just the "C" button and it will instead mange the Focus Motor.

 

Cheers
 

I don't think that's correct that its acting normally. What I'm seeing is that in the dual mode (where the joystick alone is supposed to slew the mount and you have to hold the "C" button down to get the joystick to change focus), the joystick alone (not holding the "C" button) does NOT slew the mount at all. The only way I can get it to slew is to hold both buttons down for several seconds to switch the HBG3 into the slew-only mode.  In that slew-only mode, I assume that you cannot focus.

 

Unless you decided to change the HBG3 to have focus only and slew only modes that are selected by holding the buttons down for several seconds to switch modes. If that has been done, then why do you have to hold the top button down to get the focus motor to activate with the joystick in the focus only mode?

 

BTW: I've tried several nunchucks and two HBG3 boards and they all act the same - no slewing in the dual mode.

 

I'm wondering if in all the changes that have been made since V6.X versions, something has been done that messes up the normal slew function?
 

Edited by jproehl, 25 August 2023 - 04:22 PM.

[mlord]

That is normal.  There is no "slew only" mode, but rather a choice between "slew + focus", and "focus only" modes.  Pressing/holding both buttons for 2-seconds switches between the two modes.  Which is what you are doing (successfully).  From the description, it sounds like you have the two modes reversed in your mind. 

 

EDIT: The only behaviour change ever made, is that the "focus only" mode used to require a hard-coded selection at build time, whereas now it's a 2-button option at run time (and is remembered in NVRAM).

 

In "focus only" mode, both buttons are individually used as "focus preset memory" buttons.

 

Cheers

Edited by mlord, 25 August 2023 - 05:23 PM.

[jproehl]

I've confirmed after several trials that it is working as you stated, but I'm having lots of trouble getting consistent focusing. It sometimes doesn't seem to work or will only focus in one direction and either not or very sluggishly in the other. However, I suspect that this issue may be related to problems with the used nunchucks. I found one in my collection that seemed to work better and I'll stick with it for now.

 

At one point and for about 30 min, my CPC mount was giving the dreaded "Telescope model not found" error. I found the only solution to be unplugging the Aux cable from the HBG3. After starting thew mount up successfully, I could then plug in the aux cable into the HBG3 and everything would work. Is there any danger in "hot plugging" the HBG3 into a Celestron mount like this?  Should providing 12V to the HBG3 provide any benefit for this issue?

[mlord]

At one point and for about 30 min, my CPC mount was giving the dreaded "Telescope model not found" error. I found the only solution to be unplugging the Aux cable from the HBG3. After starting thew mount up successfully, I could then plug in the aux cable into the HBG3 and everything would work. Is there any danger in "hot plugging" the HBG3 into a Celestron mount like this?  Should providing 12V to the HBG3 provide any benefit for this issue?

That should not be happening.  Are you sure your power source was still giving 12V power during that episode?

 

Yes, if you are not using the WiFi/BT/USB features of the HBG3, then you could power it from 12V without plugging it into an AUX port.  If it doesn't already have a DC-In jack, then the easiest way to accomplish that might be to create a special "AUX" cable with the 6P6C plug at one end, and a DC-In jack on the other end, connected only to the wires for pins 2 (12) and 4 (GND).

 

EDIT: Oh, Focus Motor..  Okay, so power the HBG3 with 5V through its USB port instead of connecting to the mount.

 

Hot-plugging _anything_ on a Celestron mount is risky to all of the electronics involved.

 

Cheers
 

Edited by mlord, 26 August 2023 - 07:19 PM.