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):

0Sync byte #10xF9, fixed value
1Sync byte #20xFB, fixed value
2Sync byte #30xFD, fixed value
3YearSince 1900, so 118 is 2018
4Month1 = January
5DayDay of month
6Time of day (Bits 7..0)0.1s from midnight, UT
7Time of day (Bits 15..8)
8Time of day (Bits 23..16)
9Right Ascension (Bits 7..0)Right Ascension is a 3 bytes value. Divided by 3200 gives RA in minutes.
10Right Ascension (Bits 15..8)
11Right Ascension (Bits 23..16)
12Declination (Bits 7..0)DEC is a 3 bytes value. Divided by 128 gives the declination in primes.
13Declination (Bits 15..8)
14Declination (Bits 23..16)
15Flags #1Bit 7: Force DOME realign (SLEW/ALIGN)
Bit 6: Declination sign, 1=negative
Bit 5: Coords not valid: 1=RAD/DEC coordinates in this frame are not valid and therefore should be ignored
Bit 4: Display is OFF (SET/SCOPE/DISP/ALL)
Bit 3: OPT-8-3
Bit 2: OPT-8-2
Bit 1: 1=Declination is slewing, DEC Coords are object coords (not the current telescope coordinates)
Bit 0: 1=RA is slewing, RA Coords are object coords (not the current telescope coordinates)
16Site Latitude (Bits 7..0)Site Latitude is in primes, bit 15 is sign, 1 = negative
17Site Latitude (Bits 15..8)
18Flags #2Bit 7: Unused
Bit 6: Unused
Bit 5: Unused
Bit 4: Unused
Bit 3: Dome SYNC active (OPT-7)
Bit 2: Display is dimmed
Bit 1: Parking/Parked
Bit 0: 1=Current movement has been done manually.
19Site longitude (Bits 7..0)Site longitude is in primes, it's the same number entered in the Compustar (0 to 359°)
20Site longitude (Bits 15..8)

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.



1 commento

    • Randy il April 18, 2023 alle 23:38
    • Rispondi

    Maybe I am no one I will find the dome support useful. I am building an observatory for my 22″ CompuStar controlled telescope. The observatory has a rotating octagon “dome”. This option is useful

Leave a Reply

Il tuo indirizzo email non sarà pubblicato.