Date   

Re: No output on UDRC-II

ml000-0013@...
 


  Oops:

  %s/asound\.conf/asound.state/g

On Thu, Dec 1, 2016 at 11:48 am, <ml000-0013@...> wrote:

I think we may need another update to the set-udrc-din6.sh/urdc-alsa-din6.sh script.  I ran the script to restore the standard mixer settings, but I noticed that asound.conf 


Re: No output on UDRC-II

ml000-0013@...
 

  Hi Basil,

I'll shoot you a copy of asound.state in a separate email, and I'll start comparing the instructions in CORE_INSTALL.md against my system.

I think we may need another update to the set-udrc-din6.sh/urdc-alsa-din6.sh script.  I ran the script to restore the standard mixer settings, but I noticed that asound.conf did not get updated (see below).  Looking at the script, I think 'alsactl store' needs to get moved below 'EOF' because it is a shell command:

root@hammy:~# rm udrc-alsa-din6.sh*
root@hammy:~# rm set-udrc-din6.sh 
root@hammy:~# ls -l /var/lib/alsa/asound.state 
-rw-r--r-- 1 root root 11499 Dec  1 11:37 /var/lib/alsa/asound.state
root@hammy:~# wget https://raw.githubusercontent.com/nwdigitalradio/udrc-tools/master/scripts/udrc-alsa-din6.sh
--2016-12-01 11:39:33--  https://raw.githubusercontent.com/nwdigitalradio/udrc-tools/master/scripts/udrc-alsa-din6.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.52.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.52.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1712 (1.7K) [text/plain]
Saving to: ‘udrc-alsa-din6.sh’
udrc-alsa-din6.sh                          100%[=======================================================================================>]   1.67K  --.-KB/s   in 0s     
2016-12-01 11:39:33 (7.33 MB/s) - ‘udrc-alsa-din6.sh’ saved [1712/1712]
root@hammy:~# chmod u+x udrc-alsa-din6.sh 
root@hammy:~# ./udrc-alsa-din6.sh > /dev/null
root@hammy:~# ls -l /var/lib/alsa/asound.state 
-rw-r--r-- 1 root root 11499 Dec  1 11:37 /var/lib/alsa/asound.state
root@hammy:~# alsactl store
root@hammy:~# ls -l /var/lib/alsa/asound.state 
-rw-r--r-- 1 root root 11499 Dec  1 11:41 /var/lib/alsa/asound.state
root@hammy:~# 

  Thanks
  Mike



Re: No output on UDRC-II

Basil Gunn
 

On Thu, 01 Dec 2016 09:17:43 -0800
ml000-0013@... wrote:

I haven't really made any progress with this issue, and I could
really use some help.
Hello Mike,

I would like to suggest 2 things.

1. Send me via e-mail (@basil860) or post here, your alsa
mixer settings.

- in /var/lib/alsa is a file asound.state
- I want to compare that file to my file
- attach it to an e-mail to me

Depending on what we see in that file we will want to do #2 below

2. Use my install script to install core functionality.

- go here https://github.com/nwdigitalradio/n7nix/
- read CORE_INSTALL.md & follow those instructions
- This starts from a new compass image and relies on the script to
configure everything needed.

This will get you to a configuration I know works.

I'm assuming you have a UDRC II & are using the mini-din 6 connector.

/Basil n7nix


Re: No output on UDRC-II

Edouard Lafargue
 

  if this can help: I like to use the following one-liner to debug audio issues by ear, this will redirect your UDRC-II audio to the RPi audio jack, and this has helped me a lot when I was scratching my head with the creative use of the left/right input and output channels on the UDRC's audio codec chip ;)

arecord -D hw:CARD=udrc,DEV=0 -r 48000 -f S16_LE -c2 | aplay -



On Thu, Dec 1, 2016 at 9:17 AM, <ml000-0013@...> wrote:

  Hello everyone,

I haven't really made any progress with this issue, and I could really use some help.  As near as I can tell, the software (compass, alsa settings) are working configured properly.  The URDC-II seems to power on and respond to software commands.  The audio device seems to respond when opened by a software package since the ripple observed on the scope is negated when the audio device is opened.  It seems like the audio is muted, so I suspect some issue with mixer settings.  Advice would be greatly appreciated.


  Thanks

  Mike




Re: No output on UDRC-II

ml000-0013@...
 

  Hello everyone,

I haven't really made any progress with this issue, and I could really use some help.  As near as I can tell, the software (compass, alsa settings) are working configured properly.  The URDC-II seems to power on and respond to software commands.  The audio device seems to respond when opened by a software package since the ripple observed on the scope is negated when the audio device is opened.  It seems like the audio is muted, so I suspect some issue with mixer settings.  Advice would be greatly appreciated.


  Thanks

  Mike



Re: WSJT-X with UDRC anyone?

Corky Searls
 

I have not used WSTJ-X, but when I look at the waterfall display it does not look "normal." This looks exactly like the same oscillator spurs that you had in fldigi. I am not sure that the digital-psk setting is working as imagined. I will test this when I get home, but the "normal" display should be a filtered band of white (blue or yellow waterfall) noise (assuming there are no signals in the noise), with no uniformly spaced lines. If you were to have the signals you should be able to see the tones at the various signal offsets (i.e., they do not look like straight lines), which are not present in your current display.

Thanks,
-Corky

On Nov 30, 2016, at 4:13 PM, udrc@... wrote:


I updated the debiam library I pull from to allow me to pull down WSTJ-X 1.7 istead of the 1.1 we get in the Compass Linux Build. I am also using sysdefault:CARD-urdc for both in and out. I am seeing this as my waterfall, the heat pattern on the left is VERY similar to what I got from FLDIGI trying to do PSK31.. But the rest of the waterfall sorta looks normal, I think? I mean it has blue with yellow bands possibly indicating communication streams. Meh, having never worked with WSJT-X I have no idea if this is how it should look :-D


<2016_11_30_230807_1680x1050_scrot.png>


Re: WSJT-X with UDRC anyone?

udrc@...
 


I updated the debiam library I pull from to allow me to pull down WSTJ-X 1.7 istead of the 1.1 we get in the Compass Linux Build. I am also using sysdefault:CARD-urdc for both in and out. I am seeing this as my waterfall, the heat pattern on the left is VERY similar to what I got from FLDIGI trying to do PSK31.. But the rest of the waterfall sorta looks normal, I think? I mean it has blue with yellow bands possibly indicating communication streams. Meh, having never worked with WSJT-X I have no idea if this is how it should look :-D




Re: WSJT-X with UDRC anyone?

 

You should be able to use din6 virtual soundcard for both in and out.  Those sub soundcards are more for special cases.

On Wed, Nov 30, 2016 at 9:02 AM, <udrc@...> wrote:

I grabbed a snap of my settings.






--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


Re: WSJT-X with UDRC anyone?

udrc@...
 

I grabbed a snap of my settings.




WSJT-X with UDRC anyone?

udrc@...
 

Hey Group,


With success at direwolf, showing my card does audio, I though I would try seeing what all this JT-65 stuff is about. I added wsjtx to the UDRC load of compass linux, added my Yaseu CAT cable to the mix, as WSJT-X has native CAT control for PTT, and booted it up. WSJT-X loads with no complaints using the DIN_IN and DIN_OUT virtual sound card selections, and I see some grean wavey line in the water fall. But I have never used WSJT-X or done JT-65 comms before, so I would not actually know if everything is working :-D


I am on 20M 14.076.00, DIG mode on my radio, and was told that the PSK31 USB mode for digital pretty much works for most all digital modes, so that is how I am set. Anyone use WSJT-X with the UDRC-II that can help me with pointers of settings or such that I should look for?


Nick




Re: DTMF and/or COR

 

Direwolf has DTMF functionality so it shouldn't be too hard to the pieces together.


On Nov 29, 2016 9:04 AM, <k4dls@...> wrote:

Has anyone written a dtmf and/or cor program to allow remote control with the UDRC II controller/DR-1X?


DTMF and/or COR

K4DLS
 

Has anyone written a dtmf and/or cor program to allow remote control with the UDRC II controller/DR-1X?


Re: Where did the modulation go . . .

ab9ca@...
 

On Mon, Nov 28, 2016 at 10:37 pm, Jeremy McDermond wrote:

Did you install any new packages when you switched the networking to wireless?

No, the dstar and irc daemons were running at the time. There was no internet access as the wired was not working. I decided to try to give it access by clicking on the wireless icon in the upper right. It was ID'ing at that point in time. I clicked on the icon, gave it the password and it logged onto the wireless connection. At that point it had connectivity but it lost audio and has not worked since. No decode, no encode. 


I get 96 lines of stuff with the 'systemctl status' command:


pi@compass:~ $ systemctl status

● compass

    State: running

     Jobs: 0 queued

   Failed: 0 units

    Since: Thu 1970-01-01 00:00:03 UTC; 46 years 10 months ago

   CGroup: /

           ├─1 /sbin/init

           ├─system.slice

           │ ├─avahi-daemon.service

           │ │ ├─476 avahi-daemon: running [compass.local

           │ │ └─500 avahi-daemon: chroot helpe

           │ ├─dbus.service

           │ │ └─477 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation

           │ ├─cron.service

           │ │ └─468 /usr/sbin/cron -f

           │ ├─lighttpd.service

           │ │ ├─680 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

           │ │ ├─690 /usr/bin/php-cgi

           │ │ ├─693 /usr/bin/php-cgi

           │ │ ├─694 /usr/bin/php-cgi

           │ │ ├─695 /usr/bin/php-cgi

           │ │ └─696 /usr/bin/php-cgi

           │ ├─dhcpcd.service

           │ │ └─478 /sbin/dhcpcd -q -b

           │ ├─lightdm.service

           │ │ ├─613 /usr/sbin/lightdm

           │ │ └─683 /usr/bin/X :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

           │ ├─hciuart.service

           │ │ └─758 /usr/bin/hciattach /dev/serial1 bcm43xx 921600 noflow -

           │ ├─system-serial\x2dgetty.slice

           │ │ └─serial-getty@...

           │ │   └─616 /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt102

           │ ├─systemd-journald.service

           │ │ └─134 /lib/systemd/systemd-journald

           │ ├─minissdpd.service

           │ │ └─663 /usr/sbin/minissdpd -i 0.0.0.0

           │ ├─udisks2.service

           │ │ └─930 /usr/lib/udisks2/udisksd --no-debug

           │ ├─vsftpd.service

           │ │ └─585 /usr/sbin/vsftpd /etc/vsftpd.conf

           │ ├─ssh.service

           │ │ └─562 /usr/sbin/sshd -D

           │ ├─systemd-logind.service

           │ │ └─469 /lib/systemd/systemd-logind

           │ ├─ircddbgatewayd.service

           │ │ └─559 /usr/sbin/ircddbgatewayd

           │ ├─systemd-udevd.service

           │ │ └─136 /lib/systemd/systemd-udevd

           │ ├─polkitd.service

           │ │ └─917 /usr/lib/policykit-1/polkitd --no-debug

           │ ├─system-ifup.slice

           │ │ └─ifup@...

           │ │   └─437 /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan1.pid -i wlan1 -D nl80211,wext -c /etc/wpa_supplicant/wpa_suppl

           │ ├─rsyslog.service

           │ │ └─552 /usr/sbin/rsyslogd -n

           │ ├─triggerhappy.service

           │ │ └─499 /usr/sbin/thd --daemon --triggers /etc/triggerhappy/triggers.d/ --socket /var/run/thd.socket --pidfile /var/run/thd.pid

           │ ├─ntp.service

           │ │ └─654 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:111

           │ └─bluetooth.service

           │   └─765 /usr/lib/bluetooth/bluetoothd

           └─user.slice

             └─user-1000.slice

               ├─user@...

               │ ├─713 /lib/systemd/systemd --user

               │ └─716 (sd-pam)  

               ├─session-c1.scope

               │ ├─ 705 lightdm --session-child 13 16

               │ ├─ 719 /usr/bin/lxsession -s LXDE-pi -e LXDE

               │ ├─ 745 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager

               │ ├─ 748 /usr/bin/dbus-launch --exit-with-session x-session-manager

               │ ├─ 749 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

               │ ├─ 774 /usr/lib/gvfs/gvfsd

               │ ├─ 800 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes

               │ ├─ 903 openbox --config-file /home/pi/.config/openbox/lxde-pi-rc.xml

               │ ├─ 905 lxpolkit

               │ ├─ 908 lxpanel --profile LXDE-pi

               │ ├─ 909 pcmanfm --desktop --profile LXDE-pi

               │ ├─ 916 /usr/bin/ssh-agent -s

               │ ├─ 927 /usr/lib/gvfs/gvfs-udisks2-volume-monitor

               │ ├─ 943 /usr/lib/gvfs/gvfs-goa-volume-monitor

               │ ├─ 947 /usr/lib/gvfs/gvfs-mtp-volume-monitor

               │ ├─ 951 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor

               │ ├─ 955 /usr/lib/gvfs/gvfs-afc-volume-monitor

               │ ├─ 963 /usr/lib/gvfs/gvfsd-trash --spawner :1.1 /org/gtk/gvfs/exec_spaw/0

               │ ├─ 972 /usr/lib/menu-cache/menu-cached /tmp/.menu-cached-:0-pi

               │ ├─ 986 /usr/bin/x-www-browser

               │ ├─ 992 /usr/lib/gvfs/gvfsd-metadata

               │ ├─1014 lxterminal

               │ ├─1015 gnome-pty-helper

               │ ├─1016 /bin/bash

               │ ├─1422 systemctl status

               │ └─1423 pager

               └─session-c2.scope

                 ├─615 /bin/login -f   

                 └─796 -bash

pi@compass:~ $ 






Re: Where did the modulation go . . .

Jeremy McDermond <mcdermj@...>
 

On Nov 28, 2016, at 10:06 PM, ab9ca@... wrote:

OK, it looks like ambeserver is running.



I tried to kill it but it would not die. It kept changing its PID.
So I did the:



sudo systemctl disable dstarrepeaterd@1
sudo systemctl mask dstarrepeaterd@1



and then rebooted.



Then ran the following:



pi@compass:~ $ sudo systemctl status dstarrepeaterd@1 ircddbgatewayd
● dstarrepeaterd@1.service
Loaded: masked (/dev/null)
Active: inactive (dead)

Nov 29 05:45:54 compass systemd[1]: Stopped dstarrepeaterd@1.service.

● ircddbgatewayd.service - D-STAR Gateway Daemon
Loaded: loaded (/lib/systemd/system/ircddbgatewayd.service; enabled)
Active: inactive (dead) since Tue 2016-11-29 05:45:54 UTC; 1min 11s ago
Process: 560 ExecStart=/usr/sbin/ircddbgatewayd (code=killed, signal=TERM)
Main PID: 560 (code=killed, signal=TERM)

Nov 29 05:43:25 compass systemd[1]: Started D-STAR Gateway Daemon.
Nov 29 05:45:54 compass systemd[1]: Stopping D-STAR Gateway Daemon...
Nov 29 05:45:54 compass systemd[1]: Stopped D-STAR Gateway Daemon.
pi@compass:~ $
pi@compass:~ $
pi@compass:~ $ sudo gpio readall
+-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| | | 3.3v | | | 1 || 2 | | | 5v | | |
| 2 | 8 | SDA.1 | ALT0 | 1 | 3 || 4 | | | 5V | | |
| 3 | 9 | SCL.1 | ALT0 | 1 | 5 || 6 | | | 0v | | |
| 4 | 7 | GPIO. 7 | IN | 0 | 7 || 8 | 1 | ALT5 | TxD | 15 | 14 |
| | | 0v | | | 9 || 10 | 1 | ALT5 | RxD | 16 | 15 |
| 17 | 0 | GPIO. 0 | IN | 0 | 11 || 12 | 0 | ALT0 | GPIO. 1 | 1 | 18 |
| 27 | 2 | GPIO. 2 | OUT | 0 | 13 || 14 | | | 0v | | |
| 22 | 3 | GPIO. 3 | OUT | 0 | 15 || 16 | 0 | IN | GPIO. 4 | 4 | 23 |
| | | 3.3v | | | 17 || 18 | 0 | OUT | GPIO. 5 | 5 | 24 |
| 10 | 12 | MOSI | ALT0 | 0 | 19 || 20 | | | 0v | | |
| 9 | 13 | MISO | ALT0 | 0 | 21 || 22 | 1 | IN | GPIO. 6 | 6 | 25 |
| 11 | 14 | SCLK | ALT0 | 0 | 23 || 24 | 1 | OUT | CE0 | 10 | 8 |
| | | 0v | | | 25 || 26 | 1 | OUT | CE1 | 11 | 7 |
| 0 | 30 | SDA.0 | IN | 1 | 27 || 28 | 1 | IN | SCL.0 | 31 | 1 |
| 5 | 21 | GPIO.21 | IN | 1 | 29 || 30 | | | 0v | | |
| 6 | 22 | GPIO.22 | OUT | 0 | 31 || 32 | 0 | IN | GPIO.26 | 26 | 12 |
| 13 | 23 | GPIO.23 | OUT | 1 | 33 || 34 | | | 0v | | |
| 19 | 24 | GPIO.24 | ALT0 | 0 | 35 || 36 | 0 | IN | GPIO.27 | 27 | 16 |
| 26 | 25 | GPIO.25 | IN | 0 | 37 || 38 | 0 | ALT0 | GPIO.28 | 28 | 20 |
| | | 0v | | | 39 || 40 | 0 | ALT0 | GPIO.29 | 29 | 21 |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+
pi@compass:~ $
pi@compass:~ $
pi@compass:~ $
pi@compass:~ $ ps -ef | grep ambeserver
pi 1102 1033 0 05:47 pts/0 00:00:00 grep --color=auto ambeserver

This is just your grep command in the line above. ambeserver isn’t running.

Looks like pin 7 is still an IN pin and ambeserver is still running, if I'm reading this right.



The ambeserver must be being started somewhere in the boot sequence. How do I find out where? Would the log show this?
Something that you have installed is grabbing pin 7 on boot. It’s not dstarrepeaterd because we’ve told it not to start on boot. It’s difficult for me to debug over email. If you do a:

systemctl status

it’ll show you the daemons that systemd have started. That being said, there could be a startup script somewhere that’s snagging the pin. Did you install any new packages when you switched the networking to wireless?

73, dave

ab9ca/4
--
Jeremy McDermond
nh6z@...


Re: Where did the modulation go . . .

 

This is not ambeserver running, the response is just showing you are running grep to find ambeserver.

On Mon, Nov 28, 2016 at 10:06 PM, <ab9ca@...> wrote:

OK, it looks like ambeserver is running. 


pi@compass:~ $ ps -ef | grep ambeserver pi 1102 1033 0 05:47 pts/0 00:00:00 grep --color=auto ambeserver


Looks like pin 7 is still an IN pin and ambeserver is still running, if I'm reading this right.


The ambeserver must be being started somewhere in the boot sequence. How do I find out where? Would the log show this?


73, dave

ab9ca/4


--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


Re: Where did the modulation go . . .

ab9ca@...
 

OK, it looks like ambeserver is running. 


I tried to kill it but it would not die. It kept changing its PID. 


So I did the:


sudo systemctl disable dstarrepeaterd@1
sudo systemctl mask dstarrepeaterd@1


and then rebooted.


Then ran the following:


pi@compass:~ $ sudo systemctl status dstarrepeaterd@1 ircddbgatewayd ● dstarrepeaterd@1.service Loaded: masked (/dev/null) Active: inactive (dead) Nov 29 05:45:54 compass systemd[1]: Stopped dstarrepeaterd@1.service. ● ircddbgatewayd.service - D-STAR Gateway Daemon Loaded: loaded (/lib/systemd/system/ircddbgatewayd.service; enabled) Active: inactive (dead) since Tue 2016-11-29 05:45:54 UTC; 1min 11s ago Process: 560 ExecStart=/usr/sbin/ircddbgatewayd (code=killed, signal=TERM) Main PID: 560 (code=killed, signal=TERM) Nov 29 05:43:25 compass systemd[1]: Started D-STAR Gateway Daemon. Nov 29 05:45:54 compass systemd[1]: Stopping D-STAR Gateway Daemon... Nov 29 05:45:54 compass systemd[1]: Stopped D-STAR Gateway Daemon. pi@compass:~ $ pi@compass:~ $ pi@compass:~ $ sudo gpio readall +-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | | | 3.3v | | | 1 || 2 | | | 5v | | | | 2 | 8 | SDA.1 | ALT0 | 1 | 3 || 4 | | | 5V | | | | 3 | 9 | SCL.1 | ALT0 | 1 | 5 || 6 | | | 0v | | | | 4 | 7 | GPIO. 7 | IN | 0 | 7 || 8 | 1 | ALT5 | TxD | 15 | 14 | | | | 0v | | | 9 || 10 | 1 | ALT5 | RxD | 16 | 15 | | 17 | 0 | GPIO. 0 | IN | 0 | 11 || 12 | 0 | ALT0 | GPIO. 1 | 1 | 18 | | 27 | 2 | GPIO. 2 | OUT | 0 | 13 || 14 | | | 0v | | | | 22 | 3 | GPIO. 3 | OUT | 0 | 15 || 16 | 0 | IN | GPIO. 4 | 4 | 23 | | | | 3.3v | | | 17 || 18 | 0 | OUT | GPIO. 5 | 5 | 24 | | 10 | 12 | MOSI | ALT0 | 0 | 19 || 20 | | | 0v | | | | 9 | 13 | MISO | ALT0 | 0 | 21 || 22 | 1 | IN | GPIO. 6 | 6 | 25 | | 11 | 14 | SCLK | ALT0 | 0 | 23 || 24 | 1 | OUT | CE0 | 10 | 8 | | | | 0v | | | 25 || 26 | 1 | OUT | CE1 | 11 | 7 | | 0 | 30 | SDA.0 | IN | 1 | 27 || 28 | 1 | IN | SCL.0 | 31 | 1 | | 5 | 21 | GPIO.21 | IN | 1 | 29 || 30 | | | 0v | | | | 6 | 22 | GPIO.22 | OUT | 0 | 31 || 32 | 0 | IN | GPIO.26 | 26 | 12 | | 13 | 23 | GPIO.23 | OUT | 1 | 33 || 34 | | | 0v | | | | 19 | 24 | GPIO.24 | ALT0 | 0 | 35 || 36 | 0 | IN | GPIO.27 | 27 | 16 | | 26 | 25 | GPIO.25 | IN | 0 | 37 || 38 | 0 | ALT0 | GPIO.28 | 28 | 20 | | | | 0v | | | 39 || 40 | 0 | ALT0 | GPIO.29 | 29 | 21 | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+ pi@compass:~ $ pi@compass:~ $ pi@compass:~ $ pi@compass:~ $ ps -ef | grep ambeserver pi 1102 1033 0 05:47 pts/0 00:00:00 grep --color=auto ambeserver


Looks like pin 7 is still an IN pin and ambeserver is still running, if I'm reading this right.


The ambeserver must be being started somewhere in the boot sequence. How do I find out where? Would the log show this?


73, dave

ab9ca/4



Re: Where did the modulation go . . .

Jeremy McDermond <mcdermj@...>
 

On Nov 28, 2016, at 7:30 PM, ab9ca@... wrote:
| 4 | 7 | GPIO. 7 | IN | 0 | 7 || 8 | 1 | ALT5 | TxD | 15 | 14 |

And we see that pin 7 is IN, not ALTO.

I don't know when these assignments might change. This command was issued after stopping dstarrepeaterd and ircddbgatewayd. These two daemons are started on bootup of the RPi.
Yeah, it appears as though you have something that’s setting Pin 7 to an IN pin instead of an ALT0.

How do we get pin 7 back to ALTO? It was likely there before I switched from wired to wireless. Prior to that event It was running and I was hearing the announcements.
I wouldn’t think it’s switching to wireless. It certainly wouldn’t switch the pin to an IN. It’s another daemon that’s starting that is bypassing the kernel and reassigning the pin.

Did you install ambeserver per chance? If I recall correctly, that’ll try to grab pin 7 as the reset pin. You can check by looking for the process with something like:

ps -ef | grep ambeserver

We can also try to shut down dstarrepeaterd for now to isolate things. You can keep it from starting by executing

sudo systemctl disable dstarrepeaterd@1
sudo systemctl mask dstarrepeaterd@1

Reboot after this and see if the output of gpio readall reflects that Pin 7 is in ALT0 mode.

--
Jeremy McDermond
nh6z@...

73, dave
ab9ca/4


Re: Where did the modulation go . . .

ab9ca@...
 


Jeremy, first, thank you for your help on this. I think we are going to make some progress. 


Here is the command and output:


pi@compass:~ $ sudo gpio readall

 +-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+

 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |

 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+

 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |

 |   2 |   8 |   SDA.1 | ALT0 | 1 |  3 || 4  |   |      | 5V      |     |     |

 |   3 |   9 |   SCL.1 | ALT0 | 1 |  5 || 6  |   |      | 0v      |     |     |

 |   4 |   7 | GPIO. 7 |   IN | 0 |  7 || 8  | 1 | ALT5 | TxD     | 15  | 14  |

 |     |     |      0v |      |   |  9 || 10 | 1 | ALT5 | RxD     | 16  | 15  |

 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 1 | ALT0 | GPIO. 1 | 1   | 18  |

 |  27 |   2 | GPIO. 2 |  OUT | 0 | 13 || 14 |   |      | 0v      |     |     |

 |  22 |   3 | GPIO. 3 |  OUT | 0 | 15 || 16 | 0 | OUT  | GPIO. 4 | 4   | 23  |

 |     |     |    3.3v |      |   | 17 || 18 | 0 | OUT  | GPIO. 5 | 5   | 24  |

 |  10 |  12 |    MOSI | ALT0 | 0 | 19 || 20 |   |      | 0v      |     |     |

 |   9 |  13 |    MISO | ALT0 | 0 | 21 || 22 | 1 | IN   | GPIO. 6 | 6   | 25  |

 |  11 |  14 |    SCLK | ALT0 | 0 | 23 || 24 | 1 | OUT  | CE0     | 10  | 8   |

 |     |     |      0v |      |   | 25 || 26 | 1 | OUT  | CE1     | 11  | 7   |

 |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |

 |   5 |  21 | GPIO.21 |   IN | 1 | 29 || 30 |   |      | 0v      |     |     |

 |   6 |  22 | GPIO.22 |  OUT | 0 | 31 || 32 | 0 | IN   | GPIO.26 | 26  | 12  |

 |  13 |  23 | GPIO.23 |  OUT | 1 | 33 || 34 |   |      | 0v      |     |     |

 |  19 |  24 | GPIO.24 | ALT0 | 1 | 35 || 36 | 0 | IN   | GPIO.27 | 27  | 16  |

 |  26 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 0 | ALT0 | GPIO.28 | 28  | 20  |

 |     |     |      0v |      |   | 39 || 40 | 0 | ALT0 | GPIO.29 | 29  | 21  |

 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+

 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |

 +-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+


Here is the line of pin 7 by itself as the other stuff makes it difficult to read:

 |   4 |   7 | GPIO. 7 |   IN | 0 |  7 || 8  | 1 | ALT5 | TxD     | 15  | 14  |

And we see that pin 7 is IN, not ALTO.

I don't know when these assignments might change. This command was issued after stopping dstarrepeaterd and ircddbgatewayd. These two daemons are started on bootup of the RPi. 

How do we get pin 7 back to ALTO? It was likely there before I switched from wired to wireless. Prior to that event It was running and I was hearing the announcements.


73, dave
ab9ca/4


Re: UDRC-II holding PTT on during reboot

VK3IL
 

Thanks Jeremy for the explanation. I will leave my mitigation in then for now. The shutdown case shouldn't be an issue generally as I am configuring the RPi to be hardened against power switch off (this is a mobile application) using a read only SD card implemented with overlayfs. Hence I won't be using shutdown at all in practice. It's probably worth documenting this somewhere to warn people in other use cases.

Thanks,

David.


Re: Where did the modulation go . . .

Jeremy McDermond <mcdermj@...>
 

On Nov 28, 2016, at 1:40 PM, ab9ca@... wrote:



OK, you are speaking a language I do not understand. I don't know what BCM is nor where to find it.
BCM is short for Broadcom, the manufacturer of the System on a Chip used on the Raspberry Pi. The IC itself has pin numbers that are used in the Linux kernel and Raspberry Pi firmware to identify the pins.

I don't know what pinout.xyz is nor where to find it.
http://pinout.xyz is a cool site that shows you the pin assignments for a Raspberry Pi header.

Maybe if we use the 40 pin header we can both recognize which pin we are talking about?
The numbers in parenthesis are the 40-pin header numbers.

While this command is running I see the following on these pins of the 40 pin header:

pin 3 - a DC voltage of about 3.4v, no waveform
pin 5 - a DC voltage of about 3.4v, no waveform
These look correct. The I2C should idle high.

pin 7 - nothing, no DC nor waveform
This is worrisome. This should be a 25MHz square wave. But as I said, it will *only* turn on if the mixer is set up correctly.

pin 12 - apprx 3.4v rectangular wave at approx 3 MHz
This is about right. Your playback is 32bits/sample * 48kHz * 2 samples = 3.072 MHz.

pin 35 - rectangular wave approx 3.4v approx 48 kHz
This matches your sample rate, so this is correct.

pin 38 - nothing
This is correct. You’re not recording, you’re playing back.

pin 40 - a pulse width modulated 3.4 v rectangular waveform
This is your playback data.

This command should cause the RPi to generate a 1000 Hz tone and send it to din 6. It does not do so.

Should there not be the master clock on pin 7?
Yes, but only if the kernel thinks there’s a valid playback path. Your mixer settings look correct, though.

What is the output of

sudo gpio readall

It should look something like:

+-----+-----+---------+------+---+---Pi 2---+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| | | 3.3v | | | 1 || 2 | | | 5v | | |
| 2 | 8 | SDA.1 | ALT0 | 1 | 3 || 4 | | | 5V | | |
| 3 | 9 | SCL.1 | ALT0 | 1 | 5 || 6 | | | 0v | | |
| 4 | 7 | GPIO. 7 | ALT0 | 0 | 7 || 8 | 1 | ALT0 | TxD | 15 | 14 |
| | | 0v | | | 9 || 10 | 1 | ALT0 | RxD | 16 | 15 |
| 17 | 0 | GPIO. 0 | IN | 0 | 11 || 12 | 1 | ALT0 | GPIO. 1 | 1 | 18 |
| 27 | 2 | GPIO. 2 | OUT | 1 | 13 || 14 | | | 0v | | |
| 22 | 3 | GPIO. 3 | OUT | 0 | 15 || 16 | 1 | OUT | GPIO. 4 | 4 | 23 |
| | | 3.3v | | | 17 || 18 | 1 | OUT | GPIO. 5 | 5 | 24 |
| 10 | 12 | MOSI | IN | 0 | 19 || 20 | | | 0v | | |
| 9 | 13 | MISO | IN | 0 | 21 || 22 | 1 | IN | GPIO. 6 | 6 | 25 |
| 11 | 14 | SCLK | IN | 0 | 23 || 24 | 1 | IN | CE0 | 10 | 8 |
| | | 0v | | | 25 || 26 | 1 | IN | CE1 | 11 | 7 |
| 0 | 30 | SDA.0 | IN | 1 | 27 || 28 | 1 | IN | SCL.0 | 31 | 1 |
| 5 | 21 | GPIO.21 | IN | 1 | 29 || 30 | | | 0v | | |
| 6 | 22 | GPIO.22 | OUT | 1 | 31 || 32 | 0 | OUT | GPIO.26 | 26 | 12 |
| 13 | 23 | GPIO.23 | OUT | 1 | 33 || 34 | | | 0v | | |
| 19 | 24 | GPIO.24 | ALT0 | 1 | 35 || 36 | 0 | IN | GPIO.27 | 27 | 16 |
| 26 | 25 | GPIO.25 | IN | 0 | 37 || 38 | 0 | ALT0 | GPIO.28 | 28 | 20 |
| | | 0v | | | 39 || 40 | 0 | ALT0 | GPIO.29 | 29 | 21 |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+---Pi 2---+---+------+---------+-----+-----+

I’m mainly interested in the state of Pin 7 in here to make sure the “Mode” is set to “ALT0”.

I don;t think the I2C is used by this script so I can understand no activity on pins 2 and 3.
You’ll see a burst of activity at the start of the transfer when the kernel sets up the chip, but it’ll go quiet after that.

The following is for education more than anything else; not only for you but for others on the list as well. Each of the pins on the 40-pin header has multiple functions it can serve. They can all pretty much be GPIO inputs or outputs, but there are also multiple “ALT” modes that the pins can be put in as well. These “ALT” modes are hooked to hardware on the System on a Chip (SoC) that provide specialized interfaces like I2C, I2S, SPI, Serial, etc. http://pinout.xyz will show you these alternate modes if you click on a pin on the header. For example, if you click on Pin 7, which is BCM4, you’ll see that ALT0 is GPCLK0, which is the first General Purpose Clock on the Raspberry Pi. ALT1 is for a secondary memory interface, and ALT5 is a pin for the JTAG test interface.

These pin functions are set up in two ways by NWDR. First, there is a chunk of firmware on the I2C ID flash on the UDRC itself. This tells the firmware how to set up the pins and their functions. Once the kernel is booted, the kernel will “claim” the pins and set them up for the various devices on the system. Again, there is a piece of the firmware on the ID flash on the UDRC that tells the kernel that there is additional hardware on the Raspberry Pi. This is the RPi “HAT” specification that’s detailed at https://github.com/raspberrypi/hats. NWDR tries to fully comply with the spec as much as possible.

There are issues, though, when it comes to using the wiringPi library. This library, instead of using kernel interfaces to control the GPIO pins, writes directly to the memory registers in the SoC. At first it used to do this directly through /dev/mem which is a huge security hole. The RPi folks, though, wrote a special driver that presents a device called /dev/gpiomem that is a little less dangerous. The problem is that this will “yank the rug” out from under the kernel if you’re not careful. The kernel isn’t notified that the wiringPi has changed the function of pins and breaks things. The kernel won’t let you use these pins through its normal interfaces because something else has already claimed them.


What next?
Lets make sure that your MCLK isn’t getting borked somehow. dstarrepeater uses wiringPi and can screw that up if it’s set up incorrectly. After that we’re more looking at mixer settings to make sure that the DACs are on.

73, dave

ab9ca/4
--
Jeremy McDermond
nh6z@...