Adding Extra Sensors

One of the new features of the ptFlex that really differentiates it from the other trackers is the simple integration of external sensors thanks to the Qwiic connector.  The Qwiic connector is the brainchild of Sparkfun Electronics, whereby they have created a standard cabling scheme for 3.3V I2C sensors.  Sparkfun currently has dozens of sensors available for purchase, that can plug directly into the side of the Project: Traveler ptFlex flight controller.

Learn more about Qwiic Connectors

Integrating the Code

in the ptFlex firmware, two new files have been added to facilitate custom coding.  They are custom.h/custom.cpp files.

There are four hooks into the standard code in which to insert your custom logic.

  • void customInit();
  • bool customLoop(GPS& GPSParser);
  • void customSendPositionSingleLine(bool transmitCustom, TNC& oTNC, GPS& GPSParser);
  • void customExercise();

Sample scripts are included inside of the custom.cpp file that will help you get started.  Note that there are three separate sensors included in the sample, however by default none of them are actually included (via the #include directive), and therefore they do not execute (because of the #ifdef preprocessor directives).  

customInit

The Init routine is called during the initial boot sequence of the ptFlex.  Code that should be inserted into this section would be the initializing of objects and sensors.  It is also helpful to output some basic status indicators to the Serial.println for troubleshooting.

customLoop

Loop is called approximately every second as the ptFlex reads in the current data from the GPS receiver.  If you need to "constantly" read the values from your sensor and either log the data or make decisions on the data, then this would be that spot.  The return value of the customLoop function will (if true) cause a position packet to be transmitted immediately following this call.  This would be useful if you wanted to transmit a piece of information when a sensor reads a particular value.

Be cautious with returning true from this function, as doing so will bypass any other normal transmit cycles.  So for example, if you intend to be timeslotted on a particular second past the minute, and you return true, a packet will be sent potentially outside of your normal timeslot.  Also, bad logic inside of this block could cause continuous transmitting of packets. 

customSendPositionSingleLine

This function is called every time the controller decides to send a packet.  Normally this is triggered by the four options (time delay, altitude-based, speed-based, or time-slot), or could be triggered by the customLoop function above.  Regardless of the source, this is the section where you would gather the sensor data, and format it inside of the packet.  Be very careful about how the data is transmitted, and the general rule of thumb is to only use normal alpha-numeric characters.  Using special symbols or ASCII vaues in excess of 127 can cause fatal errors for the packet parsers in your tracking software. 

Below is a standard routine for capturing the Outside Air Temp from a TMP102 sensor, and encoding its value into the output sent to the TNC.  

char statusOAT = 0;
double outsideTemp; //outside air temp
statusOAT = OAT.getTemperature(outsideTemp);
if (statusOAT != 0) {
oTNC.xmitString((char *)" OAT=");
oTNC.xmitFloat((float)outsideTemp);
}

The oTNC.xmitString formats the heading for the value, and the oTNC.xmitFloat sends the actual floating point value. 

customExercise

There is a debug function built into the ptFlex firmware which, via the Serial configuration cable, will allow you to exercise the code within the flight controller.  This customExercise hook is a place that you can insert debugging code for your sensor and test out its behavior, without having to wait for and decide the APRS packets.  Any output from this section is normally directed at the Serial object. 

Issues to Consider

Making modification to the flight controller firmware can have serious and catastrophic repercussions.  These repercussions include causing the controller not to transmit positions, corrupting the format of positions that are transmitted, transmitting constantly (thereby dominating the frequency spectrum and possibly draining the battery prematurely), and other erratic behavior.  Some of the more important issues to consider are included here.

Memory

The memory is very limited in the ATmega328p microcontroller.  There is only 2kB of RAM available, and the base firmware consumers over 1.5kB of that RAM at any given time.  Loading more than about one external sensor's libraries at a time may not be possible without drastic alterations elsewhere in the firmware (i.e. removing other unused features).  The Flash ROM storage for code is also limited, with only about 20% of the available 32kB being available to additional libraries.

Time

The timing of some of the functions inside of the ptFlex can be time sensitive.  For example when transmitting within a timeslot, an reading/processing that needs to happen inside of the custom code should be within one second, max.

Power

There is limited current available to external sensors from the 3.3V regulator.  If your sensor is consuming more than about 10mA, consider powering it from a separate source.

RFI

RFI and EMI interference can be a major problem inside of a balloon flight controller.  These types of interference can insert themselves into the transmitted RF carrier, and can also interfere with the GPS receiver and it's ability to maintain a valid position lock.  Always be sure to test any modifications to the basic ptFlex flight controller before any missions are flown.  

Testing

Any changes to the firmware, no matter how seemingly small they are, can create major problems inside of the system as a whole.  Always, always, always test your changes thoroughly before flying.  For any modification/sensor that has not been flight-tested, seriously consider pairing it with a second APRS tracker that is unaffected by the change (i.e. has the stock firmware installed).  That way, if any unintended consequences occur, you have a much better chance at still being able to track and recover the balloon through an alternate tracker.