APRS Packet Howto
Joe KI7WV
experience squirting packets out of wview using Ham Radio. No
responders. I know that there are a lot of wview installs in remote
places, and perhaps you are in the same situation like me where
a) you have a station;
b) you have dsl;
c) the dsl goes out when the power goes out and
d) you still want to know what the weather (both outdoors AND indoors
is at your station.
Ham Radio is the way to get the data out- using a 144 mHz transciever,
a digital communications packet is sent every 15 minutes to CWOP and
finds its way to MesoWest etc. Getting an amateur license is no
longer such a formidable process, no Morse Code is required any
longer, and it is a multiple choice test.
Most of us transmit these packets through the internet, and when our
IP goes down, so does the weather report. However, if ham radio is
used, the packets would continue to flow.
Has anyone either configured, or could suggest the general direction
to proceed, with a script to extract the CWOP information from the
WVIEW db, formpat a properly constructed APRS packet, and connect to a
TNC to transmit the data?
Any suggestions would be appreciated. Just getting the hardware
together to do this.
Thanks
Joe KI7WV
jmiller at eyes dot arizona dot edu
Jim
For some reason, I hadn't realized that wview didn't have APRS
support. I am saving my pennies now to buy a weather station, at
which point my intent was to use amateur radio as my primary means of
disseminating weather data.
Out here, we also have a special application: We're in farming
country, and there are many areas that have no wires to them at
all...But it would be nice to get some weather data. Thus, with a bit
of solar power, a weather station, a small embedded device and a
radio, that information can be transmitted out and eventually (well,
within a minute) make it into MesoWest and such. Furthermore, for all
other hams in the area, the weather info will show up on their maps.
In case of emergency events (out here, weather emergencies are our
most likely emergencies), this helps emergency responders and planners
as well as local citizens. And anyone can decode and display the
weather data regardless of licensing...You only need a license to
transmit.
So yes, I'm very interested in getting APRS output to work. I'm not
sure how best to go about it, though. It seems that the cwopd would
be a logical choice for modifying it to support APRS. On linux, if
the native AX.25 stack is used, then it should't be that big of a deal
to generate the correct network packet and route it out the proper
interface.
Has anyone already done this?
--Jim
Gerald Creager
passcode) or a CWOP ID, it'll get to MesoWest. Joining CWOP makes real
good sense for what you want to do, and provides data to NWS and folks
like me who use the various surface observations to improve numerical
weather prediction models.
I run the CWOP servers, and first.aprs.net. If I can help, let me know.
gerry N5JXS
>
> You received this message because you are subscribed to the Google Groups "wview" group.
> To post to this group, send email to wv...@googlegroups.com.
> To unsubscribe from this group, send email to wview+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/wview?hl=en.
>
>
Warren Gill
http://ka1fsb.home.att.net/amprnet.html
http://www.linuxjournal.com/article/2218
\\'9
Jim
ampr network, and that solution would NOT be compatible with APRS
systems (whereas getting a successful APRS packet out there should
automatically get it into CWOP and others, if I understand
correctly). Furthermore, many modern ham radios have the capability
to receive and decode the APRS packets internally, so someone
somewhere with a handheld could get the latest weather observations
nearby; that's not the case if IP / AMPR net is used.
Finally, there's efficiency. The APRS beacon would result in a single
transmission/packet that would get the data out. Using AMPR would
take several to do all the negotiation to get an IP session going,
then probably still take a couple IP packets, as all the added headers
and the relatively small packet size hinder things there.
Oh, and did I mention that most areas do NOT have internet
connectivity via AMPR net? Without that, the data would never make it
into CWOP/MesoWest/etc.
--Jim
On Dec 15, 11:35 am, Warren Gill <mymaes...@gmail.com> wrote:
> I'm no expert in this area, but I would think you do not need to change
> wview at all. You would just interface your Linux box to the ampr network,
> for example, configure wview just as you would normally, and route your
> TCP/IP traffic (at the OS level with appropriate "route" commands) using the
> 44 network as a gateway.
>
>
> \\'9
Jim
parent's station in Ridgecrest, CA does do cwop sending (and has for
~5 years now).
The issues I was raising was for areas in the "middle of nowhere"
where there isn't any internet (unless you subscribe to hughesNet
(satellite Internet) at $50/month just to send some cwop packets.
Conversely, if they set it up with APRS, it goes out via radio,
hitting a slightly larger audience with more relevance, and still
makes it into MesoWest and CWOP (I think), assuming its iGated
somewhere (which around here, and through much/most of the US it is).
So to me, the question comes down to how similar is the CWOP protocol
to APRS beacons...I'm hoping it wouldn't be too bad to modify cwopd to
send APRS beacons out, and get stuff out that way...or perhaps set
both cwopd (normal) and aprs (radio) up so it goes out both ways where
Internet is available (eg, my house).
--Jim
Joe KI7WV
Your understanding parallels mine; that when we use a tcp/ip
connection to send packets to CWOP, the format of the packet and the
addressing is different when an APRS beacon is transmitted.
There are two basic mechanisms to send the APRS beacon- dumb and
dumber. If you are using a 386 class computer with a sound card, then
the sound card can be configured to generate the FSK audio that goes
into the two meter ham radio microphone input (typically using a
device called a "Rigblaster"). The even simpler approach, for use
with something like the Sheeva or Slug, is a device called a TNC
(terminal node controller) that takes rs-232 at 1200 baud and
generates the modem tones (in the absence of the sound card).
The process in theory is pretty simple- you are sending a beacon (a
connectionless type of communication, no confirmation, no handshake).
So when it is time to transmit, the packet is assembled and either
sent out a serial port or sent to a process that drives the sound
card.
Please send me an email at jmiller at eyes dot arizona dot edu if you
would like to help debug etc. This is a much better approach than
dedicated dsl line in my opinion. Out here in the west, there are
mountaintop repeaters that make many areas accessable to packet radio.
I am at the bottom of the learning curve at the present, so practical
suggestions would be most welcome. I am not even sure I will hit our
repeater from my cabin- the repeater is only a mile away, but there
are two 200 ft hills between me and it, so it will be via diffraction
or reflection. RE the "how to aprs wview" - specific directions must
be established early on and suggestions of experienced individuals
would be appreciated.
?? - modify the CWOP process, or
?? - develop a script becomes a cron process, reads the sql database
every 15 minutes, extracts the data, and pops it out the serial port
or sound interface to the two meter transmitter
Thanks again.
Joe
Mark S. Teel
solutions. I'm not sure I have my arms around it all yet... so wview
needs to send APRS packets (the format for CWOP also) out a serial port
or transmit laser beams or what? I think wview already supports Ham call
signs...
Mark
Gerald Creager
However, I may have a little time to look at wview and see how easy it'd
be to take the data it generates, and produce a KISS-compatible packet
stream. I'll have to think about that, but it should be do-able.
An alternative is to also capture the data from the weather station via
xastir and let xastir provide the data to the RF side.
gerry
Gerald Creager
Joe KI7WV wrote:
> Jim et al,
>
> Your understanding parallels mine; that when we use a tcp/ip
> connection to send packets to CWOP, the format of the packet and the
> addressing is different when an APRS beacon is transmitted.
confirm this tonight, but that's what I'm seeing. CWOP accepts ALL data
in APRS-WX protocol, which has proven a little limiting, since APRS
didn't recognize standard meteorological precision when it was cobbled
together...
> There are two basic mechanisms to send the APRS beacon- dumb and
> dumber. If you are using a 386 class computer with a sound card, then
> the sound card can be configured to generate the FSK audio that goes
> into the two meter ham radio microphone input (typically using a
> device called a "Rigblaster"). The even simpler approach, for use
> with something like the Sheeva or Slug, is a device called a TNC
> (terminal node controller) that takes rs-232 at 1200 baud and
> generates the modem tones (in the absence of the sound card).
> The process in theory is pretty simple- you are sending a beacon (a
> connectionless type of communication, no confirmation, no handshake).
> So when it is time to transmit, the packet is assembled and either
> sent out a serial port or sent to a process that drives the sound
> card.
>
> Please send me an email at jmiller at eyes dot arizona dot edu if you
> would like to help debug etc. This is a much better approach than
> dedicated dsl line in my opinion. Out here in the west, there are
> mountaintop repeaters that make many areas accessable to packet radio.
>
> I am at the bottom of the learning curve at the present, so practical
> suggestions would be most welcome. I am not even sure I will hit our
> repeater from my cabin- the repeater is only a mile away, but there
> are two 200 ft hills between me and it, so it will be via diffraction
> or reflection. RE the "how to aprs wview" - specific directions must
> be established early on and suggestions of experienced individuals
> would be appreciated.
>
> ?? - modify the CWOP process, or
> ?? - develop a script becomes a cron process, reads the sql database
> every 15 minutes, extracts the data, and pops it out the serial port
> or sound interface to the two meter transmitter
processing that'd be some subset of the timing for the
directly-connected timing. Where we encourage updates, now, as
frequently as every 5 min on CWOP, the APRS folk tend to get up in arms
if someone sends weather more often than twice/hour. If your station is
available via RF and DSL/Cable/ethernet, send it both ways: Your local
RF reports help the community, and we still want your data in CWOP at
the higher frequency!
gerry
Jim
My main questions was the formatting of the data between CWOP and
APRS; it sounds like they're basically the same. This is good, it may
mean very little modification to wview.
First, I'd like to make some points AGAINST doing an SQL scraper/
transmitter as was initially suggested. WView is already well-
implemented with a message passing system that is designed to let
modular programs know when there's a weather update or when they need
to do something, and even provide easy access to the data. This is an
example of good software engineering.
Making a program that has no knowledge of what wview is doing, and
just wakes up periodically and reads the last entry on a database
modified by another process is an example of sub-optimal software
engineering. Moreover, cwop already does 90% of what we need, so why
re-implement it?
That said, here's how I understand the sate of things. I divide this
problem into two portions:
1) generating the data packet
2) getting the data packet transmitted
For #1, it sounds like CWOP format is actually the APRS format, so it
already does it. I would suggest adding a means of configuring a
second timer for how often to send, as APRS weather data is usually
sent once every 30 minutes (although of someone is feeling creative,
they could set it up so that it watches for some weather parameters
(alarms?) that indicate a "weather event" is happening and send more
frequently until the conclusion of the event. This is in no means a
requirement, though). There probably also needs to be a few more
settings to support this, as Gerry said, CWOP should continue to
receive its reports via the internet as it already does, but either
the same CWOP or a second copy of CWOPd needs to be configured on a
different set of timers with some additional parameters. The specific
list needs to be hammered out some more.
For #2, there are many, many ways of doing this. I believe that wview
should NOT be concerned with actual radio control, creating the
soundcard modulation, or possibly not even doing raw KISS...There are
kernel implementations to support all this already. As such, I think
there are two potential modes that wview should support: working with
xistir (the main linux APRS application), and working with the linux
kernel AX.25 package. For now, I think we should focus on just
Xistir, as this looks like it is the easiest and most immediately
useful. The linux AX.25 stack would be more useful in embedded
applications located out in the middle of nowhere, so it should still
be pursued. At the moment, I also have more questions about this.
For integration into Xistir, it looks like it would be really easy:
Just send a UDP packet with the APRS-formatted packet (that cwop
already does) to xistir's udp server port. Here some more info:http://
www.xastir.org/wiki/index.php/Server_Port
I have some contacts with Xistir devs that I believe will get a very
rapid turnaround and assistance as necessary. Does this sound like a
doable project? Are there people interested/willing/able to work on
this?
--Jim, K7LL
Graham Eddy
internet-interfaced solution, i have no intentions of operating a radio
clearly the aprs stuff should be encapsulated in a dataFeedClient (from
wview's point of view). it would spool data from wvalarmd, summarise it,
and despool to the aprs interfaces. two aprs interfaces to support, one
ax.25 into radio and the other via iGate (?) into internet
------------------------------------------------------------------------
*Graham Eddy*
Gerry Creager
I'm not so sure this is correct. In fact, the APRS observation should
be an observation, and not a summary of obs. The decision to put it on
RF or internet directly should be independent (two interfaces). Right
now, I insert my AP009 CWOP data into the internet as N5JXS, and it goes
into the APRS-IS. Any local iGate looking for local weather will see it
and gate it back out. If you want the data to go to CWOP (and CWOP,
data-hungry grubbers that we are, wants both US and international
surface obs; they're all valuable) at whatever frequency we can get
them, currently up to every 5 minutes, then by using a CWOP server on
internet the data are not available on APRS-IS foriGating back to the RF
side, so you would want to have another interface to RF. This wouldn't
confuse the system as we'd see it as a duplicate observation and it'd
not be a problem when it got to CWOP.
However, I'm not sure it needs to be spooled and summarized. You just
want to catch the latest observation when it's time for the RF output
(which, I concede, has some summarized data [rainfall accumulation, wind
averaging]) and send it out.
Am I missing something here?
gerry
Joe KI7WV
Gerry, Graham, Jim-
I don't think you are missing anything, but there is clear confusion
between the connectionless APRS beacon and the connected reporting
that is done by many wview CWOP users.
A tightly integrated implementation, say named aprs-wx derived from
cwop wview module, is without a doubt the more elegant solution, but
would increase the maintenance load on Mark Teel. Scraping, though
inelegant, has the advantage of not adding another module with need
for continued care. Of course, if the db structure changes, oops it
is now broken!
A final observation- I suspect that once people realize that they
might be able to drop the cost of a dedicated DSL connection by buying
a couple hundred dollars worth of radio gear on a one-time basis, APRS-
Wx may prove to be more popular, For example, Argent Data Systems
sells a software defined radio and TNC that reportedly directly
connects to the Davis Vantage Pro to send APRS weather beacons. If
there is a reference platform that people know will work, perhaps more
will take the plunge to get licensed and delve into the digital modes
of radio communication.
I appreciate the discussion!
TN_Yankee
related to the issue: does wview now support the CWOP/ham callsign
password to properly access APRS servers? From discussions here back
in July '08, it didn't. I've recently upgraded to 5.8, and the
question has come back up again.
Thanks!
mike
Gerry Creager
That's the point I tried to make: CWOP is well-supported. And therefore,
APRS protocol via Internet is. Now it's a matter of talking to the RF side.
gerry
tom.h...@gmail.com
I'm not quite up on the Ham side, but considering what Wview is
already doing, here's a thought...
Can this be supported similar to AWEKAS? A .htx template gets read and
creates, say, "aprsbeacon.txt" during the html runs (so probably every
5 minutes); then (perhaps via the alarm system?) every half-hour a
script runs that sends the actual data?
Something like a wvaprs module that directly calls ax.25 would be
easier from a user's point of view, but would involve coding and
integration; generating your own template in wview is simple, and a
one-line script (called via alarm or timer or whatever) would be
portable outside of wview, as well. I know of a few locations that I'd
like to use something like this to support...
Gerry Creager
OK, so my hidden agenda must rear its head. First, I think making a WV
module that reads the database and ships the data to libax25 would be
straightforward.
Second, there are several Real Big Holes in the APRS-Wx spec. When
written, they let neither a meteorologist, nor a metrologist work with
them, so units, precision and required accuracy are not as specific as
they could/should be.
Enter a next-generation spec: Open Geospatial Consortium's Sensor Web
Enablement tools. XML based, allows decent metadata streams, etc. I'm
trying to get time to write the client and server sides, but most of the
work's done and cookbooks are available for this in perl, java and I
think, python. Similar coding in C with those templaces and the libxml
tools in existence should be simple.
I'll try to generate a core CWOP sensorML schema next week. I should
have it cold, but I need to look at some new documentation that's come out.
gerry
Jim
parent's wview/Davis Vantage Pro weather station, and reading more on
CWOP, I think I have a good "first step" to take, that I think will
also be quite beneficial.
According to:
http://www.wxqa.com/servers2use.html
licensed amateur radio operators can/should use their callsign, and
they should publish to the main APRS internet webservers. This is
good for several reasons, as it will show up on aprs.fi and other map-
based aprs reporting systems. It also allows for the possibility of
being gated to the radio side by an iGate if one is configured to do
so. In addition, it will get to the CWOP databases, mesowest, etc.
As I understand it, the protocol is exactly the same as the CWOP
servers except for the requirement of a validation code (a password of
sorts). Presently, wview does not support that to the best of my
knowledge. If it were to, that would allow my station(s) and others
to gate directly into the "ham side" of the aprs/cwop internet system.
I believe its also possible for someone to run their own igate on
their local network, accepting connections directly in the aprs
standard format (the one needed above), and gating it out to the radio
world.
In short, I think this mod should be very simple, and yet actually
accomplish a lot of potential usability for the Hams (and allow us to
fully/correctly follow the CWOP instructions).
Thoughts?
--Jim, K7LL (administering K6YG for my dad, currently online)
Mark S. Teel
generation using an algorithm supplied by Gerry Creager. If the
callsign is NOT of the form CWXXX or DWXXX (CWOP only) it will generate
and insert the password in the packet. I'm not sure if anyone has
confirmed that it works properly; I have asked the hams several times
with no feedback.
Mark
Joe KI7WV
First, THANK YOU for work that went into making upgrading so easy. I
just used the procedures for debian lenny apt and it was the easiest,
smoothest upgrade yet.
Second, I am one of the hams with a call sign that uses cwop but has
not gotten back to you. I contacted Russ Chadwick (ru...@wxqa.com)
with my call sign, and he cent me a 5 digit number to use as my
validation code. I recall reading somewhere that this 5 digit number
is placed into the packet instead of a -1 but cannot find the
reference. When I go to the wviewmgmt configuration page for cwop I
do not see a place to enter this 5 digit number.
Can you help further with your above reference where you say "if the
call sign is not of the forrm cwxxx or dwxxx it will generate and
insert the password into the packet".
Does this mean that you somehow generate the 5 digit number that Russ
Chadwick gave me and all I do is enter my ham call sign?
This might be part of the confusion.
Thanks
Joe KI7WV
Mark S. Teel
Yes, that is my understanding. There is a generation algorithm that uses
the callsign as input and outputs the password.
Mark
bgrattan
The callsign/password generation seems to work fine for me according
to the data received by CWOP. Thanks.
Bob N4MRV-1
On Dec 27, 10:19 pm, "Mark S. Teel" <mteel2...@gmail.com> wrote:
> Joe,
>
> Yes, that is my understanding. There is a generation algorithm that uses
> the callsign as input and outputs the password.
>
> Mark
>
>
>
> Joe KI7WV wrote:
> > Dear Mark,
>
> > First, THANK YOU for work that went into making upgrading so easy. I
> > just used the procedures for debian lenny apt and it was the easiest,
> > smoothest upgrade yet.
>
> > Second, I am one of the hams with a call sign that uses cwop but has
> > not gotten back to you. I contacted Russ Chadwick (r...@wxqa.com)
> > with my call sign, and he cent me a 5 digit number to use as my
> > validation code. I recall reading somewhere that this 5 digit number
> > is placed into the packet instead of a -1 but cannot find the
> > reference. When I go to the wviewmgmt configuration page for cwop I
> > do not see a place to enter this 5 digit number.
>
> > Can you help further with your above reference where you say "if the
> > call sign is not of the forrm cwxxx or dwxxx it will generate and
> > insert the password into the packet".
>
> > Does this mean that you somehow generate the 5 digit number that Russ
> > Chadwick gave me and all I do is enter my ham call sign?
>
> > This might be part of the confusion.
>
> > Thanks
>
> > Joe KI7WV
>
> > --
>
> > You received this message because you are subscribed to the Google Groups "wview" group.
> > To post to this group, send email to wv...@googlegroups.com.
> > To unsubscribe from this group, send email to wview+un...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/wview?hl=en.- Hide quoted text -
>
> - Show quoted text -
Jim
I tried it, and it did work. You can go to:
And search for k6yg, you'll find our weather station now showing up.
Only authenticated ham calls running through the aprs servers will
show up on the aprs.fi maps.
That brings me to a couple more quick and easy questions:
1)what interval does the cwop packets get sent? (I could look through
my logs, except I turned all this logging off to save write cycles on
my sheeva).
2) when wview/cwop send a packet, does it send (mostly) simultaneously
to all 3 servers, or just one of the list? (If just one, how does it
choose?)
My thoughts are:
If it sends to all servers more or less simultaneously, then one could
use the aprs internet servers for two of them, and their own internal
igate for the 3rd. Presently, there would have to be an intermediate
filter to reduce transmissions to once every 30 min or so, but that
would allow a ham to transmit frequently via the internet (as the CWOP
program preferrs), and less frequently over the radio (as aprs-radio
good operating procedures requires). Of course, I haven't played with
igating at all, so I don't know for sure what it would take to
implement the radio gateway. However, I do plan to acquire a davis
weather station for my home, where I'll begin experimenting with a
local APRS guru and xistir dev.
Thanks for the awesome wview software!
--Jim, K7LL
Mark S. Teel
Jim wrote:
> Thank you, that's great!
>
> I tried it, and it did work. You can go to:
>
> http://aprs.fi
>
> And search for k6yg, you'll find our weather station now showing up.
> Only authenticated ham calls running through the aprs servers will
> show up on the aprs.fi maps.
>
> That brings me to a couple more quick and easy questions:
> 1)what interval does the cwop packets get sent? (I could look through
> my logs, except I turned all this logging off to save write cycles on
> my sheeva).
>
[MST] Per CWOP requirements implemented about a year ago, the
recommended frequency is every 10 minutes. The submission minute of each
10 minute period is the last digit of the callsign. I.e., my CWOP sign
is CW4097 so my CWOP submissions are done at :07, :17, :27,... I did
something similar for the ham callsigns.
This process will need to change somewhat for RF transmissions. Again,
once this has all crystallized into a concise set of new requirements
for wview, I'll be happy to "make it so".
> 2) when wview/cwop send a packet, does it send (mostly) simultaneously
> to all 3 servers, or just one of the list? (If just one, how does it
> choose?)
>
[MST] Again per CWOP requirements, wview allows configuration of 3 APRS
server/port pairs. It will try them one at a time until a successful
packet transmission occurs, at which point it is done until the next
submission time. The current requirement is for one and only one
submission. There will need to be a new way to specify one or more
alternate destinations in addition to the CWOP transmission. The
secondary and tertiary servers are for failover use only at this point.
> My thoughts are:
> If it sends to all servers more or less simultaneously, then one could
> use the aprs internet servers for two of them, and their own internal
> igate for the 3rd. Presently, there would have to be an intermediate
> filter to reduce transmissions to once every 30 min or so, but that
> would allow a ham to transmit frequently via the internet (as the CWOP
> program preferrs), and less frequently over the radio (as aprs-radio
> good operating procedures requires). Of course, I haven't played with
> igating at all, so I don't know for sure what it would take to
> implement the radio gateway. However, I do plan to acquire a davis
> weather station for my home, where I'll begin experimenting with a
> local APRS guru and xistir dev.
>
> Thanks for the awesome wview software!
>
[MST] My pleasure! It is finally rounding into an easy to use
application now that the debian APT install/upgrade support is there.
Gerald Creager
for inputing ham weather reports via the APRS servers is so they can be
gated back to RF. APRS-FI is not a consideration in the operation of
CWOP or APRS servers.
Mark, you and I conversed awhile back on the use of the callpass code
for generating a passcode for amateur callsigns. I can work with you on
the logic for the callsigns, but it's sorta random worldwide, overall.
gerry
CWOP servers
FIRST.aprs.net
Joe KI7WV
After doing a bit of reading and spending (about $350), I have a
packet station up and running at www.pocomas.net.
The equipment I selected as my starter setup is
TNC-X with USB http://www.tnc-x.com/
Yaesu FT-60R Dual Band Handheld (This is a VERY popular rig: I
purchased mine from Ham Radio Outlet)
I ran into two snags:
First, a strange 4 conductor 3.5 mm plug is required for the TNC-FT60
connection on the Yaseu end, and the documentation for the pinout was
sparse. A Sony Camcorder to Video / Audio RCA cable that comes with
the camcorder was available and used. I will post the interconnect
cable if anyone is interested.
Second, the FT-60 cannot be left permanently plugged into the charger
or it will cook the Li battery. It will operate on low power off the
supplied wall wart but not high power. As I am in a valley a mile
from the Mt Lemmon repeater this is not an issue for me, but it could
be for someone else. If you are a considerable distance from an APRS
gateway, you would be better to select a mobile radio that runs off 12
volts and has high power (50 watts is typical).
The TNC is now USB connected to my Debian server and I am about to
delve into getting some packets in/out when I head back down the
mountain. I tested everything worked with some windows software.
However, for this to be useful for the WVIEW communnity, it obviously
will require both integration within wview and installation of
additional software.
If there are current WVIEW uses who have packet experience using
Debian, would you please reply off line to jmiller at eyes dot arizona
dot edu? I promise to put together a Packet Howto once the data
flows.
Thanks
Joe KI7WV