Date   

Re: sub group encoders RA tracking 'tick' question?

Thomas_Jacobson
 

May I suggest you might want to look at the LS7366....
https://lsicsi.com/datasheets/LS7366R.pdf
s/b easy to add in front of your encoders.... provides a simple and reliable way to keep track of the encoder counts, no need to worry about interrupt speed etc.
T.


Re: OnStep on STM32

Egge
 

thanks Khalid and Martin,

your comments make sense... I checked the RTC module in detail, but did not find anything; anyway I resolderd the relevant pins
Here is a high resolution photo of the module
there is a green wire in the photo... did I miss something? I don't have it...

To verify everything with respect to LEDs on/off, I did all tests again and documented the output (see below) everything points to the RTC module, as you already have noted.

Only open question is, if PC13-LED on STM32 flashes, when operating WITHOUT RTC module - in my case it did not flash. Can you please comment?

in any case, I will order new RTC-module

best regards and thanks for your support
Egge


_________________________________________________________
Setup only CM2102 and STM32; no WeMos, no RTC module

flashing with OnStep.ino works fine; switching to run-mode: only PWR-LED on STM32 is activ; no blink and no solid light on other LED (PC13)

flashing with blink.ino works fine; directly after upload (even with boot-jumper in boot position) the sketch is executed and PC13-LED starts blinking; after power off and on in run-mode, sketch is also executed normally

flashing with i2cscanner.ino works fine; only PWR-LED lights up on STM32; PC13-LED is allways off;
"receiving" LED on CM2102 flahes frequently;

serial monitor gives error message (becuase no RTC/eprom included)
Unknown error at address 0x7D
No I2C devices found

flahsing with eeprom-wipe.ino works fine; only PWR-LED lights up on STM32; PC13-LED is allways off;
no response on serial monitor (as expected due to missing RTC)

____________________________________________________________
same setup as above, but WITH RTC module

flashing with OnStep.ino works fine; swithing to run-mode: only PWR-LED on STM32 is activ; no blink and no solid light on other LED (PC13); power-LED on RTC is on

flashing with i2cscanner.ino works fine; only PWR-LED lights up on STM32; PC13-LED is allways off;
"receiving" LED on CM2102 flahes frequently;

serial monitor gives
Scanning...
I2C device found at address 0x57  !
I2C device found at address 0x68  !
done


flahsing with eeprom-wipe.ino works fine; only PWR-LED lights up on STM32; PC13-LED is allways off; power-LED on RTC is on
response from serial monitor
......................................
EEPROM Wipe Complete


Re: Mks gen l v2 jumper question (not for motors)

Piers
 
Edited

I believe those connect the Diag(nostic) pin on TMC drivers to the endstops.
So you'd use them for sensorless homing and crash detection on a 3D printer.
Removing the jumpers would require and require your 3D printer to have mechanical endstops.

Hopefully you can equate my 3D printer words into Onstep ones :)


Mks gen l v2 jumper question (not for motors)

Eric Esch <ericesch85@...>
 

so as a back up I had ordered a spare main board. I noticed on this second board that there is jumpers pre installed that my other board didn't. They are not the ones for setting microsteps. There is a row of pins just above the red limit switch connectors that my second board came pre populated with and my first did not. They are marked xdiag, ydiag, zdiag etc. What are these for? 


Re: OnStep Configuration Generator Critical Error

Mike Wagner
 

Thanks for fixing this.

Mike


Re: OnStep Configuration Generator lives on ...

Khalid Baheyeldin
 

Did you use the Online Configuration Generator?
If so, please attach it to an email (do not copy/paste).
If not, you did not edit the file correctly.

Also, you did not set the options correctly in the Arduino IDE. It has to be 128K, per the instructions.


Re: OnStep Configuration Generator lives on ...

simpsonj@...
 

I'm not sure if it's operator error (likely) or a bug, but when I attempt to verify release 3.16 using the config.h file generated, I get the following error:

 Arduino: 1.8.5 (Windows 10), Board: "Generic STM32F103C series, STM32F103C8 (20k RAM. 64k Flash), STM32duino bootloader, 72Mhz (Normal), Smallest (default)"

Build options changed, rebuilding all
In file included from D:\Arduino\OnStep\OnStep.ino:55:0:

Validate.h:264: error: #error "Configuration: AXIS1_MICROSTEPS must be defined in your Config.xxx.h file if using AXIS1_DRIVER_MODEL!"

     #error "Configuration: AXIS1_MICROSTEPS must be defined in your Config.xxx.h file if using AXIS1_DRIVER_MODEL!"

      ^

Validate.h:322: error: #error "Configuration: AXIS1_MICROSTEPS; TMC2130 invalid micro-step mode, use: 256,128,64,32,16,8,4,2,or 1"

       #error "Configuration: AXIS1_MICROSTEPS; TMC2130 invalid micro-step mode, use: 256,128,64,32,16,8,4,2,or 1"

        ^

Validate.h:343: error: #error "AXIS2_MICROSTEPS must be defined in your Config.xxx.h file if using AXIS2_DRIVER_MODEL!"

     #error "AXIS2_MICROSTEPS must be defined in your Config.xxx.h file if using AXIS2_DRIVER_MODEL!"

      ^

Validate.h:398: error: #error "Configuration: AXIS2_MICROSTEPS; TMC2130 invalid micro-step mode, use: 256,128,64,32,16,8,4,2,or 1"

       #error "Configuration: AXIS2_MICROSTEPS; TMC2130 invalid micro-step mode, use: 256,128,64,32,16,8,4,2,or 1"

        ^

Multiple libraries were found for "Wire.h"
 Used: D:\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire
 Not used: D:\Arduino\hardware\Arduino_STM32\STM32F1\libraries\WireSlave
exit status 1
#error "Configuration: AXIS1_MICROSTEPS must be defined in your Config.xxx.h file if using AXIS1_DRIVER_MODEL!"

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.


I can't find an entry for "AXIS1_MICROSTEPS" or "AXIS2_MICROSTEPS" in the config.h file.  Am I missing something?

Thanks in advance.

Jim Simpson


How to build a GoTo Dobsonian that can be pushed by hand?

a
 

Hello,

I'm working on upgrading my Dobsonian to have GoTo capability, but I also want to be able to move it by hand.  My plan was to use a 100:1 geared stepper motor, followed by a 25:1 pulley ratio.  However, I'm concerned that it might not be possible to backdrive and rotate the telescope by hand without physically disengaging the motors.

I saw that SkyWatcher and Orion GoTo telescopes can be moved by hand while in auto-tracking mode.  I'm curious as to how that is mechanically accomplished without a clutch to disengage the motor.

According to the manual ( https://inter-static.skywatcher.com/upfiles/en_download_caty01335568752.pdf  ), they are using servos, but I don't know what type or how they can be backdriven.

Specs from the manual:

Power Supply: 10 to 15 V DC 1Amp, 2.1mm Plug (Center positive)
Motor type:
DC Servo Motors

Motor encoder: 1,620,000 counts per revolution, Main axis encoder: 11,748 counts per revolution

Any insights may be helpful!


Re: Importance of Steps Per Degree for DEC axis (versus RA axis). Suggested steps-per-degree.

Drew 🔭📷🚴‍♂️
 

On Thu, Aug 13, 2020 at 02:15 PM, Greg Baggs wrote:
I'm also new and working on an LXD55 mod. I'm also interested whether the Dec axis really needs much precision. I was planning on 3:1 drives for both axes and purchased 60T and 20T pulleys with 158mm belts. I am finding that I can't use these on the Dec axis as the 60T pulley is fairly large and there will be interference with the friction lock.
48T and 16T pulleys with a 146/150mm belt will work fine on the LXD55 with minimal if no modification. I am using 3D printed brackets in combination with the standard aluminum mounting bracket. Here is a pic of my Dec mounting adapter.


Re: Importance of Steps Per Degree for DEC axis (versus RA axis). Suggested steps-per-degree.

Dave Schwartz
 

Even without autoguiding, if dual-axis refraction compensation is enabled OnStep will use the DEC motor during tracking because atmospheric refraction changes the apparent DEC value too.

There is no requirement that the motors or overall reduction ratios be the same between the two axes - that's why there is the complete set of parameters (except for the STEPS_PER_WORMROT as discussed) for each. The only thing to be aware of is that the SLEW_RATE_BASE_DESIRED has to be such that each motor is kept from stalling so that means it might be less than it would be if both configurations were the same.

On 2020-08-13 2:18 p.m., Khalid Baheyeldin wrote:
On Thu, Aug 13, 2020 at 01:50 PM, <papagordygrapes@gmail.com> wrote:

For DEC axis, just initially reused a 200-step (1.5a) Nema17
stepper I already had.  2:1 pulley ratio and 88 teeth. Comes out
to 3128 steps-per-degree with 32 microsteps.  Could increase that
with finer microstepping.

Kind of wonder what is necessary for DEC axis?  More microsteps or
should I just order that 400-step motor instead?

It depends on whether you plan to use autoguiding or not.
DEC plays a factor in autoguiding, and often an important one.
If the resolution is rough, then the results may be suboptimal.

My advice is to test it and see how things go: try with 64 microsteps first, and switch to a 400 motor if the results are unacceptable.

If you don't plan to autoguide, then it does not matter much, since 2128 is close to 1 arc second, which will not have any impact on Goto accuracy.


Re: Importance of Steps Per Degree for DEC axis (versus RA axis). Suggested steps-per-degree.

Khalid Baheyeldin
 

On Thu, Aug 13, 2020 at 01:50 PM, <papagordygrapes@...> wrote:
For DEC axis, just initially reused a 200-step (1.5a) Nema17 stepper I already had.  2:1 pulley ratio and 88 teeth.  Comes out to 3128 steps-per-degree with 32 microsteps.  Could increase that with finer microstepping.

Kind of wonder what is necessary for DEC axis?  More microsteps or should I just order that 400-step motor instead?
It depends on whether you plan to use autoguiding or not.
DEC plays a factor in autoguiding, and often an important one.
If the resolution is rough, then the results may be suboptimal.

My advice is to test it and see how things go: try with 64 microsteps first, and switch to a 400 motor if the results are unacceptable.

If you don't plan to autoguide, then it does not matter much, since 2128 is close to 1 arc second, which will not have any impact on Goto accuracy.


Re: Importance of Steps Per Degree for DEC axis (versus RA axis). Suggested steps-per-degree.

Greg Baggs
 

I'm also new and working on an LXD55 mod. I'm also interested whether the Dec axis really needs much precision. I was planning on 3:1 drives for both axes and purchased 60T and 20T pulleys with 158mm belts. I am finding that I can't use these on the Dec axis as the 60T pulley is fairly large and there will be interference with the friction lock. On the RA axis there is a little more clearance and should be ok. For equatorial mount tracking Onstep should be only moving the RA axis mainly? Does it even control the DEC during tracking? I'm wondering if I can get away with a smaller pulley on the DEC axis only? Sorry if I'm hijacking this thread but it seems my question is closely related.


On Thu, Aug 13, 2020 at 3:20 PM <papagordygrapes@...> wrote:
Hi,  newbie here.

I recently added Nema17 motors to my Exos Nano EQ mount, and am using LV8729 drivers.  

For RA axis, using a 400-step (0.9a) Nema17 stepper.   With 3:1 pulley ratio and 138 teeth, comes out to 14720 steps-per-degree with 32 microsteps. 

For DEC axis, just initially reused a 200-step (1.5a) Nema17 stepper I already had.  2:1 pulley ratio and 88 teeth.  Comes out to 3128 steps-per-degree with 32 microsteps.  Could increase that with finer microstepping.

Kind of wonder what is necessary for DEC axis?  More microsteps or should I just order that 400-step motor instead?


Re: Importance of Steps Per Degree for DEC axis (versus RA axis). Suggested steps-per-degree.

Khalid Baheyeldin
 

On Thu, Aug 13, 2020 at 02:10 PM, <papagordygrapes@...> wrote:
also I'm confused by the relationship between AXIS1_STEPS_PER_WORMROT and AXIS1_STEPS_PER_DEGREE

Why is there not an AXIS2_STEPS_PER_WORMROT  ?
The wormrot parameter pertains to the worm gear for the RA axis in a German equatorial mount.
It determines the length of the worm period, and is used only if you have a Periodic Error Correction index sensor.

Therefore, it does not apply for the DEC axis.

If you don't plan to use PEC, then you can set the parameter to 0.


Re: Importance of Steps Per Degree for DEC axis (versus RA axis). Suggested steps-per-degree.

papagordygrapes@...
 

also I'm confused by the relationship between AXIS1_STEPS_PER_WORMROT and AXIS1_STEPS_PER_DEGREE

Why is there not an AXIS2_STEPS_PER_WORMROT  ?


sub group encoders RA tracking 'tick' question?

Dan Sawyer
 

Good morning all. The project is an LX50 fork mount and RA tracking for astrophotography. The current worm - drive gear produces measurable PE, I have decided implementing precision encoder feedback. The encoder will provide 180,000 direct ticks or 720,000 extrapolated ticks per rev. That works out to 2 pulses per second. I estimate the maximum error rate in open loop tracking to be less that 5%. Taken together this should provide sufficient precision to provide a correction signal. My intent is to create the feedback signal from a separate system. This will support flexibility in both correction signal generation as well as supporting a complex interface to OnStep, if required. 
My questions are:
Is there a sub group working in this area? There were several e-mails several months back, but nothing recently. 
Is there additional documentation for encoder feedback? Specifically, is there an interface definition to OnStep for how to provide incremental correction to OnStep while tracking? 
The OnStep system based on a STM32 kit. 
Thank you in advance, Dan 


Importance of Steps Per Degree for DEC axis (versus RA axis). Suggested steps-per-degree.

papagordygrapes@...
 

Hi,  newbie here.

I recently added Nema17 motors to my Exos Nano EQ mount, and am using LV8729 drivers.  

For RA axis, using a 400-step (0.9a) Nema17 stepper.   With 3:1 pulley ratio and 138 teeth, comes out to 14720 steps-per-degree with 32 microsteps. 

For DEC axis, just initially reused a 200-step (1.5a) Nema17 stepper I already had.  2:1 pulley ratio and 88 teeth.  Comes out to 3128 steps-per-degree with 32 microsteps.  Could increase that with finer microstepping.

Kind of wonder what is necessary for DEC axis?  More microsteps or should I just order that 400-step motor instead?


Re: is Android App source code available?

Khalid Baheyeldin
 

On Thu, Aug 13, 2020 at 11:59 AM, <papagordygrapes@...> wrote:
And then there's the issue that, due to code growth, 4.x now only fits in the available program flash memory if you permanently commit to never using certain features supported by the STM32 PCB.
IIRC, 3.16 was already near the 128KB flash limit of the STM32.  Are you saying that 4.x won't fit in STM32?  Bummer but not unexpected.  
Depends on the features you want to fit in. Some things like weather and focuser take more space than others.
It is certainly possible to run 4.x on the STM32, but you need to prune things you are not using (e.g. ST4 SHC, PEC, ...etc.)

Or you can stay with 3.16. The major new feature in 4.x is spiral search.
If you can do away without it, there is no downside in staying with 3.16.

He has graciously open sourced OnStep for all of us, and we can't ask him to do the same with whatever else in the ecosystem that he authored (ASCOM, Sky Planetarium, Android App).
He's done enough for all of us already.

Indeed, it is great and I'm grateful (and will send him a donation).  

I'm sure he could be asked, but I suspect that if it isn't a matter of proprietary/valuable code, it is a matter of his time in cleaning up the code and dealing with yet another GitHub repo with possible external committers. 
That could be a factor. Cooking at home is one thing, and posting your cooking on Youtube is another!

The value proposition of external committers is probably low enough given the limited scope of the app (?).  
Another factor is multiple versions on the App store. Building Android requires a different toolchain than Arduino, and not everyone wants to go through setting this up and having their own version. Imagine that it is open source, and several people add varying (possibly conflicting) features, and uploading it to the app store? It would be very confusing for the end users, unless the names are significantly different. It can also open the door to some unsavoury parties inserting malware in yet other versions.


Re: is Android App source code available?

papagordygrapes@...
 

And then there's the issue that, due to code growth, 4.x now only fits in the available program flash memory if you permanently commit to never using certain features supported by the STM32 PCB.
IIRC, 3.16 was already near the 128KB flash limit of the STM32.  Are you saying that 4.x won't fit in STM32?  Bummer but not unexpected.  

He has graciously open sourced OnStep for all of us, and we can't ask him to do the same with whatever else in the ecosystem that he authored (ASCOM, Sky Planetarium, Android App).
He's done enough for all of us already.

Indeed, it is great and I'm grateful (and will send him a donation).  

I'm sure he could be asked, but I suspect that if it isn't a matter of proprietary/valuable code, it is a matter of his time in cleaning up the code and dealing with yet another GitHub repo with possible external committers.  The value proposition of external committers is probably low enough given the limited scope of the app (?).  


Re: is Android App source code available?

Dave Schwartz
 

On 2020-08-13 11:40 a.m., Khalid Baheyeldin wrote:
Like you, I wanted to be unrestricted to the ONSTEP access point, so I enabled Station Mode, and assigned fixed IP addresses in the router's DHCP. And like you, the router does not cover the backyard, so I got another used router and placed it by the window, and ran a wire from it to the other router. The second router does not have DHCP or DNS or any routing functions at all, so it is effectively an Ethernet switch with an access points. Works very well.
For those who want to set up such a WiFi repeater, there are some routers designed to do this very simply. One such is the Asus RT-N12 that I use. It connects wirelessly to your main router and, once you log it in, it inherits everything it needs (SSID=xxxxx_RPT, passwords, DHCP ranges and reservations, DNS servers, etc)


Re: is Android App source code available?

Dave Schwartz
 

And then there's the issue that, due to code growth, 4.x now only fits in the available program flash memory if you permanently commit to never using certain features supported by the STM32 PCB.

On 2020-08-13 11:25 a.m., Khalid Baheyeldin wrote:
Are you using 3.16 or master?
The master version does add error messages and such, but it is not yet stable enough to recommend for general use.

11581 - 11600 of 35577