1. udrc@nw-digital-radio.groups.io
   Date   
Re: It was "fine", then... strange behavior #betaimage #setup #draws

Gayland Gump
 

See text below for my response to Basil's response.
Gayland
KG7GCF


On Wed, Dec 19, 2018 at 11:46 AM Basil Gunn <basil@...> wrote:

Hi Gayland,
Thank you for testing the DRAWS board.

This email only addresses your audio problem.  First uncommenting the
dtparam=audio=on line in the /boot/config.txt should not cause your
system to become unusable. I'm guessing there was something else that
was changed/added in the config.txt file that caused that.

So I un-commented the  "dtparam=audio=on" line in the draws://boot/config.txt file, saved the file, and rebooted.  I then used the menu to launch fldigi.  Fldigi status line reported inability to access the Port Audio ports.  I then opened the Config Tab -> Clicked on the Audio Tab, then attempted to choose the udrc as the port audio device but it was unavailable, at this time the USER interface locked up.  I was forced to ssh into the box and kill fldigi.  I subsequently restored /boot/config.txt to its original condition and rebooted without any on board audio and successfully used the DRAWS to engage another ham for a few minutes.

I'll dive into the VERIFY_CONFIG doc and Xaster README for the information you've provided below.  

I have notes in the VERIFY_CONFIG doc & the Xastir README describing
what you need to do for enabling analog & HDMI sound on the RPi. This
functionality is unrelated to any of the UDRC/DRAWS hats.


It is at times difficult to discern what parts of this documentation are relevant to my use of the hats.  I'd pretty much moved away from any APRS, packet use and have been focusing on Fldigi functionality.  So Basil should I be following this instruction "Before verifying CORE functionality you must have run the app config script" with the new DRAWS betas or has that already been done?

Chrony and the gps both appear to be functional although the command "chrony makestep" did not seem to be updating the date time setting, but I just checked time on the DRAWS unit and it appears to have synced this time.  Does the chrony makestep need to be run every time the  unit is powered up of course that would make the RTC and battery sort of pointless wouldn't it?

Hope I am not being too much of a pain.  Thanks for you feedback.

I have added notes in the VERIFY_CONFIG.md file near the end for "Test
RPi sound"
https://github.com/nwdigitalradio/n7nix/blob/master/VERIFY_CONFIG.md

Also please check the xastir README.md under "Configure Audio"
https://github.com/nwdigitalradio/n7nix/blob/master/xastir/README.md

/Basil



Gayland Gump <kg7gcf@...> writes:

> I haven't the sophisticated knowledge of how the DRAWS & UDRC perform their
> magic but I have the following observations.
>
> Out of the box, the DRAWS would not work with my Yaesu 857D when running
> fldigi. I believe that the PTT wasn't working immediately after I did the
> initial configuration of fldigi but I can't be sure.  Thinking back a
> couple years or so when I first got my first UDRC I began to suspect the
> ALSA settings.  Examining the UDRC settings and comparing them to the DRAWS
> I tried changing a couple of the parameters on the DRAWS to correspond to
> those on the UDRC.  After a couple changing a single parameter at a time
> with no change in outcome.
>
> I realized that on the UDRC I had the on board audio turned on.  In order
> to model the working UDRC, I decided to activate the onboard audio using
> the "dtparam=audio=on" parameter in the /boot/config.txt file on the
> DRAWS.  I had no definite rationale for doing this other than to eliminate
> another difference in the UDRC and DRAWS configurations.  The impact of
> making that change in situ on the DRAWS was disastrous as on a reboot the
> system was entirely un-useable.  I immediately reversed that change and
> returned to pursuing the ALSA settings.
>
> As my earlier approach of changing single ALSA parameters had not yielded
> any change in fldigi's performance, I did a wholesale change of the DRAWS
> alsa settings to those that were currently in place on my working UDRC.
> After completing these changes, the DRAWS was able to transmit and
> receive.  There are still some issues though.
>
> First, there is a significant difference in SNR reports on the UDRC vs the
> DRAWS.  DRAWS levels appear to be 10 or more DB lower than those being
> reported by fldigi on the UDRC.  As all I do to obtain these observations
> is move the 6-pin DIN connector back and forth between the UDRC and DRAWS
> using identical ALSA settings, I'd like to know what might be causing the
> differences in the SNR reports between those devices.
>
> Another difference, which I note between the DRAWS and UDRC which may well
> be related to the level differences is in the fldigi waterfall display.  To
> the best of my knowledge the applicable waterfall settings on the DRAWS and
> the UDRC but the displays are significantly different.   I've got my UDRC
> set so that the waterfall shows a constant noise level.  Lots of others
> seem to prefer having a noiseless screen that only display's stronger
> signals.  I find that by leaving the display set so that it displays noise
> I am able to visually identify some weak FSQ signal patterns.
>
> I'd also like to know what it takes to get the on board audio working on
> the DRAWS after all some of the software running on the DRAWS provides
> audio cues that it might be nice to use.  Of course assuming that those
> cues can be delivered to the on board audio for presentation.
>
> I want to applaud all of NWDR's efforts at bringing us some very cool and
> useful tools.  I also recognize that providing documentary support for
> these tool is extremely challenging given the resources available.   Given
> the constraints, I know that it is a lot to expect that NDWR keep in mind
> that we users including early adopters often don't have the necessary depth
> of knowledge that NDWR folks have and expecting us to know about
> non-standard applications (e.g. chrony vs ntp) or even basic linux system
> operations need to be carefully considered assumptions.
>
> Finally, I'd like to find out if NWDR has any ideas why I'd be seeing the
> differences in SNR that appear between the DRAWS and UDRC?  What have I
> overlooked or just don't know about?
>
> Thanks again for your time and attention.
>
> Gayland
> KG7GCF
>
>
> On Wed, Dec 19, 2018 at 7:07 AM Jack Spitznagel <kd4iz@...> wrote:
>
>> Basil, John, All,
>>
>> Initially, Beta 5 seemed to work out of the box but I ran into some DRAWS
>> audio and keying strangeness that is baffling me after 3 tries at
>> installing from newly flashed microSD cards and following Basil's latest
>> procedure on GitHub. Hope you can provide insight. Rig is a CAT controlled
>> IC-7000.
>>
>> Tested Direwolf with Xastir and YAAC with both RX and TX successfully, but
>> noticed the audio was a bit hot - signal here looked normal on the SpecLab
>> so I left it alone.
>>
>> Then disabled AX.25/direwolf (script) and configured fldigi and wsjt-x.
>> Both programs worked in receive but the TX audio to the IC-7000 was very
>> "hot". Put fldigi in tune then to bring the ALC reading as close to zero as
>> possible by reducing audio levels with the PCM drive control. As audio
>> level is reduced - the ALC starts to "pump", as did the power out
>> indication - unexpectedly, there was a increase of noise on audio and
>> harmonic spikes got higher as level of signal was reduced. Returned levels
>> to where they had been and meter indications returned to where they were
>> before. Was able to have a PSK31 QSO and got no comment about the signal
>> quality.
>>
>> I re-enabled AX.25/Direwolf using the script. Now both Xastir and YAAC no
>> longer would transmit audio. When the rig is keyed, the TX LED on the rig
>> flashes 3-4 times quickly and there is no modulation of the FM carrier.
>> Reboot did not change behavior. Going back to non-AX25 mode, now fldigi
>> would key the radio, but  no modulation occurred.
>>
>> Re-installation of the DRAWS beta 5 from the ground up (x2) did not help -
>> none of the programs transmit audio and symptoms are the same.
>>
>> To be sure rig was OK, I hooked up an old SIgnaLink to a laptop, ran HRD
>> and it drove and keyed the rig just fine. So I have to assume that the
>> problem is software or DRAWS hardware related.
>>
>> Where should I be looking to fix the audio? The keying?
>> Settings should not so brittle. Thanks in advance,
>> --
>> J Spitznagel - KD4IZ
>> Science River LLC
>> KD4IZ
>>
>>
>>
>
>



#js8call #upgrade Fwd: [JS8Call] JS8Call 0.11.0 Released - Auto ACK relays, Stations Heard Command is Back, and the start of a message inbox! #js8call #upgrade #release

John D Hays - K7VE
 

If you have one of our beta images, you can quickly upgrade.  From a terminal perform the following:

cd /tmp
wget https://s3.amazonaws.com/js8call/0.11.0/js8call_0.11.0-devel_armhf.deb
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install /tmp/js8call_0.11.0-devel_armhf.deb
cd
# cleanup
rm /tmp/js8call_0.11.0-devel_armhf.deb


---------- Forwarded message ---------
From: Jordan Sherer / KN4CRD <js8call+owner@groups.io>
Date: Tue, Dec 18, 2018 at 8:15 PM
Subject: [JS8Call] JS8Call 0.11.0 Released - Auto ACK relays, Stations Heard Command is Back, and the start of a message inbox! #release
To: <js8call@groups.io>


Howdy Folks!

I've released 0.11.0 of JS8Call. This is intended to be the last release that will break backwards compatibility (hooray) which means that we're getting much closer to a 1.0 general release. Go grab your updated copy: https://groups.io/g/js8call/wiki/Download-Links

What's changed? A few things!
  • The stations heard command ("HEARING?") is back. Stations will respond with the top four callsigns most recently heard.
  • Relays now "auto ack" back to the original sender. That makes it much easier to know whether or not a message was delivered. 
    • Because of this, the "#" message was replaced by the same mechanism that relays use ">". So, if you send:   J1Y>HELLO    that would be the equivalent of    J1Y#HELLO
    • The nice thing about this? These messages now get stored in a message inbox and display a flag indicator next to the callsign. Then, double clicking on the callsign will allow you to ignore it for now and respond to the message later. Here's what it looks like:

      Then... a double click:
    • I have a bunch of ideas for improving on this in the future...so keep an eye out for more on this "inbox" idea :)
  • The send button is now red while transmitting. Plus the text changes to be more clear about when a message is queued for transmit vs transmitting: 
     & 
  • Plus a bunch of bug fixes!
As usual, if you have an idea for an improvement or run into a bug/issue, head over to the issues list to report it: https://bitbucket.org/widefido/js8call/issues?status=new&status=open

You can always shoot me a note, too. Happy to help!

Hope you enjoy the holidays and the upcoming New Year! 

Cheers y'all! 

Best,
Jordan / KN4CRD

Full Changelog:
      Updated README with new links and history line items
      Fixed issue with repeat messages
      Fixed #23: Log window should not halt transmission
      Fixed #28: band activity clear should not deselect callsign selected in call activity
      Fixed #38: Moved Show Heartbeats menu item to the View menu
      Fixed #40: Force uppercase without resetting text
      Experiment with compression
      Configurable slots
      Fixed button alignment
      Simplify conditional
      Updated comments to be more clear
      Rename JS8CallExtended to JS8CallFlag
      Fixed rebase issues
      Fixed rebase issues
      Fixed defines and % in the send button
      Changed send button color while sending and label when ready
      Fixed #41: remember pane sizes when showing/hiding
      Removed comments
      Fixed #43: space prefix should not break directed call
      Fixed #23: idle watchdog should prevent all types of automated transmissions
      Fixed #13: configuration validator should require cq or callsign in cq message
      Fixed #16: do not symlink js8call in usr if not using the opt install prefix
      Added HEARING query back into the app
      Removed QRZ short message
      Removed unused commands
      Fixed heartbeat sub-channel configuration
      Bump eol and versions to 0.11.0
      Added automatic ACK for relay messages
      Removed hash messages '#' as they are now duplicated by relay '>'
      Updated about messaging
      Added relay message storage and display in the call activity list
 



--

John D. Hays
Director

  
Re: It was "fine", then... strange behavior #betaimage #setup #draws

Basil Gunn
 

Hi Gayland,
Thank you for testing the DRAWS board.

This email only addresses your audio problem. First uncommenting the
dtparam=audio=on line in the /boot/config.txt should not cause your
system to become unusable. I'm guessing there was something else that
was changed/added in the config.txt file that caused that.

I have notes in the VERIFY_CONFIG doc & the Xastir README describing
what you need to do for enabling analog & HDMI sound on the RPi. This
functionality is unrelated to any of the UDRC/DRAWS hats.

I have added notes in the VERIFY_CONFIG.md file near the end for "Test
RPi sound"
https://github.com/nwdigitalradio/n7nix/blob/master/VERIFY_CONFIG.md

Also please check the xastir README.md under "Configure Audio"
https://github.com/nwdigitalradio/n7nix/blob/master/xastir/README.md

/Basil



Gayland Gump <kg7gcf@gmail.com> writes:

I haven't the sophisticated knowledge of how the DRAWS & UDRC perform their
magic but I have the following observations.

Out of the box, the DRAWS would not work with my Yaesu 857D when running
fldigi. I believe that the PTT wasn't working immediately after I did the
initial configuration of fldigi but I can't be sure. Thinking back a
couple years or so when I first got my first UDRC I began to suspect the
ALSA settings. Examining the UDRC settings and comparing them to the DRAWS
I tried changing a couple of the parameters on the DRAWS to correspond to
those on the UDRC. After a couple changing a single parameter at a time
with no change in outcome.

I realized that on the UDRC I had the on board audio turned on. In order
to model the working UDRC, I decided to activate the onboard audio using
the "dtparam=audio=on" parameter in the /boot/config.txt file on the
DRAWS. I had no definite rationale for doing this other than to eliminate
another difference in the UDRC and DRAWS configurations. The impact of
making that change in situ on the DRAWS was disastrous as on a reboot the
system was entirely un-useable. I immediately reversed that change and
returned to pursuing the ALSA settings.

As my earlier approach of changing single ALSA parameters had not yielded
any change in fldigi's performance, I did a wholesale change of the DRAWS
alsa settings to those that were currently in place on my working UDRC.
After completing these changes, the DRAWS was able to transmit and
receive. There are still some issues though.

First, there is a significant difference in SNR reports on the UDRC vs the
DRAWS. DRAWS levels appear to be 10 or more DB lower than those being
reported by fldigi on the UDRC. As all I do to obtain these observations
is move the 6-pin DIN connector back and forth between the UDRC and DRAWS
using identical ALSA settings, I'd like to know what might be causing the
differences in the SNR reports between those devices.

Another difference, which I note between the DRAWS and UDRC which may well
be related to the level differences is in the fldigi waterfall display. To
the best of my knowledge the applicable waterfall settings on the DRAWS and
the UDRC but the displays are significantly different. I've got my UDRC
set so that the waterfall shows a constant noise level. Lots of others
seem to prefer having a noiseless screen that only display's stronger
signals. I find that by leaving the display set so that it displays noise
I am able to visually identify some weak FSQ signal patterns.

I'd also like to know what it takes to get the on board audio working on
the DRAWS after all some of the software running on the DRAWS provides
audio cues that it might be nice to use. Of course assuming that those
cues can be delivered to the on board audio for presentation.

I want to applaud all of NWDR's efforts at bringing us some very cool and
useful tools. I also recognize that providing documentary support for
these tool is extremely challenging given the resources available. Given
the constraints, I know that it is a lot to expect that NDWR keep in mind
that we users including early adopters often don't have the necessary depth
of knowledge that NDWR folks have and expecting us to know about
non-standard applications (e.g. chrony vs ntp) or even basic linux system
operations need to be carefully considered assumptions.

Finally, I'd like to find out if NWDR has any ideas why I'd be seeing the
differences in SNR that appear between the DRAWS and UDRC? What have I
overlooked or just don't know about?

Thanks again for your time and attention.

Gayland
KG7GCF


On Wed, Dec 19, 2018 at 7:07 AM Jack Spitznagel <kd4iz@frawg.org> wrote:

Basil, John, All,

Initially, Beta 5 seemed to work out of the box but I ran into some DRAWS
audio and keying strangeness that is baffling me after 3 tries at
installing from newly flashed microSD cards and following Basil's latest
procedure on GitHub. Hope you can provide insight. Rig is a CAT controlled
IC-7000.

Tested Direwolf with Xastir and YAAC with both RX and TX successfully, but
noticed the audio was a bit hot - signal here looked normal on the SpecLab
so I left it alone.

Then disabled AX.25/direwolf (script) and configured fldigi and wsjt-x.
Both programs worked in receive but the TX audio to the IC-7000 was very
"hot". Put fldigi in tune then to bring the ALC reading as close to zero as
possible by reducing audio levels with the PCM drive control. As audio
level is reduced - the ALC starts to "pump", as did the power out
indication - unexpectedly, there was a increase of noise on audio and
harmonic spikes got higher as level of signal was reduced. Returned levels
to where they had been and meter indications returned to where they were
before. Was able to have a PSK31 QSO and got no comment about the signal
quality.

I re-enabled AX.25/Direwolf using the script. Now both Xastir and YAAC no
longer would transmit audio. When the rig is keyed, the TX LED on the rig
flashes 3-4 times quickly and there is no modulation of the FM carrier.
Reboot did not change behavior. Going back to non-AX25 mode, now fldigi
would key the radio, but no modulation occurred.

Re-installation of the DRAWS beta 5 from the ground up (x2) did not help -
none of the programs transmit audio and symptoms are the same.

To be sure rig was OK, I hooked up an old SIgnaLink to a laptop, ran HRD
and it drove and keyed the rig just fine. So I have to assume that the
problem is software or DRAWS hardware related.

Where should I be looking to fix the audio? The keying?
Settings should not so brittle. Thanks in advance,
--
J Spitznagel - KD4IZ
Science River LLC
KD4IZ
Re: It was "fine", then... strange behavior #betaimage #setup #draws

Jack Spitznagel
 

Basil,

Thanks for the quick response.

I understand setting of PCM and LO Driver Gain. If I started with PCM at
zero, I could not turn LO Drive down far enough to prevent the IC-7000 doing
the "protect -self" routine and shut down transmit. Had to turn it way down
from there to have the stupid little beast transmit anything particularly a
noisy but decodable PSK31 sig!

Quick follow up with more info. At those drive levels below, direwolf is
still behaving fine - the audio is loud and clean enough that my D74A and a
creaky old AEA PK232 running as a KISS TNC can both handle it.

It is with fldigi direct to sound that is having the noise and modulation
problems? Confusing for me, but might tell you something. I am not aware of
"transmit power" adjust in fldigi like there is in wsjt-x. It might be
something the program is doing? I have used fldigi a bit, but usually in
"winders 10" prefer other digital programs.

Jack

-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On
Behalf Of Jack Spitznagel
Sent: Wednesday, December 19, 2018 13:52
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] It was "fine", then... strange behavior #betaimage
#setup #draws

Basil,

That test got me part of the way there. DRAWS was apparently overdriving the
audio front end of the IC-7000, hence the flashing TX led. I did not know it
did that! The *showudrc.sh* output is at the end of the email.
Initially *alsa-show.sh* said:
PCM L:[0.00dB], R:[0.00dB]
ADC Level L:[-2.00dB], R:[0.50dB]
LO Driver Gain L:[0.00dB], R:[11.00dB]

Using the *measure_deviate.sh* script, I was able to turn the levels back to
a point that the tone was "fairly" clean. The AGC indication was still very
high with *alsa-show.sh* now saying:
PCM L:[-31.00dB], R:[-31.00dB]
ADC Level L:[-2.00dB], R:[0.50dB]
LO Driver Gain L:[6.00dB], R:[6.00dB]

When I turned PCM back any more than that, the background noise (frying
bacon) being transmitted increased and quickly overwhelmed the tone level.
That was the ALC pumping I was seeing.

Observation: As it is set now, the circuit noise level is extremely high.
Apparently the IC-7000 input is pretty sensitive and/or badly impedance
matched?

Looks like I will need to build some kind of attenuation if the DRAWS board
does not have the ability to dial it in? (I have not gotten that far in the
documentation yet)

Unfortunately, I will have to put off any additional tweaking until Friday.

Jack - KD4IZ

I did not see anything grossly out-of-line in the *showudrc.sh* output
follows:
============================================================================
pi@kd4iz_draws:/bin $ showudrc.sh
==== Sound Card ====
udrc card number line: card 0: udrc [udrc], device 0: Universal Digital
Radio Controller tlv320aic32x4-hifi-0 [] udrc is sound card #0 ==== Pi Ver
==== Pi 3 Model B+ Mfg by Sony UK Has WiFi ==== udrc Ver ==== Found a
DRAWS

HAT ID EEPROM
Name: hat
Product: Digital Radio Amateur Work Station
Product ID: 0x0004
Product ver: 0x0204
UUID: 78feb572-30c1-420b-8596-f37186c9cb16
Vendor: NW Digital Radio

==== sys Ver ====
----- /proc/version
Linux version 4.14.79-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3
(crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1159 SMP Sun Nov 4 17:50:20
GMT 2018

----- /etc/*version: 9.6

----- /etc/*release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/";
SUPPORT_URL="http://www.raspbian.org/RaspbianForums";
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs";

----- lsb_release
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.6 (stretch)
Release: 9.6
Codename: stretch

---- systemd
Static hostname: kd4iz_draws
Icon name: computer
Machine ID: 2f51e140e908474eaa86ae805f03a6d8
Boot ID: b9e8d2eefb9f401a8884c0d1f9d7c2d3
Operating System: Raspbian GNU/Linux 9 (stretch)
Kernel: Linux 4.14.79-v7+
Architecture: arm

---- modules
tlv320aic32x4_i2c 16384 1
tlv320aic32x4 32768 1 tlv320aic32x4_i2c
udrc 16384 3
snd_soc_core 188416 3 tlv320aic32x4,snd_soc_bcm2835_i2s,udrc
snd_pcm 98304 6
snd_pcm_dmaengine,tlv320aic32x4,snd_soc_bcm2835_i2s,snd_soc_core

-rw-r--r-- 1 root 6388 Dec 8 19:59
/lib/modules/4.14.79-v7+/updates/dkms/tlv320aic32x4-i2c.ko
-rw-r--r-- 1 root 38156 Dec 8 19:59
/lib/modules/4.14.79-v7+/updates/dkms/tlv320aic32x4.ko
-rw-r--r-- 1 root 6408 Dec 8 19:59
/lib/modules/4.14.79-v7+/updates/dkms/tlv320aic32x4-spi.ko
-rw-r--r-- 1 root 8332 Dec 8 19:59
/lib/modules/4.14.79-v7+/updates/dkms/udrc.ko

---- kernel
||/ Name Version Architecture Description
+++-==================-============-============-=======================
+++====
======
ii raspberrypi-kernel 1.20181112-1 armhf Raspberry Pi bootloader
ii udrc-dkms 1.0.4 armhf DKMS source for the UDRC
driver

---- compass
Compass preference file not found: /etc/apt/preferences.d/compass
---- compass apt sources list file
deb [arch=armhf,amd64] http://archive.compasslinux.org/ cedar main
---- compass package files
-rw-r--r-- 1 root 2201 Nov 25 23:31
/var/lib/apt/lists/archive.compasslinux.org_dists_cedar_InRelease
-rw-r--r-- 1 root 17567 Jul 2 22:52
/var/lib/apt/lists/archive.compasslinux.org_dists_cedar_main_binary-amd64_Pa
ckages
-rw-r--r-- 1 root 43315 Nov 25 23:31
/var/lib/apt/lists/archive.compasslinux.org_dists_cedar_main_binary-armhf_Pa
ckages

----- Dire Wolf DEVELOPMENT version 1.6 A (Dec 9 2018)

==== boot config ====
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module #dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
# dtparam=audio=on

force_turbo=1
dtoverlay=
dtoverlay=draws

---- gpsd
● gpsd.service - GPS (Global Positioning System) Daemon
Loaded: loaded (/lib/systemd/system/gpsd.service; indirect; vendor
preset: en
Active: active (running) since Fri 2018-12-14 20:49:52 EST; 4 days ago
Main PID: 4274 (gpsd)
CGroup: /system.slice/gpsd.service
└─4274 /usr/sbin/gpsd -N -n /dev/ttySC0 /dev/pps0

Dec 14 20:49:52 kd4iz_draws systemd[1]: Started GPS (Global Positioning
System)
lines 1-8/8 (END)
============================================================================
===

-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On
Behalf Of Basil Gunn
Sent: Wednesday, December 19, 2018 12:13
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] It was "fine", then... strange behavior #betaimage
#setup #draws


In general for debugging problems:

Send output of:
~/bin/showudrc.sh
~/n7nix/debug/alsa-show.sh

Use the following instructions for measure_deviate.sh to verify PTT &
transmit paths.
https://github.com/nwdigitalradio/n7nix/tree/master/deviation

Using another radio listen to the tone produced by the measure_deviate.sh
script.

The most common problem, if the tones do not sound right, is the output is
being over driven causing it to clip.

Receive path:
Tune a radio to the APRS 1200 baud freq. 144.390 MHz run the following in a
console:

tail -f /var/log/direwolf/direwolf.log

You should see received packets scrolling by.

Let us know what you find & thanks for testing the DRAWS hat.

/Basil

Jack Spitznagel <kd4iz@frawg.org> writes:

Basil, John, All,

Initially, Beta 5 seemed to work out of the box but I ran into some
DRAWS audio and keying strangeness that is baffling me after 3 tries
at installing from newly flashed microSD cards and following Basil's
latest procedure on GitHub. Hope you can provide insight. Rig is a CAT
controlled IC-7000.

Tested Direwolf with Xastir and YAAC with both RX and TX successfully,
but
noticed the audio was a bit hot - signal here looked normal on the SpecLab
so I left it alone.

Then disabled AX.25/direwolf (script) and configured fldigi and wsjt-x.
Both programs worked in receive but the TX audio to the IC-7000 was very
"hot". Put fldigi in tune then to bring the ALC reading as close to zero as
possible by reducing audio levels with the PCM drive control. As audio level
is reduced - the ALC starts to "pump", as did the power out indication -
unexpectedly, there was a increase of noise on audio and harmonic spikes got
higher as level of signal was reduced. Returned levels to where they had
been and meter indications returned to where they were before. Was able to
have a PSK31 QSO and got no comment about the signal quality.

I re-enabled AX.25/Direwolf using the script. Now both Xastir and YAAC
no
longer would transmit audio. When the rig is keyed, the TX LED on the rig
flashes 3-4 times quickly and there is no modulation of the FM carrier.
Reboot did not change behavior. Going back to non-AX25 mode, now fldigi
would key the radio, but no modulation occurred.

Re-installation of the DRAWS beta 5 from the ground up (x2) did not
help -
none of the programs transmit audio and symptoms are the same.

To be sure rig was OK, I hooked up an old SIgnaLink to a laptop, ran
HRD
and it drove and keyed the rig just fine. So I have to assume that the
problem is software or DRAWS hardware related.

Where should I be looking to fix the audio? The keying?
Settings should not so brittle. Thanks in advance,





--
J Spitznagel
Science River LLC
KD4IZ






--
J Spitznagel
Science River LLC
KD4IZ
Re: It was "fine", then... strange behavior #betaimage #setup #draws

Basil Gunn
 

Hi Jack,
Thanks for the console output.

Your PCM /LO Driver Gain settings seem off to me.
Those are the 2 controls for setting DAC output (deviation).

The PCM control is the digital output setting & controls the number of
bits the DAC will use. You should try setting LO Driver Gain first,
leaving PCM at zero.

ADC level is the receive level setting & I use the direwolf output in
the /var/log/direwolf/direwolf.log to dial that value in. Receive signal
strength should be around 50 according to direwolf.

Will look for your response next Friday.
/Basil


Jack Spitznagel <kd4iz@frawg.org> writes:

Basil,

That test got me part of the way there. DRAWS was apparently overdriving the
audio front end of the IC-7000, hence the flashing TX led. I did not know it
did that! The *showudrc.sh* output is at the end of the email.
Initially *alsa-show.sh* said:
PCM L:[0.00dB], R:[0.00dB]
ADC Level L:[-2.00dB], R:[0.50dB]
LO Driver Gain L:[0.00dB], R:[11.00dB]

Using the *measure_deviate.sh* script, I was able to turn the levels back to
a point that the tone was "fairly" clean. The AGC indication was still very
high with *alsa-show.sh* now saying:
PCM L:[-31.00dB], R:[-31.00dB]
ADC Level L:[-2.00dB], R:[0.50dB]
LO Driver Gain L:[6.00dB], R:[6.00dB]

When I turned PCM back any more than that, the background noise (frying
bacon) being transmitted increased and quickly overwhelmed the tone level.
That was the ALC pumping I was seeing.

Observation: As it is set now, the circuit noise level is extremely high.
Apparently the IC-7000 input is pretty sensitive and/or badly impedance
matched?

Looks like I will need to build some kind of attenuation if the DRAWS board
does not have the ability to dial it in? (I have not gotten that far in the
documentation yet)

Unfortunately, I will have to put off any additional tweaking until Friday.

Jack - KD4IZ

I did not see anything grossly out-of-line in the *showudrc.sh* output
follows:
============================================================================
pi@kd4iz_draws:/bin $ showudrc.sh
==== Sound Card ====
udrc card number line: card 0: udrc [udrc], device 0: Universal Digital
Radio Controller tlv320aic32x4-hifi-0 []
udrc is sound card #0
==== Pi Ver ====
Pi 3 Model B+ Mfg by Sony UK
Has WiFi
==== udrc Ver ====
Found a DRAWS

HAT ID EEPROM
Name: hat
Product: Digital Radio Amateur Work Station
Product ID: 0x0004
Product ver: 0x0204
UUID: 78feb572-30c1-420b-8596-f37186c9cb16
Vendor: NW Digital Radio

==== sys Ver ====
----- /proc/version
Linux version 4.14.79-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3
(crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1159 SMP Sun Nov 4 17:50:20
GMT 2018

----- /etc/*version: 9.6

----- /etc/*release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/";
SUPPORT_URL="http://www.raspbian.org/RaspbianForums";
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs";

----- lsb_release
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.6 (stretch)
Release: 9.6
Codename: stretch

---- systemd
Static hostname: kd4iz_draws
Icon name: computer
Machine ID: 2f51e140e908474eaa86ae805f03a6d8
Boot ID: b9e8d2eefb9f401a8884c0d1f9d7c2d3
Operating System: Raspbian GNU/Linux 9 (stretch)
Kernel: Linux 4.14.79-v7+
Architecture: arm

---- modules
tlv320aic32x4_i2c 16384 1
tlv320aic32x4 32768 1 tlv320aic32x4_i2c
udrc 16384 3
snd_soc_core 188416 3 tlv320aic32x4,snd_soc_bcm2835_i2s,udrc
snd_pcm 98304 6
snd_pcm_dmaengine,tlv320aic32x4,snd_soc_bcm2835_i2s,snd_soc_core

-rw-r--r-- 1 root 6388 Dec 8 19:59
/lib/modules/4.14.79-v7+/updates/dkms/tlv320aic32x4-i2c.ko
-rw-r--r-- 1 root 38156 Dec 8 19:59
/lib/modules/4.14.79-v7+/updates/dkms/tlv320aic32x4.ko
-rw-r--r-- 1 root 6408 Dec 8 19:59
/lib/modules/4.14.79-v7+/updates/dkms/tlv320aic32x4-spi.ko
-rw-r--r-- 1 root 8332 Dec 8 19:59
/lib/modules/4.14.79-v7+/updates/dkms/udrc.ko

---- kernel
||/ Name Version Architecture Description
+++-==================-============-============-===========================
======
ii raspberrypi-kernel 1.20181112-1 armhf Raspberry Pi bootloader
ii udrc-dkms 1.0.4 armhf DKMS source for the UDRC
driver

---- compass
Compass preference file not found: /etc/apt/preferences.d/compass
---- compass apt sources list file
deb [arch=armhf,amd64] http://archive.compasslinux.org/ cedar main
---- compass package files
-rw-r--r-- 1 root 2201 Nov 25 23:31
/var/lib/apt/lists/archive.compasslinux.org_dists_cedar_InRelease
-rw-r--r-- 1 root 17567 Jul 2 22:52
/var/lib/apt/lists/archive.compasslinux.org_dists_cedar_main_binary-amd64_Pa
ckages
-rw-r--r-- 1 root 43315 Nov 25 23:31
/var/lib/apt/lists/archive.compasslinux.org_dists_cedar_main_binary-armhf_Pa
ckages

----- Dire Wolf DEVELOPMENT version 1.6 A (Dec 9 2018)

==== boot config ====
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
# dtparam=audio=on

force_turbo=1
dtoverlay=
dtoverlay=draws

---- gpsd
● gpsd.service - GPS (Global Positioning System) Daemon
Loaded: loaded (/lib/systemd/system/gpsd.service; indirect; vendor
preset: en
Active: active (running) since Fri 2018-12-14 20:49:52 EST; 4 days ago
Main PID: 4274 (gpsd)
CGroup: /system.slice/gpsd.service
└─4274 /usr/sbin/gpsd -N -n /dev/ttySC0 /dev/pps0

Dec 14 20:49:52 kd4iz_draws systemd[1]: Started GPS (Global Positioning
System)
lines 1-8/8 (END)
============================================================================
===

-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On
Behalf Of Basil Gunn
Sent: Wednesday, December 19, 2018 12:13
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] It was "fine", then... strange behavior #betaimage
#setup #draws


In general for debugging problems:

Send output of:
~/bin/showudrc.sh
~/n7nix/debug/alsa-show.sh

Use the following instructions for measure_deviate.sh to verify PTT &
transmit paths.
https://github.com/nwdigitalradio/n7nix/tree/master/deviation

Using another radio listen to the tone produced by the measure_deviate.sh
script.

The most common problem, if the tones do not sound right, is the output is
being over driven causing it to clip.

Receive path:
Tune a radio to the APRS 1200 baud freq. 144.390 MHz run the following in a
console:

tail -f /var/log/direwolf/direwolf.log

You should see received packets scrolling by.

Let us know what you find & thanks for testing the DRAWS hat.

/Basil

Jack Spitznagel <kd4iz@frawg.org> writes:

Basil, John, All,

Initially, Beta 5 seemed to work out of the box but I ran into some
DRAWS audio and keying strangeness that is baffling me after 3 tries
at installing from newly flashed microSD cards and following Basil's
latest procedure on GitHub. Hope you can provide insight. Rig is a CAT
controlled IC-7000.

Tested Direwolf with Xastir and YAAC with both RX and TX successfully, but
noticed the audio was a bit hot - signal here looked normal on the SpecLab
so I left it alone.

Then disabled AX.25/direwolf (script) and configured fldigi and wsjt-x.
Both programs worked in receive but the TX audio to the IC-7000 was very
"hot". Put fldigi in tune then to bring the ALC reading as close to zero as
possible by reducing audio levels with the PCM drive control. As audio level
is reduced - the ALC starts to "pump", as did the power out indication -
unexpectedly, there was a increase of noise on audio and harmonic spikes got
higher as level of signal was reduced. Returned levels to where they had
been and meter indications returned to where they were before. Was able to
have a PSK31 QSO and got no comment about the signal quality.

I re-enabled AX.25/Direwolf using the script. Now both Xastir and YAAC no
longer would transmit audio. When the rig is keyed, the TX LED on the rig
flashes 3-4 times quickly and there is no modulation of the FM carrier.
Reboot did not change behavior. Going back to non-AX25 mode, now fldigi
would key the radio, but no modulation occurred.

Re-installation of the DRAWS beta 5 from the ground up (x2) did not help -
none of the programs transmit audio and symptoms are the same.

To be sure rig was OK, I hooked up an old SIgnaLink to a laptop, ran HRD
and it drove and keyed the rig just fine. So I have to assume that the
problem is software or DRAWS hardware related.

Where should I be looking to fix the audio? The keying?
Settings should not so brittle. Thanks in advance,
Re: It was "fine", then... strange behavior #betaimage #setup #draws

Jack Spitznagel
 

Basil,

That test got me part of the way there. DRAWS was apparently overdriving the
audio front end of the IC-7000, hence the flashing TX led. I did not know it
did that! The *showudrc.sh* output is at the end of the email.
Initially *alsa-show.sh* said:
PCM L:[0.00dB], R:[0.00dB]
ADC Level L:[-2.00dB], R:[0.50dB]
LO Driver Gain L:[0.00dB], R:[11.00dB]

Using the *measure_deviate.sh* script, I was able to turn the levels back to
a point that the tone was "fairly" clean. The AGC indication was still very
high with *alsa-show.sh* now saying:
PCM L:[-31.00dB], R:[-31.00dB]
ADC Level L:[-2.00dB], R:[0.50dB]
LO Driver Gain L:[6.00dB], R:[6.00dB]

When I turned PCM back any more than that, the background noise (frying
bacon) being transmitted increased and quickly overwhelmed the tone level.
That was the ALC pumping I was seeing.

Observation: As it is set now, the circuit noise level is extremely high.
Apparently the IC-7000 input is pretty sensitive and/or badly impedance
matched?

Looks like I will need to build some kind of attenuation if the DRAWS board
does not have the ability to dial it in? (I have not gotten that far in the
documentation yet)

Unfortunately, I will have to put off any additional tweaking until Friday.

Jack - KD4IZ

I did not see anything grossly out-of-line in the *showudrc.sh* output
follows:
============================================================================
pi@kd4iz_draws:/bin $ showudrc.sh
==== Sound Card ====
udrc card number line: card 0: udrc [udrc], device 0: Universal Digital
Radio Controller tlv320aic32x4-hifi-0 []
udrc is sound card #0
==== Pi Ver ====
Pi 3 Model B+ Mfg by Sony UK
Has WiFi
==== udrc Ver ====
Found a DRAWS

HAT ID EEPROM
Name: hat
Product: Digital Radio Amateur Work Station
Product ID: 0x0004
Product ver: 0x0204
UUID: 78feb572-30c1-420b-8596-f37186c9cb16
Vendor: NW Digital Radio

==== sys Ver ====
----- /proc/version
Linux version 4.14.79-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3
(crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1159 SMP Sun Nov 4 17:50:20
GMT 2018

----- /etc/*version: 9.6

----- /etc/*release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/";
SUPPORT_URL="http://www.raspbian.org/RaspbianForums";
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs";

----- lsb_release
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.6 (stretch)
Release: 9.6
Codename: stretch

---- systemd
Static hostname: kd4iz_draws
Icon name: computer
Machine ID: 2f51e140e908474eaa86ae805f03a6d8
Boot ID: b9e8d2eefb9f401a8884c0d1f9d7c2d3
Operating System: Raspbian GNU/Linux 9 (stretch)
Kernel: Linux 4.14.79-v7+
Architecture: arm

---- modules
tlv320aic32x4_i2c 16384 1
tlv320aic32x4 32768 1 tlv320aic32x4_i2c
udrc 16384 3
snd_soc_core 188416 3 tlv320aic32x4,snd_soc_bcm2835_i2s,udrc
snd_pcm 98304 6
snd_pcm_dmaengine,tlv320aic32x4,snd_soc_bcm2835_i2s,snd_soc_core

-rw-r--r-- 1 root 6388 Dec 8 19:59
/lib/modules/4.14.79-v7+/updates/dkms/tlv320aic32x4-i2c.ko
-rw-r--r-- 1 root 38156 Dec 8 19:59
/lib/modules/4.14.79-v7+/updates/dkms/tlv320aic32x4.ko
-rw-r--r-- 1 root 6408 Dec 8 19:59
/lib/modules/4.14.79-v7+/updates/dkms/tlv320aic32x4-spi.ko
-rw-r--r-- 1 root 8332 Dec 8 19:59
/lib/modules/4.14.79-v7+/updates/dkms/udrc.ko

---- kernel
||/ Name Version Architecture Description
+++-==================-============-============-===========================
======
ii raspberrypi-kernel 1.20181112-1 armhf Raspberry Pi bootloader
ii udrc-dkms 1.0.4 armhf DKMS source for the UDRC
driver

---- compass
Compass preference file not found: /etc/apt/preferences.d/compass
---- compass apt sources list file
deb [arch=armhf,amd64] http://archive.compasslinux.org/ cedar main
---- compass package files
-rw-r--r-- 1 root 2201 Nov 25 23:31
/var/lib/apt/lists/archive.compasslinux.org_dists_cedar_InRelease
-rw-r--r-- 1 root 17567 Jul 2 22:52
/var/lib/apt/lists/archive.compasslinux.org_dists_cedar_main_binary-amd64_Pa
ckages
-rw-r--r-- 1 root 43315 Nov 25 23:31
/var/lib/apt/lists/archive.compasslinux.org_dists_cedar_main_binary-armhf_Pa
ckages

----- Dire Wolf DEVELOPMENT version 1.6 A (Dec 9 2018)

==== boot config ====
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
# dtparam=audio=on

force_turbo=1
dtoverlay=
dtoverlay=draws

---- gpsd
● gpsd.service - GPS (Global Positioning System) Daemon
Loaded: loaded (/lib/systemd/system/gpsd.service; indirect; vendor
preset: en
Active: active (running) since Fri 2018-12-14 20:49:52 EST; 4 days ago
Main PID: 4274 (gpsd)
CGroup: /system.slice/gpsd.service
└─4274 /usr/sbin/gpsd -N -n /dev/ttySC0 /dev/pps0

Dec 14 20:49:52 kd4iz_draws systemd[1]: Started GPS (Global Positioning
System)
lines 1-8/8 (END)
============================================================================
===

-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On
Behalf Of Basil Gunn
Sent: Wednesday, December 19, 2018 12:13
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] It was "fine", then... strange behavior #betaimage
#setup #draws


In general for debugging problems:

Send output of:
~/bin/showudrc.sh
~/n7nix/debug/alsa-show.sh

Use the following instructions for measure_deviate.sh to verify PTT &
transmit paths.
https://github.com/nwdigitalradio/n7nix/tree/master/deviation

Using another radio listen to the tone produced by the measure_deviate.sh
script.

The most common problem, if the tones do not sound right, is the output is
being over driven causing it to clip.

Receive path:
Tune a radio to the APRS 1200 baud freq. 144.390 MHz run the following in a
console:

tail -f /var/log/direwolf/direwolf.log

You should see received packets scrolling by.

Let us know what you find & thanks for testing the DRAWS hat.

/Basil

Jack Spitznagel <kd4iz@frawg.org> writes:

Basil, John, All,

Initially, Beta 5 seemed to work out of the box but I ran into some
DRAWS audio and keying strangeness that is baffling me after 3 tries
at installing from newly flashed microSD cards and following Basil's
latest procedure on GitHub. Hope you can provide insight. Rig is a CAT
controlled IC-7000.

Tested Direwolf with Xastir and YAAC with both RX and TX successfully, but
noticed the audio was a bit hot - signal here looked normal on the SpecLab
so I left it alone.

Then disabled AX.25/direwolf (script) and configured fldigi and wsjt-x.
Both programs worked in receive but the TX audio to the IC-7000 was very
"hot". Put fldigi in tune then to bring the ALC reading as close to zero as
possible by reducing audio levels with the PCM drive control. As audio level
is reduced - the ALC starts to "pump", as did the power out indication -
unexpectedly, there was a increase of noise on audio and harmonic spikes got
higher as level of signal was reduced. Returned levels to where they had
been and meter indications returned to where they were before. Was able to
have a PSK31 QSO and got no comment about the signal quality.

I re-enabled AX.25/Direwolf using the script. Now both Xastir and YAAC no
longer would transmit audio. When the rig is keyed, the TX LED on the rig
flashes 3-4 times quickly and there is no modulation of the FM carrier.
Reboot did not change behavior. Going back to non-AX25 mode, now fldigi
would key the radio, but no modulation occurred.

Re-installation of the DRAWS beta 5 from the ground up (x2) did not help -
none of the programs transmit audio and symptoms are the same.

To be sure rig was OK, I hooked up an old SIgnaLink to a laptop, ran HRD
and it drove and keyed the rig just fine. So I have to assume that the
problem is software or DRAWS hardware related.

Where should I be looking to fix the audio? The keying?
Settings should not so brittle. Thanks in advance,





--
J Spitznagel
Science River LLC
KD4IZ
Re: It was "fine", then... strange behavior #betaimage #setup #draws

Gayland Gump
 

I haven't the sophisticated knowledge of how the DRAWS & UDRC perform their magic but I have the following observations.  

Out of the box, the DRAWS would not work with my Yaesu 857D when running fldigi. I believe that the PTT wasn't working immediately after I did the initial configuration of fldigi but I can't be sure.  Thinking back a couple years or so when I first got my first UDRC I began to suspect the ALSA settings.  Examining the UDRC settings and comparing them to the DRAWS I tried changing a couple of the parameters on the DRAWS to correspond to those on the UDRC.  After a couple changing a single parameter at a time with no change in outcome.  

I realized that on the UDRC I had the on board audio turned on.  In order to model the working UDRC, I decided to activate the onboard audio using the "dtparam=audio=on" parameter in the /boot/config.txt file on the DRAWS.  I had no definite rationale for doing this other than to eliminate another difference in the UDRC and DRAWS configurations.  The impact of making that change in situ on the DRAWS was disastrous as on a reboot the system was entirely un-useable.  I immediately reversed that change and returned to pursuing the ALSA settings.

As my earlier approach of changing single ALSA parameters had not yielded any change in fldigi's performance, I did a wholesale change of the DRAWS alsa settings to those that were currently in place on my working UDRC.  After completing these changes, the DRAWS was able to transmit and receive.  There are still some issues though.

First, there is a significant difference in SNR reports on the UDRC vs the DRAWS.  DRAWS levels appear to be 10 or more DB lower than those being reported by fldigi on the UDRC.  As all I do to obtain these observations  is move the 6-pin DIN connector back and forth between the UDRC and DRAWS using identical ALSA settings, I'd like to know what might be causing the differences in the SNR reports between those devices.

Another difference, which I note between the DRAWS and UDRC which may well be related to the level differences is in the fldigi waterfall display.  To the best of my knowledge the applicable waterfall settings on the DRAWS and the UDRC but the displays are significantly different.   I've got my UDRC set so that the waterfall shows a constant noise level.  Lots of others seem to prefer having a noiseless screen that only display's stronger signals.  I find that by leaving the display set so that it displays noise I am able to visually identify some weak FSQ signal patterns.  

I'd also like to know what it takes to get the on board audio working on the DRAWS after all some of the software running on the DRAWS provides audio cues that it might be nice to use.  Of course assuming that those cues can be delivered to the on board audio for presentation.

I want to applaud all of NWDR's efforts at bringing us some very cool and useful tools.  I also recognize that providing documentary support for these tool is extremely challenging given the resources available.   Given the constraints, I know that it is a lot to expect that NDWR keep in mind that we users including early adopters often don't have the necessary depth of knowledge that NDWR folks have and expecting us to know about non-standard applications (e.g. chrony vs ntp) or even basic linux system operations need to be carefully considered assumptions.

Finally, I'd like to find out if NWDR has any ideas why I'd be seeing the differences in SNR that appear between the DRAWS and UDRC?  What have I overlooked or just don't know about?

Thanks again for your time and attention.

Gayland
KG7GCF


On Wed, Dec 19, 2018 at 7:07 AM Jack Spitznagel <kd4iz@...> wrote:
Basil, John, All,

Initially, Beta 5 seemed to work out of the box but I ran into some DRAWS audio and keying strangeness that is baffling me after 3 tries at installing from newly flashed microSD cards and following Basil's latest procedure on GitHub. Hope you can provide insight. Rig is a CAT controlled IC-7000.

Tested Direwolf with Xastir and YAAC with both RX and TX successfully, but noticed the audio was a bit hot - signal here looked normal on the SpecLab so I left it alone.

Then disabled AX.25/direwolf (script) and configured fldigi and wsjt-x. Both programs worked in receive but the TX audio to the IC-7000 was very "hot". Put fldigi in tune then to bring the ALC reading as close to zero as possible by reducing audio levels with the PCM drive control. As audio level is reduced - the ALC starts to "pump", as did the power out indication - unexpectedly, there was a increase of noise on audio and harmonic spikes got higher as level of signal was reduced. Returned levels to where they had been and meter indications returned to where they were before. Was able to have a PSK31 QSO and got no comment about the signal quality.

I re-enabled AX.25/Direwolf using the script. Now both Xastir and YAAC no longer would transmit audio. When the rig is keyed, the TX LED on the rig flashes 3-4 times quickly and there is no modulation of the FM carrier. Reboot did not change behavior. Going back to non-AX25 mode, now fldigi would key the radio, but  no modulation occurred.

Re-installation of the DRAWS beta 5 from the ground up (x2) did not help - none of the programs transmit audio and symptoms are the same.

To be sure rig was OK, I hooked up an old SIgnaLink to a laptop, ran HRD and it drove and keyed the rig just fine. So I have to assume that the problem is software or DRAWS hardware related.

Where should I be looking to fix the audio? The keying?
Settings should not so brittle. Thanks in advance,
--
J Spitznagel - KD4IZ
Science River LLC
KD4IZ

Re: It was "fine", then... strange behavior #betaimage #setup #draws

Basil Gunn
 

In general for debugging problems:

Send output of:
~/bin/showudrc.sh
~/n7nix/debug/alsa-show.sh

Use the following instructions for measure_deviate.sh to verify PTT &
transmit paths.
https://github.com/nwdigitalradio/n7nix/tree/master/deviation

Using another radio listen to the tone produced by the
measure_deviate.sh script.

The most common problem, if the tones do not sound right, is the output is
being over driven causing it to clip.

Receive path:
Tune a radio to the APRS 1200 baud freq. 144.390 MHz
run the following in a console:

tail -f /var/log/direwolf/direwolf.log

You should see received packets scrolling by.

Let us know what you find & thanks for testing the DRAWS hat.

/Basil

Jack Spitznagel <kd4iz@frawg.org> writes:

Basil, John, All,

Initially, Beta 5 seemed to work out of the box but I ran into some
DRAWS audio and keying strangeness that is baffling me after 3 tries
at installing from newly flashed microSD cards and following Basil's
latest procedure on GitHub. Hope you can provide insight. Rig is a CAT
controlled IC-7000.

Tested Direwolf with Xastir and YAAC with both RX and TX successfully, but noticed the audio was a bit hot - signal here looked normal on the SpecLab so I left it alone.

Then disabled AX.25/direwolf (script) and configured fldigi and wsjt-x. Both programs worked in receive but the TX audio to the IC-7000 was very "hot". Put fldigi in tune then to bring the ALC reading as close to zero as possible by reducing audio levels with the PCM drive control. As audio level is reduced - the ALC starts to "pump", as did the power out indication - unexpectedly, there was a increase of noise on audio and harmonic spikes got higher as level of signal was reduced. Returned levels to where they had been and meter indications returned to where they were before. Was able to have a PSK31 QSO and got no comment about the signal quality.

I re-enabled AX.25/Direwolf using the script. Now both Xastir and YAAC no longer would transmit audio. When the rig is keyed, the TX LED on the rig flashes 3-4 times quickly and there is no modulation of the FM carrier. Reboot did not change behavior. Going back to non-AX25 mode, now fldigi would key the radio, but no modulation occurred.

Re-installation of the DRAWS beta 5 from the ground up (x2) did not help - none of the programs transmit audio and symptoms are the same.

To be sure rig was OK, I hooked up an old SIgnaLink to a laptop, ran HRD and it drove and keyed the rig just fine. So I have to assume that the problem is software or DRAWS hardware related.

Where should I be looking to fix the audio? The keying?
Settings should not so brittle. Thanks in advance,
Re: ntpd not installed on beta 5 #ntp #chrony #ntpd

David [kg5eiu]
 

These CR1220s work well in mine:


73!!  David (KG5EIU)


On Dec 19, 2018, at 3:06 AM, f6bvp <f6bvp@...> wrote:

I did not install a battery yet  in my DRAWS hat.
None of the button batteries I have in stock fits into the case.
Could someone give me a model reference or number.

Bernard


Le 19 déc. 2018 à 07:20, Basil Gunn <basil@...> a écrit :


From some google-fu:

Note that the chrony service does not change the time. The often
misconception is that the chrony service is setting the time to the one
given by the NTP server.  This is incorrect – what actually happens is
that based on the answer from the NTP server, chrony just tells the
system clock to go faster or slower.  For this reason, sometimes even
though the time is wrong and the NTP server is working, the time does
not get corrected immediately.

If your system time is off by a lot you can try this.
To step the system clock immediately, bypassing any adjustments in
progress by slewing, issue the following command as root:

chronyc makestep

Also check out entries in:
https://github.com/nwdigitalradio/n7nix/blob/master/VERIFY_CONFIG.md
Look for "Check GPS"

Also send me the console output from this script.
https://github.com/nwdigitalradio/n7nix/blob/master/gps/verify_time.sh

/Basil

Gayland Gump <kg7gcf@...> writes:

I believe it ran for a few hours without the update, in fact I was
surprised when I finally noticed that the date and time were so off.  I did
not do anything with chrony nor the gps other than install the battery and
hooked up the antenna.

Gayland
KG7GCF


On Tue, Dec 18, 2018 at 5:56 PM Basil Gunn <basil@...> wrote:


FYI,  I installed a battery before I first powered up the DRAWS but the
time did not update even with a network connection and the gps antenna
installed.

My experience is that it can sometimes take 10 minutes for chronyd to
sync.
/Basil


I ended up setting it manually using the date command.  Haven't
been back to it to see if it has held will try to get around to that
soon.

Gayland
KG7GCF
Re: ntpd not installed on beta 5 #ntp #chrony #ntpd

Basil Gunn
 

If not already present adding
chronyc makestep
in n7nix install core script could be usefull to perform initial
system time adjustment when GPS is not yet switched. This is my case
for I did’not put any antenna for indoor use.
Yes. Exactly what I was going to do.
Just want to make sure that is sufficient to solve Gayland's problem.
/Basil



Le 19 déc. 2018 à 07:20, Basil Gunn <basil@pacabunga.com> a écrit :


From some google-fu:

Note that the chrony service does not change the time. The often
misconception is that the chrony service is setting the time to the one
given by the NTP server. This is incorrect – what actually happens is
that based on the answer from the NTP server, chrony just tells the
system clock to go faster or slower. For this reason, sometimes even
though the time is wrong and the NTP server is working, the time does
not get corrected immediately.

If your system time is off by a lot you can try this.
To step the system clock immediately, bypassing any adjustments in
progress by slewing, issue the following command as root:

chronyc makestep

Also check out entries in:
https://github.com/nwdigitalradio/n7nix/blob/master/VERIFY_CONFIG.md
Look for "Check GPS"

Also send me the console output from this script.
https://github.com/nwdigitalradio/n7nix/blob/master/gps/verify_time.sh

/Basil
It was "fine", then... strange behavior #betaimage #setup #draws

Jack Spitznagel
 

Basil, John, All,

Initially, Beta 5 seemed to work out of the box but I ran into some DRAWS audio and keying strangeness that is baffling me after 3 tries at installing from newly flashed microSD cards and following Basil's latest procedure on GitHub. Hope you can provide insight. Rig is a CAT controlled IC-7000.

Tested Direwolf with Xastir and YAAC with both RX and TX successfully, but noticed the audio was a bit hot - signal here looked normal on the SpecLab so I left it alone.

Then disabled AX.25/direwolf (script) and configured fldigi and wsjt-x. Both programs worked in receive but the TX audio to the IC-7000 was very "hot". Put fldigi in tune then to bring the ALC reading as close to zero as possible by reducing audio levels with the PCM drive control. As audio level is reduced - the ALC starts to "pump", as did the power out indication - unexpectedly, there was a increase of noise on audio and harmonic spikes got higher as level of signal was reduced. Returned levels to where they had been and meter indications returned to where they were before. Was able to have a PSK31 QSO and got no comment about the signal quality.

I re-enabled AX.25/Direwolf using the script. Now both Xastir and YAAC no longer would transmit audio. When the rig is keyed, the TX LED on the rig flashes 3-4 times quickly and there is no modulation of the FM carrier. Reboot did not change behavior. Going back to non-AX25 mode, now fldigi would key the radio, but  no modulation occurred.

Re-installation of the DRAWS beta 5 from the ground up (x2) did not help - none of the programs transmit audio and symptoms are the same.

To be sure rig was OK, I hooked up an old SIgnaLink to a laptop, ran HRD and it drove and keyed the rig just fine. So I have to assume that the problem is software or DRAWS hardware related.

Where should I be looking to fix the audio? The keying?
Settings should not so brittle. Thanks in advance,
--
J Spitznagel - KD4IZ
Science River LLC
KD4IZ
Re: ntpd not installed on beta 5 #ntp #chrony #ntpd

Bryan Hoyer
 

Battery is CR1220 NON RECHARGEABLE
Re: ntpd not installed on beta 5 #ntp #chrony #ntpd

Bernard f6bvp / ai7bg
 

If not already present adding 
chronyc makestep
in n7nix  install core script could be usefull to perform initial system time adjustment when GPS is not yet switched. This is my case for I did’not put any antenna for indoor use.

Bernard


Le 19 déc. 2018 à 07:20, Basil Gunn <basil@...> a écrit :


From some google-fu:

Note that the chrony service does not change the time. The often
misconception is that the chrony service is setting the time to the one
given by the NTP server.  This is incorrect – what actually happens is
that based on the answer from the NTP server, chrony just tells the
system clock to go faster or slower.  For this reason, sometimes even
though the time is wrong and the NTP server is working, the time does
not get corrected immediately.

If your system time is off by a lot you can try this.
To step the system clock immediately, bypassing any adjustments in
progress by slewing, issue the following command as root:

chronyc makestep

Also check out entries in:
https://github.com/nwdigitalradio/n7nix/blob/master/VERIFY_CONFIG.md
Look for "Check GPS"

Also send me the console output from this script.
https://github.com/nwdigitalradio/n7nix/blob/master/gps/verify_time.sh

/Basil
Re: ntpd not installed on beta 5 #ntp #chrony #ntpd

Bernard f6bvp / ai7bg
 

I did not install a battery yet in my DRAWS hat.
None of the button batteries I have in stock fits into the case.
Could someone give me a model reference or number.

Bernard

Le 19 déc. 2018 à 07:20, Basil Gunn <basil@pacabunga.com> a écrit :


From some google-fu:

Note that the chrony service does not change the time. The often
misconception is that the chrony service is setting the time to the one
given by the NTP server. This is incorrect – what actually happens is
that based on the answer from the NTP server, chrony just tells the
system clock to go faster or slower. For this reason, sometimes even
though the time is wrong and the NTP server is working, the time does
not get corrected immediately.

If your system time is off by a lot you can try this.
To step the system clock immediately, bypassing any adjustments in
progress by slewing, issue the following command as root:

chronyc makestep

Also check out entries in:
https://github.com/nwdigitalradio/n7nix/blob/master/VERIFY_CONFIG.md
Look for "Check GPS"

Also send me the console output from this script.
https://github.com/nwdigitalradio/n7nix/blob/master/gps/verify_time.sh

/Basil

Gayland Gump <kg7gcf@gmail.com> writes:

I believe it ran for a few hours without the update, in fact I was
surprised when I finally noticed that the date and time were so off. I did
not do anything with chrony nor the gps other than install the battery and
hooked up the antenna.

Gayland
KG7GCF


On Tue, Dec 18, 2018 at 5:56 PM Basil Gunn <basil@pacabunga.com> wrote:


FYI, I installed a battery before I first powered up the DRAWS but the
time did not update even with a network connection and the gps antenna
installed.
My experience is that it can sometimes take 10 minutes for chronyd to
sync.
/Basil


I ended up setting it manually using the date command. Haven't
been back to it to see if it has held will try to get around to that
soon.

Gayland
KG7GCF
Re: ntpd not installed on beta 5 #ntp #chrony #ntpd

Basil Gunn
 

From some google-fu:

Note that the chrony service does not change the time. The often
misconception is that the chrony service is setting the time to the one
given by the NTP server. This is incorrect – what actually happens is
that based on the answer from the NTP server, chrony just tells the
system clock to go faster or slower. For this reason, sometimes even
though the time is wrong and the NTP server is working, the time does
not get corrected immediately.

If your system time is off by a lot you can try this.
To step the system clock immediately, bypassing any adjustments in
progress by slewing, issue the following command as root:

chronyc makestep

Also check out entries in:
https://github.com/nwdigitalradio/n7nix/blob/master/VERIFY_CONFIG.md
Look for "Check GPS"

Also send me the console output from this script.
https://github.com/nwdigitalradio/n7nix/blob/master/gps/verify_time.sh

/Basil

Gayland Gump <kg7gcf@gmail.com> writes:

I believe it ran for a few hours without the update, in fact I was
surprised when I finally noticed that the date and time were so off. I did
not do anything with chrony nor the gps other than install the battery and
hooked up the antenna.

Gayland
KG7GCF


On Tue, Dec 18, 2018 at 5:56 PM Basil Gunn <basil@pacabunga.com> wrote:


FYI, I installed a battery before I first powered up the DRAWS but the
time did not update even with a network connection and the gps antenna
installed.
My experience is that it can sometimes take 10 minutes for chronyd to
sync.
/Basil


I ended up setting it manually using the date command. Haven't
been back to it to see if it has held will try to get around to that
soon.

Gayland
KG7GCF
Re: Suggested pre-installed apps for the 'final' image and bugs

Basil Gunn
 

I just loaded beta5 and going through it, I'll make a list here of
suggested apps for the final image (or at least that people should
consider installing)

- geany: great little text editor, multiple language support
Not to sound too dogmatic but text editors are personal and I've had
this discussion a few too many times already. Put whatever editor you
want on your installation but it most likely will not be in the
nw digital radio RPi image.

current bugs I've found:
- wget https://sourceforge.net produces 'certificate not trusted'
Not sure what you are talking about. There are no wget of any files in
the configuration script of the image. The whole point of making the
image is so you don't have to do that.

I'm going to manually go through the rest of my script later but so
far that looks like the biggest deal that I can see.
/Basil
Suggested pre-installed apps for the 'final' image and bugs

Art - KC7SDA
 

I just loaded beta5 and going through it, I'll make a list here of suggested apps for the final image (or at least that people should consider installing)

- geany: great little text editor, multiple language support 

current bugs I've found:
- wget https://sourceforge.net produces 'certificate not trusted'

I'm going to manually go through the rest of my script later but so far that looks like the biggest deal that I can see.
Re: ntpd not installed on beta 5 #ntp #chrony #ntpd

Gayland Gump
 

I believe it ran for a few hours without the update, in fact I was surprised when I finally noticed that the date and time were so off.  I did not do anything with chrony nor the gps other than install the battery and hooked up the antenna.  

Gayland
KG7GCF


On Tue, Dec 18, 2018 at 5:56 PM Basil Gunn <basil@...> wrote:

> FYI,  I installed a battery before I first powered up the DRAWS but the
> time did not update even with a network connection and the gps antenna
> installed.

My experience is that it can sometimes take 10 minutes for chronyd to
sync.
/Basil


> I ended up setting it manually using the date command.  Haven't
> been back to it to see if it has held will try to get around to that soon.
>
> Gayland
> KG7GCF
Re: ntpd not installed on beta 5 #ntp #chrony #ntpd

Basil Gunn
 

FYI, I installed a battery before I first powered up the DRAWS but the
time did not update even with a network connection and the gps antenna
installed.
My experience is that it can sometimes take 10 minutes for chronyd to
sync.
/Basil


I ended up setting it manually using the date command. Haven't
been back to it to see if it has held will try to get around to that soon.

Gayland
KG7GCF
Re: ntpd not installed on beta 5 #ntp #chrony #ntpd

John D Hays - K7VE
 

The RTC is part of the GPS and is set by the GPS, make sure your GPS is receiving to get the RTC set, you can use gpsmon or cgps to check the gps.  Then gpsd and chrony need to be running for the system clock updates.

On Tue, Dec 18, 2018 at 4:51 PM Gayland Gump <kg7gcf@...> wrote:
FYI,  I installed a battery before I first powered up the DRAWS but the time did not update even with a network connection and the gps antenna installed.  I ended up setting it manually using the date command.  Haven't been back to it to see if it has held will try to get around to that soon.

Gayland
KG7GCF


On Tue, Dec 18, 2018 at 4:35 PM Basil Gunn <basil@...> wrote:

Bernard,

I have been playing around with chrony for a few hours now and I've
convinced myself that chronyd should work fine with or without a gps
antenna connected.

If you look at the output of this command without a GPS antenna:

sudo timedatectl

it should have "Network time on: yes"

I have experienced chrony sometimes taking several minutes to get the
local time correct. I think installing the battery on the DRAWS board
could help that behavior. Let me know if you see other time related
problems.

/Basil



f6bvp <f6bvp@...> writes:

> Ok. I reinstalled chrony for it had been removed when installing ntp.
> This time command
> systemctl status chrony
> showed that it was started as ntp client/server and
> chrony sources command found 6 sources while gps is not activated.
>
> Thanks,
>
> 73 de Bernard f6bvp
>
>
>> Le 18 déc. 2018 à 17:20, John D Hays - K7VE <john@...> a écrit :
>>
>> Chrony works without GPS as a client on the Internet.
>>
>>> On Tue, Dec 18, 2018, 08:13 Basil Gunn <basil@... wrote:
>>>
>>> > I noticed that on my compass beta-5 system the time was not set
>>> > correctly despite I did perform initial country, keyboard
>>> > etc...configuration.  Thus I apt-get installed ntp and after one or
>>> > two minutes the console clock did display local time correctly.
>>>
>>> That's true & I need to fix that.
>>>
>>> Currently time defaults to using chrony & the gps.  Chrony is another
>>> implementation the Network Time Protocol. You should notice that when
>>> you install ntp, chrony is removed.
>>> I need to look into using chrony without a gps.
>>>
>>> /Basil
>>>
>>>
>>>
>>
>>
>
>





--

John D. Hays
Edmonds, WA
K7VE

   
3161 - 3180 of 5462