Compustar output for Dome support

10th December 2019: Updated for firmware 1.90!

Beware! This is a pretty technical post. Reason is, these informations are useful to everyone who wants to build an automated dome controller for the Compustar. Therefore, useful to no one, I guess…

Compustar 64K firmwares, starting with version 1.80, output a dataframe that can be used to calculate the position the telescope is pointing to and therefore automate a dome (or do something else).
Due to the very limited resources available in the Compustar microprocessor, the output frame does not use any particular standard, and a special dome implementation or/and external hardware is required to translate these data to some other standard.

Due to this reason, I’m developing a custom Dome controller for the “Osservatorio Città di Legnano” I will document next year with a dedicated post.

The frame is output to pin 12 of the DB-25 connector connecting the Compustar to the power box. This was an otherwise unused pin which was connected to and output-only port inside the Compustar itself.
Bits are output as a standard asychronous TTL-level RS232 output-only port.

Firmware version 1.80 outputs data at the very unusual bitrate of 1709bps, 8 data bits, no parity and several stop bits (which means that there is a considerable gap between characters).

Firmware version 1.90 outputs data at 854bps, 8 data bits, EVEN parity, to improve transmission reliability (since motor interrupts could have distorted the 1709bps bits a little too much). Note that the bits are output in a non standard way: instead of <Start><Bit 0>…<Bit 7><Parity><Stop>, the transmitted frame is <Start><Parity><Bit 0>…<Bit 7><Stop>. You will find a lookup table to translate the received byte into the correct value, here.

And if you wonder why 1709/854 bps, that’s because it is a software implementation of a serial transmission port, transmitting one bit every (other) display refresh cycle (which happens to be right at 1709 Hz).

Note (10th December 2019): I’ve corrected/improved some of the frame validation rules below.

The Frame

Frame content (Firmware 1.80):

Frame content (Firmware 1.90):

Frame Synchronization

• You should synchronize the reception using the Sync bytes.
  This could be done in two ways:
  1) Search for 3 consecutive bytes with 0xF in the upper nibble.
  2) Search for the 3 synchronization bytes (0xF9,0xFB,0xFD).
  Method #1 is more future-proof, because I could (if needed) use the lower nibble of the sync bytes to transmit additional information without having to change the frame length (which is another thing I cannot easily do)

• You must have the synchronization process running all the time, and you should resync every frame.
  This because (for some internal alignment reasons), every 3 frames there will be a spurious byte sent between the end of one frame and before the Sync Bytes of the following one. If you resync every frame, this additional “spurious” byte will be ignored. The value of this spurious byte is not defined, but it will not have 0xF as the high nibble.

Frame validation

Given the very few resources available for the creation of this frame in the Compustar, basically no data is double buffered. This means that it will happen that, sometimes, some values in the frame will not be correct. These are the recommended rules to recognize (and ignore) invalid data.

• RA/DEC: TL;DR version: if the “Coords not valid” bit is 0, they are both fine.
  Detailed explanation:
  RA/DEC are the object coordinates when the telescope is slewing (“DEC Slew” and/or “RA Slew” bit set to 1), and the current telescope coordinates otherwise. When a slew begins or ends, there is a switch between telescope coordinates to object coordinates or viceversa, and this switch is not synchronized with the frame transmission, so they may end mixed up. So when the switch occurs, to avoid transmitting wrong coordinates, the code will mark them as “not valid”.
  Note that RA and DEC are separated, so you could get the telescope coordinates for one of them and the object coordinates for the other one. Use the “DEC Slew” and “RA Slew” bits if you want handle them differently (but there is no reason to do so, I think).
• Time: It’s valid if the difference between the value read in the current frame and the value read in the previous frame is less than 5 6 (which is 0.5s 0.6s). Ignore otherwise. (Note: 6, not 5, is the correct value for all firmware versions)
• Date: It’s valid if the value read in the current frame is equal to the value read in the previous one AND the time in the current frame is valid (per the time verification rule above). Ignore otherwise.
• Site Latitude: it’s valid if the value read in the current frame is equal to the value read in the previous one. Ignore otherwise.
• Site Longitude: it’s valid if the value read in the current frame is equal to the value read in the previous one. Ignore otherwise.
• Site longitude (Bits 15..8): if the high nibble IS 0xF, discard the whole frame because some bytes went missing and the whole frame in unreliable (Note: this is valid for all firmware versions)

Additional notes

• When slewing, the frame contains the (target) object coordinates instead of the current telescope ones.
  This is easier to implement, but also more useful since it allows the dome to slew directly to the target of the slew instead of simply follow the telescope.
• OPT-8-3, OPT-8-2 are 2 Compustar options that are sent to the dome controller. Their meaning is left to the Dome controller implementation.
• There is no method to verify if Longitude and Latitude are a meaningful pair: if the user is entering the observatory coordinates in the Compustar, you will get, at one point, a valid and updated Longitude with a valid and old Latitude. This should not be a problem because the Compustar will always boot with Dome Sync (OPT-7) disabled and the user is expected to enter the correct observatory coordinates before activating the Dome Sync (and this will be done if using BEGIN with Dome Auto-Sync active – OPT-8-4).
• This is the lookup table to convert received bytes to their correct value.
  This table contains 256 values: use the received byte as an index in this table to read the correct byte.

  0x00,0x80,0x81,0x01,0x82,0x02,0x03,0x83,0x84,0x04,0x05,0x85,0x06,0x86,0x87,0x07,
  0x88,0x08,0x09,0x89,0x0A,0x8A,0x8B,0x0B,0x0C,0x8C,0x8D,0x0D,0x8E,0x0E,0x0F,0x8F,
  0x90,0x10,0x11,0x91,0x12,0x92,0x93,0x13,0x14,0x94,0x95,0x15,0x96,0x16,0x17,0x97,
  0x18,0x98,0x99,0x19,0x9A,0x1A,0x1B,0x9B,0x9C,0x1C,0x1D,0x9D,0x1E,0x9E,0x9F,0x1F,
  0xA0,0x20,0x21,0xA1,0x22,0xA2,0xA3,0x23,0x24,0xA4,0xA5,0x25,0xA6,0x26,0x27,0xA7,
  0x28,0xA8,0xA9,0x29,0xAA,0x2A,0x2B,0xAB,0xAC,0x2C,0x2D,0xAD,0x2E,0xAE,0xAF,0x2F,
  0x30,0xB0,0xB1,0x31,0xB2,0x32,0x33,0xB3,0xB4,0x34,0x35,0xB5,0x36,0xB6,0xB7,0x37,
  0xB8,0x38,0x39,0xB9,0x3A,0xBA,0xBB,0x3B,0x3C,0xBC,0xBD,0x3D,0xBE,0x3E,0x3F,0xBF,
  0xC0,0x40,0x41,0xC1,0x42,0xC2,0xC3,0x43,0x44,0xC4,0xC5,0x45,0xC6,0x46,0x47,0xC7,
  0x48,0xC8,0xC9,0x49,0xCA,0x4A,0x4B,0xCB,0xCC,0x4C,0x4D,0xCD,0x4E,0xCE,0xCF,0x4F,
  0x50,0xD0,0xD1,0x51,0xD2,0x52,0x53,0xD3,0xD4,0x54,0x55,0xD5,0x56,0xD6,0xD7,0x57,
  0xD8,0x58,0x59,0xD9,0x5A,0xDA,0xDB,0x5B,0x5C,0xDC,0xDD,0x5D,0xDE,0x5E,0x5F,0xDF,
  0x60,0xE0,0xE1,0x61,0xE2,0x62,0x63,0xE3,0xE4,0x64,0x65,0xE5,0x66,0xE6,0xE7,0x67,
  0xE8,0x68,0x69,0xE9,0x6A,0xEA,0xEB,0x6B,0x6C,0xEC,0xED,0x6D,0xEE,0x6E,0x6F,0xEF,
  0xF0,0x70,0x71,0xF1,0x72,0xF2,0xF3,0x73,0x74,0xF4,0xF5,0x75,0xF6,0x76,0x77,0xF7,
  0x78,0xF8,0xF9,0x79,0xFA,0x7A,0x7B,0xFB,0xFC,0x7C,0x7D,0xFD,0x7E,0xFE,0xFF,0x7F