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.
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)