Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

sgl_imaging_challenge_banner_solar_25_winners.thumb.jpg.fe4e711c64054f3c9486c752d0bcd6f2.jpg

jbrazio

Members
  • Content Count

    124
  • Joined

  • Last visited

Community Reputation

63 Excellent

3 Followers

About jbrazio

  • Rank
    Star Forming

Profile Information

  • Gender
    Male
  • Location
    Portugal
  1. 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
  2. Interesting design ! Never thought of mounting it this way.
  3. 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.
  4. 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.
  5. 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.
  6. 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:
  7. 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
  8. So here you have, the PCB and schematic files for Arduheater !
  9. No worries, I tend sometimes to take a while to respond because I receive no notifications from this forum (?), I'm also available @jbrazio. I never really shown my custom take on dew strips.. so here it go, the BOM for it is: 3D printed template Kanthal Resistance Wire 24AWG Kapton tape GX12-4 male & female connectors Wire & heat shrink tubing
  10. You're right, I was not thinking about the specs of the sensor but rather some "calibration value".. which in fact are the same thing. ? The values I use by default are pretty generic ones for the 10k NTC. The NTC resistance (THERMISTOR_NOMINAL_VAL) is 10000 Ohms (10k) at 25.0 ºC ambient temperature (THERMISTOR_NOMINAL_TEMP). #define THERMISTOR_NOMINAL_TEMP 25.0F #define THERMISTOR_BCOEFFICIENT 3950.0F #define THERMISTOR_NOMINAL_VAL 10000.0F I'm not familiar with the BME but the DHT sensor sends out a 40 bits stream of data with encodes directly the temperature and humidity values [plus a checksum], you just have to convert them into floats, there is no "tuning parameter(s)". But usually the error on these sensors are rather linear for a deterministic temperature range, if you need increased accuracy you may build a lookup table of offsets vs temp range. I believe for the application we are using it here one overall offset is more than sufficient. @adyj1 The NTC you provided is more than suitable. If you have a look at the datasheet you'll find the B coefficient value of 3470 or 3380 depending on the part number. http://www.eaa.net.au/PDF/Hitech/MF52type.pdf
  11. There is no "factory" tune for the temp probes (either the DHT or the NTC) instead I allow the user on the GUI to define offsets for them, so if you find that a particular sensor is out by 1ºC you just set it's offset and you're good to go. What is currently missing on the system is EEPROM support so all the parameters are kept.
  12. 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.
  13. Arduheater 0.3e released. See changelog since last release. Please report back any issues you may have found.
  14. 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.
  15. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.