Phase Correct Square Wave to Audio Sine Signal on a GIOP?

Status
Not open for further replies.

frist

New member
Hi,
I would like to use a Teensy 3.5 and the Audio Shield (Rev. C) to generate two signals:

a) a sine tone using the audio shield and
b) a digital square wave signal with the same frequency and adjustable phase angle to the sine signal.

I can already generate the sine signal (easy as the very first example in the tutorial does this already) but I don't have a idea how to approach the second signal.

I know that the sampling frequency is 60MHz/1360 so I could use a timer to generate a signal of the same frequency but I would not know the phase angle and I'm afraid over time the phase angle might drift.

Any ideas how to approach this problem?

See you
Flo
 
I don't see an easy way to do this. About all I can come up with is to create a new Audio Library class to generate the sine wave (copy AudioSynthWaveform and get rid of everything but sine) and square wave at the same time.

Every update period the class will generate the next 128 samples for the output Audio Block and at the same time write the next 128 sample of the properly-phased square into a buffer. Then, blast the square wave out of a GPIO port using DMA at exactly the Audio Library's update frequency. This is a similar concept to what the OctoWS2811 LED Library does. Of course, you'll occupy 8 bits in that port even though you only need one output line.

The trick will be timing the DMA operations synchronously with the Audio Library sample rate. Perhaps you could route LRCK from the I2S interface (which runs at the audio sample rate) to an input port and trigger a 1-byte DMA operation on every rising (or falling) edge.
 
Thinking about it some more, a MUCH simpler solution would be to use one AudioSynthWaveform object to generate the sine wave and another one to generate the square wave the same frequency but with a variable phase offset. Then route the square wave to one of the T3.5’s DAC outputs. It’s not a "GIOP [sic]" output per the subject line of your thread, but maybe it will work for your application.
 
Create two sine waves (to left and right channels) with the phase angle you want and then use a comparator to convert the other channel to square wave.
 
That would not allow setting a defined, but arbitrary phase.
Why not? Seems like this should work too:
Code:
#include "Arduino.h"
#include <Audio.h>

AudioSynthWaveform sine;
AudioSynthWaveform square;
AudioOutputAnalogStereo dacs1;
AudioConnection patchCord1(sine, 0, dacs1, 0);
AudioConnection patchCord2(square, 0, dacs1, 1);


void setup() {
  float freq = 440.0;
  float angle = 90.0;

  AudioMemory(15);
  AudioNoInterrupts();

  sine.begin(WAVEFORM_SINE);
  sine.frequency(freq);
  sine.amplitude(1.0);
  sine.phase(0);

  square.begin(WAVEFORM_SQUARE);
  square.frequency(freq);
  square.amplitude(1.0);
  square.phase(angle);

  AudioInterrupts();
}

void loop() {
}
 
Ah, there, yes. I had only focused on the comparator thing mentioned by mhelin. I stand corrected.

Problem with the square wave generated that way is that it will be aliased unless the AudioSynthWaveform can produce alias-free waveforms. Using a comparator on aliased trivial square wave would remove all aliasing in analog domain though.

If you use comparator on sine wave there is obviously some phase differerence (about 90 deg if the comparor is set to trigger on max and min) which can be though corrected by the software using some negative offset in phase.
 
I don’t understand how aliasing would be an issue here. That seems more like an ADC sampling problem. Here we’re pushing data out of the DAC. Since the DAC has finite bandwidth, it may not faithfully produce the fast edges and the response to each sample may last longer than the sample period (at 44.1 Ksamples / sec). But, that causes Inter-Symbol Interference (ISI), not aliasing. This is essentially trying to push a square wave through a low-pass filter.
 
I don’t understand how aliasing would be an issue here. That seems more like an ADC sampling problem. Here we’re pushing data out of the DAC. Since the DAC has finite bandwidth, it may not faithfully produce the fast edges and the response to each sample may last longer than the sample period (at 44.1 Ksamples / sec). But, that causes Inter-Symbol Interference (ISI), not aliasing. This is essentially trying to push a square wave through a low-pass filter.

We don't know why there are these requirements. Anyway a trivial sampled (not actually sampled but calculated in this case but considered as sample) square wave contains frequency components above Nyqvist thus aliasing (study sampling theory). If you're frequency or actually sample period is integer number then the aliasing might be low enough not to matter.

https://en.wikipedia.org/wiki/Sampling_(signal_processing)
https://en.wikipedia.org/wiki/Aliasing
 
You are incorrectly applying the aliasing concept to this situation.

The sampling rate of the Audio Library is ~44 KHz. Imagine that every sampling period you sent bits from the sequence 10101010101010…… to a digital output, i.e. you toggled the output pin between 1 and 0 every sampling period. The output signal from that pin would be a 22 KHz square wave. If instead you used the sequence 1100110011001100…., then you'd get an 11 KHz square wave. 22 KHz is the fastest square wave you can make.

How truly "square" the output would look on a scope is solely a function of the driver circuit's analog bandwidth (and that of the scope / probe) because square waves do indeed have frequency content at higher (odd) harmonics. But, there is no aliasing. Rather, those higher harmonics are simply low-pass filtered by the limited bandwidth of the driver circuit. This will be seen as slower edge speeds. But, again, no aliasing.
 
Status
Not open for further replies.
Back
Top