Neat that this is up for discussion. There are a few NMEA only trackers out there on 900Mhz to track rockets. This is one of the economical kits: Eggtimer Rocketry - Eggfinder$120.00 for the tracker and the receiver tain't bad. Add an HC-06 B/T module to the receiver and can pipe the output to wherever. I've been open to a tunable NMEA tracker in the ham bands that would stick one's callsign periodically intothe NMEA strings without screwing up decoding on the receiving side. Perhaps with a little more power thanthe 100mW with the 900Mhz tracker above. 70cm might be a bit more reliable? The proprietor of the above system mastered injecting the barometric altitude from the TRS rocket deployment altimeter (another device) into the display of the LCD receiver. Where the GPS altitude was displayed with the GPS tracker, using the TRS, the lat/long is displayed from the onboard SirfIV GPS but the barometric altitude from the onboard baro chip is telemetered back and displayed instead where the GPS altitude would ordinarily be shown. Also the status of the deployment circuits is shown while in flight. This circumvents the altitude inaccuracies of the SirfIV GPS. When monitoring this stream with Xastir, the GPS altitude will be placed on the map but the data strings from the baro altitude and status can be seen occasionally on the station info screen. If the above could be achieved, it's probably simple just to stick a callsign in the NMEA strings of a simple tracker every so often to be legal without messing any decoding up. Plus any device used for hobbyist aerial or ground tracking is likely not going to have to totally conform with all the available information to be had. Just position, direction, speed and altitude(plus a callsign to be legal every 10 minutes). Only problem here is a straight NMEA GPS track on the Ham bands would have a very limited market so is probably feltnot to be financially feasible. Plus if one is interested in onboard storage of position, the Beeline GPS tracker is alreadyout there for APRS. For the "I jes wanna find my toy people" all the additional information abilities of APRS isn't needed since we're tracking off the national frequency (at least on 2 meters or 70cm) at a desired high update rate. Yeah, I know the high altitude balloon guysuse 144.390 but they don't use high reporting rates as is desired to track a dynamic amateur rocket flight. I'm sorry about this being a bit O/T but it is in line since Xastir can plot NMEA strings other than the it's own local positionso I'm not completely off topic here. APRSISCE/32 can do it by running two instances but I believe there is some latencyhere that impedes decoding the positions in flight and local positions in real time. It didn't seem that I was decoding very many positions (they're coming across at 1/sec) in flight for launches that really didn't go very far. I suspect either the latency of decoding two strings at once with /32 caused string collisions or 100mW might be too low a power output for reliable decoding. Nonetheless, I've never lost a rocket with the 100mW tracker. I catch enough positions to get toa recovery site even for a totally "sight unseen" flight. Next round of testing I am going to fire up Xastir for NMEA tracking. I've used it for APRS rocket tracking and it works likea champ there. The once every 5 second position reports are somewhat "course" for mapping but I can download the onboard memoryoff the Beeline APRS GPS tracker that can store positions at a higher rate to plot after flight. With APRSISCE/32 I am going to fire up the NMEA instance that is tacking the NMEA strings off the rocket tracker receiver as the "local" position and shut off temporarily the network port (APRSIS)that listens for the once every 10 seconds "beacon" from the second instance of /32 that is running minimized to plot my local position. That gets beaconed/plotted on the screen that is displaying the rocket. Since I don't have to worry about my local position until after the last rocket position is received, there's no reason to be monitoring my location. I can paint it on the mapand then stop listening for the beacon over the APRSIS Network! Heck, I could shutdown the second instance to reserve as much CPU overhead for the flight in question!Once the rocket is down, I can "turn on" APRSIS in my primary instance and open the second instance of /32 to start painting my position so I can navigate out to the recovery site. With Xastir, I just have to get the bits paired and fire up Jason's (KG4WSV) script and let 'er rip. My only handicap in that regard is my lack of a decent Linux tablet arrangementthat is more easily portable. The old days with a heavy Celeron tablet was a pain. I do have Xastir going on a Pocket Chip (https://getchip.com/pages/pocketchip) though it takes awhile to come up. It does work but I don't know if there is enough CPU overhead to carry the processing load of a rocket in flight. Ground testing walking around it works pretty well but I have to use an Rf mouse as the Pocket Chip doesn't have a touch screen. Heck the screen is so small a mouse is mandatory anyways. This script kiddie had to ditch the stupid "game" ROM that comes on the PC and flash a Jessie version on it. I then found out I couldn't get my Bluetooth stuff to pair properly unless I ran the thing from a "root" account. Beats me why I had to do it but it works.I love the menu "tear offs" in Xastir and store a variety of zoom levels in the bookmarks. Once the program is up and running, it's pretty crisp. The Pocket Chip has 8Gb of onboard memoryso I can get my whole state map in there. Can't wait to get out to test. Kurt KC9LDH From: Jason KG4WSV <[email protected]> To: Xastir - APRS client software discussion <[email protected]> Sent: Friday, July 21, 2017 8:53 AM Subject: Re: [Xastir] GPS NMEA sentences decoded by Xastir On Thu, Jul 20, 2017 at 11:33 PM, Menga <[email protected]> wrote: > I noted in the file gps.c of the Xastir sources two problems in the decoding > of GPS NMEA sentences: only two types of sentences are decoded $GPRMC and > $GPGGA,
Those two sentences are part of the standard, they are provided by practically all consumer devices, and they are sufficient to provide xastir with position, course, speed, and other data needed for an APRS location packet. > no checksum is tested. that's maybe a bit sub-optimal, but for most installations of xastir it would be vanishingly rare for an error detectable by a checksum to occur. > GPS devices have many different preambles, just in my case $IIRMC and > $IIGGA, II stands for integrated instruments, but there are many others that > are banned from Xastir. They aren't "banned", they simply are not supported. What sort of device is providing II sentences and, I assume from your question, does not provide GP sentences? Have you experienced errors that would have been detected by checksum verification? -Jason kg4wsv _______________________________________________ Xastir mailing list [email protected] http://xastir.org/mailman/listinfo/xastir _______________________________________________ Xastir mailing list [email protected] http://xastir.org/mailman/listinfo/xastir
