2152 replies to this topic

[eleven]

Hi Mark,

 

I found an issue with my wiring after I observed the unexpected behavior.  I'm going to test it again this weekend.  I will let you know if I run into this issue again.  Thanks...

[mlord]

This morning I had the weirdest thing happen.. my various HBG3 units were connecting to the home WiFi in Access Point mode, but not really working..  losing packets like crazy.

 

After an initial panic where I thought perhaps the faster I2C speeds actually were messing up the WiFi again, that theory was disproved when the problem persisted after reverting to older firmware.

 

Then.. I simply rebooted the home WiFi router.   All good again.

Nothing to do with the HBG3, just something had gone screwy on the 2.4GHz band here.

 

Cheers

[SieglindeFestkochend]

This morning I had the weirdest thing happen.. my various HBG3 units were connecting to the home WiFi in Access Point mode, but not really working..  losing packets like crazy.

 

After an initial panic where I thought perhaps the faster I2C speeds actually were messing up the WiFi again, that theory was disproved when the problem persisted after reverting to older firmware.

 

Then.. I simply rebooted the home WiFi router.   All good again.

Nothing to do with the HBG3, just something had gone screwy on the 2.4GHz band here.

 

Cheers

Okay, that's reassuring if the "error" lies somewhere else entirely. But you also doubt yourself a little when it's that easy, right?

 

I spent (many years ago) quite a long time fiddling with a workstation (at a university) that simply wouldn't run. Screen remained black. Tried everything possible, maintenance from the server... In the end the brightness of the monitor was set to zero. That's it.

Edited by SieglindeFestkochend, 07 January 2024 - 09:21 AM.

[mlord]

Firmware version v8.35 is now available for this project:  hbg3.ino.v8.35.txt   297.64KB   15 downloads

• Fix NTP dates by using gmtime_r() instead of buggy local calculations.
• Change default "dew0.amps" (informational-only) setting from 1.8 to 1.7, matching Celestrons 8" Dew Ring.
• Enable use of opcode names with the "send" command.  Eg.  send GPS GET_YEAR
• Tweaks and tidying to opcode name printing.
• Fix fake Focus Motor calibration to persist across reset/power cycles.
• Get rid of "focus.calibrated" variable: focus.limits does same job.
• Revamp Focus Motor Calibration screen.
• Enable forcing a temporary ota_update_path on the command line for "ota_update" (also skips version check).

EVERYONE using a Celestron hand-controller must update, because of the bug-fix for NTP dates, which affects GPS.  Sources and binaries are all now available in the usual locations.

 

EDIT: Stay tuned for v8.36 -- NTP/GPS has a second issue..

 

Cheers

Edited by mlord, 07 January 2024 - 10:31 PM.

[mlord]

Firmware version v8.36 is now available for this project:  hbg3.ino.v8.36.txt   297.74KB   18 downloads

• Fix NTP year formatting for transfer to a Celestron hand-controller.

The earlier v8.35 fixed Network Time Protocol (NTP) so that it got correct dates again, but still had a bug in how it passed the 2-byte YEAR to the Celestron hand-controllers.. giving them invalid dates still.  FIXED!

 

Sources and binaries in all of the usual places.

 

If you use the GPS feature with your HBG3, then you MUST update for it to work properly again!

Edited by mlord, 08 January 2024 - 08:44 AM.

[hope1]

Hi all! I procured a HBG3 and wanted to provide some feedback of my own and share a message from mlord as well.

 

First, I wasn't expecting a consumer level product but my experience with HBG3 has been great and I would describe it as a plug and play product suitable for both novices and experts. The biggest challenge really was to come up with a contraption to tidy up all those wires. So far I have been using its USB, WIFI, GPS connectivity as well as its Focuser and CPWI interoperability and been impressed overall. One thing I have noticed is that WIFI simply tends to cut off if you rotate the mount such that the HBG3 ends up being eclipsed by the rotating OTA. For that reason I recommend always using USB.

 

It's cold out there at night and I am happy to say the HBG3 allows me to now work in a cozy warm room while I capture images. 

 

For those of you using the Focus motor feature (and using home-made focus motor assemblies) here is a copy of Mark's response to my question regarding initialization of the position of the focus motor, as I think many of you will have the same question:

 

> hi Mark, I've started using CPWI to haphazardly control the focus motor and wanted to ask where CPWI assumes where the initial position of the focus knob should be? I assume CPWI is completely unaware of the focus position when it starts up....

Mark's Response:

CPWI reads the current position from the Focus Motor itself.
If you are using a stepper motor attached to a HBG3,
then the initial position is always reported as 30000.

.. Unless you have wired up an FRAM module to keep track of position
across power-cycles, in which case it will be more accurate.

 

To add to this, if you end up reaching the maximum value of 44000 for the position and you still need to continue rotating, you can power cycle the HBG3, which will reset the current position to 30000 and allow you to continue rotating the knob without firmware-imposed restrictions (until you happen to reach 44000 again).

 

I did come up with a holder for the HBG3 which secures it next to the OTA. There seems to be a caveat with doing this, as I noticed it is taking a little longer to get a GPS lock, presumably because of interference caused by the OTA being in close proximity...something to beware of when you are trying to decide a suitable location to secure the HBG3. 

 

Keep up the great work!

[mlord]

if you end up reaching the maximum value of 44000 for the position and you still need to continue rotating, you can power cycle the HBG3, which will reset the current position to 30000 and allow you to continue rotating the knob without firmware-imposed restrictions (until you happen to reach 44000 again).

The HBG3 Focus Motor does not have a limit of 44000.  The usable range is identical to the Celestron Focus Motor, and runs from 0..60000, and even this can be broadened with a focus.factor setting (search earlier in this discussion).

 

After doing a Focus Motor "Calibration", those limits may be reduced, depending upon how much travel one permits as part of the Calibration cycle.  Or one can force the full range with a couple of commands on the Serial/Telnet interface:

 

   set focus.limits 0 60000

   save

   reset

 

But rather than typing in those commands, just run a (FAKE) calibration from SkyPortal, SkySafari, or CPWI.  That won't actually do anything, other than set that variable above.

 

The HBG3 Stepper Motor implementation has a "Calibration" sequence available now from the OLED and push-button.  Just follow the instructions there to set a real (not FAKE) suitable movement range.

 

And wire in an FRAM module so that the Calibration limits become more meaningful.  The FRAM is used to continuously save the motor position, which survives from one session to the next.  So the system always knows where the motor is, and can enforce the Calibration limits correctly.   Without FRAM, it always assumes a starting point of 30000.

 

FRAM modules connect with just 4-wires to the same pins (in parallel) as the OLED display.

None of this is new information.  It has all appeared in this thread already in the past.

 

Cheers

Edited by mlord, 08 January 2024 - 08:48 AM.

[Zoroastro]

Hi Mark - can a HBG3 module manage both a dew heater and the focus motor in parallel?

[mlord]

Hi Mark - can a HBG3 module manage both a dew heater and the focus motor in parallel?

Yes, no problem.

 

But note that the HBG3-Relay currently can not do Dew Control at all, because of pin conflicts.

That will change with the next firmware release!

[mlord]

Announcing v8.37 of the firmware for the HBG3 and HBG3-Relay:  hbg3.ino.v8.37.txt   299.73KB   23 downloads

• New "dew.force.enabled" boolean variable to enable Dew Control even without a SHT3x sensor being present.
• Select different thermistor_pins[] and dew_pwm_pins[] when AUXRELAY is wired.
• Disable Dew Channel-1 if no pins are available for it, due to conflicts with Ethernet, Host-USB, or Stepper motor.

Yes, this one is all about making Dew Control more accessible. One can now use it in pure Manual PWM mode if no SHT30/SHT31 sensor is wired up, by setting dew.force.enabled to true in NVRAM.

 

It is also now possible to have at least one channel of Dew Control on the HBG3-Relay.  The established pins unfortunately conflict with the Relay, so the HBG3-Relay will have to use different pins than usual for PWM and the Thermistor(s).

 

If there are no conflicts (see below), the HBG3-Relay can have two channels of Dew Control, otherwise only one channel.

 

The regular HBG3 continues to use pins 34,39 for thermistors, and pins 14,26 for PWM output.

The HBG3-Relay now uses pins 36,39 for thermistors, and pins 12,18 for PWM output.

 

If Ethernet, Host-USB, or a Stepper (focus) motor is wired, then only the first Dew channel will work on the HBG3-Relay, due to conflicts with pin 18.  There are no other possible pins remaining.

Edited by mlord, 08 January 2024 - 06:24 PM.

[hope1]

I'm currently on FW 8.14 right now which is what the HBG3 came with. Is there any reason I need to update? (I regularly use GPS, USB-CPWI, Focus motor, and would like to use WiFi if there are any connectivity improvements there)

[mlord]

I'm currently on FW 8.14 right now which is what the HBG3 came with. Is there any reason I need to update?

Yes, please update immediately.  It's so easy to do, and risk-free as well.  No mount required.  Just connect the HBG3 to your home WiFi (use SkyPortal or CPWI to configure that, if not already done), and use the OLED and push-button to perform the update.  Unlike Celestron products, the HBG3 is impossible to "brick" from a firmware update.

 

The release notes are extensive, and include several many bug fixes and improvements since 8.14.

 

Thanks!
 

Edited by mlord, 09 January 2024 - 11:03 PM.

[hope1]

I followed the instructions for binary flashing as stated in https://rtr.ca/hbg3/flashing/ 

 

Everything seemed to go as planned and I got the "FINISH" message at the end. But, I still see 8.14 as the FW version number when I power up the HBG3.

 

I downloaded the binary from https://rtr.ca/hbg3/...shing/hbg3.bin 

 

I guess the first thing to check is whether the bin file at this link is up-to-date?

[Astro Andy]

I used the bin with both the flash tool and web serial terminal.

 

If your HBG3 connects to your home network use the OLED switcher button to OTA update.

[mlord]

I followed the instructions for binary flashing as stated in https://rtr.ca/hbg3/flashing/

I believe the time has come for me to nuke that stuff entirely.  I don't understand why anyone would use that, rather than the simple, built-in OTA Firmware Update on the HBG3 itself.  How puzzling that people still do it the very hard way!

 

I just checked right now the hbg3.bin file at the link provided, and it has HBG3 v8.37 by Mark Lord inside, not v8.14.  So not only is that flashing method MUCH more difficult, it appears to somehow also be error-prone.  So don't use it if the device already has v8.1 or later installed!

 

For any version of the HBG3 that does have v8.1 or newer already installed, connect it to your home WiFi (or a mobile phone hot-spot) instead -- the SkyPortal app has a menu for "configuring Access Point" mode.  Use that, or use a serial port or telnet connection to enter the commands manually.  See this link, which is also on the HBG3 web page:  https://www.cloudyni...8#entry12939791

And also this link:  https://www.cloudyni...6#entry13084984

 

Cheers

Edited by mlord, 10 January 2024 - 08:10 AM.

[Astro Andy]

Mark, the bin file is a super easy way to 'first flash' the ESP32 for those that have never messed with Arduino IDE before. If disk space is an issue (my Surface Pro 3 with 64GB storage and Raspberry Pi) then grabbing the bin file is perfect, opposed to grabbing the portable pre-built IDE. 

 

If it is too much additional effort then that is understandable and something we would have to live with. Your efforts are really appreciated.

 

Cheers.

[hope1]

Ok just tried the OTA update successfully:

The reason I opted for the less user friendly USB update method earlier is because the case I have made for the HBG3 does not expose that little push button that needs to be pressed a couple of times to get to the FW update screen. 

 

As advertised, the OTA  (over the air) update went smoothly through the access point. It paused at around 15% progress and I resolved this by rotating the OTA (optical tube assembly) to a new position which continued the update successfully to finish as it was able to reestablish contact with the access point.

 

It's great that it was able to continue from where it left off after losing contact with the Access Point for around a minute.

[dewo]

The reason I opted for the less user friendly USB update method earlier is because the case I have made for the HBG3 does not expose that little push button that needs to be pressed a couple of times to get to the FW update screen. 

This is also why I don't use the OTA update functionality. I haven't yet implemented the push button and modified my case (and I edit the code to change the default screen). I also haven't added the resistor for focuser selection. I don't even have access to the switches with my case. So I just hardcode those changes every release, easier than redesigning my 3D printed case, doing the soldering work, etc. I do have an FRAM on the way though, so an overhaul is coming soon. It'll be nice to be able to use the OTA functionality!

[dlwmacgregor]

This is also why I don't use the OTA update functionality. I haven't yet implemented the push button and modified my case (and I edit the code to change the default screen). I also haven't added the resistor for focuser selection. I don't even have access to the switches with my case. So I just hardcode those changes every release, easier than redesigning my 3D printed case, doing the soldering work, etc. I do have an FRAM on the way though, so an overhaul is coming soon. It'll be nice to be able to use the OTA functionality!

Would you mind sharing a picture of your case with the Group?

Thanks.

[Rac19]

The reason I opted for the less user friendly USB update method earlier is because the case I have made for the HBG3 does not expose that little push button that needs to be pressed a couple of times to get to the FW update screen. 

You can login in via Telnet and use the command ota_update, no need to press the button. The telnet screen will report progress and completion/success. When using telnet, make sure that Echo and convert Cr to CrLf are turned on. For the Mocha Telenet client that I use, both are inexplicably turned off by default.

Edited by Rac19, 10 January 2024 - 07:12 PM.

[mlord]

It's great that it was able to continue from where it left off after losing contact with the Access Point for around a minute.

It survives just fine if you yank power from it midway, too.  Not the best thing to make a habit of, but these are impossible to brick during the OTA Firmware update, unlike with the Windows flasher method.

 

Cheers
 

[hope1]

I've been checking out v8.37 of the firmware for improvements. The GPS appears to be much more reliable and faster in locking now: Whereas before this update (from version 8.14 in my case) it could take minutes for GPS to become "Ready", now it appears to be available immediately after power up, even indoors!??!

 

I also tried to check for improvements in Wifi Connectivity as well:

 

-Direct Connect seems to work - I've only done basic testing so far on it.

 

-But, based on Mark's comment a while ago (quoted below), I assume Access Point mode should simply work, as long as CPWI and HBG3 are on the same network. Thus far, I have never been able to get Access Point mode to work with CPWI. I know that the HBG3 is indeed connected and within range of the access point because I did an OTA firmware update earlier today and even moved it closer to the AP. However, CPWI never connects successfully in AP mode. It simply spins endlessly as shown in the screenshot below, and eventually, a message appears saying it can't find any Celestron devices. Repeating results in the same message. Using latest CPWI version 2.5.2. Am I doing something wrong here?

 

 

The SkyPortal/SkySafari and/or CPWI all know how to find it automatically, so long as they're all on the same WiFi network.

 

Otherwise, it is shown on the OLED display, and also gets output on the serial/debug monitor when it first connects in "Access Point" mode.

 

In "Direct Connect" mode, the IP is always 1.2.3.4

 

 

Edited by hope1, 11 January 2024 - 12:22 AM.

[mlord]

Access Point mode works fine with CPWI, so yes you must be missing a PC firewall setting or something.

Try testing with telnet to port 3000 to verify your router isn't isolating clients from each other.

[hope1]

Access Point mode works fine with CPWI, so yes you must be missing a PC firewall setting or something.

Try testing with telnet to port 3000 to verify your router isn't isolating clients from each other.

It's definitely a problem with my windows PC and CPWI. I had to install it on 2 more systems before finding one that works and confirmed functionality. CPWI really feels like a work in progress so far!

[mlord]

It's definitely a problem with my windows PC and CPWI. I had to install it on 2 more systems before finding one that works and confirmed functionality. CPWI really feels like a work in progress so far!

More likely it's the (Windows?) operating system blocking the UDP port 55555 broadcasts.

You can narrow this down by using  telnet from one of the non-functioning PCs, to first see if it can access the HBG3 command interface on port 3000.  If that works, next try the AUX interface on port 2000 -- you won't see any data there, but we're really only checking that the connection to 2000 is possible.

 

If both of those work, then most likely the UDP 55555 broadcasts are being blocked.  Those are "advertisement" packets sent out by the HBG3 (or a Celestron WiFi adapter) to let CPWI and SKyPortal etc.. know where to find the device on the network.

 

Cheers