DC_REG values overwrited after opening the Rx Stream?

#1

Hi all,

I am working with a LimeSDR. Using the LimeSuiteAPI I made a program that send a CW by the Tx1 port and receives the signal using both Rx channels (Tx and Rx are connected using a power splitter).

The generation of the Tx signal is done with this settings:
InputSource->TestSignal
TSGMODE->DCSource
I set a value DC_REG and load them to I&Q. After this I start the stream and receive the samples. The problem I am facing is that the values loaded in the DC_REG (I&Q) are overwrite when the stream is opened and the samples are received.

I could verify this behavior in the Lime Suite GUI. I load some .ini file, calibrate the device, START the stream with the FFT viewer (received signal is in range A). I explicitly change DC_REG values (received signal is now in range B). I STOP & START FFT viewer and the level of received signal is change to the value previous to the DC_REG change (range A).

Is this the expected behavior?

How can I set TxTSP I&Q DC_REG values before opening the Rx stream and be sure that those values are not changed ?

Regards
Mauro

#2

Hi,
As it is now, DC_REG values will be reset after stream start. At stream start logic reset is performed to make sure digital chain is in synchronized state. The reset seems to also clear DC_REG values.

I think It could be changed to not reset Tx chain if only Rx stream is started.

#3

Thanks for the answer @IgnasJ!

Correct, I am only starting the Rx stream, the TxTSP DC_REG is reset to some default value when the Rx stream is started.
For my project it would be more simple to avoid such reset.

Can you point the lines of code where such reset is done?
I have install Lime suite by package (I am using Ubuntu). If I want to correct this behavior I will have to remove such packages, modify the source code and compile my own version of the LimeSuite, correct?

#4

The one that resets at stream start is here:

There are some in other places too (after setting sampling rate, setting digital filter, loading ini file), but they probably do not cause you problems.

Also, are you using single channel or two channels? If you are using 2 channels then there is also other channel alignment procedure that changes DC_REG on stream start.

Yes, you will have to remove packages version and compile LimeSuite yourself.

#5

Yes, I am using 2 Rx channels (I need to measure the phase diff between received signals).
I am using the Tx_TSP DC_REG values as a sort fine power adjustment (to avoid saturating the receivers).
Can you point the code for channel alignment that might also reset this registers?

I am still not sure if modifying the API would be the best solution. I would prefer keeping the API as it is provided (from a compatibility point view).

#6

Channel alignment is done here:

Note that phase difference between channel will not always be the same.

#7

Why they wont be the same?
Can you explain?

#8

The phase difference will stay the same throughout the run. But it may change once you change settings or restart streaming. Channel alignment was added in attempt to correct that. However, I can see that it no longer works in current master because “lms->ResetLogicregisters()” (Streamer.cpp#L609) that was added after it reset the state again.

#10

Correct, I have seen this behavior so far.

Correct, restarting the Rx streams sometime (randomly) lead to a different phase in channel A and/or channel B (for the same frequency). Up to now I saw that the phase in one channel could be different in 180° from one measurement to another (many post in the forum refer to this as the 180 phase jump).
Because of this (180° phase jumps) the difference will not always be the same? Or there is another problem?

The channel alignment tries to solve this 180° phase jump problem? Or was it designed to solve another kind of issue with the alignment of the samples?

#11

Hi @IgnasJ

I decided keep the LimeSuite API as it is provided.
In order to solve the DCREG reset issue I just modify the values after the RxStream is started.
I am doing something similar to this:

LMS_StartStream(&rx_streams[j]);
LoadTxTSPDCREGI(value);
LoadTxTSPDCREGQ(value);
LMS_RecvStream(&rx_streams[k], buffers[k], corrupted, &rx_metadata, 1000); //corrupted=2^15
LMS_RecvStream(&rx_streams[k], buffers[k], samples, &rx_metadata, 1000); //samples=2^17
LMS_StopStream(&rx_streams[j]);

I call 2 times the LMS_RecvStream() function. The first call is just to get rid of the samples that are “corrupted” due to the DCREG change. The second second call to LMS_RecvStream() is just to get the samples to be processed by the program.
This is not working as expected, the change of the DCREG value is still present in the second call to LMS_RecvStream() (see attached figure).

I supposed that when the FIFO buffer was read, those samples were immediately deleted from the FIFO buffer. Is my assumption incorrect?

#12

LMS_RecvStream() removes samples from FIFO and puts then into the provided buffer.