Advice to decode SUNSAT(SO-35) telemetry


-----
Date: Sun, 28 May 2000 13:21:13 +0900
From: "M. Wakita" [je9pel@jamsat.or.jp]
To: amsat-bb@amsat.org
Subject: [amsat-bb:32227] SUNSAT(SO-35) Telemetry

I received SO-35 telemetry with WiSP32 at 23:00-23:14UTC, 27 May 2000.
You will get ONLY kiss file in your PC with WiSP32 without the setting
up of "Broadcast callsign" and "BBS callsign" for SO-35 in WiSP32.
But you must check previously in GSC such as

  GSC - Setup - Satellite Setup - SO-35 - Edit - 
                 - MSPE Settings - Log Kiss frames
                                   Log telemetry frames - OK
Then,
SUNSAT   SO-35
Uplink   436.291 MHz FM
Downlink 145.825 MHz FM (doppler +-3kHz), 9600bps KISS_mode


You will hear the data bursts once every 10 seconds which are the
telemetry packets of about 50 bytes. The following is a few data.

.................................................................
>OBC1v6: up=3/15:05:5, rst=pwrn, Sat May 27 23:11:15 UTC 2000
fm SUNSAT-3 to APRS ctl UI pid F0
T#010,097,133,191,033,028,11111111
fm SUNSAT-3 to APRS ctl UI pid F0
:BLN4SO35 :FM voice repeater schedule: http://sunsat.ee.sun.ac.za
fm SUNSAT-3 to APRS ctl UI pid F0
T#011,097,128,052,033,028,11111111
fm SUNSAT-3 to APRS ctl UI pid F0
T#013,098,130,023,033,028,11111111
fm SUNSAT-3 to APRS ctl UI pid F0
:BLN5SO35 :Thanks to all who helped with the testing
fm SUNSAT-3 to APRS ctl UI pid F0
T#015,099,147,147,032,032,11100000
fm SUNSAT-3 to APRS ctl UI pid F0
>OBC1v6: up=3/15:06:5, rst=pwrn, Sat May 27 23:12:15 UTC 2000
fm SUNSAT-3 to APRS ctl UI pid F0
:BLNQSO35 :Mode B Audio and Digital Services Active
fm SUNSAT-3 to APRS ctl UI pid F0
T#020,099,146,191,033,074,11111111
.................................................................

SO-35 telemetry raw KISS_file:
  http://www.ne.jp/asahi/hamradio/je9pel/00527s35.zip

SO-35 telemetry converted ascii_file:
  http://www.ne.jp/asahi/hamradio/je9pel/00527s35.htm

SO-35 image_file with WiSP32:
  http://www.ne.jp/asahi/hamradio/je9pel/00527s35.gif

SO-35 home page:
  http://sunsat.ee.sun.ac.za


-----
Date: Sun, 28 May 2000 14:02:40 +0900
From: "M. Wakita" [je9pel@jamsat.or.jp]
To: amsat-bb@amsat.org
Subject: [amsat-bb:32228] Re: SUNSAT(SO-35) Telemetry


> OBC1v6: up=3/15:05:5, rst=pwrn, Sat May 27 23:11:15 UTC 2000
> fm SUNSAT-3 to APRS ctl UI pid F0
> T#010,097,133,191,033,028,11111111

What mean this sequence of numbers in SO-35 telemetry ?


-----
Date: Tue, 30 May 2000 18:01:58 +0200
From: "Johann Lochner" [lochner@ing.sun.ac.za]
Organization: Universiteit van Stellenbosch
To: amsat-bb@amsat.org
Subject: [amsat-bb:32256] Re: SUNSAT(SO-35) Telemetry

Hi Mineo,

 > What mean this sequence of numbers in SO-35 telemetry ?

DECODING OF SUNSAT TELEMETRY

The status and telemetry data formats follow the APRS standard.  A
typical status message is shown below.  After the identifying >
header, the onboard computer generating the message and its current
software version is shown.  This is followed by the current uptime,
reset cause (pwrn: power on, tcmd: telecommand, wdog: watchdog) and
current onboard time.

 >OBC1v6: up=3D3/03:20:54, rst=3Dpwrn, Sat May 27 11:27:12 UTC 2000

The telemetry message contain ASCII data, which can be displayed in
human readable format by terminal software connected to a TNC.  One
sample set (such as the four examples below) from a 25 entry circular
buffer (containing entries numbered 0 through 24) is transmitted at
approximately 9.59 second intervals (orbital period / 25^2).  When
the buffer pointer wraps after 24, all entries are shifted towards
24, by moving a fresh sample set into 0 (and discarding 24).  The
buffer thus contains a history of samples from the last orbit,
sampled at just under 4 minute intervals, with entry 0 being the most
recent addition.

T#000,099,139,059,028,042,11110000
T#001,099,133,110,032,088,11111110
T#002,099,138,140,032,092,11110000
T#003,099,132,132,032,096,11111100

Telemetry data is identified by a T# header.  The message consists of
7 fields, numbered 0 through 6.  The fields contain the following
data: buffer pointer (0 in the first example above), battery state of
charge (99 %), battery voltage (13.9 V), battery current (59 - 128 =
-69, indicating that the battery is a net source of 690 mA; this
field wraps at the extremes), battery temperature (28 C), top plate
sun sensor reading (42, an uncalibrated 8 bit value).  The last field
indicates the state of the 8 solar panel strings (0: sourcing the
power bus, 1: shunted, dumping energy).

Data in fields 1 to 4 is supplied to OBC1 at 60 second intervals. 
Fields 5 and 6 contain raw telemetry, sampled every 2.34 seconds. 
Possible aliasing, as well as the unsynchronized nature of the two
data sources, should be considered when correlating fields. 

Kind regards,
Johann, ZR1CBC


-----
Date: Wed, 31 May 2000 23:44:11 +0900
From: "M. Wakita" [je9pel@jamsat.or.jp]
To: amsat-bb@amsat.org
CC: lochner@ing.sun.ac.za
Subject: [amsat-bb:32267] Re: SUNSAT(SO-35) Telemetry

Johann Lochner" [lochner@ing.sun.ac.za] wrote:

> This is followed by the current uptime,reset cause (pwrn: power on, 
> tcmd: telecommand, wdog: watchdog) and current onboard time.
>
> Telemetry data is identified by a T# header.  The message consists of
> 7 fields, numbered 0 through 6.  The fields contain the following
> data: buffer pointer (0 in the first example above), battery state of
> charge (99 %), battery voltage (13.9 V), battery current (59 - 128 =
> -69, indicating that the battery is a net source of 690 mA; this
> field wraps at the extremes), battery temperature (28 C), top plate
> sun sensor reading (42, an uncalibrated 8 bit value).  The last field
> indicates the state of the 8 solar panel strings (0: sourcing the
> power bus, 1: shunted, dumping energy).

Thank you for your detail above explanations.

For the telemetry what I captured at 23:00-23:14UTC, 27 May 2000,

: OBC1v6: up=3/15:05:5, rst=pwrn, Sat May 27 23:11:15 UTC 2000
: fm SUNSAT-3 to APRS ctl UI pid F0
: T#010,097,133,191,033,028,11111111

Do the next decoding are correct ?

  Uptime                  : 3_days + 15_hours + 05_minutes + 05_seconds
  Reset cause             : power on
  Current onboard time    : Sat May 27 23:11:15 UTC 2000
  Entry buffer pointer    : 10
  Battery state of charge : 97 %
  Battery voltage         : 13.3 V
  Battery current         : 191 - 2^7 = 191 - 128 = 63 = 630 mA
  Battery temperature     : 33 C
  Top plate sun sensor    : 28 (an uncalibrated 8 bit value)
  State of 8 solor panel  : shunted all dumping energy


-----
Date: Wed, 31 May 2000 16:57:44 +0200
From: "Johann Lochner" [lochner@ing.sun.ac.za]
Organization: Universiteit van Stellenbosch
To: "M. Wakita" [je9pel@jamsat.or.jp]
Subject: Re: SUNSAT(SO-35) Telemetry

Hi Mineo,

> Thank you for your detail above explanations.

It was a pleasure.

> For the telemetry what I captured at 23:00-23:14UTC, 27 May 2000,
> 
> : OBC1v6: up=3/15:05:5, rst=pwrn, Sat May 27 23:11:15 UTC 2000
> : fm SUNSAT-3 to APRS ctl UI pid F0
> : T#010,097,133,191,033,028,11111111
> 
> Do the next decoding are correct ?
> 
>   Uptime                  : 3_days + 15_hours + 05_minutes + 05_seconds
>   Reset cause             : power on
>   Current onboard time    : Sat May 27 23:11:15 UTC 2000
>   Entry buffer pointer    : 10
>   Battery state of charge : 97 %
>   Battery voltage         : 13.3 V
>   Battery current         : 191 - 2^7 = 191 - 128 = 63 = 630 mA
>   Battery temperature     : 33 C
>   Top plate sun sensor    : 28 (an uncalibrated 8 bit value)
>   State of 8 solor panel  : shunted all dumping energy

Yes, this all seems fine.  Keep up the good work :-)

Enjoy Sunsat,
Johann, ZR1CBC


-----
Date: Sat, 10 Jun 2000 21:30:33 +0200
From: "Johann Lochner" [lochner@ing.sun.ac.za]
Organization: Universiteit van Stellenbosch
To: "M. Wakita" [je9pel@jamsat.or.jp]
Subject: Re: Why 25^2 ?

Hi Mineo,

> > One sample set from a 25 entry circular buffer is transmitted
> > at approximately 9.59 second intervals (orbital period / 25^2).
> 
> I would like to ask you:
> 
> Orbitral period = 9.6 * 25^2 = 6000 seconds = 100 minutes
> 
> Does this 'Orbital period = 100 minutes' mean the period of a round
> the earth ?   Why divide it by 25^2 ? 

Yes, it refers to the period of one rotation around the earth.  To 
fill the 25 entry buffer with samples from the last orbit (about 100 
minutes), you need to sample at 100 / 25 = 4 minutes.  However, a new 
sample is only taken when the buffer pointer wraps to zero.  You thus 
need to transmit the whole buffer in 4 minutes, which is equivalent 
to one sample every 4 / 25 = 0.16 minutes (or 9.6 seconds).

This mechanism ensures that most buffer entries will be transmitted 
three times during a typical pass, giving simple stations ample 
opportunity to capture a continuous sample set.  The approximate 
sampling instants may be deduced by noting that sample 0 is 
transmitted immediately after being collected, while the other 
samples (1, 2, 3, ..., 24) were acquired at 4 minutes intervals 
before that (at 'sample 0 time' - 4, 8, 16, ..., 96 minutes).

Note that the telemetry transmitted is only a small subset of what is 
available (and indeed what we sample and download as WOD files in 
connected mode).  We'll probably make our whole data base available 
over the Internet in future.  However, the current setup is quite 
suitable for introducing new-comers to monitoring satellites (also 
with easy-to-use equipment like the new generation data radios), 
without suffocating their interest with too much data.

Kind regards,
Johann, ZR1CBC

+------------------------------------------------+
  JG Lochner  ESL, Universiteit van Stellenbosch
  e-pos:      lochner@ing.sun.ac.za
  webtuiste:  http://esl.ee.sun.ac.za/~lochner
+------------------------------------------------+


Back to Top

Back to Home Page