Date   

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@...


Re: UDRC-II holding PTT on during reboot

Jeremy McDermond <mcdermj@...>
 

On Nov 28, 2016, at 2:53 PM, VK3IL <david@...> wrote:

UDRC-I is quite different on PTT. It has a single PTT line (also on GPIO 12), but does not have any buffer transistor. In UDRC-II, there are 2 separate PTT lines buffered with transistors on GPIO 12 and GPIO 23.

That has made me wonder though if the on chip pull-up on this line has been left active in UDRC-II (which would have been necessary in UDRC-I) ? This would trigger the symptoms I am seeing due to the inverting action of the transistor buffer, The pull-up state transcends power down and so would explain the behaviour I suspect.
The pull-up/down resistors on the chip are only active when the pin is in input mode. The firmware on the UDRC tries to set up the pin so that you don’t get this behavior, but unfortunately I haven’t been able to make it work out correctly. This is a problem that we are aware of and it’s on my long list of things to do to try to find a workaround for folks. Unfortunately part of this is hardware based because the Broadcom chip itself has defaults that don’t come up quite right. I wish I could give you a better answer.

Regards,

David.
--
Jeremy McDermond
nh6z@...


Re: Where did the modulation go . . .

ab9ca@...
 

Thank you Stuart!


With your input I pulled off the text, saved it to a file, changed owner & group, and made it executable. That left only to correct 'plughw' error on approx line 246.


It seems to run now:


pi@compass:~ $ ./measure_deviate.sh.2 -f 1000 -c din6 -l 180

Using tone: 1000 (wave file name: 1000hzsin.wav) for duration 180 & connector: din6 using gpio: 23


=== Found existing wav file: 1000hzsin.wav and tone length is not default 30 seconds.

May want to delete existing wavefile 1000hzsin.wav to create a different tone duration


If using devcal from Svxlink make sure devcal line has -f1000

Using PTT GPIO 23 with tone of 1000 Hz

Playing WAVE '1000hzsin.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo

Hardware PCM card 0 'udrc' device 0 subdevice 0

Its setup is:

  stream       : PLAYBACK

  access       : RW_INTERLEAVED

  format       : S32_LE

  subformat    : STD

  channels     : 2

  rate         : 48000

  exact rate   : 48000 (48000/1)

  msbits       : 32

  buffer_size  : 24000

  period_size  : 6000

  period_time  : 125000

  tstamp_mode  : NONE

  period_step  : 1

  avail_min    : 6000

  period_event : 0

  start_threshold  : 24000

  stop_threshold   : 24000

  silence_threshold: 0

  silence_size : 0

  boundary     : 1572864000

  appl_ptr     : 0

  hw_ptr       : 0

##################################################+| MAX^C

Aborted by signal Interrupt...

##########################                        +| MAX

** carrier off from trapped CTRL-C




Now, if only we could figure out why my UDRC quit running . . . 

I still hear nothing but the right port does key.

73, dave
ab9ca/4


Re: Where did the modulation go . . .

Stuart Longland VK4MSL
 

On 29/11/16 08:58, ab9ca@... wrote:
OK, I did the 'wget':
pi@compass:~ $ wget
https://github.com/nwdigitalradio/n7nix/blob/master/deviation/measure_deviate.sh
Yeah, have a close look at the link. In fact, rename the file to have
.html on the end and open it. Then please have a look at my earlier reply.

--2016-11-28 22:50:24--
https://github.com/nwdigitalradio/n7nix/blob/master/deviation/measure_deviate.sh

Length: unspecified [text/html]
^^^^^^

Bourne Shell doesn't understand this.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.


Re: Where did the modulation go . . .

 

Look inside downloaded files before trying to executing them, e.g. more measure_deviate.sh


On Mon, Nov 28, 2016 at 3:00 PM, John D. Hays <john@...> wrote:

On Mon, Nov 28, 2016 at 2:58 PM, John D Hays - K7VE <john@...> wrote:
If you goto https://github.com/nwdigitalradio/n7nix/tree/master/deviation
You will see a link to the script, but it shows you a view of it (HTML page), you will see a 'raw' button that gives you actual contents of the script (no HTML).
The wget I provided will get you the contents.

On Mon, Nov 28, 2016 at 2:49 PM, <ab9ca@...> wrote:


So . . .  the link at the top of this page:

https://github.com/nwdigitalradio/n7nix/tree/master/deviation


That is very plainly labeled as 'measure_deviate.sh' is in fact not measure_deviate.sh? 

No wonder I am lost . . . . 

Seems that if it is labeled as such it should be that . . . 

If it is info should it not be labeled as info?

And if it is a 'go to this page to download' should it not be labeled as that?


I'll see if I can figure out what in world you guys are talking about.


73, dave

ab9ca/4






--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


Re: Where did the modulation go . . .

 

On Mon, Nov 28, 2016 at 2:58 PM, John D Hays - K7VE <john@...> wrote:
If you goto https://github.com/nwdigitalradio/n7nix/tree/master/deviation
You will see a link to the script, but it shows you a view of it (HTML page), you will see a 'raw' button that gives you actual contents of the script (no HTML).
The wget I provided will get you the contents.

On Mon, Nov 28, 2016 at 2:49 PM, <ab9ca@...> wrote:


So . . .  the link at the top of this page:

https://github.com/nwdigitalradio/n7nix/tree/master/deviation


That is very plainly labeled as 'measure_deviate.sh' is in fact not measure_deviate.sh? 

No wonder I am lost . . . . 

Seems that if it is labeled as such it should be that . . . 

If it is info should it not be labeled as info?

And if it is a 'go to this page to download' should it not be labeled as that?


I'll see if I can figure out what in world you guys are talking about.


73, dave

ab9ca/4






--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


Re: Where did the modulation go . . .

 

If you goto https://github.com/nwdigitalradio/n7nix/tree/master/deviation
You will see a link to the script, but it shows you a view of it (HTML page), you will see a 'raw' button that gives you actual contents of the script (no HTML).
The wget I provided will get you the contents.

On Mon, Nov 28, 2016 at 2:49 PM, <ab9ca@...> wrote:


So . . .  the link at the top of this page:

https://github.com/nwdigitalradio/n7nix/tree/master/deviation


That is very plainly labeled as 'measure_deviate.sh' is in fact not measure_deviate.sh? 

No wonder I am lost . . . . 

Seems that if it is labeled as such it should be that . . . 

If it is info should it not be labeled as info?

And if it is a 'go to this page to download' should it not be labeled as that?


I'll see if I can figure out what in world you guys are talking about.


73, dave

ab9ca/4






--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


Re: Where did the modulation go . . .

ab9ca@...
 

OK, I did the 'wget':


pi@compass:~ $ wget https://github.com/nwdigitalradio/n7nix/blob/master/deviation/measure_deviate.sh

--2016-11-28 22:50:24--  https://github.com/nwdigitalradio/n7nix/blob/master/deviation/measure_deviate.sh

Resolving github.com (github.com)... 192.30.253.113

Connecting to github.com (github.com)|192.30.253.113|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/html]

Saving to: ‘measure_deviate.sh.1’


measure_deviate.sh.1        [  <=>                            ]  98.18K   272KB/s   in 0.4s   


2016-11-28 22:50:30 (272 KB/s) - ‘measure_deviate.sh.1’ saved [100539]



And it says it got it. 

I make that executable and run it:

pi@compass:~ $ sudo chmod +x ./measure_deviate.sh.1

pi@compass:~ $ ./measure_deviate.sh.1 -f 1000 -c din6 -l 180
./measure_deviate.sh.1: line 5: syntax error near unexpected token `newline'
./measure_deviate.sh.1: line 5: `<!DOCTYPE html>'

Something still not quite right.

73, dave
ab9ca/4


Re: Where did the modulation go . . .

Stuart Longland VK4MSL
 

On 29/11/16 08:49, ab9ca@... wrote:
So . . . the link at the top of this page:

https://github.com/nwdigitalradio/n7nix/tree/master/deviation
That is a link to the directory listing.

That is very plainly labeled as 'measure_deviate.sh' is in fact not
measure_deviate.sh?
Yep, it is 'measure_deviate.sh', it links to the source code listing of
that file. It is *NOT* the raw file, but a pretty-printed version for
viewing in a web browser.

The link for this is
https://github.com/nwdigitalradio/n7nix/blob/master/deviation/measure_deviate.sh

If you have a look, you'll see what I mean. Now, up the top of the
source code listing, you'll see a button labelled "Raw", *that* link is
the one you feed to curl/wget/whatever.

If you click it, it'll take you to here:
https://raw.githubusercontent.com/nwdigitalradio/n7nix/master/deviation/measure_deviate.sh

Note the lack of formatting and pretty printing.

No wonder I am lost . . . .

Seems that if it is labeled as such it should be that . . .
Blame Github. It's their UI. Unfortunately this is not under anyone's
control but theirs.

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.