2021 replies to this topic

[mlord]

With internet, the HBG3 can contact the U-BLOX servers and download "online" AssistNow data (about 4KBytes) and load that into the GPS module.  A full time/location fix then usually follows within a couple of seconds!

This is turning out to be a bit trickier.  Sometimes it works, sometimes no effect whatsoever.  There is also definitely an interaction with the "AssistNow-Autonomous" flag that was discussed earlier in this thread.

 

So this could take a few more weeks to figure it all out, as it requires writing code to implement the U-Blox GPS protocol to interrogate and change various settings.

 

Cheers

[mlord]

There also seems to be an issue with the HC switching from GPS location source to manual location, I assume when the GPS signal is too slow in coming.

No need to guess (or "assume") things.  This has already been investigated with AUX bus traces to see what is REALLY going on.

 

The answer is, never power-on the mount without the GPS plugged in. Otherwise, the Nexstar+ hand-controller will turn off GPS in its own settings, then requiring the user to turn it back on again next time the GPS is plugged in (before power-on!).

 

The same effect has been reported by at least one user who claimed their GPS was having trouble being detected, and so the Nexstar+ again just disabled it.  That's a different issue (AUX bus not working properly in that situation).

 

The Starsense HC also used to do this, and may still do the same. But I have not spent enough time tracing the most recent firmware there to know for sure.
 

Edited by mlord, 03 April 2024 - 07:02 AM.

[Rac19]

The answer is, never power-on the mount without the GPS plugged in. Otherwise, the Nexstar+ hand-controller will turn off GPS in its own settings, then requiring the user to turn it back on again next time the GPS is plugged in (before power-on!).

As you have mentioned previously, nothing should be plugged into an Aux port when it powered up, so I am careful to have the HGB3 plugged in before turning the mount on, without exception. I still find the location source on local when I know that I had set it to GPS. I did hope that the changes in HBG3 firmware to allow "fake GPS" for a fixed location and also NTP for immediate time synch (when internet is available) would help, but I still see this happening. I am using a StarSense HC, by the way.

[mlord]

I just re-tested GPS detection with my own SSAA camera and HC plugged in.  It has no issue finding the HBG3 GPS at start-up, even when I try and make it fail by entering bad WiFi credentials for "Access Point" mode (which can slow some things down).

 

Case closed here.

[mlord]

There's a new v8.43 OTA Firmware Update binary now available for the HBG3 and AIO projects:

 

Version 8.43 2024-04-03

 -- New boolean var to reverse ALT direction of Nunchuck:  nchuck.reverse.alt
Version 8.42 2024-04-02
  -- Never turn off GPS; instead let it run and update it's almanac etc..
Version 8.41 2024-04-02
 -- Get rid of oled_off_updatefn().
  -- New oled.timeout.secs variable, for auto-blanking the OLED. Default 60 seconds.
 -- Rename various OLED/Button related identifiers for easier comprehension.

 

Cheers

Edited by mlord, 03 April 2024 - 02:33 PM.

[MarkEHansen]

I just had a chance to update my HBG3 to version 8.43 and it is awesome. The device is in my living room where it would normally take a few minutes to get a GPS lock, but now, when I switch on the mount the GPS is locked in before I can press the HBG3 button to get to the GPS status page.

 

Great work Mark!

[MarkEHansen]

I'm no longer able to get to my HBG3 using Access Point mode. The OLED shows the correct SSID but shows 0.0.0.0 for the IP.
Does the updating of the firmware lose the passphrase?

 

I'm trying various way to connect to the unit, but so far, no luck. I'll keep trying.

[MarkEHansen]

I just connected using Direct Connect and am able to see the settings. The wlan.ssid and wlan.passkey values are still there and are correct. However, when I power the unit in AP mode, it is not connecting.

 

This started after I updated to the 8.43 firmware.

 

Any ideas?

[mlord]

Check your WiFi router.  Mine periodically has issues with 2.4GHz devices, and a router restart takes care of it.

[MarkEHansen]

Okay, I'll try that. However, I do see from my dhcp logs that the machine is requesting and getting an IP address.

I tried it again this morning and it worked straight out. I switched it off and after a 10 second delay, turned it back on and it was stuck with IP 0.0.0.0 again. I tried it again and it worked. It seems intermittent.

 

I'll try rebooting my WiFi mesh. Thanks,

[masi]

There's a new v8.43 OTA Firmware Update binary now available for the HBG3 and AIO projects:

 

Version 8.43 2024-04-03

 -- New boolean var to reverse ALT direction of Nunchuck:  nchuck.reverse.alt
Version 8.42 2024-04-02
  -- Never turn off GPS; instead let it run and update it's almanac etc..
Version 8.41 2024-04-02
 -- Get rid of oled_off_updatefn().
  -- New oled.timeout.secs variable, for auto-blanking the OLED. Default 60 seconds.
 -- Rename various OLED/Button related identifiers for easier comprehension.

Amazing, GPSFix within seconds, I love it.

 

Many thanks

[cyberduck]

When putting together my second HBG3 I managed to turn the button 90 degrees resulting in a perpetual reboot cycle. I desoldered the button and and soldered it back in the right position.

 

Unfortunately, I did not catch the issue before connecting it to the mount, and now neither the first nor the second HBG3 is able to to talk to the mount.

 

The mount works as expected with the HC and the Celestron WiFi accessory.

 

On connect with the HBG3 attached, SkyPortal tells me the following: "Celestron SkyPortal can make a connection to the scope, but the scope is not responding. Make sure it is connected and powered on. Also check that the scope type is correct". CPI essentially says the same thing.

 

I have tried to

• Power cycle the entire system
• Change the cable between HBG3 and the mount
• Use different sockets for the HBG3
• Disconnect all add-ons from the mount (SSAG, MotorFocuser) and the RPI, and QHY camera from the PocketPower Advance (gen 2) and only use HBG3 and SkyPortal/CPWI

... but still get the same result.

 

When boot the mount with both HC and HBG3, the HC  says "No Response 17". I also saw errors 6 and 7s but these were resolved by power cycling with only the HC connected.

 

I have connected the serial cable and am using the Arduino serial monitor. Found the help command, but would appreciate some assistance on debugging the issue... Any ideas?

[mlord]

There's no reason to even attempt WiFi or any other operation with the HBG3, unless one sees the THREE BLUE BLINKS shortly after power-on while connected to the mount.  If one does NOT see that, then immediately power off and disconnect the HBG3, as it will have a wiring or other issue.

 

In this case, it appears that something is damaged in the HBG3.

 

Most likely either the SMD 74HCT125 is damaged, or the ESP32 itself is damaged.  I'm betting on the ESP32, because the circuitry around the 74HCT125 is designed to prevent damage.

 

You can unplug the HBG3 from the mount, and never reconnect it -- to avoid damage to the mount.

Hook it up over USB/Serial to a PC, and connect over Serial to it at 115200 8N1.  Type help for a list of possible commands.

 

One of those commands is test_auxbus

It should normally give this information without any mount connection:

 

auxbus: Busy  test passed                                                                                      
auxbus: Tx/Rx test failed

 

The same test can be done plugged into AUX on the mount, but ONLY if there is NO POWER to the mount.  Just USB power to the HBG3.  The result is then likely to look like this:

 

auxbus: Busy  test failed   (might say passed, depends on the mount)
auxbus: Tx/Rx test passed

 

The important thing is that the Tx/Rx test should now PASS.  If not, then a chip is damaged on the HBG3.

Edited by mlord, 06 April 2024 - 03:21 PM.

[mlord]

Without trying it myself, I don't see how grounding D4 could damage anything.  Perhaps there's another error elsewhere in the assembly?

 

When the switch was wired wrong, was it on D4, or on a different signal?

Edited by mlord, 06 April 2024 - 03:10 PM.

[cyberduck]

On powering on, the only blue light blinking is that of the BE-180. The Arduino has a stable red light.

 

Without trying it myself, I don't see how grounding D4 could damage anything.  Perhaps there's another error elsewhere in the assembly?

 

When the switch was wired wrong, was it on D4, or on a different signal?

Remember, I am using two HBG3, one known to be working (#1) prior to connecting the second one (#2) where the button was not assembled correctly. Assembly #1 runs v8.39 and assembly #2 runs v8.43. I have tried both versions on both assemblies.

 

I would say that is very unlikely that #1 has a hardware error related to how it was assembled, given that it was working previously. Assembly #2 was wired to D4, shorting D4 with GND on the Arduino side and shorting SW to GND on the HBG3 PCB side.

 

Both assemblies produce the same output when prodded with the test_auxbus command.

 

HBG3 unconnected to mount

00:05:32.753 -> auxbus: Busy  test passed
00:05:33.022 -> auxbus: Tx/Rx test failed

HBG3 connected to mount (powered off)

00:06:34.749 -> auxbus: 1: BusyIn not HIGH when BusyOut tri-stated
00:06:34.891 -> auxbus: 1: BusyIn not HIGH when BusyOut HIGH
00:06:34.891 -> auxbus: 2: BusyIn not HIGH when BusyOut tri-stated
00:06:34.891 -> auxbus: 2: BusyIn not HIGH when BusyOut HIGH
00:06:34.891 -> auxbus: Busy  test failed
00:06:35.034 -> auxbus: Tx/Rx test failed

According to what you say, this would indicate that there a chip is broken on both assemblies, is that not a little implausible? What would make #1 break after having connected #2?

 

The only things that they share (besides me assembling them) is the cable and the mount. I made a new cable to replace the old one with the same result. What remains, is the mount.

 

However, the mount seems fine, not just no longer working with HBG3. Could it be that the mount has entered in a state that is somehow not compatible with HBG3?

 

EDIT: using a recent Celestron AVX mount.

Edited by cyberduck, 06 April 2024 - 05:58 PM.

[mlord]

Both assemblies produce the same output when prodded with the test_auxbus command.

HBG3 connected to mount (powered off)

..
00:06:35.034 -> auxbus: Tx/Rx test failed

According to what you say, this would indicate that there a chip is broken on both assemblies, is that not a little implausible? What would make #1 break after having connected #2?

Identical incorrect assembly of both modules could.   Or if both were plugged in together, and the broken one harmed the first one.  Bad cabling could also cause the failure.

 

The Tx/Rx test is rather simple.  It sends bits out the Tx pin, and checks if they are received on the Rx pin.  When NOT connected to a mount, this should never work.  But inside the mount, at the RJ12 AUX connector(s), Rx/Tx are hardwired together.  So the Tx/Rx test must always pass when plugged into an un-powered mount.  There is no reason for it to fail, except when there is a hardware fault in the HBG3, or its cable.

 

When I say un-powered, I mean NO POWER CONNECTED to the mount, even if the mount is switched off.  Unplug the power cable completely.

Edited by mlord, 06 April 2024 - 09:01 PM.

[mlord]

Does that same port on the mount, where the HBG3 was connected, still work now with the hand-controller plugged in there ?

[cyberduck]

I redid the tests with no power to the mount; previously I had the power cable attached but with the mount OFF. Also made sure to test things in a more systematic fashion. These are my findings:

• HC works with the HC and all AUX ports.
• RX/TX test passes for without any other device attached for the HC and all AUX ports.
• RX/TX test passes for all device combinations with power CONNECTED and ON.
• RX/TX test fails for any combination that includes the Motor Focuser and with the mount OFF or DISCONNECTED.

Tests made with both assemblies with identical results. The last finding explains why the tests were failing last night.

 

Even though the tests pass with power ON, SkyPortal claims that it cannot communicate with the mount though the wireless connection works.

 

 

This is the HBG3 output when making the connection with SkyPortal:

12:03:52.122 -> 000166272 w2000 Connected
12:03:52.698 -> routing[4]: SW (20) on w2000_rx
12:03:53.105 -> routing[4]: SW (20) removed from w2000_rx
12:03:53.105 -> 000167233 w2000 Disconnected

One thing that strikes me, is that when powering on the HBG3 the output seems to indicate that HBG3 thinks it is communicating with an AZ mount, or at least this is how I interpret the GET_VERSION lines produced when the units are powered on:

12:07:33.427 -> wifi_begin_server_mode
12:07:33.427 -> esp32_wifi ON, softAP, ssid=HomeBrew-DF7AB0, passkey=
12:07:42.924 -> esp32_wifi OFF
12:07:42.924 -> GPS detected.
12:07:42.924 -> esp32_wifi ON, Client mode
12:07:42.924 -> wifi_begin_client_mode:
12:07:42.924 -> GPS baud 38400.
12:07:42.924 -> bus_loop: auxbus_tx is alive
12:07:42.924 -> 000002784 auxbus_tx: auxtest: 3b 03 e2 10 fe 0d 			[HBG3   -> AZM   ] GET_VERSION
12:07:42.924 -> 
12:07:42.924 -> WiFi connected to QMB6-LAB, IP address: 192.168.5.123
12:07:42.924 -> 000003796 auxbus_tx: auxtest: 3b 03 e2 10 fe 0d 			[HBG3   -> AZM   ] GET_VERSION
[Last line repeated 12 times]

Given that I have an AVX EQ mount and that the last part of the SkyPortal error message says "Also check that your scope type is correct.", could the problem be that HBG3 somehow thinks this is an Alt-Azimuth and is reporting that to SkyPortal?

[mlord]

Even though the tests pass with power ON, SkyPortal claims that it cannot communicate with the mount though the wireless connection works.

Again, there is ZERO point in attempting anything else unless the HBG3 shows THREE BLUE BLINKs at startup.

Those blinks are an active AUX bus test, communicating with the mount, and if it fails, nothing else will work either.

 

With the mount connected, and powered, there should be THREE BLUE BLINKs as the HBG3 powers up.

No point in attempting WiFi, Nunchuck, or any other mount accesses unless one gets the THREE BLUE BLINKs.

 

 

The test_auxbus command has another component, the BUSY test.  Is that also passing?

 

 

And remember.. THREE BLUE BLINKS!!!

If one does NOT see that, then immediately power off and disconnect the HBG3, as it will have a wiring fault or other issue.

Edited by mlord, 07 April 2024 - 08:04 AM.

[mlord]

One can tell from that output that it is NOT showing the very important THREE BLUE BLINKS.  So power off and disconnect the HBG3 before anything else is damaged.

12:07:42.924 -> bus_loop: auxbus_tx is alive
12:07:42.924 -> 000002784 auxbus_tx: auxtest: 3b 03 e2 10 fe 0d 			[HBG3   -> AZM   ] GET_VERSION
..
12:07:42.924 -> 000003796 auxbus_tx: auxtest: 3b 03 e2 10 fe 0d 			[HBG3   -> AZM   ] GET_VERSION
[Last line repeated 12 times]

Note that Celestron terminology for the two motors in the mount is always AZM/ALT, even for EQ mounts where one might expect RA/DEC instead.

 

The timestamps at left are generated by the Arduino IDE and are not accurate.  The 9-digit numbers to the right of those are the REAL timestamps from the ESP32, in milliseconds.  And those correctly show the two auxtest message attempts being 1-second apart from each other.

 

Interesting that the Tx/Rx test (aka. "bus_loop") passes, but the device is still unable to communicate with the mount.  The only way that can happen, is if the BUSY line is not functioning (the test_auxbus output should show a failed Busy test).  Earlier you showed that test failing:

00:06:34.749 -> auxbus: 1: BusyIn not HIGH when BusyOut tri-stated
00:06:34.891 -> auxbus: 1: BusyIn not HIGH when BusyOut HIGH

So.. something could be wrong with the BUSYIN signal, which is connected to pin D35 on the ESP32.

 

 

Or, if the HC still does not work with the HBG3 plugged in, then the BUSYOUT signal (D32) is likely to be stuck "on" (LOW).  That would cause both the HBG3 and the HC to not work.

Edited by mlord, 07 April 2024 - 08:46 AM.

[mlord]

[updated schematic and comments above]

 

.. if the HC still does not work with the HBG3 plugged in, then the BUSYOUT signal (D32) is likely to be stuck "on" (LOW).  That would cause both the HBG3 and the HC to not work.

Test for this, by disconnecting the HBG3 from the mount.  Power it over USB.  On the serial/debug monitor, enter the 't' command once, to stop it from doing the built-in auxtest, leaving the AUX side "idle".

 

Now, check the voltage on D32 of the ESP32.  It should read +3.3V (HIGH) at idle.   If D32 reads 0.0V (LOW), then it is broken.  We can work around that if need be, re-routing a different GPIO for BUSYOUT, and changing the firmware to match.  Wait for further advice if this appears to be the case!

 

If D32 correctly shows +3.3V, then something else is wrong.  So measure the voltage on D35 (BUSYIN) now.  This should read +2.7V¹ or higher (HIGH) when idle.  If not, then something is wrong either with the 74HCT125 chip, or in the mount itself.  But if it correctly reads HIGH, then the fault is in the ESP32.  And again, this can be worked around.

 

¹ +2.7V with USB power only; +3.3V when powered from the mount.

Edited by mlord, 07 April 2024 - 11:01 AM.

[mlord]

HBG3 unconnected to mount

00:05:32.753 -> auxbus: Busy  test passed
00:05:33.022 -> auxbus: Tx/Rx test failed

HBG3 connected to mount (powered off)

00:06:34.749 -> auxbus: 1: BusyIn not HIGH when BusyOut tri-stated
00:06:34.891 -> auxbus: 1: BusyIn not HIGH when BusyOut HIGH
00:06:34.891 -> auxbus: 2: BusyIn not HIGH when BusyOut tri-stated
00:06:34.891 -> auxbus: 2: BusyIn not HIGH when BusyOut HIGH
00:06:34.891 -> auxbus: Busy  test failed
00:06:35.034 -> auxbus: Tx/Rx test failed

Back to this now.  The behaviour of the BusyIn test when connected to an unpowered mount can upon the mount.

 

But when connected and powered-on at the mount, with no HC or other accessories connected, the BusyIn test should PASS.  If it passes when not connected (as shown at top), but then fails when connected and the mount powered-on, then something is broken at the mount.

 

So you could now try that test (powered from the mount, no accessories, no HC) and post the results here.

This may explain how both HBG3 devices suddenly went "bad".

[cyberduck]

OK, got the point on three blue blinks. :-)

 

The blue LED blinks once when connected and powering on the mount.  Same for both HBG3 assemblies. I have disconnected the mount from external power and disconnected all accessories.

 

Output of test_auxbus HBG3 unconnected to the mount

auxbus: Busy  test passed
auxbus: Tx/Rx test failed

Output of test_auxbus HBG3 connected to mount with extrnal power DISCONNECTED

auxbus: 1: BusyIn not HIGH when BusyOut tri-stated
auxbus: 1: BusyIn not HIGH when BusyOut HIGH
auxbus: 2: BusyIn not HIGH when BusyOut tri-stated
auxbus: 2: BusyIn not HIGH when BusyOut HIGH
auxbus: Busy  test failed
auxbus: Tx/Rx test passed

Same behaviour for both HBG3 assembly #1 and #2.

 

The test_auxbus command has another component, the BUSY test.  Is that also passing?

From the previous tests (when the mount was CONNECTED and ON) the BUSY test was mostly failing but did pass some of the time. 

 

With HBG3 attached to the mount when power is DISCONNECTED, the BUSY test fails consistently as shown above.

 

So.. something is wrong with the BUSYIN signal, which is connected to pin D35 on the ESP32.

I hear you, but I still think it is weird that both HBG3 assemblies fail in the same way, in particular when #1 was known to work before.

 

Does this not point to a problem with the mount?

 

On the other hand, the Celestron WiFi accessory still seems to work fine. I have not done extensive testing, but SkyPortal is able to connect and I can slew using the app. Same for the HC.

 

Is there a way I can test the BUSY and BUSY in lines using a multitool for measuring voltage, current or resistance?

 

EDIT: added a note that there are were no accessories connected for the test above.

Edited by cyberduck, 07 April 2024 - 09:14 AM.

[cyberduck]

Sorry, did not see your last posts. Will read through and come back.

[mlord]

Without trying it myself, I don't see how grounding D4 could damage anything.

And.. back to this now .  I did try it myself, and one can permanently ground D4 without any lasting ill effects.  Everything works normally, including the THREE BLUE BLINKS, the Nunchuck, the mount hand-controller, etc..  All that doesn't work, is the button itself for managing the OLED display.

 

Oh, and the HBG3 will self-reset every 5-seconds when that button (D4) is held in while the main status display is being shown, so it also does that when the button (D4) is permanently grounded.
 

So whatever is wrong, it likely has nothing to do with the button being miswired, UNLESS it was miswired to a pad other than D4.  Note that the SW pad on the purple HBG3 PCB is not actually connected to anything on that PCB.

 

EDIT: Or.. if one had the hand-controller also connected while the HBG3 was repeatedly being reset, then I'm not sure what might happen, because the outputs of the HBG3 are not controlled while it resets.  The very first thing it does AFTER reset, is program the outputs correctly.  Normally this happens while the hand-controller is dealing with the same type of issue itself.

 

I will update the firmware to detect the situation where D4 is permanently LOW, and have the HBG3 simply ignore it -- no more 5-second resets when that is the case.

Edited by mlord, 07 April 2024 - 09:31 AM.