Helium Balloon GPS & RTTY

A friend and I are trying to launch a Helium balloon using the Arduino as the flight computer and transmitting its GPS coordinates back to earth via RTTY.

The code sort of works, but after sometimes 30 transmissions, the they seem to “lock” and the same GPS coordinates are transmitted each time.

I’m not sure if it is a buffer issue, but i am now stuck.

The GPS receiver works fine and talks to the Arduino via the hardware Tx / Rx.

Can anyone cast their eye over the code and see if there is any obvious mistakes please.

Unfortunately the code is too long to post here :frowning:

Many thanks,

balloon_project_2.ino (14.8 KB)

I'm confused.

The GPS receiver works fine and talks to the Arduino via the hardware Tx / Rx.

Why are the pins that the Debug instance talks to called GPSrx and GPStx, then? What IS connected to those two pins?

You aren't having problems with the commented out code, obviously. So why are we expected to wade through it?

You don't have memory to spare. test_str, which is not referenced, occupies a fair portion of that memory.

Why are you including WString.h? I almost closed the file, and moved on.

char buffer[200];
char str_out[200];

That's 20% of the memory on a 328-based machine.

  //Insert stop bits on the string.
    clock[6]='\0';
    lat[10]='\0';
    lon[10]='\0';
    no_sat[2]='\0';
    alt[alt_count]='\0';

This assumes that the GPS returned exactly the same number of characters for each field, every time. That is not a valid assumption. Every time a character is added to an array, a NULL should be stuffed in the next element.

    int  a  =  sprintf(buffer, "$%s,%u,%.2ld:%.2ld:%.2ld,%s,%s,%ld,%.2u\0",
    callsign,  ticks,  gps.hour,  gps.minute,  gps.second,  gps.lat,  gps.lon, gps.alt, gps.sat);

ticks is an int (%d), not an unsigned.

    int b = sprintf(str_out, "%s%s\n\0", buffer, checksum_str);

Why not just strcat() checksum_str onto buffer, instead of copying buffer to str_out?

  long hour;   //Shouldn't need to be a long, but is multiplied a lot when used, so programs fails if this is an int.

This comment is wrong, and the "solution" is wrong. Where the int is used, casting should be done to make sure that the value doesn't overflow.

Actually, a lot of what this code does is unnecessary/wrong. Parsing the GPS data, converting to numeric values, then converting back to strings, to be sent, should not be done on the Arduino. Simply collect and send the GPS data. Parse and convert on the receiving end.

    if (1.0*ticks/20 == ticks/20) set_GPS(); //This should every 20th cycle reset the GPS, ensuring that it remains in Nav Mode with all of the correct strings in place

Exact comparison of ints and floats is not recommended. What would cause the GPS to need to be reset?

It takes 200 milliseconds per character to send data in the rtty_50() function. You are sending about 50 characters. That will take 10 seconds total to send all that data.

During that time, you are guaranteed to lose GPS data. The serial buffer is simply not large enough to hold 10 seconds worth of GPS data, especially considering that you can never catch up.

You MUST find a faster way to send data from the balloon to the ground.