Extraits choisis et triés par thème de discussions tenues entre Dick Seymour, Andrew Johansen, Mike Weasner, Jean-Marie et Michel (moi-même)
(Vous pouvez aussi passer cette discussion et sauter directement aux conclusions).
1 – comment être certain de ne pas perdre les corrections enregistrées ou les rendre inopérantes (voir contre productives) par exemple lorsqu'un reboot de l'Autostar fait perdre à celui-ci la correspondance entre les corrections à apporter et le point précis de la vis tangente où il faut les apporter ?
:
Michel :
Hello Mike and/or Dick,
I am a french amateur using a LX90 updated to E33Ef and also "myscope" by Andrew Johansen. I find your autostar pages quite useful and wish to thank you a lot for them. May I ask a question?
I read in the help file of Johansen's "myscope" that : "If you use this option to read, by going into download mode, you must wait for the HBx to restart and the app to reread the data back in before pressing any more buttons."
That's what I have done, and the HBx DID restart indeed.
As it did so without having first PARKED SCOPE, does it mean that the scope will have lost its position among the 150 worm steps, thus making my previous PEC useless ? In other words, does this restart work like a complete power cycle, or does it keep memory of the position etc... ?
Thanks in advance for reply if you can.
Greetings from
Michel Bonnement
Dick :
I don't know.
It is possible that if the telescope was in the PARK position at the time
of the reboot, then the position was not lost. I think.
I am forwarding a copy of your question (below) to Andrew... perhaps
he can change the download/reboot code to include a PARK command.
We will certainly investigate the issue.
Michel :
Thank you very much for your fast reply. It seems probable, indeed, that
Andrew has managed to keep PEC position while the HBx reboots, otherwise any
previous PEC training would be of no use (and thus, no interest in
comparing, editing, averaging as allowed by his software...)
I'll train another PEC and check if the result is different or not from the
first one. If not, it'll mean the reboot does not work as a power cycle. (I
think).
Andrew :
>...Andrew has managed to keep PEC position ...
Sorry to say, but I'm not so sure on the above currently.
> ...otherwise any previous PEC training would be of no use (and thus, no interest in comparing, editing, averaging as allowed by his software...)
Not absolutely, necessarily so.
When i wrote the initial code, it was under Dicks instructions,
as PEC in the 497 autostars was new.
We never really figured out how Meade kept it synchronised
across reboots at that time, and as per Dicks recent reply we are
still not sure.
After that, i left it in my app, but must admit i then forgot
about it for any form of detailed analysis.
If its any help, you are the first person to comment on this function in
over a year.
>... I'll train another PEC and check if the result is different or not from the first one. If not, it'll mean the reboot does not work as a power cycle. (I think).
I'll be interested in yr data.
1) Do you run patched firmware. If so the PEC can be read without
going into download mode, hence no damage to it.
If you dont run patched firmware, i suggest you load a patched version
as this makes a lot more data available,
Secondly, if PEC is only maintained if you PARK, there is a possible
solution.
The current software does the whole operation in one buttonpress.
It would/may require manual user intervention but the following may work.
1) Park scope, go into download mode, backload data but dont reboot,
Turn off scope at the power switch.
When you reboot, it will think its still parked
Only Prob here is what is the effect of turning off whilst in download
mode.
I have done this many times, so know it wont hurt, but dont know if it
will work
2) Park scope, go into download mode, backload data, reboot scope.
User must now realign then repark.
Or maybe even the software could Repark after Rebooting.
Dunno.
Anyway, Dick is looking into the code, and when he can tell me how
it is operating, i will mod my app to suit, or just remove the function if
its
going to cause grief.
Dick :
Looking at Andrew's various (1)(2)(3) suggestions, it was variations
on those themes that had me writing a far-too-long message this
morning.
His idea of using the patched firmware to allow live-update of the PEC
is the best approach at the moment: the scope never has to be turned off,
so all alignments and PEC indexing remains valid.
When he says "power up in download mode", he means Safe Load,
pressing both [enter] and [scroll up] as power is applied.
Further analysis will take a few days...
Michel :
I could train another PEC from scratch yesterday night
This is a summary of the data :
- 1st PEC, may 20th, running firmware rev 33Ef UNPATCHED - Then scope parked
- Firmware rev 33El downloaded on may 24th and PATCHED with Dick's 33El4 -
HBx restart - Editing PEC file, backloading to HBx, exporting to Excel and
all sorts of tries to test Andrew's app - Scope parked again. Noticed that
reading PEC causes no going to download mode, BUT backloading a modified
file to HBx DOES go to download mode
- 2nd PEC from scratch, may 25th : file compared with may 20th's one :
slight differences, same general shape, no obvious offset.
Averaging both curves gives a third one whose general shape seems coherent
with the first two
-> my current conclusion is that the worm step count seems not to have been
lost in the restarts ; has to be confirmed by further testing.
If the sky keeps clear, I'll try a third (or more) train and send you the
resulting .rm files.
If the conclusion is confirmed, no further modifications should be performed
(I think ?)
Andrew :
>... Noticed that reading PEC causes no going to download mode, BUT backloading a modified file to HBx DOES go to download mode
Umm Thats in the help file :-)
Perhaps i should use capitals, as yr test has pointed out a possible lurgie
for those who have ( properly ) PEC trained a 497
Thats also why i suggested Dicks patch. With that loaded, i can read the
Autostar data on the fly.
If Dicks research works we may be able to write back on the fly as well,
which will be much better all round.
>... - 2nd PEC from scratch, may 25th : file compared with may 20th's one : slight differences, same general shape, no obvious offset.Averaging both curves gives a third one whose general shape seems coherent with the first two...
Sounding good. When you did the PEC backload, was the scope parked???
Michel :
The scope had been parked before, but was not while backloading.
I attach the 3 .rom files I have today : first PEC on may 20th, the same,
updated on may 25th, and the third one from scratch on may 25th.
You can see they look quite alike. The general shape is the same. I think
losing the worm step count would have offset the curves right or left (don't
you think ?) but it is not the case.
Sorry I could'nt make another train yesterday night due to cloud overcast
(and now, the sun is shining through a clear blue sky...)
Andrew :
> ...You can see they look quite alike.
Sort of, but i'm not so sure.
I have run them through a few averaging/smoothing functions to see the
general shape,
and i'm not as optimistic as you yet.
I know from my testing of the GPS scopes PEC, that the end results can vary
a lot,
so three datasets isnt a large base to work from, but from what you have
supplied
the 20/05 plus update seem similar, but the new 25/05 looks phase shifted to
me.
I need to try some more smoothing types ( and more datasets if you can get
them )
Michel :
You're right, they are not as similar as I thought.
Andrew :
I have modified my app to plot the data in a different way, which allows me
to phase shift the data and look for trends
Based on this, it "appears" as though yr train/update were syncd but the
third new train was about 60 points out.
Michel :
I could perform another update on 27/05, starting from 25/05 session.
I made an export of the four data sets into Excel. The file is attached to
this message.
It seems that updating from a previous data set yields a similar shape,
while starting from scratch gives somes differences.
Andrew :
As it should, unless, you didnt park at the end.
Michel :
But what's the cause ? HBx restart or guiding differences ?
I would guess for guiding : if it were HBx restart (there has been another
one between 25/05 and 27/05 update), the update would also be more different
from the original, would'nt it ?
I also attach a graph of the recorded shift, while guiding for updating
(almost no shift,
except for turbulence) and then, without guiding and with PEC (thus updated)
ON.
The second part of the curve shows that the result of the training is far
from perfect... (take no care of the sharp spikes, due to bad seeing and the
webcam losing guiding star for a while). Drift remaining and some amount of
PE too ?
Andrew :
It appears as though the PEC pointer is software based and uses dead
reckoning.
As such, it "appears" that any time you train PEC, then later reboot the
scope without doing a park, restart AND realign, it will lose the plot. This
is NOT confirmed yet, but is looking more likely.
Dick is still looking at this to get the exact mechanism, but it means any
accidental power loss, or start /stop without proper align/park, will lose
yr data.
I have modded my app to show data in different ways, to
help analyse whats happening.
Also, Dick has made a patch ( that i am currently testing ), which will
allow me to write PEC back, without going into download mode.
If this works, and you are happy to be a tester, i can get you a copy of it
( and my modded app ) to see how it goes.
Michel (a few days later) :
I have downloaded Dick's latest patch34cc, patched build34Ec firmware and updated Autostar with Build34cc.rom.
Followed Dick's link to your myscope.zip, but the downloadable version is still the same (am I wrong ?)
Andrew :
Excellent. I had to wait for Dick to finish his patch before i could test it.
Then i found the RCX scopes use slightly different codes, so had to adjust
and test for that
Then the New ASU came out, and my app was screwing up reading/editing of the
new format
sooo back to the drawing board again.
I am in the final stages of testing, but if you go to
http://members.optusnet.com.au/johansea/myscope.zip
you will find a beta version only a few days old
It now will ask if you want to park before doing download ops ( if you dont
have dicks patch )
and will read/write on the fly if you do have dicks patch
The new display mechanism seems to work well and i have also added an online
smoothing function.
I havent done a "proper test" on the smoothing here as its winter and wet,
but if you can see the sky, i would be interested in how it goes.
Full online help is updated for the new functions but basically :
Do one PEC train;
Save data to say run1.rom file
Do a second PEC train;
Save data to say run2.rom file
Do an update;
Save data to say run2u.rom file
( All in one session )
Now open up the PEC Compare tab and load run1, run2, run2u
The PEC will show, but its messy.
Select "show summary" and you should now have three "clean" plots that
approximate the shape of yr worm.
No magic or processing here, its just PEC offset plotted as a running
summary.
Select smoothing and play with the buttons till you get a nice smooth curve.
Select BackloadRA data button.
Now you are back in the edit tab, with yr smoothed data loaded.
Select the "Write 497 data" option and it will write the new PEC back to yr
scope.
See how the result looks.
Also added a function for backloading old "good" pec, after you have lost
synch.
Dunno how this will work, but the logic seems sound.
All in the Help under phase shifting.
Have a read and ask questions as reqd.
However, if you want to do a dry run, just use the compare tab, and load in
the 4 files you sent in yr last emails to me.
Have a look at how far phase shifted they really were.
Also forgot: I have also been looking at drive training for GPS and ETX scopes.
The GPS is pretty precise, but i have found with the ETX i may need to train
three times in a row to get a good set of consistent results. It almost
seems to be an iterative process, rather than a once off.
As such i wrote a semi automated routine to do this process and log the
results.
Thus, If you have an LPI ( or other webcam/videocam ), you can train yr
drives using video.
If you have Dicks latest patch loaded, you can now also manually edit yr
train and backlash values via little floating panels in the app.
You can do this anytime, but if you are watching the video at the same time
( for backlash especially ), you can emulate the HBx keys and just watch for
timings, then adjust and retry till yr happy.
Makes training a breeze.
Again, fully described in the help.
Dick :
I'm bouncing this off Andrew in a separate (more detailled with boring bits)
note, but i'll run it by you, too, as a heads-up.
Doing an Erase/Track-test may not be totally valid for hunting your
issue, since Meade handles the "erased" case -differently- during PEC
"playback".
The Erase loads x80 x80 x80 throughout the PEC table. (this is "PEC zero")
The "adjust tracking to handle PEC" code -watches- for that -particular-
value, and skips a bunch of code if it's seen.
So the "Erase, PecOn and Track" will yield -interesting- data, but not conclusive
(unless it -also- causes Tracking errors)
The back-channel note to Andrew is about trying to puzzle out a non-zero,
but carefully non-biasing, set of PEC data. (merely +1,-1,+1,-1 won't work,
for complex reasons)
Michel :
I download yr new version of Myscope and try it as soon as I can.
Andrew :
No worries.
However, if you want to do a dry run, just use the compare tab, and load in
the 4 files you sent in yr last emails to me.
Have a look at how far phase shifted they really were.
Michel :
I wonder shall I use the new ASU or try StarPatch. Dick writes the latter is twice as fast.
Andrew :
Correct.
Even if you use the freeware version, its still quicker than the ASU , and
it appears to be more robust when it comes to grabbing and holding the port.
If you buy the full version, it will load a 497 in about 2minutes
If you use the freeware version ( which takes about 1/2 the normal time ),
you still get full functionality ( port grabbing ), jus it slows don a bit
at the end.
Michel :
And also, backloading firmware to the autostar via ASU DOES cause download mode AND reboot, so back to the same problem. Maybe StarPatch loads data on the fly ?
Andrew :
Nope. To load firmware, they both need to go into download mode.
Starpatch wont backload tours etc and even using ASU to "connect" to a 497
handbox
( you only connect, you dont actually do anything ), causes the Hbx to go
into download mode.
The only way out of download mode is a reboot, hence you are cactus.
( Thats Australian for in trouble )
Thats one of the reasons i maded the phase adjust function.
If you have a good PEC set and lose it, you "should" be able to restart the
scope and do one "rough" pec train.
Then go to the compare tab and set it to grab scope live data. Then load the
old pec in as file1 and set the screen to summary mode.
Phase adjust the old data till its "shape" matches the new, then load it
back to the scope.
2 – comment affiner les réglages de PEC encore plus précisément qu'avec les procédures internes de l'Autostar (PEC update) ?
Michel :
Tried StarPatch yesterday. OK, but speed is not the main problem. It's reboot.
Andrew :
Yep. There is no way to avoid rebooting if you are doing a software load.
Even Dicks patches wont help there.
As to Editing user data/ PEC/ site data. That can be done live, if Dicks
patch is there.
As to writing Tours/Asteroids/Comets etc, thats still a connect to ASU and
hence a reboot.
Michel :
This how I sum up the question :
when you guide and train the PEC, you also record all sorts of random moves, so the curve you get is NOISY,
making one or several updates is much like STACKING several short CCD exposures - you add the signal and average the noise and thus improve S/N ratio,
but autostar pec updating is BLIND stacking - you don't know (see) exactly what you stack...
Andrew :
Not quite so. Austostar 497 works on 150 "bins" per turn of the worm.
Each run you do, it averages the total movement during that bin, and places
it in the bin
Next time through it does the same, but as you note, if you have one good
run and one bad run, you only see the result of the two merged.
Michel :
...your app allows to record several independant trains (not updates), compare them, see if they are compatible, erase the wrong ones, smooth and
average the good ones and reload a good noiseless set of data.
Andrew :
You got it.
Michel :
That's what I had tried to do when analysing my data in an Excel sheet (think I had sent it to you ?). But one thing that I forgot : raw data are
DIFFERENCES from one point to another, to get the actual offset from the starting point, you need to SUMMERIZE them first ! That's precisely what
does the new version of your app.
Andrew :
Sort of correct.
Looking at the raw data, you are averaging the independent offsets and this
doesnt play out very well, as there is no real trend to smooth through.
Looking at the summarized data you are smoothing a MUCH simpler curve, with
superimposed noise.
The trick then is to convert it back into PEC offsets.
I had read all the posts where people were working out arcseconds per second
per PEC point etc, but all of that is irrelevant.
If the new smoothed summary curve is the same shape as the raw one, then you
have the right trend, and recalcing the new PEC is just a simple reversal of
the adding process...
Dans le même temps, se tenait une autre conversation, en français, avec
Jean-Marie :
Bon finalement hier soir j'ai trouvé le "custom" et mis comme valeur +7 puisque j'avais a peu près le même résultat que toi sur ta page.
Donc j'ai fait un "PEC training" => maintien de l'étoile a la raquette dans le réticule le temps qui est determiné par l'Autostar c'est a dire 150.
Ensuite bien sur j'ai activé la PEC pour voir et là franchement pas convaincu du tout car j'ai une dérive que je n'avais pas, direction Ouest uniquement.
Plus moyen de faire une seule image sans erreur de suivi a 20 sec. Bizarre parce que j'ai bien fait attention a garder mon étoile centrée pendant le training.
Michel :
Temps déterminé par l'autostar : il faut considérer une rotation complète
de la
vis tangente (worm en anglais) sur la roue dentée (gear) qui a 154 dents
(teeth) qui prend environ 9 min 19,507sec (sachant que 154 x 9min19,507sec =
86164,1 sec = 1 jour sidéral).
Voici un copié collé de ce que j'ai trouvé sur la question, et mes mesures
perso :
"LX90 Worm period the period varies slightly from telescope to telescope due to variations in
the drive electronics and voltage levels - hence the use of the custom
tracking rate to correct for this. Presumably you want to know the
theoretical correct speed, and that is governed by the number of teeth on
the worm wheel and the length of the sidereal day.
A sidereal day is 86164.1 seconds. There are 154 teeth on the LX90 RA gear.
So the worm needs to rotate 154 times in a sidereal day, hence the worm
period is 86164.1/154 = 559.507(142857) secs. 9 minutes 19.507 seconds."
Résultat trouvé expérimentalement sur l'analyse de la dérive de ngc2903 du
110405 : 9 min 26 sec.
Les 150 points qui défilent ne sont que des repères de positionnement de la
vis tangente (voir précédent msg) chaque repère vaut donc +/- 3,8 sec.
Inutile
donc d'essayer de guider à une fréquence + élevée (d'autant qu'on risque de
"guider sur la turbulence")
Je constate exactement la même chose : tant que je suis en training et
donc en guidage manuel, la courbe et parfaitement droite et horizontale. Dès
que je laisse filer, la courbe reste (à peu près) droite, donc l'erreur
périodique est (à peu près) corrigée mais cette droite descend, ce qui
indique
une dérive (non périodique) vers l'ouest (suivi trop lent). D'ou ajustement
du
tracking rate, mais rien n'y fait... J'en suis au même point que toi. D'où
une
question que j'ai évoquée précédemment sur l'interraction entre EP et dérive
constante et la nécessité ou pas que la seconde soit corrigée indépendamment
de l'enregistrement de la correction d'EP.
Jean-Marie :
Il m'est venu une idée aussi a ce propos : Quand j'appuie sur la fleche de gauche puis de droite et inversement j'ai un temps de réponse pour que tous les engrenages soient en buté (je crois qu'on appelle ça le backlash). Si j'ai ce petit soucis il faudrait alors que je fasse le moins de correction possible lors de l'enregistrement du PEC et surtout le moins possible dans le sens inverse du suivi, sinon le telescope doit rattrapper le jeu dans les engrenages soit qq secondes. Non ???
Michel :
Tout à fait d'accord, je pense qu'il faut "calmer le jeu" quand on
enregistre le guidage (voir ci-dessus pour la fréquence des points de
repère)
Pour le contrôle des paramètres (calibration moteurs, et surtout
pourcentages, qui sont sans doute trop faibles dans ton cas) qui influent
sur le backlash (c'est vrai que c'est un point
important dans l'efficacité du guidage, une réponse trop lente ou trop
brutale peut être contre productive si elle arrive en opposition de phase),
je te renvoie à cette page :
http://www.weasner.com/etx/autostar/as_tracking-percents.html (voir plus bas
une traduction rapide des points essentiels)
Jean-Marie :
Donc il vaut mieux laisser filer légèrement l'étoile plutôt que de vouloir absolument qu'elle ne quitte pas le repère. Si on intervient trop pour compenser la dérive, cela va "marquer" trop la correction a apporter par la PEC et celle-ci va finalement faire un peu n'importe quoi.
Michel :
Laisser filer est un peu fort, disons, ne pas se précipiter dès qu'elle bouge un poil à gauche, parce que c'est peut-être la turbulence, laquelle va la ramener 1/2 seconde plus tard un poil à droite. Si entre temps, tu as corrigé, tu n'as fait qu'accentuer l'effet de la turbulence. En fait, il faut évaluer l'intensité et la fréquence de celle-ci et corriger seulement si on sent (c'est bien une question de feeling !) qu'il s'agit d'une vraie dérive.
Jean-Marie :
Ne vaut-il pas mieux faire des corrections douces et faire plusieurs "PEC UPDATE" ?????
Michel :
Exactement. En fait, quand tu enregistres une PEC, tu enregistres en même temps que les corrections utiles, un tas de mouvements aléatoires liés à la turbulence, au temps de réaction du scope (on retrouve le backlash, à régler au mieux), à tes propres réflexes, à une surcorrection que tu regrettes 1/2 sec plus tard etc...
En somme, la courbe est BRUITEE. Si j'emploie cette expression, c'est à dessein, car il s'agit vraiment de bruit qui vient parasiter le signal. De la même façon qu'en imagerie CCD tu vas accumuler de nombreuses prises de vues pour additionner le signal, alors que le bruit, lui, se moyenne, ce qui conduit à améliorer le rapport S/B, en guidage, tu vas faire plusieurs updates qui vont, là aussi, améliorer le rapport S/B et régulariser progressivement la courbe de PEC. CQFD !
Jean-Marie :
Pendant la PEC UPDATE, est-ce que je dois également tenir l'étoile dans le réticule ????
Michel :
Oui, bien sûr, il s'agit d'affiner le premier suivi. On peut faire plusieurs
updates successifs, c'est comme compositer plusieurs images de 30s pour simuler une pose longue !
Maintenant, la piste que je vais explorer est celle, non pas d'updates "à
l'aveugle" (seul l'autostar voit et enregistre les corrections successives),
mais une série de trainings indépendants les uns des autres (avec
éventuellement un pec erase entre chaque) que je vais ensuite enregistrer,
éditer,
comparer, lisser, et moyenner avec le fameux logiciel myscope d'Andrew
Johansen.
De cette manière, je vais vraiment visualiser une courbe
résultante et en réinjecter les données dans l'autostar.
Jean-Marie :
La PEC reste-t-elle valable indéfiniment ?
Michel :
C'est bien la question la plus importante !
La différence entre le LX90 et le LX200 c'est que sur ce dernier, il s'agit de PPEC (permanent periodic error correction). Sur le LX90, la PEC ne reste utilisable que si on parque le scope (commande utilities/park scope) AVANT de l'éteindre.
Jean-Marie :
Ca tombe bien, c'est ce que je fais !!! Quand à ma mise en station, je dois dire qu'elle ne dois pas être trop mal car je n'ai pas de dérive en
hauteur, c'est dire ie mon étoile repasse systematiquement au même endroit lors de ces dérives.
Michel :
Pour le réglage du backlash, en résumé :
faire un calibrage moteur, si ce n'est pas déjà fait, pour que ses caractéristiques soient bien connues de l'autostar,
régler les pourcentages (ne pas confondre avec alt ratio et az ratio, auxquels il ne faut pas toucher) pour obtenir un temps de réponse
satisfaisant, ni trop sec (le scope dépasse la cible et y revient après) ni trop mou (il commence à se déplacer alors que les 3,8 sec du compteur sont
presque écoulées, et la correction arrive à contre temps)
3 – quelles sont les relations entre le réglage de la correction d'erreur périodique (PEC train) et celui de la dérive constante liée à différents facteurs dont le premier est la vitesse du moteur (Custom tracking rate) ? Peut-on envisager que le réglage de PEC prenne en charge à la fois l'erreur périodique et la dérive ?
Michel :
...I hope it will help me solve another problem I have faced up to day : when guiding/training (using an app which yields a live graph of the shifts from the start position), I get a perfect straight horizontal zeroed curve.
Andrew :
As a guider should do. It should take care of Drift AND PEC.
Michel :
As soon as I have finished training and let the scope track free with PEC ON, the curve remains more or less straight (PE +/- removed) BUT declining
(westward non periodic drift). No matter how much I then modify the custom tracking rate, the drift continues. I'd like to clear the question of the interraction between adjusting custom tracking rate and pec training. Do you think leaving tracking rate to "sidereal" and letting the pec train do all the job is possible ? I think it over but don't find the answer.
Andrew :
Dunno with the 497, that one is better directed to Dick.
With the Autostar II, pre firmware 3.0d, doing PEC accounted for drift as
well as PEC.
Ie when you look at a summary curve, it has an offset between point 1 and
point 200
Post 3.0d, Meade have normalised PEC to remove any drift effects.
This actually slightly distorts the resultant PEC.
As such, you have to set yr tracking to a custom value first, then PEC train
to get the best results.
I dont know how the 497 works in this respect, as i havent tested or used it
much in that mode.
Dick :
At the moment: i don't know.
The effect is also (probably) changing from firmware version to firmware version.
(there was a bug in v33, which was corrected in v34, but i don't know if it
also affected PEC vs sidereal).
It will take me a moderate amount of time to trace the flow of the code.
In -older- versions, the tracking rate, PEC and guiding were added together
to yield the speed value which the autostar would send to the motors.
Based upon previous examples, it is -entirely- within the realm of reason
to expect that Meade dropped/broke some of that coding as they tweaked pieces
of it.
Before your report, I think I have only seen LXD people
complaining of a PEC-related effect, but those people -can- restore
the proper tracking speed by increasing the Tracking Rate (+50 was
cited in one posting).
I have not tried "real" PEC training on my ETX90 for about a year.
(since whenever PEC for the 497 came out). I do not remember seeing
the Tracking Rate being affectedby having PEC turned on. I did
almost all of my PEC work on the ETX90 by having an LPI serving
as the guider/trainer, and as the analysis monitor after the training.
The PEC cycle on the ETX90 is 24 minutes, so it's not something i
devoted many nights to. I have done daytime testing of PEC, but
that only reveals its existence (affecting the drift-by timing of
landmarks), and does not allow precise measuring of sidereal.
Do you see a slowdown in Tracking Rate if the PEC table is Erased
before the test? i.e. Erase PEC, turn PEC ON, observe drift.
How -much- does the tracking rate change (arcseconds of drift
per clock minute, or arcminutes of drift per clock hour)
Michel :
Those graphs date back from last summer. I can't say which version of firmware I was using then.
Dick :
Oooookaaaayyyy...
Last summer they weren't "normalizing" the data, so a tracking rate
error during training (even self-induced) would have been masked
and integrated into the PEC table itself (shown by data not summing
to near zero).
To start with a clean slate, you'd have to have current firmware
(34cc) and do an Erase, (you could turn On pec without training
and look for drift...), Train and at least a couple of Update
cycles. THEN look for Tracking Rate problems.
I would NOT play with the PEC editor (or attempt other taxes-the-Autostar
methods) DURING the PEC Training, since you may be introducing
timing skews which may cause parasitic issues.
I'm assuming you're on a permanent pier, since minor errors
in mount alignment will cause "too slow" tracking, too.
(at 0.12 arcsec/sec, and the resulting +7 adjustment, you're
still within a percent of perfect tracking.)(irrelevant footnote: your
error is twice the solar->sidereal adjustment)
Jean-Marie, sur le même sujet :
Je te fais une copie d'écran de la courbe d'EP avant et celle faite suite a ma première "PEC TRAINING" et en y ajoutant + 7 et tu me diras ce que tu en penses...
Michel :
Le résultat après PEC est assez bon et sûrement utile, tel quel, pour améliorer le temps de pose possible : il reste une petite dérive mais qui ne doit pas se traduire par un filé des étoiles avant peut-être une minute à environ 600 mm de focale et la composante périodique a disparu.
Ce qui me laisse perplexe, c'est toujours le même point : sur la courbe avant PEC, si l'erreur périodique est évidente, on ne voit pas vraiment de dérive (la sinusoïde est à peu près horizontale). Pourquoi la dérive apparaît elle APRES la PEC, à tel point qu'il te faut alors ajouter +7 au tracking rate, et qu'il en reste encore un chouilla ???
D'après Dick Seymour, les versions récentes du firmware de l'autostar supprimeraient, si j'ai bien compris, la correction de dérive constante que tu introduis forcément en guidant (quand on corrige, on corrige tout, que ce soit de l'EP ou de la dérive) pour ne garder que la PEC proprement dite. Il faut alors corriger la dérive avec l'outil qui est fait pour ça, c'est-à-dire le custom rate, exactement comme tu fais. Mais ça n'explique toujours pas pourquoi on ne VOIT PAS la dérive AVANT le training...
Mais si ça marche comme ça, c'est une question secondaire.
Michel :
Gday Andrew,
Yesterday, first clear night for 3 or 4 weeks !
Trained pec 3 times independantly (pec off between each, but no erase). Rom files attached. See also curves (raw data and summarized).
Recorded PE after 3rd train (040703_3CR10.jpg). Still shows permanent drift
with custom rate set to +10. Maybe 11 or 12 would suit better.
The 3 data sets are quite compatible. Smoothed and averaged them
(see pec040705_123average.jpg, much less "noisy").
I will backload the result to the autostar and try another record with
higher custom rate. I expect to be able to expose up to 2 minutes at 600mm
or 5 min at 180mm (piggybacked photolens) instead of 20 sec / 30 sec
previously.
Andrew :
Data looks interesting.
Did you change tracking rate between trains???
Michel :
No. During all of three trains, the tracking rate was set to sidereal. I just changed it to +10 after the third train and recorded the 040703_3CR10.jpg curve with that rate. Concluded 11 or 12 would be better, but had no time to try again.
Andrew :
Why i ask is the curves look good ( synchronisation wise ), but all showed different "drift" Ie run 1 was -20 pec points, run 2 was +70 and run 3 was +6
Michel :
I noticed that. Don't understand why... I tried averaging and smoothing the three sets. Then swaped +/- the result. See how the resulting summerized curve perfectly matches the initial PE recorded one year ago (compare the shapes of initial PE record and "pec040705_123averageswaped.jpg")
Andrew :
As it should. I did this test with a local who had a "startrail" pec recorded on his camera, and the pec plot was almost an exact match.
After all, you are really plotting "total" offset from tracking rate at a given point in time, hence it shld cancel the pec smoothly
The real test will be how a "smoothed" plot plays back.
Michel :
If the data sets don't sum up to zero, like this case, doesn't it mean that there has been NO normalization ?
Andrew :
Yep, but i dont "understand" how the 497 PEC works. I know what happened in the GPS as i was doing a lot of testing and they also changed their data structures. The 497 PEC is a rough "add on", and i dont think it works anything like the GPS method.
Only Dick can really answer this one, as he is the only one who can read the Meade code.
Michel :
Anyway, if this means that PEC handles (a part of) the drift, the tracking rate still has to be set
to rule the question completely. Or should I normalize the three data sets (how ?)
Andrew :
Dunno, just try different things.
I would turn pec off and plot data over time, using different rates until i got a tracking rate that held the plot steady "over time".
Then i would do several PEC trains with it set at that rate, and see the results.
Each time you restart, you would need to reset yr tracking rate, as its not stored.
<- Page précédente
Epilogue ->
