Simple Digital Mod Problem

Im a total newbie to GNURadio. So my plan was to simply test a digital
modulation path, without channel. Then compare input file and output
file.
The input file was a previously captured random file through GNURadio.
But
the problem is, that the output file is about 8 times bigger and clearly
not
the same!
Any help :)?
http://gnuradio.4.n7.nabble.com/file/n38857/grc.png


View this message in context:
http://gnuradio.4.n7.nabble.com/Simple-Digital-Mod-Problem-tp38857.html
Sent from the GnuRadio mailing list archive at Nabble.com.

The output of the demod is unpacked, that is, only one bit in each
byte is used. Place an unpacked_to_packed block before the sink and
you will have more luck, however you will still get an offset in the
byte boundaries between the input and output.

Ben

Thanks! I see now what you mean, but how can i get rid of these boundary
mistakes? The Result is similar to the original, but the bytes are kind
of
“shifted”. So from a “FF 00” results a “FE 01”…


View this message in context:
http://gnuradio.4.n7.nabble.com/Simple-Digital-Mod-Problem-tp38857p38936.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Take a look at the packet_encoder and packet_decoder blocks. The
encoder adds a header to the packet, so that the decoder can
synchronise to it, and get the correct byte boundary. The
implementation (in the current master branch) is found at
gnuradio/grc/grc_gnuradio/blks2/packet.py.

This is actually what i would like to do later by hand. Isnt there a
possibity how i can fetch the raw bits or bytes directly after
receiving?
Sorry if its a stupid question…


View this message in context:
http://gnuradio.4.n7.nabble.com/Simple-Digital-Mod-Problem-tp38857p38944.html
Sent from the GnuRadio mailing list archive at Nabble.com.

I don’t understand you’re question. What do you mean by fetch the raw
bits or bytes? It seems that you are already doing that fine with
your file outputs.