Michael Berman-2 wrote:
> The problem does not lie with the bpsk modulator, the problem is in the
> packetizer. The packetizer waits until it gets enough data to completely
> fill up a packet, generally resulting in the loss of the last packet as
> there is not enough data to fill it perfectly.
> There is a modified copy of the packetizer.py that you could use that has
> been set up to handle this specific async digital communication scenario
. If you look at
> .../trunk/src/Data_Path, there is a modified Python file for
> You may also want to look at the dpsk.py file in this directory, as it
> how to set up the top level design to use a message queue for the
> asynchronous sending of packets. The last (useful) file in this director
> the txrx_controller.py, which establishes a custom rudimentary protocol to
> ensure packet retrieval went well, and all information is received
> properly. There is some documentation for this in the Docs folder.
> -Michael Berman
> On Tue, Mar 9, 2010 at 12:03 AM, Fisheep <address@hidden
>> I have some problem about dbpsk and bpsk using benchmark_tx/rx.py with
>> My experiment set up was that the transmitter waits for a time delay (0.5
>> after sending a packet.
>> It means that we transmit data discontinuously.
>> If we using dbpsk modulation, we can successfully receive every packet.
>> But if we removed the differential encoder/decoder (equals to bpsk
>> modulation), we uaually
>> lost some packet (almost half of the data lost).
>> However, when we transmit data continuously,the bpsk modulation seems
>> fine and we can successfully receive every packet.
>> My problem is that what reason causing the bpsk modulation can not
>> successfully receive packet when
>> transmit data discontinuously.
>> Could anyone have any idea about it, please let me know.
>> I am deeply appreciative.
>> Fisheep :)
>> View this message in context:
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>> Discuss-gnuradio mailing list
> Discuss-gnuradio mailing list