Working late into the night, I was trying to prepare the flight computer and relevant systems for a range test. I'd had poor results in earlier tests, and made the call that we would not launch if we could not get at least 1 mile of range on the radio.
But we never got as far as the range test. We had components outside, we were moving to the cars, when suddenly I noticed the flight computer had stopped transmitting. The transmitter was still on, but it wasn't doing anything. I re-uploaded the sketch to no avail.
Finally we went back inside and I did some more debugging. The SD card library that had been supposedly fixed for chipkit processors was having problems. After a file got too big, it would hang when trying to write, and stop the whole show. I looked at the data on the SD card and saw that the last time data had been recorded had been 30 minutes ago, despite the fact the flight computer was on the whole time.
Trying to fix the issues by switching flight computers led to damage to the SD card shield that we surprisingly weren't able to repair, even with the most primitive methods. Another decision I had made is that we had to log flight data to the onboard SD card. In the event the radio communications broke off, but we managed to find the payload either via the cell phone backup or some good samaritan finding it and calling us, I wanted to know the ground track of the balloon and the max altitude it achieved. This would help indicate how accurate the predictions were, and that seemed important enough to me.
So we're not able to launch the balloon, but the preparations to do so certainly got me closer to launching than I've been yet. The flight box is pretty much assembled, and it weighs about 2.5 lbs without batteries, comfortably under the FAA 4lb limit for such payloads. The flight computer has matured from breadboard to protoshield, and the code, while still having issues, is coming along. Most of the materials are in place, now we just need a new opportunity.
The rest of this post has some more details on the other tasks on which we made progress and the errors we faced.
But we never got as far as the range test. We had components outside, we were moving to the cars, when suddenly I noticed the flight computer had stopped transmitting. The transmitter was still on, but it wasn't doing anything. I re-uploaded the sketch to no avail.
Finally we went back inside and I did some more debugging. The SD card library that had been supposedly fixed for chipkit processors was having problems. After a file got too big, it would hang when trying to write, and stop the whole show. I looked at the data on the SD card and saw that the last time data had been recorded had been 30 minutes ago, despite the fact the flight computer was on the whole time.
Trying to fix the issues by switching flight computers led to damage to the SD card shield that we surprisingly weren't able to repair, even with the most primitive methods. Another decision I had made is that we had to log flight data to the onboard SD card. In the event the radio communications broke off, but we managed to find the payload either via the cell phone backup or some good samaritan finding it and calling us, I wanted to know the ground track of the balloon and the max altitude it achieved. This would help indicate how accurate the predictions were, and that seemed important enough to me.
So we're not able to launch the balloon, but the preparations to do so certainly got me closer to launching than I've been yet. The flight box is pretty much assembled, and it weighs about 2.5 lbs without batteries, comfortably under the FAA 4lb limit for such payloads. The flight computer has matured from breadboard to protoshield, and the code, while still having issues, is coming along. Most of the materials are in place, now we just need a new opportunity.
The rest of this post has some more details on the other tasks on which we made progress and the errors we faced.
Flight Box:I found an old styrofoam box lying around the house that was just about the perfect size for the project. I saw another project using a modular system, which gave me the idea for the clipboard. In retrospect, I could have thought through the installation process a bit more, since the clipboard doesn't really do much, but when I reconfigure everything it will make field testing easier.
At least now it looks like all those payloads I've seen on everyone else's blogs :)
At least now it looks like all those payloads I've seen on everyone else's blogs :)
Antenna:
This is a 1/4 wave ground plane antenna, build out of a SO239 mount plate (easily available at your local RadioShack) and metallic coat hangers (easily available at your local closet).
It should augment the transmit ability of the NTX2. We did a quick and dirty range test just on the street with this thing (and the transmitter outputting a static message, no GPS data), and it worked well up to about 1/3 of a mile, but then we lost line-of-sight, so it's hard to conclude if it's just a weak antenna or if it really just needs line of sight (which shouldn't be too hard at 30km....)
This is a 1/4 wave ground plane antenna, build out of a SO239 mount plate (easily available at your local RadioShack) and metallic coat hangers (easily available at your local closet).
It should augment the transmit ability of the NTX2. We did a quick and dirty range test just on the street with this thing (and the transmitter outputting a static message, no GPS data), and it worked well up to about 1/3 of a mile, but then we lost line-of-sight, so it's hard to conclude if it's just a weak antenna or if it really just needs line of sight (which shouldn't be too hard at 30km....)
Flight computer:
The issues with the SD card were described above, but there was another issue I was running into. The transmitter would only transmit either GPS data (only when the GPS had a lock) or that the GPS was searching for a signal (even if it did have a lock). The ideal behavior is that it transmits when the GPS is searching for a signal, and when it finds one begins to transmit the GPS data. But depending on how the code was set up, it could only do one, or the other.
I put in an element of the code that looks like this to have the transmitter send a message while the GPS didn't have a lock:
gps.f_get_position(¤t_lat, ¤t_lon, &fix_age); //Get the current latitude and longitude from the GPS, as well as how //old the information is
if ( fix_age==TinyGPS::GPS_INVALID_AGE && ((check_GPS_fix - millis()) > 60000)) { //check if unit has a fix and if 60sec have //passed
rtty_txstring("Acquiring signal\n"); //Send a message through the transmitter that GPS does not have a signal
check_GPS_fix = millis(); } //Update the time against which to check if 60 seconds have passed
In English, what this is doing is pulling the latitude and longitude from the GPS chip, as well as how much time has passed since that information was decoded. If that last bit of information, how long it's been since the information was decoded, reads as invalid the computer sends a message to the ground that the GPS is still acquiring the signal. It's only supposed to do this once a minute, so that some resources can go to finding a signal, instead of pooling all resources into telling the ground it doesn't have a signal.
However, I didn't implement the code correctly. If you look at the condition for a minute passing, it says take your reference time (check_GPS_fix, which is initialized at 0), SUBTRACT the amount of time the program has been running, and see if that number is over 60000 (the millis() command tells you for how many milliseconds the program has been running). So, since I'm subtracting a large number from 0, THIS CONDITIONS SHOULD NEVER BE TRUE. Meaning, the incorrect way I wrote it means a minute will never pass, according to the code.Since I'm using an AND condition (that's the &&, which, for non-computer people means both sides have to be true for the program to run the stuff inside the curly braces), and one of the conditions is NEVER TRUE, the program SHOULD NEVER NEVER NEVER EVER AT ANY TIME execute what is inside the curly braces.
BUT IT DOES!!!! With this snippet of code inside the program, all that ever happens on the receiver end is that the user sees "Acquiring signal" forever and ever. I can't fathom right now why this would be, but I'll post to some forums and see what people who have more experience with the TinyGPS library have to say. Without resolving this issue, loss of communication with the payload could be either a GPS problem or a radio problem, but being on the ground we won't know which, and this is unacceptable.
Update: On the Arduino forums one user wisely pointed out that 60000 is larger than the largest positive number a computer can store in the default "int" storage format (32767). Being too large, it goes over and becomes a negative number, in which case it makes sense that the program enter the if-statement (executes the stuff in the curly braces). Although that doesn't explain why the same issue occurred when I used a 20 seconds delay time instead of 60 seconds.....
The issues with the SD card were described above, but there was another issue I was running into. The transmitter would only transmit either GPS data (only when the GPS had a lock) or that the GPS was searching for a signal (even if it did have a lock). The ideal behavior is that it transmits when the GPS is searching for a signal, and when it finds one begins to transmit the GPS data. But depending on how the code was set up, it could only do one, or the other.
I put in an element of the code that looks like this to have the transmitter send a message while the GPS didn't have a lock:
gps.f_get_position(¤t_lat, ¤t_lon, &fix_age); //Get the current latitude and longitude from the GPS, as well as how //old the information is
if ( fix_age==TinyGPS::GPS_INVALID_AGE && ((check_GPS_fix - millis()) > 60000)) { //check if unit has a fix and if 60sec have //passed
rtty_txstring("Acquiring signal\n"); //Send a message through the transmitter that GPS does not have a signal
check_GPS_fix = millis(); } //Update the time against which to check if 60 seconds have passed
In English, what this is doing is pulling the latitude and longitude from the GPS chip, as well as how much time has passed since that information was decoded. If that last bit of information, how long it's been since the information was decoded, reads as invalid the computer sends a message to the ground that the GPS is still acquiring the signal. It's only supposed to do this once a minute, so that some resources can go to finding a signal, instead of pooling all resources into telling the ground it doesn't have a signal.
However, I didn't implement the code correctly. If you look at the condition for a minute passing, it says take your reference time (check_GPS_fix, which is initialized at 0), SUBTRACT the amount of time the program has been running, and see if that number is over 60000 (the millis() command tells you for how many milliseconds the program has been running). So, since I'm subtracting a large number from 0, THIS CONDITIONS SHOULD NEVER BE TRUE. Meaning, the incorrect way I wrote it means a minute will never pass, according to the code.Since I'm using an AND condition (that's the &&, which, for non-computer people means both sides have to be true for the program to run the stuff inside the curly braces), and one of the conditions is NEVER TRUE, the program SHOULD NEVER NEVER NEVER EVER AT ANY TIME execute what is inside the curly braces.
BUT IT DOES!!!! With this snippet of code inside the program, all that ever happens on the receiver end is that the user sees "Acquiring signal" forever and ever. I can't fathom right now why this would be, but I'll post to some forums and see what people who have more experience with the TinyGPS library have to say. Without resolving this issue, loss of communication with the payload could be either a GPS problem or a radio problem, but being on the ground we won't know which, and this is unacceptable.
Update: On the Arduino forums one user wisely pointed out that 60000 is larger than the largest positive number a computer can store in the default "int" storage format (32767). Being too large, it goes over and becomes a negative number, in which case it makes sense that the program enter the if-statement (executes the stuff in the curly braces). Although that doesn't explain why the same issue occurred when I used a 20 seconds delay time instead of 60 seconds.....
RSS Feed