Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Losmandy_users
- Messages
Search
Re: Valid Guide Rates for PEC on Gemini Level 4
On Tue, Aug 18, 2020 at 11:20 AM, Michael Herman wrote:
Michael, there are two steps and you keep talking only about the first one. Step one is recording PE data, the other is programming it into Gemini. Recording data into Gemini requires knowing the guide rate, otherwise Gemini doesn't know the size of the corrections you are sending. |
Re: Valid Guide Rates for PEC on Gemini Level 4
Ray,
You seemed pretty stubborn about me being wrong about the move distances being different between East/WestThe issue with PEMPRO is not the difference between East and West moves, but I don't want to get off topic. According to your PDF when you had mismatched guide and PEC rates you observed drift.The report does not say that. The mount reports its state as slewing periodically and momentarily, but there is no change in drift. I assume that because the PEC divisors are different than the guide divisors, the mount reports its state as slewing at each PEC correction, but there does not seem to be any other side effect. Have you tried measuring drift with mismatched guide/pec rates?I did measure the drift with the same PEC curve and different guide rates and the drift in RA does not change (approximately 1 arcsec/min). Hopefully someone else can measure their residual PE/drift at different guide rates using the same PEC curve so we have more than one sample. Eric |
Re: Valid Guide Rates for PEC on Gemini Level 4
I still think it's a mis translation or a mis statement. I think the statement should be: ? ...the PEC data is recorded at the present Tracking speed.... It cannot be guide speed since there is no guiding being performed during PEC recording.? But Tracking rate surely would affect the PEC recording, since that determines the RA rate of speed and the corrections are matched to the worm rotation period.? ? So in recording PEC data, I'd avoid using King rate, etc...just stick to Sidereal.?? Stay well, ... Michael? On Tue, Aug 18, 2020, 7:13 AM Brian Valente <bvalente@...> wrote:
|
Re: G11 Mount Not Tracking Correctly
In addition to verifying that you are not in lunar or solar, make sure that your dec wire is in fact to dec and RA to RA.? Sounds stoopid but I have confused the wires more than once.
Sometimes the wires are OK but one is not completely plugged in. I would only use GPS if you can't see Polaris. |
Re: Valid Guide Rates for PEC on Gemini Level 4
I still cannot get PEMPRO to work with my mount, but I wrote my own PEC programming software :)PEMPro works well on other Gemini equipped mounts if you follow the directions. You seemed pretty stubborn about me being wrong about the move distances being different between East/West, so maybe you didn't follow the directions? You state "the Gemini firmware is using the current guide rate instead of the rates defined by the divisors".You should get some correction when the rates are different, but not the best possible correction. The more severe effect is the extra drift introduced, which can cause poorer autoguiding RMS than if you turned PEC off. The first time I noticed this is when I forgot to match the guide rate toAccording to your PDF when you had mismatched guide and PEC rates you observed drift (mount would indicate "slew"). I've definitely seen logs where there has been extra drift when the rates do not match. I don't have a mount myself to test with but others can try this test. There is always the possibility that there has been a firmware change to account for this. Have you tried measuring drift with mismatched guide/pec rates? -Ray Gralak Author of APCC (Astro-Physics Command Center): Author of PEMPro V3: Author of Astro-Physics V2 ASCOM Driver: -----Original Message----- |
Re: Valid Guide Rates for PEC on Gemini Level 4
Ray,
I still cannot get PEMPRO to work with my mount, but I wrote my own PEC programming software :) You state "the Gemini firmware is using the current guide rate instead of the rates defined by the divisors". However, as I described in my previous post, this is not my observation. I can change the guide rate to any value, it does not change PEC behavior. The first time I noticed this is when I forgot to match the guide rate to the currPEC rate and collected residual PE data. The residual PE with PEC ON was well corrected regardless of the guide rate. Do you have data that shows that the guide rate affects PEC? That behaviour does not match my mount. Eric |
Re: Valid Guide Rates for PEC on Gemini Level 4
>>>
Also, note that serial command 502 always returns 0.5, regardless of the actual guide rate used to train PEC, so it cannot be used to determine the PEC rate; you have to look at the clock divisors in thew currPEC.pec file to determine the PEC rate. this was the part i remembered about something in Gemini always returning 0.5x On Tue, Aug 18, 2020 at 6:02 AM Cyclone <148cyclone1@...> wrote:
--
Brian? Brian Valente portfolio |
Re: Valid Guide Rates for PEC on Gemini Level 4
>>>
Periodic error correction pulses are recorded and stored?at the current guide speed?by Gemini, regardless of how PEC is programmed yep - glad you guys added some meat to that bone On Tue, Aug 18, 2020 at 5:36 AM Paul Kanevsky <yh@...> wrote: On Mon, Aug 17, 2020 at 08:23 PM, Ray Gralak wrote: --
Brian? Brian Valente portfolio |
Re: Valid Guide Rates for PEC on Gemini Level 4
Eric,
I recall our discussion on the CCDWare forum last year, where you didn't believe me that the PEC move distance was different between east and west moves. I am glad to see you now understand. :-) Based on my observations using my G11 with Gemini 2 in the past few years, the guide rate does not affectYes, at mount boot time, the Gemini firmware reads the PEC data, and the PEC table is calculated/loaded. However, I don't think that changing the guide rate after booting recalculates the PEC table. If the Gemini firmware does not recalculate the PEC table there can be two effects at guide rates different from the guide rate at boot time: 1) Playback of the PEC data is not as effective (i.e., under or over-emphasized) 2) There may be RA drift, which might be why in your document you say you wrote: However, I have observed that when the PEC clock divisors and the current guide rate do not match,This implies that despite the rate divisor values in the PEC table, the Gemini firmware is using the current guide rate instead of the rates defined by the divisors. -Ray Gralak Author of APCC (Astro-Physics Command Center): Author of PEMPro V3: Author of Astro-Physics V2 ASCOM Driver: -----Original Message----- |
Re: G11 Mount Not Tracking Correctly
Sorry to read of your headache getting proper performance. It seems that your G11 has a very light payload, as your lenses seem very light compared to the strength of this G11 mount.? So? something is mis-set... let's try a checklist to "round up the usual suspects" to steal a line from Casablanca. 1. COLD BOOT your Gemini.? ?You have not mentioned this, so I'll put it first on the list.? Remember that the Gemini always reads its Model values and offers first to Warm Boot.? The Model parameters are a bunch of corrections to a perfect mount.? The values consist?of error corrections for polar alignment, counterweight bar flex, errors in AZ and ELevation.? Warm Boot sounds like a great idea, if you have not moved anything.? But as soon as you shift anything...the Elevation knob, the AZ rotation, to polar align, the prior model data is worthless?and even worse... the mount will be making the wrong corrections.? So when any pointing goes awry, first suspect the Model data is bogus.? Do a Park at CWD, torn off the Gemini, and reboot it in Cold Boot mode. 2. Is something slipping?? It sounds absurd that such a strong mechanical system could ever slip, but if you've ever tried to drive a car with a worn out clutch, you know the problem.? The clutch system uses thick plastic disks, one each in RA and one in DEC, to hold position.? You can clean these disks rather easily, but it means removing your scope first, then counterweights and bar, then pulling out the DEC axis from the RA axis, then pulling out the?RA axis from the mount head.? Then yank out the clutch disks, cleaning them and the metal mating surfaces in something like isopropyl alcohol. while those 1.25 inch shafts are out, it's sensible to see if you can rotate the needles of the needle bearings with your finger.? If those are sticking, due to "gummed up" old lubricant, it is time to use some nasty degreasing chemical to remove all the old grease. [Nasty means it must be done outdoors with rubber protective gloves and a face mask...something like an automotive degreaser like Berryman B-12 works well...you spray in some of that and catch the residue in a metal bucket...this stuff will dissolve a plastic bucket.? ?Just be very careful.]? ?I'll add that I make a high friction clutch disk for our mounts that holds much better than the stock plastic clutch pads and also retards or prevents oil migration on to those plastic and metal clutch surfaces.? Let me know if you need such things.] 3. Other things can get loose and move or shift.? Be sure to tighten down your RA and EL hold down bolts after polar aligning!? The stock thumbscrews are 3/8-16 thread.? They have only got flat washers under the bolt head.? When you loosen those AZ bolts, the mount head is only held by a central rotation bold under the middle center under the mount head.? That likewise also only has a flat washer...or even No washer at all.? So I put in (you guessed it) 3/8 Belleville spring washers bounded by flat washers in those 3/8-16 bolts locations.? Then when you loosen the AZ or EL, the bottom bold is always being held with some spring force in the bottom center, and the AZ bolts also have some now-adjustable force to hold the AZ in position.?? 4. I found one of my tripod legs was slightly?slipping?length over time.? The problem was the heavy weight of my scope, and the huge hand knobs that hold the legs position started to loosen over time and temperature.? Be sure those legs adjusters are really tight.? This was the last thing in the world that I ever suspected...in your case, with such? a light load on the mount, it seems unlikely but I'll leave it on the checklist.?? 5. Others already mentioned that the data entry for Latitude and Longitude use a decimal point entry.? But it is NOT a decimal point!? It is instead a European style comma!? So you enter Degrees.Minutes? ?not Degrees.Fraction.? ?(If your minutes are near zero, of course, it will not matter.? I can't imagine what devilish havoc is caused if you enter something?over 59 in the degrees entry...maybe you can't?? Something like longitude "122.97" ?? )? (No... IO won't try that to see!) 6. The polar scope...? ?this is a wonderful invention.? But it is prone to difficulty.? The Losmandy style polar scope is better than others like the one in the Orion Atlas/Synta EQ6... but none of them are perfect.? The problem is that the glass "reticula" is held by 3 tiny metal screws that must always be somewhat loose from the round glass reticule plate inside.? If too tight,the glass will get cracked.? As you rotate the RA or the plasr scope around to get the stars lined up,, the glass plate can shift and mess up the visual point of the NCP (or SCP) point.? So I use a drift align to follow up and check polar alignment?before deep sky imaging.?? There are other polar alignment gadgets these days that are highly praised.? I don't yet have one but it's on my shopping list.? Another local group member came by to pick up a Gemini-1 I just fixed for him, and he told me he has some recommendations for this... as others?on this forum have praised.?? 7 As Paul mentioned in his following email, beware of GPS data.? I always hand enter UTC time, not local time.? [The entry coding is:? YYMM.DD?HH:MM:SS? like 2008.18 20:15:59? ] you mentioned that you checked and found your local time was UTC -5 hours.? That's nice to see, but given the crazy way daylight savings time dates get changed these nutty times, always enter only the UTC time (from a website giving the current UTC time of course).? And if your Latitude and Longitude are correct, the local sidereal time (LST) will be correct.?? 8. Related to this is the problem with some GPS units (namely older GPS models don't' read the latest GPS codes right and get the wrong UTC time or maybe wrong position data.? There was a whole?discussion of this problem... leading some to say their old GPS unit could not read the latest satellite information being sent.? Anway, the bottom line is:? also suspect GPS provided information and double check that.? ? 9. As Paul mentioned (in the email following), you?may easily have left your Gemini?in some tracking mode like Lunar, or maybe Solar (we have sunspots again, yeah!).? So double check the tracking rate is really Sidereal.?? That's about it... try this checklist first, and let us know if the problem went away! All the best, Michael On Tue, Aug 18, 2020 at 2:43 AM Jamey Jenkins <jameyljenkins@...> wrote:
--
|
Re: Valid Guide Rates for PEC on Gemini Level 4
Good morning all,
Based on my observations using my G11 with Gemini 2 in the past few years, the guide rate does not affect PEC once a PEC file is loaded. The currPEC.pec file contains all the information required for PEC to run independently of the guide rate. Also, note that serial command 502 always returns 0.5, regardless of the actual guide rate used to train PEC, so it cannot be used to determine the PEC rate; you have to look at the clock divisors in the currPEC.pec file to determine the PEC rate. Attached is the first section of a draft document I am writing on guiding and PEC. Eric |
Re: Valid Guide Rates for PEC on Gemini Level 4
On Mon, Aug 17, 2020 at 08:23 PM, Ray Gralak wrote:
That's incorrect if you are using an autoguider to program PEC data. The autoguider keeps the star centered so it MUST send pulse guide commands via the ASCOM interface. The Gemini moves the mount and keeps track of the movement at that autoguider rate. What gets stored are indicators to move forward or backward (at autoguider speed) at each internal clock "tick".Ray is exactly right. This is what I was trying to say, albeit a little less clearly :) Periodic error correction pulses are recorded and stored?at the current guide speed by Gemini, regardless of how PEC is programmed. If you change the guide rate later, the pulses will no longer match the speed and the result will be overshoots or undershoots by PEC. Both not desirable. |
Re: G11 Mount Not Tracking Correctly
Hi Doug(?)
It sounds like your polar alignment was too far off if tracking is trailing at short focal length in a matter of minutes. The other possible reasons for this: wrong tracking rate selected in Gemini (should be Sidereal), wrong mount type selected resulting in the wrong tracking speed, or something is very loose in your imaging train causing image to shift as the mount tracks.? I'd investigate these first. GPS, time and coordinates are all important for a better initial goto, but not important at all for tracking at Sidereal rate. Regards, ? ? ?-Paul |
Re: G11 Mount Not Tracking Correctly
I had a similar problem with my G811g earlier this summer. I had input the longitude and latitude in decimal form rather than degrees. When I switched to degrees it has worked fine since. I'd try there first...if not that I'm sure the wizards on here will have the solution. Jamey On Tue, Aug 18, 2020, 5:29 AM <dougwheeler90@...> wrote: Hey everyone, first post here. |
G11 Mount Not Tracking Correctly
Hey everyone, first post here.
I have used the G11 mount before and had success with it, but this past weekend, it seems like no matter what I tried, I could not get the alignment correct. ?I purchased the GPS attachment thinking that would make things more accurate and simple, but that didn't seem to help. ?After setting up my mount, I aligned it due north with a compass and waited for sunset to align with Polaris using the polar scope. ?The app I have on my phone to match the reticle never seems to be in the same position when looking through the reticle of the polar scope, but I've never had difficulty aligning before. ?So after aligning Polaris between the correct lines in the reticle, I fired up the mount and used quick start. ?I verified the GPS data with another source and verified the time zone UTC -5, or Central Daylight Time, and ensured the time was also correct, and it was. ?However when using the two bright stars to perfect the alignment, (typically I use Vega and Deneb), the GoTo was way off. ?It would slew but point in totally different directions for either star. ?After using the buttons to slew to the correct position, it still would not go back to the correct spot and then trying to slew back to Polaris did not even work. ?I put everything back in the correct position with CWD and all that, all my cameras pointing at Polaris and tried again using Vega and Arcturus, and then Arcturus and Dubhe and never got good results. ?All my images ended up with trailing and I was using short focal lengths with relatively short shutter times of 3-4 minutes. ?I have previously done 8 minute exposures and had no trailing whatsoever at 24mm focal length on a 35mm full frame. ?For this past weekend I had three cameras mounted and balanced, with an 85mm lens, a 24mm lens, and a medium format camera with 23mm lens (18mm full frame equivalent). I wanted to also do a series of Andromeda with my 600mm lens, but that would have been out of the question since I was getting trails at short focal lengths. Any recommendations for how to fix this? ?Honestly, even if the GoTo doesn't take me to the exact position, I'm fine with using the buttons to slew to where I want to go, but I at least need it to track properly. |
Re: PEC Curves vs. Payloads
Thanks Brian. I will check to see if I saved my PHD logs in a usable fashion. Please note the guiding is better with the heavier payload, which is the reverse of the that rule of thumb thing. I always recheck the brain in PHD2 to make sure the camera pixel width, and focal length are correct. The 80mm guide scope has a third? Losmandy scope ring around the focuser outlet, whereas the 50mm does not, so flexure might be a factor.
|
Re: PEC Curves vs. Payloads
As an added thought, balance will affect overall performance. so of course you want to make sure whatever you are using is reasonably balanced Brian On Mon, Aug 17, 2020 at 5:46 PM Brian Valente via <bvalente=[email protected]> wrote:
--
Brian? Brian Valente portfolio |
Re: PEC Curves vs. Payloads
Hi John I don't think weight has any effect on the periodic error. It would probably help if you uploaded some representative PHD logs to review, who knows why one is better than the other. It's possible it could be the smaller guidescope, but could also be how the guiding assembly is attached, the configuration of your guiding parameters, etc. On Mon, Aug 17, 2020 at 5:38 PM John Kmetz <jjkmetz54@...> wrote: Hello all: --
Brian? Brian Valente portfolio |
PEC Curves vs. Payloads
Hello all:
The recent discussions on PEC curves had led me to some thinking. Do I need to redo the PEC curves when I change payloads? During the winter I primarily use my Celestron C925 Edge HD, especially for galaxy season. And then in the summer I switch to my Explore Scientific ES102mm, for capturing nebulae. As a rough statement I will say the the latter apparatus with counterweights is only half the weight of the former. With the C925 I use an 80mm guide scope with the ES102, a 50mm guide scope. The G11G (w. Gemini 2) I'm using has a one piece worm as far as I know, but I have yet to take it apart in my 3 years of ownership. Often my best guiding with the C925 is around 0.5 arcsec, while with the ES102 it is about 0.7 arcsec. My assumption was that the smaller guide scope would lead to greater guiding error. But now I am considering whether the total weight could effect the way the gears mesh together, strain on the motors, effects from load balance, etc. PEMPro is where I get my curves which are then uploaded to the Gemini 2 unit. The best answer would be better safe than sorry and just redo. But other payload combinations are also used and I'm wondering how much weight change makes a difference. Any suggestions or thoughts would be appreciated. I go east heavy in RA, and camera heavy in Dec. Guiding is about the same on either side of the meridian, and best closer to zenith. Thanks, John |
Re: Valid Guide Rates for PEC on Gemini Level 4
I think Paul's ideas might be close to the mark. I still don't quite "see" the issue in my mind's eye yet.That's incorrect if you are using an autoguider to program PEC data. The autoguider keeps the star centered so it MUST send pulse guide commands via the ASCOM interface. The Gemini moves the mount and keeps track of the movement at that autoguider rate. What gets stored are indicators to move forward or backward (at autoguider speed) at each internal clock "tick". Gemini PEC data is recorded based on the autoguide speed. If you change the autoguide speed after collecting periodic error playback will be either under or over-emphasized. Also, when recording and averaging multiple cycles via an autoguider there are other problems besides seeing. You are also inherently introducing phase error from camera delay as well as potential periodic error from uncorrectable frequencies (like the 3.15x frequency). This will lead to an inferior PEC curve, even when averaged. BTW, that was my mistake reducing the autoguider rates to just two options (0.3x and 0.5x). I'll restore the full range in the next PEMPro build. -Ray Gralak Author of APCC (Astro-Physics Command Center): Author of PEMPro V3: Author of Astro-Physics V2 ASCOM Driver: -----Original Message----- |
to navigate to use esc to dismiss