Hi Barry,
On Thu, 2019-06-20 at 09:27 -0400, Barry Duggan wrote:
Marcus,
Thank you for that. So now I have three questions:
1) Does it matter if one uses [brackets] or (parentheses) to enclose a
vector? It appears not.
That's Python syntax; [] means Python list (a mutable sequence of
references to the contained elements), () means python tuple (immutable
seq...). The difference is irrelevant in this case; it's just that
[ 1 ] is a list containing the element 1 only, and ( 1 ) is just the
number one (with parentheses around it, meaning nothing), so when
explaining stuff, I'd prefer the more "explicit" []. (You'd need to do
(1,) if you wanted a single-element tuple.)
2) What determines the rate at which the vector contents are presented
to the output?
Nothing :)
This is just the exact sequence of numbers that are produced. It
doesn't have a physical rate.
GNU Radio will just repeat the vector on its output as fast as that
output is emptied. The speed at which that happens is completely (!!)
irrelevant to the math happening with that.
I'd recommend trying to completely forget about these signals having
something to do with an analog signal that changes over time, just for
a moment.
It's just a bunch of zeros and ones, one after the other. That goes
through some processing steps, let's say it gets multiplied by 213
first and then 106.5 gets subtracted. Now it's still a bunch of
numbers. Simply a sequence of numbers flowing through that flow graph.
There's no rate, or speed notion attached to that.
Now, these +106.5 and -106.5 values reach the frequency modulator. What
that does is it takes each number, multiplies it with its sensitivity,
adds the result to its internal phase accumulator, and produces a new
number on its output, which is simply exp(j·phase); still, everything
is just a sequence of numbers.
Some of these numbers might have a value that depends on a variable
that might for example be called samp_rate, or f_samp or whatever. But
that just changes the values of the numbers, not the fact that their
existence and calculation has nothing to do with real-world time.
Now, at some point, these numbers are sent to a DAC of some kind. And
now, that DAC actually is actually driven by some hardware clock that
forces it to take one sample every so and so many nanoseconds. Double
the speed of that clock, and you'd change the physical (frequency)
"meaning" of the digital signal you convert to analog, but not the
digital signal as is – it'd still be the same sequence of numbers.
3) If one were to add a 'throttle', where would it go? Is it needed
here?
Don't do it at all if you're actually building a modem.
A throttle is just a "copy input sequence to output" block, that goes
to sleep (as in: ask the operating system of your computer to wake it
in so and so many microseconds) for a while to limit the average number
of samples that it copies per second. You'd only do that if you're in a
simulation, and don't want signal processing to happen as fast as it
can (there not being a DAC that limits the rate at which they are
consumed), but still e.g. want to look at the signal with a human eye
at a sensible speed.
In your modem example, the DAC already limits the speed; don't "double
limit" it. From your obvious experience with digital clocked circuits,
you know that in the wake of two independent clocks (your DAC's clock
and your PC/operating system clock) there only lies madness, FIFO over-
and underflows and tears.
(same of course applies to reception: The ADC only gives us one sample
per sampling period; then, we process the resulting sequence as fast as
possible.)
Of course, one of the main things you'd use GNU Radio for is to first
design your modem in simulation before attaching real analog/digital or
digital/analog conversion hardware to it.
In that case:
1. If you want to test whether the modem works end-to-end, you'd attach
your TX modem flowgraph to your RX modem flow graph (maybe with a block
that simulates a wireless channel in between), and not throttle at all,
but just send some finite amount of test data and check whether the
result at the other end is the same.
2. But very often, you'd e.g. want to look at the output of your pulse
shaper in real time (or slow motion); then you'd just add exactly one
Throttle to your simulation, typically right at the visualization (that
position doesn't matter too much, however – as you can infer from my
description above, the whole flowgraph will always get the chunk of
samples that your Throttle passed through, and process it as fast as it
can, then go back into waiting for more data, while the throttle sleeps
for as long as it needs to sustain the requested average copying rate).
BTW, a minor correction: the second vector is missing a comma after
the
last 0.
oh, yeah!
Cheers,
Marcus
Thanks
---
Barry Duggan
On 2019-06-20 05:14, Müller wrote:
> Ah, I think I see where you're going :)
> So, here, we're really talking about digital clock division! That is, a
> counter :)
>
> While that'd be totally possible to piece together (counting edges,
> then emitting an edge every N input edges), it's not how DSP works: the
> things you handle *are* already with respect to a common time source.
>
> That also means that you don't have to worry about phase coherence: If
> you start two different oscillators at the same phase, they will stay
> coherent, as long as math doesn't fail.
>
> Because I think this is easier to show with binary signals than with an
> oscillation generation, try the following:
>
> 1. Add a vector source, output type "byte", values
> [0, 0, 0, 0, 0, 1, 1, 1, 1, 1]
> 2. Add a vector source, output type "byte", values
> [0, 0, 0, 0, 0, 0 1, 1, 1, 1, 1, 1]
> 3. use the "And" block from the "boolean operations" category, input
> type "byte"; connect the two vector sources to it.
> 4. add three "UChar to float" blocks. Connect one to the output of the
> first signal source, one to the output of the second, and one to the
> output of the And block.
> 5. Add a "Qt GUI time sink", input type float, number of inputs 3.
> 6. Connect the outputs of the UChar to float blocks to the inputs of
> the Qt GUI time sink.
>
> Let the whole thing run. You'll see how everything stays phase
> coherent, the AND of the two clocks just is the let's call it beat
> signal of the two clocks and everything is fine.
>
> > Why don't I just switch between 1277 and 1064 signal sources?
> > Because
> > the result is not phase-coherent.
>
> Luckily, that's not true :) (I've built something very much like that
> as a quick example for some stranger on the internet a couple years
> back, see [1]).
>
> This is software! All the signals in GNU Radio are just sequences of
> numbers. When you apply an operation to two sequences, the math just
> handles the two sequences coherently :) So, all the digital-logic
> problems of the real world, namely having things that drift off
> arbitrarily, don't apply.
>
> Now, you can imagine that this is not really how you'd build an FSK
> modem in GNU Radio.
>
> You can just simply go in,
>
> * "multiply const" and "add const" to your input signal,
> so that it makes sense as baseband frequency values;
> (in your case, I'd go with +- 213/2 Hz as frequencies),
> * Repeat (that's a block!) them for as many samples in your samp_rate
> one FSK symbol takes, and then
> * use a "Frequency Mod"¹ block straight away.
> (I'd go with sensitivity = 2*3.141 / samp_rate)
>
> You'd get CPFSK in baseband. Attach a Qt Frequency sink to see!
> If you used an interpolating FIR with a sensible pulse shape as taps
> instead of the Repeat block, you'd get CPFSK with a pulse shape.
>
> Best regards, and loads of fun,
>
> Marcus
>
> ----------
> ¹ btw: the "sensitivity" parameter of the Frequency Mod block gives the
> factor between input sample amplitude and output "phase advance in
> radians per sample"; e.g if your input is 10, 10, 10... , and your
> sensitivity is pi/200, then you produce a signal with a phase increase
> of 1/40 of a full cycle every sample, i.e. has a period of 40 samples,
> which means it has a frequency of f_sample/40.
>
>
> [1]
>
https://stackoverflow.com/questions/36898574/fsk-demodulation-with-gnu-radio/36915550#36915550
>
> On Wed, 2019-06-19 at 12:55 -0400, Barry Duggan wrote:
> > Marcus, Chris, and others:
> >
> > What I am really trying to do is replicate a time-domain FSK modem I
> > designed in 1972 (using discrete components of course). It used a
> > crystal oscillator at 12,770 hz (square wave) and divided that by 5
> > and
> > then ANDed with the input signal. The other path divided by 6 and
> > ANDed
> > with the inverted input signal. The two paths were ORed together and
> > divided by 2, giving a fairly good phase-coherent FSK with 1277 /
> > 1064
> > frequencies. Low pass filtering followed.
> >
> > Why don't I just switch between 1277 and 1064 signal sources?
> > Because
> > the result is not phase-coherent.
> >
> > My other objective is just to learn what I can do with Gnu radio :)
> >
> > Cheers!
> > ---
> > Barry Duggan