mMIMO experiment MEB_multiple frames issue

[sayaz...@gmail.com]

Hi Powder team,

I am currently running an experiment on MEB rooftop mMIMO setup to send some signal (something similar to OFDM but a slightly modified version) from BS antenna array and receiving it at one of the UE (downlink only). To send/receive signal I am using the mimo_driver.m developed by rice team. Things are working fine, I am able to send/receive/decode the signal. 

One problem I am facing is with the number of frames I want to transmit. For e.g. when I am transmitting 5 OFDM frame, at times all 5 frames are received in single try, and at other times each frames are required multiple tries. As an example:

reading stream: (ret:ret=1784, flags=6, timeNs=8590065664), 8590065664, 2, 2
LOW SIGNAL A False, LOW SIGNAL B False, BOTH CHAN? False
triggers = [3], Amplitude = 0.08193548768758774
frame = 2, tries = 3, all_triggred = True, good_signal = True, amp = 0.08193548768758774
n_samp is: 1784  

1. Here it can be seen that frame #2 required 3 tries before the signal was succefully received at UE. I am unable to understand the exact reason of this(tries) from the code itself. Is it because no signal (even noise !) was received by the UE and that is why the frame is resent or something else. This experiment was done with a TX gain = 95 and RX gain = 65. Changing the antenna element or increasing the gain does not seems to solve the issue.

2. I am required to send at least 1000 frames. If each frames requires multiple tries (when no. of tries is unknown)  its taking a long time to complete transmission of 1000 frames. In such case what might be the best way to do this experiment ?

Thank you,

Ayaz

[Oscar Bejarano]

Hi Ayaz,

The matlab framework relies on a hardware correlator to synchronize transmissions between the base station and the UE.
If the UE does not find the sequence, it will not transmit (or receive) when it is supposed to.
Unfortunately, that correlator is somewhat unreliable so we simply attempt multiple consecutive transmissions under the hood (until you get a good frame). That way we minimize the impact on users.
We now have a more reliable version of the correlator but it needs further testing before we can update the image on the SDRs.

A few options:

1) (Dummy option) The simplest may be to just get rid of most of those printouts to make it faster. Not a great solution but it should speed things up.
2) (Better option) The transmission/reception process doesn't take too long. The interface to matlab and the rest of the matlab/python code does.
You can simply hack the driver such that you let it continue triggering transmissions and receptions, then, once you know you have 1000 good frames, you return everything. I'm not sure how well Matlab will handle that many frames so you may want to do fewer at a time. Give it a try.
3) (Best option) The best approach to what you are trying to do is to use the Sounder and replace the generated data with your signal. Of course this is the more complex method and will require more time to implement and test...
4) Btw, although you mention gains don't solve the issue, they certainly make a difference. Keep RX=65 but you may want to try a higher TX gain, let's say between 100 and 105.

I hope this helps,

-Oscar

--
You received this message because you are subscribed to the Google Groups "Powder Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to powder-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/powder-users/6abfa3d4-cab5-4c70-8f8d-b236580023f2n%40googlegroups.com.