See text below for my response to Basil's response.
On Wed, Dec 19, 2018 at 11:46 AM Basil Gunn <basil@...
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
Also please check the xastir README.md under "Configure Audio"
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.
> 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
>> 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
>> 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