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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment