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

[CEL]

Hi Barry,

on my way to bed, so really quick:
On Thu, 2019-06-20 at 17:48 -0400, Barry Duggan wrote:
> Marcus,
> 
> OK, so that works. Now I have more questions!
> 
> 1) Since the vector source has a repeat option, why use the Repeat 
> block? Does it still need a 'vector to stream' function?

The vector source's "repeat" option just says the vector source should
just repeat producing its sequence on the output forever. Without that,
it emits the vector once, and then says "I'm done; shut down this
thing".

The repeat block takes every input sample, and repeats it. 

Illustration: 

Vector source, sequence = A B C D, repeat = True:

A B C D A B C D …

Repeat block, input stream = A B C D, repetitions = 4

A A A A B B B B C C C C D D D D

> 2) What criteria did you use to pick the 4,545 sample rate? If there 
> were no repeat, what would you do? The repeat of 100 seems to go with 
> the sample rate.

I just used the 45.45 bd you said you'd wanted to use and rolled with
it, and the fact that I used a factor of 100 and not say, 101 or 7 was
just because 100 is such a nice number :)

> 3) If I change the frequencies to the US standard 2295 / 2125 Hz, do I 
> need to change the sample rate? It's not quite twice the 2295 frequency.

Yep; but that just means that you for example repeat by 200, and thus
use 9090 as "intermediate" rate, or so. 

As you can guess, one could computationally optimize the hell out of
this, but at these rates, your computer is not even beginning to break
a sweat.

> 4) Looking at the output of the rational resampler, it needs a low-pass 
> filter. How can I add one without messing up the timing?
> 

The Rational Resampler block *should* automatically use a low-pass
filter if your enter nothing in the "Taps" field. Does it not? 
 

> I *really* appreciate all your help on this!

You're welcome :) It's fun to talk about all this once in a while.

Best regards,
Marcus

> 
> ---
> Barry Duggan
> 
> 
> On 2019-06-20 11:10, Müller wrote:
> > 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
> > > > 
> 
> <snip>

smime.p7s
Description: S/MIME cryptographic signature