Debugging ANSRTrack – Part 3
Debugging ANSRTrack – Part 3
Unexplained Rotator Movement
There is one final problem noted during the inaugural flight with the new ANSRTrack Ground Station program. At a point about 30 – 45 minutes into the flight, the ground station received an APRS beacon from the balloon, on its normal 30 second interval.
The azimuth rotor suddenly rotated about 45 degrees counterclockwise from its prior position. As I looked at the screen to determine what might have happened, we received another beacon, and the azimuth control returned to where it should have been pointing. This twice. Once at about 36 minutes into the flight, and once at about 42 minutes into the flight.
There are a couple of possible causes for this action.
- We may have received a bad packet from the APRS beacon on the balloon.
- We may have calculated the wrong bearing to the balloon for those two packets.
- There may be a communication problem at the ground station.
- Between the TNC and the computer or…
- Between the computer and the rotor controller
- There may be a hardware problem.
- The rotor controller may have failed
- The rotor interface may have failed
- There may have been a shorted connection between the rotor and the rotor controller.
Since this is a new program, my first suspicion is that there is a calculation error in the program, given some very specific circumstance.
To chip away at the problem, I decided to first examine the telemetry data stored on the two independent beacons for the balloon.
These are stored as $GPGGA and $GPRMC GPS sentences on each beacon payload package. They are saved and archived after every flight. I got onto our google drive site and downloaded the appropriate files.
$GPRMC,160244.00,A,3626.31640,N,10841.94539,W,63.046,87.43,260319,,,D73 $GPVTG,87.43,T,,M,63.046,N,116.761,K,D31
$GPGGA,160244.00,3626.31640,N,10841.94539,W,2,12,0.87,15858.4,M,-22.5,M,,000066 $GPGSA,A,3,26,27,16,31,22,03,23,51,09,07,06,14,1.49,0.87,1.210C
$GPGSV,4,1,14,03,58,206,45,04,11,300,39,06,05,307,38,07,18,253,417C $GPGSV,4,2,14,09,26,306,44,14,06,106,33,16,61,122,41,22,40,184,457A
$GPGSV,4,3,14,23,59,323,45,26,50,064,39,27,05,138,38,31,15,057,417C
Analysis of the telemetry logs reveals that there were no anomalies in the GPS coordinates reported. This doesn’t mean that something on the payload didn’t change the data after it was measured, but that would seem unlikely.
Next, I wanted to see how the ANSRTrack program would respond to a “replay” of the flight.
I wrote a Perl program to extract the latitude, longitude and altitude from the telemetry files, and generate new APRS KISS formatted packets, just like my TNC would deliver to the ANSRTrack program in normal operation.
I set up an Arduino to play every 30th packet, to get a 30 second interval, since the telemetry is stored at 1-second intervals. Playing this stream into the ANSRTrack program, and saving the rotator commands to a file, I was able to graph the results in LibreOffice Calc (Excel equivalent for linux).
The graph shows that there are no anomalies with the rotator commands generated from this stream.
Finally, I ran a similar simulation, but used every 1-second telemetry packet. The program is fast enough to keep up with this rate without problems. This should increase the odds that we would hit that special circumstance that caused the problem. But again, no anomalies were found in the commands generated. Notice that there are no bars on the graph sticking out from their neighbors, other than the normal transition through true north (from 359 degrees to 0 degrees…)
So that leaves either some intermittent hardware problem, or a software problem that we haven’t been able to duplicate.
I think the path forward is to modify the ANSRTrack code to log the incoming telemetry (to show what it thinks it heard), and the outgoing rotator commands (to show what it thinks it sent). Then we will run some more flights and wait for the problem to recur.
We’ll keep you updated if we run into the problem again.
Comments
Post a Comment