I'm learning SDR by trying to decode different 433Mhz keyfob signals.
My initial flow for capture and pre-processing looks like this:
What I get on the sink is:
I guess the bits are visible fine and I could proceed to decode it somehow. But I am worried about the big difference in the amplitude: the very beginning of the burst has much higher amplitude in comparison to the rest of the packet. This picture is very consistent (I was not able to get bursts with more balanced amplitudes). If I was speaking about music recording I would look for a compression method. But I don't know what the equivalent in the SDR world is.
I'm not sure if this will be a problem when I'll try to quadrature demod, binary slice and/or clock recover.
Is this a known problem and what is the approach to eliminate it within GNU Radio Companion?
I am new to AudioKit. I want to build a Synth with two Oscillators where one is synced by the other, means every wavelength of OSC1 (every second zero-crossing) the OSC2 is restarted (phase set to 0). Is this possible with AKOperation oscillators? thnx!
Edit: Maybe my explanation was very bad. Wikipedia is better: "One oscillator will restart the period of another oscillator, so that they will have the same base frequency. This can produce a musical sound, rich with harmonics. The timbre can be altered on the synched oscillator by varying its frequency input. A synched oscillator that resets the other oscillator(s) is called the master, and any synched oscillator that is reset by another oscillator is called a slave."
And here is some nice sounding visualization on YouTube.
Another Link with image and some maths.
EDIT 2: I have a strong feeling that this needs some DSP code. I thought about triggering stop()-and-start() with phase set to 0 by an Metronome running with the master osc frequency - but this does not sound like a good performing solution.
any thoughts/help is very appreciated!
I'm trying to implement a simple noise gate if the amplitude is beyond a certain threshold using AudioKit.
I believe this should be simple and I just need to use the AKAmplitudeTracker and set the output to zero, but I can't work out how to do the latter part.
Source for AKAmplitudeTracker
If I understand your question, you don't know how to set the output to zero. I'll go ahead and write the most obvious answer first, send the output through a booster,
...tracker stuff...
let booster = AKBooster(tracker, gain: 0)
AudioKit.output = booster
and then wherever you poll the tracker, set
if tracker.amplitude > threshold {
booster.gain = 1
}
Mind you, this will be very primitive and you'll have a better noise gate doing things at the DSP level, but this may be good enough for a proof of concept or test.
Here's what I have:
Acoustic model (CMU Sphinx) to be used in a keyword spotter. Trained for speech sampled at 16kHz and performs well. Doesn't perform well when presented with a speech signal sampled at 8kHz or a speech signal with max bandwidth of 4kHz and sample rate = 16kHz.
A microphone which only delivers a narrow-band signal. The bandwidth of the signal is max 4kKz. I can set the sample rate (audio driver API) to 16kHz, but the bandwidth remains the same since the underlying
HW samples at 8kHz. Can't change that!
Here's the result:
The keyword spotter fails when it's presented with a speech signal (sample rate 16kHz) which only has
a bandwidth of 4kHz.
Here's my question:
Would it be reasonable to expect that the keyword spotter will work if I "fake it" by bandwidth
extending the narrowband signal prior to sending it to the keyword spotter?
What is the simplest BW-extender ? (I'm looking for something which can be implemented fast).
Thanks
There are 8khz models, you should use them instead.
https://sourceforge.net/projects/cmusphinx/files/Acoustic%20and%20Language%20Models/US%20English/cmusphinx-en-us-ptm-8khz-5.2.tar.gz
Does anyone know of anywhere I can find actual code examples of Software Phase Locked Loops (SPLLs) ?
I need an SPLL that can track a PSK modulated signal that is somewhere between 1.1 KHz and 1.3 KHz. A Google search brings up plenty of academic papers and patents but nothing usable. Even a trip to the University library that contains a shelf full of books on hardware PLL's there was only a single chapter in one book on SPLLs and that was more theoretical than practical.
Thanks for your time.
Ian
I suppose this is probably too late to help you (what did you end up doing?) but it may help the next guy.
Here's a golfed example of a software phase-locked loop I just wrote in one line of C, which will sing along with you:
main(a,b){for(;;)a+=((b+=16+a/1024)&256?1:-1)*getchar()-a/512,putchar(b);}
I present this tiny golfed version first in order to convince you that software phase-locked loops are actually fairly simple, as software goes, although they can be tricky.
If you feed it 8-bit linear samples on stdin, it will produce 8-bit samples of a sawtooth wave attempting to track one octave higher on stdout. At 8000 samples per second, it tracks frequencies in the neighborhood of 250Hz, just above B below middle C. On Linux you can do this by typing arecord | ./pll | aplay. The low 9 bits of b are the oscillator (what might be a VCO in a hardware implementation), which generates a square wave (the 1 or -1) which gets multiplied by the input waveform (getchar()) to produce the output of the phase detector. That output is then low-pass filtered into a to produce the smoothed phase error signal which is used to adjust the oscillation frequency of b to push a toward 0. The natural frequency of the square wave, when a == 0, is for b to increment by 16 every sample, which increments it by 512 (a full cycle) every 32 samples. 32 samples at 8000 samples per second are 1/250 of a second, which is why the natural frequency is 250Hz.
Then putchar() takes the low 8 bits of b, which make up a sawtooth wave at 500Hz or so, and spews them out as the output audio stream.
There are several things missing from this simple example:
It has no good way to detect lock. If you have silence, noise, or a strong pure 250Hz input tone, a will be roughly zero and b will be oscillating at its default frequency. Depending on your application, you might want to know whether you've found a signal or not! Camenzind's suggestion in chapter 12 of Designing Analog Chips is to feed a second "phase detector" 90° out of phase from the real phase detector; its smoothed output gives you the amplitude of the signal you've theoretically locked onto.
The natural frequency of the oscillator is fixed and does not sweep. The capture range of a PLL, the interval of frequencies within which it will notice an oscillation if it's not currently locked onto one, is pretty narrow; its lock range, over which it will will range in order to follow the signal once it's locked on, is much larger. Because of this, it's common to sweep the PLL's frequency all over the range where you expect to find a signal until you get a lock, and then stop sweeping.
The golfed version above is reduced from a much more readable example of a software phase-locked loop in C that I wrote today, which does do lock detection but does not sweep. It needs about 100 CPU cycles per input sample per PLL on the Atom CPU in my netbook.
I think that if I were in your situation, I would do the following (aside from obvious things like looking for someone who knows more about signal processing than I do, and generating test data). I probably wouldn't filter and downconvert the signal in a front end, since it's at such a low frequency already. Downconverting to a 200Hz-400Hz band hardly seems necessary. I suspect that PSK will bring up some new problems, since if the signal suddenly shifts phase by 90° or more, you lose the phase lock; but I suspect those problems will be easy to resolve, and it's hardly untrodden territory.
This is an interactive design package
for designing digital (i.e. software)
phase locked loops (PLLs). Fill in the
form and press the ``Submit'' button,
and a PLL will be designed for you.
Interactive Digital Phase Locked Loop Design
This will get you started, but you really need to understand the fundamentals of PLL design well enough to build it yourself in order to troubleshoot it later - This is the realm of digital signal processing, and while not black magic it will certainly give you a run for your money during debugging.
-Adam
Have Matlab with Simulink? There are PLL demo files available at Matlab Central here. Matlab's code generation capabilities might get you from there to a PLL written in C.