Simple Digital Mod Problem

[Hanz]

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 :)?

[Ben Reynwar]

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

On Mon, Jan 7, 2013 at 3:21 AM, Hanz <[hidden email]> wrote:

> 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.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Hanz]

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"..

[Ben Reynwar]

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.

On Fri, Jan 11, 2013 at 8:21 AM, Hanz <[hidden email]> wrote:

> 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.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Hanz]

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..

[Ben Reynwar]

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.



On Fri, Jan 11, 2013 at 12:33 PM, Hanz <[hidden email]> wrote:

> 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.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio