My guess is no, the receiver doesn't have its own thread, because I'm not
sure how to tell.
On Fri, Sep 25, 2015 at 11:21 AM, Martin Braun
wrote:
> On 24.09.2015 16:31, lwas...@ostatemail.okstate.edu wrote:
> > Julian and Martin,
> >
> > Typically 2 U's appear then a stream of O's. Ya, I don't
On 24.09.2015 16:31, lwas...@ostatemail.okstate.edu wrote:
> Julian and Martin,
>
> Typically 2 U's appear then a stream of O's. Ya, I don't have any sort
> of correlation block on the receiver side so that is definitely a
> problem. Next week I'll work on implementing a correlation block with a
>
Julian and Martin,
Typically 2 U's appear then a stream of O's. Ya, I don't have any sort of
correlation block on the receiver side so that is definitely a problem. Next
week I'll work on implementing a correlation block with a barker code preamble.
Do you have any suggestions for quick testing
Hi Logan,
The problem is that the USRP does not know where your burst of data starts and
how long it is and therefore it will respond with Us as soon as no new data is
coming in. In order to tell the USRP how long a packet of data is the USRP sink
in GNURadio offers the 'length tag name' proper
On 24.09.2015 08:20, Washbourne, Logan wrote:
> My question is, do I need to treat a burst communication system
> different than a continuous system? My problem is that on each side I am
> getting O's whenever I start the program, I have tried increasing and
> decreasing the sampling rate, and I di
Hello all,
I've been trying to modify the chat app tutorial into a system that can
utilize USRPs and an acknowledgement system. The acknowledgement system
works so far, the RX just sends a pdu back to the TX side saying that it
received the message. I am now trying to implement the USRPs to have a
