2152 replies to this topic

[dewo]

I now have a 28BYJ-48 DIY focuser working quite well, excellent (I may swap the C and Z buttons as the trigger in the code though as I'd find it much easier to hold the Z button while moving the thumbstick)

 

I see that you have added code for focuser backlash compensation. I don't see any focuser backlash settings in my starsense controller menu like the Celestron Motor Focus manual mentions (I realise it's only emulating it so I imagine that's why. I can control it from the menu though, just no backlash menu). Can I simply play with the values of the following lines to get that working? I understand it should be in the 0-100 range?

static byte focus_backlash_pos        = 0;      // saved in NVRAM
static byte focus_backlash_neg        = 0;      // saved in NVRAM

Cheers,

Dean

[mlord]

 

I now have a 28BYJ-48 DIY focuser working quite well, excellent (I may swap the C and Z buttons as the trigger in the code though as I'd find it much easier to hold the Z button while moving the thumbstick)

 

I see that you have added code for focuser backlash compensation. I don't see any focuser backlash settings in my starsense controller menu like the Celestron Motor Focus manual mentions (I realise it's only emulating it so I imagine that's why. I can control it from the menu though, just no backlash menu). Can I simply play with the values of the following lines to get that working? I understand it should be in the 0-100 range?

static byte focus_backlash_pos        = 0;      // saved in NVRAM
static byte focus_backlash_neg        = 0;      // saved in NVRAM

Actually, it is NOT "only emulating" it; rather it is fully implementing everything except the "Calibration sequence", which is currently merely emulated. 

 

I checked just now on my own StarSense HC, and sure enough.. the Backlash menu is missing from it.  My Nexstar+ HC does have that menu.  I don't see one in SkyPortal or SkySafariPro though.  Forgot whether CPWI has it or not.

 

But yes, you can just use the "set" command over serial or over telnet (port 3000) to change the values, followed by the "save" command, and then the "reset" command.  They don't take effect from there until after a "reset".

 

Speaking of which:  Found/fixed a bug in the "set" command.  New release in my next post!

Edited by mlord, 22 July 2023 - 07:11 AM.

[mlord]

Here is v6.28 of the Arduino ESP32 source code for the HomeBrew Gen3 (HBG3) project:  hbg3.ino.v6.28.txt   203.9KB   35 downloads

 

One IMPORTANT bug-fix in this release:  The "set" command was sometimes saving corrupted strings in NVRAM.  Which means that when configuring the WiFi "Access Point" parameters from SkyPortal/SkySafari, it could end up with bad data and be unable to connect.

 

So..

                Everyone: please update to this version NOW.

 

Cheers

-ml

Edited by mlord, 22 July 2023 - 07:20 AM.

[mlord]

 

I now have a 28BYJ-48 DIY focuser working quite well, excellent (I may swap the C and Z buttons as the trigger in the code though as I'd find it much easier to hold the Z button while moving the thumbstick)

Press and hold both buttons simultaneously, and wait about 1.5-seconds for the blue LED to light up, then release them.  The Nunchuck is now in "focus.only" mode, where the two individual buttons can now save positions (long press) and return to those positions later (short press).  Otherwise the thumbstick now only operates the focuser, not slewing.

 

Another long press of both buttons toggles it back again to slew/focus mode.

[andriy_melnykov]

I also didn‘t see backlash settings for focuser in CPWI.

Speaking of backlash, only for info: many SW apps have also own way to deal with focuser backlash. For example CPWI and SkyPortal approach focus position only from one direction. SharpCap has many internal settings for backlash, and by automatic focusing set focus also only from one direction.

But for focusing with Nunchuck it must be a useful function of course.

[mlord]

I also didn‘t see backlash settings for focuser in CPWI.

Speaking of backlash, only for info: many SW apps have also own way to deal with focuser backlash. For example CPWI and SkyPortal approach focus position only from one direction.

The HBG3 does exactly the same thing, automatically, when seeking to a specific/numbered position, using a preset button.

 

The "backlash" settings are for something different:  they apply only when manually jogging the focuser from the hand-controller, CPWI, an app, or from the Nunchuck's thumbstick.  When one switches direction of focus, there will be a brief burst in the new direction to take up any slack from the focus mechanism or motor gearing.  The backlash "number" setting specifies the duration of that brief burst.

 

It took me a while to figure that out. 

Edited by mlord, 22 July 2023 - 01:20 PM.

[dewo]

I checked just now on my own StarSense HC, and sure enough.. the Backlash menu is missing from it.  My Nexstar+ HC does have that menu.  I don't see one in SkyPortal or SkySafariPro though.  Forgot whether CPWI has it or not.

 

But yes, you can just use the "set" command over serial or over telnet (port 3000) to change the values, followed by the "save" command, and then the "reset" command.  They don't take effect from there until after a "reset".

Thanks for this info. You really have done some thorough work here!

I do still have the Nexstar+ HC so I'll plug that in to set the focus backlash and get it saved to NVRAM 

[Zoroastro]

Hi Mark - for the Celestron dew heater ring, can you confirm the HBG3 pins for the pwm output, thermistor input and SHT31 signal? 

 

They should be:

 

Thermistor

- GPIO #34 with 10k pull-up to 3.3V

- GND

 

PWM

- GPIO#4 with a diode to PWM Out = SIG of a IRF520 MOSFET

 

Sht3x

- I2C bus (no pull-ups needed)

 

All the other connections to switches, buttons etc stay the same.

 

Is that right?

 

Cheers!

Edited by Zoroastro, 23 July 2023 - 11:00 AM.

[mlord]

static byte   thermistor_pins [DEW_NUMCHANNELS] = {34, 39};  // Must be from GPIOs 32..39.

static byte   dew_pwm_pins    [DEW_NUMCHANNELS] = {14, 26};  //

 

So for the first DewControl channel, form a voltage divider with a 10K thermistor (Celestron uses 10K) and a 1% 10K resistor in series.  Resistor pulled up to +3.3V, thermistor down to GND, and the midpoint between them goes to GPIO34.  https://www.cloudyni...2#entry12683617

 

The PWM output to the MOSFET transistor goes from GPIO14 through a diode to the IRF520 module.  If not using a module, then you'll have to supplement the IRF520 transistor with a resistor, same as on the modules.  They seem to use a 1K pull-down between the PWM input and GND.  https://cdn.shopify....ng?v=1601006843

 

SHT30 (or SHT31, I used the SHT30 myself) just connects to the I2C bus directly.  On the one I built, I did have to add an extra set of 5K pull-ups on SDA/SCL for reliable operation.  The built-in 5.1K pull-ups on the HBG3 should really have been 3.3K (fixed for the next iteration), so adding a second set of them strengthens the pull on the bus to about 2.5K.  Works well.

 

As soon as the HBG3 sees the SHT30 on the I2C bus at startup, it enables the DewControl functionality.

Edited by mlord, 23 July 2023 - 12:39 PM.

[andriy_melnykov]

Hi together, please be aware of IRF520 parameter. If really the IRF520 is used in the module, it can not be reliably controlled from 3.3V output of ESP32. Threshold voltage is according to datasheet from 2 to 4V, and this is still for very low current in the drain. It can work, but also can happen, that transistor is not (fully) opened. Also, strongly dependent on temperature in this gate voltage region. It is also not guaranteed from 5V port, but probability is much higher.

The minimal gate voltage for stable control is about 8V.

[mlord]

Hi together, please be aware of IRF520 parameter.

Good point:

 

So at 5V trigger it looks perfectly good for our application: Dew Rings up to 3-amps each.

But at 3.3V trigger, as currently used, it may suffer a bit.  But it does work (mine heats up just fine).

 

I'll keep this in mind when designing a PCB for it though, perhaps adding a transistor to boost the gate voltage up to 5V.

 

EDIT: A simpler method for the interim just be a pull-up resistor (to +5V) on the PWM output, rather than the 1K pull-down. With the voltage drop through a 1N4007 diode, this will give about 4.1V at the IRF520's gate when "on", which is good for about 1A of current.  The downside is that this then makes the default heater state "on" rather than "off".

 

Thanks

-ml

Edited by mlord, 23 July 2023 - 02:35 PM.

[Zoroastro]

We can use an NPN transistor to drive the IRF520. Eg 2N3904.

 

Or maybe use a IRL540 MOSFET?

Edited by Zoroastro, 23 July 2023 - 05:05 PM.

[mlord]

We can use an NPN transistor to drive the IRF520. Eg 2N3904.

Or maybe use a IRL540 MOSFET?

Or maybe both?  I see in the datasheet for the IRL540 that 5V PWM is used in the test circuit.

 

My medium/end-of-year term plan, is to produce a HomeBrew Gen4 design and PCB, with onboard 2X Smart Dew Control and Stepper Motor support (for Focus), as well as all of the usual HBG3 functionality.  It would be great if perhaps you and Andriy might sort out exactly what we should have there for the MOSFET and driving transistor (if needed).   And I can ensure each of you get a PCB to play with from the first run, whenever that happens (September November/December?).

 

Cheers
 

Edited by mlord, 23 July 2023 - 05:22 PM.

[Zoroastro]

That would be great! IRL540N probably is the right choice, but Andriy knows this stuff 1,000x better than me ;-)

Edited by Zoroastro, 23 July 2023 - 05:22 PM.

[andriy_melnykov]

IRL540 will work with 5V perfectly. With 3.3V it should work also, but not as reliable, as I would like to see in a series device.

Good candidates are, in my opinion:

- double MOSFETs: BUK9K13-60, Si4228DY, Si9926CDY

- single MOSFETs: Si4116DY, BUK9Y09-40, PSMN9R0-25

They are all small and fit good for a compact PCB. No need for big transistors in this case. No need for cooling at 3A. Control frequency can be critical though, if controlled directly from ESP32 pin.

 

But the choice is strongly dependent from requirements. Mark, can you please share the requirements, here or in private messages?

- SMD or through hole

- preferred source, price

- control frequency

- ...

Edited by andriy_melnykov, 24 July 2023 - 12:50 PM.

[mlord]

The Si9926CDY Looks great.  JLCPCB stocks them too, for about $0.50/each, so I could very easily use that for two-channels of PWM output.

 

Here is the datasheet for the exact one at JLCPCB:  https://rtr.ca/teles...DY-T1-GE3-1.pdf

 

Do you think it would need any additional support circuitry, or just be wired directly to the GPIO lines and the 12V telescope power source?  EDIT:  with 1K pull-downs on the gate inputs.

Edited by mlord, 24 July 2023 - 03:17 PM.

[mlord]

Mmm.. JLCPCB linked to the BDY version, whereas we want the newer CDY version, also available at JLCPCB:  https://rtr.ca/teles...3-datasheet.pdf

[andriy_melnykov]

The circuit for this case would be, as my proposal:

 - series resistor between I/O-pin and gate to limit pin current: ~140 Ohm (for ~20mA limitation, for default pin driver strength 2). This resistor can be chosen higher, if control frequency is low - less EMC problems.

 - resistor between I/O-pin and GND, to define reset state (many pins have weak pull-up): ~2-3k (pin voltage under 0.3 V with 75µA pull-up current in reset state).

 - zener diode or ESD diode with ~7-8 V between I/O-pin and GND: ESD protection of the gate - because ESP32 is removable.

 - ESD protection at output, in this case ceramic 4.7nF capacitor between drain and GND should be enough. ESD diode with ~16 V as alternative.

 

The circuit should be analysed for switching time, to confirm low switching power loses - dependent on control frequency. I can of course further support, if needed.

Edited by andriy_melnykov, 24 July 2023 - 04:21 PM.

[mlord]

Every time I look at the HBG3 PCB layout, my innards cringe at the thought of trying to re-do it for extra things like Dew Control or Focus Motor control.

 

So I think instead perhaps a companion PCB is the way to go here.  It could be mounted side-by-side with the HBG3 in a box, and have all of the necessary connectors for Dew Control along one edge, and other things:

• 12V Dew Heater power input jack.
• two RCA jacks for 12V PWM Heater outputs.
• two 2.5mm mono jacks for thermistor inputs.
• maybe a spare AUX port jack?  No, needs too many extra wires.
• an extra set of pads for a Nunchuck socket, because it is difficult to use the normal one when fitting things into a box.

That's a lot of external connectors!  But then also a bunch of internal connections:

• I2C connection from the main HBG3.
• I2C header for the SHT30/31 ambient sensor.
• I2C header for directly mounting an OLED in a good position.
• extra I2C header for other "stuff".
• GPIO connections from the HBG3: 4 needed for Dew Control.
• the 2-channel MOSFET chip w/diode, various resistors/capacitors.

For Focus Motors, I may just leave that off of the Dew module.  It needs a lot of real estate for either a STEP/DIR driver module or a ULN2003 chip (could be co-located to save space), and 3 or 4 GPIO signals, plus 12V from AUX and GND, and a motor connector.  Plus an FRAM chip for keeping track of motor position, which then needs I2C for connection.

Edited by mlord, 25 July 2023 - 11:37 AM.

[b079]

Was thinking about the layout myself last night, and that's definitely a tough one. Personally, I have no issue with a larger board but understand that will increase cost and complexity.

One idea I was throwing around is to maybe make it stackable like the adafruit feather series. There could be an extra board in between the hbg4 and the esp32. This board would have direct access to all the IO, but could also be larger. It would also open up the option to have a bit of a protoboard off to the side.

Whatever you decide to do, I'll support. You've done some amazing work.

https://www.adafruit.com/category/814

Edited by b079, 25 July 2023 - 01:05 PM.

[tjay]

I think a companion PCB would be reasonable, and not too hard to design a case around.

 

Just curious, are you thinking FRAM to try to avoid the flash write cycles of using something the EEPROM library to store stuff in flash on the ESP32?

[mlord]

Just curious, are you thinking FRAM to try to avoid the flash write cycles of using something the EEPROM [SPIFFS] library to store stuff in flash on the ESP32?

Yes. The quality of flash chip used on most ESP32 modules is probably not the best.  And for the Focus Motor, we'd ideally want to continuously save the current stepper position, so that on a power cycle or reset the HBG3 would still know where the stepper last was.  Same as the Celestron Focus Motor does.  This is needed for supporting the mix/max travel limits of the Focuser.

 

I have a little FRAM module here now, and just plugged it into the I2C bus of the HBG3. Very easy to get going (no extra library needed) and seems to work well enough.  Not the smallest SMD chip in the world, though -- SO-8 package so it does need a bit of PCB space.

Edited by mlord, 26 July 2023 - 07:27 AM.

[mlord]

Here is v6.29 of the Arduino ESP32 source code for this project:   hbg3.ino.v6.29.txt   207.55KB   29 downloads

• Fix AUXRELAY operation: broken since v6.2 came out.
• FRAM:  Preliminary support for FRAM modules.
• NVRAM: Don't display "reservedNN" variables from "get all" command.
• NCHK:  Tweak slowest slew speed for easier use at the scope.

I finally got around to re-testing the AUX bus relay operation, and discovered it had been broken since v6.2.  Fixed.

 

This is the special hardware mode where the HBG3 has been wired up with a second AUX port and matching interface logic, and acts as a packet relay (or bridge, or "router") between the two AUX buses.  Most useful for NexStar-GPS mounts, but occasionally also to solve problems of overloading with too many accessories.

 

Cheers

[dewo]

I'm having some nunchuck issues that I just can't figure out. Using the latest version of the code, a couple of seconds after booting the mount and focus motor both go a little crazy simultaneously, and I have to quickly turn it off. It only happens when the nunchuck is plugged in. On an earlier version of the code everything just works as it should. From memory I think there was an even earlier version that did something similar (mount just ran away after boot when nunchuck was in)?

 

I see the following in the logs but can't see any obvious clues. Note that this is without touching the nunchuck at all, just having it plugged in, and on earlier versions it behaves as expected. STEPPER_DRIVER is set to STEPPER_DRIVER_ULN2003 (that's the one I'm using) and EMULATE_FOCUS is true.

nchuck_detect: 00 00 a4 20 00 00
Nunchuck detected
Nunchuck Calibration Data: 00 00 00 00 00 00 00 00 ff 00 80 ff 00 80 00 00
...
nchuck_set_ranges: X-axis: (255,255,0,0): 252 255 255 255 2 <> 253 0 0 0 3
nchuck_set_ranges: Y-axis: (255,255,0,0): 252 255 255 255 2 <> 253 0 0 0 3
X=  1, range:  0 -> -5
Y=  2, range:  0 -> -1
nchuck_send_mc_cmd: dev=0x10 cmd=0x25 speed=0x09
nchuck_send_mc_cmd: dev=0x11 cmd=0x25 speed=0x04
bus_loop: auxbus_tx is alive
000002167 auxbus_tx: 3b 04 e2 10 25 09 dc     [ESP32  -> AZM   ] MC_MOVE_NEG
X=  3, range: -5 ->  1
nchuck_send_mc_cmd: dev=0x10 cmd=0x24 speed=0x00
nchuck_send_mc_cmd: dev=0x11 cmd=0x24 speed=0x00
nchuck_send_mc_cmd: dev=0x12 cmd=0x24 speed=0x01
000002196 auxbus_tx: 3b 04 e2 11 25 04 e0     [ESP32  -> ALT   ] MC_MOVE_NEG
X=  0, range:  1 -> -5
Y=  0, range: -1 ->  5
nchuck_send_mc_cmd: dev=0x12 cmd=0x25 speed=0x05
000002219 auxbus_tx: 3b 04 e2 10 24 00 e6     [ESP32  -> AZM   ] MC_MOVE_POS
000002231 auxbus_tx: 3b 04 e2 11 24 00 e5     [ESP32  -> ALT   ] MC_MOVE_POS
000002239  emdev_rx: 3b 04 e2 12 24 01 e3     [ESP32  -> FOCUS ] MC_MOVE_POS
000002247  emdev_rx: 3b 04 e2 12 25 05 de     [ESP32  -> FOCUS ] MC_MOVE_NEG
000002255 nchuck_handle_fm_response: 3b 03 12 e2 24 e5    [FOCUS  -> ESP32 ]
000002262 nchuck_handle_fm_response: 3b 03 12 e2 25 e4    [FOCUS  -> ESP32 ]
Y=255, range:  5 -> -5
nchuck_send_mc_cmd: dev=0x12 cmd=0x24 speed=0x00
nchuck_send_mc_cmd: dev=0x12 cmd=0x24 speed=0x00
nchuck_send_mc_cmd: dev=0x10 cmd=0x25 speed=0x09
nchuck_send_mc_cmd: dev=0x11 cmd=0x25 speed=0x09
000002415  emdev_rx: 3b 04 e2 12 24 00 e4     [ESP32  -> FOCUS ] MC_MOVE_POS
X=255, range: -5 ->  5
nchuck_send_mc_cmd: dev=0x10 cmd=0x24 speed=0x00
nchuck_send_mc_cmd: dev=0x11 cmd=0x24 speed=0x00
nchuck_send_mc_cmd: dev=0x12 cmd=0x24 speed=0x05
000002439  emdev_rx: 3b 04 e2 12 24 00 e4     [ESP32  -> FOCUS ] MC_MOVE_POS
000002451 auxbus_tx: 3b 04 e2 10 25 09 dc     [ESP32  -> AZM   ] MC_MOVE_NEG
X=  0, range:  5 -> -5
Y=  0, range: -5 ->  5
nchuck_send_mc_cmd: dev=0x12 cmd=0x25 speed=0x05
000002472 auxbus_tx: 3b 04 e2 11 25 09 db     [ESP32  -> ALT   ] MC_MOVE_NEG
000002479 nchuck_handle_fm_response: 3b 03 12 e2 24 e5    [FOCUS  -> ESP32 ]
000002491 auxbus_tx: 3b 04 e2 10 24 00 e6     [ESP32  -> AZM   ] MC_MOVE_POS
000002503 auxbus_tx: 3b 04 e2 11 24 00 e5     [ESP32  -> ALT   ] MC_MOVE_POS
000002510  emdev_rx: 3b 04 e2 12 24 05 df     [ESP32  -> FOCUS ] MC_MOVE_POS
000002518 nchuck_handle_fm_response: 3b 03 12 e2 24 e5    [FOCUS  -> ESP32 ]
000002526  emdev_rx: 3b 04 e2 12 25 05 de     [ESP32  -> FOCUS ] MC_MOVE_NEG
000002533 nchuck_handle_fm_response: 3b 03 12 e2 24 e5    [FOCUS  -> ESP32 ]
000002540 nchuck_handle_fm_response: 3b 03 12 e2 25 e4    [FOCUS  -> ESP32 ]
nchuck_send_mc_cmd: dev=0x12 cmd=0x24 speed=0x00
nchuck_send_mc_cmd: dev=0x12 cmd=0x24 speed=0x00
nchuck_send_mc_cmd: dev=0x10 cmd=0x25 speed=0x09
...etc...

Any thoughts on what's going on? Is there a setting I've missed? Is my clone nunchuck flaky?

 

Thanks for any help!

 

Cheers,

Dean

Edited by dewo, 29 July 2023 - 06:21 AM.

[mlord]

I'm having some nunchuck issues that I just can't figure out.

...

I see the following in the logs but can't see any obvious clues. Note that this is without touching the nunchuck at all, just having it plugged in, and on earlier versions it behaves as expected. STEPPER_DRIVER is set to STEPPER_DRIVER_ULN2003 (that's the one I'm using) and EMULATE_FOCUS is true.

nchuck_detect: 00 00 a4 20 00 00
Nunchuck detected
Nunchuck Calibration Data: 00 00 00 00 00 00 00 00 ff 00 80 ff 00 80 00 00
...
nchuck_set_ranges: X-axis: (255,255,0,0): 252 255 255 255 2 <> 253 0 0 0 3
nchuck_set_ranges: Y-axis: (255,255,0,0): 252 255 255 255 2 <> 253 0 0 0 3

What's that "..." all about?  The line above it, and the next two lines are normally all together with nothing in between?

 

Nothing looks wrong with the code -- I fed it the same calibration data as shown in your report, and mine gives much better output.  Which means, your Nunchuck is not "at centre" for the first second after connection, when the code is trying to verify the centre (rest) point.

 

08:20:17.629 -> nchuck_debug=1
08:20:20.817 -> nchuck_detect: 00 00 a4 20 00 00
08:20:20.817 -> Nunchuck detected
08:20:20.817 -> Nunchuck Calibration Data: 00 00 00 00 00 00 00 00 ff 00 80 ff 00 80 00 00
08:20:21.646 -> nchuck_set_ranges: X-axis: (255,128,128,0): 252 241 191 170 131 <> 125 86 64 14 3
08:20:21.680 -> nchuck_set_ranges: Y-axis: (255,128,128,0): 252 241 191 170 131 <> 125 86 64 14 3

Edited by mlord, 29 July 2023 - 08:15 AM.