Welcome, Guest. Please login or register.

Username: Password:

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jslight

Pages: [1] 2
1
DIY AstroEQ / Re: Reliable 12V connection?
« on: April 19, 2019, 05:29:11 »
I use XT-60 connectors made of Teflon, they work great and are somewhat hard to disconnect.

I personally use an XT-60 to barrel jack adapter; if you are going to solder one side directly to the AstroEQ, I recommend adding a knot in the cable before feeding it through the hole, in order to relieve stress on the solder joints.

2
AstroEQ Support / Re: AstroEQ and cg4 dual axis motor drive
« on: April 19, 2019, 05:11:55 »
I am using NEMA17 stepper motors that work great on my Celestron CG-4.  You can use them with either gears or belts/pulleys (the latter is recommended to reduce backlash).  NEMA14 motors would also work (smaller size).

Stepper specs (from https://www.astroeq.co.uk/tutorials.php?link=custommotors):
  • Rated Current: <1.2A per Phase
  • Rated Voltage: Lower voltage generally have higher torque, but can cause stuttering. Higher voltage (max 12V) will reduce stuttering issues.
  • Inductance: again, lower is better. Look for something <10mH per phase
  • Step Angle: typically 1.8 degrees or 0.9 degrees.

Based on my experience with my motors (5.4V), I would recommend finding motors with a voltage rating close-ish to, but lower than, the voltage supply you are using (e.g. ~9-11.5V motors w/ 12V supply); you don't need the extra torque with a CG-4.  Also, I would recommend using 0.9 steppers if you are doing lots of astrophotography, 1.8 steppers if you want higher top speeds.  OMC Stepper Online has a good selection.

Probably the more difficult part is making the mounting brackets; personally, I just cut pieces of L-angle aluminium and drilled holes (easy  ;D).

3
AstroEQ Support / Re: EQMod not responding after firmware upgrade
« on: September 10, 2018, 14:58:10 »
Moving the mount West should always travel the same direction as sidereal tracking.
If it is traveling/tracking in the wrong direction, reverse the RA axis using the AstroEQ Config Utility.

North and South can be a tad bit confusing because the direction the mount should rotate depends on which side of the pier the telescope is on.
One option here is to use the EQASCOM Reverse DEC checkbox when flipping pier sides so that North commands actually travel North.

An easy test can be done by pointing the telescope up towards the zenith with the telescope itself on the East side of the mount.  From there, try moving a bit West while watching if the mount travels the correct direction.
Then try moving a bit North while watching the mount; if it moves the correct direction, then current Reverse DEC checkbox setting works while the telescope is on the East side of the mount, toggle the checkbox when flipping the telescope to the West side of the mount.

Also note that all directions are usually inverted when looking through an eyepiece.

4
AstroEQ Support / Re: Guiding problems on DEC with INDI
« on: September 09, 2018, 22:14:36 »
There is a serious problem with v8.13 and v8.14 firmwares, ASCOM/INDI will freeze after the first operation command is sent.  I manually recompiled these versions from the same source code and everything works fine, I think there's something wrong with your compiler.

After manually recompiling, I had two flawless nights of observing and photographing (with KStars/Ekos/INDI).  I was actually able to capture a 20 minute, single exposure of M31 (Andromeda Galaxy) with guiding accuracy below 2 arcseconds; before this, the longest exposure I had ever been able to take was 2 minutes.  Here is the unedited exposure:

5
AstroEQ Support / Re: EQMod not responding after firmware upgrade
« on: September 09, 2018, 22:10:21 »
There is a problem with the compiled version of 8.13; I was having the same problems this weekend after upgrading, ASCOM or INDI would lock up after sending the very first command to the AstroEQ.  I downloaded a fresh copy of the Config Utility and reflashed v8.12 (don't click Update Firmware), everything was working again.

6
AstroEQ Support / Re: Guiding problems on DEC with INDI
« on: September 06, 2018, 06:45:36 »
I did a series of testing using Stellarium (plus StellariumScope) via EQASCOM on Windows: slews, gotos, highspeed/lowspeed, and tracking all seem to work correctly still.  I believe the Windows EQASCOM driver was sending the :G command before all (or almost all) :J commands, and therefor working around the problem.

As posted on GitHub, I tested the functionality using Linux, everything seems to have been fixed.

I'm volunteering for a camp out this weekend with the local Astronomical Society, I'll let you know if I notice any other issues.

7
DIY AstroEQ / Re: RA tracking speed
« on: September 05, 2018, 16:59:07 »
I think it is my driver on the RA itself as when I swap them on the board the motor speeds also swap.
Yep, that's definitely the problem then.

The steppers themselves are 0.8A rated with suggested voltage of 12V. I do find it difficult to set the current limit so the motors can turn with out getting too hot. 0.4V on the vref doesn't always seem to be able to turn it. I could get higher amp rated steppers.
An unmodified AstroEQ has a maximum limit of 1.2A steppers, 0.8A should work well (my steppers are 0.8A).  It might be the 12V rating, that is, if you are powering the AstroEQ with a 12V PSU, then the Stepper Drivers can't perform their current limiting because the stepper needs the full PSU voltage to even draw that current to begin with.  You could test this with a slightly higher input voltage (15V maximum according to this post by Tom https://www.astroeq.co.uk/forum/index.php/topic,259.msg1672.html#msg1672).


P.S.  Additionally, too low of a stepper voltage rating (less than ~50% of input voltage) is known to sometimes cause stuttering/ticking problems with DRV8825 drivers (see https://www.astroeq.co.uk/forum/index.php/topic,80.0.html).  This effect can be diminished by lowering the input voltage (9V minimum), changing the decay mode, or adding the diodes in series with each stepper phase.

8
DIY AstroEQ / Re: RA tracking speed
« on: September 04, 2018, 23:19:41 »
Also I cannot get my head round which way the mount revolves when jogging east west, North south with eqascom. If it could be described as revolving clockwise or anticlockwise when turning in ra and Dec when viewed from counter balance arm when the scope is parked pointing to nip that would be great.
Moving West should always travel the same direction as sidereal tracking.
If it is traveling the wrong direction, reverse the RA axis using the AstroEQ Config Utility.

North and South can be confusing because the direction to rotate depends on which side of the pier the telescope is on.
The best option here is to use the EQASCOM Reverse DEC checkbox when flipping pier sides so that North actually travels North.

9
DIY AstroEQ / Re: RA tracking speed
« on: September 04, 2018, 22:57:31 »
Actually, 14 seconds would be 16x too fast.  It sounds like the Stepper Driver ICs are not switching to the correct mode (1/2 instead of 1/32, or full instead of 1/16).  Make sure you have the correct Stepper Driver IC selected in the Config Utility; also verify you soldered the two jumpers on the PCB for the correct model of Stepper Driver IC and the connections from the microprocessor to the mode pins are good.

10
DIY AstroEQ / Re: RA tracking speed
« on: September 04, 2018, 19:22:27 »
I think it may be moving too fast, it takes just under 14 seconds for the RA stepper to rotate once when at sidereal speed, is this correct please?

The EQ5 mount has a 144:1 worm gear ratio for both axes.  360 / 144 = 2.5, the angle of mount movement with one revolution of the shaft.  If you are using the 40 and 15 tooth pulleys from the FAQ (with the 40 tooth pulley on the mount shaft), then 2.5 / 2.6666667 = ~0.9375, the angle of mount movement with one revolution of the stepper.

Sidereal rate ≈ 1 / 4min.  So it should take about 3 minutes and 45 seconds for a full stepper revolution at sidereal rate.

The default values of the EQ5-Custom-Pulley.conf are correct for this configuration, make sure you also have the correct Motor Driver IC selected (defaults to DRV882x).

As far as microstepping, it shouldn't make much difference regarding sidereal tracking, it's more about how fine the resolution of nudges can be while guiding.  Ideally you want to use the highest number your Motor Driver IC supports and enable Gear Changing (these are the defaults).

What are the Voltage and Phase Current specifications for your steppers?
Are you using the AstroEQ with Windows/ASCOM or Linux/INDI?
Which version of the AstroEQ firmware are you using?

11
DIY AstroEQ / Re: Astoeq tracking pause every seconds.
« on: September 02, 2018, 20:44:20 »
The diode modification works well to smooth the ticking when using low current, low voltage steppers and DRV8825 drivers.

I used two bridge rectifiers (four diodes inside) per motor instead of eight diodes; just tie the DC legs (+ & -) together, then wire the AC legs (~) in series with only one side of each phase.  The rectifiers got hot as expected, but nowhere near dangerous levels, just make sure they are rated for the phase current of your steppers.

12
AstroEQ Support / Re: Guiding problems on DEC with INDI
« on: September 02, 2018, 01:36:28 »
Yep, this seems to work.  I tested that all the problems we have been working on haven't relapsed; I also tested repetitive and alternating highspeed slews, lowspeed slews, highspeed gotos (far), lowspeed gotos (close), and tracking.  This could still affect other areas (such as ASCOM or standalone mode), I'll submit the changes to your github branch.

13
AstroEQ Support / Re: Guiding problems on DEC with INDI
« on: September 02, 2018, 01:04:19 »
LOL, we've gone full circle.  The motorStopRA/DC calls are resetting the GVal back to lowspeed slew mode, but doing so while the motors are running, so the change isn't effected until :J is called, causing :f responses to make INDI EQMod still think we are in the correct mode, thus not sending :G.
Code: [Select]
            if(readyToGo[RA] == MOTION_START_REQUESTED){
                //If we are ready to begin a movement which requires the motors to be reconfigured
                if(cmd.stopped[RA] == CMD_STOPPED){
                    //Once the motor is stopped, we can accelerate to target speed.
                    signed char GVal = cmd.GVal[RA];                      <------------------this has been reset to 1
                    if (canJumpToHighspeed){
                        //If we are allowed to enable high speed, see if we need to
                        byte state;
                        if (motionIsLowSpeed(GVal)) {                       <-------------------therefor this is true
                            //If a low speed mode command
                            state = modeState[SPEEDNORM]; //Select the normal speed mode
                            cmd_updateStepDir(RA,1);
                            cmd.highSpeedMode[RA] = false;
                        } else {
                            state = modeState[SPEEDFAST]; //Select the high speed mode
                            cmd_updateStepDir(RA,cmd.gVal[RA]);
                            cmd.highSpeedMode[RA] = true;
                        }
                        ...
Only reset GVal if it was previously in GOTO mode?

14
AstroEQ Support / Re: Guiding problems on DEC with INDI
« on: September 02, 2018, 00:48:16 »
Side-effect #1:
Repeated slews at highspeed in the same direction are toggling the highspeed flag, resulting in alternating highspeed/lowspeed slews.  It seems to be happening when :J is received, or at least that's when :f returns such.

15
AstroEQ Support / Re: Guiding problems on DEC with INDI
« on: September 01, 2018, 23:42:53 »
Wow, that was quick!

That definitely fixes the problem.

it would require that a :G command is never issued while the motors are running. I believe that is the case, but I'm not 100% certain.
I also believe this is the case.  It seems to be just with initialization that :G it sent without :J; nice solution.

I'll do some usage testing tonight if the winds cooperate.

Pages: [1] 2