Date   

Re: OnStep from Instein.eu

Mike
 

Originally, I thought the site (mentioned above) was the main onstep site as they appeared to sell the kit...  strangely enough... there was no link to purchase it.

Just checked the link and domain is now for sale...

Michael


Re: Periodic error in an eq3-2 mount on 60s exposures. #backlash

Matt
 

Will do thanks guys!

čet, 16. srp 2020. u 01:22 Graeme <grmwebb70@...> napisao je:

I had wobbly pulleys also.
Turns out the shaft was 6mm but a lot of pulleys seem to be 6.3mm bore.
I found some on eBay that were 6mm and all good now.
Definitely check the bore if they're wobbling.


Re: Vixen Great Polaris periodic error and slow tracking #backlash

Mike Ahner
 
Edited

On Wed, Jul 15, 2020 at 08:31 PM, <biggs@...> wrote:
Regarding belts, are there ever issues with using GT2 belts with MXL gears?  I think my DEC axis is an MXL 60T gear.
Difficult finding the 60T GT2 gear with 6mm bore, and may have bought an MXL not noticing the difference.

On the RA the belt seems to bulge a little going over the 60T gear in 1 spot. 

Hi Biggs, I don't think you can mix gear & belt types successfully. The pitch is wrong so the belt won't fit correctly into the teeth and the bending radius will likely differ. I think that's what you're seeing with the bulge. Or perhaps the set screw isn't flush or below the teeth.

First, it's possible to buy a pulley with a 5mm bore and then bore it out on lathe or even a drill press. (although that's not as precise as a metal lathe). You can do this easily if you can go to a machine shop, or if you know a friend with a lathe, or you can go to a local maker shop or college metal shop.
Here is a 60T 5mm bore on Amazon, if you're in the US it can be delivered next day.

Second thought: I have a Vixen GP2 and I use a 3:1 ratio with 16T x 48T pulleys. It works very well and I can get slew speeds of about 2 or 3 d/s with a Vixen VMC200L mounted on it. 48T pulleys are possibly easier to find in 6 mm bore and I believe you'll not have any issues with 3:1. I don't remember where I bought my 48T pulleys, possibly from China but now so much is very slow shipping out there.

Another source but more expensive is from Stock Drive Products. Here's a 60T with 6 mm bore. It's flangeless which makes the outer diameter somewhat smaller and might allow it tuck in closer to the mount.

-Mike


Re: Vixen Great Polaris periodic error and slow tracking #backlash

biggs@...
 

I have extra pulleys I can use to count the teeth.  Seems to be 16, but easy to miscount.

Regarding belts, are there ever issues with using GT2 belts with MXL gears?  I think my DEC axis is an MXL 60T gear.
Difficult finding the 60T GT2 gear with 6mm bore, and may have bought an MXL not noticing the difference.

On the RA the belt seems to bulge a little going over the 60T gear in 1 spot.  Need to look further.  Sides on the gear are blocking the view.

Thanks,
David


Re: Vixen Great Polaris periodic error and slow tracking #backlash

Khalid Baheyeldin
 

On Wed, Jul 15, 2020 at 06:47 PM, Howard Dutton wrote:
On Wed, Jul 15, 2020 at 02:53 PM, <biggs@...> wrote:
16 and 60 teeth
I'd count those teeth, make sure it's not something else, like a 4:1.
If the pulleys are mounted, then it would be hard to count the teeth.
One way, if they are outside of the mount, is to make clay/playdough impressions (like the Sumerian Seals), and then count the impression on the clay.
Another is the method in Rafael's video, which can be used while they are mounted.


Re: Vixen Great Polaris periodic error and slow tracking #backlash

Khalid Baheyeldin
 

On Wed, Jul 15, 2020 at 06:38 PM, <biggs@...> wrote:
I will also change the belts as I have multiple.
I don't think the belts would cause any of the symptoms you have.


Re: Periodic error in an eq3-2 mount on 60s exposures. #backlash

Graeme
 

I had wobbly pulleys also.
Turns out the shaft was 6mm but a lot of pulleys seem to be 6.3mm bore.
I found some on eBay that were 6mm and all good now.
Definitely check the bore if they're wobbling.


Re: Periodic error in an eq3-2 mount on 60s exposures. #backlash

Mike Ahner
 
Edited

On Wed, Jul 15, 2020 at 05:50 PM, Howard Dutton wrote:
On Wed, Jul 15, 2020 at 02:23 AM, Matt wrote:
I found that the 48 teeth pulley is not sitting properly and is wobbling when rotating.
This is a big deal.  If you can see it wobbling, it isn't going to track well.
Matt, I wonder if you have the wrong size bore hole for that pulley? It often seems the motor shafts & worm shafts are different sizes. That will likely cause an increase in periodic error but shouldn't make tracking slow.  (Sorry, I confused the other thread with this one) Perhaps the pulley bore is so big that it's not tightening down and slipping?

It could also mean the worm gear is bent or damaged somehow an so isn't straight.
-Mike


Re: Periodic error in an eq3-2 mount on 60s exposures. #backlash

Howard Dutton
 

On Wed, Jul 15, 2020 at 02:23 AM, Matt wrote:
I found that the 48 teeth pulley is not sitting properly and is wobbling when rotating.
This is a big deal.  If you can see it wobbling, it isn't going to track well.


Re: Vixen Great Polaris periodic error and slow tracking #backlash

Howard Dutton
 

On Wed, Jul 15, 2020 at 03:47 PM, Howard Dutton wrote:
On Wed, Jul 15, 2020 at 02:53 PM, <biggs@...> wrote:
16 and 60 teeth
I'd count those teeth, make sure it's not something else, like a 4:1.
The fact that both slews and tracking started working ~ +5% is telling us something I suspect.


Re: Vixen Great Polaris periodic error and slow tracking #backlash

Howard Dutton
 

On Wed, Jul 15, 2020 at 02:53 PM, <biggs@...> wrote:
16 and 60 teeth
I'd count those teeth, make sure it's not something else, like a 4:1.


Re: Vixen Great Polaris periodic error and slow tracking #backlash

Dave Schwartz
 

What Khalid said. In addition, if your motors are getting too hot it means your current/Vref is far too high.


On July 15, 2020 5:53:18 PM EDT, biggs@... wrote:
Hi all,

I have a Vixen Great Polaris that I've converted to OnStep and now finally getting things working properly.
I bought the mount second hand and it came with the original motors, hand controller and rotation encoders for the DSC computer.
The tracking always seemed a bit off even with the original motors, but I put it down to not being polar aligned and old motors.

Now I have OnStep installed with NEMA 17 400 step motors running at 24V and gears with 16 and 60 teeth for a 3.75 gear ratio.
I also now have an observatory, a pier and it's properly polar aligned.

After lots of investigation I found that I needed to increase the RA tracking rate by 5% to get objects to stay in the FOV.  I did this by increasing the steps per degree in OnStep.
I confirmed this fixed the tracking and the slewing in both directions by using the encoders as a reference.  I can now slew to targets and they are in the FOV.
But I don't know why the RA is 5% slow.  I don't know if it's friction or something slipping like the clutches.  The motor does get very hot while tracking.

Part 2 of the issue is that I have a very weird periodic error with a 4 minute period that doesn't match the 10 minute worm drive rotation, or the 160 second small gear rotation.
Below is a plot of a 30 minute run with 10 second exposures.  Anything longer and I get star trails.  I removed the residual linear drift that is still to be fine tuned.


Any advice on how to proceed would be appreciated.  I'm wondering if I need to disassemble the mount and regrease it, but not something I really want to have to do.

Thanks,
David

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: Vixen Great Polaris periodic error and slow tracking #backlash

biggs@...
 

Hi Khalid,

Thanks for your quick reply.  You are correct about the 19200 and the 48000 as the original steps configured.  I don't have Android but do use Ekos and Sky Planetarium for testing where I first did the rate adjustment.

I would say that when the clutches are off the movement isn't as frictionless as some mounts I've seen but seems smooth.  You need more than 1 finger but less than a hand.  When locked it doesn't move.

I'll check out the shafts and pulleys next time I'm at the mount.  I will also change the belts as I have multiple.  I'll make a video of the movement so I can review later.  Thanks for the video links and suggestions.

Cheers
David


Re: Vixen Great Polaris periodic error and slow tracking #backlash

Khalid Baheyeldin
 

On Wed, Jul 15, 2020 at 05:53 PM, <biggs@...> wrote:
Now I have OnStep installed with NEMA 17 400 step motors running at 24V and gears with 16 and 60 teeth for a 3.75 gear ratio. I also now have an observatory, a pier and it's properly polar aligned.
I am assuming that your spreadsheet looks like this:

400, 32, 3.75, 144 = 19200 steps per degree.
And steps per worm rotation is 48000.

Correct?

And one way to confirm that your ratio is correct is using Rafael's very simple method in this video.

After lots of investigation I found that I needed to increase the RA tracking rate by 5% to get objects to stay in the FOV.  I did this by increasing the steps per degree in OnStep.
That should not be the case.
But a better compensation strategy is to change the tracking rate from the Android app.

I confirmed this fixed the tracking and the slewing in both directions by using the encoders as a reference.  I can now slew to targets and they are in the FOV.
But I don't know why the RA is 5% slow.  I don't know if it's friction or something slipping like the clutches.  The motor does get very hot while tracking.
You can test the smoothness by unlocking the clutches, and rotating the RA axis using just one finger. If it moves easily, then there is no issue. Then lock the clutches and try again. The mount should not move (no slipping).

Part 2 of the issue is that I have a very weird periodic error with a 4 minute period that doesn't match the 10 minute worm drive rotation, or the 160 second small gear rotation.
Below is a plot of a 30 minute run with 10 second exposures.  Anything longer and I get star trails.  I removed the residual linear drift that is still to be fine tuned.
That secondary wave is indeed weird. Maybe a motor shaft is bent or eccentric?
Try swapping the motors and see if that makes a difference.
There is also the possibility of a pulley being eccentric.
For example, see this commercial mount with the smaller pulley wobbling.

Any advice on how to proceed would be appreciated.  I'm wondering if I need to disassemble the mount and regrease it, but not something I really want to have to do.
I don't think just regreasing will solve this.


Vixen Great Polaris periodic error and slow tracking #backlash

biggs@...
 

Hi all,

I have a Vixen Great Polaris that I've converted to OnStep and now finally getting things working properly.
I bought the mount second hand and it came with the original motors, hand controller and rotation encoders for the DSC computer.
The tracking always seemed a bit off even with the original motors, but I put it down to not being polar aligned and old motors.

Now I have OnStep installed with NEMA 17 400 step motors running at 24V and gears with 16 and 60 teeth for a 3.75 gear ratio.
I also now have an observatory, a pier and it's properly polar aligned.

After lots of investigation I found that I needed to increase the RA tracking rate by 5% to get objects to stay in the FOV.  I did this by increasing the steps per degree in OnStep.
I confirmed this fixed the tracking and the slewing in both directions by using the encoders as a reference.  I can now slew to targets and they are in the FOV.
But I don't know why the RA is 5% slow.  I don't know if it's friction or something slipping like the clutches.  The motor does get very hot while tracking.

Part 2 of the issue is that I have a very weird periodic error with a 4 minute period that doesn't match the 10 minute worm drive rotation, or the 160 second small gear rotation.
Below is a plot of a 30 minute run with 10 second exposures.  Anything longer and I get star trails.  I removed the residual linear drift that is still to be fine tuned.


Any advice on how to proceed would be appreciated.  I'm wondering if I need to disassemble the mount and regrease it, but not something I really want to have to do.

Thanks,
David


Re: Failed to init device yet again

Gerry Byrne
 

Drew,
Good suggestion. I'll work on that too tomorrow.
Gdrry

On Wed 15 Jul 2020, 22:12 Drew 🔭📷🚴‍♂️, <drewbolce@...> wrote:
On Wed, Jul 15, 2020 at 03:41 PM, Dave Schwartz wrote:
I'm going to assume that the COM port you are selecting in the IDE is the one that appears when you connect the CP2102.
A quick test to be sure something Arduino is on the selected COM port is to press the "Get Board info" selection under the Port. You can ignore the information itself, only a live port will open up the info box. No info box, you have the wrong port.


--
Copernicus


Re: Failed to init device yet again

Gerry Byrne
 

Dave,
Thanks for your detailed response. I Will check your suggestions on the Com issue. It is so obvious, I suppose. 
Tomorrow I'll also try a switch free flash.
Gerry

On Wed 15 Jul 2020, 20:41 Dave Schwartz, <Dave.Schwartz@...> wrote:
I'm going to assume that the COM port you are selecting in the IDE is
the one that appears when you connect the CP2102. Are you actually
selecting that from the 'Port' flyout ? Your picture doesn't show a port
as being selected. You have to actually select it, its not good enough
that it just be in the flyout list.

Let's eliminate that wiring harness to the flash-run switch. Go back to
using the original jumper. The existing yellow jumper on BOOT1 is where
it always stays, bridging the center and '0' end pins. Put the one on
the BOOT0 header... the same end as BOOT1 is the run position and the
opposite (bridging the center and '1') end pins is the flash position. I
believe the green LED should not be active when in flash mode because
not even the original blink sketch will be running in that mode.

On 2020-07-15 11:40 a.m., Gerry Byrne wrote:
> Dave,
> Yes, it's a brand new replacement STM32 and it flashed from the
> get-go, before I attempted to upload anything to it.
>
> I think you may have a point about the blink sketch (Drew makes a
> similar point). I never realised Arduino behaved like that. But would
> that completely explain the failure to initialise?
>
> Since writing earlier I did a circuit test on links between the CP2102
> and the STM board. One pin on the CP2102 appeared slightly loose with
> an intermittent circuit  between it and A10 on the Blue Pill and I
> re-soldered it and the connection is now perfect between RX, Tx and A9
> and A10.. But still I cannot upload.
>
> Here, in excruciating detail, is what I have been doing.
>
> I unplug everything. Move the switch to flash. Power up via the 5V
> supply on the PCB. Red LED lights, Green LED flashes.  Then plug USB
> from the laptop to the CP2102. Instruct the IDE to upload the Onstep
> sketch. It compiles and then goes into upload mode. It says "done
> uploading" but inspection reveals the "failed to init device" message
> again along with the other stuff about blink. I repeat by depowering,
> unplugging the USB and repowering and reinserting the USB plug
> followed by another attempt at uploading.
>
> My board settings are as in the attached photo. COM Port is not shown
> but it is COM 3 and this is confirmed by Device Settings. When I
> changed it to COM 2, the IDE went looking for COM 3 and I changed it
> back.
>
> I attach other pics attempting to show the switch connections to the
> Blue Pill.
>
> Many thanks for your interest.
> Gerry
>
>
>
>
>
>
>
>
>
> On 15/07/2020 15:05, Dave Schwartz wrote:
>> Is the flashing green LED the behavior of the STM32 before you have
>> uploaded anything to it? If so, that is normal because there is a
>> default blink program uploaded to it as a test step during
>> fabrication. All the ones I have had did that.
>>
>> I have no idea what the 'Invalid library' could be... not the
>> foggiest idea why something would be trying to access something from
>> the blink sketch an during OnStep build unless you have somehow
>> corrupted the OnStep directory with blink sketch code. A complete
>> wipe of the OnStep directory and refresh from the repository might be
>> needed.
>>
>> Please describe, in excruciating detail, the steps you are performing
>> when preparing the STM32 for the upload and restoring it to run mode.
>> Perhaps include detailed descriptions or a picture of how the
>> flash/run switch is connected to the header on the STM32 (or the
>> configuration of the jumpers if you are not using the switch). This
>> has been conquered by literally hundreds of people so there must be
>> something in the sequence that you are doing that is incorrect but
>> you don't recognize it because you've never seen it work
>> successfully. Nothing worse than having a procedure wrong and doing
>> it over and over expecting a different result because you haven't
>> realized a tiny error. Been there, done that.
>>
>> On 2020-07-15 8:24 a.m., Gerry Byrne wrote:
>>> I continue to receive the following error messages (see below this
>>> message) when attempting to flash the STM32 with Onstep.
>>>
>>> I have reloaded all the appropriate software libraries, etc, and the
>>> sketch compiles  without problems. Uploading is the problem.
>>>
>>> I have replaced both the STM32 Blue Pill and the CP2102 to no avail.
>>> My laptop now recognises the CP2102 and has allocated it to Com 3
>>> (previously I got a "device is faulty" message). It flashes red
>>> about four times when the USB is connected then remains a steady red.
>>>
>>> The new STM32 Blue Pill has a power light (red) on when the PCB
>>> power supply (5V) is connected. However it also has a rapid flashing
>>> green LED. Is this normal?
>>>
>>> Gerry Byrne
>>>
>>> Error Message:
>>>
>>> *Failed to init device *
>>> *stm32flash 0.4*
>>> *http://stm32flash.googlecode.com/*
>>> *Using Parser : Raw BINARY*
>>> *Interface serial_w32: 115200 8E1*
>>> *Invalid library found in
>>> C:\Users\gerbyrne\Documents\Arduino\libraries\blink: no headers
>>> files (.h) found in
>>> C:\Users\gerbyrne\Documents\Arduino\libraries\blink*
>>> *Invalid library found in
>>> C:\Users\gerbyrne\Documents\Arduino\libraries\blink: no headers
>>> files (.h) found in
>>> C:\Users\gerbyrne\Documents\Arduino\libraries\blink*
>>> --
>>> *Copernicus*
>>>
>>
>>
>>
>
>
>




--
Copernicus


Re: Failed to init device yet again

Drew 🔭📷🚴‍♂️
 

On Wed, Jul 15, 2020 at 03:41 PM, Dave Schwartz wrote:
I'm going to assume that the COM port you are selecting in the IDE is the one that appears when you connect the CP2102.
A quick test to be sure something Arduino is on the selected COM port is to press the "Get Board info" selection under the Port. You can ignore the information itself, only a live port will open up the info box. No info box, you have the wrong port.


Re: Failed to init device yet again

Dave Schwartz
 

I'm going to assume that the COM port you are selecting in the IDE is the one that appears when you connect the CP2102. Are you actually selecting that from the 'Port' flyout ? Your picture doesn't show a port as being selected. You have to actually select it, its not good enough that it just be in the flyout list.

Let's eliminate that wiring harness to the flash-run switch. Go back to using the original jumper. The existing yellow jumper on BOOT1 is where it always stays, bridging the center and '0' end pins. Put the one on the BOOT0 header... the same end as BOOT1 is the run position and the opposite (bridging the center and '1') end pins is the flash position. I believe the green LED should not be active when in flash mode because not even the original blink sketch will be running in that mode.

On 2020-07-15 11:40 a.m., Gerry Byrne wrote:
Dave,
Yes, it's a brand new replacement STM32 and it flashed from the get-go, before I attempted to upload anything to it.

I think you may have a point about the blink sketch (Drew makes a similar point). I never realised Arduino behaved like that. But would that completely explain the failure to initialise?

Since writing earlier I did a circuit test on links between the CP2102 and the STM board. One pin on the CP2102 appeared slightly loose with an intermittent circuit  between it and A10 on the Blue Pill and I re-soldered it and the connection is now perfect between RX, Tx and A9 and A10.. But still I cannot upload.

Here, in excruciating detail, is what I have been doing.

I unplug everything. Move the switch to flash. Power up via the 5V supply on the PCB. Red LED lights, Green LED flashes.  Then plug USB from the laptop to the CP2102. Instruct the IDE to upload the Onstep sketch. It compiles and then goes into upload mode. It says "done uploading" but inspection reveals the "failed to init device" message again along with the other stuff about blink. I repeat by depowering, unplugging the USB and repowering and reinserting the USB plug followed by another attempt at uploading.

My board settings are as in the attached photo. COM Port is not shown but it is COM 3 and this is confirmed by Device Settings. When I changed it to COM 2, the IDE went looking for COM 3 and I changed it back.

I attach other pics attempting to show the switch connections to the Blue Pill.

Many thanks for your interest.
Gerry









On 15/07/2020 15:05, Dave Schwartz wrote:
Is the flashing green LED the behavior of the STM32 before you have uploaded anything to it? If so, that is normal because there is a default blink program uploaded to it as a test step during fabrication. All the ones I have had did that.

I have no idea what the 'Invalid library' could be... not the foggiest idea why something would be trying to access something from the blink sketch an during OnStep build unless you have somehow corrupted the OnStep directory with blink sketch code. A complete wipe of the OnStep directory and refresh from the repository might be needed.

Please describe, in excruciating detail, the steps you are performing when preparing the STM32 for the upload and restoring it to run mode. Perhaps include detailed descriptions or a picture of how the flash/run switch is connected to the header on the STM32 (or the configuration of the jumpers if you are not using the switch). This has been conquered by literally hundreds of people so there must be something in the sequence that you are doing that is incorrect but you don't recognize it because you've never seen it work successfully. Nothing worse than having a procedure wrong and doing it over and over expecting a different result because you haven't realized a tiny error. Been there, done that.

On 2020-07-15 8:24 a.m., Gerry Byrne wrote:
I continue to receive the following error messages (see below this message) when attempting to flash the STM32 with Onstep.

I have reloaded all the appropriate software libraries, etc, and the sketch compiles  without problems. Uploading is the problem.

I have replaced both the STM32 Blue Pill and the CP2102 to no avail. My laptop now recognises the CP2102 and has allocated it to Com 3 (previously I got a "device is faulty" message). It flashes red about four times when the USB is connected then remains a steady red.

The new STM32 Blue Pill has a power light (red) on when the PCB power supply (5V) is connected. However it also has a rapid flashing green LED. Is this normal?

Gerry Byrne

Error Message:

*Failed to init device *
*stm32flash 0.4*
*http://stm32flash.googlecode.com/*
*Using Parser : Raw BINARY*
*Interface serial_w32: 115200 8E1*
*Invalid library found in C:\Users\gerbyrne\Documents\Arduino\libraries\blink: no headers files (.h) found in C:\Users\gerbyrne\Documents\Arduino\libraries\blink*
*Invalid library found in C:\Users\gerbyrne\Documents\Arduino\libraries\blink: no headers files (.h) found in C:\Users\gerbyrne\Documents\Arduino\libraries\blink*
--
*Copernicus*



Re: Periodic error in an eq3-2 mount on 60s exposures. #backlash

Matt
 

Alright, I'll look into it. Thank you!


On Wed, Jul 15, 2020, 7:03 PM Khalid Baheyeldin <kbahey@...> wrote:
You can measure the periodic error roughly by doing a very long exposure, with the least ISO on an area that has dim stars (e.g. somewhere in the Milky Way).

The exposure can be double the worm period. The worm period depends on the GR2 reduction (main worm wheel) number of teeth. It is basically the number of minutes for a full worm gear rotation.

For example, for an EQ5 with 144 teeth, it is 600 seconds. For a mount with 180 teeth, it is 480 seconds, and so on.

When you do the long exposure, it should show two sine waves (approximately).

See an example of how I did it in this thread, with images.