Where did the modulation go . . .


ab9ca@...
 


On 11/24/16 5:56 PM, John D Hays - K7VE wrote:
> There is a sub-group for UDRC.
>

Maybe you can move the discussion to that sub-group? Or maybe I can. Will give it a stab.


> Going over wired or wireless does not make any difference to
> ircddbgateway.

AFAIK ircddbgateway is working OK. As I said in my note, it is dstarrepeater that is not working. I get no RX nor TX showing in the dstarrepeater.log file or when viewing the tail during operation.

>
> Do you have ircddbgateway and dstarrepeater talking to each other over
> the 127.0.0.1 address? If you were using LAN addresses, that could be
> the disconnect.

As far as I can tell, yes. Both config files show that address for the other device. Not using LAN addresses at all.

>
> If your alsa settings are correct, try shutting down and removing
> power to be sure nothing is in a unknown state.

This occurred yesterday afternoon late. The entire setup was without power overnight. The levels in alsamixer are as I left them set when it was sorta working.

>
> Can you perform other network activity from the RPI over Wifi?

Yes, I call up the NW Digital site to look over the instructions.

>
> I will be doing Thanksgiving with the family so may not be available
> for hours at a time.

Thank you much for your help . . . on Thanksgiving Day no less! I was not expecting to hear anything until tomorrow at the earliest.

Keep in mind that the setup was working for everything but audio from the reflectors. I could link to a reflector, hear the canned message that I was linked, etc. The crawl was being decoded and displayed on the screen of the 91AD. The addresses had to be right for all that to happen.

But while trying to set up the port forwarding I lost wired connectivity. The instant I connected via wireless, dstarrepeater stopped working. Nothing else changed. I told the RPi to connect to the wireless and dstarrepeater stopped working. No RX has been decoded since, nor have a I heard any modulation when the ID's key the TX, only dead carrier.

I have the ID interval set to 2 min. But earlier, while troubleshooting, it had been set to 30 sec. I see the ID being sent in the dstarrepeater.log window but nothing is heard over the air.

I have the tail of dstarrepeaterd.log in one window, the tail of ircddbgatewayd.log in another, and have a 3rd open to type commands into.

73 de dave
ab9ca/4


>
>
> On Nov 24, 2016 15:47, <ab9ca@... <mailto:ab9ca@...>> wrote:
>
>
>     OK, after several frustrating hours I finally got the UDRC to the
>     point where I could log on to reflectors. Heard the canned message
>     about being linked. But heard no reflector audio. I assume that is
>     because I had not yet set up port forwarding.
>
>     While trying to set up port forwarding something happened to my
>     router. Not sure what. Lost wired internet connectivity. Dunno what
>     caused it but eventually got it resolved and think the port forwarding
>     is set up. Have wired connectivity back.
>
>     While I had lost wired internet, the wireless still worked. So I set
>     the RPi up to connect wirelessly.  Apparently this is a mistake. The
>     docs are totally silent on this. No reason not to connect wireless,
>     right? The instant it connected wirelessly, the modulation
>     disappeared, and, numerous reboots and restarts later, it has not
>     re-appeared.
>
>     So why does the radio connection care about whether the internet is
>     wired or wireless?
>
>     And how do I get modulation back?
>
>     PTT is still working. I get dead carrier when the UDRC ID's. Note that
>     I also have no detection of RX modulation. Neither TX nor RX shows any
>     response. The internet connection does work, I can see the activity in
>     ircddbgatewayd.log. But nothing shows up in dstarrepeaterd@1.log <mailto:dstarrepeaterd@1.log>. And
>     I hear nothing over the air. Monitoring with a RX set to analog FM.
>
>     I checked the levels in alsamixer and those appear to be OK.
>
>     73, dave
>     ab9ca/4


ab9ca@...
 


Thanks to Stuart for pointing out that the AIC3204 is likely not completely dead as alsamixer appears to be working correctly. 

OK, now with a tone input I can check the pins on the AIC3204. Running the modified tone generator script with this command (no need to use sudo):

./measure_deviate.sh 1000 100

I see:

On pin 1 *NOTHING* the schematic shows a 25 MHz Master clock on here but I see no signal. Is this the issue?

On pin 2 I see an approx 3 MHz 3.4v rectangular waveform

On pin 3 I see a 48 kHz 3.4v rectangular waveform

On pin 4 I see a rectangular waveform that is 3.4v but with variable pulse width. This is the tone input? 

On pins 22 and 23 I see a small DC level, about 1v, but no output waveform. 

Any other pins I should check? 

Freq and amplitude measurements are from my Rigol 100 MHz scope. 

Is the issue the missing Master Clock on pin 1 or is the schematic in error and we have something else? 

I dunno if this is germane or not but when I told the RPi to switch to the wireless internet, and killed the modulation, the UDRC was transmitting an ID. Is there something in one of the scripts that would go crazy if we switched internet while key is down?


73 de dave

ab9ca/4



Jeremy McDermond <mcdermj@...>
 

With regards to the pins that drive the AIC3204, you should be looking at the following. You can check these on pinout.xyz that shows you RPi 40-pin pinout as well as BCM numbers. When I talk about things, I will generally refer to BCM numbers. I will *never* refer to “wiringPi” numbers.

Pins (RPi header numbers in parenthesis):

BCM 2 (RPi 3) — SDA - I2C Data Pin - Control bus for the AIC3204
BCM 3 (RPi 5) — SCL - I2C Clock Pin - Control bus for the AIC3204
BCM 4 (RPi 7) — GPCLK0 - General Purpose Clock 0 - This is used for the 25MHz MCLK into the AIC3204
BCM 18 (RPi 12) — BCLK - I2S Bit Clock - Data bus for the AIC3204
BCM 19 (RPi 35) — FCLK - I2S Frame Clock - Data bus for the AIC3204
BCM 20 (RPi 38) — DIN - I2S Data In - Sample data from the ADC on the AIC3204
BCM 21 (Rpi 40) — DOUT - I2S Data Out - Sample data to the DAC on the AIC3204

Note that the AIC3204 driver uses DAPM for audio power management. That means that the kernel will shut down clocks it doesn’t think are going to be used. This causes the clocks, this includes MCLK, BCLK, and FCLK, to be dead unless there’s active audio being played or recorded. They will only come on when the audio device is in use. Similarly, if the mixer settings are set such that there is no valid path from the DAC to the output pin, the DAPM system will shut down the appropriate components on the AIC3204 to save power. They’ll only come on if there’s a valid path in the mixer from source to output.

This really doesn’t sound like a low level issue with I2C/I2S though. If you had audio working before and were hearing announcements and now you don’t, there’s likely another issue going on here. Have you installed anything that tries to mess with the GPIO pins? wiringPi is particularly problematic because it pokes at memory behind the OS’s back and breaks things.


Jeremy McDermond
nh6z@nh6z.net


ab9ca@...
 


OK, you are speaking a language I do not understand. I don't know what BCM is nor where to find it. I don't know what pinout.xyz is nor where to find it. Maybe if we use the 40 pin header we can both recognize which pin we are talking about?


So far as I know there is nothing else running on the RPi.  But I can no longer recall how to display what is running. Years ago I ran Linux full time. But have forgotten much of it. 


The new tone generation script does not work. I get the following:

..........................

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

./measure_deviate.sh: line 5: syntax error near unexpected token `newline'

./measure_deviate.sh: line 5: `<!DOCTYPE html>'

..........................................

However I still have the old script that does work, AFAIK. I renamed it 'generate_tone.sh'. The following command should generate 1000 cycle tone for 3 min:

................................. 
pi@compass:~ $ ./generate_tone.sh 1000 10
Found existing wav file: 1000hzsin.wav
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
...............................................

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
pin 7 - nothing, no DC nor waveform
pin 12 - apprx 3.4v rectangular wave at approx 3 MHz

pin 35 - rectangular wave approx 3.4v approx 48 kHz

pin 38 -  nothing

pin 40 - a pulse width modulated 3.4 v rectangular waveform


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? 


I don;t think the I2C is used by this script so I can understand no activity on pins 2 and 3.


What next?


73, dave

ab9ca/4



Stuart Longland VK4MSL
 

On 29/11/16 07:40, ab9ca@arrl.net wrote:
pi@compass:~ $ ./measure_deviate.sh -f 1000 -c din6 -l 180

./measure_deviate.sh: line 5: syntax error near unexpected token `newline'

./measure_deviate.sh: line 5: `<!DOCTYPE html>'
You've downloaded a HTML file and you're trying to execute it as if it
were a shell script. As the script in question lacks the initial #!
characters to tell the shell what program is supposed to execute the
script, it tries to "execute" the HTML directly.

HTML is not valid Bourne shell syntax.
--
Stuart Longland (aka Redhatter, VK4MSL)

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


Basil Gunn
 

On Mon, 28 Nov 2016 13:40:30 -0800
ab9ca@arrl.net wrote:


The new tone generation script does not work. I get the following:

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

./measure_deviate.sh: line 5: syntax error near unexpected token
`newline'

./measure_deviate.sh: line 5: `<!DOCTYPE html>'
You are not running the script. There is no `<!DOCTYPE html>' in the
script.

git clone https://github.com/nwdigitalradio/n7nix
cd n7nix/deviation/
./measure_deviate.sh -f 1000 -c din6 -l 180


 

On Mon, Nov 28, 2016 at 1:59 PM, Basil Gunn <basil@...> wrote:
On Mon, 28 Nov 2016 13:40:30 -0800
ab9ca@... wrote:

>
> The new tone generation script does not work. I get the following:
>
> pi@compass:~ $ ./measure_deviate.sh -f 1000 -c din6 -l 180
>
> ./measure_deviate.sh: line 5: syntax error near unexpected token
> `newline'
>
> ./measure_deviate.sh: line 5: `<!DOCTYPE html>'

You are not running the script. There is no `<!DOCTYPE html>' in the
script.

git clone https://github.com/nwdigitalradio/n7nix
cd n7nix/deviation/
./measure_deviate.sh -f 1000 -c din6 -l 180






--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


ab9ca@...
 


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




Stuart Longland VK4MSL
 

On 29/11/16 08:49, ab9ca@arrl.net 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.


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


 

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
   


 

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
   


 

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
   


Stuart Longland VK4MSL
 

On 29/11/16 08:58, ab9ca@arrl.net 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.


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


Jeremy McDermond <mcdermj@...>
 

On Nov 28, 2016, at 1:40 PM, ab9ca@arrl.net 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@nh6z.net


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


Jeremy McDermond <mcdermj@...>
 

On Nov 28, 2016, at 7:30 PM, ab9ca@arrl.net 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@nh6z.net

73, dave
ab9ca/4


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



 

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