Date   

Re: A couple of interesting tidbits #xastir #wsjtx #pulseaudio #draws

Jack Spitznagel
 

Thanks for pointing this out John. I will putter around with Annaliese’s instructions… Exactly why I bought this little beast in the first place! Since my most of rigs are primarily ICOM, it will be interesting to mix it in with use of the built in sound systems of the 7100 and 7300. Also interesting to learn if trying this is not going to overload the Pi B 3+. RPi are cheap, so the ICOMs will probably be run by a cluster rather than with the DRAWS.

 

I still am struggling with getting an appropriate drive level for using fldigi and wsjtx on the IC-7000. Xastir/YAAC does work on the 7000 and all programs I have tried work fine on the FT-817, but properly configuring the DRAWS and IC-7000 for HF digital modes has bugged me since early December. My correspondence with Basil and Brian about that is here in the UDRC archive.

 

Love to know if there has been any “discovery” made about this issue.

 

KD4IZ

Jack Spitznagel

FM19oo

 

 

 

From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On Behalf Of John D Hays - K7VE
Sent: Friday, April 12, 2019 13:10
To: udrc@nw-digital-radio.groups.io
Subject: [udrc] A couple of interesting tidbits #xastir #wsjtx #pulseaudio #draws

 

Here is a screenshot from K7UDR's remote base.  It runs a headless DRAWS™ HAT on a Raspberry Pi 3+.  I access it from about 60 miles away over VNC.

The left and right mini DIN-6 ports run independently via an install and configuration of Pulse Audio.  Pulse Audio is not installed on the DRAWS™ beta images and is in test mode at the moment.  Anna has instructions for setup at https://github.com/nwdigitalradio/split-channels for the adventurous/experimenter.

On the left mini DIN-6 is an FT-817 hooked up to a dipole, with CAT control via USB port.  In the screen shot we are running WSJT-X. PTT is via CAT for this transceiver configuration.

 

On the right mini DIN-6 is an IC-706Mk2G. Which under CAT control over a second USB port.  This radio doesn't allow PTT over CAT (CI-V), so applications must support an alternative keying method.  Fortunately, direwolf supports PTT via GPIO on the Raspberry Pi/DRAWS™.  In the screenshot you will Xastir running, using gpsd for position and direwolf for the packet modem.   

 

In this configuration, both an HF datamode and Xastir/Direwolf are running simultaneously from one DRAWS™ HAT, using two attached radios.

Fldigi can access Pulse Audio natively, other applications are using ALSA mappings of Pulse Audio 'devices' for audio.

Screen Shot 2019-04-12 at 9.43.43 AM.png


Any application that uses direwolf, should be able to take advantage of this type of configuration for packet applications.   Data mode applications access either through native Pulse Audio support, or via Pulse Audio/ALSA mappings.

 

--

 


John D. Hays
Director

  


--
J Spitznagel
Science River LLC
KD4IZ


A couple of interesting tidbits #xastir #wsjtx #pulseaudio #draws

 

Here is a screenshot from K7UDR's remote base.  It runs a headless DRAWS™ HAT on a Raspberry Pi 3+.  I access it from about 60 miles away over VNC.

The left and right mini DIN-6 ports run independently via an install and configuration of Pulse Audio.  Pulse Audio is not installed on the DRAWS™ beta images and is in test mode at the moment.  Anna has instructions for setup at https://github.com/nwdigitalradio/split-channels for the adventurous/experimenter.

On the left mini DIN-6 is an FT-817 hooked up to a dipole, with CAT control via USB port.  In the screen shot we are running WSJT-X. PTT is via CAT for this transceiver configuration.

On the right mini DIN-6 is an IC-706Mk2G. Which under CAT control over a second USB port.  This radio doesn't allow PTT over CAT (CI-V), so applications must support an alternative keying method.  Fortunately, direwolf supports PTT via GPIO on the Raspberry Pi/DRAWS™.  In the screenshot you will Xastir running, using gpsd for position and direwolf for the packet modem.   

In this configuration, both an HF datamode and Xastir/Direwolf are running simultaneously from one DRAWS™ HAT, using two attached radios.

Fldigi can access Pulse Audio natively, other applications are using ALSA mappings of Pulse Audio 'devices' for audio.

Screen Shot 2019-04-12 at 9.43.43 AM.png

Any application that uses direwolf, should be able to take advantage of this type of configuration for packet applications.   Data mode applications access either through native Pulse Audio support, or via Pulse Audio/ALSA mappings.

--


John D. Hays
Director

  


Re: Kenwood TM-281a Cable

ac8dg@...
 
Edited

make sure you connect to the 'tip' not the ring of the speaker jack for audio out of the radio

and the volume control knob affects the received signal audio level


Re: #audio #audio

 

Got it back by audio control settings. No idea why anything might have changed.


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

Josh H. KB6FJ
 

I rebuilt Xastir from the latest git pull (2.1.1) and I'm now able to use GPSD to update my location.

Basil you were better able to explain to Tom and Curt what the hardware DRAWS is using, I opened the issue with them but couldn't explain what was really happening.
This is a great fix for everyone and will help reduce user issues going forward.

 


#audio #audio

 

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

 

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