Trouble with multiple time sensitive starts of 2x2 MIMO system

[Bjarni]

Greetings

I am working on a masters thesis project using USRPs in a reverberation chamber measuring throughput over the air.

I have a problem when using 2x2 mimo using 4 USRPs connected via 2 MIMO cables when I need to use channel state information at the transmitterside. Since the channel is rapidly changing I need to be able to send one packet, estimate the channel from that packets training sequence, precode the next and transmit. I've estimated that the packet transmission time is around 5ms, computation time is around 5ms but the problem lies in that I can't get less than 120ms as wait time sent into the "niUSRP set time" and "niUSRP configure trigger" VIs or else i'll get the error "Packet had timestamp that was late (or too early)?"

This provides no problem where I don't need the precoding, but when using beamforming algorithms then the precoding is needed. Is there a way to either implement a way for the USRPs to run continously and change the input waveform as they are running OR somehow reduce that wait time ?

I wanted to attach the sub VI in question and its overhead sub VI along with all sub VI's needed for it to run but it is too large 9(MB) so I've added a dropbox link to it here. The problem is in sub_txrxData_SVD.vi which is called by sub_tx_rx_hande.vi which is called by a larger program that does pre & post processing of the packets.

Thanks in advance

Bjarni Þór

[psisterhen]

The wait time is necessary to allow the waveform packets to cross the bus and arrive at the device before the time that the device starts outputting.  The minimum time required will vary and depends on many factors including machine speed and bus speed.

I think your suggestion of running Tx continuously, inserting precoded packets when they are available, and just sending 0s between packets might work.  This depends on your transmission bandwith... is your IQ rate small enough to not overwhelm the bus bandwidth?

[ErikL]

In the attached code we were able to get the round trip latency down to 15-20 ms.  It impliments an ALOHA MAC with TX and RX between 3+ devices.

[Bjarni]

I'm aware of the time needed to send the packet over the bus.

My IQ bandwidth is only 400k so it's far from overwhelming the bandwidth.  I have tried to implement the continous tx/rx soloution using several while loops & queues as I need three components, the previous packet channel state, the precoded packet for transmission and the received packet in order to estimate the channel state.

I run into the problem there that it is crapshoot which of the 3 actions (precode, transmit, estimate) is done first and it tends to hang on the deque element if the que is empty resulting in the code hanging. I start the code with the assumption of unit channel sending a dummy packet to get the "true" state estimate, then it should precode using the until channel, transmit/receive, estimate and then repeat it self.

I have also taken a look at the ALOHA MAC code and used some ideas from there on how to implement this.

[ErikL]

It sounds like a race condition. Queues black until they can dequeue. If it did not block, what is the desired dataflow behavior?

[Bjarni]

It's a race condition indeed.

The desired dataflow is:

1. Precoding of message to be transmitted
2. Transmission & reception of message
3. Channel estimation from received message
4. Precoding next message for transmission
5. etc

My code seems to have a tendency to get stuck in 2. a perpetual loop of transmit/receive where it's just transmitting buffer zeros and receives nothing, I'm working on a way to force it out of 2. and accept a unit channel estimate for next precoding

[ErikL]

When we worked on the Aloha MAC we had to plan for TX and RX to happen at the same time and therefore needed their own loops. We used simple energy detection to detect packets. We also had to consider that the Tx and Rx units are not be synchronized unless an external an external PPS and Ref are shared externally.

Also we wrote the MAC code so that every participant in the network used the same code. This was may not be necessary in your case. It made planning more challenging but made the implementation more scalable. It took some white boarding to map out interaction and timing between devices.