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
>