Date   

Re: Simple smart hand controller

Khalid Baheyeldin
 

On Wed, Apr 8, 2020 at 12:38 PM, <matzgp@...> wrote:
Hello, Howard, or whom it may concern...
now that the latest version is working i want to build the (simple) smart hand controller. Can I build and operate the Simple smart hand controller (with the ESP_wroom_32s) with the current onstep master (version 3.2) I think the schematic was originally for the teenAstro project. Or is there a better current schematic ?
Best regards Matthias and stay healthy!
There is already an ESP Smart Hand Controller that uses the ESP32 microcontroller.

Schematic and PCB are here

https://easyeda.com/dschwartz/onstep-shc


Simple smart hand controller

Matthias
 

Hello, Howard, or whom it may concern...
now that the latest version is working i want to build the (simple) smart hand controller. Can I build and operate the Simple smart hand controller (with the ESP_wroom_32s) with the current onstep master (version 3.2) I think the schematic was originally for the teenAstro project. Or is there a better current schematic ?
Best regards Matthias and stay healthy!


Re: Track speed is very hy #define

Khalid Baheyeldin
 

I got a direct message from him with this:
I finished my first onstep, but my sideral speed is very high, I am using nema 17 with planetarium reduction 100/1, in my onstep calculator I am using 200 steps, 32 microsteps, 1 reduction and 100 reduction.
If that is how you calculated, then it could be wrong.

GR2 is the reduction between the motor and the worm gear (100:1 in your case)
GR1 is the worm wheel (e.g. EQ5 is 144:1)

What is your mount?
We need more information.


Re: STM32 Bluepill problem

thaiacepilot
 

I'm building another board and now get problem in STM32 it keeping blink PC13 LED and cannot program to board (maybe boot1 not work), I've changed the board but same result  in all 3 board. This problem is from STM32 board? (That mean all my 3 boards are broken)


Re: Track speed is very hy #define

Howard Dutton
 

Tell us about the drive design and the controller hardware and show us the Config.h file then we can comment.


Track speed is very hy #define

hmsampaio@...
 
Edited

Olá, qualquer um, eu finalizo minha primeira etapa, tudo acabou, tudo está bem, mas minha velocidade lateral é muito alta, tipo 160x mais, eu estou usando duas nema 17 com redução de planetário 100/1.
Qualquer corpo me ajuda


Hi, anyone, I finish my first stage, everything is over, everything is fine, but my lateral speed is very high, like 160x more, I am using two nema 17 with planetary reduction 100/1.
Any body helps me


Re: Changing tracking rate in app

Terry Fishlock
 

Thanks Alex, Will certainly try your suggestions. Much appreciated.


Terry

On Tue, Apr 7, 2020 at 3:15 PM Alex F <phobos226@...> wrote:

[Edited Message Follows]
[Reason: Added image clarification of 'east heavy']

I have been having the most success with my EQ5, 130mm Newtonian and 50mm guidescope combination using all three of refraction compensation, OnStep PEC playback and Predictive Pec (PPEC) in PHD2. I have been recording and averaging my PEC curve over about 5 or 6 sessions and it seems to have smoothed out the transient errors to reflect the natural periodic error of my RA drive by now. Most nights I am averaging around 0.4-0.8 arc seconds in RA which isn't bad for a 130mm on an EQ5 in my opinion and well within my imaging scale of 1.81 arc sec / pixel.

Every system is different though, so do some PEC recordings over a few nights to average out the polar alignment errors, wind etc. and incrementally update the PEC accuracy as you go. I can definitely recommend PPEC over the default Hysteresis algorithm for an EQ5 though regardless, definitely give it a try.

I'd suggest an analytical approach on a multiple night basis, keep a little notepad or text file and ignore the graph, focusing on the RMS values and the images you capture. Sometimes my graph looks horrific but the RMS values are tight and the resulting images have good star shapes.

When you're dithering then even the RMS values aren't anything to go by as it ruins my stats, but provided you leave a long enough 'settle' time after each dither you won't affect the quality of your images once guiding stabilises itself before the next exposure begins.

My approach was this:
  • Polar drift align the mount, get it to within 5 minutes of error to minimise the effects of polar alignment on your readings
  • Set guide speed to 0.5x
  • Choose a target with minimal atmosphere in the way to reduce that variable on your guiding as well, you can image at the same time but don't expect much usable data, this is more about the mount than imaging at this point
  • Balance the RA axis East heavy so the worm drive stays engaged at all times during guiding, so that when it's commanding a West guide pulse the teeth aren't disengaging and falling due to gravity
  • Enable the Hysteresis algorithm on RA
  • Run the Guiding Assistant for just over one full worm rotation period, on my EQ5 with 144 tooth RA axis this is just under 600 seconds or 10 minutes, I'm not sure what that is on the CGE
  • Fill the min-move with what the assistant tells you to, adjust your guide camera exposures as directed, I run 2.5sec exposures 90% of the time, 3sec the other 10%
  • Keep OnStep PEC playback turned off, start guiding and start recording PEC data
  • Guide through 4 or 5 worm periods to get a nice averaged RMS result, don't do any dithering!
  • Note down your stats
  • Turn PEC on and repeat, compare the stats for improvements
  • Write PEC data to EEPROM
  • Turn off PEC playback in OnStep Switch the algorithm to Predictive PEC, repeat the observation and note taking
  • Turn PEC back on in combination with PPEC, take notes again
  • Compare all your results and see what is working and what isn't
It's a right pain to sit through but it works out in the end, and it's how I settled on my current combination of Predictive PEC, OnStep's PEC playback averaged over multiple sessions and Refraction compensation turned on. The next few nights are perfect for it as it's a full moon and you're not going to be imaging much anyway, except maybe the moon itself.

Hope this helps!

EDIT - Clarification of 'East Heavy' if you're unfamiliar. Just in case - https://stargazerslounge.com/uploads/monthly_2018_08/Untitled-1.jpg.800c56d9d5bbb13847b3003d96a85b0e.jpg


Re: Intervalometer

Michael Ehemann
 

Top ... great job

thx


Re: Changing tracking rate in app

Alex F
 
Edited

I have been having the most success with my EQ5, 130mm Newtonian and 50mm guidescope combination using all three of refraction compensation, OnStep PEC playback and Predictive Pec (PPEC) in PHD2. I have been recording and averaging my PEC curve over about 5 or 6 sessions and it seems to have smoothed out the transient errors to reflect the natural periodic error of my RA drive by now. Most nights I am averaging around 0.4-0.8 arc seconds in RA which isn't bad for a 130mm on an EQ5 in my opinion and well within my imaging scale of 1.81 arc sec / pixel.

Every system is different though, so do some PEC recordings over a few nights to average out the polar alignment errors, wind etc. and incrementally update the PEC accuracy as you go. I can definitely recommend PPEC over the default Hysteresis algorithm for an EQ5 though regardless, definitely give it a try.

I'd suggest an analytical approach on a multiple night basis, keep a little notepad or text file and ignore the graph, focusing on the RMS values and the images you capture. Sometimes my graph looks horrific but the RMS values are tight and the resulting images have good star shapes.

When you're dithering then even the RMS values aren't anything to go by as it ruins my stats, but provided you leave a long enough 'settle' time after each dither you won't affect the quality of your images once guiding stabilises itself before the next exposure begins.

My approach was this:
  • Polar drift align the mount, get it to within 5 minutes of error to minimise the effects of polar alignment on your readings
  • Set guide speed to 0.5x
  • Choose a target with minimal atmosphere in the way to reduce that variable on your guiding as well, you can image at the same time but don't expect much usable data, this is more about the mount than imaging at this point
  • Balance the RA axis East heavy so the worm drive stays engaged at all times during guiding, so that when it's commanding a West guide pulse the teeth aren't disengaging and falling due to gravity
  • Enable the Hysteresis algorithm on RA
  • Run the Guiding Assistant for just over one full worm rotation period, on my EQ5 with 144 tooth RA axis this is just under 600 seconds or 10 minutes, I'm not sure what that is on the CGE
  • Fill the min-move with what the assistant tells you to, adjust your guide camera exposures as directed, I run 2.5sec exposures 90% of the time, 3sec the other 10%
  • Keep OnStep PEC playback turned off, start guiding and start recording PEC data
  • Guide through 4 or 5 worm periods to get a nice averaged RMS result, don't do any dithering!
  • Note down your stats
  • Turn PEC on and repeat, compare the stats for improvements
  • Write PEC data to EEPROM
  • Turn off PEC playback in OnStep Switch the algorithm to Predictive PEC, repeat the observation and note taking
  • Turn PEC back on in combination with PPEC, take notes again
  • Compare all your results and see what is working and what isn't
It's a right pain to sit through but it works out in the end, and it's how I settled on my current combination of Predictive PEC, OnStep's PEC playback averaged over multiple sessions and Refraction compensation turned on. The next few nights are perfect for it as it's a full moon and you're not going to be imaging much anyway, except maybe the moon itself.

Hope this helps!

EDIT - Clarification of 'East Heavy' if you're unfamiliar. Just in case - https://stargazerslounge.com/uploads/monthly_2018_08/Untitled-1.jpg.800c56d9d5bbb13847b3003d96a85b0e.jpg


Re: Intervalometer

Howard Dutton
 
Edited

On Sun, Apr 5, 2020 at 06:22 AM, Michael Ehemann wrote:
The compiler shows no error.

This case of the FEATURE_LIST_DS  option being enabled and no devices found is now more informative:

Dallas/Maxim OneWire bus device s/n's:
No DS18B20 devices found
No DS2413 devices found


Re: successful upgrading

Howard Dutton
 

On Tue, Apr 7, 2020 at 11:33 AM, <matzgp@...> wrote:
i've got it from my FritzWlanApp while sending a GOTO command. It's about 20m distance...



but don't ask me about technical details...
More work, but updating that WiFi Add-on would be a good idea.  It's come a long way too.


Re: successful upgrading

Matthias
 

Hi, Tomo (?)

i've got it from my FritzWlanApp while sending a GOTO command. It's about 20m distance...



but don't ask me about technical details...
best wishes Matthias (stay healthy) and clear skies, watching the "super-moon today


Re: Changing tracking rate in app

Howard Dutton
 

On Tue, Apr 7, 2020 at 09:32 AM, Terry Fishlock wrote:
Thanks Howard, that clears up the tracking side. So Single Axis and Refraction ?
I doubt it will matter much given the other tracking errors (worm PE, etc.) but turning it on shouldn't hurt.  Just be sure dual axis is off since you don't want Dec constantly bouncing back and forth in the backlash during guides.


Re: OnStep is making news

tnut55
 

Plus AstroEQ is arduino based.  No flexibility to use faster, more capable boards.

My first project was AstroEQ.  It convinced me that a stepper system for telescope control could be feasible.

But Onstep delivers the goods!  Thank you, Howard.

On Tue, Apr 7, 2020 at 12:00 PM, Howard Dutton
<hjd1964@...> wrote:
On Tue, Apr 7, 2020 at 09:25 AM, <stefano.martini.fi@...> wrote:
AstroEQ was maybe the first board, but isn't opensource and this is one reason cause is gone out of fashion :D
OnStep was started in August of '12, I don't have the sources from then but I do have the revision log from an early version (about 1 year later) still on GitHub:
https://github.com/hjd1964/OnStep/blob/259e53006a2c9b2236ceae5df08825be360bf406/OnStep.ino


Re: OnStep is making news

Howard Dutton
 

On Tue, Apr 7, 2020 at 09:25 AM, <stefano.martini.fi@...> wrote:
AstroEQ was maybe the first board, but isn't opensource and this is one reason cause is gone out of fashion :D
OnStep was started in August of '12, I don't have the sources from then but I do have the revision log from an early version (about 1 year later) still on GitHub:
https://github.com/hjd1964/OnStep/blob/259e53006a2c9b2236ceae5df08825be360bf406/OnStep.ino


Re: Changing tracking rate in app

Terry Fishlock
 

Thanks Howard, that clears up the tracking side. So Single Axis and Refraction ?


On Tue, Apr 7, 2020 at 12:09 PM Howard Dutton <hjd1964@...> wrote:
On Tue, Apr 7, 2020 at 08:37 AM, Terry Fishlock wrote:
I will always be guiding as this rig is for long exposures. So what do you think the best tracking combo would be for that for best guiding. Is there a chance that one of the options might fight against the corrections being applied by the guiding program?
Yes, don't use dual axis & guiding unless you have a zero backlash Declination drive.

I totally missed any indication of changes to V3 I am reluctant to upgrade as my mount is performing pretty well right now. Is there an update list of changes from V1?
GitHub can browse the OnStep history, pick a branch and work your way back to see the comments/changes.

Generally speaking stability and solid bug free performance arrived in release-2.22.  Then release-3.16 added refinements, like its much improved configuration file format & configuration validation & more sophisticated command error checking/reporting, but deep down it's basically just like 2.22.  The current master branch (version 4.3) reworked the micro-step mode switching code (a fairly major low level change) and added a nice "auxiliary feature" control subsystem (for operating switches, dew heaters, intervalometer, etc.)


Re: OnStep is making news

stefano.martini.fi@...
 

One of the most buetiful thing of Onstep is to be opensource and having varius economical and object configuration, olso if I think that no many people help in the development.
AstroEQ was maybe the first board, but isn't opensource and this is one reason cause is gone out of fashion :D

One of the worst thing is the driver and the app not "opensource" but I understand Howard , if he give us the driver and the app, the day after we will see some "conversion box" at payment, with any reference to onstep and any gift to Howard...

Money are money, but open source is better <3

Good Job to everyone!!


Re: Changing tracking rate in app

Howard Dutton
 

On Tue, Apr 7, 2020 at 08:37 AM, Terry Fishlock wrote:
I will always be guiding as this rig is for long exposures. So what do you think the best tracking combo would be for that for best guiding. Is there a chance that one of the options might fight against the corrections being applied by the guiding program?
Yes, don't use dual axis & guiding unless you have a zero backlash Declination drive.

I totally missed any indication of changes to V3 I am reluctant to upgrade as my mount is performing pretty well right now. Is there an update list of changes from V1?
GitHub can browse the OnStep history, pick a branch and work your way back to see the comments/changes.

Generally speaking stability and solid bug free performance arrived in release-2.22.  Then release-3.16 added refinements, like its much improved configuration file format & configuration validation & more sophisticated command error checking/reporting, but deep down it's basically just like 2.22.  The current master branch (version 4.3) reworked the micro-step mode switching code (a fairly major low level change) and added a nice "auxiliary feature" control subsystem (for operating switches, dew heaters, intervalometer, etc.)


Re: Changing tracking rate in app

Terry Fishlock
 

Thanks again. I will email you the config. I have made so many changes over the months hardware wise that I will need to check my teeth counts on both pulleys.  

Regards


Terry.

On Tue, Apr 7, 2020 at 11:55 AM Khalid Baheyeldin <kbahey@...> wrote:
On Tue, Apr 7, 2020 at 11:37 AM, Terry Fishlock wrote:
I will always be guiding as this rig is for long exposures. So what do you think the best tracking combo would be for that for best guiding.
What is the best combo? I am no expert in autoguiding, since I am still working to learn it ..

But the main observation is that with autoguiding, lots of errors and mistakes are compensated for.
For example, the last session, I forgot to do a proper alignment, and still got decent results. That is
with no PEC at all (disabled it since I started guiding).

One caveat is that the mount has very low PE to begin with (Vixen SXD, about +/- 4"), so maybe
that is why guiding can do away without it. Don't know how a regular EQ5 with +/- 40" will do
without PEC, so that is the only difference to consider.

And I enabled the refraction compensation setting I mentioned earlier. The higher in the sky you go,
the less refraction offset there is, so if you image near the zenith, it matters less. But again, it cannot
be worse than regular sidereal and has advantages elsewhere, so why not make that the default?

Is there a chance that one of the options might fight against the corrections being applied by the guiding program?
There is no evidence that PEC and guiding fight each other in OnStep. But you may want to ignore PEC and see if autoguiding alone takes care of business. Or you can check Adaptive PEC in PhD2 and see if it improves things.

I totally missed any indication of changes to V3 I am reluctant to upgrade as my mount is performing pretty well right now. Is there an update list of changes from V1?
This is a recurring question, and the answer is check github, but it is a very long list. If Howard
would include the version changes in the commit messages, I would extract a change log from
there and edit to remove all the extra stuff (fixing comments, refactoring, ...etc.). But this is an
added task for Howard to do, and we can't be demanding on this time.

My recommendation is a solid go ahead and upgrade to 3.16. It has a much easier configuration
system, and breaks nothing. A few improvements here and there, but nothing earth shattering.
If you email me your configuration file (off list, as an attachment), I will create a 3.16 config file
for your


Re: Changing tracking rate in app

Khalid Baheyeldin
 

On Tue, Apr 7, 2020 at 11:37 AM, Terry Fishlock wrote:
I will always be guiding as this rig is for long exposures. So what do you think the best tracking combo would be for that for best guiding.
What is the best combo? I am no expert in autoguiding, since I am still working to learn it ..

But the main observation is that with autoguiding, lots of errors and mistakes are compensated for.
For example, the last session, I forgot to do a proper alignment, and still got decent results. That is
with no PEC at all (disabled it since I started guiding).

One caveat is that the mount has very low PE to begin with (Vixen SXD, about +/- 4"), so maybe
that is why guiding can do away without it. Don't know how a regular EQ5 with +/- 40" will do
without PEC, so that is the only difference to consider.

And I enabled the refraction compensation setting I mentioned earlier. The higher in the sky you go,
the less refraction offset there is, so if you image near the zenith, it matters less. But again, it cannot
be worse than regular sidereal and has advantages elsewhere, so why not make that the default?

Is there a chance that one of the options might fight against the corrections being applied by the guiding program?
There is no evidence that PEC and guiding fight each other in OnStep. But you may want to ignore PEC and see if autoguiding alone takes care of business. Or you can check Adaptive PEC in PhD2 and see if it improves things.

I totally missed any indication of changes to V3 I am reluctant to upgrade as my mount is performing pretty well right now. Is there an update list of changes from V1?
This is a recurring question, and the answer is check github, but it is a very long list. If Howard
would include the version changes in the commit messages, I would extract a change log from
there and edit to remove all the extra stuff (fixing comments, refactoring, ...etc.). But this is an
added task for Howard to do, and we can't be demanding on this time.

My recommendation is a solid go ahead and upgrade to 3.16. It has a much easier configuration
system, and breaks nothing. A few improvements here and there, but nothing earth shattering.
If you email me your configuration file (off list, as an attachment), I will create a 3.16 config file
for your