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_dslr_mirrorlesss_winners.thumb.jpg.9deb4a8db27e7485a7bb99d98667c94e.jpg

hdutton

Members
  • Content Count

    68
  • Joined

  • Last visited

Community Reputation

11 Good

About hdutton

  • Rank
    Nebula

Profile Information

  • Location
    Philadelphia, PA
  1. This is doable but annoying on the software side. You'd have to deliberately sync both axes positions by micro-stepping to (driver indexer) valid full-step positions before the switch to full-step. If on-the-fly mode switching is desired then this would need to be done in the middle of an acceleration ramp up.
  2. Now back on topic (apologies)... Is the Raspberry Pi able to step fast enough? [edit: you'd think a RPi running Python would be fast enough to not even need mode switching according to the GPIO Benchmarks] Wonder how much timing jitter too (poorly timed steps rob the motors of torque)? If you directly drive the worm of 896/897 tooth wheel gears with a 200 step motor you'll need to step at about 1 kHz to get to 2 deg/s when full-stepping. If you switch between tracking 16x and full-step before/after the slew there's going to be lots of noise/vibration at the slew start so switching during the slew is preferred. There are valid micro-step indexer locations for switching from 16x to 1x so that no steps are lost and you'll want to keep track of that. Switching from 1x to 16x (lower to higher) is ok at any step position. The stepper driver data-sheets cover this.
  3. In OnStep I use simple hw timers to keep things portable. I think it was that Library linked above I looked at a while back, used the PWM hardware in the Teensy M4 for higher performance, neat but not something OnStep really needs. Step rate limits, for two axes: Mega2560 (8 bit 16MHz) 31KHz step rates (steps are pulsed, all others are square wave.) STM32 (72MHz) 41KHz. ESP32 (2 x 240MHz) 62KHz. Teensy3.2 (96MHz) 83KHz. Teensy3.6 (180MHz) 250KHz. The Timer ISR's do step counting, tracking, direction change, backlash comp, u-step mode switching, etc. aside from just sending step pulses. Obviously, the basic 16 MHz processor - Nano / Uno / Mega - is not limited to about 4 kHz step rates. The AccelStepper library might be thus limited but not the hw. With an UNO etc. using just Timer1 for one output you should be fine to at-least 60KHz (pulse) or 30KHz (sqw.)
  4. Which I failed to get working alongside OnStep, fortunately I was successful with the onboard BT support.
  5. Not true, a lost step occurs when the rotor is displaced through a full step position. A small(ish) fraction of a full-step worth of rotor displacement won't be lost over and over and accumulate. Also more micro-steps generally are better, less vibration, smoother slews. Resonance, as in "ringing" about step positions, at moderate rpm's robs the motor of torque (even to the point of stalling) and fine micro-stepping helps to combat this (as can changing acceleration rates and drive current.) Generally more micro-steps is better as long as the driver/controller can handle the step rates. There is really little to no accuracy gain in micro-step positioning past 16X or 32X though. Arrg, moving one axis at a time? It's not like the synchronization can't happen on both axes essentially simultaneously. Your idea is basically what OnStep does though... OnStep "finishes" the goto then enters a mode where the tracking rates are adjusted +/- proportional to the delta between the actual axis position and the target (which are usually both moving for Axis1 and Axis2 in Alt/Az mode) in order to bring the actual position into very close agreement with the target. Naturally the target RA(HA)/Dec (and so target Alt/Az for Alt/Az mode) is constantly in motion (sidereal tracking) during the slew and until the synchronization is done. OnStep will run on the Teensy3.2, 3.5, and 3.6 (and some older obsolete models as well.) Thanks to Paul S's excellent libraries this took very little effort. The Teensy3.6 is the fastest of all OnStep supported platforms, easily besting even the ESP32 (2 core 240Mhz) an every way that counts (4x higher step rates at 250KHz vs. 62KHz for the ESP32 and it's faster at FP intense ops too.) The one area it doesn't beat the ESP32 in... price Counting the SMT pins on the back and analog I/O the 3.5 and 3.6 have over 60 pins available for I/O in one form or another.
  6. Aluminum's CTE is about 13 x 10^-6 m/m deg C. About 1.4m of circumference means 0.02mm length gain per deg.C Since each tooth is a bit over 1mm the proposed about 7mm gain in length would require heating by 350 deg. C. I really have no idea how this would work but guessing you mean mostly local heating of the band by the tap? Still seems unlikely that he'd reach anything remotely close to ambient+350C.
  7. On my LXD75 there's a long bolt that passes through the mount body from the back and holds the RA motor assy. in place.
  8. First, let me say that this project was a quick and dirty exercise in how fast I could get it done. I don't even use CSEP... I'm not following point 1 though. What is a "sensor driver". A driver in my mind is a library/code to access a given sensor device. You need that (even if it is "client side".) What is a "sensor controller". Is this the Micro-controller (Mega2560 or UNO in this case)? Sounds like you're saying that you don't need an ASCOM driver that the Micro-controller is sending data to ASCOM but my understanding of ASCOM says that's not how it works. An ASCOM driver talks to the Microcontroller that talks to the sensors. I'm not really interested in working on CSEP again but rather just want to understand if this is something worth looking into for my other projects or not.
  9. Are the sensors attached... it doesn't obey that setting except... #if defined(MLX90614_ON) && (defined(DS18B20_ON) || defined(DHT22_ON) || defined(HTU21D_ON))
  10. Join the OnStep Group, talk to users... https://groups.io/g/onstep
  11. Wow, the list of sensors really goes on forever. Arduino is very popular so lots of library support. I like to stick with I2C since it travels some distance with little trouble and two pins take care of everything. I use all of the following in one role or another: BME280, SI7021, MLX90614, BMP180, DS18B20 (1-wire)
  12. OnStep can optionally be configured to start tracking when powered up. A build with Wifi (by addon ESP8266) can use Android or iOS phone/tablet to control (via custom Android App or web site.) Bluetooth and the Android App are a second option but no iOS in that case. Wifi has the website and an IP channel so connections from PCs Windows/OSX/Linux/etc. are supported. Optionally a smart hand controller (SHC) with display can be built and things controlled from there (soon to be the best option, as firmware for it is still being worked on... though it adds to the cost a bit.) Cheap to buy EasyEDA PCB and a 3D printed case design are available for this. I use the SHC now since it's so much more convenient than a cell-phone... plugs into any OnStep ST4 port and does some fancy tricks to make a data connection (also powered from the ST4 port.) Any of the above can be used to start tracking/align, setup, park, etc, etc. Object catalogs (Bright Star, Messier, Herschel400, Planets, etc.) are available in the Android App and SHC. The lowest cost/easiest build OnStep is by using a 3D printer RAMPS kit. OnStep can be configured for full control of one of those including all 5 stepper drivers (two telescope axes and two focusers and a rotator control.) It also can control dew heater/accessory on,off using the RAMPS MOSFET heater drivers. The MKS Gen-L all in one (Mega2560+RAMPS) is probably the best low cost option since it has a crystal oscillator and supports 24V to the stepper driver section. More advanced hardware etc. exist too, just scratching the surface here. https://groups.io/g/onstep/wiki/home
  13. It's been an age since I've touched this code. Provided your configuration and hardware are good the only thing that comes to mind would be if Chart.min.js was updated and is no longer functioning as intended with my code. Github can be used to download an older version (from any repository) or grab the fork I made from about two years ago and try that... https://github.com/hjd1964/Chart.js
  14. Another vote for FreeCAD which is what I use for most of my design work. I use OpenSCAD too though, it's more of a "CAD by programming" type tool but can be really handy if you want a custom timing belt pulley, for instance. Just printed two of those for help in adding an Dec axis encoder to my old Meade LXD75.
  15. I wanted to mention that I learned of a possible solution to the problem of full tri-state control (of the CFG pins) of the SSS TMC2100 when it's directly wired into a MCU (the Teensy3.2/Arm M4 in my tests.) I recently was told by someone who tackled this very issue (on a different MCU) that the solution is to power the VIO pin of the SSS (where it gets it's reference voltage from) with an I/O pin of the MCU. I had it wired into the 3.3V VRM output of the Teensy3.2 and this isn't evidently the way to go. I haven't tried this yet so if someone has success please let us all know. Howard
×
×
  • Create New...

Important Information

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