I can run the programs (Rx first, then Tx) and I receive the file, but slightly smaller than the transmitted file.
The file being transmitted is 2 MB of /dev/urandom and the received file
is
8.192e3 bits smaller than the transmitted file.
Any ideas as to where those bits went? Were they lost during
synchronization?
Thanks.
-William
I can run the programs (Rx first, then Tx) and I receive the file, but slightly smaller than the transmitted file.
The file being transmitted is 2 MB of /dev/urandom and the received file is
8.192e3 bits smaller than the transmitted file.
It may be not flushing to file. Try using a head block with the size
param set to the expected file length and set the flow graph to run to
completion.
-Josh
Any ideas as to where those bits went? Were they lost during
synchronization?
Any ideas as to where those bits went? Were they lost during
synchronization?
its also possible
Hi Josh,
Thanks for the tips; however, I suspect it has also something to do with
how
packet encoder/decoder works.
I ran some tests using a simpler setup without USRP in the loop (.grc
attached)
file source → packet encoder → GMSK modulator → GMSK demodulator →
packet decoder → file sink
When using an input file with size that is an integer multiple of the
“Payload Length” parameter of the packet encoder, the last packet will
be
missing, i.e. if payload length is 1000 bytes then the output file will
be
1000 bytes smaller than the input file. Using vbindiff I could confirm
that
it is indeed the last packet that is missing.
When using an input file with size that is not an integer multiple of
the
payload length of the packet encoder then both the last full packet and
the
reminder bytes will be missing in the output.
When input file size = payload length (only one packet) the output file
will
be empty.
I tried many different payload sizes, pad for USRP on/off, replaced gmsk
with dbpsk, all gave same results. Adding a Head block did not make any
difference either; however, making the “Num Items” smaller than the size
of
the input file resulted in an output file with NumItems-PayloadSize
bytes so
also in this case the last packet was missing.
Maybe there is some end-of-stream signal that stops the flow graph
before
the last packet is decoded.
I ran these tests using v3.3.1git-96-g1fa9a8ea
Alex
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.