Ground stations for the Featherweight GPS Tracker system are now shipping with a new feature.
Up until now, the USB port on the ground station could only been used for battery charging. The new version of the ground station makes the USB port available as a serial port text interface that can work with pretty much any desktop or laptop computer, whether Windows or Mac or Linux.
This feature is completely optional; the Bluetooth connection to an iPhone or iPad are unaffected, and for the vast majority of users, the iFIP phone app will continue to be the only way they use the system. Also, we're not currently planning to provide any special software that uses this feature; all of our focus is on improving the functionality available through the phone app.
But if you're o.k. with writing your own software or using a terminal program like RealTerm or Putty, you can watch live data like what's shown below, save it to a file to sort, filter and plot in Excel or Matlab, or go wild and write your own application to do whatever you want with the data. If you're not, that's fine, just ignore this thread, 'cause it's going to get geeky.
Here's what it looks like using RealTerm:
If you look closely at the screen shot above, you can see there is a mix of readable text and garbage-looking binary output. The garbage binary output is an unavoidable side effect of the fact that the data lines going to the USB port are shared with the data lines connecting the two microcontrollers on the board. The main microcontroller sends out binary packets that go to the Bluetooth microcontroller and then on to the phone, and also sends out the ASCII text packets that you see here. The ASCII packets all start with an "@" character, and then have the packet type, packet length, and a date/timestamp. There are 14 different packet types that are documented in the command/data dictionary that you can download on the Featherweight GPS product page, a snapshot of which is attached below.
Taking a closer look at the middle lines of the above screenshot may give some idea for the possibilities:
First, a little background on the Featherweight GPS system "lost rocket" feature for those who aren't familiar: Every Featherweight Tracker transmits once per second to its paired ground station during flight, on its own dedicated channel. In between those transmissions, it's listening on a special lost-and-found channel to hear if there are any rockets in the area that are out of communication because they have landed and don't have a line of sight to their own ground station. If it does receive that lost rocket data, it sends the now-found rocket data down to its ground station. The ground station is communicating with other local ground stations on a special GS coordination channel when it's not talking with its paired tracker. A ground station that receives lost rocket data sends it along to the other ground stations at the launch. This way, if you fly your rocket and it lands behind a hill outside of LoRa radio range, if a friend flies her rocket, it will hear your rocket and automagically send your rocket's data back to you. The lines above show what this looks like from the perspective of a ground station that just received the lost rocket packet.
The first line is the RX_FOUND packet that ground station puts out when it hears that its tracker received a packet from a lost rocket. Here's how to decode it (taken from the command and data dictionary:
The Ground station received a packet from its tracker called "secondTrk", which is passing along data from the "lostexample" rocket. The packet counters and received signal strength (in dBm) of the lost rocket to the tracker, the tracker to the ground station, and the GS acknowledgment to the tracker are all shown.
The next line is yet more information about the link from the lost rocket to the tracker that is relaying the data, the "relay" below:
This line describes the signal strength and geometry between the relay tracker and the lost rocket, based on the GPS data from the two units, along with the battery voltage of the tracker and the lost rocket. The relay temperature is currently an unsupported feature.
The next 3 lines give the GPS information from the found rocket, the tracker relay, and the ground station. Below is the example for the tracker
Here the table is mostly self-explanatory. The detailed satellite info (satellite az, el, and strength) is known onboard the tracker but is not passed along to the ground station to reduce airtime. The ground station GPS data is all zeros because it, like the rest of the new ground stations, rely on the phone for its GPS location data, and do not have their own GPS module installed.
Up until now, the USB port on the ground station could only been used for battery charging. The new version of the ground station makes the USB port available as a serial port text interface that can work with pretty much any desktop or laptop computer, whether Windows or Mac or Linux.
This feature is completely optional; the Bluetooth connection to an iPhone or iPad are unaffected, and for the vast majority of users, the iFIP phone app will continue to be the only way they use the system. Also, we're not currently planning to provide any special software that uses this feature; all of our focus is on improving the functionality available through the phone app.
But if you're o.k. with writing your own software or using a terminal program like RealTerm or Putty, you can watch live data like what's shown below, save it to a file to sort, filter and plot in Excel or Matlab, or go wild and write your own application to do whatever you want with the data. If you're not, that's fine, just ignore this thread, 'cause it's going to get geeky.
Here's what it looks like using RealTerm:
If you look closely at the screen shot above, you can see there is a mix of readable text and garbage-looking binary output. The garbage binary output is an unavoidable side effect of the fact that the data lines going to the USB port are shared with the data lines connecting the two microcontrollers on the board. The main microcontroller sends out binary packets that go to the Bluetooth microcontroller and then on to the phone, and also sends out the ASCII text packets that you see here. The ASCII packets all start with an "@" character, and then have the packet type, packet length, and a date/timestamp. There are 14 different packet types that are documented in the command/data dictionary that you can download on the Featherweight GPS product page, a snapshot of which is attached below.
Taking a closer look at the middle lines of the above screenshot may give some idea for the possibilities:
First, a little background on the Featherweight GPS system "lost rocket" feature for those who aren't familiar: Every Featherweight Tracker transmits once per second to its paired ground station during flight, on its own dedicated channel. In between those transmissions, it's listening on a special lost-and-found channel to hear if there are any rockets in the area that are out of communication because they have landed and don't have a line of sight to their own ground station. If it does receive that lost rocket data, it sends the now-found rocket data down to its ground station. The ground station is communicating with other local ground stations on a special GS coordination channel when it's not talking with its paired tracker. A ground station that receives lost rocket data sends it along to the other ground stations at the launch. This way, if you fly your rocket and it lands behind a hill outside of LoRa radio range, if a friend flies her rocket, it will hear your rocket and automagically send your rocket's data back to you. The lines above show what this looks like from the perspective of a ground station that just received the lost rocket packet.
The first line is the RX_FOUND packet that ground station puts out when it hears that its tracker received a packet from a lost rocket. Here's how to decode it (taken from the command and data dictionary:
| Sync Char | Parse type | Packet Length | Year | Month | Date | Time | CRC Check | LoRa ID of sender | GS Received counter | Relay Sent counter | Signal Strength | Ack counter | Ack Sent Counter | Ack RSSI | Found LoRa ID | EDM Received by relay Counter | EDM Sent Counter | Found RSSI | Spreading Factor | ||||||||||||||
| @ | RX_FOUND | 204 | 2020 | 11 | 15 | 16:49:43.0 | CRC_OK | secondTrk | PkRx | 47467 | PkSnt | 49461 | p_RSSI | -88 | AckRx | 48551 | AckSnt | 49442 | a_RSSI | -95 | lostexample | FndRx | 148 | FndSnt | 0 | f_RSSI | -28 | SF | 10 | f | 911000000 | CRC: | 94C5 |
The Ground station received a packet from its tracker called "secondTrk", which is passing along data from the "lostexample" rocket. The packet counters and received signal strength (in dBm) of the lost rocket to the tracker, the tracker to the ground station, and the GS acknowledgment to the tracker are all shown.
The next line is yet more information about the link from the lost rocket to the tracker that is relaying the data, the "relay" below:
| Sync Char | Parse type | Packet Length | Year | Month | Date | Time | CRC Check | LoRa ID of sender | Relay Signal Strength | Relay delta Altitude | Relay horiz distance | Found battery voltage | Relay battey voltage | Relay Temperature | ||||||||||
| @ | RLY_DIST | 156 | 2020 | 11 | 15 | 16:49:43.0 | CRC_OK | Relay: | lostexample | RSSI | -28 | Relay_dAlt | 34 | Relay_Dist: | 4 | m | Fnd_mv: | 3763 | Rly_mV: | 3520 | 0 | degC | CRC: | EA10 |
This line describes the signal strength and geometry between the relay tracker and the lost rocket, based on the GPS data from the two units, along with the battery voltage of the tracker and the lost rocket. The relay temperature is currently an unsupported feature.
The next 3 lines give the GPS information from the found rocket, the tracker relay, and the ground station. Below is the example for the tracker
| Sync Char | Parse type | Packet Length | Year | Month | Date | Time | CRC Check | GPS Unit Type | LoRa ID | Altitude ASL | Latitude | Longitude | Horiz. Velocity | Horizonal Heading | Upward Velocity | Satellite Fix Type | Total Sats | Sats >24 dB Strength | Sats >32dB Strength | Sats >40dB Strength | 1st Sat Info | 2nd Sat Info | 3rd Sat Info | 4th Sat Info | 5th Sat Info | ||||||||
| @ | GPS_STAT | 203 | 2020 | 11 | 15 | 16:49:43.094 | CRC_OK | TRK | secondTrk | Alt | 5676 | lt | 39.55612 | ln | -105.10319 | Vel | 0 | -1 | 0 | Fix | 3 | # | 14 | 12 | 6 | 2 | 000_00_00 | 000_00_00 | 000_00_00 | 000_00_00 | 000_00_00 | CRC: | 95DF |
| Bytes | Feet | Decimal Degrees | Decimal Degrees | feet/sec | degrees | feet/second | Count | Count | Count | Count | hex |
Here the table is mostly self-explanatory. The detailed satellite info (satellite az, el, and strength) is known onboard the tracker but is not passed along to the ground station to reduce airtime. The ground station GPS data is all zeros because it, like the rest of the new ground stations, rely on the phone for its GPS location data, and do not have their own GPS module installed.
