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.

  • Announcements

    sgl_imaging_challenge_banner_widefield.jpg.36065d79cb2625eb299137a5b4432c96.jpg

rkc

Advanced Members
  • Content count

    115
  • Joined

  • Last visited

Community Reputation

34 Excellent

1 Follower

About rkc

  • Rank
    Star Forming

Profile Information

  • Gender
    Male
  • Location
    Worcestershire, UK
  1. The astrotrac does look interesting. I will go and look at some reviews...
  2. ... And I pressed the wrong button and it won't let me edit... I already have a Polarie and will certainly be taking that and a DSLR for wide field. I was looking for something that could handle a FSQ-85 refractor, ATIK filter wheel/OAG etc. Power is the other problem to consider, for sure.
  3. Thanks for the suggestions - I'll look at them. I already have a Polarie and will certainly be taking that and a DSLR for wide field. I was looking for something that could handle a FSQ-85 refractro
  4. I'm planning a holiday to a dark sky location where I may be able to do some astro-photography. Is there a mount available that would meet the following criteria: 1. Light enough (and robust enough) to take in a suitcase. 2. Equatorial 3. Accurate enough to be worth using for AP Any suggestions/experience gratefully received Richard
  5. The full code needs a lot of cleanup before I could publish it - but here's the ISR I use to track the encoder position: /* encoder routine. Expects encoder with four state changes between detents *//* This code will need changing for other boards and other pins *//* I use Arduino Micro */#define ROTA 2 // pin 2 associated with int0#define ROTB 3 // pin 3 associated with int1void setup(){ pinMode(ROTA, INPUT); pinMode(ROTB, INPUT); digitalWrite(ROTA, HIGH); // enable pullups digitalWrite(ROTB, HIGH); attachInterrupt(0, rotary_isr, CHANGE); attachInterrupt(1, rotary_isr, CHANGE);}volatile int rotary_position = 0;void rotary_isr(){ static int8_t stepsSeen = 0; static uint8_t old_AB = 3; //lookup table index and initial state uint8_t encport; //encoder port copy static const int8_t enc_states[] PROGMEM = { 0, -1, 1, 0, 1, 0, 0, -1, -1, 0, 0, 1, 0, 1, -1, 0 }; //encoder lookup table old_AB <<= 2; //remember previous state encport = ENC_RD & 0x03; //read encoder old_AB |= encport; //create index stepsSeen += pgm_read_byte(&(enc_states[( old_AB & 0x0f )])); if (stepsSeen > 1) { // two steps forward rotary_position += 1; stepsSeen = 0; } else if (stepsSeen < -1) { //two steps backwards rotary_position -= 1; stepsSeen = 0; }}
  6. I've been trying to understand how Bayer masks work (and the one in the Lodestar C is a little odd - CYMG2 I think). I had some images I took during a rare break in the clouds and was trying to see if I could pull any data out of them. I tried various different settings for the debater process in Nebulosity and in PixInsight, and some looked better than others, but I wasn't convinced any of them were "right", so today I did some experimenting with an image that I _knew" what the colours should be. i attached the Lodestar-C to a Canon lens and took a set of images at 500ms exposure of a stack of books (yellow, red and green) using both Lodestar Live (0.10) and Nebulosity3, and ran the images through the PicInsight batch CMYK debater process with each of the 8 possible offset values in turn, so that I would know for future reference what the "correct" values were. For the images from LodestarLive, it was pretty obvious what the right settings were - there were 4 that looked very grey, and 3 with false colour, but just one with approximately correct colour), which is what I expected. But for the images from Nebulosity, none of the 8 were correct. 4 were very grey, and 4 had vertical colour banding). I dug a bit further to try to see what the differences might be, and I noticed that the stated resolution of the fits files from Nebulosity was different (779 by 580) from the ones captured by Lodestar Live (752 * 580), the latter being correct according to the specs as far as I can see. So now I am even more confused than I was before. Has anyone else tried capturing from a Lodestar C using Nebulosity3?
  7. Lodestar Live and Yosemite OS

    I tried Lodestar Live with Yosemite today (but only on daylight subjects) - did not notice any issues.
  8. EQMac and Yosemite OS

    Does anyone know how well PixInsight works with a retina display - reports on the PixInsight forums seem a little mixed.
  9. Playing with LodeStar Live today with a view to using it as my "holiday" setup - one thing I noticed immediately during daytime testing is that the minimum exposure of 0.02 seconds is too long. With a sensitive camera live the Lodestar, and a fastish scope, even 0.001 seconds (the minimum that the SX Lodestar app supports) is a little too long, but is manageable with a suitable aperture mask.
  10. I built a focuser using almost precisely that setup - except I use a single rotary encoder, and the built-in push button on it cycles between fast and slow modes. Works very nicely. I should probably get around to cleaning up and publishing the source code sometime. Getting the rotary encoder to work smoothly was the tricky bit, especially with cheap encoders that generate quite a bit of bounce. Interrupts are the key here.
  11. Hmm, I find the reverse, I think. The issue really isn't getting it to track without slipping - so long as everything is well balanced that doesn't require much force on the clutches. I was trying to hold it in place as I disassembled everything at the end of the night, meaning it was temporarily out of balance as I removed bits from the scope. I should probably get into the habit of moving it to a "weights down" position before disassembly. Richard
  12. Thanks - some useful info there
  13. last night while trying to tighten the RA clutch on my AZ-EQ6 I managed to bend the lever and strip some of the thread on it - I think I had not properly screwed it into the hole in the "capstan". So firstly, a warning to any AZ-EQ6 owners out there to make sure that you screw the lever in properly before applying any force to it. And secondly, can anyone with an undamaged AZ-EQ6 RA clutch lever confirm what the thread is supposed to be on it - it seems like "almost" M6, but when I try to screw an M6 bolt into the capstan I am getting more resistance than I would like - that may be that the threads on the capstan are a bit damaged (in which case I'll put a tap in to clean them out) but it may also be that it's the wrong thread. Thirdly, does anyone know if the lever is available as a spare? I can probably rig something up with a bit of threaded rod and some nuts, but a proper replacement might be more comfortable. Richard
  14. losmandy G11 problems

    A stepper motor will behave like that if only one coil is firing - could just be a broken wire in the cable...
  15. OAG on an ED80???

    I happened across this http://www.365astronomy.com/lacerta-offaxis-guider-for-canon-eos-m48-thread-p-2217.html when looking for something else entirely - it looks like it might work (should fasten directly to the back of the FF/FR). Anyone tried it?
×