2035 replies to this topic

[Rac19]

Great to hear!  So not a complete write-off of my efforts to provide it.

 

Perhaps it has something to do with the type/version of Bluetooth transceiver in the PC, then.  My 2023 AMD Ryzen Mini-PC here with up-to-date Win11-Pro only gets CPWI connecting once in a blue moon or so now.  Very modern Bluetooth chip there though.

 

My older Win10 Dell laptop used to work fine with it, but didn't when I briefly tried it the other day.  Will try again.  I also have an older USB Bluetooth transceiver, which Win11 does not support.  Win10 supports it, so perhaps I'll try that too.

 

EDIT: No luck for me with v8.13, or with the beta versions of CPWI up to 2.5.5-beta4.  They DO actually "connect", send two bytes for a Nexstar+ hand-controller, and then disconnect again..  I'll play with that handshake and see if anything can be done.

 

The Celestron Focuser Utility connects just fine over the Bluetooth connection though, and works the focus motor without issue.
 

I was going to try the latest CPWI Beta but I won't do so now as it doesn't seem to fix the problem. I am running HBG3 v8.25 under Windows 10 on an oldish Intel NUC. Bluetooth connectivity isn't an urgent issue for me but I would like to get it working  I will give up on it for now, until there is a possible HBG3 fix to try out.

 

As per the CPWI log, there does seem to be a slight difference in the interaction with the "Outgoing" (Com 7) and "Incoming" (Com 8) Bluetooth ports. If I allow CPWI to try both, it attempts to connect to Com 8.

 

When I connect through Com 3 (the Celestron Focuser USB Bridge), CPWI discovers the HBG3 GPS and reads the location coordinates from it. This indicates to me that HBG3 is communicating successfully on the Aux bus. In fact, prior to mini USB port being damaged, the CPWI was able to connect via HBG3 USB but I didn't give it much of a workout.

Edited by Rac19, 12 December 2023 - 04:14 PM.

[mlord]

I'm looking at it.  It appears that CPWI Bluetooth now needs the HBG3 to briefly emulate a hand-controller, and get through the associated handshakes for that..

 

EDIT:  Yup, got it working here.  Yay!!

 

CPWI appears to REALLY want to talk to a "hand controller" and tell it to go into "bootloader mode", and then set its baud rate to 19200.  Bluetooth doesn't have "baud rates", but we can pretend to easily enough. 

 

Needs tidying.  Might release it later this week.  Here's what the comms looks like:

 

16:36:15.078 -> BT: CONNECTED mode 0
16:36:15.145 -> rx 56     <<< 'V'

16:36:15.178 -> rx 8a     <<< "Enter bootloader mode"

 

16:36:15.178 -> TX fa
16:36:15.443 -> TX fa
16:36:15.676 -> TX fa
16:36:15.942 -> TX fa
16:36:16.174 -> TX fa
16:36:16.440 -> TX fa

16:36:16.705 -> TX fa

 

16:36:16.938 -> rx 0a     <<< 10-byte command to set baud rate to 19200
16:36:16.938 -> rx 00
16:36:16.938 -> rx 02
16:36:16.938 -> rx 08
16:36:16.938 -> rx 00
16:36:16.938 -> rx 4b
16:36:16.938 -> rx 00
16:36:16.938 -> rx 00
16:36:16.938 -> rx d0
16:36:16.938 -> rx c0

 

16:36:17.502 -> rx 3b     <<< AUX protocol begins

 

16:36:17.502 -> 000121447     bt_rx: 3b 03 20 10 fe cf                [SW     -> AZM   ] GET_VERSION
16:36:17.502 -> 000121458 auxbus_tx: 3b 03 20 10 fe cf                [SW     -> AZM   ] GET_VERSION
16:36:17.535 -> 000121465 auxbus_rx: 3b 07 10 20 fe 07 11 00 62 51    [AZM    -> SW    ] Version: 7.17.0098
16:36:17.535 -> 000121474     bt_tx: 3b 07 10 20 fe 07 11 00 62 51    [AZM    -> SW    ] Version: 7.17.0098
16:36:17.602 -> 000121545     bt_rx: 3b 03 20 11 fe ce                [SW     -> ALT   ] GET_VERSION

...

Edited by mlord, 12 December 2023 - 04:44 PM.

[Rac19]

Re post #977. I did notice how, when talking to Com 7, CPWI looked for an HC and wanted to set it to passthrough mode. I think that I had used CPWI connected through Com 3 (Celestron Focuser USB Bridge) without an HC plugged in. It may be that once CPWI detects a "USB Bridge", it doesn't worry about the HC.

 

CFM actually reports finding the USB Bridge and it is always the first device reported. Later this morning, I will check the precise wording, I think that it is either " USB Bridge" or "USBBridge", most likely the former.

 

EDIT: Actually, I am certain the I have routinely connected via the USB without an HC plugged in.

Edited by Rac19, 12 December 2023 - 05:18 PM.

[mlord]

I've noticed that CPWI still sends the "hand-controller" commands even on a USB-Bridge.  But it doesn't seem to care whether or not there's a response to them.  On Bluetooth, it now seems to care.

[Rac19]

For what it's worth the current CFM devices list is quoted below. It's probably not important but I had to disable Com 7 and Com 8 in the Device Manager to get CFM to successfully discover Aux devices through Com 3.

 

 

 

USB Bridge   on Link: SERIAL using portal: COM3

StarSense HC   on Link: USB using portal: StarSense_HC
App version = 1.22.22307 

Evolution   on Link: USB using portal: Motor_Controller
App version = 7.17.98 

Focuser   on Link: USB using portal: Motorized_Focuser
App version = 7.16.9300 

StarSense Accessory Camera   on Link: USB using portal: SSA_Camera
App version = 1.2.13343

[Rac19]

Re post #980 it would seem that CFM tried to find Aux devices on Com 7 and locked it up. To disable Com 7 after running CFM, the PC had to be restarted, which is not normal.

 

The best thing is probably to disconnect HBG3 or to disable both Bluetooth com ports before running CFM.

[Rac19]

NEVER EVER RUN CFM OVER A HBG3 CONNECTION!!!!

That wasn't what I intended to do but I guess CFM saw the Bluetooth Com 7 port before it detected Com 3 (USB Bridge) and used it. It seems that you really need to disable the Bluetooth Com ports before starting CFM. Intending Bluetooth users should probably be warned about this.

 

With the Bluetooth Com ports disabled, CFM found the Aux bus on Com 3 (USB Bridge) and listed all attached Aux devices except the HBG3 GPS. When CPWI connects via Com 3, it discovers the HBG3 GPS and reads the location coordinates from it.

 

I did a firmware update (via Com 3) while I was there, only to find that with the latest firmware CPWI 2.5.2.99 connects to the mount then immediately crashes. CPWI 2.5.3 Beta 2 (the latest beta that I could find) seems to maintain a connection stable. It's weird for a Beta version to be more stable than the official release.

Edited by Rac19, 12 December 2023 - 08:52 PM.

[Rac19]

CPWI appears to REALLY want to talk to a "hand controller" and tell it to go into "bootloader mode", and then set its baud rate to 19200.  Bluetooth doesn't have "baud rates", but we can pretend to easily enough. 

Hope once CPWI thinks the non-existent HC is in pass-through mode at desired speed it will not bother trying to do anything else with it (the HC).

 

As for CFM, the only option might be to disable the Bluetooth Com ports prior to running it. Even with the HGB3 disconnected, I think that the Bluetooth Com ports are visible in the Device Manager. I will give it a try when I get a chance. There was no harm done by the way, no chance of even thinking about a firmware upgrade, in fact that option remained disabled in CFM.

[mlord]

For CFM, the RECOMMENDED and REQUIRED option, is to disconnect any HomeBrew devices from the mount prior to powering on and then running CFM.  Anything else is too risky.

[Rac19]

For CFM, the RECOMMENDED and REQUIRED option, is to disconnect any HomeBrew devices from the mount prior to powering on and then running CFM.  Anything else is too risky.

As per post #985, I will reduce my input but the Bluetooth ports in relation to CFM seem to present a particular challenge.

 

Even with the HBG3 disconnected, the Bluetooth Com ports remain visible in the Device Manger and CFM still attempts to connect them and fails, So I think that even after unplugging the HBG3, it is necessary to disable the any Bluetooth Com ports. It may depend on the order in which the Com ports are listed in the Device Manager. In my case it is Com 7, Com 8 then Com 3 and I can't find a way to change the order, even after uninstalling them all and adding them back in the desired order.

 

CFM latches on to Com 7 and gets no further. Temporarily disabling Com 7 and Com 8 seems to be then only solution. A problem unique to Windows, maybe.

[mlord]

CPWI and Bluetooth:

 

After a lot of effort looking into the CPWI/Bluetooth issue, here are the results:

1. The issue seems to revolve around the use of the bt.connected() library function.  This was not used prior to v8.12.
2. Firmware versions prior to v8.12 probably all work fine.  Somehow they don't confuse CPWI.
3. Newer versions that call bt.connected() result in the HBG3 code seeing CPWI's attempts to handshake with a Celestron hand-controller, which is what it assumes the HBG3 is on Bluetooth.  CPWI is then unhappy that the HBG3 doesn't respond to hand-controller commands.
4. I have now implemented code that manages the handshake, and this works fine with CPWI.

But.. why not just revert back to NOT using the bt.connected() call?

This was actually the plan today, and the code was rearranged for such.  But in testing, it was observed that the MS-Windows "experience" is more seamless when bt.connected() is called than otherwise.  The RFCOMM fake serial devices appear more quickly, without having to monitor Windows Device Manager before connecting.  Pairing seems faster too, most of the time.

 

I have no idea why this is the case -- this is all happening at multiple library and operating system layers below the HBG3 application code.  But the newer code, with the appropriate handshaking added for CPWI, does seem to work better than the older stuff.  The only glitch I have seen, is that once in a while (twice over about 50 connects), MS-Windows has randomly popped up a "pairing" window for no obvious reason.  The older code has different and more severe glitches than that from time to time.

 

So, I'm planning to go with the new handshaking code in the next release.  It has been tested it on the AIO as well as on the HBG3, including making sure it doesn't mess up the other Bluetooth modes and apps, and everything seems quite happy with it now.

 

User ScopeWizard has tried it on his set-up (thanks!) and reports consistent success connecting CPWI over Bluetooth.  If anyone else wants to give it a try in advance of a formal release, let me know -- it is possible to update to this test version using OTA Firmware Update after changing one setting on the HBG3.

 

EDIT:  Oh, and a note about Rac19's CFM saga.  Those posts are "off topic" in the quantity that has appeared here.  But since I'm writing about Bluetooth, the way to avoid those issues is to simply un-pair the HBG3, and unplug it from the mount, before running CFM.  Easy-peasy!    Ditto for any other Bluetooth serial devices one might be using.

Edited by mlord, 13 December 2023 - 03:39 PM.

[mlord]

The mount and I were out in the cold this evening, my first outing in weeks, and the second time the SSAG has been put to a test.  I'm pleased to report that everything worked like a charm this time, including the Smart Dew Controller!

 

About 40-minutes into the session, I shone a light at the corrector lens, and saw dew forming around the edges.  So I used the push-button on the HBG3 to knock up the "aggression" on Auto to +15C (overkill!).  The lens gradually cleared over the next 20-minutes, after which I cranked it back down, eventually to +7C, and left it there for the rest of the session.

 

 

The lens remained completely clear throughout, so I probably could have set it even lower.  I periodically took a glance at the display, and most of the time the heater was OFF, but sometimes on again, varying from 21% to 48% as needed.  Nice!

 

The entire session was again managed using Bluetooth to my Android tablet, running SkySafari 6+.  No glitches, the single session stayed up the entire time out there, including when I left Saturn in the eyepiece while going inside for dinner and a show.  Back out after an hour, and Saturn was still there, a bit off-centre, and the tablet was still happily running the show.

 

I do want to capture some message traces from the SSAG though, so on Thursday (sky permitting) I'll repeat this, but also try to simultaneously connect over WiFi from my PC in the office for tracing things.  Should be interesting!

 

The session was powered from the Evolution's built-in battery, along with an external DeWalt 5AH pack that charged the mount and powered the dew-heater.  It still showed 3/3 bars at the end of the 4-hours, despite a lot of slewing around to about 30 different objects.

Edited by mlord, 13 December 2023 - 11:21 PM.

[fdboucher]

The mount and I were out in the cold this evening, my first outing in weeks, and the second time the SSAG has been put to a test.  I'm pleased to report that everything worked like a charm this time, including the Smart Dew Controller!

Yay! 

I am amazed by the thermistor controller… The dew point is even reported! I have to try it.

Did you get to try out your Celestron motor focuser during that session?

Thanks again, Mark, for a fantastic gizmo…

Edited by fdboucher, 14 December 2023 - 10:12 AM.

[mlord]

Did you get to try out your Celestron motor focuser during that session?

No, I don't actually use a Focus Motor myself.  I just implement it for others to play with.

 

On a related note, could everyone perhaps STOP quoting my entire posts every time one replies to something?  Just edit it down to the relevant parts, if any.  Like I just did here (above).  That'll make this discussion thread shorter and easier for others to read and find information within.

 

Thanks.

 

I do realize that the mobile version of the site unfortunately defaults to quoting EVERYTHING, but one can still fix that before posting.

Edited by mlord, 14 December 2023 - 09:30 AM.

[mlord]

I am amazed by the thermistor controller… The dew point is even reported! I have to try it.

Here it is connected via Bluetooth to CPWI:

 

 

Those charts are all from communicating with the HBG3 Smart Dew Controller, which emulates the Celestron 2X Controller.

 

Oddly, one thing that CPWI does NOT show is the temperature at the thermistor sensor.  I didn't see that in the protocol either, so perhaps it is simply "local" to the Dew Controller hardware.    I'll have another look though, and see if it's something that can be passed along to CPWI or not.

Edited by mlord, 14 December 2023 - 11:16 AM.

[mlord]

Version v8.26 of the HBG3 firmware is now available:  hbg3.ino.v8.26.txt   272.1KB   27 downloads

• Bluetooth: Make debug easier: [always] keep WiFi on when musb.rfenable is 1.
• Bluetooth: New 'b' command to toggle Bluetooth debug on/off.
• Bluetooth: Don't forward AUX packets to BT until handshake is completed.
• Bluetooth: Show BT-Handshake state on OLED and status command.
• Bluetooth: Add trickery for initial handshake needed by CPWI.
• Disable both AUX buses and free up their RAM during OTA updates.

As one can see, this version gets Bluetooth working again with CPWI on MS-Windows.

There's also more information reported on the OLED display while CPWI is trying to connect.

 

I find that the MS-Win-11-Pro that I have here can still be a tiny bit fussy from time to time on pairing, but other than that it works very well.  CPWI now connects more quickly and reliably than before.  Let us know here if that's not the case for you, but do fiddle with the operating system a bit first, before blaming the HBG3! 

 

Binaries are in all of the usual places, and the HBG3_Arduino IDE bundles have now been updated too.

 

Cheers

Edited by mlord, 14 December 2023 - 11:12 AM.

[Rac19]

v8.26 Bluetooth , Thanks Mark.

 

NOTE:

For the reason described below it seems best to configure CPWI to ignore the "Incoming" port and to use only the "Outgoing" port.

 

It seems that after CPWI finds all the Celestron accessories that it can on the first Com port it detects (Com 7 in my case), if it hasn't found everything it needs to, it will search any further Com ports that it can detect (Com 8 in my case) for the remaining Celestron accessories. Because Com 8 is an "Incoming" port, CPWI gets stuck on it. It should be possible to configure CPWI to ignore selected accessories but at the moment there doesn't seem to be an option to skip SSAG.

Attached Thumbnails

• 

Edited by Rac19, 15 December 2023 - 04:53 AM.

[scopewizard]

v8.26 Bluetooth , Thanks Mark.

 

NOTE:

For the reason described below it seems best to configure CPWI to ignore the "Incoming" port and to use only the "Outgoing" port.

 

It seems that after CPWI finds all the Celestron accessories that it can on the first Com port it detects (Com 7 in my case), if it hasn't found everything it needs to, it will search any further Com ports that it can detect (Com 8 in my case) for the remaining Celestron accessories. Because Com 8 is an "Incoming" port, CPWI gets stuck on it. It should be possible to configure CPWI to ignore selected accessories but at the moment there doesn't seem to be an option to skip SSAG.

You should be able to set this in "CPWI/Settings/More settings", goto "Ignored accessories"  "Starsense" and set it to on (orange color).

Make sure that "Support for multiple connections" (first line at the top) is set to "off".

Close CPWI and restart.

[Rac19]

Re posts #993 and #994. I am using CPWI 2.5.3 Beta 2, at the moment, which supports StarSense AutoGuide (SSAG) but doesn't yet have provision to ignore SSAG, I assume that this will get fixed before too long.

 

A simple way to force CPWI to use a particular Com port is to tell it to ignore all ports but the one that you want it to use. That's what I have been doing anyway.

 

Also, when using Bluetooth, I think that it it IS probably best to tell CPWI to ignore the "Incoming" port as it (CPWI) always gets stuck when it tries to connect to it.

[dlwmacgregor]

Support For  Multiple Connections?

It might be a future feature for multiple mounts at the same time for those who are lucky enough to have that big of a setup?

Just spitballing.

[Rac19]

By the way, my original complaint about the SkySync GPS being hopelessly slow might have a little unfair. Things don't seem to be much better with HBG3, the big difference being that the OLED screen at least provides some useful in formation, it's not a total black box like SkySync.

 

It will sit there for hours displaying 0/0 satellites or 0/17 (for example). I get the impression it that as soon as at least one satellite is detected but not necessarily "acquired" (0/1 satellites), UTC is available. Is it correct that HBG3 will then pass the time to the HC along with the last known/saved location coordinates, so that it no longer displays "waiting for GPS".

 

Just why I see 0/0 satellites for such long periods is a mystery. I have moved the HBG3 around to get a clearer view of satellites etc. Neither the GPS in my car nor my golf GPS are as troublesome. Perhaps there is a GPS black spot in my backyard.

[Rac19]

Current CPWI versions available here...

 

http://software.cele...nstallers/CPWI/

That's odd, Team Celestron seems to be a couple of versions behind.

[mlord]

CPWI also has a setting for "support for multiple connections".  I have that disabled (the default), because I have no idea what it does.  The release notes don't say anything about it, other than that the option was added in Feb/2023. 

Sorted that.  "Support For Multiple Connections" simply means that CPWI will search all of the (enabled) COM ports, not stopping when it finds the mount.  The idea is that a Focuser, or Dew Controller, or other accessory might be plugged in separately from the main mount connection.  So CPWI keeps looking to find any of those "standalone" devices on other ports.

 

I have observed this now, with both an HBG3 and and HBG3-Relay plugged to the mount.  CPWI establishes the main (bluetooth) connection to one of them, but later opens the second HBG3 (bluetooth there too) to search for a Focus Motor and Dew Controller.  As stated, one can just tell CPWI not to look for them, and one can also turn off "Support For Multiple Connections" in the latest versions from Feb/2023 onward.

 

Now it's me that's getting off-topic -- this really is NOT the correct thread to be discussing CPWI features and versions, so please take that elsewhere.  Thank-you.

Edited by mlord, 15 December 2023 - 10:46 AM.

[Rac19]

This is a snippet from the  CPWI log. It definitely seems that once it got what it could from Com 7, it when on to Com 8, and got stuck there, possibly because it didn't find SSAG on Com 7. I can't see the logic in this. Who would intentionally have two serial links to a mount at the same time?

 

 

 

2023-12-15 19:19:41.718 +11:00 [Connection_Tasks1#5] (Connection) StarSense AutoGuider NOT Found
2023-12-15 19:19:41.735 +11:00 [Connection_Tasks1#5] (Connection) Searching for StarSense Accessory
2023-12-15 19:19:41.790 +11:00 [Connection_Tasks1#5] (StarSenseService) StarSense found with version 1.2.13343
2023-12-15 19:19:41.867 +11:00 [Connection_Tasks1#5] (StarSenseService) StarSense center calibration is 699, 611
2023-12-15 19:19:41.867 +11:00 [Connection_Tasks1#5] (Connection) StarSense Accessory Found
2023-12-15 19:19:41.882 +11:00 [Connection_Tasks1#5] (Connection) Successfully connected via COM7
2023-12-15 19:19:41.882 +11:00 [Connection_Tasks1#5] (Connection) Attempting to open port COM8
2023-12-15 19:19:41.882 +11:00 [Connection_Tasks1#5] (Connection) If a hand-controller is present on port COM8, putting it into passthrough mode now.
2023-12-15 19:19:41.882 +11:00 [Connection_Tasks1#5] (Connection) Opening COM8 to attempt version command

[Astro Andy]

This is a snippet from the  CPWI log...

You don't fancy starting a new thread for this topic and keeping Mark's thread for HBG3 Dev do you?

 

I get that the HBG3 is involved but the most is CPWI, Windows Bluetooth and COM ports. A summarisation of the end result posted here would be great so everyone knows.

 

Would be much appreciated. Cheers.