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

Join udrc@nw-digital-radio.groups.io to automatically receive all group messages.