Topics

KISS TNC for APRS


Jerome Lofton <LoftonJ@...>
 

Lynn,

Can you elaborate on your plans for KISS TNC for APRS and how it would be
used with APRS-IS CE.

Thanks,
Jerome
WD4CWG


Lynn Deffenbaugh
 

Jerome Lofton wrote:
Can you elaborate on your plans for KISS TNC for APRS and how it would be used with APRS-IS CE.
I'm glad you asked! ;)

I have a version of the client running in development that allows configuration of a "data source" for KISS TNCs and/or NMEA GPS. This will be supported in both the Windows Mobile and Win32 when it is released. By "data source" I mean either a serial port (which may be a paired BlueTooth serial port) or a TCP/IP address and port combination. This will allow APRSISCE/32 to connect either directly via serial, or via BlueTooth serial (which looks the same to the program), or via a TCP/IP stream to either a KISS-mode TNC or an NMEA-protocol external GPS.

When an NMEA port is used (which is mutually exclusive with the currently support GPSapi-supported GPS), APRSISCE/32 gets position and time information from the GPS and uses that in the same fashion as it currently uses the internal GPSapi-supplied data. Beaconing and position awareness will then be support on non-GPS-equiped phones, PDAs, and laptops.

When a KISS port is configured, APRSISCE/32 reads KISS packets from the port and provides KISS packets to the port. Beacons, telemetry, and status updates are sent both out the APRS-IS connection AND to the KISS port (obviously with a configurable path). Received KISS packets are formatted and sent to APRS-IS proving a receive IGate capability. RF-received stations are noted in the scrolling station log with an * and a count of how many times the same packet was heard. A View filter allows seeing all RF-received stations, only those considered to be "local" (configurable hop limit), or "direct" (no used path components). A future version will support IGating message traffic from APRS-IS to the RF port provided that both are enabled and the destination station was "recently" heard "locally" or direct.

Now, all I have to get is my day-job's work caught up so I can put the finishing touches on the configuration of all of the described capability. I've been running it on my laptop for about 3 weeks now with a BlueTooth link to a GPS in another room and a TCP/IP connection to a comm-port KISS shim which is actually another BlueTooth link from my server to a BlueTooth to serial link directly connected to my IGate's TinyTrak4. And it works. KJ4ERJ-1 is the APRSIS32 using this KISS connection, however it's actively competing with my main KJ4ERJ-2 javAPRSSrvr.

Anyway, does that answer your question? I've got a fairly long row to hoe to define how this is all going to work, and it's actually the user-configuration of these options that I still haven't done yet.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


m6xsd <m6xsd@...>
 

Hi Lynn,

Your plans for COM port / NMEA implementation sound 'spot on', I can't wait to try it.
I normally run a Garmin eTrex Summit GPS hooked up to my HP iPaq HX2750 PDA (currently for moving map display), I just need to sort out a TNC to hook up to my radio & I should have an excellent mobile system.
Would it be possible to have the software revert to a 'static position' when GPS fix is lost(i.e when you enter a building). Ideally
the 'static position' would be easily selectable from pre-programmed points and have different icon (so it is obvious you are no longer mobile). This could also be useful when out climbing hills (SOTA & WOTA) because you could show you are at a summit (or other waypoint) without draining valuable GPS power (hopefully Julian will let us know if this is practical from the walkers point of view).


73,
Colin.

--- In aprsisce@yahoogroups.com, "Lynn W. Deffenbaugh" <kj4erj@...> wrote:

Jerome Lofton wrote:
Can you elaborate on your plans for KISS TNC for APRS and how it would
be used with APRS-IS CE.
I'm glad you asked! ;)

I have a version of the client running in development that allows
configuration of a "data source" for KISS TNCs and/or NMEA GPS. This
will be supported in both the Windows Mobile and Win32 when it is
released. By "data source" I mean either a serial port (which may be a
paired BlueTooth serial port) or a TCP/IP address and port combination.
This will allow APRSISCE/32 to connect either directly via serial, or
via BlueTooth serial (which looks the same to the program), or via a
TCP/IP stream to either a KISS-mode TNC or an NMEA-protocol external GPS.

When an NMEA port is used (which is mutually exclusive with the
currently support GPSapi-supported GPS), APRSISCE/32 gets position and
time information from the GPS and uses that in the same fashion as it
currently uses the internal GPSapi-supplied data. Beaconing and
position awareness will then be support on non-GPS-equiped phones, PDAs,
and laptops.

When a KISS port is configured, APRSISCE/32 reads KISS packets from the
port and provides KISS packets to the port. Beacons, telemetry, and
status updates are sent both out the APRS-IS connection AND to the KISS
port (obviously with a configurable path). Received KISS packets are
formatted and sent to APRS-IS proving a receive IGate capability.
RF-received stations are noted in the scrolling station log with an *
and a count of how many times the same packet was heard. A View filter
allows seeing all RF-received stations, only those considered to be
"local" (configurable hop limit), or "direct" (no used path
components). A future version will support IGating message traffic from
APRS-IS to the RF port provided that both are enabled and the
destination station was "recently" heard "locally" or direct.

Now, all I have to get is my day-job's work caught up so I can put the
finishing touches on the configuration of all of the described
capability. I've been running it on my laptop for about 3 weeks now
with a BlueTooth link to a GPS in another room and a TCP/IP connection
to a comm-port KISS shim which is actually another BlueTooth link from
my server to a BlueTooth to serial link directly connected to my IGate's
TinyTrak4. And it works. KJ4ERJ-1 is the APRSIS32 using this KISS
connection, however it's actively competing with my main KJ4ERJ-2
javAPRSSrvr.

Anyway, does that answer your question? I've got a fairly long row to
hoe to define how this is all going to work, and it's actually the
user-configuration of these options that I still haven't done yet.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


Phillip <zl2tze@...>
 

 Hi Lynn,
                 Is there any provision in your program to allow for more than 1 TNC port and also a beacon TXT file for each port
 
I ask this because not all Igates etc run 1 port, here I run 3 VHF ports on different frequencies and they all require their own Beacon TXT
 
73 Phillip
ZL2TZE
 
 
 
 


Lynn Deffenbaugh
 

Phillip wrote:


Is there any provision in your program to allow for more than 1 TNC port and also a beacon TXT file for each port
I ask this because not all Igates etc run 1 port, here I run 3 VHF ports on different frequencies and they all require their own Beacon TXT
Is that three different TNCs and three different serial connections? Or are you talking port numbers in AGEPE?

If you've got three TNCs, I'd plan to support this as running three copies of the client, one for each TNC.

However, that's all a much more complex installation than I'm currently targeting. Personally, with that much running, I'd be using javAPRSSrvr to do the IGating and just use a client like mine as a single viewer.

Lynn (D) - KJ4ERJ - Crawling before Walking before Running....


g4ilo
 

--- In aprsisce@yahoogroups.com, "Lynn W. Deffenbaugh" <kj4erj@...> wrote:
By "data source" I mean either a serial port (which may be a
paired BlueTooth serial port) or a TCP/IP address and port combination.
Does this mean it will work with the AGW Packet Engine on a PC? I don't know too much about this but it appears to run as a TCP/IP server listening on port 8000.

Julian, G4ILO


Lynn Deffenbaugh
 

m6xsd wrote:
Hi Lynn,

Your plans for COM port / NMEA implementation sound 'spot on', I can't wait to try it.
I normally run a Garmin eTrex Summit GPS hooked up to my HP iPaq HX2750 PDA (currently for moving map display), I just need to sort out a TNC to hook up to my radio & I should have an excellent mobile system.
Good to know it'll work for someone outside of me! I'm using a TT4 for testing and will be hooking it to a T2-135 as soon as I get a power supply for another BlueTooth to Serial in my mobile. I can't wait to run the mobile IGate!

Would it be possible to have the software revert to a 'static position' when GPS fix is lost(i.e when you enter a building). Ideally
the 'static position' would be easily selectable from pre-programmed points and have different icon (so it is obvious you are no longer mobile). This could also be useful when out climbing hills (SOTA & WOTA) because you could show you are at a summit (or other waypoint) without draining valuable GPS power (hopefully Julian will let us know if this is practical from the walkers point of view).
My current thinking was that when/if you disable the GPS but keep Tracking enabled, it would continue to beacon as if you were standing still at the last coordinate. I want to base it on Enabled rather than Lost Fix as it's way to easy to lose a fix.

I need to do more thinking on the hiking thing as well.

Lynn (D) - KJ4ERJ - Dashing out the door!


m6xsd <m6xsd@...>
 

--- In aprsisce@yahoogroups.com, "Lynn W. Deffenbaugh" <kj4erj@...> wrote:

Good to know it'll work for someone outside of me! I'm using a TT4 for
testing and will be hooking it to a T2-135 as soon as I get a power
supply for another BlueTooth to Serial in my mobile. I can't wait to
run the mobile IGate!
My other preferred installation is to swap out the Garmin for a Bluetooth GPS when I don't forsee needing the extra info the Garmin supplies.

Would it be possible to have the software revert to a 'static position' when GPS fix is lost(i.e when you enter a building). Ideally
the 'static position' would be easily selectable from pre-programmed points and have different icon (so it is obvious you are no longer mobile). This could also be useful when out climbing hills (SOTA & WOTA) because you could show you are at a summit (or other waypoint) without draining valuable GPS power (hopefully Julian will let us know if this is practical from the walkers point of view).
My current thinking was that when/if you disable the GPS but keep
Tracking enabled, it would continue to beacon as if you were standing
still at the last coordinate. I want to base it on Enabled rather than
Lost Fix as it's way to easy to lose a fix.

I need to do more thinking on the hiking thing as well.
Yep, point taken on 'Lost Fix' but I still think being able to select pre-programmed static points when 'en-route' would be good, I can think of quite a few situations where I would like to 'annouce'(for want of a better word) that I'm not exactly where my GPS thinks I am (or was).

73,
Colin.


g4ilo
 

--- In aprsisce@yahoogroups.com, "m6xsd" <m6xsd@...> wrote:

Hi Lynn,

Your plans for COM port / NMEA implementation sound 'spot on', I can't wait to try it.
I normally run a Garmin eTrex Summit GPS hooked up to my HP iPaq HX2750 PDA (currently for moving map display), I just need to sort out a TNC to hook up to my radio & I should have an excellent mobile system.
Would it be possible to have the software revert to a 'static position' when GPS fix is lost(i.e when you enter a building). Ideally
the 'static position' would be easily selectable from pre-programmed points and have different icon (so it is obvious you are no longer mobile). This could also be useful when out climbing hills (SOTA & WOTA) because you could show you are at a summit (or other waypoint) without draining valuable GPS power (hopefully Julian will let us know if this is practical from the walkers point of view).
Personally I think the last known position would be the best one to use when going into a building. Incidentally the last time this happened to me I forgot to turn the thing off when I went into a building and left my jacket and when I came back I had a hot phone with a depleted battery, so an auto-disable GPS if unable to get a fix after x min option might be a useful battery conservation tool.

The ability to easily select a different icon would be a nice touch though I don't know if many would bother with it. I'm using the icon of a jogger because that seemed the most appropriate for a pedestrian mobile, but I also have it with me in the car and people may get the idea I'm a pretty fast runner. It would be nice to switch to an icon of a car without opening the config dialog and scrolling through that long list. There could do with being an icon of a guy in a chair with his feet up for when the thing is docked in its cradle on the desktop. :)

I'm not sure how successful my earlier suggestion of an economy mode that only gets a fix now and then would be, because as Lynn pointed out the GPS will struggle to get a fix if you are moving. I have been trying to remember to disable the GPS (or switch the phone off with the button on the top which keeps the APRS-IS connection going so you can still receive messages) but I have been switching it on and then setting off without waiting to get a fix and as a result I have travelled long distances before my next position was reported.

Julian, G4ILO


Lynn Deffenbaugh
 

g4ilo wrote:
--- In aprsisce@yahoogroups.com, "Lynn W. Deffenbaugh" <kj4erj@...> wrote:
By "data source" I mean either a serial port (which may be a
paired BlueTooth serial port) or a TCP/IP address and port combination.
Does this mean it will work with the AGW Packet Engine on a PC? I don't know too much about this but it appears to run as a TCP/IP server listening on port 8000.
I have AGWPE support on my list, but that's not the IP/port that I mention above. There are Ethernet and WiFi serial port devices that offer a TCP/IP port to which you connect to access the serial data. I have also written similar shim programs that run on other machines and offer a TCP/IP connection to serial ports on those machines. The support I'm currently building expects the TCP data to appear just as if the serial device was locally connected. AGEPE adds a whole different protocol layer to the "TNC" communications.

AGW support will be there eventually, but not soonest.

Lynn (D) - KJ4ERJ


Lynn Deffenbaugh
 

g4ilo wrote:
Personally I think the last known position would be the best one to use when going into a building. Incidentally the last time this happened to me I forgot to turn the thing off when I went into a building and left my jacket and when I came back I had a hot phone with a depleted battery, so an auto-disable GPS if unable to get a fix after x min option might be a useful battery conservation tool.
That's maybe a reasonable suggestion. How long to make the delay before auto-disable is the hard part. I know with my AT&T Tilt the GPS will sometimes go out to la-la land for a few minutes when the visible satellite count drops to small numbers. I'll add this somewhere down on the ToDo list.

The ability to easily select a different icon would be a nice touch though I don't know if many would bother with it. I'm using the icon of a jogger because that seemed the most appropriate for a pedestrian mobile, but I also have it with me in the car and people may get the idea I'm a pretty fast runner. It would be nice to switch to an icon of a car without opening the config dialog and scrolling through that long list. There could do with being an icon of a guy in a chair with his feet up for when the thing is docked in its cradle on the desktop. :)
I've considered doing some sort of a named Profile set of settings that would include beaconing, Icon, status, and such. I don't know that I'll get as fancy as doing automatic profile switching ala the Tracker2 family, but at least having a Configure/Profile cascading menu selection might be nice. Hiking, Biking, Mobile, QTH/Stationary kind of settings where the user configures the names AND the parameters.

I'm not sure how successful my earlier suggestion of an economy mode that only gets a fix now and then would be, because as Lynn pointed out the GPS will struggle to get a fix if you are moving. I have been trying to remember to disable the GPS (or switch the phone off with the button on the top which keeps the APRS-IS connection going so you can still receive messages) but I have been switching it on and then setting off without waiting to get a fix and as a result I have travelled long distances before my next position was reported.
Yep, that's the GPS behavior. Those really quick fix times the manufacturers like to advertise are for fix acquisition without moving or at most walking. If you turn on the GPS, drop it on the dash, and dash on down the road, it'll be a while till it figures out where you really are. I've taken to backing out my driveway and turning the GPS on while I record my mileage (yes, most of what I drive, I get reimbursed for). But then, I live on a cul-de-sac, so I don't have to worry much about traffic while sitting in the middle of the street!

Economy mode still intrigues me because my GPS will pick up a fix pretty quick at walking speeds. It's trying to use economy mode while driving that would get rather iffy. Maybe an economy mode that disables itself if the prevailing speed is greater than some reasonable threshhold...

Lynn (D) - KJ4ERJ - QTH at KJ4ERJ-2


Lynn Deffenbaugh
 

m6xsd wrote:
Yep, point taken on 'Lost Fix' but I still think being able to select pre-programmed static points when 'en-route' would be good, I can think of quite a few situations where I would like to 'annouce'(for want of a better word) that I'm not exactly where my GPS thinks I am (or was).
See Bob's APRS 1.1 extension called "Destination Waypoints" described at:

http://wa8lmf.net/bruninga/APRS-docs/MOBILE.TXT

This is part of the APRS 1.1 Spec Addendum you can see at:

http://wa8lmf.net/bruninga/aprs/aprs11.html

I'm considering supporting the ability to beacon a "destination
waypoint" as well as interpret them and draw the lines that are
described. I don't know how many other APRS clients do this, but it's
part of the published spec, so I might as well support it! Who knows, I
might even make it part of the Poll's () "slow beacon" mode!

Oh, and another preview of things to come is that I'm designing a
"coordinate picker" dialog that will embed the OpenStreetMap with pan
and zoom to allow you to home in on and set a coordinate. It'll still
support a variety of manually-entered coordinates, but you'll be able to
see where you entered or enter what you see. - Thoughts?

Lynn (D) - KJ4ERJ