SB  ALL@AMSAT < DB2OS  $GGJA-4173-86
WO-18: Picture protocol (corrected version)
R:900302/0615z 43586@W3IWI.MD.USA [Balto/Wash MD/DC/VA/DE] Z:21029
R:900302/0545z 33653@WA3ZNW.MD.USA.NA [Wheaton,Md] Z:20906 N:MCBBS
R:900302/0531z 12386@K4NGC.VA.USA.NA [Woodbridge, Va]  Z:22193
R:900301/0017z 50847@N4QQ   [Silver Spring,Md]  Z:20901
R:900301/1953z 16180@N4QQ-1 [McLean, VA  USA]  Z:22101
R:900301/1545z 14544@GB7LDI [JO02ON]
R:900225/1024z 41768@4X1RU  
R:900225/0758z @DK8AT  []
R:900224/2337z @DK0MAV [NORD><LINK PEINE, JO52CI, TheBox 1.6 OP: DF3AV]
de DB2OS @ DK0MAV

Posted: Wed, Feb 21, 1990   1:49 AM GMT
From:   WEBER
To:     amsat
Subj:   correct protocol

     I have been told there is an erroneous description of the picture
protocol published on Compuserve.  To avoid the possibility of people
wasting their time with it, below is the correct, complete description.

     The format of picture data for the camera color composite signal is
as follows:

     Callsign (for this transmission scheme) is PHOTO (for the camera).
SSID is picture number (modulo 16).  We are currently often overwriting
a given picture number with different pictures perhaps twice a day.  This
is done when a picture is clearly black and there is no point in getting
all of it.

     The first two bytes of data portion of the UI frame (packet)
contain the 10-bit X position of the first sample in that packet, the
two most significant bits of the X position occupy the two least
significant bits of the first byte, the eight least significant bits of
X are in the next byte.  Legal X values are from 0 to 644.  Y values are
in third byte and range from 0 to 241.  If the two least significant
bits of the first byte are both set (forming an X 768..1023), the data
beginning with the second data byte is clear text information about the
picture (which we call the "picture header") occupying 252 bytes.  The
six most significant bits of the first byte are reserved for future
protocol definitions, only one of which is presently defined.

     The data then consists of a sample for every third X value.  This
has little to do with RGB, but is relevant to color as the NTSC waveform
is sampled at precisely 3 times the color burst frequency.  A zero byte
value indicates a simple compression sequence as follows: 00, the count
of repeats, then the value repeated.  Actual samples with a value of 0
(hor. sync) are changed to 1 to allow indicating a following compression
sequence.  When the X value is greater than 644, increment the Y value
by two and subtract 645 from the X value.  At the end of one of these
compression passes, encoding returns to the top of the pic, moves one
byte to the right and proceeds.  This takes place three times to
complete one half pic (every other line).  Alternating half pics (even
vs. odd) lines are transmitted every 101 minutes (every other
visibility pass at these latitudes).  There is not vertical sync transmitted.
The picture begins at the end of the header.

     The 645th byte of a reconstructed line is the count of zeroes which
was in the original digitized sample between the 644th byte of that
line and the beginning (the first non-zero) of the next line.  If you
are reconstructing the original waveform replace that count byte with
that many zeroes.

     I must again emphasize that this protocol is very temporary and can
be expected to change with little advance notice.  The compression scheme
is poor and was selected only for its simplicity.  It also will change.
These changes will be handled with Weberware version updates.  Also,
please note that we have the ability to download individual R, G or B
signals from the camera and their protocol may be different.  Ditto for
the 1.2 GHz experiment.  For those, however, you can expect a bit more
advance notice of variation.

     As of today, only one picture has been arguably of the earth.  We
have been taking pictures (15) for only 8 (12 of our 15 on the first
day) days now and it will require time to polish our procedures.  We are
concentrating on the equator now because pre-launch projections
suggested potential problems at high latitudes.  The first 12 pics were
over the U.S. and none were of the planet.  We have taken one pic at
night (in the dark) to characterize performance.  Two interesting
tidbits.  Shots that turn out to be of the sun don't move the impact
sensor because, presumably, the iris is stopped down and has little
distance to spring closed.  Deep space photos increment the impact
sensor considerably.  The second tidbit has to do with the night photo.  It
has an average light level much lower than even the deep space photos taken
during the day.  Perhaps a little atmospheric glow around the spacecraft
even at that altitude?

     Thank you all for your interest.

73's,
Chris




/EX