Featherweight GPS tracker

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
My strongest motivation is to get rid of needing iOS. I think there is an untapped market of Android users who would be interested in Featherweight without the iOS requirement.

I have heard some talk of Adrian putting the iOS app in the App Store or making an Android app. Given that I clearly see the product of the Featherweather GPS tracker has been around for five years, I am not holding my breathe.

OK, you are new here, so my advice is to read some previous threads. In summary, those of us who bitched for years either moved on to other products or sucked it up and bought an iOS device. We continue to tolerate a risky beta software that expires.

Adrian finally came clean on all this in a recent post. For the current FW GPS, there will be no Android software, and the iOS software will remain in TestFlight. I think this is due to the developer's availability and skill level. The Blue Raven integration is going in a different direction, with both platforms supported. However, I am disappointed to see the Blue Raven being sold at full retail price with beta software once again.
 
Already done via blueraven software.

As a dedicated Android user, I think there is a lot of grasping at straws in the thread. Last thing, even on my level 2 flight, was iOS and the app crashing. Of course, as things go, didn't need it on that flight.

The device does not require cell service. I use an older iphone without any type of cell service.

And frankly, 1000' in altitude? You really don't need a tracker. Sure adds a level of comfort but with a 4" rocket like that shouldn't have an issue. Have never put one in my micro magg even when running Hs on it.

But as far as mounting... Cut the base off the nose cone, it's plenty sturdy, and shove a centering ring in above the shoulder. Then you have options to create a plywood sled that you bolt into centering ring. Did that on my level one, and bunch of other rockets including the above micro magg and works just fine.

P.s. think you'll find that there are quite a few people here that do software of all sorts here both "professionally" and "unprofessionally". But good luck, especially with golang on Android.
I just solved why this works for everyone else and not for me mystery. It is actually very simple.

I am using a iPad 9th gen, wifi only. Googling tells me this iPad has NO gps chip. It ONLY gets a map reading via WIFI. The iOS seems to draw the arrow based on the reading from the iOS device. So when the reading is ALWAYS within a large margin and it is never going to work well. Also out in the middle of nowhere it is going to be even worse when there is no wifi signal. I was watching it tracking me by both mapping the lat/long from the app for me, and in Google Maps via location. Both said I was east of my actual location consistently, even after being outside for a while.

I need to return the iPad, and either get a iPad with a cellular chip in it or an iPhone. Yet this gives me even more motivation to write some Android software.

The just go to the tracker's lat/long method works, because it actually has a gps chip in it.
 
Last edited:
I just solved why this works for everyone else and not for me mystery. It is actually very simple.

I am using a iPad 9th gen, wifi only. Googling tells me this iPad has NO gps chip. It ONLY gets a map reading via WIFI. The iOS seems to draw the arrow based on the reading from the iOS device. So when the reading is ALWAYS within a large margin and it is never going to work well. Also out in the middle of nowhere it is going to be even worse when there is no wifi signal. I was watching it tracking me by both mapping the lat/long from the app for me, and in Google Maps via location. Both said I was east of my actual location consistently, even after being outside for a while.

I need to return the iPad, and either get a iPad with a cellular chip in it or an iPhone. Yet this gives me even more motivation to write some Android software.
Yikes! That is really unfortunate about the iPad, I'm glad you figured it out. But is is a good cautionary tale for the rest of us. The original system used two identical trackers that each had a GPS chip, and used the chip in the base station (which was just a tracker set to base station mode). I forget that the new system does not have a GPS chip in the base station, which requires the iOS device to have a chip. I suspect we all just assumed you bought an iPad with a cellular chip, which also includes the GPS module.

I hope you find the system satisfactory once you get the new device. If you don't get the new device in time, anyone else with the software installed on an iPhone can easily pair with your tracker and follow it for you, and then give you the final coordinates.

And good luck with your L1 cert.


Tony
 
I just solved why this works for everyone else and not for me mystery. It is actually very simple.

I am using a iPad 9th gen, wifi only. Googling tells me this iPad has NO gps chip. It ONLY gets a map reading via WIFI. The iOS seems to draw the arrow based on the reading from the iOS device. So when the reading is ALWAYS within a large margin and it is never going to work well. Also out in the middle of nowhere it is going to be even worse when there is no wifi signal. I was watching it tracking me by both mapping the lat/long from the app for me, and in Google Maps via location. Both said I was east of my actual location consistently, even after being outside for a while.

I need to return the iPad, and either get a iPad with a cellular chip in it or an iPhone. Yet this gives me even more motivation to write some Android software.

The just go to the tracker's lat/long method works, because it actually has a gps chip in it.
That would explain it.

Android uses a combination of signals to do location, but if you remove GPS from it too you get less precision, etc. If you remove Wifi and/or cell signal, there isn't a lot that it can go on... would be similar for iOS devices too.
 
That would explain it.

Android uses a combination of signals to do location, but if you remove GPS from it too you get less precision, etc. If you remove Wifi and/or cell signal, there isn't a lot that it can go on... would be similar for iOS devices too.
I have also retested it with an iPhone. I can confirm it works better, but still suffers a little from margin of error problems. It is always going to be worse in ideal conditions to use two GPS readings from two different GPS chips to find each other than it is going to be to just map the lat/long of the tracker. The ideal conditions are when you have a map with frames of reference. You could argue will it really be better, but with frames of reference you can get an even more accurate idea of where you are and where the tracker is than the second GPS reading from your iOS device is going to give you. On the other hand the delta between the two, most of the time, is going to be ignorable. Examples of frames of reference are roads and sidewalks in urban areas. With urban satellite images you could use buildings too. Where as in rural areas, where launch sites generally are, it would be more satellite images that will show you trees, bushes, etc.

Another point is a mindset question. The watching the arrow method is going to get you to fixate on the arrow. Where as if you are using a map and frames of reference you will now when you have arrived. The app really should give you a signal, hey you are with the known margin of error or even just say 10 feet, stop, look around, you have arrived. This is how the end of Google Maps navigation works. I say this, because even with the iPhone it was spinning me in circles even though it kept saying it was 5-10 feet away. It would be a user experience enhancement.
 
Last edited:
Another point is a mindset question. The watching the arrow method is going to get you to fixate on the arrow. Where as if you are using a map and frames of reference you will now when you have arrived. The app really should give you a signal, hey you are with the known margin of error or even just say 10 feet, stop, look around, you have arrived. This is how the end of Google Maps navigation works. I say this, because even with the iPhone it was spinning me in circles even though it kept saying it was 5-10 feet away. It would a user experience enhancement.

Have you used a GPS before, like a Garmin handheld? Yes, spinning in circles 5-10 ft from the target is exactly what +/- 3m precision means! All GPS do this. Geez.

You clearly don't want to use the Featherweight GPS in the way that it was designed to work. Perhaps put it up for sale in the Yardsale forum (somebody will snatch it up within minutes) and buy another unit that does what you want. There are other devices/software that use maps, Android, and ring a bell when you are close to the target. Here are some options:

Hardware: Missileworks, Eggfinder
Android Apps: Rocket Locator, Rocket Track, Blue GPS, GPS Connector, GPS Essentials
Windows Software: ucenter, VisualGPS, Mapshere
 
Last edited:
I have also retested it with an iPhone. I can confirm it works better, but still suffers a little from margin of error problems. It is always going to be worse in ideal conditions to use two GPS readings from two different GPS chips to find each other than it is going to be to just map the lat/long of the tracker. The ideal conditions are when you have a map with frames of reference. You could argue will it really be better, but with frames of reference you can get an even more accurate idea of where you are and where the tracker is than the second GPS reading from your iOS device is going to give you. On the other hand the delta between the two, most of the time, is going to be ignorable. Examples of frames of reference are roads and sidewalks in urban areas. With urban satellite images you could use buildings too. Where as in rural areas, where launch sites generally are, it would be more satellite images that will show you trees, bushes, etc.

Another point is a mindset question. The watching the arrow method is going to get you to fixate on the arrow. Where as if you are using a map and frames of reference you will now when you have arrived. The app really should give you a signal, hey you are with the known margin of error or even just say 10 feet, stop, look around, you have arrived. This is how the end of Google Maps navigation works. I say this, because even with the iPhone it was spinning me in circles even though it kept saying it was 5-10 feet away. It would be a user experience enhancement.
I hate to say it, but if you are within 10 feet of your rocket and still walking in circles, you might have other issues! Keep in mind you're not trying to find a small object hidden away, but a rocket that (hopefully) will have a parachute, shockcord, and a fin can that should be easy to see from more than 10' away. I think since you are testing it without a rocket, you are too focused on the typical GPS margin of error.

Below are two photos from a flight at Airfest in 2019. It's a 38mm MD rocket that went to about 15,000'. The first image is the field it landed in, the second is what I found by following the Featherweight tracker software. I would argue if the tracker and software resolution is good enough to recover in those conditions, it will work for the vast majority of flights. I will say though that I often plot the landing location on a map to look for access roads, streams I may have to cross, etc., but once I get close I always end up using the tracking software.


Tony

first look: (not a lot of frames of reference to use!)
tracker-1.jpg

following the green arrow:
tracker-2.jpg
 
Last edited:
I just came back from a fantastic honeymoon and I see I have a little catching up to do.

IMG-1283.jpg
View attachment IMG-1284.jpg
@Adrian A Are you willing to share some technical data on how I might go about this via bluetooth? My plan is to open source my application by posting it to GitHub. I am also not looking to make any money off it. I would think it would be in your own self interest. Any form of Android app would be free work, and likely increase sales.

I'm thinking about publishing information on the Bluetooth characteristics for those who would want to roll their own. I haven't decided yet but I'm leaning that way (at a low priority)

I'll summarize the historical context for people who are relatively new to this product (Welcome!), and give some development status updates:

Kevin Small and I have collaborated on Featherweight hardware and software since around 2011, when we were both doing it as a hobby and a side gig. My day job was working on NASA programs in big aerospace and startup aerospace companies. I made the Parrot and then the Raven altimeters, and Kevin wrote a windows interface and graphing app for those altimeters in C#, for royalties. In 2017 I made the Featherweight GPS system, pretty much in its current form, and Kevin took some time off from work to make the first iFIP GPS app, writing it natively for iOS. I added more capabilities into the firmware, partly in a collaboration with my day job working on NASA's LOFTID program. Around that time, Kevin got promoted and needed to focus more on his day job. Android development got put on hold, releasing the app got put on hold, and there were a number of bug fixes, improvements, and other work that were left undone. In the meantime, COVID happened, I had a lot of big personal changes, I moved back to Colorado permanently into a house where I could build rockets again. Then the nature of my day job changed, and I decided to quit my day job to develop the Blue Raven and Featherweight Altimeters full-time. To do this, I needed to develop a phone app with a dedicated app developer who I could direct to put in all the features I wanted. Kevin did a great job on the iFIP, and together IMO we raised the bar for rocketry tracking. But I needed more time and energy than he could give, so I found a new developer for the Blue Raven.

The Blue Raven uses a microcontroller that does all of the flight control plus the Bluetooth interface, and I taught myself what I needed to know to get the Bluetooth working on top of the next-generation flight control and data recording functions. The developer I have contracted with created the Blue Raven phone app, using Flutter to handle the iOS and Android development concurrently. What we are working on right now, besides releasing the Blue Raven app through the stores and making some other improvements, is adding the GPS tracker interface to the new Featherweight phone app that currently just has the Blue Raven. My near-term goal is to do that without disturbing the firmware on the trackers and the ground station. This way I can provide a good Android interface sooner without needing to wait for me to learn how to work with the Cypress (now NXP) Bluetooth module that Kevin wrote the firmware for, and without my developer needing to support over-the-air updates in the phone app for that module.

The GPS tracker/GS firmware still has untapped potential features that I'm planning to take advantage of with the phone new app, including a way to de-conflict channel selection with other users at the launch, and features related to monitoring other people's flights. Further down the road (probably next year) I'll update the tracker hardware design to use the same microcontroller I'm using for the Blue Raven.
 
Last edited:
I just came back from a fantastic honeymoon and I see I have a little catching up to do.

View attachment 592219
View attachment 592222
Congratulations on getting married.

I'm thinking about publishing information on the Bluetooth characteristics for those who would want to roll their own. I haven't decided yet but I'm leaning that way (at a low priority)
I have already gotten most of the way there on the Bluetooth characteristics. I know there are two Bluetooth interfaces, one for the ground station and one for the tracker. I found the ground station one first. I then found the characteristics and comparing the data to USB data I was able to debug an incrementing packet number, and realized I was definitely looking at the ground station data. Next I found the tracker Bluetooth interface, and it's characteristics. I can tell I am in theory looking at the right packet, because I can see the number of satellites in the hex data.

Satellites in bold:
@ GPS_STAT 203 0000 00 00 00:21:01.034 CRC_OK TRK FthrWt04025 Alt 001304 lt +33.34901 ln -111.75781 Vel +0000 -120 +0002 Fix 3 # 4 3 0 0 000_00_00 000_00_00 000_00_00 000_00_00 000_00_00 CRC: 52DE

20 fe a1 00 0a 00 46 74 68 72 57 74 30 34 30 32 .....FthrWt0402
35 00 a9 e0 13 72 1c 63 bd a2 f6 05 00 03 00 00 5....r.c........
60 ff 02 00 01 04 00 00 03 1d 00 00 11 00 00 00 `...............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 bd 00 4c 00 35 00 2f 00 00 .........L.5./..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 2a 48 44 25 00 00 00 00 00 00 00 00 00 ...*HD%.........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 df 0f 97 cb c4 ef 17

I did find plenty of other characteristics, but nothing useful. I do know I can write commands at these characteristics, but again haven't gotten anything useful from that. I did manage to get some very interesting behavior from the ground station by writing a certain command, but still wasn't useful.

Characteristics:
00060001-f8ce-11e4-abf4-0002a5d5c51b
c8875008-57d2-4b60-9adc-3e080635bdda

Overall I am just trying to pull the lat/long. My best guess from the hex data above is that the data I am looking for is bolded below. I just don't know how to decode it.

20 fe a1 00 0a 00 46 74 68 72 57 74 30 34 30 32 .....FthrWt0402
35 00 a9 e0 13 72 1c 63 bd a2 f6 05 00 03 00 00 5....r.c........
60 ff 02 00 01 04 00 00 03 1d 00 00 11 00 00 00 `...............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 bd 00 4c 00 35 00 2f 00 00 .........L.5./..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 2a 48 44 25 00 00 00 00 00 00 00 00 00 ...*HD%.........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 df 0f 97 cb c4 ef 17

I also suspect there is some piece of the ground station interface I don't understand. Where if I send it the right write commands it will start outputting the same tracker packet I see on the tracker interface. I say this, because the tracker interface only works when the tracker is around my computer. Which makes me think it is coming directly from the tracker itself. I know from all my research that the same data has to come out of the ground station interface.

Can you tell me which bytes in the packet are the lat/long and how to decode them? Then you don't have to write full documentation until you decide to get around to it.
I'll summarize the historical context for people who are relatively new to this product (Welcome!), and give some development status updates:
Kevin Small and I have collaborated on Featherweight hardware and software since around 2011, when we were both doing it as a hobby and a side gig. My day job was working on NASA programs in big aerospace and startup aerospace companies. I made the Parrot and then the Raven altimeters, and Kevin wrote a windows interface and graphing app for those altimeters in C#, for royalties. In 2017 I made the Featherweight GPS system, pretty much in its current form, and Kevin took some time off from work to make the first iFIP GPS app, writing it natively for iOS. I added more capabilities into the firmware, partly in a collaboration with my day job working on NASA's LOFTID program. Around that time, Kevin got promoted and needed to focus more on his day job. Android development got put on hold, releasing the app got put on hold, and there were a number of bug fixes, improvements, and other work that were left undone. In the meantime, COVID happened, I had a lot of big personal changes, I moved back to Colorado permanently into a house where I could build rockets again. Then the nature of my day job changed, and I decided to quit my day job to develop the Blue Raven and Featherweight Altimeters full-time. To do this, I needed to develop a phone app with a dedicated app developer who I could direct to put in all the features I wanted. Kevin did a great job on the iFIP, and together IMO we raised the bar for rocketry tracking. But I needed more time and energy than he could give, so I found a new developer for the Blue Raven.

The Blue Raven uses a microcontroller that does all of the flight control plus the Bluetooth interface, and I taught myself what I needed to know to get the Bluetooth working on top of the next-generation flight control and data recording functions. The developer I have contracted with created the Blue Raven phone app, using Flutter to handle the iOS and Android development concurrently. What we are working on right now, besides releasing the Blue Raven app through the stores and making some other improvements, is adding the GPS tracker interface to the new Featherweight phone app that currently just has the Blue Raven. My near-term goal is to do that without disturbing the firmware on the trackers and the ground station. This way I can provide a good Android interface sooner without needing to wait for me to learn how to work with the Cypress (now NXP) Bluetooth module that Kevin wrote the firmware for, and without my developer needing to support over-the-air updates in the phone app for that module.

The GPS tracker/GS firmware still has untapped potential features that I'm planning to take advantage of with the phone new app, including a way to de-conflict channel selection with other users at the launch, and features related to monitoring other people's flights. Further down the road (probably next year) I'll update the tracker hardware design to use the same microcontroller I'm using for the Blue Raven.
The history and future plans are very interesting. Thanks for sharing them.
 
Last edited:
I just got my wire whip antenna Featherweight GPS. I want to remove the battery terminal block, and solder some wires with a battery connector directly to the board to save space. I also want to bypass the onboard switch, just out of paranoia that it might get jostled in a slightly janky avbay.

From what I understand, I think I can just remove the terminal block, and then solder the positive wire to the hole labeled switch+, and solder the negative to the existing negative hole that the terminal block is currently soldered to. I'd just like a confirmation about this before I start modifying my expensive tracker.
 
I just got my wire whip antenna Featherweight GPS. I want to remove the battery terminal block, and solder some wires with a battery connector directly to the board to save space. I also want to bypass the onboard switch, just out of paranoia that it might get jostled in a slightly janky avbay.

From what I understand, I think I can just remove the terminal block, and then solder the positive wire to the hole labeled switch+, and solder the negative to the existing negative hole that the terminal block is currently soldered to. I'd just like a confirmation about this before I start modifying my expensive tracker.
Correct.. if you desolder the connector block and reference the positive and negative sides then solder your connectors to it specifically it will be for battery connection. There are 2 holes for additional switch wires you can connect to the board for external switch.
 
I finally got to use my FT last weekend. Was able to walk straight up to the rocket. I had landed about 1.25km downrange. Really happy with the unit (except the Apple experience 🙂).
And im sure that apple experience has left you scared for life 🤣 🤣 🤣


Ive used it for a few years (android user myself and only have the Iphone for tracking) and havent had any third arms grow, or any scaring or mental issues occur.
 
I just got my wire whip antenna Featherweight GPS. I want to remove the battery terminal block, and solder some wires with a battery connector directly to the board to save space. I also want to bypass the onboard switch, just out of paranoia that it might get jostled in a slightly janky avbay.

From what I understand, I think I can just remove the terminal block, and then solder the positive wire to the hole labeled switch+, and solder the negative to the existing negative hole that the terminal block is currently soldered to. I'd just like a confirmation about this before I start modifying my expensive tracker.
That’s all correct.
 
@Nathan Grennan how was your Level-1 cert flight and tracking experience?
The initial launch was great, but the parachute didn't pop. It probably went to about 2000 feet. I misspoke when I said 1100 before. It went ballistic and landed 0.3 miles away in a field. The rocket and all electronics were left in pieces. I know what I did wrong, and it is easily corrected. I already ordered another kit to build.

As for the tracking system, it worked well. It was a short distance. It only went off the last known lat/long, since the tracker board died when it hit the ground. The spot was relatively open, and I saw it from probably 50 feet away.
 
I am so sorry to hear that, Nathan !

The reason I asked how much your LOC-IV weighed in Post #164 is because when I sim'd a 1-Kg LOC-IV in OpenRocket, it hit 2200 - 2300 ft.

I had to add another Kg of mass ( about 2-Kg Dry mass ) to only go 1100 ft on an H100-W and a G80 didn't do much at all in a 2-Kg LOC-IV.

I've core-sampled more than my fair share.

Get back on that horse and ride again ASAP !

-- kjh
 
Using Testflight is a PITA. I have a launch next weekend and because the app times out after three months I have to update it each time. If I forget to update it that tracker is dead in the water.

Yep, this recently happened to me. At the launch site, I powered on the cheap iPhone7 with no cellular service that I use only for the FW GPS (like everybody recommends) only to find the iFIP expired. No wifi service at the field to update the software, either. I briefly thought about making a hotspot with my Android daily driver phone, then said screw it. I put my Missileworks T3 in the rocket instead and missed out the data I was hoping collect.
 
Yep, this recently happened to me. At the launch site, I powered on the cheap iPhone7 with no cellular service that I use only for the FW GPS (like everybody recommends) only to find the iFIP expired. No wifi service at the field to update the software, either. I briefly thought about making a hotspot with my Android daily driver phone, then said screw it. I put my Missileworks T3 in the rocket instead and missed out the data I was hoping collect.
Like remembering to charge my batteries, make sure all stuff on my checklist is gone through i add this to things on the check list so it doesnt get forgotten.
 
I flew my new tracker in my rocket on Sunday but I didn’t hear the vice telemetry a’la Kate. Do you have any tips on making sure this feature is active? Thanks!
 
I flew my new tracker in my rocket on Sunday but I didn’t hear the vice telemetry a’la Kate. Do you have any tips on making sure this feature is active? Thanks!
from post 178 in this thread:

"The main two items are making sure audio is not muted and screen sleep is disabled"

It's easy to test by going to Settings in iFip and changing the voice setting. If you don't hear the voice, your device may be muted or the volume is turned down very low. You can also play a song or video to set the volume level.


Tony
 
from post 178 in this thread:

"The main two items are making sure audio is not muted and screen sleep is disabled"

It's easy to test by going to Settings in iFip and changing the voice setting. If you don't hear the voice, your device may be muted or the volume is turned down very low. You can also play a song or video to set the volume level.


Tony
It also used to be you had to be on the tracking screen at launch for it to work as well
 
It also used to be you had to be on the tracking screen at launch for it to work as well
Hmm, I don't know what other screen I'd be on during a flight, but that's a great point. In the post I wrote back in 2021, I did explicitly state that the phone has to be on the tracking screen to get the voice callouts:

https://www.rocketryforum.com/threa...hile-using-ifip-featherweight-tracker.168888/
Here's an excerpt:
  • MAKE SURE YOU ARE ON THE TRACK PAGE - Once a launch is detected, the iFIP software will call out audible updates
    • Note: the displayed GPS data is MSL, but the audio callouts during flight are AGL (basically flight MSL altitude - launch MSL altitude)
  • Commence flight operations
  • Don’t leave the iFIP app while the rocket is in air – you can flip between TRACK and GPS and the voice should pick up once back on TRACK screen. But there is really no reason to leave the TRACK screen once the flight starts and until the rocket lands or communication is lost
I've gotten so used to that it just seems natural to always stay on the tracking page. I reviewed the steps I posted and it looks like they are still current. I used pretty much the exact same procedure at BALLS last month and I don't recall any differences, but I suppose with the new iOS some interface elements may have moved around.


Tony
 
Hmm, I don't know what other screen I'd be on during a flight, but that's a great point. In the post I wrote back in 2021, I did explicitly state that the phone has to be on the tracking screen to get the voice callouts:

https://www.rocketryforum.com/threa...hile-using-ifip-featherweight-tracker.168888/
Here's an excerpt:
  • MAKE SURE YOU ARE ON THE TRACK PAGE - Once a launch is detected, the iFIP software will call out audible updates
    • Note: the displayed GPS data is MSL, but the audio callouts during flight are AGL (basically flight MSL altitude - launch MSL altitude)
  • Commence flight operations
  • Don’t leave the iFIP app while the rocket is in air – you can flip between TRACK and GPS and the voice should pick up once back on TRACK screen. But there is really no reason to leave the TRACK screen once the flight starts and until the rocket lands or communication is lost
I've gotten so used to that it just seems natural to always stay on the tracking page. I reviewed the steps I posted and it looks like they are still current. I used pretty much the exact same procedure at BALLS last month and I don't recall any differences, but I suppose with the new iOS some interface elements may have moved around.


Tony
Yes, I was on the tracking page. However, I will check the volume before launch. Thanks, Tony!

Jack
 

Latest posts

Back
Top