# TrackSoar Users Wanted

### Help Support The Rocketry Forum:

#### lowga

##### A.K.A. 'Mr. HoJo'
TRF Supporter
I recently purchased a TrackSoar APRS unit. Of all the products available, it was the only one I could find that provided both APRS/GPS tracking capability along with real-time telemetry data such as the barometric sensor. I'm waiting on my unit to arrive--and plan to fly it on a Madcow Cowabunga kit. I've installed an altimeter bay in the nosecone, and I'm hoping there is enough room for the TrackSoar and an audible beeper.

I'd love to hear from any other rocketeers who have purchased and use the TrackSoar. I want to be considerate to the 144.390 national frequency, but love the idea of having the data posted to the network in case there are any local reception issues.

73,

Les Rayburn, N1LF
NAR #81057

#### ksaves2

The only issue is your antenna but 300mW should be a reasonable output for tracking sport rockets. The problem with this system is you will be confined to 144.390 and if you are in a more urban area with nearby digipeaters you could end up
triggering a mess of them jerking the 'ire of the APRS Nazis with once every 5 second APRS packet transmissions. If the unit allows you to fly with a bare path statement so you don't trigger outside digipeaters or IGATEs there would be the option
of using a ground station/phone with wireless internet access that could gate your positions to the APRS-IS via the network directly. That will not raise anyone's eyebrows. An example is using your
phone with internet access to gate it to the APRS-IS network. That is of course if your phone has data access at your launchsite.
The high altitude balloon guys can really tick off the APRS community with frequent packet updates and WIDE1-1,WIDE2-2 settings in the path. At 100,000' they can hit a lot of digipeaters and clog up the systems with

I dunno, does the device allow you to program it to transmit position packets once every 5 seconds? If so its usable. You really can't go any more frequent with APRS reliably.

I don't know what this fascination is with gating one's rocket flight to the internet. I just want my rocket back so it's not of any interest to anyone else. If I was going to use
2 meters I'd tune off the national frequency and do high rate tracking without disturbing anyone else.

Look, your rocket flights aren't going to last that long nor are they likely going to be flying that far to need to be monitored by the national backbone. High altitude balloon fliers can count on the APRS-IS network if their project
gets out of range of their ground station so it is of benefit to them if they have a local internet link to check on their out-of-range balloon. Not likely of any help with a local rocket flight.

Now, if you don't have a local network connection to the internet and there is an IGATE station nearby, you could put that stations callsign in the path and it will be the only one that "hears" the rockets positions and gates it to the internet for you
(besides your local receiving station). In this case, it's the range/distance between the IGATE and the rocket that governs whether or not the position is received and gated to the internet not the distance between you and your ground receiving station. You would have to be certain the nearby station is an IGATE and not simply a digipeater.

Also, those teeny-tiny GPS receive antenna/chipsets give less performance than the larger ones. Yeah the newer chipsets are better than the older one's but I've found with side-by-side comparisons the antennas with more
surface area give better performance than those smaller ones.

The Tracksoar looks sized for smaller rockets though. Be aware with 300mW output your battery isn't going to last as long and need to take that into account. Kurt

#### lowga

##### A.K.A. 'Mr. HoJo'
TRF Supporter
My understanding is that the TrackSoar APRS parameters can be easily modified in software. This includes the ability to change how often the unit transmits position packets. I know that most of the balloon guys transmit updates only once per minute, for example. The only desire for transmitting to the national network is that if there are reception problems locally, you could at least recover a position packet from the Internet showing the last position of the rocket and no where to look. But I agree that it's important to be considerate, and not having the packets digipeated like crazy. Even at a few thousand feet, a 300 miliiwatt transmitter can hit a lot of receivers over a wide area.

I'm hoping to hear from TrackSoar owners who have some experience in flying the unit on rockets. According to the company, they've sold at least 2 or 3 of these to high power rocket guys. Anyone out there?

Thanks for the insights Kurt.

73,

Les N1LF

#### ksaves2

You're welcome,

Oh, a couple of other things. It looks like if you would like a screw on antenna an SMA connector looks like it could be added to the board. Avoid a carbon fiber airframe and metallic paints as they can shield Rf from getting out and perhaps further
degrade the GPS signal from being received. One other suggestion. Fly it in a project on low powered motors first and see what kind of performance you get from that micro GPS antenna then proceed to longer flights unless you hear from someone who has already flown them in rockets. The dynamic state of a rocket is quite different from a high altitude balloon. I found out the hard way and vow never to do that again. I put a tracker in a rocket, always a shakedown flight before really punching it
even if I'm confident "it's right". It gets pretty pricey, pretty quickly to lose your $200.00 tracker along with a rocket and deployment electronics if something is wrong with one's tracker installation. Am pretty religious about this and wished there was someone around when I started out to help me avoid the mistakes I made. Cost $. Kurt

#### lowga

##### A.K.A. 'Mr. HoJo'
TRF Supporter
Kurt,

Solid advice. I have a BigRedBee 70cm tracker that I've flown on low power flights. It's 100mw with a screw on SMA antenna--works great! With my HT and an Arrow antenna, I can easily track it for miles. Lost the rocket in a swamp after the chute drifted like crazy on me. Lost sight of the rocket, but tracked it easily using a five element 70cm Arrow antenna.

Honestly, the GPS tracking is more for "cool" than practical. If you just want to recover your rocket, the BigRedBee transmitter is hard to beat. Rugged and works great. Easy to program too. If memory serves me, they also make a 900 MHz version that does not require a license.

Anyone who can past the Level 2 cert test could pass the Technician Ham test.

73

Les N1LF

#### jderimig

Tracksoar owner here but haven't flown it yet.

The software is Arduino code. Common aprs configuration is done by editing well commented lines of code. Also if you are novice programmer you can do some neat custom things in code.

For example there is bmp180 pressure send and code for built in. To be a good aprs neighbor you can modify the software to transmit updates around apogee and again 100 feet or so above ground to be sure to get clean fixes when you need them while still having a low update rate.

#### ksaves2

I briefly scanned the program but I didn't see a PATH statement. It's likely in there. My understanding is if one doesn't have anything in the PATH, the digipeaters won't digipeat which is fine to be a good neighbor with a rocket launch on .390.
Question is are any packets going to be gated to the APRS-IS system soooooo...... one's positions can be seen on the internet. (If that is what's desired) Can select a nearby IGATE by callsign or if it's only a digipeater with an IGATE
nearby, one could put something like N5RAX, WIDE2-1. N5RAX is the digi and hopefully it will repeat the rocket position one time so it hits an IGATE so it ends up on Google APRS. In that regard it's the distance from the digipeater/IGATE to the rocket that's important with regards to tracking.

The best situation to be in is if one has an internet connection on the device they are using as a receive station, use a bare path statement on the tracker so digipeaters don't respond and potentially, albeit briefly pipe high rate positions through the network so as to minimize the effects of transmitting an APRS packet over long distances via Rf when that is really not needed. Putting the APRS positions at high rate through the network can be handled quite easily.

Comment about onboard sensors. Totally useless for outside data gathering period. If one wants to see an accurate temperature of the outside, there needs to get a remote probe to the outside. The probes are on the board and the boards usually get warm with use.

For balloon guys, this can act as a reassurance their electronics will remain healthy. It gets too cold, their batteries or unit may cease operating. In rockets? Most folks don't remain at altitude long enough for it make a difference. Ditto that for humidity. What's it good for? Nothing as far as relevancy of a rocket flight.

A tracker is primarily to find ones rocket and should be considered as nothing more.

I messed with a small GPS antenna some Sparkfun stuff as shown below:

Now maybe the Tracksoar people have figured out how to get them to receive reliably out in the open but I never could get more than 5 satellites to lock. True these are older and perhaps there is a pre-amp on the Tracksoar board but you guys are the pathfinders here.

If you get decent performance. this would be a nice additional device for use to use.
The size and power output on 2 meters is pretty darned good. If it stands up to rocket flight
and gives decent performance on the downside I'll save up for one. Kurt

#### jderimig

I briefly scanned the program but I didn't see a PATH statement. It's likely in there. My understanding is if one doesn't have anything in the PATH, the digipeaters won't digipeat which is fine to be a good neighbor with a rocket launch on .390.
Its set in the config.h file.

Code:
// Set your callsign and SSID here. Common values for the SSID are
// (from https://zlhams.wikidot.com/aprs-ssidguide):
//
// - Balloons:  11
// - Cars:       9
// - Home:       0
// - IGate:      5
#define S_CALLSIGN      "N2AFU"
#define S_CALLSIGN_ID   11

// Destination callsign: APRS (with SSID=0) is usually okay.
#define D_CALLSIGN      "APRS"
#define D_CALLSIGN_ID   0

// Digipeating paths:
// The recommended digi path for a balloon is WIDE2-1 or pathless. The default
// is pathless. Uncomment the following two lines for WIDE2-1 path:
#define DIGI_PATH1      "WIDE2"
#define DIGI_PATH1_TTL  1

// APRS comment: this goes in the comment portion of the APRS message. You
// might want to keep this short. The longer the packet, the more vulnerable
// it is to noise.
#define APRS_COMMENT    "Tracksoar v1 Beta"

// --------------------------------------------------------------------------
// AX.25 config (ax25.cpp)
// --------------------------------------------------------------------------

// TX delay in milliseconds
#define TX_DELAY      300

// --------------------------------------------------------------------------
// Tracker config (trackuino.pde)
// --------------------------------------------------------------------------

// APRS packets are slotted so that multiple trackers can be used without
// them stepping on one another. The transmission times are governed by
// the formula:
//
//         APRS_SLOT (seconds) + n * APRS_PERIOD (seconds)
//
// When launching multiple balloons, use the same APRS_PERIOD in all balloons
// and set APRS_SLOT so that the packets are spaced equally in time.
// Eg. for two balloons and APRS_PERIOD = 60, set APRS_SLOT to 0 and 30,
// respectively. The first balloon will transmit at 00:00:00, 00:01:00,
// 00:02:00, etc. and the second balloon will transmit at 00:00:30, 00:01:30,
// 00:02:30, etc.
#define APRS_SLOT     -1     // seconds. -1 disables slotted transmissions
#define APRS_PERIOD   60    // seconds

// GPS baud rate (in bits per second). This is also the baud rate at which
// debug data will be printed out the serial port.
#define GPS_BAUDRATE  9600
Comment about onboard sensors. Totally useless for outside data gathering period.
Except for the baro sensor

Now maybe the Tracksoar people have figured out how to get them to receive reliably out in the open but I never could get more than 5 satellites to lock.
Nope. That is the weakest point of the unit. Indoor lock is spotty for me but outdoors I think it is ok. I think I have gotten 8 sats in a reasonable time but time to re-acquire after lost lock might be a concern in a rocket. In a balloon no problem there is a lot of time available. However I am reasonably confident that in a rocket under chute it should not be a problem. I will find out when I put one up in the air hopefully this year.

#### ksaves2

Its set in the config.h file.

Code:
// Set your callsign and SSID here. Common values for the SSID are
// (from https://zlhams.wikidot.com/aprs-ssidguide):
//
// - Balloons:  11
// - Cars:       9
// - Home:       0
// - IGate:      5
#define S_CALLSIGN      "N2AFU"
#define S_CALLSIGN_ID   11

// Destination callsign: APRS (with SSID=0) is usually okay.
#define D_CALLSIGN      "APRS"
#define D_CALLSIGN_ID   0

// Digipeating paths:
// The recommended digi path for a balloon is WIDE2-1 or pathless. The default
// is pathless. Uncomment the following two lines for WIDE2-1 path:
#define DIGI_PATH1      "WIDE2"
#define DIGI_PATH1_TTL  1

// APRS comment: this goes in the comment portion of the APRS message. You
// might want to keep this short. The longer the packet, the more vulnerable
// it is to noise.
#define APRS_COMMENT    "Tracksoar v1 Beta"

// --------------------------------------------------------------------------
// AX.25 config (ax25.cpp)
// --------------------------------------------------------------------------

// TX delay in milliseconds
#define TX_DELAY      300

// --------------------------------------------------------------------------
// Tracker config (trackuino.pde)
// --------------------------------------------------------------------------

// APRS packets are slotted so that multiple trackers can be used without
// them stepping on one another. The transmission times are governed by
// the formula:
//
//         APRS_SLOT (seconds) + n * APRS_PERIOD (seconds)
//
// When launching multiple balloons, use the same APRS_PERIOD in all balloons
// and set APRS_SLOT so that the packets are spaced equally in time.
// Eg. for two balloons and APRS_PERIOD = 60, set APRS_SLOT to 0 and 30,
// respectively. The first balloon will transmit at 00:00:00, 00:01:00,
// 00:02:00, etc. and the second balloon will transmit at 00:00:30, 00:01:30,
// 00:02:30, etc.
#define APRS_SLOT     -1     // seconds. -1 disables slotted transmissions
#define APRS_PERIOD   60    // seconds

// GPS baud rate (in bits per second). This is also the baud rate at which
// debug data will be printed out the serial port.
#define GPS_BAUDRATE  9600
Except for the baro sensor

Nope. That is the weakest point of the unit. Indoor lock is spotty for me but outdoors I think it is ok. I think I have gotten 8 sats in a reasonable time but time to re-acquire after lost lock might be a concern in a rocket. In a balloon no problem there is a lot of time available. However I am reasonably confident that in a rocket under chute it should not be a problem. I will find out when I put one up in the air hopefully this year.
That is good to hear. Looks like the program is bare path unless one removes the comment. I suspect if one hits an IGATE their position will be gated to
APRS-IS hence it gets to Google APRS. I've seen if one uses "NOGATE" in the path statement will tell the IGATE not to pipe to -IS. With the flights most rockets
being short, high rate reporting through the network is not much of an issue.
Outdoor reception is the kicker here. The more satellites one receives the better. Eight is plenty.

Righto on the baro sensor as long as there is a static port to the outside and one is interested in it.

My comment on the 5 satellites was on the two GPS units I showed in the picture with the chip antennas. They are many years old now and old technology.
It was not with a Tracksoar.

I'd like to see flight reports in the future. If it gives good service it would be a great device for Ham fliers to have available. It's close in cost to a Beeline if
one considers the need for the programming hardware. Kurt

#### lowga

##### A.K.A. 'Mr. HoJo'
TRF Supporter
I'm actually excited about the baro sensor. I'd love to modify the code to see frequent baro reports and positions reports. My thought is that flights are so short that it won't be on the network for long, and many might be interested in seeing telemetry from a rocket on APRS. Certainly it's novel.

Can't wait to get mine, and try it out.

73,

Les Rayburn, N1LF

#### ksaves2

I'm actually excited about the baro sensor. I'd love to modify the code to see frequent baro reports and positions reports. My thought is that flights are so short that it won't be on the network for long, and many might be interested in seeing telemetry from a rocket on APRS. Certainly it's novel.

Can't wait to get mine, and try it out.

73,

Les Rayburn, N1LF
Ahhhhhhh, Does the device have onboard storage? If not you'll have to be satisfied with APRS updates once every 5 seconds and you might not receive all of the position packets via Rf. The thing in your favor though is the 300mW output, the fact the
propagation on the 2 meter band is better than 70cm and 33cm and the fact you'll have the option to use a 2 meter Yagi (3 element is about all that is easily hand held) will increase the odds of successfully decoding packets.

There is a video of a multi-stage rocket going to extreme altitude and the camera is shown monitoring the screen of the Multitronix receiver. The Multitronix is not an APRS system but is actually more optimized in my opinion for
high frequency rate updates. That device it is said, sends data out at 5/sec although I don't know if that is the altitude readings 5/sec.
It appears there are periods of delay when the altitude is unwinding on camera. Granted, the delay is shorter than I've observed with other systems but many times with one every 5 seconds APRS updates, I've seen no discernable positions sometimes for 10 to 20 seconds on the down side. Sometimes it's once every 5 seconds but not every Rf packet is decodeable. Higher transmit power and better receive antennas improve the chance of accurate decoding but don't get your hopes up for getting "totally" reliable high rate data over the Rf link via APRS. You'll have plenty of information to find your rocket so don't fret that.

When I used to APRS track on a laptop with Xastir in Linux, even with the once every 5 seconds updates the bread crumb trail on the map was most helpful. I'm hoping to give it a go with Xastir on a Pocket Chip in the future.
https://docs.getchip.com/pocketchip.html#pocketc-h-i-p-at-a-glance One ditches the Pocket Chip firmware and flashes Debian "Jessie" that's available on the Next Thing site. The Pocket Chip runs fine.

I loaded Xastir and some basic maps and Xastir takes awhile to open but it does work. I've got the NMEA EggFinder trackers working with it by piping the incoming NMEA strings into a python script that makes it into an APRS packet. Just select "allow networking" in Xastir, run the script in a plain x-term while Xastir is running and minimize the terminal. The EggFinder is seen on the Xastir map like a pseudo APRS icon.

Here is the link for the script: https://www.ece.uah.edu/~jdw/rockets/gps2aprs.txt One has to change the .txt to .pl, edit their particulars as explained in the comments and its possible to use an NMEA tracker with Xastir.
Just put the location the receiver resides (ex, /dev/rfcomm0) in the appropriate statement in that script. Another funky thing is the script can put a number on the icon. I have the number 8 appearing on the body of the rocket icon.
I haven't seen that before in any programs actually.

The Pocket Chip has the potential of running APRS too via a Bluetooth TNC. Xastir has the ability to put a lot of information next to the icon on the map including groundspeed, bearing, track and altitude along with bread cumbing the track and saving the positions for repainting later on the program. Can save a variety of logs simultaneously including a .kml file. Just go to the directory, grab the .kml and loft it to Google Earth. No conversion program to run.

If one wants to do APRS on a laptop, get UI-View and find a torrent of the maps for offline maps and one will have much the same capability as Xastir except UI-View allows one to record in real time the flight. Only program that does that. One can playback the flight in real time any time they want. No other APRS program does that. Only problem is bluetooth connectivity in the latest WinBlows leaves everything to be desired. It really sucks and one might be stuck with a wired TNC which can be a drag as is running a full sized laptop out in the field. The issue is with UI-View is the author died and refused to disclose the source code. It's frozen in time.

APRSIS-32 on a tablet is very workable and can deal with the infernal WinBlows bluetooth issues. The program itself can work with bluetooth TNC's and GPS (for local) position. I've used it a lot on several different tablets
satisfactorily. It can save a variety of maps but there is no longer a MapQuest photomap set for it. There are a variety of Open Source maps for it that can be cached on a microSD card for offline use.
On WinBlows tablets I have mine setup like a laptop desktop. I can't get used to Micro interpretation of a tablet. A mouse is a must. Wear black pants and you can run a wireless mouse on your pants leg or get a handheld mouse. I use a mouse with the Pocket Chip too as it doesn't have a touch screen.

Out of all the programs out there APRSIS32 might be a little easier for a new person to learn. Extensive online database and the user group is very helpful and don't mind answering elementary questions. This program
can be hacked for use with NMEA trackers like the EggFinder and Missileworks. So I only have to have my WinBlows tablet(s) and I can use them with my APRS and NMEA trackers. One program good for both formats.
(As is Xastir too but perhaps a higher learning curve with that one.)

Sorry to be long winded but I really enjoy the ease of finding a rocket with live map tracking when one gets the system down pat. You start toying with a live tracking remedy and master it to a degree,
it makes tracking a totally out of sight flight less stressful and actually enjoyable. Kurt

Last edited:

#### lowga

##### A.K.A. 'Mr. HoJo'
TRF Supporter
Once every five seconds for baro updates and positions will most likely meet my needs. I've used UI-View for amateur satellite operations including contacts though the ISS. I'll have to experiment with that on a laptop, and see how that works. Looking forward to extensive ground testing with the TrackSoar when it gets here.

Have not tried Xastir, but I'll look into that as well.

Most of my rocketry falls into the "low and slow" category, so tracking is a secondary consideration. Telemetry is of great interest, along with recording video of the flights.

73,

Les N1LF

#### ksaves2

Once every five seconds for baro updates and positions will most likely meet my needs. I've used UI-View for amateur satellite operations including contacts though the ISS. I'll have to experiment with that on a laptop, and see how that works. Looking forward to extensive ground testing with the TrackSoar when it gets here.

Have not tried Xastir, but I'll look into that as well.

Most of my rocketry falls into the "low and slow" category, so tracking is a secondary consideration. Telemetry is of great interest, along with recording video of the flights.

73,

Les N1LF
Les, Do you have the Precision Mapping mapset for UI-View? It makes it easier for off line tracking. The maps are zoomable. If you have experience with UI-View you're in a very good position to use it. You know where the record position is in the toolbar?

The other thing that handicaps this program is Precision Mapping it out of production so if one really wants it, they have to look for a pirated version to download
or by the CD's from somebody or NOS.

The only potential problem is since the Tracksoar is on the national frequency 144.390, one is stuck with decoding incoming positions from other stations via Rf.
The potential for packet collision and getting lost positions from your rocket is much higher if the APRS backbone is very active near your launch site.

This is where a tunable device is helpful because one has the option going off the National APRS frequency say 144.800 or another simplex channel and track
with less fear of interference from other stations. Kurt

Last edited: