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.
2) What determines the rate at which the vector contents are presented
to the output?
3) If one were to add a 'throttle', where would it go? Is it needed
here?
BTW, a minor correction: the second vector is missing a comma after the
last 0.
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