New Featherweight GPS Tracker text interface

The Rocketry Forum

Help Support The Rocketry Forum:

Adrian A

Sponsor
TRF Sponsor
TRF Lifetime Supporter
Joined
Jan 22, 2009
Messages
2,317
Reaction score
289
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:

1605458569312.png


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:

1605460603063.png

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 CharParse typePacket LengthYearMonthDateTimeCRC CheckLoRa ID of senderGS Received counterRelay Sent counterSignal StrengthAck counterAck Sent CounterAck RSSIFound LoRa IDEDM Received by relay CounterEDM Sent CounterFound RSSISpreading Factor
@RX_FOUND2042020111516:49:43.0CRC_OKsecondTrkPkRx47467PkSnt49461p_RSSI-88AckRx48551AckSnt49442a_RSSI-95lostexampleFndRx148FndSnt0f_RSSI-28SF10f911000000CRC: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 CharParse typePacket LengthYearMonthDateTimeCRC CheckLoRa ID of senderRelay Signal StrengthRelay delta AltitudeRelay horiz distanceFound battery voltageRelay battey voltageRelay Temperature
@RLY_DIST1562020111516:49:43.0CRC_OKRelay:lostexampleRSSI-28Relay_dAlt34Relay_Dist:4mFnd_mv:3763Rly_mV:35200degCCRC: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 CharParse typePacket LengthYearMonthDateTimeCRC CheckGPS Unit TypeLoRa IDAltitude ASLLatitudeLongitudeHoriz. VelocityHorizonal HeadingUpward VelocitySatellite Fix TypeTotal SatsSats >24 dB StrengthSats >32dB StrengthSats >40dB Strength1st Sat Info2nd Sat Info3rd Sat Info4th Sat Info5th Sat Info
@GPS_STAT2032020111516:49:43.094CRC_OKTRKsecondTrkAlt5676lt39.55612ln-105.10319Vel0-10Fix3#141262000_00_00000_00_00000_00_00000_00_00000_00_00CRC:95DF
BytesFeetDecimal DegreesDecimal Degreesfeet/secdegreesfeet/secondCountCountCountCounthex

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.
 

Attachments

Adrian A

Sponsor
TRF Sponsor
TRF Lifetime Supporter
Joined
Jan 22, 2009
Messages
2,317
Reaction score
289
Part 2:

Commands are also possible through text. The available commands are:


CommandComment, functionExample w argExample Response
set TrackerIDSets the ID string for the hardwareset TrackerID DRM_SN001<none>
?stateSet the flight state (00: GS default, 01-07 reserved 08: monitor (no acks) 09-10: reserved 11: Monitor only coordination channel)?state 08+state
?saveSaves the flight state used the next time the unit boots?save 01+save
set freqSets the frequencyset freq 915000000RX_TMOUT packet
?DT4Shows the firmware build time and various settings?DT4+DT4 packet


The ?state function can put the ground station into one of three available states: The default state (00) in which the GS will communicate with its tracker normally, a monitor state (08) in which the GS listens to a channel but won't ever transmit acknowledgements, and the coordination monitor state (11), where the GS stays listening to the GS coordination channel full-time. The latter is useful if, for example, you wanted to know what are all the channels current in use at the launch site, and to get data on all the lost rockets as they come in.

For the 3 of you who are still interested after all this, get your new ground station and have fun!
 

BTharpe

Active Member
TRF Supporter
Joined
Dec 5, 2019
Messages
28
Reaction score
9
Location
Dallas
For a computer science based nerd like me, this is fantastic to have access to the raw data!

Bring on the NumPy and MatPlotLab :)
 

Buckeye

Well-Known Member
TRF Supporter
Joined
Sep 6, 2009
Messages
2,712
Reaction score
528
Ground stations for the Featherweight GPS Tracker system are now shipping with a new feature.
Is the live text following any format standard, like NMEA?

If I simply connect the serial port to software like Ublox Ucenter or Visual GPS, will the software immediately recognize data from Featherweight like lat, lon, elevation, sats, etc, and know what to do with them? I suspect not.

Other trackers that send NMEA strings can be connected to the aforementioned software and start processing the incoming data immediately. No text parsing, filtering, or coding needed.

Any reason why NMEA cannot be transmitted? For example, Big Red Bee sends both NMEA and its own proprietary format. Ucenter, by default, just ignores the BRB lines and works with the NMEA lines.
 

Buckeye

Well-Known Member
TRF Supporter
Joined
Sep 6, 2009
Messages
2,712
Reaction score
528
Is the live text following any format standard, like NMEA?

If I simply connect the serial port to software like Ublox Ucenter or Visual GPS, will the software immediately recognize data from Featherweight like lat, lon, elevation, sats, etc, and know what to do with them? I suspect not.

Other trackers that send NMEA strings can be connected to the aforementioned software and start processing the incoming data immediately. No text parsing, filtering, or coding needed.

Any reason why NMEA cannot be transmitted? For example, Big Red Bee sends both NMEA and its own proprietary format. Ucenter, by default, just ignores the BRB lines and works with the NMEA lines.
Bumping my own post. Anybody using the Featherweight GPS ground station text interface?
 

kjs

Well-Known Member
TRF Supporter
Joined
Jan 22, 2013
Messages
285
Reaction score
119
Bumping my own post. Anybody using the Featherweight GPS ground station text interface?
It was originally developed for a college competition to have a 'control center' for tracking multiple rockets and people on the range - as well as updating for 'found rockets' when another rocket goes up and picks up a rocket on the ground that can no longer talk to it's ground station. As such, I don't think NMEA was part of the discussion (although it is a good suggestion)...

There were some binary packets I stripped out of the attached log, but this is what I got from one of the new GS2 units listening to my single tracker (KevinRKT). I don't know if either of the utilities you list could read from stdout of another application, otherwise I could probably write a converter to change it to NMEA style formating.
 

Attachments

AllDigital

Lifetime Supporter
TRF Lifetime Supporter
Joined
Jun 14, 2013
Messages
299
Reaction score
199
Location
SoCal
The lost and found concept is really cool and novel, but requires others at the launch to be flying or looking in the same area. When we fly with our tracker, even with very powerful radios, we often lose signal at the horizon (below 100’ or in the dirt), especially if the rocket is out a few miles. I’ve often considered the idea of flying a tethered balloon up 1000’ with a transceiver and mesh configuration to forward the packets from rockets that have landed far away. This could be useful at large launches or facilities to extend range, but would require everyone to use the same radios/tech. Maybe putting another featherweight up on a tethered balloon would accomplish the same thing.
 

Buckeye

Well-Known Member
TRF Supporter
Joined
Sep 6, 2009
Messages
2,712
Reaction score
528
There were some binary packets I stripped out of the attached log, but this is what I got from one of the new GS2 units listening to my single tracker (KevinRKT). I don't know if either of the utilities you list could read from stdout of another application, otherwise I could probably write a converter to change it to NMEA style formating.
Thanks for the log file, but no joy. The utilities expect to receive NMEA.
 
Top