What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

How to Configure Your APRS Tracker

Sam Buchanan

been here awhile
Reminder: A ham radio license is required in order to operate an aprs tracker!

Navigating through the configuration software for the Micro-Trak trackers is not particularly difficult but does involve dealing with some terminology that most pilots have not previously encountered. Byonics provides a good config document in the download of the configuration software, but the purpose of this sticky is to streamline the process and fill in areas that pertain particularly to airborne trackers.

The information presented in this sticky is already available in the VAF APRS forum but is in several separate threads. This thread will hopefully be a summary of information that can be retrieved in one location.

You will need a cable for connecting your computer to the tracker for the configuration process. The simplest and most reliable method uses a computer with a serial port. A laptop that only has USB can also be used but be advised that problems sometimes arise with low-cost commercial USB-serial converter cables. It may be worth the trouble to find a desktop or older machine that has a serial port. This also allows you to construct a very simple cable for configuring the tracker.

The homemade cable only consists of two female DB-9's (you don't have to install the shields) and some common wire (shielding not necessary). Wire up the cable using this format:

computer pin 5 ------------------- tracker pin 5
computer pin 2 ------------------- tracker pin 3
computer pin 3 ------------------- tracker pin 2

Note that 2 and 3 are crossed. This is intentional and absolutely necessary for the cable to function. This serves as the "null modem" mentioned in the Byonics manual. Do not attach a null modem to this cable or you will "un-null" it! By the way, this cable is bi-directional, it'll work regardless of which end you attach to the devices.

If you have a commercially available cable, you can add gender changers and a null modem in order for it to allow the computer and tracker to talk to each other. But the homemade cable only requires a few minutes to make, costs nearly nothing, and works like a charm.

Here is a screen shot of the configuration page in the Byonics software:

tracker_config.jpg


This screenshot is basically what I use with my tracker and this config has proved to work well for many users of Micro-Traks. Let's work our way through a few areas where questions often arise with new users. Start out by being sure the "Primary" tab is selected.

tracker_config-2.jpg


You have some choices for the call sign to use to ID your tracker. The traditional method used by most ground-bound trackers is to insert the FCC call sign into the "call sign" box. This works fine for our trackers as well. However, many of us wish to have our N-number appear on the tracking maps since those following our flights will be more familiar with the tail number of our plane than our Ham call sign. Using the N-number is legal as long as we ID the tracker according to FCC regulations and we will address that matter shortly.

The Digi Path determines how your tracker packets will be handled by the APRS network of repeaters. The recommended norm for ground trackers is "WIDE1-1, WIDE2-1" which triggers not only large repeaters but also small, fill-in repeaters that assist in getting your beacons to an iGate. However, since an airborne tracker can "see" to the horizon, and we only need to hit the big repeaters, eliminating WIDE1-1 will prevent unneeded bounces from the small fill-in stations. Either protocol will work, but using only WIDE2-1 is recommended for our use unless conditions in your local area dictate the addition of WIDE1-1. If WIDE1-1 is used, be sure it is placed before WIDE2-1 to prevent a wide-ranging cascade of repeater transmissions from occurring.

The symbol fields allow you ensure the generic little airplane symbol is displayed with the track of your flight on the internet maps. Use an apostrophe and a forward slash for the little airplane.

tracker_config-3.jpg


The Timing fields can be left with the default settings and you will most likely never need to make any changes unless you get really creative with the config of your tracker. This area is primarily for those who use the sister product, Tiny-Trak, with a handheld transciever.

tracker_config-4.jpg


The Status area is important because this is where you ID your tracker per FCC regulations if the N-number was inserted into the Call Sign field. The text field will accommodate whatever text you wish to use and some Hams get creative by inserting stuff like "Howdy Ya'll, Billie Bob's tracker is back on the road agin!" but keep in mind the text field adds to the length of the packet and increases the possibility of the packet getting dropped if the frequency is crowded. At the very least, your FCC call sign needs to be in the text field, and you might want to add the aircraft type.

FCC regs require our tracker to be ID'ed at least every ten minutes (but you knew that from cramming for the Tech exam...). Consequently, the status text doesn't have to be transmitted with every packet (keep those packets short!) so if we add a number such as "4" to the "send every" box we will satisfy the ID requirements if we are using an interval of sixty seconds or so for our beacons.

tracker_config-5.jpg


This area only needs minimal attention. The only check you will definitely want is "send altitude" so the altitude of your plane will appear in the data on the internet maps. Some airborne tracker users also check "only send valid". This means the tracker won't transmit unless it is receiving good data from the GPS receiver (green light is glowing steadily on the tracker). If you want the tracker to transmit for set-up or diagnostic purposes without a GPS connected, this box should not be checked. Use your own judgment on this one. In my case the GPS in the plane is generally locked on prior to tracker activation so this is a moot point, your installation may be different.

Update: See this thread for information concerning disabling MIC-E and adding time stamps for increased tracking reliability.

tracker_config-6.jpg


Use the default setting for the other boxes.

tracker_config-7.jpg


SmartBeaconing is a really cool feature of our trackers. The Byonics doc is pretty good in this area and should answer most of your questions. By all means enable SmartBeaconing if you want the highest quality track that shows the aircraft as it maneuvers. The first column of boxes that deal with angle, slope, etc can be left with default settings. The speed and rate settings shown in this example will work fine and get you up and running but you may want to customize them as you get more familiar with your tracker.

The remaining area at the bottom of the page is pretty much self-explanatory and covered in the manual.

There you have it! This should get a tracker to the point where it is functional in your aircraft and performing at a high level. We didn't discuss the secondary tab but it allows you to have a second configuration that can be used if you want the tracker to transmit a different packet protocol. This might be used if you want to transmit a unique emergency packet or maybe you want to use your tracker on the ground and a different configuration would work better for ground ops. A switch is required to activate the secondary config so you can ignore the secondary tab if you don't intend to do something special with the tracker.
 
Last edited:
Great post Sam.

At least in my area, I've noticed that when I removed WIDE1-1 from my path my coverage got much worse. I'm guessing there are folks who are running at home iGates that we're now ignoring me.

I want to be a good citizen, but I think I'll go back to WIDE1-1,WIDE2-1 the next time I'm working on the plane.
 
Great post Sam.

At least in my area, I've noticed that when I removed WIDE1-1 from my path my coverage got much worse. I'm guessing there are folks who are running at home iGates that we're now ignoring me.

I want to be a good citizen, but I think I'll go back to WIDE1-1,WIDE2-1 the next time I'm working on the plane.

Thanks Kevin.

The digi-path won't have anything to do with how an iGate picks up your tracker. An iGate (even if part of a digi-peater) is a receive-only operation (at least in regard to your beacon getting to the internet) and will port any beacon it hears to the internet regardless of the WIDE settings.

It may very well be that you are not getting to iGates as readily without the assistance of the fill-in repeaters, and that may be what you are saying. Whatever the reason, if the inclusion of WIDE1-1 is necessary for satisfactory performance of your tracker....ya gotta do whatcha gotta do. :)

Be sure WIDE1-1 is inserted in the string before WIDE2-1.
 
Last edited:
FCC Call sign with a -X

Gang,

Do the dash numbers after a call sign mean anything? Does it matter one way or the other?

The following is Pete's info, highlighted the -1.

N789PH - info
2008-10-11 18:09:40z
11 MPH 181? alt 932 ft
KD0CVN-1 RV-9A
[TU0X5U via N0NAS-10,K0LAV-8,WIDE2*,qAR,N9MEC]
being tracked - [stop tracking]
 
Gang,

Do the dash numbers after a call sign mean anything? Does it matter one way or the other?

The following is Pete's info, highlighted the -1.

N789PH - info
2008-10-11 18:09:40z
11 MPH 181? alt 932 ft
KD0CVN-1 RV-9A
[TU0X5U via N0NAS-10,K0LAV-8,WIDE2*,qAR,N9MEC]
being tracked - [stop tracking]

Matthew, the dash number doesn't mean anything in particular. If an operator has multiple trackers or stations under his control, he might assign different dash numbers to each.

Many of us like to use our tail number as the callsign for tracking purposes, then put the FCC callsign in the comments text. That satisfies FCC requirements for station ID.
 
-1

Actually it means I am #1, the top dog, the big Kahuna - oh wait, that one is taken already......

Hmmm - what Sam said, then.

KD0CVN-2 will be the APRS unit in the car that my teenage twins will be driving soon. I will be glad to have the speed readout..........Poor Ryan claiming GPS speed is inaccurate. It is just plain unfair.
 
A Question about Configuring the Micro-Trak MT-300

I took Sam's advice and bought one of the latest run of the MT-300 model which turns out to be Version 1.5. Since my RV is very much in the gestation stage, I have been in the shop devising a "portable" package for the MT-300, a 9 volt battery and associated switch and wiring all in a single enclosure. So far everything is coming together nicely. I'm not ready to show photos yet because it's no beauty contest winner, but I may show a photo later.

I'll be using an old Garmin GPS III+ unit I bought for the motorcycle I used to ride. APRS looks like a good use for an old GPS that has not been used for three or four years. As soon as I modify the wiring harness of the four-pin connector to supply data to the MT-300, I'll be almost there...

Well, not quite. I bought the Gordon West study book Sam mentioned and with the practice tests on the QRZ.com site, I am now ready to take the test. I also need to devise an antenna, but I have a plan for a 19.45" piece of wire...Soon...very soon...:D

Question for Sam, Pete, Allen and others: Do I need to power up the tracker before I download the configuration values?

Yes, the tracker must be powered up to read/write the configuration. S. Buchanan

I unzipped the file last night and entered the values from Sam's post, but decided to wait about downloading to the MT-300 until I am listed in the FCC/ULS database...(to be legal). Something tells me power must be supplied to the MT-300 to make the configuration changes, but since I'm not licensed yet, I guess I need to wait.

My thinking is get licensed, power up the first time with the standard configuration, then load the software changes. Is there anything else I need to do? Also, are the values for the config setup for the MT-300 the same as the values used for the MT-8000?

For anyone else out there, I would suggest reading all the MT-300 manuals (Versions 1.1, 1.3, 1.4.1 and 1.5) in sequence. It seems the manual for the 1.5 doesn't include all the information a newby like me might need to know. Of course, Allen is phasing out the MT-300 so it really doesn't make much sense to totally re-write the manual.

I know with the low power output of the 300 mw tracker, my range will be limited, but in the spirit of amateur radio, I am anxious to see what it will do with "just enough" power. I plan to use it in the car, hiking on a mountain and maybe just maybe in the C172. The internal antenna in the C172 may be a problem. We'll see. Seems like the RV-9A pilot who attended Burning Man had an MT-300 and an internal antenna. I'll have to check that. [Update: It was Paul Eastham, but he didn't post any photos of his antenna installation. I think he just velcroed/taped it inside his canopy.]

I really need to get busy on my RV-7 elevators, but this APRS sure is fun. I hadn't soldered anything in years until the other night. :eek:

Don
 
Last edited by a moderator:
Thanks, Bob...Seems there's several clubs/groups that don't list on the ARRL site and the only way to find them is to ask around. That's what I'm doing...
Thanks.
Don
 
Last edited by a moderator:
NMEA Data?

I have an old Garmin 55AVD I use in the Corben. I didn't see data in the operating manual as to whether its NMEA data is TTL or RS-232 (I *think* it is TTL). Can the Byonics Micro-Trak 300 accept TTL and/or RS-232?
 
No Auto Transmit on MT8000FA

Hope someone can help me. I cannot get the my tracker to auto transmit. It sends out a good signal at power up, but that's all. I have the configuration set like Sam suggests. What else can I do?
 
Wont send more than one packet?

You probably have it set for Smart Beaconing with a slow position report rate. If the green LED is on, you have good GPS data to the Micro-Trak, if not you have other issues. I suggest programming a fixed transmission period in the second page of configuration so that you can test the unit without having to fly in circles to generate velocity and angular change. Send me a screen print of your Config screen and lets see if anything jumps out.

73,

Allen
VHS

[email protected]
 
Screen Print

If you have Windows, open your configuration screen, and read whatever is on the chip to the config program. Hit the "print Screen" button on the upper right hand side of your key board, this will copy the whole screen to the clip board. Open a new document in your word processor, and and paste the image to the Word Doc. Send me the Word Doc as an attachment.

Best regards,

Allen
 
MTAIO Tracker Config: Smart Beaconing

Sam and other folks in-the-know,
I've got my Byonics MT-AIO running pretty well. I have flown it and found I must "power on" the GPS 10 seconds prior to the Tx to get accurate "speed" values when SmartBeaconing is OFF. But now I'm experimenting with SmartBeaconing enabled. It works, but I'd sure like a better understanding of the SB parameters. I've read your original post and have my parameters set like you suggested, but I still want to know what they mean. Here is my guess. Please enlighten me if I'm wrong.

If SmartBeaconing is selected, I believe the Tx rate is selected by
Timing: "Auto Transmit Rate"
UNLESS
If my speed is LESS than the "Slow Speed", then Tx rate is "Slow Rate".
If my speed is equal to or more than the "Fast Speed", then the Tx rate is the "Fast Rate".

I assume if I exceed "Min Turn Angle" in the "Min Turn Time", the tracker will transmit another point. But can you explain "Turn Slope"?

Of course I may have all of the above completely wrong!! If so, I'd sure like to know the correct meaning of the parameters.

Thanks for all the help. This is a blast!!
AF6QO
 
Sam and other folks in-the-know,
I've got my Byonics MT-AIO running pretty well. I have flown it and found I must "power on" the GPS 10 seconds prior to the Tx to get accurate "speed" values when SmartBeaconing is OFF. But now I'm experimenting with SmartBeaconing enabled. It works, but I'd sure like a better understanding of the SB parameters. I've read your original post and have my parameters set like you suggested, but I still want to know what they mean. Here is my guess. Please enlighten me if I'm wrong.

If SmartBeaconing is selected, I believe the Tx rate is selected by
Timing: "Auto Transmit Rate"
UNLESS
If my speed is LESS than the "Slow Speed", then Tx rate is "Slow Rate".
If my speed is equal to or more than the "Fast Speed", then the Tx rate is the "Fast Rate".

I assume if I exceed "Min Turn Angle" in the "Min Turn Time", the tracker will transmit another point. But can you explain "Turn Slope"?

Of course I may have all of the above completely wrong!! If so, I'd sure like to know the correct meaning of the parameters.

Thanks for all the help. This is a blast!!
AF6QO

John,

I think you have SmartBeaconing pretty much nailed. I have seen an explanation or two of "turn slope" but still don't understand it enough to offer any insight.

I just use a setting that works and don't worry about why it works. :)

Glad you are enjoying your tracker!
 
John,

I think you have SmartBeaconing pretty much nailed. I have seen an explanation or two of "turn slope" but still don't understand it enough to offer any insight.

I just use a setting that works and don't worry about why it works. :)

Glad you are enjoying your tracker!

Sam,
Thanks for the confirmation. The word "slope" immediately brought to mind the possibility of using the altitude rate-of-change to alter the Tx rate. But since it is "Turn Slope" I'm confused.

OK, I'll just use it and enjoy it.

Thanks for all your posts in initially sparking my interest in APRS, and all the help getting it operating from Byon and Allen.
Best Regards to all,
AF6QO
 
Sam,
Thanks for the confirmation. The word "slope" immediately brought to mind the possibility of using the altitude rate-of-change to alter the Tx rate. But since it is "Turn Slope" I'm confused.

OK, I'll just use it and enjoy it.

Thanks for all your posts in initially sparking my interest in APRS, and all the help getting it operating from Byon and Allen.
Best Regards to all,
AF6QO

I did a little more Googling.... and found this:
"Turn Slope = Number when divided by current speed creates an angle that is added to Min Turn Angle to trigger a beacon."
At Paul VA3PC's web site:
http://www.ciinet.org/paul/aprs.html

Regards,
AF6QO
 
I did a little more Googling.... and found this:
"Turn Slope = Number when divided by current speed creates an angle that is added to Min Turn Angle to trigger a beacon."
At Paul VA3PC's web site:
http://www.ciinet.org/paul/aprs.html

Regards,
AF6QO

John,

Ah...now I know what turn slope is.........I think.............. :eek:

The link you referenced had some good info, among it the recommended dash numbers to use if the FCC callsign is used as the primary ID:

-0 Home Station, Home Station running IGate
-1, 2, 3, 4 are for digipeaters and other home stations
-4 is for HF to VHF Gateway
-5 IGate (Not home station)
-6 is for Operations via Satellite
-7 is for TH-D7 walkie talkies
-8 is for boats, sailboats and ships (maybe 802.11 in the future)
-9 is for Mobiles
-10 is for operation via the internet only
-11 is for APRS touch-tone users (and the occasional Balloons)
-12 Portable Units such as Laptops, Camp Sites etc
-14 is for Truckers
-15 is for HF

Guess aviation would be -9, unless you are Pete Howell who probably needs to use all the dashes! :D :D

Thanks for the info!
 
Last edited:
5 second "Min Turn Time" is too short

To start, I wish to thank Sam for showing me APRS, so I have something to do while I wait for the economy to turn around and I can afford to buy my RV12 empennage. I have been lurking here for several years, and I hate that my first post is one contradicting one of the great ones at VAF.

After experimenting with APRS for 10 months, I feel that the suggested smart beacon settings are a bit too aggressive if not downright abusive.

Here are the suggested settings for "Smart Beaconing":
smart-beacon-too-fast.jpg

The "Min Turn Time" is the number of seconds that must pass before retransmitting while turning.

Consider this "anonymous" APRS airplane track:
aprs-example.jpg


There are 10 positions transmitted over a 40 second period. The tracker was correctly configured with a WIDE2-1 single hop path. All 10 packets were picked up directly by Igates, but that doesn't mean that the packet didn't get digipeated. In fact, there are at least 5 digipeaters within 30 miles of this location. At 1000 feet AGL, it is likely that all 5 digipeaters heard the packets. With a WIDE2-1 path every digipeater would retransmit the packet exactly once. Those 10 packets got turned into 50 packets that effectively shut down all APRS activity within range of those digipeaters.

I suggest that the "Min Turn Time" be set to no faster than 15 seconds when in an area of low to medium APRS traffic. In high traffic areas, we should not be be transmitting any faster than 30 seconds when in a turn, and probably no faster than every 90 to 180 seconds when in a straight line. If you are in an area with good igate coverage, consider using NO path when at high altitude.

With a 15 or 30 second "Min Turn Time", you won't be able to draw perfect circles any more, but you will be making much better use of a limited resource.

I know from experience how fun it is to go home and look at your track and see your every move recorded by the magic of APRS. Let's use this resource wisely and be good APRS citizens. If we aren't careful, we may find that airborne APRS users will develop a bad reputation.

--
Martin
ki6wjp
 
To start, I wish to thank Sam for showing me APRS, so I have something to do while I wait for the economy to turn around and I can afford to buy my RV12 empennage. I have been lurking here for several years, and I hate that my first post is one contradicting one of the great ones at VAF.

After experimenting with APRS for 10 months, I feel that the suggested smart beacon settings are a bit too aggressive if not downright abusive.

Here are the suggested settings for "Smart Beaconing":
smart-beacon-too-fast.jpg

The "Min Turn Time" is the number of seconds that must pass before retransmitting while turning.

Consider this "anonymous" APRS airplane track:
aprs-example.jpg


There are 10 positions transmitted over a 40 second period. The tracker was correctly configured with a WIDE2-1 single hop path. All 10 packets were picked up directly by Igates, but that doesn't mean that the packet didn't get digipeated. In fact, there are at least 5 digipeaters within 30 miles of this location. At 1000 feet AGL, it is likely that all 5 digipeaters heard the packets. With a WIDE2-1 path every digipeater would retransmit the packet exactly once. Those 10 packets got turned into 50 packets that effectively shut down all APRS activity within range of those digipeaters.

I suggest that the "Min Turn Time" be set to no faster than 15 seconds when in an area of low to medium APRS traffic. In high traffic areas, we should not be be transmitting any faster than 30 seconds when in a turn, and probably no faster than every 90 to 180 seconds when in a straight line. If you are in an area with good igate coverage, consider using NO path when at high altitude.

With a 15 or 30 second "Min Turn Time", you won't be able to draw perfect circles any more, but you will be making much better use of a limited resource.

I know from experience how fun it is to go home and look at your track and see your every move recorded by the magic of APRS. Let's use this resource wisely and be good APRS citizens. If we aren't careful, we may find that airborne APRS users will develop a bad reputation.

--
Martin
ki6wjp

Martin,

Thank you for your considered post concerning aprs config settings. Yours is certainly not the first to call into question the settings many of us use for our airborne trackers. My experience with aprs is limited to a little over two years of actual use so I certainly don't rank as an aprs "elmer".

I only want to address a couple of the points you raised. One is your assertion that our settings are abusive and will result in airborne trackers developing a bad reputation. In regard to our reputation, according to the designer of the most popular series of aprs trackers (who frequents this forum), aviation aprs has provided a tremendous shot in the arm for this segment of ham radio and has resulted in the production of a lot of new ham licenses. Contrary to developing a bad reputation, it seems we are helping to energize this segment of ham radio.

Secondly, the dire warnings about how aviation aprs is clogging the frequency don't appear to be valid at this point. If the majority of aircraft had trackers this might be the case. But a look at aprs.fi will usually reveal only two or three aviation trackers (nationwide) in use at any one moment, and they are usually traveling in a straight line. You stated that my (or anyone's) transmission of ten packets in less than a minute "effectively shut down all APRS activity within range of those digipeaters (30 miles)". How do you reach this conclusion other than on a theoretical basis? How many other trackers in my area tried to send a packet within those forty seconds? Is there any way of knowing? If we can't know, how can we determine whether or not the entire local network was paralyzed for less than a minute?

My point is not to disagree about the need for civil use of the service. I guess I've just heard enough hysterical wailing over the past two years from a very small number of hams, nearly all of whom are non-aviation users, about how we are trashing the system that my patience is wearing a little thin. But the network still works very nicely in spite of the occasional aviation tracker.

In regard to tailoring packet transmission rates to fit particular digi densities and tracker altitudes, we just don't currently have the technology for our simple trackers to adjust beacon intervals based on the environment. What might be "appropriate" for a particular portion of a flight over congested areas would not be best for other portions of the flight over sparse population where safety concerns dictate maximum performance from the tracker. You suggested up to 180 seconds for straight line intervals. You may wish to set your tracker that way, but flying nine miles between beacons ain't gonna cut it for me when the technology exists for a much finer (safer!) resolution, and in my opinion meets the criteria for civil use of the service. My tracker is configured for maximum performance for maneuvering flight close to the ground which is precisely the situation wherein the safety advantages of real-time tracking are most important.

I hope this reply doesn't appear harsh or unappreciative of your input. However, after two years of energetic embrace of aprs by many in the aviation community, the settings in common use seem to be cohabiting with the aprs community very nicely while adding a remarkable dimension to aviation safety. It may very well be that in years to come our approach will need to be reconsidered, but we can face that when a very large number of aircraft are flying trackers.

Best wishes for an enjoyable RV project, whichever one you decide to build!
 
Last edited:
I would just like to wholeheartedly agree with and second Sam's comments above.

I also think Sam has been a proponent of responsible use throughout his postings, for example his recommended path of WIDE2-1, which eliminates the fill-in digi hops.

Might I also suggest that, as Sam has done, aviation users of APRS who want to "give back" to the system, consider setting up a digi or iGate of their own to bolster the network, especially in those areas where the network is sparse. This should go a long way in building our reputation within the ham community.
 
Consider this "anonymous" APRS airplane track:
aprs-example.jpg


There are 10 positions transmitted over a 40 second period. The tracker was correctly configured with a WIDE2-1 single hop path. All 10 packets were picked up directly by Igates, but that doesn't mean that the packet didn't get digipeated. In fact, there are at least 5 digipeaters within 30 miles of this location. At 1000 feet AGL, it is likely that all 5 digipeaters heard the packets. With a WIDE2-1 path every digipeater would retransmit the packet exactly once. Those 10 packets got turned into 50 packets that effectively shut down all APRS activity within range of those digipeaters.

I suggest that the "Min Turn Time" be set to no faster than 15 seconds when in an area of low to medium APRS traffic. In high traffic areas, we should not be be transmitting any faster than 30 seconds when in a turn, and probably no faster than every 90 to 180 seconds when in a straight line. If you are in an area with good igate coverage, consider using NO path when at high altitude.

With a 15 or 30 second "Min Turn Time", you won't be able to draw perfect circles any more, but you will be making much better use of a limited resource.


Martin
ki6wjp

Martin,

I thought about this graphic after sending the previous post and thought you might be interested:

97KB-99SB.jpg


This plots the formation entry into the pattern of our local airport of my RV-6 and a pal's RV-6A. We both use the SmartBeacon intervals that you expressed concern about. However, instead of one of the trackers crashing the local network as you predicted, it seems that all the beacons from both trackers successful hit the net even though we were flying mere seconds apart.

Perhaps the aprs system has a bit more capacity than is sometimes predicted. :)
 
...You suggested up to 180 seconds for straight line intervals. You may wish to set your tracker that way, but flying nine miles between beacons ain't gonna cut it for me when the technology exists for a much finer (safer!) resolution!...
I love that statement! This is why I am building an RV.

Plus, I wouldn't have been able to do this for my then girlfriend, now very supportive wife:
Picture3sm.jpg
 
Boy did I poke a stick in a bee's nest. Sorry if I stepped on anybody's toes. I don't want this to become the next "Primer Wars".

While airborne, our trackers cover a much larger area than ground based trackers, and we should behave accordingly. Transmitting every 5 seconds would be frowned upon by every APRS group that I know of.

Just because your packets made it to the internet does not mean you were not impacting the airwaves for hundreds of miles around you. We should be careful to not abuse the privilege.

Just like you can install an O-360 in an RV9, you can beacon at fast rates. In both cases, it is against the intent of the designer. However, there are valid reasons why you would want to do so. You just have to understand the downsides that come with the choice. (My feeble effort to make this as RV related as possible :) )

I urge all prospective APRS users to understand the configuration settings shown at the top of this thread before you start flying with your tracker. If you are in an area of heavy APRS activity, you should certainly consider slower beacon rates.

--
Martin Nile
ki6wjp (hopefully airborne someday)
 
Giving Back To APRS ... Seeking Help

I would just like to wholeheartedly agree with and second Sam's comments above.

I also think Sam has been a proponent of responsible use throughout his postings, for example his recommended path of WIDE2-1, which eliminates the fill-in digi hops.

Might I also suggest that, as Sam has done, aviation users of APRS who want to "give back" to the system, consider setting up a digi or iGate of their own to bolster the network, especially in those areas where the network is sparse. This should go a long way in building our reputation within the ham community.

In the spirit of Pat's message, I am like many who want to "give back" to the APRS system and hopefully improve its "capacity" to handle all these airborne trackers. :)

So ...
UI-View32 - check
AGWPE ... check
Packet Engine Pro (for a "BETTER" AGWPE) ... check
Scanner tuned to 144.390 and connected to sound card on home PC ... check

After MUCH time, I get packets coming through my system and can see them with various pieces of monitoring software.

After additional time I get UI-View32 to "send beacon" and my info shows up on aprs.fi in the right location. [UPDATE: Now that seems to not work. :-( ]

BUT .... I keep get the following message (somewhat paraphrased from memory):

" ... Lost the AGWPE connection to 127.0.0.1..."

AND ..

I cannot get AGWPE nor PE Pro to "talk" to UI-View and thus I cannot "i-gate" the stuff I see locally.

Anyone out there with any ideas?? Yes, I read through the links that Sam put up.

I am starting to think maybe a "winsock" matter but all my other internet stuff seems to be working OK.

James
p.s. If someone made a "sure to work PACKAGE" of all this stuff, I would be first in line to BUY a copy. I have spent WAY TOO MUCH time trying to sort it out. :) :)

p.p.s. THANKS goes to Sam and Kahuna for the time they let me waste of theirs as well. :)
 
First time posting... sorry if I double post ('puter didn't seem to get it there the first time)...

I have never ran APRS (I came this board because of my interest in aprs), but I have a lot of experience in two similar RF technologies: ham radio VHF packet service and a commercial radio service that transmitted a lot like packet/aprs.

First off, in the '90's I did a lot of ham packet radio in San Jose, CA. Using a 25/50 watt 2 meter rig with an antenna 30 feet in the air. Lots of square miles of coverage in Silicon Valley. Back when there were a LOT of ham radio bulletin boards... and a lot of ham radio packet stations...before everyone was on the Internet. Rarely was there a problem getting a signal through the "ether" to the 'verse. Some re-transmits, but not bad. Communicated with other hams all over usa on vhf packet, almost in real time.

Earlier than that, in the '70s and '80s a high tech company I worked for pioneered using UHF radios with digital-to-RF 1200 baud modems of their design (and patent) for use in warehouses for real-time communications between a forklift truck operator and the warehouse computer system. Computer directed picking of goods and put away of goods. We commonly had 20-40 UHF radios operating (split frequencies, kind of like a repeater) from these forklifts on the same frequency pair at the same time. The ONLY time we had problems was if the forklift terminals were all turned on at EXACTLY the same time. Then there would be a lot of RF signal "collisions" and a lot of re-transmits from the terminals. In fact we tested systems this way by turning on as many RF terminals as we could at once to test the system's software ability to recover from the mass collisions. The only thing we did was insert some code to provide for a random amount of wait time, or delay, for that very first transmisson. After that all those operators rarely had but an occasional re-transmit. It SEEMS like the airwaves were going to be full of all those messages, but looking at it with monitoring and recording equipment, even with 40 radios in the same warehouse, transmitting on the same frequency, in a relatively small space, there was mostly empty airtime.

There is lots of 2 meter aprs airspace...and if we don't use the bands, we stand a good chance of losing them. As a ham, I would rather the bands be crowded than under utilized!

-Ed-
KD6UBY
 
Welcome!

Hi Ed,

Good to have you aboard. All that radio stuff is great, but you realize you are required to build a plane now!
 
There is lots of 2 meter aprs airspace...and if we don't use the bands, we stand a good chance of losing them. As a ham, I would rather the bands be crowded than under utilized!

-Ed-
KD6UBY

Ed,

Welcome to the forum and thank you for taking the time to post.

Your comment reflects the observations I have made during the two years a tracker has been in my aircraft. The dire warnings by a few (non-aviation) hams about killing the frequency with aircraft trackers just don't seem to be evidenced by reality.

I also have to wonder if the aprs system has seen a net gain in capacity due to the new iGates that have been installed by aviation aprs enthusiasts...... ;)
 
Maybe we are not doing so bad after all ...

Ed,

Welcome to the forum and thank you for taking the time to post.

Your comment reflects the observations I have made during the two years a tracker has been in my aircraft. The dire warnings by a few (non-aviation) hams about killing the frequency with aircraft trackers just don't seem to be evidenced by reality.

I also have to wonder if the aprs system has seen a net gain in capacity due to the new iGates that have been installed by aviation aprs enthusiasts...... ;)

Did some back of envelope calculations (which means they are probably WRONG:)-) and concluded that in a "typical" city, you would probably need a density of about 1 device/sq mile transmitting in 1 minute intervals with WIDE2-2 to clog the system. Made a lot of assumptions about randomness of arrivals and thus throughput.

That would be a LOT of airplanes even at 1/10th that density.

It is a good idea for us (as mentioned) to be considerate and ALWAYS mindful of the impact of not being good citizens. So far I think we have been and the short burst nature of our transmissions, the limited time in an area and the limit on the propagations is what makes it all work out nicely (so far :) )

James ... just trying to understand this more as I try to find the error in my i-Gate setup. :mad:
 
The network is overwhelmed at times here in NH and elsewhere, just with the terrestrial APRS beacons. Digipeaters are numerous (I have three I take care of) and it only takes a few bad paths or too frequent beacons to QRM the network. We have only one, single frequency for trackers, text messaging, weather data, telemtry, etc.

What folks don't realize is that it only take one I-gate or home user running Ui-View to Igate a position report. Once airborn, you are often in receive range of several of these stations. Especially East of the MS River! Take a look at your raw packet data on APRS.fi and you can see who Igated you and how many hops it took. Better than 95% of the time these I-gates and/or home users hear you first and post your position report on the internet. Any digipeating thereafter is QRM to the network. Essentially restricting all other users from transmitting until the resulting mayhem subsides. It makes no sense to run WIDE1-1, WIDEn-N from an aircraft, and is frowned upon by the creator himself, WB4APR, Bob.

Plus, aircraft trackers HAVE to TX in the blind (dumb tracker, no RXR) , i.e. not waiting for quiet squelch activity. There's no way around not TXing atop of another packet because East of the MS River and up at altitude... the channel is busy 100% time!

An excellent site to study up on the effects of bad paths, frequent beaconing, long TXD, long text, etc etc is:

http://www.aprs.org/fix14439.html

I highly suggest EVERYONE using APRS in an aircraft to read over it, there's more to operating APRS (properly, efficiently, effectively) than what was in the FCC exam book.

APRS was NOT intended for JUST vehicle tracking, but most users now only do just that.

Beaconing position reports every 30 sec is abusive (at times they're 6 seconds apart!) especially when the wrong path is used... for example, todays example is N519RV:

2010-03-22 16:28:00 EDT: N519RV>ST2T5T,N4GMT-3*,WIDE2-1,qAR,WB4EPG-3:`w+B'[,'/"G{}DIRECT->4M3(32nm),C=409,KD0IQK
2010-03-22 16:28:30 EDT: N519RV>ST2U2X,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w,2'o+'/"Gq}DIRECT->4M3(31nm),C=410,KD0IQK
2010-03-22 16:29:00 EDT: N519RV>ST2V0P,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w- ()-'/"Gs}DIRECT->4M3(30nm),C=411,KD0IQK
2010-03-22 16:29:30 EDT: N519RV>ST2V7U,N4GMT-3*,WIDE2-1,qAR,WB4EPG-3:`w-u(3,'/"Gt}DIRECT->4M3(29nm),C=412,KD0IQK
2010-03-22 16:30:00 EDT: N519RV>ST2W4W,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w.c(=,'/"Gp}DIRECT->4M3(28nm),C=413,KD0IQK
2010-03-22 16:30:30 EDT: N519RV>ST2X2Q,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w/S()-'/"Gr}DIRECT->4M3(27nm),C=414,KD0IQK
2010-03-22 16:31:00 EDT: N519RV>ST2X9X,WIDE1-1,WIDE2-1,qAR,KE5VRO:`w0E(e-'/"Gp}DIRECT->4M3(26nm),C=415,KD0IQK
2010-03-22 16:31:30 EDT: N519RV>ST2Y7R,N4GMT-3*,WIDE2-1,qAR,WB4EPG-3:`w17(o,'/"Gn}DIRECT->4M3(25nm),C=416,KD0IQK
2010-03-22 16:32:00 EDT: N519RV>ST3P5V,LTROCK,WIDE1*,WIDE2-1,qAR,W5CI:`w22)<0x1f>,'/"Gk}DIRECT->4M3(24nm),C=417,KD0IQK
2010-03-22 16:32:30 EDT: N519RV>ST3Q3W,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w3*)o-'/"GN}DIRECT->4M3(23nm),C=418,KD0IQK
2010-03-22 16:33:00 EDT: N519RV>ST3R2S,N4GMT-3*,WIDE2-1,qAR,WB4EPG-3:`w4(*=,'/"F_}DIRECT->4M3(22nm),C=419,KD0IQK
2010-03-22 16:33:30 EDT: N519RV>ST3S1Q,LTROCK,WIDE1*,WIDE2-1,qAR,W5CI:`w5(*G,'/"Ed}DIRECT->4M3(21nm),C=420,KD0IQK
2010-03-22 16:34:00 EDT: N519RV>ST3S9V,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w6%*Q,'/"Dt}DIRECT->4M3(19nm),C=421,KD0IQK
2010-03-22 16:34:30 EDT: N519RV>ST3T8S,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w7$*=,'/"D)}DIRECT->4M3(18nm),C=422,KD0IQK
2010-03-22 16:35:00 EDT: N519RV>ST3U7Q,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w8#*=,'/"C+}DIRECT->4M3(17nm),C=423,KD0IQK
2010-03-22 16:35:30 EDT: N519RV>ST3V5Y,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w9$*Q-'/"B9}DIRECT->4M3(16nm),C=424,KD0IQK
2010-03-22 16:36:00 EDT: N519RV>ST3W5P,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w:(*Q,'/"AD}DIRECT->4M3(15nm),C=425,KD0IQK
2010-03-22 16:36:30 EDT: N519RV>ST3X3X,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w;)*[,'/"@]}DIRECT->4M3(13nm),C=426,KD0IQK
2010-03-22 16:37:00 EDT: N519RV>ST3Y2W,LTROCK,WIDE1*,WIDE2-1,qAR,K5MCM:`w<+*e,'/"?i}DIRECT->4M3(12nm),C=427,KD0IQK
2010-03-22 16:37:30 EDT: N519RV>ST4P1W,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w=/*o,'/">r}DIRECT->4M3(11nm),C=428,KD0IQK
2010-03-22 16:38:00 EDT: N519RV>ST4Q0T,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w>/*o,'/">"}DIRECT->4M3(10nm),C=429,KD0IQK
2010-03-22 16:38:30 EDT: N519RV>ST4Q8X,LTROCK,WIDE1*,WIDE2-1,qAR,W5CI:`w?,)Q-'/"=h}DIRECT->4M3(9nm),C=430,KD0IQK
2010-03-22 16:39:00 EDT: N519RV>ST4R7S,WIDE1-1,WIDE2-1,qAR,KE5OVE:`w@)*<0x1f>+'/"<X}DIRECT->4M3(7nm),C=431,KD0IQK
2010-03-22 16:39:30 EDT: N519RV>ST4S5Q,WIDE1-1,WIDE2-1,qAR,KE5OVE:`wA!(G*'/"<F}DIRECT->4M3(6nm),C=432,KD0IQK
2010-03-22 16:40:00 EDT: N519RV>ST4T2S,LTROCK,WIDE1*,WIDE2-1,qAR,W5CI:`wA(<0x1f>''/"<G}DIRECT->4M3(5nm),C=433,KD0IQK
2010-03-22 16:40:30 EDT: N519RV>ST4T9S,LTROCK,WIDE1*,WIDE2-1,qAR,W5CI:`wBx(y*'/"<6}DIRECT->4M3(4nm),C=434,KD0IQK
2010-03-22 16:41:00 EDT: N519RV>ST4U7S,LTROCK,WIDE1*,WIDE2-1,qAR,W5CI:`wCu)y.'/";$}DIRECT->4M3(3nm),C=435,KD0IQK
2010-03-22 16:41:30 EDT: N519RV>ST4V6V,LTROCK,WIDE1*,WIDE2-1,qAR,W5CI:`wDk)[3'/"9S}DIRECT->4M3(2nm),C=436,KD0IQK
2010-03-22 16:41:36 EDT: N519RV>ST4V8V,LTROCK,WIDE1*,WIDE2-1,qAR,W5CI:`wDx(yG'/"9?}DIRECT->4M3(2nm),C=437,KD0IQK
2010-03-22 16:41:42 EDT: N519RV>ST4W0P,LTROCK,WIDE1*,WIDE2-1,qAR,K5MCM:`wDz(oU'/"99}DIRECT->4M3(2nm),C=438,KD0IQK
2010-03-22 16:41:48 EDT: N519RV>ST4W2S,LTROCK,WIDE1*,WIDE2-1,qAR,W5CI:`wDx'&$'/"9;}DIRECT->4M3(1nm),C=439,KD0IQK
2010-03-22 16:42:42 EDT: N519RV>ST4X2Y,LTROCK,WIDE1*,WIDE2-1,qAR,K5MCM:`wE$#<0x1e>s'/"7_}DIRECT->4M3(1nm),C=443,KD0IQK
2010-03-22 16:43:12 EDT: N519RV>ST4X3S,LTROCK,WIDE1*,WIDE2-1,qAR,W5CI:`wEf"<d'/"6/}DIRECT->4M3(0nm),C=444,KD0IQK

Think:
Low power (QRP, non need to QRM for hundred miles around you!)
Low TX rate (you don't test flight for NASA or Boeing, so why so many reports?)
Use a simple path of WIDE2-1 (Don't QRM the other users for hundreds of miles!)

Then we can all get along just fine!

Kriss
KA1GJU-6
 
Last edited:
Interesting to read through this thread again. While I agree with the concept of not clogging the fequency, one of my goals is safety. I had been using Wide 2-1 and not getting decent paths at all. Once, my wife made a couple frantic calls when my path stopped (I was still flying for quite some time, but no hits, so she thought I had gone down! - see track from May 30). This past weekend, I switched to Wide 1-1, Wide 2-1 and got really good results. To show the difference, compare my tracks from May 30 of this year (I actually flew all the way to Ely but the track stops far short of there), or August 14 (the flight went all the way to Elko) with my track from today (September 6). Note that the two earlier flights were at considerably higher elevations (at least some of the time up to 13,000 ft) whereas today I never got above 11,000 and was below 8500 some of the time. The difference in hits and track quality is considerable. I intend to continue using these settings, at least while flying out west, primarily for safety reasons. I will probably decrease my TX frequency and hope that helps with any congestion issues.

greg
 
Any changes to APRS configuration recommendations?

Sam or anyone for that matter.......any changes to your original setup screen shots?

As it has been a while, I just thought I would ask prior to sticking mine in the wing tip.
 
Sam or anyone for that matter.......any changes to your original setup screen shots?

As it has been a while, I just thought I would ask prior to sticking mine in the wing tip.

The screen shots will serve you well. There has been some sniping over the years saying the SmartBeacon settings don't make sense, but they work fine.

Just make sure your tracker isn't too hard to get to in case you want to tweak the config for your particular installation. Somewhere in the forum are some posts about putting a mini-jack in your wingtip so you can reprogram without taking off the tip.

Happy trackin'!
 
For those of you who have setup your own I-Gate/DigiPeater, please read the following link to ensure your Station isn't introducing delayed packets back into the APRS Network. Since I have been flying with my Tracket that I have designed/built, I have found 3 Station in the Kansas City area that had this issue of digipeating packets that can be anywhere from minutes to hour old. When this happens in the APRS Network it starts showing trackers jumping back in time and will reject good position reports while accepting old ones.

The statement below was from a HAM in the area that was able to assist the Station owner to correct the problem.

Just to clarify... The station in question is an igate (a station which relays packets from the radio channel to the Internet). I'm not sure if it's a digipeater at all (don't have time to verify now - it's 1 AM and we just won the ice hockey world championship ;).

The delay can be caused by a bad TNC (Kantronics KPC3+), possibly bad serial line flow control settings, or even a bad Internet line at the igate. I've written a couple of blog posts on the subject:

http://blog.aprs.fi/2008/03/on-duplicate-and-delayed-packets.html

http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html


Thanks

Ray Doerr
N519RV
KD0IQK
 
If at all possible, use WIDE2-1

APRS iGate coverage is no uniform. There are a few areas that have very sparse stations. However, from a couple hundred feet elevation, an APRS tracker transmits a long distance.

The start of this thread recommends the APRS bet configured for WIDE2-1. Some trackers come configured for WIDE1-1,WIDE2-1. This is causing some problems when those units get above the ground.

When I was testing my configuration, I thought I was seeing spotty coverage so I reset my tracker and had WIDE1-1,WIDE2-1. Turns ou that was a bad idea.

A local APRS station operator saw the mid atlantic area light up. It turns out that when I was at 3,000 ft, I was directly received from more than 100 miles away and with WIDE1-1, it was relayed further. Stations were trying very hard to relay the packets so it was hitting nearly every station from multiple points. OOPS.

Thankfully they staff at Byonics where I purchased my tracker is very involved with the Amature Radion community side of APRS. They sent me a note with better settings.

If you are running WIDE1-1,WIDE2-1 it would be good to visit one of the Internet tracking sites and take a look at the raw data.

I was looking around and found another aircraft APRS track that had WIDE1-1,WIDE2-1 and it was making stations over 350 miles away. With WIDE1-1 the packets were being repeated and it was creating large numbers of duplicate data.

I confess, prior to finding out my mistake, I never gave much thought to exactly how the APRS system worked and how my tracker participated (and affected) the network.

My new tracker supports two profiles. I'm going to look into a way to switch profiles automatically based on speed (switch at something below stall) so I can have coverage when on the ground but not blanket the network when atvaltitude.
 
Last edited:
Back
Top