[islandlabs] Balloon Telemetry System Update

Joe toolfox at gmail.com
Sun Mar 6 23:38:52 UTC 2011


The current state of "FLUFFY" (the follow-on APRS unit that will be
replacing BETTI) is getting better.

Early yesterday morning, I went into the tracker's configuration and
lengthened the system's delay between turning on the transmitter and
sending the packets. The old setting, which was 4X overkill for the old
transmitter module (100 milliseconds, and the transmitter's spec says
stable carrier wave 25 milliseconds after activation) was increased to
200 milliseconds.

I turned FLUFFY on, set her in my car out in the back parking lot,
fired up Xastir on the kitchen table, and then went to shower up.

When I came back, Xastir was displaying nearly 100 packets received
with NO skips in the numbered sequence and full GPS coordinates on each
transmission.

I then took FLUFFY for a walk around Patchogue Lake. The map tracking
showed accurate plotting up to about a half mile away to the north,
then a jump to about a half mile to the south as I was returning.

There might be a LOS (loss of signal) problem given the ground clutter,
electronically speaking (lots of buildings, lots of trees, lots of
power lines). For further tests, I'm going to need the real radio that
will be going up (should be in this week sometime) so I can use my
radio to call back to the base station and find out what's going on.

This may be a simple problem of a crappy rubber-duck on the 
RadioShack scanner that I'm using as a receiver that doesn't have a
decent groundplane.

For a handheld radio, the person holding it forms the groundplane.

For a launch, I'm going to use a magmount antenna on the roof of the
chase vehicle, which will give MUCH better results.

It's also been suggested that a 20" length of trailing wire be attached
to FLUFFY's radio chassis to act as a local groundplane.

Further research, experimentation, and testing is needed, but the APRS
system is really coming together.




Joe



P.S. -- The APRS tracker has an internal counter that can report how
many times a signal has been received on one of it's input pins.

This counter can be cumulative or be reset with each packet
transmission.

What if we connected that pin to the still camera's shutter system.
This way, each telemetry packet (separate from the position packet)
would contain a count of how many pictures were taken up to that time.
Each captured packet gets a date/time stamp, so we could match up photo
numbers and time of day.

Instead of counting shutter commands, we could maybe count how many
camera failures occured where the camera turned off and had to be
restarted by the controller.

Thoughts? Comments?


More information about the List mailing list