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?
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
fcp.grc