2122 replies to this topic

[Frisk]

CFM doesn't have anything to do with HBG3 , correct Mark?

[mlord]

Quick Q, but can we confirm for certainty which CFM version for the SS HC is the latest one that won't brick the Homebrew GPS?

Nothing I know of will ever "brick" the HomeBrew GPS, so I'm not sure what that question is about(??).

 

Note that one should always disconnect any non-Celestron accessories before attempting to update any of their firmware.

 

The HBG3 takes some precautions to try and prevent attempts to run CFM through an HBG3, and those precautions will be further improved in the next release.  But this is all for protection of the Celestron branded stuff, not the HBG3 itself!

 

EDIT:  There was some discussion earlier in this thread about the SSHC possibly taking issue with the presence of an HBG3, but that turned out to be false.  The real issue was a bad AUX port connector on the mount.

Edited by mlord, 16 August 2023 - 08:04 PM.

[Frapeno]

It was great to meet up in person, François!  Looking forward to next time.  And thank-you for taking the final HomeBrew Gen3d device off my hands.  I'm sure you and the local club there will find uses for it.

 

Which brings me to this now:

 

Gen3e_PCB.jpg

 

The new Gen3e PCBs arrived while I was away, so I have hurriedly assembled one to test, and am happy to report that it works!     I posted about them earlier in this thread, with the main new feature being that there is now a dedicated set of I2C holes for directly mounting a 0.96" OLED display, with the 3V3 and GND signals also now in the order preferred by most such displays.

 

The OLED attaches very easily, and is far enough "forward" to not block the WiFi/BT antenna area.

 

Happy! 

Hi Mlord, nice work adding oled display, how do it in current item I just got success yesterday ?
I tried to figure out the pin connection as photos I saw here, but did not work, I have same display 

[Frapeno]

Hi Mlord, nice work adding oled display, how do it in current item I just got success yesterday ?
I tried to figure out the pin connection as photos I saw here, but did not work, I have same display 

Oh sorry, now after twice turned off the circuit , now worked , very nice display features

[Frapeno]

Nothing I know of will ever "brick" the HomeBrew GPS, so I'm not sure what that question is about(??).

 

Note that one should always disconnect any non-Celestron accessories before attempting to update any of their firmware.

 

The HBG3 takes some precautions to try and prevent attempts to run CFM through an HBG3, and those precautions will be further improved in the next release.  But this is all for protection of the Celestron branded stuff, not the HBG3 itself!

 

EDIT:  There was some discussion earlier in this thread about the SSHC possibly taking issue with the presence of an HBG3, but that turned out to be false.  The real issue was a bad AUX port connector on the mount.

Hi mlord, i don't know if I missed something, but GPS takes hour ( 1h30 - 2h ) to get GPS data, is it normal ?? or something wrong in my circuit ?
I kept running and randomly I check if Display show up SATs qty, some time is like this... (00/09), (05/10)..., but no Longitude / Latitude data show up.
After long time running, then show up all data,
If turn Off and On again, then issues repeat and I have to wait hours to see data on display.
 

[mlord]

It should take under 2 minutes in open-sky, with the GPS antenna facing the sky.

[dlwmacgregor]

Note that if you are "testing" it indoors it can take a few mnutes to "lock" the GPS.

[jproehl]

Note that if you are "testing" it indoors it can take a few mnutes to "lock" the GPS.

Also note that if your testing indoors and you have a metal roof it can take a very long time (if ever) to get any GPS signal.

 

In addition, most GPS boards have a small battery to allow them to remember where their last position fix. If your board has been sitting around, that battery may be dead.

Edited by jproehl, 17 August 2023 - 12:11 PM.

[mlord]

Hi mlord, i don't know if I missed something, but GPS takes hour ( 1h30 - 2h ) to get GPS data,

Could you post a photo of the unit, showing the GPS portion?

I just want to see which style of GPS receiver it has.

 

Thanks

[Frapeno]

Could you post a photo of the unit, showing the GPS portion?

I just want to see which style of GPS receiver it has.

 

Thanks

Hi guys, thanks for helpful informations, below more details after your comments

- Yes I am using indoor because leave in apartment, but have reasonable open area to  see the sky.

- Yesterday when set data I also checked battery voltage, it was 2v but today morning checked again it is now 0v.

- Attached photo of GPS module

- So, i will find a way to replace this battery and try again

[Frapeno]

Hi guys, thanks for helpful informations, below more details after your comments

- Yes I am using indoor because leave in apartment, but have reasonable open area to  see the sky.

- Yesterday when set data I also checked battery voltage, it was 2v but today morning checked again it is now 0v.

- Attached photo of GPS module

- So, i will find a way to replace this battery and try again

Attached Thumbnails

• 

[mlord]

The "battery" is usually a "super capacitor", and how long it holds a charge will vary.  So probably okay as-is.

 

The quality of GPS modules does vary.  The BE-180 is currently the "best" one in the 18mm form factor, closely followed by the impressive BN-180.

 

Cheers

[Frapeno]

The "battery" is usually a "super capacitor", and how long it holds a charge will vary.  So probably okay as-is.

 

The quality of GPS modules does vary.  The BE-180 is currently the "best" one in the 18mm form factor, closely followed by the impressive BN-180.

 

Cheers

Ok i will provide a better GPS module, maybe this one I have is not good, thanks

[firemachine69]

Nothing I know of will ever "brick" the HomeBrew GPS, so I'm not sure what that question is about(??).

 

Note that one should always disconnect any non-Celestron accessories before attempting to update any of their firmware.

 

The HBG3 takes some precautions to try and prevent attempts to run CFM through an HBG3, and those precautions will be further improved in the next release.  But this is all for protection of the Celestron branded stuff, not the HBG3 itself!

 

EDIT:  There was some discussion earlier in this thread about the SSHC possibly taking issue with the presence of an HBG3, but that turned out to be false.  The real issue was a bad AUX port connector on the mount.

 

 

Sorry, badly worded on my part. Both my HBG's don't work on my Evolution. If I don't plug in either one (not at the same time, obviously), my mount behaves "normally" excluding all the other gaffs in the HC firmware. 

 

My "original" HBG I received (the one with the physical on/off WiFi switch) now gives me error 17 on my CGEM mount since the last CFM update. It also completely freezes up my Evolution mount on boot at the Application Init please wait, never had problems with it there before the last two updates. I tested various ports, and the results are consistent. 

 

My HBG3 now freezes my Evolution mount on the same Application Init please wait. Curiously enough, it runs fine on my CGEM, at least the GPS portion that I could see yesterday afternoon.

 

If you're wondering, I was tentatively updating my firmwares in anticipation of the Celestron dew heater I planned on buying, before I realized it was a big stinky pile, and the SSAG (which I've decided against after all). 

Edited by firemachine69, 17 August 2023 - 09:44 PM.

[Frisk]

When my HBG3 wasn't making proper contact I got the same error on my i-Series mount. Did you try a new cable? Straightening the pins on your Evolution port?

You aren't clear on what recent updates - to the HBG3 or the Evolution or the HC?

Edited by Frisk, 18 August 2023 - 05:20 AM.

[mlord]

My "original" HBG I received (the one with the physical on/off WiFi switch) now gives me error 17 on my CGEM mount since the last CFM update. It also completely freezes up my Evolution mount on boot at the Application Init please wait, never had problems with it there before the last two updates. I tested various ports, and the results are consistent. 

 

My HBG3 now freezes my Evolution mount on the same Application Init please wait. Curiously enough, it runs fine on my CGEM, at least the GPS portion that I could see yesterday afternoon.

How odd.  There is literally NOTHING that CFM or a firmware-update can do that will harm the HBG3.  I have two Evolution mounts here (one older, one newer) that all HBG3s I make get tested on, with both types of hand-controllers (Nexstar+ and StarSense) running the latest available firmware from Celestron.

 

I don't remember the history of your HBG3, whether it was a self-build or one I assembled, or even which version it is.  But all of the PCB based designs (since December 2022) have the same identical circuit and firmware, so specific PCB revisions have no effect on compatibility.

 

Note that the HBG3 firmware must be at least v7.7 now -- anything older has known bugs that might cause issues.

 

Are you sure that there's not a different issue with either of those mounts?  Earlier in this thread you can see where one person thought the HBG3 had issues, but it turned out to be a stuck pin inside one of the AUX connectors on the mount.

[firemachine69]

How odd.  There is literally NOTHING that CFM or a firmware-update can do that will harm the HBG3.  I have two Evolution mounts here (one older, one newer) that all HBG3s I make get tested on, with both types of hand-controllers (Nexstar+ and StarSense) running the latest available firmware from Celestron.

 

I don't remember the history of your HBG3, whether it was a self-build or one I assembled, or even which version it is.  But all of the PCB based designs (since December 2022) have the same identical circuit and firmware, so specific PCB revisions have no effect on compatibility.

 

Note that the HBG3 firmware must be at least v7.7 now -- anything older has known bugs that might cause issues.

 

Are you sure that there's not a different issue with either of those mounts?  Earlier in this thread you can see where one person thought the HBG3 had issues, but it turned out to be a stuck pin inside one of the AUX connectors on the mount.

 

 

I'm not sure about harming the HBG3, just that either HBG isn't playing nice with the Evolution mount. I'll have to check the HBG3 firmware. But curiously I'm not having issues with the HBG3 on the CGEM mount (after the last CFM update on the CGEM bricked my mount and caused me to pull out my hair for hours). I am wondering if I've got a MC board issue on the Evolution because errors are so intermittent, and once last week I turned on the power switch and got... Nothing. Classic sign the board is on its way out AFAIK. But that shouldn't have anything to do with the controller hanging up on Init once the board is fired up. 

 

I am now at the point in my life I regret not completing my college studies for electronics design and repair. 

Edited by firemachine69, 18 August 2023 - 09:07 AM.

[mlord]

The power switch on the Evolution is known to be flaky some of the time.  I bricked my Evo flicking the switch off/on/off/on to get it to work one day -- caused power spikes or something.  Replaced the switch (and repaired the Evo main board), and all has been good since then.

[mlord]

Here is v7.8 of the Arduino ESP32 Source Code for this project:  hbg3.ino.v7.8.txt   213.96KB   31 downloads

• Tidy up MUSB/RF-Kill status on OLED.
• Get rid of setTxBufferSize() calls: default buffering is adequate.
• Enforce full blocking of packets from CFM.
• Reduce AUXBUS_PKT_MAX to 16 from 32, matching reality and using considerably less RAM.

The flashable binary and pre-packaged .ZIP/.TGZ files have also been updated at https://rtr.ca/hbg3/

There is no particular need for anyone to update to this version just yet. Most of the small changes were to free up additional memory, giving more margin for complex set-ups -- especially for the AUX Relay functionality. That said, it does help with development if at least a few people would update to v7.8 regardless, as that means more than just me is doing the testing!

Cheers

Edited by mlord, 18 August 2023 - 06:57 PM.

[mlord]

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

[dlwmacgregor]

I'm OK with leaving it in CPWI's "hands".

 

I know they buggered this up in the past but it seems that the fix they implemented has worked.

[Zoroastro]

Battery monitoring?

[mlord]

Battery monitoring?

For the Evolution mount, sure.  That's a good idea, easy enough to do.

[mlord]

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.

 

I'm OK with leaving it in CPWI's "hands".

I know they buggered this up in the past but it seems that the fix they implemented has worked.

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".

Edited by mlord, 19 August 2023 - 01:36 PM.

[mlord]

Okay, that works. 

 

The HBG3 v7.8+ firmware will now automatically "fix" CPWI sending bad MC_POLL_CORDWRAP commands.  This also prevents it from accidently enabling CORDWRAP as a consequence of the bad commands.

 

Edited by mlord, 19 August 2023 - 02:39 PM.