1540 replies to this topic

[scopewizard]

Mark,

 

When I select   #define EMULATE_SSAA to false in HBG3 - v8.48,  it breaks the sketch.

 

It appears to be the only one.

I know, I could leave it to true but figured you should know.

 

HBG3 - v8.46, working fine with EMULATE_SSAA set to false.

Edited by scopewizard, 16 June 2024 - 03:16 PM.

[mlord]

 select   #define EMULATE_SSAA to false in HBG3 - v8.48,  it breaks the sketch.

Thanks!  Appears to be a brace bracket around line 6962 that should be AFTER the #endif instead of before it.  Fixed for the next release.

 

[scopewizard]

It is line 6938, I fixed it, works fine.

[mimmo]

There's room for one more character on those lines, so I could add a space after the degrees, which may make it a bit more readable.  Here's the updated version: hbg3.ino.txt

 

Note:  When replying to a post immediately above, it is rarely necessary to quote the previous message, and NEVER necessary to quote an ENTIRE message.  If one must quote a message, please EDIT it down to the bare minimum needed.  Following this basic netiquette helps keep the discussion thread more readable.  Thanks.

Hi Marco, wow already edited......excellent
I have already uploaded the beta of 8.48 and I'm testing it.
Sorry what are the lines you rewrote. I would like to eliminate a space so that the first letter of lat and lon can be read better.
Thank you

[mlord]

The OLED display for GPS is at oled_gps_updatefn() in the code, around line 5464.

[mlord]

Firmware version v8.49 is now available for the HBG3 and All-In-One projects:   hbg3.ino.v8.49.txt   321.95KB   18 downloads

• Show GPS coordinates as DDD° MM'SS.ss" C, similar to Celestron hand-controller displays.
• Fix build when EMULATE_SSAA is false.
• Set default ETHERNET_ENABLED back to true, for benefit of hbg3-aio builds.

Binaries and source code are available now in all of the usual places, including for the (recommended) built-in Over-The-Air (OTA) Firmware Update mechanism.

 

Cheers

 

[mlord]

The DHL guy dropped off a new batch of PCBs here today, so I promptly set about building a new HBG3-Relay from a couple of them, just to test that the batch is all good and functional.

 

Everything worked, and I plugged in my favourite red Nunchuck for the final test.. not detected.  Huh?  Tried the blue Nunchuck instead, no problem all good.  HUH?  Back to the red one, no worky.

 

Very tempting to just leave it at that.. after all, the blue one works! 

 

But.. no, not good enough.  So I removed the Nunchuck connector and all of the solder around it, and installed another new Nunchuck socket in its place.  All good now, both the red and blue Nunchucks work fine.

 

Are you puzzled yet?  I was.. briefly.

 

My theory is that perhaps a bit of stray solder contacted one of the two middle pins of the connector, shorting it to one of the large nearby ground pads.  One of those two pins is an I2C address select pin, not normally used.  But if shorted to GND, the Nunchuck is supposed to respond to a different I2C address than the default address.  This is how a Nintendo game box can have two Nunchucks without any extra internal wiring or GPIOs required.

 

Along with this, I suspect the blue Nunchuck I have simply ignores the address pin, but the red one actually respects it and changed I2C address because of that.

 

What I ought to do now, is deliberately short the address pin on an HBG3 and verify that the red and blue Nunchucks behave as theorized above.  And perhaps have the HBG3 firmware try both addresses for fun!

 

EDIT:  Nope.  So much for that theory. 

Tried tying the address select pin both high and then low (via a 220-ohm resistor), and neither caused the red Nunchuck any issue.  So.. still a bit of a mystery as to what the original problem was.

Edited by mlord, 17 June 2024 - 07:54 PM.

[mimmo]

Hi Mark, sorry, as you will notice from the OLED photo, the words on the left, I would like to move them one space to the right. I found the part of the code concerning the OLED, but I don't want to mess things up. Could you please tell me how to change.
Thank you

 

[mlord]

Which OLED model is that?  The code does have a way to work with a few OLEDs other than the recommended one.  But the recommended one is best.  If yours is one of the other types the code knows about, then a simple setting may help it to work.

 

Blue is the worst colour choice for an OLED, because once one adds a red filter for astronomy use, all of the blue light is blocked.

 

Cheers

[mlord]

You can try this setting from the serial port, and see if it corrects the display:

 

set oled.type SH1106_128x64

save

reset

[mimmo]

Which OLED model is that?  The code does have a way to work with a few OLEDs other than the recommended one.  But the recommended one is best.  If yours is one of the other types the code knows about, then a simple setting may help it to work.

 

Blue is the worst colour choice for an OLED, because once one adds a red filter for astronomy use, all of the blue light is blocked.

 

Cheers

1.3" OLED Display Module 1.3 inch Module White/Blue 128X64SPI/IIC I2C
I will try to make the change you suggest.

[mimmo]

You can try this setting from the serial port, and see if it corrects the display:

 

set oled.type SH1106_128x64

save

reset

both in version 8.48b and in version 8.49 the setting is already SH1106_128x64

[scopewizard]

both in version 8.48b and in version 8.49 the setting is already SH1106_128x64

If you are doing the install with Arduino

In Version 8.48 and 8.49, go to line 5161 make sure it shows "oled_types[0].oled;", edit [0] to [2]

 

static const DevType *oled_type = oled_types[2].oled;

Edited by scopewizard, 18 June 2024 - 03:12 PM.

[mlord]

If you are doing the install with Arduino

In Version 8.48 and 8.49, go to line 5161 make sure it shows "oled_types[0].oled;", edit [0] to [2]

Don't do that!  Bad advice -- gets wiped out next time one updates the firmware.

Instead, use the oled.type setting as already described.

[mlord]

both in version 8.48b and in version 8.49 the setting is already SH1106_128x64

Well, that must mean that your OLED is NOT that type.  So just clear the setting instead:

 

set oled.type

save

reset

[scopewizard]

Mark,

 

I tried CPWI 2.5.6 beta1

 

Setting the wifi access fails as it lacks the direct access name.

It now shows name and password for access and direct mode, yes both. 

It will not connect to enter anything.

 

I am sure this feature will stay in the future.

[mlord]

CPWI 2.5.6 beta1

Setting the wifi access fails as it lacks the direct access name.

It now shows name and password for access and direct mode, yes both.

Not really an issue.  I can connect just fine with CPWI-2.5.6-beta1 in both Access Point and Direct Connect modes.  And the HBG3 has always supported softap.passkey (unlike Celestron dongles).  But CPWI even has a checkbox to say "disable passphrase" for their own dongles.

 

The part that isn't wasn't working is the Settings --> WiFi WLAN Config screen of CPWI-2.5.6-beta1, which is used only for one-time configuration of Access Point mode of the dongle, prior to switching from Direct Connect mode.  This part is now asking the WiFi dongle for its MAC address.  Which is odd.. because it already knows the MAC address from the UDP broadcast packets.  Otherwise it would never get as far as it already does.

 

Okay, fine.  They can be stupid about it if they want to be, I suppose. 

 

Here is HBG3 firmware v8.50 with support for the "get wlan.mac" command from CPWI:  hbg3.ino.v8.50.txt   322.31KB   11 downloads

 

This version enables the current CPWI 2.5.6-beta1 to proceed to the Settings --> WiFi WLAN Config screen, where it (CPWI) has another bug and shows the wrong softap.ssid field value, hardcoding it as "Celestron-XXX" instead of querying it from the adapter.  That will probably break compatibility with older Celestron SkyQLink stuff as well.     But one can simply edit that field to match the dongle, if desired.

 

Binaries for v8.50 are now available via the OTA Firmware Update mechanism.  The source code archives have also been updated.

 

Cheers

Edited by mlord, 19 June 2024 - 07:47 AM.

[scopewizard]

Mark,

 

It now shows "Celestron -xxx". I can enter a Passphrase for Direct Connect or not, it connects and works.

In trying to set Access Point, I can not enter the Network SSID, the cursor shows being at the start of the line but I can not type any character.

In the Network Passphrase line, it works fine.

 

Did you encounter this issue?

[mlord]

Remember, that Settings --> WiFi WLAN Config is only for use to configure the dongle for Access Point mode.  It is NOT used to actually "connect" to the dongle in either mode. 

 

Yes, I also notice that this beta CPWI does not enable typing anything into either of the SSID fields.  CPWI Bug.

 

Same behaviour with the Celestron-xxx WiFi of my Evolution mount.  Curiously, my _other_ Evolution mount, older style with SkyQLink-xx WiFi, doesn't work at all with Win11, so unable to test that with CPWI.

Edited by mlord, 19 June 2024 - 05:30 PM.

[mimmo]

Well, that must mean that your OLED is NOT that type.  So just clear the setting instead:

 

set oled.type

save

reset

Hi, I deleted what you told me from line 5159 version 8.49, but nothing changes. then I tried to replace sh1106 128x64 with adafruit 128x64, nothing changed here either.
ok, come on, we understand anyway.
Thank you

[mlord]

I plugged in my favourite red Nunchuck for the final test.. not detected.  Huh?  Tried the blue Nunchuck instead, no problem all good.  HUH?  Back to the red one, no worky.

That mystery may never be solved, but I did take a few minutes here today to sort out what the extra pin on the Nunchuck connector is for.

 

Some photos on the internet call it the "Detect" pin, and what I see inside each of three Nunchucks here is that the 3.3V power is simply looped back from the Nunchuck to that pin.  So, a wasteful engineer at Nintendo could hook that pin up to a dedicated GPIO pin at the processor, and poll it for "HIGH" to know whether a Nunchuck is currently connected or not.  Or use an interrupt pin on the processor to save the need for polling.

 

That's quite wasteful though, because it doesn't tell WHEN the Nunchuck was plugged in -- a short waiting period of perhaps 100msecs is required after that before the Nunchuck can be programmed and used.  So one still has to poll it over I2C and delay a bit more.  Since it has to be polled over I2C anyway, there's no practical use for a dedicated "Detect" pin, other than to avoid polling once every second or so when no Nunchuck is plugged in.

 

I'm sure they had a good committee-style reason for it though! 

 

I would instead have used it as an address select pin (an input to the Nunchuck), enabling TWO Nunchucks to share a common I2C bus, along with other stuff on the same bus.

Edited by mlord, 21 June 2024 - 11:47 AM.

[Rons_World]

Does anyone know if this HBG3 work with the ASIAIR?

 

And how would I do an EQ align? My alignments are all done with the HC.....

[mlord]

ASIAir does not support Celestron mounts natively -- it can only connect and control them through the Celestron hand-controller, not by any AUX port connection.  So, no, it doesn't work with Celestron WiFi, nor with the HBG3.

 

The HBG3 is just a communications intermediary, so EQ align is done whatever way one would normally do it.

Edited by mlord, 26 June 2024 - 08:57 AM.

[Rons_World]

ASIAir does not support Celestron mounts natively -- it can only connect and control them through the Celestron hand-controller, not by any AUX port connection.  So, no, it doesn't work with Celestron WiFi, nor with the HBG3.

 

The HBG3 is just a communications intermediary, so EQ align is done whatever way one would normally do it.

Ah ok, good to know.

[vtaDan]

My nunchuck has failed a few times now in an odd manner. It will work fine for a while then decide that no matter which direction I move the stick in Dec, it will move the scope north. Control input north => scope north, control input south => scope north... It's a cheapo, off-brand nunchuck from amazon so I won't be surprised if the problem is with it and I've ordered a new one. But I wanted to see if anyone else has seen this issue.

 

I've seen it a handful of times over the last couple months and with different versions of the HBG3 firmware. I don't recall which version I saw the issue under the first time.  I most recently saw it happen with the v8.50 firmware. One somewhat puzzling note: I was able to recover it one time by switching to focus control mode and back to slew control. In all other instances I had to cycle power on the mount to get it working again.  

Any thoughts?

Thanks!