[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: STP questions

>RUDAK TLM is AX.25 UI frames.  There is no error check information within 
>the data portion of the frame.  A TNC strips off the AX.25 CRC and 
>typically provides a KISS wrapped frame to the computer.  Would the 
>spacecraft telemetry block include the KISS wrapper?  I assume yes.

No, not the KISS header, as that's not end-to-end. The CRC is still
there in the over-the-air frame, and that's the one that should be
carried in the STP frame. Although some hardware demods might not make
the CRC available, it is very easy to get in a software demod, and I
expect the software demods will soon displace them anyway.

>Some satellites may send TLM frames as often as every 2 or 3 seconds.  Is 
>each frame a separate messages in STP, proceeded by the full set header 
>lines?  I assume yes.

Yes. If header overhead is a concern, you can compress.  That will
take care of the redundancy in the frames themselves, not just the STP
headers. I expect this will be standard practice for disk files and TCP

Stream compression would not be suitable for UDP/IP multicast. Here I
have an idea for an abbreviated header. It would be computed from a
hash of the full header, which would be put on every Nth packet so you
could match the abbreviated headers with the full ones. Something
similar is already being done to compress UDP headers in real-time
Internet applications (e.g., voice over IP).

>Many existing 400 bps PSK demods send only 512 bytes of the AO-40 TLM to 
>the computer so no CRC or other error checking is available.  Would the 
>sync vector still be included in the spacecraft telemetry block?  I assume yes.

Yes. And with due respect to those with 400 bps PSK hardware demods, I
believe that the software demods now appearing will perform better at
much lower cost. DSP technology has come a long way since the mid
1970s when the P3 format was defined. With the DSP capability of the
typical consumer PC now significantly outstripping the Cray
supercomputers of the late 1970s and early 1980s, we can not only do a
much better job demodulating the existing telemetry formats, we can
design new formats that will significantly outperform the old ones.

>One might tentatively suggest the following Source definitions for RUDAK in 

I assume there are going to be several Rudak formats, and not all have
been defined yet. E.g., there needs to be a FEC-coded Rudak format
that uses the convolutional encoder, and I need to write up a proposal
for this as well. (I propose to base it on the concatenated
Reed-Solomon/convolutional scheme used by deep space links since
Voyager and since standardized by CCSDS. We could also experiment with
Turbo codes if somebody can address the patent issues.)  We can assign
Source definitions as these formats are defined and implemented.

>even alternately on the same frequency.  For example when a 153k6 downlink 
>is activated the data stream may contain the full TLM data set while the 
>9k6 downlink would be constrained to a small subset.  Should that be 
>implemented how would we define the Source?  Should there be a another 

My thinking is that the Source field should merely tell whoever gets a
STP packet how to interpret the data within it. There are many
analogous identifiers throughout the Internet protocols, including
Ethernet type fields, IP protocol fields, TCP/UDP Well-Known Port
numbers, and MIME types.

All this implies only one Source field per frame format, even if there
can be multiple streams in the same format coming out of the same
spacecraft subsystem at the same time. You can still distinguish
between them with the Frequency: field.  Perhaps the Frequency: field
needs to be mandatory in this case.

>layer under the subsystem name?  The frequency may not always identify the 
>sub-subsystem either because they send on the same frequency or because of 
>Doppler (recognizing the frequency header should be the nominal 
>frequency).  It would be possible to identify the sub-subsystem by 

Well, if the ground station can't distinguish the streams by
frequency, then how else is it supposed to do it? If the ground
station has to dig into the frame to identify it, then this is
something that can be done just as well by the STP receiver.

In other words, I'm not inclined to create a STP header that carries
anything that can be determined from the contents of the frame. The
STP headers are for ground station "meta-data" that *doesn't* show up
in the actual telemetry frame. Hence headers like receive time,
frequency, modulation type, station location, etc.

For the ultimate in generality, I could define a Source type that
means the station is simply digitizing a receiver passband around some
specified RF frequency and sending whatever it hears. And instead of
naming the satellite, it could give antenna az/el. Putting a demod at
the ground station and explicitly naming the source can therefore be
seen as just a form of data compression, as the demodulated data is
much more compact than the raw A/D samples.


Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org