New tracker range test result

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Quick question Adrian, will you be making a Aussie version of this unit? 900-915MHz is licensed spectrum down here and ACMA are very serious about keeping the band clear as that spectrum is sold to mobile phone providers. We're unlicensed from 915-928Mhz down here fyi.
 
What I'm testing now is tracker-only, with some hooks to share data with a possible future altimeter. The unused pins on the tracker's microcontroller are calling to me, though, (Use me!... Use me!!) and the GPS may turn out to be good enough to make a baro sensor unnecessary, so I'm giving some thought to making a combined unit for the next product.
I didn't see the benefit of a combined unit until I used the TeleMetrum and was able to see flight computer status and particularly ematch continuity back at the flight line.
 
Quick question Adrian, will you be making a Aussie version of this unit? 900-915MHz is licensed spectrum down here and ACMA are very serious about keeping the band clear as that spectrum is sold to mobile phone providers. We're unlicensed from 915-928Mhz down here fyi.

The LoRa part being used indicates that it supports 860-930 MHz so that would appear to support operating in the unlicensed area. We were actually running at 915MHz and 917MHz at BALLS...

I'm not sure if the 'spreading' impacts OverTheTop's comment about "Probably stating the obvious too, but the entire emissions need to be within the band."
 
Quick question Adrian, will you be making a Aussie version of this unit? 900-915MHz is licensed spectrum down here and ACMA are very serious about keeping the band clear as that spectrum is sold to mobile phone providers. We're unlicensed from 915-928Mhz down here fyi.


Yes, the frequency for the dedicated comm to/from your own ground station will be user-selectable over a wide range. I have been planning to have some special-purpose fixed-frequency public channels as well, and I understand that for you guys down under you would need those to be in 915-928 MHz range as well.
 
Yes, the frequency for the dedicated comm to/from your own ground station will be user-selectable over a wide range. I have been planning to have some special-purpose fixed-frequency public channels as well, and I understand that for you guys down under you would need those to be in 915-928 MHz range as well.

Fantastic! Thanks Adrian.
 
Yeah Tony but what Adrian is doing is parallel with what I've observed with combined GPS/Glonass strings. If he comes up with a live mapping app, all the better. If not and he
can only get the GPS/Glonass strings piped off over USB or Bluetooth, might be wise to have a means for the end user to shut off Glonass and use the USA GPS alone. Kurt

We deal with the uBlox binary data from the receiver, which is set to output navigation solutions that incorporate both satellite constellations. The idea of using a live map during the flight is interesting. While the rocket is in the air I think I would personally prefer to see data like vertical velocity and altitude, ground track speed and heading, and save the map usage for after it lands, but maybe other users would prefer to see a live map that just shows the ground track updating real-time. I don't think we have planned to provide that, but if people want that and we can send data to a live mapping app, I would think we could mimic NMEA strings so that the app wouldn't know the data came from a combined GPS/GLONASS solution. In that case, do you see any advantage to turning off the GLONASS information?

Our current plan is that during the flight we will show live flight data as I mentioned above, along with live pointing guidance, and then have a button or two to use after landing that would make it easy to send the last known position and/or estimated landing location to a mapping app like Google Maps so that you can plan your recovery route from there, and then easily switch back and forth between that app and the Featherweight app, which would always point to your rocket. The two mapping apps I use often, Google Maps and Motion-X GPS, both allow you to cache maps before your trip so that you don't need internet access in the field.
 
I'm getting ready to update the design for the final round of prototypes before the first production run, and there are some changes planned based on our experiences in recent flight testing:

1. Openlog is nice for prototyping, but it's not a clean or inexpensive solution for production. It's pretty easy to dislodge the micro-SD card, so we're thinking about more robust logging options. We can get up to around 96 kB of non-volatile data storage just by investing in some more firmware development without adding any logging-specific hardware. 96kB should be enough for some pretty detailed logging of a long flight, and the end product will be smaller, less expensive, and more mechanically robust. That seems like a clear win in value, so we're heading in that direction.

2. Having a really accurate GPS on the tracker has spoiled us in GPS performance, and now the iPhone's GPS accuracy, particularly in altitude, seems rather disappointing. So we're leaning toward putting a GPS module in the ground station as well, so that the iPhone's GPS isn't the limiting factor in AGL altitude accuracy, or any other accuracy for that matter. That could add some cost but also open up an opportunity to make the guts of the ground station hardware identical to those of the tracker. My current thinking is to produce both trackers and ground stations from the same production run, and then just give them different roles in software. That might make up for the cost of the additional GPS module. But the current ground station also includes a battery, battery charger, nice big LEDs, a human-sized toggle switch, and a nice solid aluminum closed case as I have shown in pictures up above. Since the aluminum case is not compatible with a GPS receiving signals in there, it would have to be replaced by a plastic substitute. To give our customers some flexibility on the cost, I'm thinking of providing the case, battery charger, LED, switch etc. as a separate ground station kit that can be added to the core board, but it would be optional for those who would prefer to roll their own power supply for the ground station. Sadly, the following picture that was going to go on the new Featherweight web site would not longer be relevant:

wLns6ub.jpg


I'll admit I still have a soft spot for the metal-cased version of the ground station, so I'm interested to hear if people really want that version despite needing to rely on their phone's GPS.
 
Having a GPS module in the ground unit seems like it would solve a lot of issues and give you a much more robust solution than relying on the users phone or other hardware. Also should make software development easier with a standard hardware config. Put me down for one of the first units.

Great shot of your hardware on the playa. I really missed going to BALLS this year and based on the cost of the rocket I lost at Airfest it would have been cheaper for me to go have gone to BALLS. I am absolutely serious that I am interested in your setup. I've tried and seen others and while all have pros and cons, having iOS software is the clincher for me.


Tony
 
I'll admit I still have a soft spot for the metal-cased version of the ground station, so I'm interested to hear if people really want that version despite needing to rely on their phone's GPS.
I'm fine with using the iPhone's GPS & not having one on the ground station. I'm curious why you need altitude accuracy on the ground station side though. Can't you just have the Tx side remember its starting location & altitude? Or have your iPhone app remember the pad location after it gets some reasonably sized pile of points that get filtered to one location? There should be software ways to solve that problem.

I'm cool with it either way though. It'd definitely be nice on your end to only have one unit to produce. That's definitely a big win on your side of things.

Cool stuff!

p.s. You could totally photoshop the new hardware into that picture.
 
Personally, I'd rather have the GPS in the ground station, I'd be happy to come up with my own power solution and 3D-print my own case (frankly even if it came with a case I'd probably print my own). Seems like it would be a win for Android as well since it wouldn't require the phone/tablet have its own GPS. The same-board-rocket-and-ground approach is used by the MW RTx as well (though the ground unit is available with and without the GPS module, for a reduced-cost option).

Is it possible to operate two ground stations receiving data from the same rocket? I do this with my Eggfinders, I have an EF RX back at my camp logging real-time data on my computer, and then the handheld unit on me to track the flight and navigate to the rocket. I realize this unit will do its own logging, but I'd prefer to have recording on the ground also in case it gets lost or crashes.
 
My vote is for the GPS in the Ground Station. When you are standing 20 feet from your rocket and pointing the phone at it, and the direction arrow is hopping around because the phone GPS isn't very accurate, then is a little confusing... currently it seems odd that you have to walk farther away from the rocket to get the arrow to settle down and point in the right direction... :)
 
We deal with the uBlox binary data from the receiver, which is set to output navigation solutions that incorporate both satellite constellations. The idea of using a live map during the flight is interesting. While the rocket is in the air I think I would personally prefer to see data like vertical velocity and altitude, ground track speed and heading, and save the map usage for after it lands, but maybe other users would prefer to see a live map that just shows the ground track updating real-time. I don't think we have planned to provide that, but if people want that and we can send data to a live mapping app, I would think we could mimic NMEA strings so that the app wouldn't know the data came from a combined GPS/GLONASS solution. In that case, do you see any advantage to turning off the GLONASS information?

Our current plan is that during the flight we will show live flight data as I mentioned above, along with live pointing guidance, and then have a button or two to use after landing that would make it easy to send the last known position and/or estimated landing location to a mapping app like Google Maps so that you can plan your recovery route from there, and then easily switch back and forth between that app and the Featherweight app, which would always point to your rocket. The two mapping apps I use often, Google Maps and Motion-X GPS, both allow you to cache maps before your trip so that you don't need internet access in the field.

Xastir with an NMEA Python script comes close as the rocket icon is displayed with GPS altitude, bearing to, horizontal speed and distance. The Festival voice server can call out distance aurally too.

On the APRS side UI View can actually "record" a flight in real time and play it back. Kurt
 
Unless adding a GPS to the ground station would cause a significant increase in price (25% or more) which it doesn't sound like it would, I would want the GPS in the ground station.
 
Xastir with an NMEA Python script comes close as the rocket icon is displayed with GPS altitude, bearing to, horizontal speed and distance. The Festival voice server can call out distance aurally too.

On the APRS side UI View can actually "record" a flight in real time and play it back. Kurt

For voice, I think I can use either iOS or Android APIs to output verbal information and that could then be either just on the phone speaker or sent via BT to a headset or BT speaker (for the LCO). After both iOS and Android are covered, I might look into whether Java now has support for BT and/or voice (I would certainly guess the latter). I also expect to save the flight data to a file for playback and sharing (playback within the phone itself initially).
 
Thanks Tony.

A small update. I was getting ready to try out some longer-range settings in preparation for tracking rockets to over 100,000 feet at BALLS this weekend, so I started by doing a range test with my current setup. I taped a transmitter to the window at my lab at work, and drove to the furthest accessible spot with a clear line of sight, which is 47690 feet (9 miles) away. I was reading packets with 18.5 dB of signal strength margin, which means that I could have gotten data from 439,000 feet. :surprised: That altitude would be beyond the edge of space with over 100,000 feet to spare. I guess I don't need the change the settings after all. :cheers:

Will your U-Blox GPS do 400,000'+ altitude? We need something like that for Sugar Shot.

Rick
 
Will your U-Blox GPS do 400,000'+ altitude? We need something like that for Sugar Shot.

Rick
I recall reading somewhere that although 160,000 feet is the highest that u-Blox advertises or tests, that they don’t do anything to preclude higher operation so it should work at the altitudes you’re interested in. You might see if you can find the same discussion, but independent test data would probably be hard to come by.
 
I recall reading somewhere that although 160,000 feet is the highest that u-Blox advertises or tests, that they don’t do anything to preclude higher operation so it should work at the altitudes you’re interested in. You might see if you can find the same discussion, but independent test data would probably be hard to come by.

Yup, I've never seen more than 156,000 feet advertised on an MTK GPS chipset in the past so 160k seems to be the guaranteed limit for off-the-self stuff. Am curious about the need for a GPS on the ground station. I do not own an iPhone but
with my experience tracking at ground level, my Android stuff seems to get a better fix if I'm moving. Having really close accuracy on the rocket side is very nice but just about any GPS on the receiving end for ground location can get one
pretty darned close to the rocket.

The iPhone terminal tracking program looks nice and folks who use that device will much appreciate it as there is a dearth of tracking software for that platform. That said, it would be nice if the NMEA/GNSS sentences could be had off the planned receiver
so those who desire to pipe them into another tracking app or another platform (Android or Windows) could do so. There is a work-around for the Android app "GPS Rocket Locator" that seems satisfactory to that end to track using the combined GPS/Glonass
sentences. Works very well in my ground testing. Interoperability is very advantageous to make everyone happy.:smile:

Again, I don't see the need for a local ground station GPS if altitude is the issue. One can simply make a mental note of the MSL indication coming off the rocket tracker while the rocket is sitting on the pad to get the field elevation and then mentally
subtract it from the incoming altitudes from the rocket to get the AGL indication. The most important is the main chute deployment altitude. If the rocket on the pad shows 700 feet and the main is set for 1000', when the tracker is getting close to 1700' that's when to expect the main chute. That's the time to be looking in that direction to "possibly" get a visual for main deployment.

From the video, it seemed the arrow was jumping about quite a bit and it was mentioned it was due to the fact that someone was likely holding the phone and the arrow was responding to hand movement. It certainly looked like
it was pointing to the rocket and one would be able to get an idea of where to be looking for the expected "main event". That's the important thing but of course if the rocket is too far away to be seen, it's best to be concentrating
on getting the last fix before LOS (loss of signal) to give one a starting point of where to start a search from. One strategy if one is "going long" with a bluetooth receiving station, just duct tape the receiver on a pole to
get it up in the air off the ground. That has the potential to increase receiving range or use a patch antenna for 900Mhz.

For really extreme flights where LOS occurs at a farther distance away and higher up, live map plotting gives further insurance to develop a drift line to follow when one gets to the last known position and the rocket has drifted out
of "radio tracker footprint" range. That drift line with the rocket down low gives one a direction to proceed to get within the ground footprint to receive a final position to effect recovery.

It's easy to experiment with this cheaply by putting small tracked rockets out of sight for long periods of time with modest motors. They stay out of sight longer and at much closer ranges.:wink: Kurt
 
Am curious about the need for a GPS on the ground station. I do not own an iPhone but with my experience tracking at ground level, my Android stuff seems to get a better fix if I'm moving. Having really close accuracy on the rocket side is very nice but just about any GPS on the receiving end for ground location can get one pretty darned close to the rocket.

Although the iFIP app was certainly usable already at BALLS with no GPS in the ground station, but the GPS in the GS should make some things ‘exceptional’ … :)

The iPhone terminal tracking program looks nice and folks who use that device will much appreciate it as there is a dearth of tracking software for that platform. That said, it would be nice if the NMEA/GNSS sentences could be had off the planned receiver so those who desire to pipe them into another tracking app or another platform (Android or Windows) could do so. There is a work-around for the Android app "GPS Rocket Locator" that seems satisfactory to that end to track using the combined GPS/Glonass sentences. Works very well in my ground testing. Interoperability is very advantageous to make everyone happy.

Our goal is to get the iFIP done (iPhone) as a rev 1 and then immediately replicate to Android. We have some plans for some things that should be better served without limiting ourselves to NMEA strings including recording, playback, etc and also ‘send last location phone mapping software’ for when you just want to switch to google maps.

Again, I don't see the need for a local ground station GPS if altitude is the issue. One can simply make a mental note of the MSL indication coming off the rocket tracker while the rocket is sitting on the pad to get the field elevation and then mentally subtract it from the incoming altitudes from the rocket to get the AGL indication.

The ground station GPS just makes for a much more accurate location when you are close up. It is confusing when the phone says you are 80’ off from the rocket elevation when you are only 100’ away at the launch pad. Our experience was the iPhone was not as accurate as we would like.

The most important is the main chute deployment altitude. If the rocket on the pad shows 700 feet and the main is set for 1000', when the tracker is getting close to 1700' that's when to expect the main chute. That's the time to be looking in that direction to "possibly" get a visual for main deployment.

The iFIP app already subtracts off the phone ASL to get AGL for the rocket. I may add the ability to enter the expected main deployment altitude to then also possibly give a warning regarding descent rate after that has been crossed. Likely could add warnings for drogue descent rate as well (does it look ballistic).

From the video, it seemed the arrow was jumping about quite a bit and it was mentioned it was due to the fact that someone was likely holding the phone and the arrow was responding to hand movement.

Actually some of the jumpiness was simply not ignoring bad packets - or before GPS lock. You’ll notice the rocket sometimes does warp speed to somewhere millions of feet away - that is a bad packet that we will be filtering out in the future so you wouldn't see it. When those are ignored and with the GPS in the GS, then I expect it will be very 'crisp'... :)

It certainly looked like it was pointing to the rocket and one would be able to get an idea of where to be looking for the expected "main event". That's the important thing but of course if the rocket is too far away to be seen, it's best to be concentrating on getting the last fix before LOS (loss of signal) to give one a starting point of where to start a search from. One strategy if one is "going long" with a bluetooth receiving station, just duct tape the receiver on a pole to get it up in the air off the ground. That has the potential to increase receiving range or use a patch antenna for 900Mhz.

For the 137K ft flight at BALLS, one of us had a Yagi for 900MHz and the other had just the stub antenna. Both were working to the 137K ft (with bad/missed packets but certainly well enough to track the rocket very well).

For really extreme flights where LOS occurs at a farther distance away and higher up, live map plotting gives further insurance to develop a drift line to follow when one gets to the last known position and the rocket has drifted out of "radio tracker footprint" range. That drift line with the rocket down low gives one a direction to proceed to get within the ground footprint to receive a final position to effect recovery.

I think we should be able to combine last location/bearing/speed information with a ‘projected landing’ point (or impact point). For ‘live mapping’, I would look into whether the data can be fed to the phone mapping software so as to not have to totally reinvent that wheel…

It's easy to experiment with this cheaply by putting small tracked rockets out of sight for long periods of time with modest motors. They stay out of sight longer and at much closer ranges.

Yes, after the L and the M at BALLS, I’m going to now drop to 29 and 38 mm motors for testing. I was once a motor dealer so have ~150 small Aerotech motor reloads capable of putting small rockets out of sight… :)

==> Time for me to get back to programming :)
 
Yup, I've never seen more than 156,000 feet advertised on an MTK GPS chipset in the past so 160k seems to be the guaranteed limit for off-the-self stuff.

Did you mean limit of guaranteed performance, or guaranteed not to work above there? I would agree with the former but not the latter. See:
https://forum.u-blox.com/index.php?...including-altitude-above-000m&show=2317#a2317

Am curious about the need for a GPS on the ground station. I do not own an iPhone but
with my experience tracking at ground level, my Android stuff seems to get a better fix if I'm moving. Having really close accuracy on the rocket side is very nice but just about any GPS on the receiving end for ground location can get one
pretty darned close to the rocket.

Agreed that the phone GPS can get you "pretty darn close", but we're trying to do better than that. Disagreement between the phone and the uBlox receiver in the 5-20 foot range is pretty common, which is enough to sometimes make the pointing direction wrong when both GPS receivers are within arm's reach. For a new user it would erode confidence when they're trying out the system. If you walk the phone away from the tracker so that inaccuracy of a few yards no longer matters, the pointing works fine, but that can be inconvenient. It's true that putting the GPS on the ground station isn't strictly necessary, but we think it's a good value for where we are positioning this product in the market.

The iPhone terminal tracking program looks nice and folks who use that device will much appreciate it as there is a dearth of tracking software for that platform. That said, it would be nice if the NMEA/GNSS sentences could be had off the planned receiver
so those who desire to pipe them into another tracking app or another platform (Android or Windows) could do so. There is a work-around for the Android app "GPS Rocket Locator" that seems satisfactory to that end to track using the combined GPS/Glonass
sentences. Works very well in my ground testing. Interoperability is very advantageous to make everyone happy.:smile:

As we get farther along we'll look into if there would be advantages for our users to make an interface to Rocket Locator or another program. Our first goal is to provide everything the user needs/wants into our own app so that it "just works" right out of the box. DIY projects are great, and can be the lowest-cost option if you're willing and interested to put in the time, but our first priority is to users who don't have such an interest in electronics and software.

From the video, it seemed the arrow was jumping about quite a bit and it was mentioned it was due to the fact that someone was likely holding the phone and the arrow was responding to hand movement.

The "jumping around" in that video was mostly due to a lot of phone motion, and partly to an incomplete new feature, so I have some mixed feelings about putting it out there. Maybe we should post a different video from an external camera that shows the arrow staying steady while the phone moves around.

it's best to be concentrating on getting the last fix before LOS (loss of signal) to give one a starting point of where to start a search from.

The system so far does a pretty good job of keeping track of the last position so you can always track to that, so the user can concentrate on other things. We are going to make some improvements here to make sure that the last known position is based on validated data, and I think there would also be value in making a predicted landing point to give the best possible estimate.

One strategy if one is "going long" with a bluetooth receiving station, just duct tape the receiver on a pole to
get it up in the air off the ground. That has the potential to increase receiving range or use a patch antenna for 900Mhz.

If there is a user who needs more than 300,000 feet of range, then by all means use a patch antenna or a YAGI. But what we have found is that if the rocket is in the air, the omni antenna will make the link as long as your body isn't blocking it.

For really extreme flights where LOS occurs at a farther distance away and higher up, live map plotting gives further insurance to develop a drift line to follow when one gets to the last known position and the rocket has drifted out
of "radio tracker footprint" range. That drift line with the rocket down low gives one a direction to proceed to get within the ground footprint to receive a final position to effect recovery.

Another way to help the user in that situation is to capture the heading and 3D velocity information from the last packet, which we do, and use it to estimate the landing point, which we're planning to do. But this brings up another possible new feature, which could be to add the rocket last heading direction and/or ground track to the display somehow so that if you're still having trouble finding the rocket from the estimated landing point, you know the ground track direction for further searching.

It's easy to experiment with this cheaply by putting small tracked rockets out of sight for long periods of time with modest motors. They stay out of sight longer and at much closer ranges.:wink: Kurt

Yep. And since the tracker fits into a 24mm tube, this is relatively straightforward. Maybe I should make a camouflaged little rocket for this. I finally have my 24mm motors back where I can fly them, so this is on the to-do list.

Edit: Apparently Kevin and I decided to answer these at the same time, without consulting each other.
 
Last edited:
Did you mean limit of guaranteed performance, or guaranteed not to work above there? I would agree with the former but not the latter. See:
https://forum.u-blox.com/index.php?...including-altitude-above-000m&show=2317#a2317

"It was a very long time since I looked. I used to track the high altitude balloons in the Midwest. They use APRS and there was a digipeater 1200 feet away from me that had an antenna 100 feet up in the air. I was effectively using
that antenna and was seeing reception from 400+ miles away when close to 100k'. I believe MTK was guaranteeing accuracy and not saying it was "stopped" at 156k. One has to be careful as some cheap chipsets cutoff at 60k as you know no matter what the speed. This link is dated but gives some info: https://ukhas.org.uk/guides:gps_modules" ... AKS"


Agreed that the phone GPS can get you "pretty darn close", but we're trying to do better than that. Disagreement between the phone and the uBlox receiver in the 5-20 foot range is pretty common, which is enough to sometimes make the pointing direction wrong when both GPS receivers are within arm's reach. For a new user it would erode confidence when they're trying out the system. If you walk the phone away from the tracker so that inaccuracy of a few yards no longer matters, the pointing works fine, but that can be inconvenient. It's true that putting the GPS on the ground station isn't strictly necessary, but we think it's a good value for where we are positioning this product in the market.

"Um, that's about the limit of accuracy if you sit and stare and the Ublox UCenter app as I have. I've sat a 3DR/Neo-m8n radio out in the yard with GPS/Glonass strings coming in and the "spot" wonders
around a bit. Depends upon the status of the GPS/Glonass satellite constellations at the given moment.

spread.jpg

This is an older pic but the results were worse last night when I tested. The constellation wasn't as advantageous. This Android app: https://play.google.com/store/apps/details?id=com.nec.android.qzss.gnssview&hl=en can give one an
idea of the constellation position though I can't get it to display as well in my phone. I can't get the AR view to come up. My larger Nexus tablets it displays fine. Alternatively one can use B/T GPS: https://play.google.com/store/apps/details?id=googoo.android.btgps&hl=en to subvert and ignore the internal GPS of the Android device and one can get an exact idea of what the GPS in the Rocket is seeing while on the pad.
It works with GPS or combined GPS/Glonass. In fact if one minimizes it, it will present the rocket GPS/Glonass strings to the the Android app "GPS Rocket Locator" and the rocket will get plotted as the blue dot:
https://play.google.com/store/apps/details?id=com.frankdev.rocketlocator&hl=en If one pipes the GPS/Glonass strings directly to GPSRL it cannot decode the rocket position as the red pushpin. No problem, just pair
an external GPS B/T source and have GPSRL use that as the red pushpin. So the local position and rocket is reversed in this method. The blue dot "limit of accuracy" circle will be smaller with the combined GPS/Glonass strings.
I'm a script kiddie so this was discovered by trial an error. The 900Mhz Beeline GPS can't export live NMEA strings due to the presence of extra data. That system is limited to manually inputting the last known
position into another device to start the process of recovery. Anyone correct me if I'm wrong with that observation." AKS

As we get farther along we'll look into if there would be advantages for our users to make an interface to Rocket Locator or another program. Our first goal is to provide everything the user needs/wants into our own app so that it "just works" right out of the box. DIY projects are great, and can be the lowest-cost option if you're willing and interested to put in the time, but our first priority is to users who don't have such an interest in electronics and software.

"The only thing you would have to do is make sure the strings come off at 9600bps over bluetooth and they can be piped into anything. If you have it work with your iPhone app only then that's the only folks who'll buy your product. That little work-around I point out above makes a tracking program more easily available for the Android crowd. Yeah, it don't have all the pretty speeds, estimates etc. but it will give a visual indication of the rocket position to effect recovery. Incidentally, only horizontal speed will be had from most apps but of course your could write your own that would display vertical speed instantaneously on your software suite. Me thinks find the rocket and download the data for later analysis." AKS

The "jumping around" in that video was mostly due to a lot of phone motion, and partly to an incomplete new feature, so I have some mixed feelings about putting it out there. Maybe we should post a different video from an external camera that shows the arrow staying steady while the phone moves around.

"Understood but if it got you within close enough range to find the rocket, it's doing the job. I once had a downed rocket and the positions were cheerfully coming in nicely. I couldn't see the rocket on the ground and was puzzled. Would look
really stupid to lose a GPS tracked rocket with valid positions coming in. It looked like I was "right on top of it". Well it occurred to stupidhead to "zoom in" on the map and went right to it. The rocket was camouflaged in
the no-till cornfield. This was with an NMEA tracker as opposed to an APRS one on a modified Windows APRS tracking program. I've taken the advice of others that it's smart to put an aural beacon on a harness to get you
the last 20 feet! (If you can fit it in!)" AKS

The system so far does a pretty good job of keeping track of the last position so you can always track to that, so the user can concentrate on other things. We are going to make some improvements here to make sure that the last known position is based on validated data, and I think there would also be value in making a predicted landing point to give the best possible estimate.

"That would be nice but if you can keep that internal to your local iPhone app and keep the strings clean, it would make them interoperable to the Android and (Windows) crowd. What I mean by that is have the raw GPS/Glonass strings
sent by your tracker without having it add further "stuff" to the sentences. If you want to make your unit proprietary that is the way to go then. If you have your iPhone software process the strings for what you are looking for
then your software will offer a bonus to iPhone users. If the strings remain in the raw form, what do I mean by that? Attach the GPS chip to a USB serial board and that's the raw native strings another platform could deal with them
if they are simply transmitted in that fashion. Rf is the long cable. The analogy is with Altus-Metrum. Their software and hardware will read and decode a lot of data in real time but if one simply wants to find the rocket, they can switch it to plain jane APRS worry about downloading the data later. Looking on a map for a visual representation in flight doesn't get any easier than that." AKS

If there is a user who needs more than 300,000 feet of range, then by all means use a patch antenna or a YAGI. But what we have found is that if the rocket is in the air, the omni antenna will make the link as long as your body isn't blocking it.

"Yagi beamwidth on 900Mhz is possibly too narrow for active, dynamic tracking of an extreme flight. More likely to miss positions because it's hard to keep it aimed at something you can't see. 70cm, 1.25 and 2 meter bands the
beamwidth is broader and more workable with a Yagi. That said, once your rocket is down and generally stationary a Yagi most definitely can increase the ground footprint of the tracker. I've proven that to myself on 900Mhz.
Used the Yagi on recovery and when I first started receiving positions from the downed rocket, unplugged it and screwed on the duck or vertical dipole. Signal disappeared. 900Mhz Yagis are generally economical and
easy to carry. Inflight monitoring I agree use a vertical/omni or a patch antenna." AKS

Another way to help the user in that situation is to capture the heading and 3D velocity information from the last packet, which we do, and use it to estimate the landing point, which we're planning to do. But this brings up another possible new feature, which could be to add the rocket last heading direction and/or ground track to the display somehow so that if you're still having trouble finding the rocket from the estimated landing point, you know the ground track direction for further searching.

"Just lock the last position to memory and one will be a decent shape to get to that position. Make so if power is lost, program can call it up when power is restored. Breadcrumbs on a map are pretty easy to follow but if you
can write it in to your software to save the last known position "no matter what" that will work" AKS

Yep. And since the tracker fits into a 24mm tube, this is relatively straightforward. Maybe I should make a camouflaged little rocket for this. I finally have my 24mm motors back where I can fly them, so this is on the to-do list.

Edit: Apparently Kevin and I decided to answer these at the same time, without consulting each other.

"Best of luck getting this out there to the masses. It has a lot of potential. One last thing to keep in mind is most phones GPS's do pretty well out in the open even with just the GPS strings so I wouldn't belabor it if it will only jack
up the price in the end. I believe your tracker will work perfectly once it's out there." Kurt (answers inline with quotes and initials. Couldn't figure out how to do otherwise. Sorry)
 
Last edited:
"Yagi beamwidth on 900Mhz is possibly too narrow for active, dynamic tracking of an extreme flight. More likely to miss positions because it's hard to keep it aimed at something you can't see.

But the phone is telling you exactly where to point the Yagi :smile: (the phone is pointing you to the rocket even if you can't see it). Now if you ignore it for a while, maybe you would miss something but generally when the rocket is in flight, you would be pointing the Yagi directly at the rocket based on the phone interface/feedback - if it drifts, you would still be certainly close enough for a Yagi at the range we are talking (out of sight). I've even though of mounting the phone to the Yagi so it is one 'unit'...
 
I have a saying I use with my students from time to time. In this context it would be:

"What are the odds you'll ever regret having a highly accurate GPS receiver in the ground station?"

Some may not see it as necessary but I'll defer to Adrian and Kevin. I can think of a lot of value of having a very accurate GPS in the ground station.

I'm a rocket guy – not a ham radio/Android hacker/Arduino/freeware guy. I want to buy a system that works without me having to spend a lot of time messing with it or downloading software that comes from a different vendor or freeware. A complete system that includes all the hardware and software from a single source is what I believe the vast majority of users want. I just want to turn on the hardware, fire up the app on my phone, and track and find my rocket.


Tony
 
" Kurt (answers inline with quotes and initials. Couldn't figure out how to do otherwise. Sorry)

If you reply with quote, and then go to the advanced editing, you can copy and paste the tags that show up in your text editor (the ones that are surrounded by square brackets) to start and stop block-quotes.

On the antennas, at the risk of beating a dead horse, directional antennas aren't necessary at either end of the Featherweight Altimeter tracking system because there is lots of receiver sensitivity margin even using omnidirectional antennas. But if you do want more signal margin, a variety of directional antennas can help. But they all help by squishing the RF energy into a narrower beam, and the higher the gain, the narrower the beam. An ideal patch antenna would force all of the signal into one hemisphere rather than 2, which should double the signal strength in the "good" hemisphere. In reality there is some leakage out the back, and there is a stronger signal toward the centerline than near the edges, but doubling the strength while cutting the beamwidth in half is a decent approximation. That doubling is reflected in a +3dB gain, which can be converted to a factor of 2 in power. Yagi antennas come in a variety of gains and beamwidths. Two from Amazon we bought recently have +8 dB and +13 dB. I see there is a 10 dB beamwidth one, too. An 8dB Yagi will have a directional pattern that isn't all that concentrated, somewhere around a 60 degree beamwidth (width of the beam that corresponds to 50% of the peak power). Yagi antennas are reasonably-sized for anything from 100 MHz signals up to 2.4 GHz signals. At the lower frequencies, the elements need to be longer, scaled with the wavelength.

-Adrian
 
But the phone is telling you exactly where to point the Yagi :smile: (the phone is pointing you to the rocket even if you can't see it). Now if you ignore it for a while, maybe you would miss something but generally when the rocket is in flight, you would be pointing the Yagi directly at the rocket based on the phone interface/feedback - if it drifts, you would still be certainly close enough for a Yagi at the range we are talking (out of sight). I've even though of mounting the phone to the Yagi so it is one 'unit'...

You could experience drop-outs nonetheless but whether or not that makes a difference in the recovery, I've never experimented with that in flight. One could compare with two different ground stations but I wouldn't want to be surprised while tracking a far ranging flight to find out I can't keep a lock. I'll tell you that's a sick feeling. (Been there, done that with APRS.)

I did notice on ground recovery with the 900Mhz Yagi on the fringe of reception, I had to point the Yagi accurately as there was little"play" on either side of the bearing. Now this was on the ground with the rocket stationary so in moving flight at a distance it could be hard to keep the antenna pointed in the right direction. It's true the beamwidth is wider at distances but the tracker power output might come into play to compensate here. The LoRa technology you are using can pick up the slack there. The videos of Multitronix extreme flights zoomed-in on the receiver show pretty decent recovery of telemetry and I believe the X beam antenna is an attempt to deal with mulitpath interference and increase gain. Here's a link on circularly polarized antennas: https://www.robkalmeijer.nl/technie...hniek/hambladen/qst/1990/01/page24/index.html.

A good directional patch antenna with a broader beamwidth is a no brainer for a neophyte if going real far but the best indication of one's needs is how a system is performing in other's hands. If they get great service with a given setup, no need to spend more on hardware if one's flight isn't going to exceed what's already been tried by others.

Kurt
 
If you reply with quote, and then go to the advanced editing, you can copy and paste the tags that show up in your text editor (the ones that are surrounded by square brackets) to start and stop block-quotes.

On the antennas, at the risk of beating a dead horse, directional antennas aren't necessary at either end of the Featherweight Altimeter tracking system because there is lots of receiver sensitivity margin even using omnidirectional antennas. But if you do want more signal margin, a variety of directional antennas can help. But they all help by squishing the RF energy into a narrower beam, and the higher the gain, the narrower the beam. An ideal patch antenna would force all of the signal into one hemisphere rather than 2, which should double the signal strength in the "good" hemisphere. In reality there is some leakage out the back, and there is a stronger signal toward the centerline than near the edges, but doubling the strength while cutting the beamwidth in half is a decent approximation. That doubling is reflected in a +3dB gain, which can be converted to a factor of 2 in power. Yagi antennas come in a variety of gains and beamwidths. Two from Amazon we bought recently have +8 dB and +13 dB. I see there is a 10 dB beamwidth one, too. An 8dB Yagi will have a directional pattern that isn't all that concentrated, somewhere around a 60 degree beamwidth (width of the beam that corresponds to 50% of the peak power). Yagi antennas are reasonably-sized for anything from 100 MHz signals up to 2.4 GHz signals. At the lower frequencies, the elements need to be longer, scaled with the wavelength.

-Adrian

I think the 137,000 foot flight shows the utility of your hardware already. Types of antennas, tracker power output and gain is simply splitting hairs for most fliers. Kurt
 
Back
Top