318 replies to this topic

[JJscope]

Have you looked at using an INA3221 to perform the voltage and current measurements for the DEW Rings and 12V Input.  I've attached my schematic for a DEW Controller, GPS, USB, AUX Bus Relay, and OLED display based off of the HBG3 by mlord.  It is fully functional with the CPWI/DEW Heater GUI (except for environmental sensor calibration) and provides GPS and Dew Controller information on the OLED.

 

 

[mlord]

That looks nice.  The choice of DHT21 for the environmental sensor isn't as good as what we normally use.  I have a lot of those DHT21/22 sensors in use around here, and nearly all of them have had the humidity sensing portion stop working -- they need to be periodically dried out for it to keep functioning.  That's what the "calibration" cycle is for on the recommended SHT30/21 sensors: it runs the built-in heater to dry them out periodically.

 

I would also try and get the environmental sensor away from the electronics housing, preferably in free air near the business end of the optical tube assembly for best results.

 

For the switching MOSFETs of the dew heaters, there was quite an involved discussion of those earlier in this thread, which ended up strongly favouring "logic level" MOSFETs over many other types.  The one you've chosen is suitable for 5V logic, but not so much for 3.3V.  It works though, just at not the same efficiency.  Worth a read back in this thread for that stuff.

 

0.1% resistors will give better accuracy on the thermistor readings, and hardly cost any more than the run-of-the-mill 1% variety.

 

Cheers!

Edited by mlord, 16 July 2024 - 02:51 PM.

[mlord]

Here is the newly updated wiring diagram for this project.

 

For those who might also want to connect the HBG3-Relay PCB into a Dew Controller set-up, there are some wiring changes required due to pin conflicts.

 

The changes are to the pair of green (PWM output) wires in the diagram.  Those should connect instead to pins D12 (PWM-0) and D18 (PWM-1) of the ESP32 module.

 

The current HBG3 firmware automatically expects that to be the case when a Relay is wired up.

Edited by mlord, 17 July 2024 - 07:01 AM.

[JJscope]

That looks nice.  The choice of DHT21 for the environmental sensor isn't as good as what we normally use.  I have a lot of those DHT21/22 sensors in use around here, and nearly all of them have had the humidity sensing portion stop working -- they need to be periodically dried out for it to keep functioning.  That's what the "calibration" cycle is for on the recommended SHT30/21 sensors: it runs the built-in heater to dry them out periodically.

 

I would also try and get the environmental sensor away from the electronics housing, preferably in free air near the business end of the optical tube assembly for best results.

 

For the switching MOSFETs of the dew heaters, there was quite an involved discussion of those earlier in this thread, which ended up strongly favouring "logic level" MOSFETs over many other types.  The one you've chosen is suitable for 5V logic, but not so much for 3.3V.  It works though, just at not the same efficiency.  Worth a read back in this thread for that stuff.

 

0.1% resistors will give better accuracy on the thermistor readings, and hardly cost any more than the run-of-the-mill 1% variety.

 

Cheers!

Thanks for the feedback, changed to a SHT40 sensor since it is suppose to be fully functional in a condensing environment per the sensiron datasheet and can also implement the heater via environment sensor calibration in CPWI Dew Controller GUI.

 

I had previously read the discussion about the IRF520 vs LR7843 module.  The IRLB8743PbF datasheet (Fig. 12 On-Resistance vs. Gate Voltage) shows the Rds value of 9mOhms @ 3.3V Vgs for Id = 40A. Additionally, per Fig.3, Typical Transfer Characteristics, you can switch 100A drain to source current @ 3.3V VGS.  I've set the total max current draw to 10A (2 Dew Rings and 1 12Vout combined), via a resettable fuse; therefore the voltage drop across the drain to source  @ 10A would be 90mV or 0.9W (if 1 output were to draw 10A).  Having said that, per the Celestron Dew Ring manual:

 

Dew Heater Ring, Max Current Draw:

5”, 0.6 A - would equate to 5.4mV (3mW) of lost power.
6”, 1.0 A - would equate to 9mV (9mW) of lost power
8”, 1.7 A - would equate to 15.3mV (26mW) of lost power
9.25”, 2.0 A - would equate to 18.0mV (36mW) of lost power
11”, 2.5 A - would equate to 22.5mV (56.3mW) of lost power
14”, 4.4 A  would equate to 39.6mV (174mW) of lost power. For 12V Power, you get 52.626W instead of 52.8W to the Dew Ring (99.67%)@100% duty cycle.

 

Verified with a 6" Dew Heater Ring (12.7 Ohms measured via DMM): See pictures

 

The 12V Input, Dew Heater#1 and Dew Heater#2 Outputs are measured via the INA3221 module (purple pcb).  The INA3221 has 3 channels that measure the Input Voltage and the Voltage Difference across a 0.01 Ohm resistor(allows for measuring approx. upto 16A) to determine the Current.  Additionally, it is configured to average 1024 readings (140uS/reading) to determine the Voltage and Current since it is a PWM signal @ 4Hz (250mS) vs 860ms/ch (140uS X 1024) X 6 measurements (2/channel@3channels).  So it is basically averaging 3 cycles of a 4Hz signal. 

 

The efficiency for the LR7843 module comes from switching the MOSFET with a higher gate voltage via the 12V DC Power Supply and PC817 optoisolator. 
Basically the IRLB8743 and LR7843 MOSFETs are very similar in characteristics when comparing datasheets, except the LR7843 MOSFET data sheet does not supply fig.12 defining the Rds(on) for Vgs.

 

Don't really need 0.1% resistors, but agree it would make the thermistor readings more "accurate".  The code uses the actual resistance value measured via DMM, along with the actual ADC 3.3Vref value, when calculating the Thermistor temperature.  These values are programmed into flash memory once via USB port command after building the PCB.

 

 

 

[mlord]

The code uses the actual resistance value measured via DMM, along with the actual ADC 3.3Vref value, when calculating the Thermistor temperature.  These values are programmed into flash memory once via USB port command after building the PCB.

One still runs into the fundamental problem that the ESP32 has very poor ADC circuitry.  The results are inconsistent and vary from unit to unit.  That's why we've since moved on to a very accurate external ADC chip that does not require any special characterization on behalf of the person assembling one.  The 0.1% resistors just guarantee excellent results there, and hardly cost any more than run-of-the-mill 1% tolerance resistors. 

 

Cheers

Edited by mlord, 29 July 2024 - 08:03 PM.

[JJscope]

Was wondering how the DEW Ring Thermistor Beta value was determined to be 3950. I did a quick look at available 10KOhm NTC Thermistors available on Mouser and saw that the Beta Value, were there was at least/around 100 unique thermistors available, ranged from 3380 (131) to 3984 (84).  The graph below depicts the effects of Beta on the calculated Temperature.  Anecdotally, comparing Beta value 3950 to 3984 and 3936 have a temperature difference of 0.1 to 0.25 degC.

 

 

Second, would a different value for the Thermistor Voltage Divider resistor place the measured voltage range in the middle of the temperature range used (what would be a good range?) for the Dew Ring thermistor.  Also, a higher voltage divider resistor value lowers the current draw through the thermistor reducing self heating effects.

 

The above graphs apply equally to both the ESP32 ADC and the external ADS1115 since it the calculation of the thermistor temperature based on the measured voltage. Having said that, the ADS1115 may have a wider range since it is usable over a large voltage input.  My understanding for the ESP32 is for an attenuation of 11db, it's useable range is from 150mV to 2.45V.

 

[mlord]

The beta value of 3950 was just some random recommendation I found when first beginning this project.  Ideally, one should replace that with a calculated beta using 3-points or more in the range of interest for dew control:  -8C, 0C, and +15C perhaps.

 

If you have the expertise to do that, then please contribute and I'll update the HBG3 code with the new beta value.  Or even parameterize it for individual customization.  Not everyone is using the Celestron Dew Rings on all Dew Control channels, but they should mostly be using 10K NTC style thermistors.

 

The 10K resistor value works well enough with random 10K thermistors, and is unlikely to change in the HBG3 design.  The temperature readings from it seem to stay within half a degree or so of the SHT30 ambient sensor under many conditions.  I have not put a lot of effort into detailed characterization there though.

 

Cheers!

Edited by mlord, 31 July 2024 - 10:25 AM.

[Zagath]

For those who might also want to connect the HBG3-Relay PCB into a Dew Controller set-up, there are some wiring changes required due to pin conflicts.

 

The changes are to the pair of green (PWM output) wires in the diagram.  Those should connect instead to pins D12 (PWM-0) and D18 (PWM-1) of the ESP32 module.

 

The current HBG3 firmware automatically expects that to be the case when a Relay is wired up.

Hi Mark,

What thermistor reference did you use?

 

Regards.
Gabriel G.

[mlord]

What thermistor reference did you use?

NTC 10K thermistor, same as found in the Celestron Dew Rings.

[jharvey]

Ok, I feared this topic (currently running for 4 years!) was no longer active, but here we are with the topic starter posting last month.

 

Mark, you showed early on that the thermistors can be queried for their temperature.  I have a 4x controller that I want to use for temperature control (vs dew point) using ASCOM.  I don't see any evidence that ASCOM provides a path for reading the thermistor temperatures.  The CPWI GUI doesn't even display the thermistor temperatures.

 

Any guidance on how I might set heater power in manual mode with a temperature feedback loop to control temperature?

[mlord]

Celestron doesn't have anything in their Dew Controller protocol for reading the thermistor temperatures.

Since the HBG3 version implements the same protocol, for full compatibility, it also currently lacks a command to return the thermistor temperatures to a remote app.

[jharvey]

So it seems that serial com over USB would be the way to go rather than ASCOM?  For my application, I don't intend to have a Celestron mount or hand controller; just a USB connection.  Some of your original posts are helpful to see how the serial send/receive strings are formed.  It seems that you have worked through the details of the serial interface for your Homebrew implementation.  Is that indeed what you did?  All I intend to do is configure the heater channels in manual mode, read back the thermistor temperatures, and command a heater percentage in a feedback loop.  Do you see that as a workable solution?

[mlord]

Sure, something like that could work.  There's no command to "read" the thermistors there either, but by issuing the "d" command, the HBG3 should  begin spewing regular temperature reports out over the USB/Serial connection.

 

However, there is no current command there to set the PWM percentage.  One could get added though.

[jharvey]

Not sure I follow you on the "d" command.  Is that specific to the HBG3?  I see from your previous posts that the GET_STATUS command returns a hex string that contains the thermistor temperature for that port.

[mlord]

This discussion is about the HomeBrew Smart Dew Controller, and it is normally implemented using the HBG3 hardware.  So, YES, it is specific to the HBG3. 

 

If you are trying to do that with a Celestron Dew Controller, then you're out of luck -- as I said earlier, to the best of my knowledge, Celestron does not currently provide a way to get the thermistor temperature.

[jharvey]

I mostly have the hooks figured out to do the temp control, thanks to your earlier posts.  I can send a hex command for the 4 heater channels which are producing a response that contains the thermistor temperatures.  I have been able to spy a few command being sent to make manual heater level changes.  These commands have a unique checksum that doesn't match any of the standard methods like summing or XORing.  As an example for setting dew heater #1 to 100% duty cycle:

 

3B 05 20 17 17 00 FF AE

 

00 is channel 1, 01 would be channel 2...

 

FF (255) is the duty cycle (0-255 translates to 0-100%), checksum is AE.

 

3b 05 20 17 17 00 9E 0F sets the duty cycle to 62% (158/255), checksum is 0F.

 

3B 05 20 17 17 00 57 56 sets the duty cycle to 34%, and again, a unique checksum of 56.

 

Any clue how the checksum byte is being calculated?  I don't see an obvious pattern.

 

The thermistor query commands (4 unique commands) have checksums, but those are easy to spy since there are only 4.

[jharvey]

I found an online checksum calculator at scadacore.com and it seems that the algorithm that returns the correct checksum for the full message doesn't do so for the shorter message so it looks like the latter is incomplete (truncated). I dropped the preamble and the checksum bytes to get the longer message's checksum to match.

 

Checksums
3B-09-B6-20-10-03-02-00-97-7D-40-B8
09B62010030200977D40
CheckSum8 2s Complement 0x100 - Sum Of Bytes = B8

3B-09-B6-20-10-03-02-00-97-BB
09B6201003020097
CheckSum8 2s Complement 0x100 - Sum Of Bytes = 75

I think this answers the question!

[mlord]

I mostly have the hooks figured out to do the temp control, thanks to your earlier posts.  I can send a hex command for the 4 heater channels which are producing a response that contains the thermistor temperatures.

Which specific commands are those?

EDIT: Oh, I should read my own code more often!    The thermistor readings are indeed returned as part of the response to the DEW_QUERY_HEATER(0x12) command.  It's just that CPWI doesn't display that information for some reason.

 

Checksums are a LOT simpler than many people here think.  Just add up ALL of the message bytes after (but not including) the starting 0x3B, including the final checksum byte.  The resulting sum should be 00 when truncated to 8-bits.

 

EDIT: "Two's-Compliment" is just a fancy term for "ordinary signed arithmetic".  So, for example, if trying to calculate a new checksum byte for a message that you're building up, add all of the bytes together (except for the beginning 0x3B), and then subtract that sum from zero.  The lower 8-bits of the result is the value for your new checksum byte.

Edited by mlord, 26 November 2024 - 10:10 AM.

[jharvey]

Well, it took me a hot minute to figure out the checksum method, and apparently Rac19 is smarter than ChatGPT as well.  I fed it several example commands with checksums and asked it to suggest a method.  It tried a few methods and failed.  Then when I saw the post suggesting the two's compliment method and suggested that to ChatGPT, it knew exactly what that method was and was able to verify that it worked.  Odd that it couldn't figure it out without the prompt.