EPEC - did you try it?

[Armando]

Hi @all,

I'm tempted to test EPEC: I think it's the main LFEP feature. Unfortunately I think nobody, including Rajiva, tested it.
Orlando Andico is developing a cheap board to allow RA ST4 corrections by an RA encoder feedback (a sort of cheap TDM alternative).
Anyway if LFEP EPEC is not affected by any bugs I would suggest an interpolator to convert analog sine outputs to TTL ones: LFEP should make the rest. It could be simpler than a "TDM style" board: no timing/oscillator issues, no ST4 outputs, no ST4 inputs, no need to correct anything, just the need for a signal conversion... LFEP should make autoguiding possible with guiding exposure times of 30s (or more) with cheap guiding cameras on OAG too!

In case of limited capabilities of the MCU used to convert the encoder sine outputs, EPEC could be automatically toggled by ASCOM driver when a GoTo command is sent. I think also that angle computations could be avoided: storing and comparing (by a LUT) tg or ctg values could be enough...

So the only expensive part is the encoder because of the need of 5000 cpr and adequate accuracy.

Did you try EPEC?
I'd like to avoid to buy the encoder and make an interpolator just to discover that LFEP EPEC doesn't work at all (because of LFEP firmware bugs). I would appreciate a confirmation that LFEP is really able to manage EPEC. 
I found on the old forum some attempts to use a gearbox to connect a low resolution encoder with no need to opt for sine rotary encoder and interpolators... I perfectly understand a gearbox is not a good starting point but if these attempts failed simply because of gearbox issues I think it's worth trying to build an interpolator...

What do you think about this idea?

CS
Armando Beneduce

[Armando]

Before going to buy any encoder I could test EPEC by emulating the encoder outputs by a PIC MCU...
I could check if RA speed increases/decreases by applying square wave outputs with variable frequency around the "expected sidereal" one...
I hope the LFEP controller is able to "follow" huge errors (i.e. keep memory of many missing or excess signal edges).

Anyway, before going on, I need to know if I can connect the PIC MCU output pins (used to emulate the square wave encoder outputs) directly to LFEP encoder input pins with no resistors at all. Are LFEP encoder inputs TTL ports?

CS
Armando Beneduce

[Armando]

I just made some tests by emulating an encoder (1M ticks)...

With EPEC disabled I can see that RA encoder position (shown by the display) follows the emulated speeds.

If I enable EPEC and intentionally emulate a wrong (high) speed, after some seconds  tracking speed decreases. But, as soon as this happens, if I emulate a low speed the mount speed is kept low.
The same happens with a wrong (low) emulated speed: tracking speed increases but if I emulate an high speed the mount speed is kept high. 

I tried also to emulate different speeds by gradually increasing/decreasing the starting sidereal one but unsuccessfully.
I should make some tests on a star but frankly I'm a little disappointed. 

CS
Armando Beneduce

[Tobias]

Hi Armando,
thank you for your tries... too bad that it don't work well .
I had some discussions in the old board with a member, which name i have forgotten, about possible encoders. I have a Canon encoder with 50 000 ticks here and we have sheltered that there is no possibility to create a transmisson without enormous erros like temperature-drifft and so on.
So we thought an Sinus-magnet encoder could do the job if there were the possibility to help the accuracies with some statistics...
If the epec didn't work well I see no option how to implement it without the firmeware-code. Or we had to fabricate a box which tells the LF to make a GoTo  many times per second.... so it would block the connection to other programms nearly completly I think.

Have you other thoughts?

CS Tobias

[sleepwalker]

Hi Armando,

Please excuse my bad english first. The English language and I are not best friends.

Thank you for your tests. They are not positive, but very helpful.

I have got a "Renishaw" Encoder (RGH34 + 400mm measuring tape).
I achieve a resolution of 0.7 arc seconds so. That should be enough for EPEC.
The adaptation to the axis is not yet completely finished.

I also have a 3300 AEDA with 20000 ticks tested and found that only 1 revolution per second (that is 20,000 ticks / s) are possible with the LFEP. with faster turn the LFEP doing a reboot. The GOTO positions are then gone.
When I sometime mounted the Renishaw encoders, it is only possible to rotate (by hand) for less than 10 degrees per second.
That is very unfortunate.

Also I can not test EPEC, because I do not have the PEC -Tracker and also do not know where I can get it. Do you know where I can find one?

Maybe I need 2 encoder on the RA-Axis. One with less resolution for GOTO.
And the second for EPEC. I do not know the project of Orlando Andico. But maybe that's the better way.

I hope you can understand what I mean.

CS, Dennis

[sleepwalker]

Hi Tobi,
ich denke, das war ich 
CS, Dennis

[Tobias]

Hallo Dennis,
ja das warst du! Da ja die PNs nicht mehr aufrufbar sind... war ich mir nicht mehr sicher - sorry. Schön, dass du hier nun auch aktiv bist, so können wir da evt weiter machen - falls sich etwas ergibt.

Cs Tobias

PS Gut, dass du die Encoder noch nicht gekauft hast, da ja scheinbar der Epec nicht funktioniert… wäre schon schön gewesen.

[Armando]

Hi Dennis and Tobias,

if EPEC doesn't work then a TDM style solution could be used: I think ST4 is the only way to properly manage the encoder feedback.
Anyway, even if more versatile and not limited to LFEP, a TDM style board is difficult to be realized. It will also oblige to guide by ST-4.
During the autoguiding exposure it should send its own ST4 corrections; while receiving ST4 corrections the board should use encoder feedback to keep a different speed (e.g. 1x+0.33x or 1x-0.33x) : this way it will effectively track also the correction.

I think enabling autoguiding is a requirement, also in case of an ideal polar alignment: it should solve possible integral errors caused by oscillator frequency issues and by the same encoder limited accuracy.
Orlando Andico published on CloudyNights his attempts to make a feedback by a sine rotary encoder useful to reduce the tracking error (with no autoguiding). But some troubles occurred because of possible PE due to the encoder itself!

We could prefer the EPEC by converting sine outputs to TTL ones. In case it won't work we will be obliged to switch to a TDM style solution.

I think currently it's not priority to take into account possible encoder feedback issues while the mount is slewing or because of a movement by hand. In the worst case a quick solution will be to provide a command to toggle EPEC off/on by ASCOM driver (and automatically for GoTo commands).

If LFEP is able to track 20000 ticks/s I see no encoder reading issues at all at sidereal speed.
What I'm not sure is EPEC. As a 5000cpr encoder is not cheap at all, do you think it's worth it?

AFAIK EPEC option is enabled by an appropriate firmware update.
I bought my LFEP unit with all options enabled; afterwards Rajiva announced the end of the LFEP support.

CS
Armando Beneduce

[Armando]

According to the noise coming from RA motor (by assuming that EPEC works by moving RA motor at 1x+0.33x or 1x-0.33x) I found that simulated high (resp. low) speed forces LFEP to decrease (resp. increase) tracking speed.I see no troubles while switching between sidereal and lower speed. But as soon as the higher speed is activated the controller remains locked at that speed.
I've no way at home to check by a telescope.

CS
Armando

[sleepwalker]

Hi Armando,
The encoder error is not unimportant. My encoder has a maximum error of 60% per tick. This is a half arc second. I think that is tolerable. Also should not be used as a gearbox in order to increase the resolution. It makes no sense to try error of gears with other gears to fix.

It is not only the polar alignment. The stiffness of the mount against wind and vibration as well as the bending of the telescope itself must be minimized.
The bearings should have no gap and have to run very precisely.
(1 arc second are only 1mm at 200 meters)
These are very high demands on a payable mount.
My mount is a self made with 60mm diameter axis and handles very precisely.

My encoder is an optical non-contact encoder ring. Thermal expansion is not a problem.
If only I could somehow get the EPEC option for testing.
Is there really no more updates?

I think that there should be a way to improve the EPEC.
It can not be so difficult to influence the speed of a stepper motor controller.

5000 tpr are not quite enough. With quadrature you have a resolution of 65 arcsec.
(1296000 "/ (5000tpr x 4 (quadrature)) = 64.8")
And then comes the potential errors in the Enoders ...

What annoys me with the LFEP: an encoder that allows EPEC, makes no GOTO by hand.
No matter if TDM or LFEP, I need currently 2 encoder on the RA axis to have both.

Perhaps there is a way (with additional box) to save the tick and leave in a specific maximum speed to the LFEP. GOTO by hand is then slower but doable.

CS, Dennis

[Armando]

Hi Dennis,

the 5000 cpr encoder I'm referring to is a transducer with analog sine outputs (and 5000 sine periods per revolution).
By a differential ADC for each differential output channel it's possible, with appropriate interpolation, to achieve the required resolution (e.g. by opting for 512 samples/sine period a resolution of 1296000''/(5000*512) = 0.5'' is possible). Even if, according to Heidenhain specs, accuracy is limited to 1/20 grating period, as TDM solution works as expected and makes use of the same encoder I'm referring to, I think it's possible (but also difficult) to effectively reduce PE. Probably the accuracy is the overall one that takes into account also the integral error. By making use of an autoguiding system this limitation won't cause any issues since the integral error is minimal on a short guiding exposure...
The IBV660 B interpolator by Heidenhain with a 400x interpolation (1600 by taking into account the quadrature) should confirm that it's reasonable to force an huge interpolation (i.e. to achieve good resolution).
I think your encoder requires reduced eccentricity; we could prefer it because of TTL outputs with no need to interpolate any analog outputs... Anyway I think that currently EPEC doesn't work.

As for GoTo, the I2C interface can allow us to avoid the use of 2 RA encoders: an ASCOM command by I2C can command the board to switch to "low" resolution mode. Then wrong RA coordinates can be managed by ASCOM according to the high/low resolutions ratio...
The board in low resolution mode could limit itself to count the sine periods. Anyway I still think GoTo limitations are marginal.

But making a TDM style controller is not a joke... 

CS
Armando

[Antoon]

Hi Armando,

I also gave the EPEC a try.
The RA drive of my scope is a homemade steelbeltdrive. It works great. Here is a link to some photo's i made from the EPEC trial more then a year ago.
 https://plus.google.com/photos/117395768557029373537/albums/5864006567181203345
As you can see, i mounted a 5000 tics encoder on one of the guide-rolls of the steel belt. (20.000 quadrature)
Because the resolution is waaaay too small for mounting it directly on the polar axe. But probably the total resolution of the encoder is still not big enough.
Every time i switched EPEC on, the motor started a correction in +0.3 siderial.
I did a lot of measures with an oscilloscope and two electronic counters. But finally i gave up, dissapointed of course.
I asked Mr Rajiva some questions about it, and he promised to look at it in the future.
But now we know he gives no support anymore. That's a sad thing. 
But as i said before i respect his deciscion.

Best Regards
Antoon

[Armando]

Hi Antoon,

I also found EPEC, some seconds after the activation, caused 1.33x guiding.
So I tried to tune (iteratively) the emulated encoder outputs frequency to have no RA coordinates drift. I didn't check by a scope the (emulated encoder) output frequency and because of the annoying computation of PIC18 ISR overhead and possible frequency drift I preferred to take into account RA coordinates shown by the handbox display (with EPEC disabled) to define the square wave output frequency corresponding to sidereal speed (according to LFEP  )...
Then I found that higher and lower frequencies made EPEC apparently working. But as soon as 1.33x (or 1.66x) is activated by EPEC I see that the controller remains locked at that speed.

Because of 1.33x speed activation as soon as you enable EPEC, I think your test is a confirmation... I think you can also notice RA encoder coordinate drift (with EPEC disabled).
Could you make a similar test?  As you obviously can't change encoder resolution, could you check by entering (iteratively) an intentionally wrong encoder resolution by the handbox? I'm suggesting to iteratively tune a (wrong) encoder resolution...
Then you could enable EPEC and let us know what happens...

CS
Armando

[Armando]

Antoon,

be sure also the encoder output wires are not to be swapped...

[Antoon]

Hi Armando,

Sorry for the late answer. I've been very busy the last few days.
You said ; "be sure also the encoder output wires are not to be swapped..."
I'm sure this was not the case. I tried all combinations. 

You also asked; "Could you make a similar test? "
Unfortunately i must say no, Sorry ! I sold my encoders to a guy who bought the servo controller from "SIDERIAL TECHNOLOGY" (Mel Bartels)
He used them for his mount with DC servo motors.

As i said i gave up because Mr Rajiva mentioned somewhere on the old forum to use encoders of at least 648.000 tics.

This is what he wrote;
my calculator ... , 648000 Ticks (not counts) is correct for +-1 arcsec http://en.wikipedia.org/wiki/Minute_of_arc#Symbols.2C_abbreviations_and_subdivisions
CS
Rajiva

I mounted my encoders on one of the drive rolls of my mount. A little measuring and calculation learns that i had only 74.117 tics.
So way too little. And such encoders (if they exist) cost probably more then the entire LFEP. 
Now i'm working with an autoguider, and that works ok for me.

Best Regards
Antoon


 

[Armando]

Hi Antoon,

Sorry for the late answer. I've been very busy the last few days.

Thank you for your reply. 

You said ; "be sure also the encoder output wires are not to be swapped..."
I'm sure this was not the case. I tried all combinations. 

 

I mounted my encoders on one of the drive rolls of my mount. A little measuring and calculation learns that i had only 74.117 tics.
So way too little.

Yes, 648000 tics or more are required to enable EPEC.

And such encoders (if they exist) cost probably more then the entire LFEP. 

This is the reason why I think a sine rotary encoder is required together with an home made interpolator. And by this combination the encoder would be no more than 350 Euro.

Now i'm working with an autoguider, and that works ok for me.

I don't mean to replace an autoguiding camera by an encoder. I'd like to add support for an encoder feedback during the autoguiding exposure to achieve the best tracking performance...
Anyway I'll take my time to evaluate if it's worth it (there is also another reason why I'm tempted to enable an encoder feedback: PEC could help to improve tracking during long autoguiding exposures (i.e. more than 5s) but I found a not integer reduction ratio on my new SynScan coupling that makes PEC no more useful.  Maybe I'll replace the gears by a belt/pulley transmission to improve tracking and to have a 5:1 reduction. Then replacing the RA motor by a new one with 0.9° step angle could help to further improve tracking.

CS
Armando

[the_lizardking]

Hi folks,

not sure is the software already downlaodable - I do not have the feature EPEC activated so I would need to update my LFEP first - encoders are there.

cheers

[sleepwalker]

hi,
I also have no idea where we can get the update for EPEC-option.
If mr Rajiva publishes the software (as he promised), perhaps we will find someone who takes a look at EPEC, polar alignment and the other things which do not work now.

My complete optical encoder cost 400 euros (including 19% tax).

http://www.renishaw.com/en/rgh34-linear-encoder-system--6450

The measuring tape can be glued to a ring with a diameter of 125mm or larger (approx 393mm length).
I have the type: "RGI34W" and achieve a resolution of 0.66 arcsec (0.002 mm x 392.7 mm = 1.963.495 tics/revolution (TTL, quadrature inclusive)).
I still have to build a case and a 125mm ring with fixation on RA axis.
The service Renishaw told me that temperatures less than 0 ° C are in order, if no condensation occurs.
(This design of the encoder are also used by ASA-mounts.)
I think this encoder and EPEC (if it works at some point) are still much cheaper than a good gear and a precision worm gear.

Armando:
Now I understand your statement about your encoder resolution. Thanks for that.

My problem is still that I do not have a second Encoder on the RA axis for GOTO by the hand (no space). So I need a hardware or software that buffers the encoder signals and pass it with 20000 Hz or less to the LFEP (for example).

CS, Dennis

[the_lizardking]

Really good idea to use linear encoders, so you can build this tapes for less money,... testing the things will never be the problem,... theres always someone who uses this features - I use both if needed to be tested :-) maybe someone of our mechatronics picks this idea up and build the missing interface for you. It sounds like a practicable solution that should be published for everyone.
However for testing EPEC the DEC encoder is good enough, I also have a smaller one in RA axis for goto,... it looks for me that it works almost stable for GoTo so far. But I always have some smaller troubles with it that I cant locate or project to either the complete setup itself or the encoder function. Some support and two oppinions would be great in this section... as it is a complex topic.

Lets see what future brings up, I hope Rjiva will find the time to support us with the software once, I think its a huge work to upload everything and make short infotexts for each,... so it will take some time to do so.

[the_lizardking]

Armando,

also Inducoder is a cheap option,... I have one with 80000 tics using a 16x quadrature (4x internat and 4x gear) with a beltdrive and it works fine with a TDM test. Of course there are some failures from encoder but with this resolution it can be resolved by the technic itself.
I also bought my LFEP with all options and I thought EPEC would be includued, otherwise I would have bought encoder option,... but no epec. In a perfect world we live heheh some have encoders but no epec other have epec but no encoder :p ... I do not know how but we should overcome this oneway road situation and should have a GNU License version of the firmware to update all LFEPs with all options opened.