Date   
Re: State of GPSD on boot and PPS2 #pps #gpsd #chrony

Daniel VE3NI
 

Hi Annaliese,

I checked /etc/default/gpsd and the GPSD_OPTIONS was set as GPSD_OPTIONS=-n

In my investigation of this issue I checked the www.catb.org/gpsd/ site and under troubleshooting I found:

      Ubuntu/Debian

      The .deb package supplied for the Debian and Ubuntu Linux distributions launch at boot either using systemd with gpsd.socket and gpsd.service, or on older releases from the system V-like script /etc/init.d/gpsd. However, both are governed by a control file, /etc/default/gpsd. If necessary, edit the control file as root.

      Please note that systemd will only start gpsd on request by clients connecting to the unix or tcp socket. In case you need gpsd to run always, you'll need to configure systemd to start it. One way would be to create /etc/systemd/system/gpsd.service with the following content:

      [Unit]

      Description=GPS (Global Positioning System) Daemon

      Requires=gpsd.socket

      # Needed with chrony SOCK refclock

      After=chronyd.service

      [Service]

      EnvironmentFile=-/etc/default/gpsd

      EnvironmentFile=-/etc/sysconfig/gpsd

      ExecStart=/usr/sbin/gpsd -N $GPSD_OPTIONS $DEVICES

      [Install]

      WantedBy=multi-user.target

      Also=gpsd.socket

Then make sure you ask systemd to reload its config run:

sudo systemctl daemon-reload; systemctl reenable gpsd.service

I have implemented this as suggested and it resolves the problem that I run into.

I suspect that this would not be an issue for anyone who is automatically starting applications that access gpsd on bootup but that is not my case.  My main use of gpsd is for chrony to act as a time server for my local network.

Cheers,

Daniel  VE3NI

-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On Behalf Of Annaliese McDermond
Sent: Tuesday, January 01, 2019 7:32 PM
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] State of GPSD on boot and PPS2

> On Jan 1, 2019, at 2:01 PM, Daniel VE3NI <dgoodier@...> wrote:

> This however has not resolved the fact that gpsd service does not start automatically on startup until I either issue a systemctl start gpsd.service or run gpsmon.

> I believe that this is still under investigation.

If you haven’t already checked, make sure that as part of the GPSD_OPTIONS variable in /etc/default/gpsd, it includes the “-n” flag.  It should read something like:

GPSD_OPTIONS="-n -G”

This line will cause gpsd to start as a daemon and to answer queries from outside of the Pi (if, for example, you wanted to use it as a GPS source for Xastir or YACC).

--

Annaliese McDermond (NH6Z)

nh6z@...


> Cheers,

> Daniel  VE3NI / NI2D

Re: possible DRAWS hardware failure.

Joseph Vilardo
 

Annaliese

Thanks, you nailed it. dtparm=audio=on was before dtovelay= and dtoverlay=draws. Made the change and it fixed the problem. Someone needs to make this change in the image. I didn't change the contents or order of the commands in config.txt,  just added # to comment out the line and got FLDIGI to work on urdc (0,0).   I have been fighting with the problem for about a week and convinced it was a hardware failure, which was wrong,  but not smart enough to know what it was or how to fix it.

I am sure there are dozens of subtle problems in getting a product and software launched. All of the players at NW digital providing support have been great. Early adopting can be frustrating at times.

Thanks,

Joe

On 1/1/2019 7:40 PM, Annaliese McDermond wrote:
It appears to me that you have incorrect settings in your config.txt file.  I will make this very explicit because I’m not sure I’ve made myself clear before:

*ORDER MATTERS IN LINES IN config.txt*

If you do not get the directives in the correct order, the OS kernel will not load the correct drivers for you.

If you intend to use the onboard audio on the Pi, the line

dtparam=audio=on

*MUST* come after the lines

dtoverlay=
dtoverlay=draws

Otherwise the device tree will not be loaded correctly and you won’t get a proper driver set.

--
Annaliese McDermond (NH6Z)
nh6z@...


On Jan 1, 2019, at 3:56 PM, Joseph Vilardo <jvilardo@...> wrote:

Basil

I ran your suggested procedures and I am still where I was when I started.  When I run FLDIGI, after doing all the prerequisites for shutting down  DIREWOLF and and running ./ax25-stop , I still cannot select a sound card from the fldigi audio setup menu.  To select the the codec from the fldigi audio set up I must have #dtparam=audio=on commented out in the config.txt file. With dtparam=audio=on commented out with the # symbol I can then select urdc: - (hw:0,0) , not urdc: - (hw:0,1) for capture and urdc:-(hw:0,0) for playback. This result is what you said enumerates with dtparm=audio=on commented out, only hw 0,0 will enumerate. 

When following the new draw "getting started doc "DRAWS Raspberry PI image"  from the wiki and run "aplay-l I" do not get the same results shown in the example of the doc. 

This what I see:


**** List of PLAYBACK Hardware Devices ****

card 
0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]

  
Subdevices: 7/7

  
Subdevice #0: subdevice #0

  
Subdevice #1: subdevice #1

  
Subdevice #2: subdevice #2

  
Subdevice #3: subdevice #3

  
Subdevice #4: subdevice #4

  
Subdevice #5: subdevice #5

  
Subdevice #6: subdevice #6

card 
0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]

  
Subdevices: 1/1

  
Subdevice 
#0: subdevice #0

Your example shows the following which I do not get:


 card 1: udrc [udrc], device 0: Universal Digital Radio Controller tlv320aic32x4-hifi-0 []

  
Subdevices: 0/1

  
Subdevice #0: subdevice #0

I have tried re formatting the micro sd card, changing sd cards,  re burning the image, changing the RPi 3 B+ to a different RPi B+, powering the RPi/DRAWS board from 12 volt supply. I am out of ideas and because of the anomaly in the results from aplay -l I think the problem it is a hardware failure of the DRAWS Board.

If you have any suggestions I am ready to try them.

Best regards and happy New Year,

Joe K3JV





On 12/30/2018 1:08 AM, Basil Gunn wrote:
Joe,
Thanks for all the information.


I have been successful in verifying the core operation of Beta 6 and
have Direwolf/YAAC running without issue on port 0. I also have FLDIGI
running on port 0 (left hand port on the draws board) without a
problem but had to deviate from the information in
DRAWS_CONFIG.md. The directions in the verify document tell us to
remove the # from dtparm=audio=on to "Test analog audio" . I do that
by removing the # in the config.txt file for the Rpi and the test runs
and I get the results indicated. The same is true for "TEST OF HDMI
AUDIO" . By the way there is a minor error in the information the beta
6 release doesn't have a file named "silence.wav" in $
/usr/share/xastir/sounds.

Yes I see that. I'll fix it.
For now just copy it from n7nix/xastir/silence.wav to the
/usr/share/xastir/silence.wav


Here is the question. When I complete the verify core test and
shutdown --ax25

You need to run a script in your local bin called. ax25-stop


and then start FLDIGi and try to configure the sound
card FLDIGI fails and shuts down.

Try this.
You should see the process id of direwolf the first time you run pidof
and not the second time.

cd
cd bin
sudo su
pidof direwolf
./ax25-stop
pidof direwolf

Now run fldigi


In fldigi under the choices in the
audio selection menu there is no udrc audio choice available.

I just tried it & Fldigi enumerates:
udrc: -(hw:1,0)

without the enabled RPi sound device the udrc will enumerate like this:
udrc: -(hw:0,0)

I have a feeling you are not shutting down direwolf.
The next image will have direwolf unloaded by default.


IF I go
back to CONFIG.TXT and comment out, put the # in, for the line
dtparam=audio=on, reboot, start FLDIGI I can then select the udrc 0
port and complete the configuration of fldigi without issue and fldigi
runs just fine. Am I overlooking something in your instructions?
Or are we to comment out the dtparam=audio=on in the config.txt of the
RPi

There should be no problem enabling the BCM2835 RPi sound device.
I use it with Xastir for the sound alerts.


I am making some progress with WSTX I can receive and decode but not
transmit yet. I need to recheck the cable I made that goes from the
6pin mini din of the draws board to the 13 pin Din of my TS 590.

Thanks,
K3JV Joe





      




Re: Draws and IC-7000 #draws #ic7000 #minidin6

Jack Spitznagel
 

Thank you Annaliese,

Your answers below were a big help as they always are!

Had a few minutes to play today so I went through the current settings in alsamixer by browsing through the outputs of "amixer", "amixer scontents", and "amixer controls" (essentially the same list +/- the setting values). Did not see the "DAC Right|Left Playback Powertune" control listed.

Do I surmise correctly that the PTM control is not exposed in the BETA 6 mixer driver?

If it is, where/how would I find it and under what subdevice name?

HNY and 73,

KD4IZ
Jack Spitznagel
FM19oo

-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On Behalf Of Annaliese McDermond
Sent: Monday, December 31, 2018 18:44
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6



On Dec 31, 2018, at 1:34 PM, Jack Spitznagel <@flyingfrawg> wrote:

Hi Basil,

Again Thanks!!!
I understand these differences. Not confusing. I have been leaving the base config alone for now, but with the info from Annaliese yesterday and yours below, is speculative experimentation fair game now 😊?

Her notes on the implementation of the TI CODEC chip brought up these questions:
1. Should we disable the port not in use if only using 1 of them?? Annaliese suggests this would eliminate possibility of crosstalk. Is there a description of how you do this in the DRAWS wiki or your github pages? I missed it.
Just change the pin you would like to disable to “Off.” For example, to turn off the discriminator input to the left DIN-6, you would set “IN1_L to Left Mixer Positive Resistor” to “Off” Likewise to change the 1200 baud/audio input off to the left DIN-6, you would set “IN2_L to Left Mixer Positive Resistor” to “Off"


2. The info she sent about the PTM-P1/2/3 (DAC Left|Right Playback Powertune) settings for selecting the max output level suggests that the PTM-P1 setting should be default for the sensitive radios like the 7000. I look forward to seeing that available in Beta7. Where is it defaulting to now?
Default is PTM-P3

3. Her description of the three resistances associated with configuring input routing appear to be for the input only, I assume input from the rig?
Yes, this is audio/discriminator from the rig. Input from the DRAWS’s point of view.

Do they also impact the output to the rig? What you say below implies that... I am a little confused on this now.
No, it does not impact the output channels in any way. If you look at the analog routing diagram on the Wiki page, the resistor in question is represented by the switches between the various pins and the respective Mic PGA. They aren’t straight switches, they are either off, or they switch in a resistor of one of the three values.

For the record, I am doing everything at 1200 for the initial testing here thus focusing on IN2. IN1 - 9600/GMSK will come later once I know things work the way I want.

Assume you mean the 7000 below, not the 7100? They appear similar as far as the data port specs are concerned, I just have not played with the 7100 all that much other than using its internal sound device for HRD/DM780 ops and as a modem for Spectrum Lab.

In the DRAWS implementation here, the IC-7000 and the FT-817 will get used (max portability), both of which I have used with audio/data and GMSK/data in the past. The IC-7100 here is happy as is, mostly acts as #2 in an SO2R set up, providing 144/440 coverage and HF D-STAR. The primary HF radio can't do that.

If you have something specific you would like me to look at, or a possible solution you want to test for one of these radios (assuming not all are available to you), please ask. I have or can scrounge pretty much any needed test equipment. I also have a PDF copy of the service manual for the IC-7000 which may provide more clarity for that radio if you think it might help.

KD4IZ
Jack Spitznagel
FM19oo





--
J Spitznagel
Science River LLC
KD4IZ

Re: note about xastir and building from source #draws #xastir #aprs

Ken Koster
 

On Tuesday, January 1, 2019 4:25:51 PM PST Art - KC7SDA wrote:

> so I found out about this problem quite by accident... if you run xastir

> that was installed by apt from the repository and you want to build from

> the source (for version 2.1.1 or later) you have to rename/modify/delete

> xastir.cnf in ~/.xastir/config to point to /usr/local/share/xastir instead

> of /usr/share/xastir.

 

You could also remove the old xastir and it's config files with:

apt-get purge xastir

That will remove the config files, then build and install xastir.

 

Or if you want to keep the config files build xastir with:

../configure --prefix=/usr

 

That will place the new xastir in the same location as the repository package does.

 

> Also, as of this writing the beta images come with the binary version of

> xastir (version 2.0.8)

>

>

 

 

--

Ken - N7IPB

Email: n7ipb@...

JID: n7ipb@...

SvxLink Repeaters: http://pnw220.wetnet.net

PGP Sig: F42B EF90 3CD3 31C7 3056 122E 993A 7B2E 5138 C42A

“Contrariwise,' continued Tweedledee, 'if it was so, it might be;

and if it were so, it would be; but as it isn't, it ain't. That's logic.”

Re: note about xastir and building from source #draws #xastir #aprs

Basil Gunn
 

Debian File System Hierarchy Standard
https://wiki.debian.org/FilesystemHierarchyStandard

It's a debian convention that locally built binaries use:
/usr/local/var
/usr/local/etc
/usr/local/share
/usr/local/bin

programs installed with apt use:
/var
/etc
/usr/share
/bin

The install method for Xastir on the DRAWS image can be seen in the
n7nix/xastir/install.sh script.

- xastir is installed using apt-get
- a desktop icon is used that actually works
- xastir-sounds are installed to /usr/share/xastir-sounds

/Basil

Art - KC7SDA <@nouse4anick> writes:

so I found out about this problem quite by accident... if you run
xastir that was installed by apt from the repository and you want to
build from the source (for version 2.1.1 or later) you have to
rename/modify/delete xastir.cnf in ~/.xastir/config to point to
/usr/local/share/xastir instead of /usr/share/xastir.

Also, as of this writing the beta images come with the binary version
of xastir (version 2.0.8)

Re: possible DRAWS hardware failure.

Basil Gunn
 

From your description your system is either not loading the draws driver
or you have a hardware error.

Please send the output of showudrc.sh to my personal email address.

/Basil

I ran your suggested procedures and I am still where I was when I
started. When I run FLDIGI, after doing all the prerequisites for
shutting down DIREWOLF and and running ./ax25-stop , I still cannot
select a sound card from the fldigi audio setup menu. To select the the
codec from the fldigi audio set up I must have #dtparam=audio=on
commented out in the config.txt file. With dtparam=audio=on commented
out with the # symbol I can then select urdc: - (hw:0,0) , not urdc: -
(hw:0,1) for capture and urdc:-(hw:0,0) for playback. This result is
what you said enumerates with dtparm=audio=on commented out, only hw 0,0
will enumerate.

When following the new draw "getting started doc "DRAWS Raspberry PI
image" from the wiki and run "aplay-l I" do not get the same results
shown in the example of the doc.

This what I see:

|****ListofPLAYBACK HardwareDevices****card 0:ALSA [bcm2835 ALSA],device
0:bcm2835 ALSA [bcm2835 ALSA]Subdevices:7/7Subdevice#0: subdevice
#0Subdevice#1: subdevice #1Subdevice#2: subdevice #2Subdevice#3:
subdevice #3Subdevice#4: subdevice #4Subdevice#5: subdevice
#5Subdevice#6: subdevice #6card 0:ALSA [bcm2835 ALSA],device 1:bcm2835
ALSA [bcm2835 IEC958/HDMI]Subdevices:1/1Subdevice#0: subdevice #0 Your
example shows the following which I do not get: |

**

*|card 1:udrc [udrc],device
0:UniversalDigitalRadioControllertlv320aic32x4-hifi-0[]Subdevices:0/1Subdevice#0:
subdevice #0|*

**

I have tried re formatting the micro sd card, changing sd cards, re
burning the image, changing the RPi 3 B+ to a different RPi B+, powering
the RPi/DRAWS board from 12 volt supply. I am out of ideas and because
of the anomaly in the results from aplay -l I think the problem it is a
hardware failure of the DRAWS Board.

If you have any suggestions I am ready to try them.

Re: possible DRAWS hardware failure.

Annaliese McDermond
 

It appears to me that you have incorrect settings in your config.txt file. I will make this very explicit because I’m not sure I’ve made myself clear before:

*ORDER MATTERS IN LINES IN config.txt*

If you do not get the directives in the correct order, the OS kernel will not load the correct drivers for you.

If you intend to use the onboard audio on the Pi, the line

dtparam=audio=on

*MUST* come after the lines

dtoverlay=
dtoverlay=draws

Otherwise the device tree will not be loaded correctly and you won’t get a proper driver set.

--
Annaliese McDermond (NH6Z)
nh6z@...

On Jan 1, 2019, at 3:56 PM, Joseph Vilardo <@k3jv> wrote:

Basil

I ran your suggested procedures and I am still where I was when I started. When I run FLDIGI, after doing all the prerequisites for shutting down DIREWOLF and and running ./ax25-stop , I still cannot select a sound card from the fldigi audio setup menu. To select the the codec from the fldigi audio set up I must have #dtparam=audio=on commented out in the config.txt file. With dtparam=audio=on commented out with the # symbol I can then select urdc: - (hw:0,0) , not urdc: - (hw:0,1) for capture and urdc:-(hw:0,0) for playback. This result is what you said enumerates with dtparm=audio=on commented out, only hw 0,0 will enumerate.

When following the new draw "getting started doc "DRAWS Raspberry PI image" from the wiki and run "aplay-l I" do not get the same results shown in the example of the doc.

This what I see:


**** List of PLAYBACK Hardware Devices ****

card
0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]


Subdevices: 7/7


Subdevice #0: subdevice #0


Subdevice #1: subdevice #1


Subdevice #2: subdevice #2


Subdevice #3: subdevice #3


Subdevice #4: subdevice #4


Subdevice #5: subdevice #5


Subdevice #6: subdevice #6

card
0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]


Subdevices: 1/1


Subdevice
#0: subdevice #0

Your example shows the following which I do not get:


card 1: udrc [udrc], device 0: Universal Digital Radio Controller tlv320aic32x4-hifi-0 []


Subdevices: 0/1


Subdevice #0: subdevice #0

I have tried re formatting the micro sd card, changing sd cards, re burning the image, changing the RPi 3 B+ to a different RPi B+, powering the RPi/DRAWS board from 12 volt supply. I am out of ideas and because of the anomaly in the results from aplay -l I think the problem it is a hardware failure of the DRAWS Board.

If you have any suggestions I am ready to try them.

Best regards and happy New Year,

Joe K3JV





On 12/30/2018 1:08 AM, Basil Gunn wrote:
Joe,
Thanks for all the information.


I have been successful in verifying the core operation of Beta 6 and
have Direwolf/YAAC running without issue on port 0. I also have FLDIGI
running on port 0 (left hand port on the draws board) without a
problem but had to deviate from the information in
DRAWS_CONFIG.md. The directions in the verify document tell us to
remove the # from dtparm=audio=on to "Test analog audio" . I do that
by removing the # in the config.txt file for the Rpi and the test runs
and I get the results indicated. The same is true for "TEST OF HDMI
AUDIO" . By the way there is a minor error in the information the beta
6 release doesn't have a file named "silence.wav" in $
/usr/share/xastir/sounds.
Yes I see that. I'll fix it.
For now just copy it from n7nix/xastir/silence.wav to the
/usr/share/xastir/silence.wav


Here is the question. When I complete the verify core test and
shutdown --ax25
You need to run a script in your local bin called. ax25-stop


and then start FLDIGi and try to configure the sound
card FLDIGI fails and shuts down.
Try this.
You should see the process id of direwolf the first time you run pidof
and not the second time.

cd
cd bin
sudo su
pidof direwolf
./ax25-stop
pidof direwolf

Now run fldigi


In fldigi under the choices in the
audio selection menu there is no udrc audio choice available.
I just tried it & Fldigi enumerates:
udrc: -(hw:1,0)

without the enabled RPi sound device the udrc will enumerate like this:
udrc: -(hw:0,0)

I have a feeling you are not shutting down direwolf.
The next image will have direwolf unloaded by default.


IF I go
back to CONFIG.TXT and comment out, put the # in, for the line
dtparam=audio=on, reboot, start FLDIGI I can then select the udrc 0
port and complete the configuration of fldigi without issue and fldigi
runs just fine. Am I overlooking something in your instructions?
Or are we to comment out the dtparam=audio=on in the config.txt of the
RPi
There should be no problem enabling the BCM2835 RPi sound device.
I use it with Xastir for the sound alerts.


I am making some progress with WSTX I can receive and decode but not
transmit yet. I need to recheck the cable I made that goes from the
6pin mini din of the draws board to the 13 pin Din of my TS 590.

Thanks,
K3JV Joe


Re: State of GPSD on boot and PPS2 #pps #gpsd #chrony

Annaliese McDermond
 

On Jan 1, 2019, at 2:01 PM, Daniel VE3NI <dgoodier@...> wrote:

This however has not resolved the fact that gpsd service does not start automatically on startup until I either issue a systemctl start gpsd.service or run gpsmon.

I believe that this is still under investigation.
If you haven’t already checked, make sure that as part of the GPSD_OPTIONS variable in /etc/default/gpsd, it includes the “-n” flag. It should read something like:

GPSD_OPTIONS="-n -G”

This line will cause gpsd to start as a daemon and to answer queries from outside of the Pi (if, for example, you wanted to use it as a GPS source for Xastir or YACC).

--
Annaliese McDermond (NH6Z)
nh6z@...


Cheers,
Daniel VE3NI / NI2D

note about xastir and building from source #draws #xastir #aprs

Art - KC7SDA
 

so I found out about this problem quite by accident... if you run xastir that was installed by apt from the repository and you want to build from the source (for version 2.1.1 or later) you have to rename/modify/delete xastir.cnf in ~/.xastir/config to point to /usr/local/share/xastir instead of /usr/share/xastir.

Also, as of this writing the beta images come with the binary version of xastir (version 2.0.8)

Re: possible DRAWS hardware failure.

Joseph Vilardo
 

Basil

I ran your suggested procedures and I am still where I was when I started.  When I run FLDIGI, after doing all the prerequisites for shutting down  DIREWOLF and and running ./ax25-stop , I still cannot select a sound card from the fldigi audio setup menu.  To select the the codec from the fldigi audio set up I must have #dtparam=audio=on commented out in the config.txt file. With dtparam=audio=on commented out with the # symbol I can then select urdc: - (hw:0,0) , not urdc: - (hw:0,1) for capture and urdc:-(hw:0,0) for playback. This result is what you said enumerates with dtparm=audio=on commented out, only hw 0,0 will enumerate.

When following the new draw "getting started doc "DRAWS Raspberry PI image"  from the wiki and run "aplay-l I" do not get the same results shown in the example of the doc.

This what I see:

**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 7/7
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Your example shows the following which I do not get:

card 1: udrc [udrc], device 0: Universal Digital Radio Controller tlv320aic32x4-hifi-0 []
  Subdevices: 0/1
  Subdevice #0: subdevice #0

I have tried re formatting the micro sd card, changing sd cards,  re burning the image, changing the RPi 3 B+ to a different RPi B+, powering the RPi/DRAWS board from 12 volt supply. I am out of ideas and because of the anomaly in the results from aplay -l I think the problem it is a hardware failure of the DRAWS Board.

If you have any suggestions I am ready to try them.

Best regards and happy New Year,

Joe K3JV



On 12/30/2018 1:08 AM, Basil Gunn wrote:
Joe,
Thanks for all the information.

I have been successful in verifying the core operation of Beta 6 and
have Direwolf/YAAC running without issue on port 0. I also have FLDIGI
running on port 0 (left hand port on the draws board) without a
problem but had to deviate from the information in
DRAWS_CONFIG.md. The directions in the verify document tell us to
remove the # from dtparm=audio=on to "Test analog audio" . I do that
by removing the # in the config.txt file for the Rpi and the test runs
and I get the results indicated. The same is true for "TEST OF HDMI
AUDIO" . By the way there is a minor error in the information the beta
6 release doesn't have a file named "silence.wav" in $
/usr/share/xastir/sounds.
Yes I see that. I'll fix it.
For now just copy it from n7nix/xastir/silence.wav to the
/usr/share/xastir/silence.wav

Here is the question. When I complete the verify core test and
shutdown --ax25
You need to run a script in your local bin called. ax25-stop

and then start FLDIGi and try to configure the sound
card FLDIGI fails and shuts down.
Try this.
You should see the process id of direwolf the first time you run pidof
and not the second time.

cd
cd bin
sudo su
pidof direwolf
./ax25-stop
pidof direwolf

Now run fldigi

In fldigi under the choices in the
audio selection menu there is no udrc audio choice available.
I just tried it & Fldigi enumerates:
udrc: -(hw:1,0)

without the enabled RPi sound device the udrc will enumerate like this:
udrc: -(hw:0,0)

I have a feeling you are not shutting down direwolf.
The next image will have direwolf unloaded by default.

IF I go
back to CONFIG.TXT and comment out, put the # in, for the line
dtparam=audio=on, reboot, start FLDIGI I can then select the udrc 0
port and complete the configuration of fldigi without issue and fldigi
runs just fine. Am I overlooking something in your instructions?
Or are we to comment out the dtparam=audio=on in the config.txt of the
RPi
There should be no problem enabling the BCM2835 RPi sound device.
I use it with Xastir for the sound alerts.

I am making some progress with WSTX I can receive and decode but not
transmit yet. I need to recheck the cable I made that goes from the
6pin mini din of the draws board to the 13 pin Din of my TS 590.

Thanks,
K3JV Joe



Re: State of GPSD on boot and PPS2 #pps #gpsd #chrony

Daniel VE3NI
 

Hi Art,

 

Thanks for having a look at this.

 

John had pointed out to be that the ‘require’ at the end of the gps line was not required in my case and that the PPS2 was caused by the fact that when I ENABLED the line ‘refclock PPS  . . . . ’  I need to comment out the ‘refclock SHM 2 . . . ’  line in the chrony.conf file.

 

Since I did this I have not had any issue with ‘multiple’ PPSx showing up in sources.

 

pi@draws:~ $ chronyc sources -v

210 Number of sources = 6

 

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.

/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,

| /   '?' = unreachable, 'x' = time may be in error, '~' = time too variable.

||                                                 .- xxxx [ yyyy ] +/- zzzz

||      Reachability register (octal) -.           |  xxxx = adjusted offset,

||      Log2(Polling interval) --.      |          |  yyyy = measured offset,

||                                \     |          |  zzzz = estimated error.

||                                 |    |           \

MS Name/IP address         Stratum Poll Reach LastRx Last sample              

===============================================================================

#x GPS                           0   3   377    13   -152ms[ -152ms] +/-  102ms

#* PPS1                          0   4   377    16   +249ns[ +389ns] +/-  251ns

^- zero.gotroot.ca               2   8   377    41  -1336us[-1336us] +/-   43ms

^- 2607:5300:60:975a::           2  10   377   303   -142us[ -142us] +/-   10ms

^- comet.spiderspace.co.uk       2   9   377   439  +1482us[+1483us] +/-   11ms

^- 2620:10a:800f::12             1  10   377    53   +283us[ +283us] +/-  504ms

pi@draws:~ $

 

This however has not resolved the fact that gpsd service does not start automatically on startup until I either issue a systemctl start gpsd.service or run gpsmon.

 

I believe that this is still under investigation.

 

Cheers,

Daniel  VE3NI / NI2D

 

From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On Behalf Of Art - KC7SDA
Sent: Tuesday, January 01, 2019 1:33 PM
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] State of GPSD on boot and PPS2

 

I was messing around last night and I think that if you don't remove 'require' at the end of the gps line it won't update based on the ntp server time chrony just hangs.

testing:
- shutdown pi
- remove gps antenna
- wait 10+ minutes
- boot pi
- use chronyc sources to verify

if you add the -v flag you get this output:


one of the time servers should be selected (either * or +).

Re: Updated DRAWS Brochure Uploaded #draws

Patrick <ptwaugh@...>
 

Awesome!  A 3D mockup and virtualization would be even better.  :)

Patrick
K3BBG - Branson, MO

Why chrony? #chrony #draws #time

 

Here is a feature comparison.


--


John D. Hays
Edmonds, WA
K7VE

   

Re: State of GPSD on boot and PPS2 #pps #gpsd #chrony

Art - KC7SDA
 

I was messing around last night and I think that if you don't remove 'require' at the end of the gps line it won't update based on the ntp server time chrony just hangs.

testing:
- shutdown pi
- remove gps antenna
- wait 10+ minutes
- boot pi
- use chronyc sources to verify

if you add the -v flag you get this output:


one of the time servers should be selected (either * or +).

Re: DRAWS Codec Technical Documentation

f6bvp
 

Hi,

By default direwolf can only send calibration test signal on channel 0 using option -x

I submitted a patch for direwolf 1.6 making possible to choose the audio channel : option becomes -x 0 or -x 1

This gives the possibility to send calibration test on UDRC II din6, otherwise not possible.

Of course channel choice is also working fine with DRAWS.

Here is the link :

https://github.com/wb2osz/direwolf/issues/184

73 de Bernard, f6bvp


Le 31/12/2018 à 21:12, John D Hays - K7VE a écrit :
Yes this is a change with DRAWS. Left audio to left DIN. 

On Mon, Dec 31, 2018, 12:01 f6bvp <f6bvp@...> wrote:
Hi,

With DRAWS I noticed that PBEACON sendto=0 is sending APRS beacon on
left DIN6 (CHANNEL 0).

This is absolutely correct and in accordance with n7nix
measure_deviate.sh deviation script that sends modulation wav through sox.

However when using UDRC II modem and the same direwolf configuration
file, direwolf is sending beacon via HD15 plug.

If someone wants to send beacon via DIN6 when using UDRC II, PBEACON
sendto=1 must be used.

Is UDRC II CHANNEL inversion the result of a hardware difference between
UDRC II and DRAWS or a bug in UDRC II firmware ?


73 de Bernard, f6bvp

Le 31/12/2018 à 05:18, Annaliese McDermond a écrit :
> I have just posted the following article to the UDRC/DRAWS Wiki:
>
>
>
Bernard, F6BVP
http://f6bvp.org


Short Demo #FT-817 #DRAWS #FT-8 Decode #ft-817 #draws #ft-8 #ft817 #hf

 


--


John D. Hays
Edmonds, WA
K7VE

   

Re: Draws and IC-7000 #draws #ic7000 #minidin6

Annaliese McDermond
 

On Dec 31, 2018, at 1:34 PM, Jack Spitznagel <@flyingfrawg> wrote:

Hi Basil,

Again Thanks!!!
I understand these differences. Not confusing. I have been leaving the base config alone for now, but with the info from Annaliese yesterday and yours below, is speculative experimentation fair game now 😊?

Her notes on the implementation of the TI CODEC chip brought up these questions:
1. Should we disable the port not in use if only using 1 of them?? Annaliese suggests this would eliminate possibility of crosstalk. Is there a description of how you do this in the DRAWS wiki or your github pages? I missed it.
Just change the pin you would like to disable to “Off.” For example, to turn off the discriminator input to the left DIN-6, you would set “IN1_L to Left Mixer Positive Resistor” to “Off” Likewise to change the 1200 baud/audio input off to the left DIN-6, you would set “IN2_L to Left Mixer Positive Resistor” to “Off"


2. The info she sent about the PTM-P1/2/3 (DAC Left|Right Playback Powertune) settings for selecting the max output level suggests that the PTM-P1 setting should be default for the sensitive radios like the 7000. I look forward to seeing that available in Beta7. Where is it defaulting to now?
Default is PTM-P3

3. Her description of the three resistances associated with configuring input routing appear to be for the input only, I assume input from the rig?
Yes, this is audio/discriminator from the rig. Input from the DRAWS’s point of view.

Do they also impact the output to the rig? What you say below implies that... I am a little confused on this now.
No, it does not impact the output channels in any way. If you look at the analog routing diagram on the Wiki page, the resistor in question is represented by the switches between the various pins and the respective Mic PGA. They aren’t straight switches, they are either off, or they switch in a resistor of one of the three values.

For the record, I am doing everything at 1200 for the initial testing here thus focusing on IN2. IN1 - 9600/GMSK will come later once I know things work the way I want.

Assume you mean the 7000 below, not the 7100? They appear similar as far as the data port specs are concerned, I just have not played with the 7100 all that much other than using its internal sound device for HRD/DM780 ops and as a modem for Spectrum Lab.

In the DRAWS implementation here, the IC-7000 and the FT-817 will get used (max portability), both of which I have used with audio/data and GMSK/data in the past. The IC-7100 here is happy as is, mostly acts as #2 in an SO2R set up, providing 144/440 coverage and HF D-STAR. The primary HF radio can't do that.

If you have something specific you would like me to look at, or a possible solution you want to test for one of these radios (assuming not all are available to you), please ask. I have or can scrounge pretty much any needed test equipment. I also have a PDF copy of the service manual for the IC-7000 which may provide more clarity for that radio if you think it might help.

KD4IZ
Jack Spitznagel
FM19oo

Re: Draws and IC-7000 #draws #ic7000 #minidin6

Jack Spitznagel
 

Hi Basil,

 

Again Thanks!!!

I understand these differences. Not confusing. I have been leaving the base config alone for now, but with the info from Annaliese yesterday and yours below, is speculative experimentation fair game now 😊?

 

Her notes on the implementation of the TI CODEC chip brought up these questions:

1. Should we disable the port not in use if only using 1 of them?? Annaliese suggests this would eliminate possibility of crosstalk. Is there a description of how you do this in the DRAWS wiki or your github pages? I missed it.

 

2. The info she sent about the PTM-P1/2/3 (DAC Left|Right Playback Powertune) settings for selecting the max output level suggests that the PTM-P1 setting should be default for the sensitive radios like the 7000. I look forward to seeing that available in Beta7. Where is it defaulting to now?

 

3. Her description of the three resistances associated with configuring input routing appear to be for the input only, I assume input from the rig? Do they also impact the output to the rig? What you say below implies that... I am a little confused on this now.

 

For the record, I am doing everything at 1200 for the initial testing here thus focusing on IN2. IN1 - 9600/GMSK will come later once I know things work the way I want.

 

Assume you mean the 7000 below, not the 7100? They appear similar as far as the data port specs are concerned, I just have not played with the 7100 all that much other than using its internal sound device for HRD/DM780 ops and as a modem for Spectrum Lab.

 

In the DRAWS implementation here, the IC-7000 and the FT-817 will get used (max portability), both of which I have used with audio/data and GMSK/data in the past. The IC-7100 here is happy as is, mostly acts as #2 in an SO2R set up, providing 144/440 coverage and HF D-STAR. The primary HF radio can't do that.

 

If you have something specific you would like me to look at, or a possible solution you want to test for one of these radios (assuming not all are available to you), please ask. I have or can scrounge pretty much any needed test equipment. I also have a PDF copy of the service manual for the IC-7000 which may provide more clarity for that radio if you think it might help.

 

KD4IZ

Jack Spitznagel

FM19oo

 

 

 

 

-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On Behalf Of Basil Gunn
Sent: Monday, December 31, 2018 15:18
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6

 

 

Hi Jack,

Thanks for all the info.

 

Just a couple of points. HF/VHF/UHF radios like the IC-7000, Yaesu FT-817, FT-857, Kenwood TS-2000 etc. need some understanding of their VHF/UFH packet & HF AFSK digital modes.

 

At least some of these radios route their vhf/uhf packet audio through their discriminator output & their HF AFSK output through AFOUT. The digital mode determines the pin used on the mDin6 connector so you need to route these pin properly with ALSA mixer settings. With the IC-7100 I think you have the option of setting the 1200 or 9600 bps output independent of the digital mode.

 

ALSA settings for routing to DISCOUT or AFOUT

IN1 (left & right) is for discriminator out (DISCOUT)

IN2 (left & right) is for audio out (AFOUT) These controls have the following options, 'Off' '10 kOhm' '20 kOhm' '40 kOhm' so you might try the different resistor values to knock down your signal level.

 

Also in the next couple of days with Beta7 image release you will have 2 more controls that will allow setting the output level, LO Playback Common Mode control and DAC Left & Right Playback PowerTune control.

 

In the IC-7100 manual there is a warning to never apply data levels over 0.6Vp-p  for TX audio in (DATA IN)

 

* 0.4 Vp-p (0.2 Vrms): recommended level

* 0.2-0.5 Vp-p (0.1-0.25 Vrms): acceptable level

 

I need to do more research for you wsjt-x problem.

 

/Basil

 

Jack Spitznagel <kd4iz@...> writes:

 

> Hopefully this experiment provides some useful info:

> I built a breakout strip to help solve the issues with overdrive of

> the

> IC-7000 in fldigi. As I began to put things together I went to the

> ICOM manual (version 5 English) to confirm how they label their pin

> position numbers on the diagram.

> Used a couple of "half cables" that I had from other projects in the

> past, rang out the pin connections, and lined them up on a proto strip

> so a jumper connected each together. This worked same as the mini Din6 cables supplied.

> IC-7000 pinout diagram is at the end of the email for those interested.

> Substituted a junk box 500KOhm pot in for the DATA IN jumper (probably

> overkill for what might really be needed). Ends of the resistor to the

> Pi side cable and to the cable shield/GND, the wiper was to the Radio

> side cable on DATA IN. The pot was initially set so there was no

> resistance in

nn> the DATA IN line.

> After boot, tested Xastir (my control state) first at the original

> alsamixer

> settings:

> PCM               L:[-21.50dB],    R:[-21.50dB

> ADC Level         L:[-2.00dB],     R:[-2.00dB]

> LO Driver Gain    L:[-6.00dB]      R:[-6.00dB]

> IN1               L:[10kOhm],      R:[10kOhm]

> IN2               L:[Off],         R:[Off]

> Xastir worked to spec in FM mode RX and TX.

> Killed AX25, then tested fldigi in USB mode at same alsamixer

> settings. As before, overdrove the radio input causing ALC reading to be high.

> Then increase resistance while transmitting into a dummy load and was

> able to reduce ALC reading considerably while maintaining output

> power. Signal looked clean on Spectrum Lab fed from another receiver.

> Shut down fldigi and restarted AX25/Direwolf. No longer enough audio

> there to drive the rig in FM mode. Sending with Xastir would key rig

> (using flrig) but no signal was TX. Removed the pot, put the jumper

> back in and Xastir could transmit as before.

> Key Findings:

> 1.         There is a difference between the audio input level the IC-7000

> wants for clean FM and for "ALC free SSB". Based on the position of

> the pot, that was a drive signal reduction of about 40 to 50%.

> 2.         For fldigi, the alsamixer PCM and LO Drive settings could be

> increased well above the -30dB noise floor (PCM to 0.00, LO Drive to

> 0.00) tweeking the pot a bit got ALC to essentially zero with rig

> power at ~30% (approximately 25 Watts) and still looking very clean.

> 3.         To confuse the issue, I still have found no way to get wsjt-x to TX

> with sufficient audio regardless of the settings of alsamixer. This

> apparent drive signal attenuation has got to be something wsjt-x is

> doing. Does not make sense.

> It would be great to find the "half-way point" where both HF programs

> and Direwolf use identical alsamixer settings.

> KD4IZ

> Jack Spitznagel

 

 


--
J Spitznagel
Science River LLC
KD4IZ

Re: DRAWS Codec Technical Documentation

Basil Gunn
 

Hi,

With DRAWS I noticed that PBEACON sendto=0 is sending APRS beacon on
left DIN6 (CHANNEL 0).

This is absolutely correct and in accordance with n7nix
measure_deviate.sh deviation script that sends modulation wav through sox.

However when using UDRC II modem and the same direwolf configuration
file, direwolf is sending beacon via HD15 plug.
Yep, that's correct.

If someone wants to send beacon via DIN6 when using UDRC II, PBEACON
sendto=1 must be used.

Is UDRC II CHANNEL inversion the result of a hardware difference between
UDRC II and DRAWS or a bug in UDRC II firmware ?
On Draws the convention is as you describe. Left connector is chan 0,
Right connector is chan 1.

On UDRC II HATs the DB 15 connector was made chan 0 and is the right
hand connector. So as you observed the Left & Right channel numbers are
flipped between the UDRC II & DRAWS.

/Basil


73 de Bernard, f6bvp

Le 31/12/2018 à 05:18, Annaliese McDermond a écrit:
I have just posted the following article to the UDRC/DRAWS Wiki:

https://nw-digital-radio.groups.io/g/udrc/wiki/DRAWS™-Audio-CODEC-Analog-Routing%2C-Digital-Interfacing-and-Controls

This is a technical document outlining the audio codec on the DRAWS, the TI TLV320AIC3204 and how we use it on the DRAWS board. It’s not designed to be a “how-to” guide or something to hold someone’s hand on how to solve their problem, but rather a technical document on how the hardware and software is designed to support the low level audio interface. If people feel there are missing pieces, please let me know and we’ll see if I can address them. Again, though, this isn’t designed to be a “how to set up your DRAWS” but a conceptual document to help the more technical minded folks understand what they’re dealing with.

--
Annaliese McDermond (NH6Z)
Xenotropic Systems
mcdermj@...



Bernard, F6BVP
http://f6bvp.org

Re: Draws and IC-7000 #draws #ic7000 #minidin6

Basil Gunn
 

Hi Jack,
Thanks for all the info.

Just a couple of points. HF/VHF/UHF radios like the IC-7000, Yaesu
FT-817, FT-857, Kenwood TS-2000 etc. need some understanding of their
VHF/UFH packet & HF AFSK digital modes.

At least some of these radios route their vhf/uhf packet audio through
their discriminator output & their HF AFSK output through AFOUT. The
digital mode determines the pin used on the mDin6 connector so you need
to route these pin properly with ALSA mixer settings. With the IC-7100 I
think you have the option of setting the 1200 or 9600 bps output
independent of the digital mode.

ALSA settings for routing to DISCOUT or AFOUT
IN1 (left & right) is for discriminator out (DISCOUT)
IN2 (left & right) is for audio out (AFOUT)
These controls have the following options, 'Off' '10 kOhm' '20 kOhm' '40
kOhm' so you might try the different resistor values to knock down your
signal level.

Also in the next couple of days with Beta7 image release you will have 2
more controls that will allow setting the output level, LO Playback
Common Mode control and DAC Left & Right Playback PowerTune control.

In the IC-7100 manual there is a warning to never apply data levels over
0.6Vp-p for TX audio in (DATA IN)

* 0.4 Vp-p (0.2 Vrms): recommended level
* 0.2-0.5 Vp-p (0.1-0.25 Vrms): acceptable level

I need to do more research for you wsjt-x problem.

/Basil

Jack Spitznagel <@flyingfrawg> writes:

Hopefully this experiment provides some useful info:

I built a breakout strip to help solve the issues with overdrive of the
IC-7000 in fldigi. As I began to put things together I went to the ICOM
manual (version 5 English) to confirm how they label their pin position
numbers on the diagram.

Used a couple of "half cables" that I had from other projects in the past,
rang out the pin connections, and lined them up on a proto strip so a jumper
connected each together. This worked same as the mini Din6 cables supplied.
IC-7000 pinout diagram is at the end of the email for those interested.

Substituted a junk box 500KOhm pot in for the DATA IN jumper (probably
overkill for what might really be needed). Ends of the resistor to the Pi
side cable and to the cable shield/GND, the wiper was to the Radio side
cable on DATA IN. The pot was initially set so there was no resistance in
nn> the DATA IN line.

After boot, tested Xastir (my control state) first at the original alsamixer
settings:

PCM L:[-21.50dB], R:[-21.50dB
ADC Level L:[-2.00dB], R:[-2.00dB]
LO Driver Gain L:[-6.00dB] R:[-6.00dB]
IN1 L:[10kOhm], R:[10kOhm]
IN2 L:[Off], R:[Off]



Xastir worked to spec in FM mode RX and TX.



Killed AX25, then tested fldigi in USB mode at same alsamixer settings. As
before, overdrove the radio input causing ALC reading to be high.



Then increase resistance while transmitting into a dummy load and was able
to reduce ALC reading considerably while maintaining output power. Signal
looked clean on Spectrum Lab fed from another receiver.



Shut down fldigi and restarted AX25/Direwolf. No longer enough audio there
to drive the rig in FM mode. Sending with Xastir would key rig (using flrig)
but no signal was TX. Removed the pot, put the jumper back in and Xastir
could transmit as before.



Key Findings:



1. There is a difference between the audio input level the IC-7000
wants for clean FM and for "ALC free SSB". Based on the position of the pot,
that was a drive signal reduction of about 40 to 50%.
2. For fldigi, the alsamixer PCM and LO Drive settings could be
increased well above the -30dB noise floor (PCM to 0.00, LO Drive to 0.00)
tweeking the pot a bit got ALC to essentially zero with rig power at ~30%
(approximately 25 Watts) and still looking very clean.
3. To confuse the issue, I still have found no way to get wsjt-x to TX
with sufficient audio regardless of the settings of alsamixer. This apparent
drive signal attenuation has got to be something wsjt-x is doing. Does not
make sense.



It would be great to find the "half-way point" where both HF programs and
Direwolf use identical alsamixer settings.



KD4IZ

Jack Spitznagel