Quoting Douglas Quagliana dquagliana@aol.com:

stefan_wagener@hotmail.com wrote:

...

One key component of failure analysis is the availability of data, especially

...

telemetry. [snip] My question is, can the satellite user community at large come up with

a

...

system that allows the routine capturing of satellite telemetry? Is there a role that AMSAT can play? What would it take?

Thoughts are appreciated.

Hi, Here's my thoughts...

I would like to see a system put in place that is similar to

the one that was up and running while AO-40 was alive. That is, multiple groundstations around the world could receive the telemetry using whatever modem they used and forward that telemetry over the Internet (in either realtime or via email) to a central site which both archives and disseminates the telemetry to other groundstations. The archives were (and still are) publicly available on AMSAT web/ftp site at

http://www.amsat.org/amsat/ftp/telemetry/ao40

I suppose if we asked the right people we could easily get hard drive space on that server to start archiving telemetry from other satellites.

A very nice side effect of the collection efforts was that you could point your telemetry display program (which was not necessarily the same as the program that collected the telemetry and sent it to the server) at the telemetry server and the server would send current live telemetry to you as others sent their telemetry in to the server. In this way you could watch ("Live!") the progress of the satellite even when it was on the other side of the world and even if you yourself lacked the radios and/or modems. This was a lot of fun.

By a curious coincidence, I have been working on a 9600 baud soundcard demodulator for Echo along with a telemetry display program and an Internet telemetry reflector.

Ok, who wants to help?

Douglas KA2UPW/5

Doug and everyone:

By another coincidence, I've been working on some software that does something along the lines Doug mentioned. It comprises two components, both exploiting the jabber conferencing protocol and infrastructure. 'MultiTelemSource' sends changes in a local watch file to a specified jabber conference. This conference's purpose is to aggregate telemetry text from multiple sources. I've not written 'MultiTelemSink', but it is meant to stream out the conference text to do whatever you want. For instance, the folks at Libertad could 'grep' for their callsign and process all telem relating to their project.

I think an open approach like this, where everyone can be a producer and a consumer, will more likely succeed. I'd be more interested in collecting telem. if I knew that by doing so I could enter a group through which I could get a more global view of the sat's health. Furthermore, people who are not generating telem could still join the conference and read the telem.

The code is based on the 'smack' library for java. I've found it to be pretty robust. (I tried some other libraries and after a couple of days the links were lost, etc.) I'm pretty sure the best idea is to make use of technology like jabber, in any case: there's so much infrastructure there.

Beyond simply relaying the telem as added to the watch file, I've also played with getting the code to 'announce' a station's capabilities in the streaming XML when an instance of the program first signs on. Projects could use this info to assess the quality of a station required to successfully downlink.

A more clever set of tools could also automatically web-publish audio files and send links to them in the data stream, too. I suppose wiring up with predict could let the software automatically label the links with the name of the tracked satellite.

The code needs some passwords and such stripped out before I can put it on the web. I'll do that in the next couple of days.

In the meantime if you want to see the code at work (but not with real telem.) go to cubesats@conference.jabber.org with your jabber client.

73, Bruce VE9QRP