-fine and coarse readouts - telemetry - The az and el position readouts on the 6-m antennas are based on a combination of fine and coarse resolution measurements. Fine resolution is provided by Inductosyns (encoders); their output is periodic every 2 degrees. Coarse resolution is provided by resolvers with a resolution of (65536 counts/360 deg), approximately 182 counts/degree. The antenna computer combines the encoder and resolver outputs for each axis to produce final az and el position readouts. I believe that some attempt was made to install the elevation encoders so that they read 0 with the dish at elevation 0 (as measured with a bubble level). The az encoders, and both az and el resolvers, were installed with arbitrary offsets. The zero point of the resolvers is established by manually driving the antenna to elevation 0, pointed due south (both estimated by eye), then offsetting both axes to the nearest point where the encoders=0 positions. These are the raw antenna positions; absolute pointing offets are measured relative to these with optical or radio pointing measurements. The telemetry system sends both the endocer and the resolver readouts to the antenna computer every 0.01 sec via the CANbus telemetry stream. The encoder readings change only every 0.08 secs. Every 0.08 secs the telemetry software (Telemetry.cc) loads these values into shared memory addresses, which may then by processed by Drives.cc to update the antenna positions. The az and el values are packaged into telmemetry words 0x100 and 0x101, as follows 0x100 0x20 0x21 0x2C 0x2D 0x30 0x... The list of telemetry words is as follows: 0x20,0x21 (xx bits) az resolver -> AZRSOLV 0x22,0x23 (xx bits) el resolver -> ELRSOLV 0x2C,0x2D (xx bits) az digital velocity filter -> AZDVELF 0x30,0x31 (xx bits) az encoder cosine -> AZCOSEN 0x32,0x33 (xx bits) az encoder sine -> AZSINEN 0x34,0x35 (xx bits) el encoder cosine -> ELCOSEN 0x36,0x37 (xx bits) el encoder sine -> ELSINEN One can monitor the telemetry in real time with cansniffer, which is run from the csh prompt (not from a sac window): One can monitor these telemetry packets with cansniffer: > cansniffer server=C11 mid=0x100 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 5f 9f ff 26 b8 a5 a6 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 62 9f ff 26 b8 a5 a6 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 66 9f ff 26 b8 a5 a6 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 6a 9f ff 26 b8 a5 a6 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 6d 9f ff 26 b8 a5 a6 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 71 9f ff 26 b8 a5 a6 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 75 9f ff 26 b8 a5 a6 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 78 9f ff 26 b8 a5 a6 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 7c 9f ff 34 1a 8e 24 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 80 9f ff 34 1a 8e 24 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 83 9f ff 34 1a 8e 24 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 87 9f ff 34 1a 8e 24 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 8b 9f ff 34 1a 8e 24 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 8e 9f ff 34 1a 8e 24 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 92 9f ff 34 1a 8e 24 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 96 9f ff 34 1a 8e 24 Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 99 9f ff 34 6b 0c ee Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 9d 9f ff 34 6b 0c ee Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 a1 9f ff 34 6b 0c ee Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 a4 9f ff 34 6b 0c ee Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 a8 9f ff 34 6b 0c ee Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 ac 9f ff 34 6b 0c ee Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 af 9f ff 34 6b 0c ee Bus 0, api 144, node 1, mid 0x100, to host. Data: c9 b2 9f ff 34 6b 0c ee res velf cosen sinen Note that the resolver outputs change continuously, while the encoder sine and cosine values are updated only every 0.08 sec. It is also possible to log onto the antenna computer and read out the values in shared memory, but this is much slower: > ssh control@bima4 > [control@c10 ~]$ bimaValue name=ELCOSEN # c10 -> bima4 ELCOSEN (int)=13408 A tangled bunch of code inside Drives.cc converts these values into raw az and el readouts. Basically, the code subtracts an offset from the resolver readings to get the zero offset, then rounds downward to an integer number of 2 degrees; the to get fine + coarse; if the offset is within 90 counts,should be accurate; but will jump (in 1 degree increments for elevation, 2 degree increments for az) The expectation is that the resolver is within 0.1 degree of the correct reading resolverCheck.py dumps out the az and el resolver and encoder values and compares them to make sure that we are close; the expectation is that the resolver is within about 0.1 degree of the correct reading (max error of about 20 counts) The telemetry system sends both the encoder and resolver readouts to the antenna computer every .01 sec.; they appear on telemetry word ... However, the encoder is updated only every xxx sec; one can monitor this with cansniffer: the telemetry thread dumps these to shared memory values ... and ...; these can be accessed via bimaValue: Drives.cc combines the coarse and ifne value using an offset in drives.tab; the algorithm is: - find nearest 2 degree value - round off to smaller number - coarse = resolver-offset if < 0: add 65536 # at this point, it is a number between 0 and 65536; most it COULD be is 65536; and we SUBTRACT an offset which had better be positive! int_degrees = coarse*360 / 65536. (this must be 0 or more!) twodeg = degrees & -2 (round to next lower even degrees) (0 -> 0; 1 -> 0; 2 -> 2) assumptions: - readouts stay in sync (if fine is updated, so is coarse) - offsets always are positive - fine and coarse agree fairly well; don't worry about the case where coarse reads 54.9 degrees and fine reads 1.6 degrees; this will be interpreted as 53.6 degrees, not 55.6 degrees!