|1.1||29-Feb-2016||Update for Mk4|
The Mark I and Mark II ST5000 star trackers produce various kinds of "primitive" image types, and the ST5000 image handling software can transform these primitive types into "reduced" types. This note describes these data products.
Each version has a video ram into which the image is written by the frame grabber.
mk1 image ram: 2**20 bytes
mk2 image ram: 2**19 bytes (each; it has two of these, A & B).
mk4 image ram: 2**19 bytes (each; it has two of these, A & B).
Each frame grabber has a natural line length. This is the number of video ram bytes between 2 sensor pixels in the same sensor column.
mk1 natural line length: 1024
mk2 natural line length: 910
mk4 natural line length: 910
Each frame grabber has its own style of writing pixels into image ram.
The mk1 sensor data fall roughly between bytes 10 and 765. There is essentially no dead space before the start of the even field, and no dead space between the even and odd fields.
The mk2 sensor data fall roughly between bytes 210 and 950. There is dead space (about 20 lines) before the even field, and also between the fields (also about 20 lines).
The mk4 sensor data fall roughly between bytes 140 and 920. There is dead space (about 20 lines) before the even field, and also between the fields (also about 20 lines).
The "active area" is that part of image ram into which the grabbing is done.
mk1 active area: 768 x 480 = 368640
mk2 active area: 910 x 525 = 477750
mk4 active area: 910 x 525 = 477750
Note that the natural line length of the mk1 is larger than the active area. You save the first 768 bytes, then ignore the next 256. For the mk2 and mk4 units, the lengths agree, so no bytes are ignored.
The file types vary by how much image ram they represent, which data management codes are built into them, and whether the fields have been shuffled into frames. Embedded line numbers are encoded MSB first:
line = (length >> 8) & 0xff
line = (length >> 0) & 0xff
length = ((line << 8) + line) & 0xffff
File types vary according to suffix:
mk1: 2+2+768 x 480 = 772 x 480 = 370560
mk1: 2+1024 x 1024 = 1026 x 1024 = 1050624
mk2: 2**19 = 524288
mk4: 2**19 = 524288
mk1: 2+768 x 480 = 770 x 480 = 369600
mk2: 2+910 x 525 = 912 x 525 = 478800
mk4: 2+910 x 525 = 912 x 525 = 478800
mk1: 768 x 480 = 368640
mk2: 910 x 525 = 477750
mk4: 910 x 525 = 477750
You can convert between field and frame lines (FH = field height):
mk1 field height: 241
mk2 field height: 263
mk4 field height: 263
frame = 2 * field (field line < FH)
frame = 2 * (field-FH) + 1 (field line >= FH)
field = frame/2 (frame line even)
field = frame/2 + FH (frame line odd)
mk1 frame: 768 x 480 = 368640
mk2 frame: 910 x 525 = 477750
mk4 frame: 910 x 525 = 477750
Finally, there is the "good" part of the image to work with. This has to allow for the ragged edges in the grab, the late start of the image in the mk2 unit, and so on. Only good sensor data should be included.
mk1 good area: 740x460+10+12 = 340400 good pixels
mk2 good area: 740x460+210+40 = 340400 good pixels
mk4 good area: 694x460+140+30 = 319240 good pixels
Note: the mk2 unit shows a little variation in the "210" figure. This may be due to part-to-part variation in the flash ADC. It has been seen as large as 215, in which case the image is "shifted right" with wraparound: 5-ish pixels from the right edge of the sensor appear at the left of the frame.