Re: Rocket Tracking
- Thank you James, this clears up a lot of questions we were wondering about. I didn't know exactly what the differences were between the PACKET and APRS TNC's on the Kenwood, but the way you explained it makes a lot of sense.
We got it up and running yesterday after I submitted my post by opening the packet log to view the raw packets and then parsing those using a script. We will try out the CTRL-G utility you mentioned which sounds like it would allow us to filter out the other stations while looking at the raw packets.
I'd never heard of ICMP packets before, are those the only types which have tracks that can be saved? What kind of devices send that ping? I guess the confusion we were running into was the difference between a series of waypoints (which is what we are sending right?) and a track. It seemed like to us that since the waypoint packets appear to contain all the relevant positional information, saving to a GPX file was just a matter of formatting. Is there some extra information sent in a ICMP packet that allows GPX files to be created?
I apologize if these questions are silly. We're just a bunch of college kids and somehow it feels like unless you know someone from the previous generation who is a big ham, it's hard to pick this stuff up.
--- In email@example.com, James Ewen <ve6srv@...> wrote:
> On Wed, Apr 24, 2013 at 11:09 PM, ajmitchell91 <ajmitche@...> wrote:
> > APRSIS seems to only pick up the packets received by the Kenwood when
> > I have the Kenwood TNC in PACKET12 mode rather than APRS12 mode.
> That would be because you have APRSISCE/32 configured to use PACKET
> mode on the Kenwood. When the Kenwood is in PACKET mode, the internal
> APRS software is removed from the chain, and the raw serial data is
> presented to the computer. You need to configure APRSISCE/32 in APRS
> mode (which Lynn really doesn't like) in order to allow the radio to
> still operate in APRS mode, and then shove the packets out the port to
> the computer as well. This is my preferred mode of operation on the
> D710, but I have not configured the TH-D72 to do the same. I think
> others have on here though. Check the archives.
> > However in PACKET12 mode the packets are no saved at all on the Kenwood
> > which makes me a little worried.
> Don't be worried, the radio is operating perfectly.
> > I have managed to receive a few packets from the BigRedBee, which are plotted on
> > the map perfectly. I then used MultiTrack on the BRB station, which opened another
> > window, but despite more pings coming in no GPX file has been saved.
> That would be position reports... there are no ICMP ping packets in APRS.
> > Also in the sidebar not "Save Track" option is available for these packets. Is they in
> > a format that does not allow them to be saved? Is there anywhere I can go to get
> > this data (Lon. Lat. and Alt.).
> You should be able to save the information. Again others have played
> with that much more that I, and the archives will probably have lots
> of information.
> You can press CTRL-G and then put in a budlist filter parameter for
> your rocket. Another window will open and any packet from your rocket
> will be recorded there. You can copy the data and save it to a text
> file from there.
> The wiki describe the APRS-IS filter parameters.
> You would use something like:
> where MYROCKET would be the callsign of your rocket.
- On Thu, Apr 25, 2013 at 4:15 PM, ajmitchell91 <ajmitche@...> wrote:
> Thank you James, this clears up a lot of questions we were wondering about.Sounds like you still need a bit of clarification... think of it this
> I didn't know exactly what the differences were between the PACKET and APRS
> TNC's on the Kenwood, but the way you explained it makes a lot of sense.
way, the Kenwood radios have 3 distinct units inside them. There is a
radio, a TNC, and an APRS User Interface. Compare this to one of the
older traditional packet configurations where you had three boxes, a
radio, a TNC, and a computer. The radio looked after sending and
receiving audio over the airwaves. The TNC converted serial data to
audio, or audio to serial data (modem). The computer ran a program
that took the serial data from the TNC and displayed on screen, or
took your keypresses and sent them out to the TNC.
When in packet mode, the Kenwood radio receives the audio, passes that
to the internal TNC, and then the serial data is passed out the port
to an attached computer, plus the opposite direction sending data from
the computer to the TNC, which is passed on to the radio and sent out
over the air.
When in APRS mode, instead of sending the data out the com port, the
data is passed along to the built in computer, the APRS user
interface. The packets are decoded and shown to you on the screen. The
APRS user interface also gathers information from the built in GPS,
and sends position reports on your behalf as per your settings.
So generally, you either present the data from the TNC to a computer
built into the radio, or out a port to an outboard computer. The
newest generation Kenwood radios however have another special trick
where you can not only let the APRS user interface parse and display
the data, but you can also share that data with an external computer.
The problem here is kind of like having multiple personality disorder.
There's a bit of a tug-of-war between the built in APRS user interface
and the external APRS program. Who's in charge? Most APRS program
assume they are in charge, and you can end up with a bit of a war. You
have to really understand what's going on to try and ensure that when
attempting to use this mode, you get stuff set up right.
> We got it up and running yesterday after I submitted my post by opening theThe CTRL-G filter test mode will grab just the packets that match the
> packet log to view the raw packets and then parsing those using a script.
> We will try out the CTRL-G utility you mentioned which sounds like it would
> allow us to filter out the other stations while looking at the raw packets.
filter parameter. You will have to decipher what the packets are
telling you, and if the packets are mic-e or compressed, you've got
some work cut out for you unless you have an APRS parsing script like
the APRS FAP from Hessu and friends.
> I'd never heard of ICMP packets before, are those the only types which haveI'm guessing you have because you are using the term ping. A ping is a
> tracks that can be saved? What kind of devices send that ping?
specific type of packet used on an IP network. If you go to a command
prompt and type in PING 126.96.36.199, your computer will send a number
of ping packets out to that IP address. The server at 188.8.131.52 will
send responses back, and you will be able to tell how long it took for
the packet to get to the remote server, and a response to come back.
There is no ping facility in APRS at all.
In the APRS world we send UI packets. Those packets are one way only
packets. There is no response coming back at all. The only time you
will get an acknowledgement in APRS is when you send a message packet,
and the recipient station hears that packet. The receiving station
will send an ack back to let your station know the message was
> I guess the confusion we were running into was the difference between aNope, waypoints are specific sentences that get sent from an APRS
> series of waypoints (which is what we are sending right?) and a track.
device to an attached GPS. They are usually defined by the NMEA 0183
$GPWPL string, but there are some proprietary sentences of similar
The best term to use to describe the packets that get sent from an
APRS station containing location information is position reports. If
you use this term, we all know exactly what you are talking about the
term ping does not apply to APRS (although there are some people that
use the term erroneously), and a waypoint is a position report that
has been received by an APRS station, and then translated into the
NMEA sentence, and is being passed on to a connected GPS device.
It may sound like semantics, but using the proper terminology can
ensure that everyone is talking about the same specific bit of
> It seemed like to us that since the waypoint packets appear to contain allSo after all the definitions, we know the above is a little erroneous.
> the relevant positional information, saving to a GPX file was just a matter of
> formatting. Is there some extra information sent in a ICMP packet that allows
> GPX files to be created?
The BRB device sends a series of position reports which should be
heard and decoded by the TH-D72, and the serial data passed to the
computer running APRSISCE/32. APRSISCE/32 will then plot those
positions on the map for you. How exactly APRSISCE/32 takes those
position reports and saves them in a GPX file (using the appropriate
format), I'm not sure of. Lynn might be able to explain.
There's no black magic in the type of position report being sent, just
setting up APRSISCE/32 to save the information in a GPX file. I don't
play with that much though, so I'm not too much help there.
> I apologize if these questions are silly. We're just a bunch of college kids andThe questions aren't silly, and I hope that these definitions help
> somehow it feels like unless you know someone from the previous generation
> who is a big ham, it's hard to pick this stuff up.
clear things up a bit and allow us to communicate clearly in the
future. We can hopefully ensure that we are all talking about the same
thing at least. It can be intimidating, and appear as if APRS is a
black art, but it is all simple data communications and computers...
they only do what we ask, and exactly that. We just have to understand
what we are asking sometimes.