2040 replies to this topic

[scopewizard]

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?

Mark is right, select the multiple connections in the CPWI settings. You need to plug SSAG in a USB and let CPWI find it.

 

I just bought a Celestron 9.25 EdgeHD a few days ago. Installed a Celestron motor focuser.

 

Celestron motor focuser is plugged only in a USB in minipc which is on top of scope, no Aux connection. CPWI finds the focuser if multiple connection is on.

 

Correction:

 

Issues: Multiple Connections on.

 

Port 3 and 4 showing in device manager and CPWI.

 

CPWI, in WIFI Access mode, connected to the mount, go to Settings, connected to focuser, everything works.

 

In BT mode, connected to the mount but kept searching com 3 for other devices.

 

In CPWI settings, set ignore Port 3.

 

Connected to the mount, focuser found, everything works.

Edited by scopewizard, 15 December 2023 - 01:15 PM.

[scopewizard]

#define WIFIRELAY_ENABLED                   false  // When false, code for wifi_relay_mode is omitted.
#define BLOCK_CFM_CONNECTIONS     true  // Set to false to allow CFM to attempt to interogate/update firmware (VERY RISKY!!). DO NOT DO THIS!!
#define NCHUCK_ENABLED                      false  // Enables use of a Nunchuck game controller on I2C for slew/focus.
#define OLED_ENABLED                           true  // When true, OLED support is included. Requires library: https://github.com/g...n/SSD1306Ascii/
#define OTA_ENABLED                              true  // When true, support is included for Over-The-Air (OTA) Firmware Updates
#define EMULATE_GPS                              true  // When true and GPS is attached, pretend to be a Celestron SkySync GPS receiver.
#define EMULATE_SSAA                            true  // When true, include code for StarSense AutoAlign  simulator. Can be turned on/off via NVRAM variable.
#define EMULATE_SSAG                           true  // When true, include code for StarSense AutoGuider simulator. Can be turned on/off via NVRAM variable.
#define EMULATE_DEW                            true  // When true and SHT3x is attached, pretend to be a Celestron 2X Smart Dew Heater Controller.
#define EMULATE_FOCUS                        true  // When true and stepper motor is wired, pretend to be a Celestron Focus Motor.

 

Before connecting,

 

In CPWI settings,

let say you have Com 3 and Com 4

Set Ignore Com 3

 

Connect BT

 

Mark, maybe this would help. HBG3 seem to need some kind of answer otherwise it keep trying.

Edited by scopewizard, 15 December 2023 - 02:07 PM.

[mlord]

Mark, maybe this would help. HBG3 seem to need some kind of answer otherwise it keep trying.

Sorry, I don't understand the question.  The HBG3 always responds as soon as it learns of a BT connection.
 

[scopewizard]

Sorry, I don't understand the question.  The HBG3 always responds as soon as it learns of a BT connection.
 

On my HBG3, I only select WIFI, BT and GPS. The only way for me to get the Celesron focuser in a USB mode only (no AUX connection) is to use the Multiple Connections in CPWI settings.

But when I do, it searches for others, i.e Starsense, Dew Heater and so...on . CPWI gets into a loop on other com ports. By selecting and loading the new sketch with the above settings in shown post #1002 and also setting the BT outgoing com port  to ignore in CPWI settings, everything works fine. My impression is that these EMULATE_SSAA   EMULATE_SSAG   EMULATE_DEW provide some kind of response as part of the AUX connection search. When I initiates a connection via BT, the focuser is found first then mount and GPS. I can see the search for the SSAA, SSAG and DEW on the AUX system, no com indication (like Searching...Com 3) . The search for a focuser show Searching...Com 9 for only a couple of seconds as the port is assigned to 9 in OS system. Even when these are set to be ignored in CPWI settings the search still takes place. This tells me that the settings are for AUX connected system only. HBG3 adds these when selected in the sketch and somehow a response of not connected is send to CPWI.

Edited by scopewizard, 15 December 2023 - 05:26 PM.

[mlord]

Those build options are "on" by default in standard HBG3 builds.  And they don't do ANYTHING AT ALL unless the relevant hardware is there for a Dew Controller and/or Stepper motor, or unless one enables the SSAA/SSAG "emulators" in the NVRAM variables.

Edited by mlord, 15 December 2023 - 08:46 PM.

[scopewizard]

Those build options are "on" by default in standard HBG3 builds.  And they don't do ANYTHING AT ALL unless the relevant hardware is there for a Dew Controller and/or Stepper motor, or unless one enables the SSAA/SSAG "emulators" in the NVRAM variables.

Looking at the code, in pkt_s *bus_get_next_txq_entry (struct bus_s *bus), if for example SSAG is set to true, the codes are loaded in HBG3. The packet would get processed  "ssag_handle_request(p->from_rxbuf, pdata);"

 

Nothing take place in that procedure but the final line of the code still send a reply "emulate_send_reply(rxbuf, reply, len);"

 

That might be enough for CPWI to take it as it exists but not working.

Edited by scopewizard, 15 December 2023 - 08:00 PM.

[scopewizard]

So far, I have done at least over a dozen BT connections no issue.

The focuser works in CPWI, connects with CPWI in NINA, and Sharpcap.

 

If it works, I'll leave it alone.

[mlord]

Looking at the code, in pkt_s *bus_get_next_txq_entry (struct bus_s *bus), if for example SSAG is set to true, the codes are loaded in HBG3. The packet would get processed  "ssag_handle_request(p->from_rxbuf, pdata);"

Again, that code does NOTHING unless you also do "set emulate.ssag 1" and then "save" and then "reset" to enable it in NVRAM.  Here is the code you found:

 

#if EMULATE_SSAG      // This is normally true in the regular HBG3 firmware builds by me
    if (EMULATING_SSAG && dst == DEV_SSAG) {
      ssag_handle_request(p->from_rxbuf, pdata);
      goto discard_txq_entry;
    }
#endif

 

And here is what EMULATING_SSAG expands to in that scenario:

 

#define EMULATING_SSAG emulate_ssag     // C/C++ treat uppercase/lowercase as DIFFERENT.

 

And here is where the value of emulate_ssag comes from:

 

emulate_ssag = nvram_get_bool("emulate.ssag");   // zero 0 unless one has set the variable to 1

 

If one hasn't changed the default for that NVRAM variable, it will be zero (aka. "false").

Then the earlier code block is actually this:

 

    if (0 && dst == DEV_SSAG) {     // or..  if (0) {
      ssag_handle_request(p->from_rxbuf, pdata);
      goto discard_txq_entry;
    }
 

That little 0 means the code DOES NOTHING, as I said earlier. 

The function then continues normally, and ends with:

 

    return p;

 

Which results in the packet being passed onto the AUX bus for a real SSAG (if present) to respond to.

 

Cheers

-ml

Edited by mlord, 15 December 2023 - 08:51 PM.

[mlord]

Now that the Bluetooth is working reliably with CPWI, and the skies have briefly cleared for a few hours each of the past three nights.. I've gotten some more testing done with the new SSAG camera that arrived a month ago.

 

It works fine with the HBG3 and HBG3-Relay, but attempting to capture message traces with the HBG3's built-in protocol analyzer has been troublesome when the SSAG has "Guiding" enabled.  Basically, the HBG3-Relay gets totally overrun and swamped by that.

 

So I've worked on a solution for it, and that is now humming away nicely here tonight.  What I have done, mainly for the benefit of the HBG3-Relay, is implement a "routing table" in the firmware.  So just like an internet router, the HBG3-Relay now learns which devices are on which bus or connection, and then forwards packets for them only to the link they are actually connected to.

 

This reduces the packet storms to a manageable level, making it possible to capture protocol traces of the SSAG Guiding in action. 

 

I'm sitting on the code for another day or two before release, but if anyone else wants to give it a try before then, and point out bugs to me.. just give the word!

 

Also forthcoming in the same release, is the ability to re-compile the firmware with working Ethernet support on the HBG3.  So if one wants to wire a Wiznet Ethernet adapter to the SPI pins of the HBG3, it will now work.

 

 

Cheers

Edited by mlord, 16 December 2023 - 03:49 PM.

[scopewizard]

Again, that code does NOTHING unless you also do "set emulate.ssag 1" and then "save" and then "reset" to enable it in NVRAM.  Here is the code you found:

 

Ok, that makes sense.

 

Thank Mark.

[Rac19]

Alternative GPS suggestion.

 

There are mobile phone Apps that can provide GPS location and time over Bluetooth (e.g. "Share GPS)". The advantage would be that mobile phone location data would be instantly available, no need to wait for the GPS chip to acquire satellites on power up.

 

As HBG3 already has Bluetooth and supplies GPS data to via an Aux port, it may not be too difficult to implement thus feature. Not for me to say of course.

 

Just a suggestion for future consideration.

[mlord]

There are mobile phone Apps that can provide GPS location and time ..

I recently spent about two days looking into that.  It all sounded nice and rosy to begin with, but turned out to be nigh impossible to use for our application.  The data exchange model was backwards of what we needed, or the apps were so complex to install and configure that nobody would use them.

 

So.. dropped for now.

 

I also then looked into having the HBG3 get Time from the internet -- really easy that part.  And then GeoLocation.. again, just about impossible without a paid monthly subscription to a GeoLocation service.  And not that accurate -- my location is off by 500Km+ on a lot of them.

 

It is possible for the HBG3 to directly download the entire ephemeris data set, for the USA GPS system at least.  But It is not in the data format required by the GPS modules, and it looked like a bit of effort to research exactly what they expect and how to convert it all.  If perhaps someone would volunteer to figure that out for us, then we might be able to add it to the HBG3, RAM constraints aside.

 

Cheers
 

Edited by mlord, 17 December 2023 - 07:39 AM.

[Astro Andy]

Am I right in thinking the GPS can be manually entered and stored for those that are using that same position? What format is needed?

[mlord]

Am I right in thinking the GPS can be manually entered and stored for those that are using that same position? What format is needed?

Location is just a couple of numbers, obtained from the HBG3 GPS module.

So one sets up the HBG3 outside with a good view of the sky -- no mount required -- and waits for a GPS fix.  Then use the OLED and push-button to SAVE LOCATION.  Done.

 

Next time out with the telescope, wait for the GPS to show a valid Date/Time, which happens much more quickly than full Location data, and then use the OLED and push-button to RESTORE LOCATION. Done.

 

That last bit can be automated with an NVRAM setting, as described earlier in this discussion thread.

 

EDIT: I suppose one might want to combine this idea with having the HBG3 get Time/Date from WiFi (internet) in Access Point mode.  Then, no waiting at all.  Mmm.. might add that.

Edited by mlord, 17 December 2023 - 08:39 AM.

[Astro Andy]

Brilliant Mark. If it can get the time from the net and the GPS from manual setting, where no GPS module is present but coordinates are know, then awesome. Obviously there'd need to be an 'enable GPS screen when no hardware is detected true/false' setting.

[Rac19]

EDIT: I suppose one might want to combine this idea with having the HBG3 get Time/Date from WiFi (internet) in Access Point mode.  Then, no waiting at all.  Mmm.. might add that.

Sounds like a simple idea, well worth implementing. It won't work for me because my 2.6 GHz WiFi signal is marginal. 5 GHz (from my mesh repeater) would work but I think that HBG3 is 2.6 GHz only.

[Rac19]

I recently spent about two days looking into that.  It all sounded nice and rosy to begin with, but turned out to be nigh impossible to use for our application.  The data exchange model was backwards of what we needed, or the apps were so complex to install and configure that nobody would use them.

There was an App called "Bluetooth GPS Output" that to sends GPS data t other devices. It had mixed reviews and has been withdrawn from Playstore, so possibly it was not much good.

 

Another option would be a standalone Bluetooth GPS device. I know of two, the Garmin GLO 2 and a device from GNS Electronics. They cost at least as much as an assembled HBG3, but I for one, would be prepared to buy one. I actually have an early model GNS that works well with my WiFi only iPad.

 

The slightly worrying thing about the Garmin GLO 2 is that Garmin says that it shows up in Windows as BT Headset. I would expect it to work as Bluetooth Serial Port (SPP), possibly sending out NMEA sentences, either on request or as a continuous stream.

 

Just my 2 cents worth.

[scopewizard]

I shielded my GPS from the HBG3 module and moved it higher on the tripod.

 

I get a lock on after not using it for a month (cold start) in 3 mins after a day or 2 later 10-20 seconds.

 

The tripod can act as a signal reflector and confuses the GPS, see many satellites but can not lock.

 

A lot of info on the web that explain the weaknesses and solutions to improve reception. 

[Rac19]

Sounds like a simple idea, well worth implementing. It won't work for me because my 2.6 GHz WiFi signal is marginal. 5 GHz (from my mesh repeater) would work but I think that HBG3 is 2.6 GHz only.

Actually, I already connect the HBG3 to my mobile phone (acting as a mobile hotspot) for OTA upgrades and that seems to very reliable.

 

So if, on detecting internet access (be it via home network router or mobile hotspot), HBG3 gets the time from a public NTP Sever and presents it as GPS time, I think the problem is solved as far time synchronisation is concerned. Add to that the ability to substitute the most recently saved location coordinates while waiting for an active GPS fix, instant start up should be available to all, except when out of both WfFi and mobile network range. In such circumstances an actual GPS fix is the only alternative to manual time and location entry.

Edited by Rac19, 17 December 2023 - 09:53 PM.

[Rac19]

The slightly worrying thing about the Garmin GLO 2 is that Garmin says that it shows up in Windows as BT Headset. I would expect it to work as Bluetooth Serial Port (SPP), possibly sending out NMEA sentences, either on request or as a continuous stream.

Garmin explains all this in the link below, So in Windows, apparently, you find the BT GLO 2 "Headset" and configure a Com port for it. It goes on to explain that from said Com port there will be a continuous stream of GPS data, probably NMEA sentences I suspect. I am not sure how this would work in Arduino world.

 

As per my post #1019, if HBG3 can get a time synch from and NTP server, it's only when out of range of mobile phone and WiFi reception that the Garmin GLN2 (or GNS) would be required and then only if the HBG3 internal GPS was under performing.

 

https://support.garm...r4A0d3ug27OUJa9

Edited by Rac19, 18 December 2023 - 04:32 AM.

[mlord]

Here is version v8.27 of the Arduino ESP32 source code for this project:

  The main source file:        hbg3.ino.v8.27.txt   281.2KB   22 downloads

  Optional ethernet support:   eth.h.txt   17.18KB   14 downloads

 

There is no need to edit either file.  If one wants Ethernet support, then place eth.h into the same Arduino Sketchbook folder as hbg3.ino and it will be discovered and used.  Otherwise, if eth.h is not present, then hbg3.ino will build without Ethernet support.  Automatically.

 

The eth.h file is not new:  it is the same file (but now updated) that is normally part of the aio-hbg3 builds for the HomeBrew All-In-One (AIO) device.

 

New in this version of the firmware:

• Tighten up command parsing and also make it mostly case-independent, except for single-letter commands.
• Add new "send" command.  Requires device and at least one (hex) command byte as args. Eg.  send ALT fe
• Decode/display Evolution battery state when tracing.
• New 'D' command to toggle discarding of MC ACK responses to SSAG: reduces traffic on Relay bus.
• Reduce AUXBUS_TXQ_SIZE from 32 to 16; it rarely gets as high as 8; SSAG AutoGuiding may need more than 8.
• Add routing table: keep track of which devices are on which bus.
• p3000: Close connection before completing "reset" command.
• Ethernet: Add Ethernet support to HBG3.  Uses same pins as Stepper Motor, so either/or for those two.
• Ethernet: Enable more than one client at a time for myDHCP Server.

So it's not just the new Ethernet stuff, but a big improvement (routing) for the HBG3-Relay devices, and upgrades to the Serial/Telnet debug commands.

 

https://www.amazon.com/dp/B0B7MLTGZ3/

https://www.amazon.com/dp/B07MYY7QW2/

 

The recommended Ethernet hardware is a Wiznet W5500 module, which will connect directly to the HBG3's SPI pins, and can be powered with 3.3V from the HBG3 I2C pads or, for Ethernet modules with a 5V regulator onboard, from the 5V pin of the HBG3.  One literally just hooks up the six (6) jumper wires between the HBG3 and the Ethernet module, and it works.  No fuss.

 

Note that the SPI pins are also the same multi-purpose pins used when wiring up a Stepper motor to the HBG3, so one can hook up ONLY one of Ethernet or Stepper Motor.  The code will auto-detect which (if any) is connected, and do the Right Thing™.   Another thing to keep in mind, is that these Ethernet modules can sometimes interfere with GPS reception unless they are well shielded.  See the HomeBrew All-In-One thread for details.

 

Flashable binaries (with Ethernet support) are in the usual places, including Over-The-Air (OTA, using WiFi) Firmware Update binaries for both the HBG3 and the AIO project.  Fully pre-configured and patched HBG3_Arduino build packages are also available from the links at https://rtr.ca/hbg3/

Edited by mlord, 17 December 2023 - 11:19 PM.

[Jackey]

Hello! After successfully building the skysync gps clone I started looking for a celestron compatible focuser, and this project seems to be the ready solution not only for this but also for a dew heater controller which could potentially save me some battery life. My only concern is that I use the nextstar evolution mount which already has a built in wifi. I was wondering if hb3 wifi module would cause any conflicts with it. Also in the code I noticed a lot of switches to disable/enable additional modules in hb3, but not for WiFi. Has anyone tested HB3 with Nexstar Evolution? Thanks

Another question would be, is BE-180 the only supported wifi module? In my gps clone I used gy-neo6mv2 which seems to be good enough and 10x cheaper. I have a module ready an running so I can always use a separate module for GPS.

Edited by Jackey, 18 December 2023 - 12:12 AM.

[mlord]

I develop and test the HBG3 on an Evolution mount myself, so there are no issues whatsoever combining HBG3 devices with that mount.  Whenever a connection is active via the HBG3, it sends a command to temporarily turn off the mount's own WiFi, and turns it back on again when the connection goes dormant (when software has disconnected).

 

The basic HBG3 has two slider switches, one of which selects between the two WiFi (and ethernet) modes, and the other is an RF-Kill/MUSB switch (turns off WiFi and Bluetooth, enables Mount-USB).

 

Most GPS modules probably work, but I only support the Beitian BN-180, BE-180, BE-182, and BE-122.  I have tried some labelled as "Neo-whatever" in the past, and they simply never got a GPS fix after hours of on-time.  There are a lot of "fake" Neo GPS units out there.

 

Despite what one might infer from a persistent poster here, the Beitian units generally work extremely well.  I use these modules because of their convenient form factor as well as their performance.  Most of the time they get a quick fix indoors in my office here.  But once in a while here, they seem to take forever.  It depends a lot on the weather and how many satellites of the various constellations happen to be overhead.

 

https://rtr.ca/hbg3/

Edited by mlord, 18 December 2023 - 02:16 AM.

[pbddict1]

I acquired the BE-180 very inexpensively(~$8), and it gets a a fix and the time so rapidly and so reliably, that I don't understand why GPS fix "delays", alternative methods, or alternative devices are as popular a topic here as they are.
Mine is mounted inside a PETG 3d printed enclosure, with a thinner layer of plastic over the antenna(0.4mm)area than the rest of the case.
I place it(Velcro)on my CGEM mount, right below the polar scope alignment port. (Below a C11 with a large dew sheild). Inside my home (one story, architectural asphalt shingles) it's still pretty quick. (2minutes maybe).
Even after my scope sits for a couple weeks...when I bring it out and turn it on, it takes so little time, that I do not even think about it, aside from maybe "oh, that was quick" and "that's a really nice little display"
My recommendation to others is that it's just not worth seeking alternatives or trying to work around it. ... Maybe I just got a "good one".

Edited by pbddict1, 18 December 2023 - 06:59 AM.

[Rac19]

I acquired the BE-180 very inexpensively(~$8), and it gets a a fix and the time so rapidly and so reliably, that I don't understand why GPS fix "delays", alternative methods, or alternative devices are as popular a topic here as they are.

I think that the delays in getting a GPS fix must be related to geographical location and not have much to do with which particular GPS module is used, although no doubt they vary in performance.

 

Tonight I had my venerable Garmin eTrex and HBG3 side by side. Early in the evening they both got a GPS fix within a minute or so of powering up, perfectly acceptable. Later, at about midnight, they both really struggled, with 0/0 satellites for at least 30 minutes which is obviously unacceptable. There seems to be a pattern to this, with poor GPS performance later in the night, on a very regular basis. It's a mystery to me, but there it is.

 

The HGB3 probably took about 30 minutes to even come up with a time value. I am not blaming the HBG3, it's just the way things are at my location. It's a normal suburban backyard, by the way, with no high rise buildings or such.

 

The end result is that the HC can spend 30 minutes or more "Waiting for GPS". The proposal for HGB3 to get the time from an NTP server and use the last saved location and clear the "Waiting for GPS" message, would fix my problem. If I am the only person on the face of the planet who experiences such problems, it's probably not worth fixing.

 

If something can be done, that would be great, if not I will just have to work around the problem.

 

EDIT: If the Evolution mount had a small battery to keep accurate time when it was turned off, there wouldn't be a problem.

Edited by Rac19, 18 December 2023 - 08:48 AM.