Jump to content

Narrowband

jbrazio

Members
  • Posts

    126
  • Joined

  • Last visited

Reputation

66 Excellent

Profile Information

  • Gender
    Male
  • Location
    Portugal

Recent Profile Visitors

1,806 profile views
  1. Thanks for your answers. I did tests with it well balanced and also a bit CW heavy just in case, same behaviour. If I remember correctly, if I raise the RA CC bar without any weight (and without any equipment on top) parallel to the horizon and let it go it would act like pendulum going back and forth until settling down with the bar perpendicular to the horizon. Yesterday when dismounting everything I tried it and the RA axis does not swing even once, it goes into a halt like 10º past the perpendicular to the horizon. Nevertheless if I try to move it manually, I don't have to do any special force in order for it to do a complete 360º turn on RA.. it is just not "as free" as I remember it to be before. It never produced any weird sound during the night, sound wise it was just as I remember it to be. I even used it with three different controllers: EKOS, EQMOD and Syntrek, all of them show the same erratic non-predictable behaviour. I used teflon based lubricant at the time and off the shelf KOYO sealed bearings which are supposed to be a good brand.
  2. Hi all, I have a NEQ6 with the belt mod for some time now, it always tracked well. The mount has been not used for over than 3y but has been always well kept at a home environment without massive temperature changes. Yesterday night I took it out, despite some clouds, just to get it working again. After going trough the Polar alignment routing in EKOS until both axis are in the green zone.. this was the result of a 120s exposure non guided using a DSLR with a 105mm lens. After a lot of testing with 60 and 120s exposures (without guiding) the error is inconsistent, some times it produces longer star trails, other times start almost fully round. I lost years of my life and gained a lot of white hair last night.. :-/ What could be causing this ? Thanks for your help.
  3. Due to popular demand and some work started by jkoenig72 Ardufocus now has support for manual focus using physical switches. You can operate it either manually or through ASCOM as the counters will always be in sync. The basic interface is two push buttons and one pot (speed adjust) but if you are using two motors you can add a third button to switch between the motors, it also support LED to display the active motor. After two years into "beta" I am on the last mile to release the official 1.0 version together with a new PCB layout. ardufocus.com
  4. Interesting design ! Never thought of mounting it this way.
  5. Hi yes motor cabling is kinda of agnostic because you can always tell the firmware which connection (pins) it needs to use using the config.h file. yes the latest fw is compatible as long as you don’t enable High Resolution mode and you have the capacitor on the reset line to prevent the DTR auto reset.
  6. Proper documentation is the hardest thing to build.. 🙂 I've been doing a lot of effort to give this project a proper documentation, I believe it's not ready for prime time but for sure has improved a lot. Have a look at https://ardufocus.com/ This will be the location with the most updated information around this project. Any [good or bad] suggestions are welcomed. Is that a world first ? This is my motorized OAG focuser. 🤓
  7. In the meanwhile [behind the scenes] I've been working at two major changes for Ardufocus. Introduce a new high-resolution position counter mode Finally implement the second motor driver on the same controller I've built a new focusing mechanism prototype which delivers next level precision basically reducing backlash and removing slippage from the equation. In theory using single stepping (which is the mode were more torque is available) you can archive sub micron move for each step.. I say in theory because the 28byj-48 stepper motor and it's internal gearbox is not the most accurate thing on the world. I would say a more conservative approach would be using a NEMA17 with no gearbox where each step would be in the order of 4 microns. You may now think about micro-stepping thus increasing the resolution per step i.e. by using a 1/4 microstepping each step can reach one micron resolution. The maximum step value allowed by the Moonlite protocol is 65535 steps (uint16), with my prototype bellow the physical movement of the draw tube will be only 12.8mm. My TS MonorailR96 focuser has a travel distance of 50mm or 256000 steps. Breaking the Moonlite protocol in order to use 32-bit positional counter means I need a new ASCOM driver and that's exactly what I have been baking. The driver will be backward compatible meaning it will automatically detect either the firmware is a original Moonlite or if it is an Ardufocus running at 16-bit or 32-bit protocol. The driver will come with a standalone graphical user interface to replace the standalone Moonlite tool. Switching to 32-bit will also allow to have single precision floating point temperature. For all the latest updates follow me or star and watch the Github project.
  8. And have less backlash.. that's why I used them in this project. But you're right the best possible solution would be to print hubs and use a belt avoiding printed gears altogether. BTW, in our plastic world.. they work nice even in PLA, here is a good channel about the topic:
  9. So here you have, the PCB and schematic files for Ardufocus ! Please note this revision is untested but it passes ERC and DRC. PCB size: 50x55mm
  10. Not a silly question. The Moonline protocol allows the activation of a temperature compensation feature but this is not implemented on Ardufocus, the reason why ? I find it useless.. the auto focus program should be the one handling the temperature compensation, just like SGP does. The thermistor still has an important role because you need to provide to the AF program the environmental temperature so it can temperature compensate (not that useful IMO) or automatically run the AF routine on each degree change.
  11. Sorry for the late reply but for some reason I'm not getting e-mail notification of the subscribed topics. @NickK In one hand powering down a stepper driver will make you lose accuracy exactly has you described, on the other hand leaving the driver in holding torque will make the motor heat. My main concern is not the driver itself but the motor, the 28BYJ-48 running at 12V gets pretty toasty. Has this is not a one size fits all situation I leave up to the user to choose by toggling MOTOR1_SLEEP_WHEN_IDLE. However there is a catch, you need to have full accuracy during an auto focus run, i.e. when you're moving on the focal axis and taking measurements and then moving back to the best position; you don't really need that much accuracy between runs, i.e. you auto focus now and then auto focus in one hour. For this reason even if you have MOTOR1_SLEEP_WHEN_IDLE enabled there is an undocumented flag that defines a timeout after the last move before the motor's power is cut, by default this is set to 5 seconds. This should be set to accommodate the time it takes for your setup to take a frame and analyse it before moving into the next position, this way your motor will be powered off during most of the session but still keep accuracy when it is really required to. If the changes required to make the DRV8825 work are as trivial as increasing the delay after a sleep instruction then I suggest the following: https://github.com/jbrazio/ardufocus/compare/patch/drv8825 @NickK could you please comment ? Thanks. @swaxolez in fact there are two versions of the 28BYJ-48, the ULN2003 driver board is the same for both models. You must power the driver board either with 5V or 12V according with the motor type you have, however you should not power a 5V motor with 12V.
  12. Fresh update, yesterday I've released Ardufocus 0.1e, the main changes are: - Improvement on the stepping procedure - Both A4988 and ULN2003 driver boards now provide exactly the same functionality - Implementation of acceleration profiles: No-acceleration, Linear, Trapezoid and S-Curve See changelog since last release. Please report back any issues you may have found.
  13. Happy new year ! Some fresh news to start the year. - Uploaded to Thingverse the .stl files to 3D print the controller enclosure. - After an overall code refactoring job the v0.1b has been released on Github. - Documentation improved a lot, it should not be clear what you need to do and how to do it by reading the README file and the config.h file. Important: Please have special attention if you're upgrading from a previous version of Ardufocus as the AREF has changed from External (3.3V) to Internal (1.1V), the physical wiring changed accordingly. You may need to modify your board layout before uploading the new version. PS: For the eagle-eyed ones.. yes, that on the left is a second focus motor output port, stay tuned. ;-)
  14. So you would like to have a "stepping profile" that would automatically switch between the micro-stepping modes ? This is interesting but is it an overkill ? Specially with your 100:1 setup. The setup I'm using has a 64:1 reduction on the gearbox and then the gears further reduce that 3:1, I don't feel the need to drive to focus motor other than full step mode, I get very fine precision focusing with SGP using 100 step per frame with a minimum of 9 frames it 99% of the time enough for the system to get the optimal intersection point.
  15. Hi Nick ! Which stepper driver are you using in your implementation ? Is it the DRV2285 ? I had yesterday night a request to support the DRV8834. The Moonlite protocol is not a gem, specially if you look at the second motor control.. it looks what it was.. a hack to something already existing, nevertheless is a well known and supported protocol. My intention was not to extend the existing protocol but to be a stand-in replacement for their control box and allow at the same time a low cost DIY entry to auto-focus. I thought about end-stops, which I believe have a special importance for remote observatory operation using Crayford focusers; Crayford focusers rely on friction between two polished surfaces, one being the control rod and the other one the flat zone on the tube itself, as there are no "sync notches" slippage will occur no matter what, the integral of the slippage during time will start to drift the focus point between sessions, that's why a end-stop or better a home-end-stop was something that already had crossed my mind and in fact the Moonlite protocol supports it with the "PH" command. If you intention is really to have end-stops (in and out) then I also believe no protocol extension is required, just behave like a "FQ" command stopping the motor and the position counter. But I'd like to have more information on the protocol extension you have built to make them work and all things INDI. :-) I will happily welcome you on board. > I couldn't see at the moment in the code is the stepping sync points when micro stepping You're right, I do support micro stepping but I do not change the way the step counter behaves (i.e. 4x 1/4 micro-stepping = 1 step on the counter), I always consider each micro-step a step (i.e. 4x 1/4 micro-stepping = 4 steps on the counter), this was basically because the step counter is a integer thus nor the software nor the firmware are expecting to receive floats. If your suggestion is when changing from 1/1 to 1/4 micro stepping the counter should be updated i.e. multiply by 4 then that's a really insightful suggestion which I will implement ! :-)
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.