Date   
#audio #audio

Todd
 

I had audio working ok for both Fldigi and Js8Call. Somehow or reason today I noticed no receive on either program. Anybody have any suggestions?
THX
Todd
AL7PX

Kenwood TM-281a Cable

Steve McGrane <temporarilyoffline@...>
 

I'm looking to make a cable for my 281 so I can get APRS up and running. 

Here are my thoughts:

DIN PIN   Purpose Radio PIN
1         AFIN     6               
2         GND      5 
3         PTT      4               
4         DISCOUT  N/C               
5         AFOUT    Rear Speaker Ring
6         SQL      N/C

Kenwood Mic Cable:
image.png

How does that look to yous guys?

- Steve, KM9G

Re: How do I change the AGW from Channel 0 to Channel 1 #udrc-ii #direwolf

TG9AOR
 

Basil, thank you very much for your reply. I will try with XASTIR. I was not successful with APRSICE32.


73 de TG9AOR

Xastir/gpsd Update #draws #gpsd #config #xastir

 

The problem with Xastir accessing gpsd for position data has been identified and a patch has been tested and merged into the Xastir master source on GitHUB.

Thanks to Tom Russo of the Xastir team and Basil from NW Digital Radio for working through this issue.

A install update for the beta images will take a few days to produce.

Thanks to all involved.

Re: xastir not passing GPS data via GPSD #draws #gpsd #config #xastir

Basil Gunn
 

Will the DRAWS image be updated with the working version of Xastir?
Yes. I will probably spin up yet another image to accommodate the new
Xastir build.

What must one do to update the version currently running on DRAWS?
Previously Xastir was installed from a Debian package. It is clear that
besides fixing a problem with parsing the DRAWS GPS sentences the latest
version of Xastir is a much better way to go. Xastir will be another ham
program that will be built from source and will be part of the
prog_refresh.sh script that I use to keep the image master up-to-date.

Thanks for your (rapid) research and help!
That should be directed at Tom Russo KM5VY.
Also I had some behind the scenes emails with Curt Mills WE7U that
helped clarify some things for me.

Edd - KD5M

Re: xastir not passing GPS data via GPSD #draws #gpsd #config #xastir

Edward Seeliger
 

Will the DRAWS image be updated with the working version of Xastir?
What must one do to update the version currently running on DRAWS?
Thanks for your (rapid) research and help!
Edd - KD5M

Re: DRAWS + FT-891 + WSJT-X/FT8

Steve McGrane <temporarilyoffline@...>
 

Did some more testing and here are my results.  See below for an individual response to the very helpful suggestions that have come in so far.

I have not been able to get any messages out via FT8 on any setup today.  We are in the middle of a pretty big snow storm.  I am receiving fine, but can't get through the storm.

Something new I noticed is that on the linux+signalink setup I am hearing through the radio the FT8 transmit.  On DRAWS I hear nothing.  No changes to the radio in either situation.

August's Notes:

I have the Data In menu setting setup for REAR instead of MIC. (JC mentions this in a future email as well)

John Hays' Notes:

Ambient Shack Noise = Noises that I make in the shack, knocking on the workbench, speaking loud enough , etc.  This is coming from the handheld mic.  Turns out the mic has always been "hot" even on the old config.  Never noticed it as I never had a reason to before.

No shack noise when the mic is unplugged.
   
John Chablako's Notes:

Menu 08-09 is already set to REAR

I am using Input:

plughw:CARD=udrc,DEV=0
Output: plughw:CARD=udrc,DEV=0

But in left setting per John Hays

Julian's Notes:

Pin 6 is pulled.  Once I get this working, I'll have no way to verify if this was the fix or not.  I'm in the process of making up a cable for the Kenwood TM-281 to test out APRS from the Right MiniDIN port.

Thanks and looking forward to the next round of testing!

On Thu, Apr 11, 2019 at 11:47 AM art upton via Groups.Io <artupton=yahoo.com@groups.io> wrote:
<Quoting:Corky Searls --- Steve, pulling pin 6 is a requirement for any Yaesu radio as the radio treats this as an input and will do nothing.>

FYI  I got my FT-891 working months ago in the first shipments without pulling Pin 6. I sent my Alsa settings to others so they could get theirs working in the very early beta images.
Is there something now in the newer images that made the software work this pin that was not there before?

Seems I need to update my image and check and see.....

Re: xastir not passing GPS data via GPSD #draws #gpsd #config #xastir

 

Good research and hopefully the fix proves solid over time.

On Thu, Apr 11, 2019 at 11:16 AM Basil Gunn <basil@...> wrote:

Update from testing a fix provided by Tom Russo.

The code change for Xastir provided in Tom's "feature-supportglonass"
branch appears to fix the problem of DRAWS gps not working in Xastir. I
am continuing to run this version but everything looks OK.

A statement by Tom explaining the problem follows:

> I think I see exactly what the issue is here.  I am now reading the
> S1216F8-GL documentation at www.skytraq.com.tw/datasheet/S1216V8_v0.9.pdf
> more clearly, and realize that the table of NMEA sentences it supports is
> very different than the other devices documented in the same PDF.  That is, it
> does NOT produce GPGGA and GPRMC sentences, it instead outputs GNGGA and GNRMC
> sentences.
>
> And Xastir doesn't even look at those.

A big thank you to Tom for sleuthing this problem.

/Basil n7nix

Tom Russo <russo@...> writes:

> From the sound of it, since Xastir won't accept the data from DRAWS even
> when reading directly from the serial port, there is something about the NMEA
> sentences that the DRAWS hat is sending that Xastir is not understanding, with
> or without GPSD.  So the very first thing to look at is what those sentences
> are and why they're not being recognized.  Hopefully, capturing the raw serial
> stream for a little while will shed some light on that.
>
> Xastir ignores ALL NMEA strings except GPRMC and GPGGA --- those two contain
> all the information Xastir ever needs.  If DRAWS is sending those and Xastir
> isn't recognizing them, it should be straightforward to figure out why once
> we see what they look like. 
>
> I'm looking at the spec sheet for the s1216f8-gl now, and from what I see
> the GGA sentences and RMC sentences the docs say it sends should be
> completely recognizable by the code in gps.c that is supposed to decode them.
> So this is certainly a puzzle I'm keen to understand.


--


John D. Hays
Edmonds, WA
K7VE

   

Re: xastir not passing GPS data via GPSD #draws #gpsd #config #xastir

Basil Gunn
 

Update from testing a fix provided by Tom Russo.

The code change for Xastir provided in Tom's "feature-supportglonass"
branch appears to fix the problem of DRAWS gps not working in Xastir. I
am continuing to run this version but everything looks OK.

A statement by Tom explaining the problem follows:

I think I see exactly what the issue is here. I am now reading the
S1216F8-GL documentation at www.skytraq.com.tw/datasheet/S1216V8_v0.9.pdf
more clearly, and realize that the table of NMEA sentences it supports is
very different than the other devices documented in the same PDF. That is, it
does NOT produce GPGGA and GPRMC sentences, it instead outputs GNGGA and GNRMC
sentences.

And Xastir doesn't even look at those.
A big thank you to Tom for sleuthing this problem.

/Basil n7nix

Tom Russo <russo@...> writes:

From the sound of it, since Xastir won't accept the data from DRAWS even
when reading directly from the serial port, there is something about the NMEA
sentences that the DRAWS hat is sending that Xastir is not understanding, with
or without GPSD. So the very first thing to look at is what those sentences
are and why they're not being recognized. Hopefully, capturing the raw serial
stream for a little while will shed some light on that.

Xastir ignores ALL NMEA strings except GPRMC and GPGGA --- those two contain
all the information Xastir ever needs. If DRAWS is sending those and Xastir
isn't recognizing them, it should be straightforward to figure out why once
we see what they look like.

I'm looking at the spec sheet for the s1216f8-gl now, and from what I see
the GGA sentences and RMC sentences the docs say it sends should be
completely recognizable by the code in gps.c that is supposed to decode them.
So this is certainly a puzzle I'm keen to understand.

Re: DRAWS + FT-891 + WSJT-X/FT8

art upton <artupton@...>
 

<Quoting:Corky Searls --- Steve, pulling pin 6 is a requirement for any Yaesu radio as the radio treats this as an input and will do nothing.>

FYI  I got my FT-891 working months ago in the first shipments without pulling Pin 6. I sent my Alsa settings to others so they could get theirs working in the very early beta images.
Is there something now in the newer images that made the software work this pin that was not there before?

Seems I need to update my image and check and see.....

Re: Icom 706MKIIG Setup #icom #ptt

 

Disable other programs using the pin (direwolf, wsjtx, ...)

Left PTT -- toggle will switch state from off to on or on to off
gpio -g toggle 12
Right PTT -- toggle will switch state from off to on or on to off
gpio -g toggle 23

Find out more with

man gpio

For good measure reboot after playing with toggle.  (In case of typos)

On Wed, Apr 10, 2019 at 8:38 PM Todd via Groups.Io <ic7461=yahoo.com@groups.io> wrote:
Can anybody tell me how to manually KEY the PTT line? 
Todd



John D. Hays
Edmonds, WA
K7VE

   

Re: Icom 706MKIIG Setup #icom #ptt

Corky Searls
 

I am not exactly sure what you mean by "manually key the PTT." With ICOM rigs if you short the PTT line to ground  it will put the radio in transmit mode. This can be done either on the MIC connector or the rear data connector.

-Corky

On Wed, Apr 10, 2019, at 8:38 PM, Todd via Groups.Io wrote:
Can anybody tell me how to manually KEY the PTT line? 
Todd

Thanks and 73,
-Corky, AF4PM

Re: Icom 706MKIIG Setup #icom #ptt

Todd
 

Can anybody tell me how to manually KEY the PTT line? 
Todd

Re: xastir not passing GPS data via GPSD #draws #gpsd #config #xastir

Basil Gunn
 

Tom,

Thanks for the response. I will try the things you mentioned & get back
to you. gpsd version 3.18.1 is the latest version and I made the
decision to use it back in December. It fixed a couple of problems I was
seeing with the 3.16 version from the Raspbian stretch repo.

Basil


Tom Russo <russo@...> writes:

On Wed, Apr 10, 2019 at 03:45:21PM -0700, we recorded a
bogon-computron collision of the <@basil860> flavor,
containing:

Xastir & gpsd version 3.18.1 do NOT work.
Hmmmm. It is possible something has changed in 3.18 that breaks Xastir.
I have only tested with 3.17 and the current version in Raspbian Stretch,
which appears to be 3.16. Are you building your own GPSD from source in order
to get gpsd 3.18? Is that because 3.16 isn't compatible with the DRAWS hat
in some way?

Curt and I are both rather busy and it is difficult for us to do the legwork
to bring this to ground quickly. You could help immensely to pin this down if
you could verify that the issue is actually gpsd 3.18 vs. 3.17 or earlier,
rather than something specific to the DRAWS gps. Is there any chance you
could connect up the DRAWS GPS to a Pi running stretch with its default
gpsd package (3.16) and see if it still fails to show up on Xastir? Can
you also check check that it happens with some other gps as well?

I have already tested that both 3.16 and 3.17 will communicate the GPS data
to Xastir with the only USB GPS I have, on my Pi with 3.16, on another
system running 3.18, and on an Ubuntu 16.04 system (which is running gpsd
3.15), and all three worked flawlessly with Xastir. That's about all I have
had time to try, and about all I will likely have time to play with anytime
soon. Having a DRAWS board of my own won't really help speed it up much,
because of how little time I have to work on Xastir these days.

Xastir never reports that the DRAWS gps is working when using Networked GPS
(via gpsd). I killed gpsd & tried the DRAWS serial interface to the gps
& that doesn't work either.
Oohboy, that itself is *very* interesting --- if the direct serial interface
isn't working either, then it really sounds like there's something screwy
with the NMEA sentences that DRAWS is sending. It might have nothing to do
with gpsd at all, and be some quirk of how Xastir is decoding sentences and
what sentences DRAWS is sending.

Could you possibly capture some of that raw serial data and send it to us?
It might not tell us anything, but *maybe* we could spot why the RMC and GGA
decoding isn't working on those sentences.

The DRAWS gps works well on YAAC using gpsd and other clients (cgps, gpsmon,
gpspipe) work with gpsd but like you I would prefer to
run Xastir. I suspect that the Xastir code is not parsing the gpsd
sentences properly.

That is entirely possible if something changed in gpsd 3.18, or if there is
something unique about the sentences that the DRAWS hat is sending.

ie. search for "// Pre-2.90 GPSD protocol" & "//
Post-2.90 GPSD protocol" comments in the add_device() function in the interface.c
file. I uncommented the Post-2.90 code & built Xastir but got the same result.
https://github.com/Xastir/Xastir/blob/master/src/interface.c
Those comments are really misleading. The "Pre-2.90" code is there to allow
Xastir to communicate with old GPSD versions (and was just never removed even
though the odds that anyone is still using something that old are negligible)
and the commented-out "Post-9.0" code right after it is just wrong --- if you
look elsewhere in interface.c, that same code is present and uncommented. I
believe the issue is that the Post-9.0 code was initially in the wrong
place, and then was moved in commit 00eef061 about 9 years ago. Rather than
just removing it, Curt commented out the old version and left it there. That
is an unfortunate pattern in Xastir source --- lots of dead code was commented
out instead of being removed altogether.

So I would not expect that playing around with the interface start-up code
in interface.c would help, since it appears that Xastir is in fact connecting
to the port and saying all is well --- and that's all that the interface.c code
takes care of. The actual code that does the reading of GPS strings is in
main.c down around line 11707, and calls functions in gps.c.
Those functions do have some debugging output that can be enabled with
debug level 128.

So instead of playing around with uncommenting code, I'd enable debug level
128 and watch for indications that it is getting confused by non-RMC or
non-GGA strings. Clearly something is very wrong, and it would only be by
seeing exactly what, if anything, is coming in over the gpsd interface and
how it's being (or rather, not being) recognized.

If you're seeing the little red "incoming data" arrow lighting up on the
gpsd interface icon at the bottom of the Xastir screen, but not seeing any
debug output even with debug level 128 enabled, then you might have to
insert debugging statements of your own to see what raw data it's getting and
then ignoring.

There is also the "channel_data" function in interface.c that actually
reads the gps interface and saves any GPSGGA or GPSRMC sentences it
finds in a global variable that is later used by the code in main.c to
pass on to the decoding routines. Unfortunately, channel_data() isn't
instrumented with any debugging code that can be enabled by
a debug level setting, you'd have to add it.

And since I have no system with gpsd 3.18 installed on it, I am unable to
do this investigating, at least not right now. If you can get even a little
of this investigation done and throw me some data about what you see, I might
be able to figure out what's going on, or Curt might.

There is an 'issue' posted to Xastir on github here:
Unable to get GPS data via GPSD #53
https://github.com/Xastir/Xastir/issues/53

Curt, Tom do you want a DRAWS board so you can figure this out?
Is there something I can do?

The best thing you can do to help is to try to pin down whether this is an
issue specific to the DRAWS hat, or if it's something specific to that version
of GPSD. If you have another GPS to try out, or can run your pi with an
older version of gpsd, that would be an enormous step forward.

As I said, the one that comes in Raspian Stretch's repos is 3.16, not 3.18, and
when I run my cheapie USB GPS and tell gpsd to use it, Xastir can see the
gps data coming in just fine through its gpsd interface.

DRAWS is a Raspberry Pi HAT that has the SkyTraq S1216F8-GL GNSS Module
on it.

/Basil

Josh H. KB6FJ <@kb6fj> writes:

I'm beating my head against the wall with this issue.
I've done a fresh beta 11 build on a brand new sdcard and I'm still not able to get GPS data into xastir via GPSD.
YAAC gets the GPS data fine, but i don't like YAAC since maps are slow to load if they load at all.

Has anyone been successful with beta 11 with xastir and GPSD?
I've tried the bug reports and while I've had a couple responses there isn't a solution.

Re: DRAWS + FT-891 + WSJT-X/FT8

 

What do you mean by "Ambient Shack Noise"?

From this end it indicates that it is picking up from a microphone, which the DRAWS™ HAT does not have.  Check August's suggestion.  You could also see if you are getting the noise if the microphone is unplugged.



On Wed, Apr 10, 2019 at 4:28 PM Steve McGrane <temporarilyoffline@...> wrote:
Input and output set to plughw:CARD=udrc,DEV=0.  Audio Channel set to left.  Pin 6 Removed.

Decode continues to work.

Transmit continues to NOT work.
Transmit continues to transmit ambient shack noise instead of anything from DRAWS.

What's next?

On Wed, Apr 10, 2019 at 5:25 PM John D Hays - K7VE <john@...> wrote:
Screen Shot 2019-04-10 at 3.22.13 PM.png
This should be your audio setting in wsjtx

On Wed, Apr 10, 2019 at 3:15 PM Steve McGrane <temporarilyoffline@...> wrote:
Trying to get WSJT-X working for the next video. Details First, Questions at the end.

Radio: Yaesu FT-891
CAT control works over USB
Radio connected via LEFT Audio port (closest to GPS port)
RIGHT Audio port disabled via DRAWS Manager
I’ve ran `sudo bin/setalsa-ft817.sh`

Audio Input of `sysdefault:CARD=udrc/Mono` works fine and I’m decoding signals

I am unable to find an audio output setting that does anything.  Valid choices are:

default
sysdefault:card=alsa
sysdefault:card=udrc
hw:card=alsa,dev=0
plughw:card=alsa,dev=0
plughw:card=alsa,dev=1
plughw:card=udrc,dev=0

This radio works fine with a separate signalink and linux PC.

The FT-891 manuals do not specify what the “Peak to Peak Input Voltage” is, so I can not complete the calculations.

It appears that when the software triggers the PTT, that ambient shack noise is being transmitted instead of the audio/data stream from the DRAWS. (I can't whistle FT8 yet, but I'm getting close)

I have not pulled out pin 6 yet, the prev thread with Julian didn’t conclude if that was necessary or not.

Questions:
  1. What is the Peak to Peak Input Voltage of the FT-891
  2. What is the proper sound output device
  3. Any suggestions for what might be missing or what to try next?
73s,
Steve, KM9G



--


John D. Hays
Edmonds, WA
K7VE

   



--


John D. Hays
Edmonds, WA
K7VE

   

Re: DRAWS + FT-891 + WSJT-X/FT8

August Johnson KG7BZ
 

You need to change the setting in the Radio that tells it to use the Data connector for transmit audio, instead of from the Microphone. You want MODE = DAT(a) instead of MODE = SSB.

August KG7BZ

On Wed, Apr 10, 2019 at 4:28 PM Steve McGrane <temporarilyoffline@...> wrote:
Input and output set to plughw:CARD=udrc,DEV=0.  Audio Channel set to left.  Pin 6 Removed.

Decode continues to work.

Transmit continues to NOT work.
Transmit continues to transmit ambient shack noise instead of anything from DRAWS.

What's next?

On Wed, Apr 10, 2019 at 5:25 PM John D Hays - K7VE <john@...> wrote:
Screen Shot 2019-04-10 at 3.22.13 PM.png
This should be your audio setting in wsjtx

On Wed, Apr 10, 2019 at 3:15 PM Steve McGrane <temporarilyoffline@...> wrote:
Trying to get WSJT-X working for the next video. Details First, Questions at the end.

Radio: Yaesu FT-891
CAT control works over USB
Radio connected via LEFT Audio port (closest to GPS port)
RIGHT Audio port disabled via DRAWS Manager
I’ve ran `sudo bin/setalsa-ft817.sh`

Audio Input of `sysdefault:CARD=udrc/Mono` works fine and I’m decoding signals

I am unable to find an audio output setting that does anything.  Valid choices are:

default
sysdefault:card=alsa
sysdefault:card=udrc
hw:card=alsa,dev=0
plughw:card=alsa,dev=0
plughw:card=alsa,dev=1
plughw:card=udrc,dev=0

This radio works fine with a separate signalink and linux PC.

The FT-891 manuals do not specify what the “Peak to Peak Input Voltage” is, so I can not complete the calculations.

It appears that when the software triggers the PTT, that ambient shack noise is being transmitted instead of the audio/data stream from the DRAWS. (I can't whistle FT8 yet, but I'm getting close)

I have not pulled out pin 6 yet, the prev thread with Julian didn’t conclude if that was necessary or not.

Questions:
  1. What is the Peak to Peak Input Voltage of the FT-891
  2. What is the proper sound output device
  3. Any suggestions for what might be missing or what to try next?
73s,
Steve, KM9G



--


John D. Hays
Edmonds, WA
K7VE

   

Re: DRAWS + FT-891 + WSJT-X/FT8

Steve McGrane <temporarilyoffline@...>
 

Input and output set to plughw:CARD=udrc,DEV=0.  Audio Channel set to left.  Pin 6 Removed.

Decode continues to work.

Transmit continues to NOT work.
Transmit continues to transmit ambient shack noise instead of anything from DRAWS.

What's next?


On Wed, Apr 10, 2019 at 5:25 PM John D Hays - K7VE <john@...> wrote:
Screen Shot 2019-04-10 at 3.22.13 PM.png
This should be your audio setting in wsjtx

On Wed, Apr 10, 2019 at 3:15 PM Steve McGrane <temporarilyoffline@...> wrote:
Trying to get WSJT-X working for the next video. Details First, Questions at the end.

Radio: Yaesu FT-891
CAT control works over USB
Radio connected via LEFT Audio port (closest to GPS port)
RIGHT Audio port disabled via DRAWS Manager
I’ve ran `sudo bin/setalsa-ft817.sh`

Audio Input of `sysdefault:CARD=udrc/Mono` works fine and I’m decoding signals

I am unable to find an audio output setting that does anything.  Valid choices are:

default
sysdefault:card=alsa
sysdefault:card=udrc
hw:card=alsa,dev=0
plughw:card=alsa,dev=0
plughw:card=alsa,dev=1
plughw:card=udrc,dev=0

This radio works fine with a separate signalink and linux PC.

The FT-891 manuals do not specify what the “Peak to Peak Input Voltage” is, so I can not complete the calculations.

It appears that when the software triggers the PTT, that ambient shack noise is being transmitted instead of the audio/data stream from the DRAWS. (I can't whistle FT8 yet, but I'm getting close)

I have not pulled out pin 6 yet, the prev thread with Julian didn’t conclude if that was necessary or not.

Questions:
  1. What is the Peak to Peak Input Voltage of the FT-891
  2. What is the proper sound output device
  3. Any suggestions for what might be missing or what to try next?
73s,
Steve, KM9G



--


John D. Hays
Edmonds, WA
K7VE

   

Re: xastir not passing GPS data via GPSD #draws #gpsd #config #xastir

Basil Gunn
 

Xastir & gpsd version 3.18.1 do NOT work.

Xastir never reports that the DRAWS gps is working when using Networked GPS
(via gpsd). I killed gpsd & tried the DRAWS serial interface to the gps
& that doesn't work either.

The DRAWS gps works well on YAAC using gpsd and other clients (cgps, gpsmon,
gpspipe) work with gpsd but like you I would prefer to
run Xastir. I suspect that the Xastir code is not parsing the gpsd
sentences properly. ie. search for "// Pre-2.90 GPSD protocol" & "//
Post-2.90 GPSD protocol" comments in the add_device() function in the interface.c
file. I uncommented the Post-2.90 code & built Xastir but got the same result.
https://github.com/Xastir/Xastir/blob/master/src/interface.c

There is an 'issue' posted to Xastir on github here:
Unable to get GPS data via GPSD #53
https://github.com/Xastir/Xastir/issues/53

Curt, Tom do you want a DRAWS board so you can figure this out?
Is there something I can do?
DRAWS is a Raspberry Pi HAT that has the SkyTraq S1216F8-GL GNSS Module
on it.

/Basil

Josh H. KB6FJ <@kb6fj> writes:

I'm beating my head against the wall with this issue.
I've done a fresh beta 11 build on a brand new sdcard and I'm still not able to get GPS data into xastir via GPSD.
YAAC gets the GPS data fine, but i don't like YAAC since maps are slow to load if they load at all.

Has anyone been successful with beta 11 with xastir and GPSD?
I've tried the bug reports and while I've had a couple responses there isn't a solution.

Re: xastir not passing GPS data via GPSD #draws #gpsd #config #xastir

Josh H. KB6FJ
 

I guess the bigger question is this issue affecting everybody with a DRAWS hat and beta 11or is it just us lucky select few.

If submitted the issue to the xastir community. I still have the zip for beta 9 I might try reloading that.

Re: xastir not passing GPS data via GPSD #draws #gpsd #config #xastir

Kevin K. - N7KJK
 

Josh, 
I'm in the same boat here.  New Beta 11 image. Ran through all the config stuff.  Double checked that GPSD and Xastir are current.  Still no luck. Confirmed good data from the GPS, and YAAC work as you describe. 

I am afraid we might just have to wait for a fix to Xastir.  I've been thinking about this from the service/network perspective.   I will certainly share with the group if I figure out something before Xastir folks do.

73
Kevin