Re: [Discuss-gnuradio] Divide frequency by a constant

[CEL]

ha! That's easier than I think you think it is :)

So, you have some hardware to actually transmit. Let's, for the time
being, assume we're doing an acoustocoupler using your soundcard.
That's cool, because a) you very likely have that and b) it's easy to
observe :D

So, you use GNU Radio's Audio Sink block to send a sequence of numbers
to the sound card, and also configure the sound card to run at 44.1
kilosamples per second. (44.1 kS/s is the most common rate that all
soundcards can work at – I'm not 100% sure why Philips/Sony picked that
rate when they designed the CD, but it has really stuck since that
audio storage medium was introduced.)

That sets the "meaning" of a sample period on the stream going into the
Audio Sink. For example, a cosine going into that that takes 100
samples for a period will be a 441 Hz sound.

Now, you want a 45.45 bd transmission. So, you need to make all the
rate conversions from your symbol source to your audio sink implement a
rate change by 44100 / 45.45.

Let's say we use the simple idea from the StackOverflow answer I've
linked to:

* Use a (float) vector source to produce test input data; some
[0,1,1,0,1, …]

* Use the "repeat" block to repeat that 100×

* Signal Source (let's call it "A"), float, amplitude 0.5, freq=1046,
4545 sampling rate (which really just tells the source to produce a
cosine that has a period of 4545/1046 samples)
* Multiply A with output of Repeat

* Also connect output of repeat to "Add const, const=-1", and the
output of that to "multiply const, const = -1"; that way, you get an
"inverted" repeated bit stream
* Signal Source, float, amplitude 0.5, freq=1277, 4545 sampling rate
(which really just tells the source to produce a cosine that has a
period of 4545/1277 samples)
* multiply with the above inverted thing, let's call the result "B"

* Use the Add block on A & B

* Use a Rational Resampler block, decimation = 4545, interpolation =
44100 

* Finally, connect to both a Qt GUI time sink (make sure to use 44100
as rate of that; it changes nothing, but makes the time axis be scaled
like you want it)
* and to the input of an Audio Sink, set to sampling rate 44100

* Don't turn up the volume on your speakers very much 
* Run the flowgraph

--------------------

In conclusion: Again, you nowhere actually use any software to set a
processing / generation speed. You use your digitization /
analogization (is that a word?) hardware to define what your signal
means, and just use sample rate-converting processing blocks (in this
case: a repetition by 100, and a resampler of rate 44100/4545) to make
the sequences of numbers mean the right thing.

Go "backwards", from the soundcard running at 44.1 kHz, through your
flow graph, and notice what the rate of the input side of each must be
to produce the rate on the output side: I hope it all makes sense then
:)

The resampler needs to consume 4545 samples on its input if its to
produce 44100 on its output (that's why we picked the decimation and
interpolation like we did). The add block needs one sample on each of
its inputs per sample of output it produces, so we're still at 4545.
Same for the Multipliers. The repeat block needs 0.01 input sample per
output sample, so that gives you exactly the data rate at your input
that you wanted.

Best regards,
Marcus

On Thu, 2019-06-20 at 10:43 -0400, Barry Duggan wrote:
> OK, I think I understand all that (it IS a shift in mind-set from my 
> history;), BUT, at some point I need to send the bits at a fixed baud 
> rate (e.g. 45.45). That is what was behind my question #2. Where / how 
> can I do that?
> 
> ---
> Barry Duggan
> 
> 
> On 2019-06-20 09:55, Müller wrote:
> > 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

smime.p7s
Description: S/MIME cryptographic signature