LittleFoot Elegance Photo > LittleFoot Elegance Photo

EPEC - did you try it?

(1/9) > >>

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

Navigation

[0] Message Index

[#] Next page