Hi Haaris,
On 11.12.2015 10:21, Haaris wrote:
> Hi everyone
> Can we set the bit rate of a source e.g random or vector source to a
> specific value?
> If we cannot set it to a specific value then how to even know the bit
> rate of e.g a random source?
We don't. Bit rate has no meaning for these sources!
> I connected a random source to unpacked to packed with 8 bits per chunk
> Which means that the bytes generated will be 0000001 or 00000000.
> Then i connected the output of unpacked to packed to uchar to float
> and connected a scope at the end.
> Whenever I try to read the bit rate from scope it somehow comes out to
> be equal to sampling rate.
GNU Radio doesn't care or even know what the things you put in your
samples are. For GNU Radio, it's just a sequence of things ("items" we
call them, to make clear that we don't even know whether they are
numbers, symbols, samples, bits...) that you exchange between blocks.
So, "sample" is the only relation between GNU Radio and signals. Hence,
a sampled signal doesn't have something like a bandwidth in GNU Radio,
and a random source doesn't have a bit rate -- it just produces random
numbers, one each item.
Take the signal source: It "claims" to have a "frequency" and a
"sample_rate" field, but in reality, this is only used to calculate the
/relative/ frequency of the generated signal, ie. the number of samples
per period. That doesn't have anything to do with real world frequencies
until you give it that meaning. So, if you set the frequency of a signal
source to 1 and the sampling rate to 20, then the generated signal will
have a period of 20 samples. If you set the frequency to 2e6 and the
sampling rate to 40e6, *exactly* the same signal will be generated: A
signal with a period of 20 samples.
The only difference that you can make is if you configure your graphical
sink to act as if your signal was sampled at a given rate. So for
example, take that freq=1/sampling rate=20 signal, and connect it to the
scope plot, setting that scope plot's "sampling rate" setting to 20 --
then, your signal will be displayed as having a period of 1s. But it's
really really just a setting for display, and that's what the display
does: you tell it "assume this signal was sampled at x Hz", and the sink
displays it as if it was actually sampled at that rate.
Especially, it doesn't say anything about how fast the samples are being
processed. If you look at how many samples will go through a simple
signal source->scope display flowgraphs, it will be in
Megasamples/second, and again, that's totally independent of what you
set your signal source or your visualization to. "sample rate" is really
just a /concept/ of how to /interpret/ the numbers.
> This bit rate does not matches the output symbols of a QPSK mod if i
> keep samples/sym=8 and sampling rate of that scope equal to
> samp_rate*8 because i calculated the bitrate to be equal to sampling rate.
> So, what is going on?
> The other question is that what is on the output type of the PSK demod
> or what do we get at the output of psk demod? (i know it should be the
> actual data sent in the PSK mod)
>From the documentation tab in GRC:
> / The input is a complex modulated signal at baseband.//
> // The output is a stream of bytes, each representing a recovered
> bit.//
> // The most significant bit is reported first./
So, you get out bytes (hence the single-byte output type), and a byte is
either 0 or not, representing a received bit. The order is MSB first.
> I have tried almost everyway to write the output of PSK demod on a
> file through file sink but it always ends out to be junk.(Connecting a
> file source and file sink directly writes the file just fine)
> I have tried unpacking and packing bits of the output of PSK demod.
Packing is what you should do, here.
> I have also tried unbuffered on and off of the file sink.(repeat is on
> in the source)
> Can someone please highlight my mistakes.
How does your PSK demod know where to start? How do you account for
random phase?
Timing/phase synchronization as well as start-of-payload detection are
non-optional in a receiver.
Best regards,
Marcus
>
> P.S
> timothee answered the bit rate question but i was not able to make
> sense out of that answer.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
