Gday Matt
If I understood correctly, a perfect bin on an LX200gps should take 2.4 seconds. This would be the duration if PEC is turned OFF and the scope is just turning at sidereal speed.
Technically, yes or no
.
The non 16" mount has 180 tooth wormwheel and 200 PPEC bins per rev of worm
At sidereal, this gives 478.6894s per rev and 2.393447s per bin
Problem is there is no way to measure ( or use ) this data easily.
as the base loop clock in the LX200 runs at 225Hz, so thats the best time you can get.
As such, a PEC bin in the LX200GPS is properly defined as a set no of encoder ticks,
as that is the only thing you can use as a datum, but that is also fraught with indecision.
ie
The mount has a 50:1 gearbox and 256 line encoder
One rev of motor = 256 * 4 = 1024 encoder ticks
50 revs of motor = 51200 encoder ticks
With 200 bins per rev that gives 256 ticks per bin
However.... 51200 ticks is not necessarily one rev of the worm :-) )
This is because the gears in the gearbox dont reset properly until 3 revs of the worm complete
and there are some shocking gearboxes out there.
This is partly why Meade went to a 3 turn PEC model ( but that also has its own problems )
Now thats a definition of the perfect world, but back to reality :-)
Do you have any data that, when running at sidereal speed with no PEC, shows
a) by how much the bin duration fluctuates
Sort of, but its not real time, as i had to poll the mount to see what happens,
and the data i got made no sense, as it was so ragged, i didnt believe it.
( I thought i was smart back then
)
I then did lots of tests ( ref attached example log where i recorded the motor card comms
in different screens with PEC ON and OFF )
Once i started monitoring the motor cards ( vs read the main firmware )
i realised there was a smoke and mirrors exercise going on.
The limit in this case isnt the code in the main CPU,
its the main board PIC and how it reads the data from the motor cards.
I have hundreds of minutes of data collected from my test bench
and what it shows is the rate the encoders get read ( and the time taken to read an encoder )
can change at the whim of that PIC. In many cases, it can get up to 3 seconds between
encoder reads, and this totally destroys any precision in the PEC application.
ref attached plot which shows the end of a sensor detect followed by resuming polar tracking.
At the beginning, it was reading the RA encoder at about a 1sec period and tight clocking
but once it detected and read the sensor trip,
it went to 3 seconds per read and very long read times ( ie 270ms just to do one read ),
all of which destroys any precision ( timewise )
I also tested this by patching the firmware to dump out the encoder position every time it
was read by the main firmware. What it showed was the main PIC simply replied with
the last read encoder value until a new one came in :-)
b) the actual speed calculated from the RA encoder signal
Bucket loads, but it is like watching a mad womans chooks.
Most people assume a simple pwm pulse train gets sent, but it is anything but that.
It is a very complex drive system, tho the resulting pwm does smooth it out a bit.
I recorded the bin duration on my system for approximately 5 minutes
What is your drive system / gearbox etc, and does it fully repeat every turn of the worm ????
Andrew Johansen Melbourne Australia
LX200Polar Std30 RA15 Alt15 Locn15 Std15.txt 8.19KB
11 downloads