DC_REG values overwrited after opening the Rx Stream?

mauro · 23 June 2019 20:16

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

IgnasJ · 26 June 2019 10:04

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.

mauro · 27 June 2019 01:53

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?

IgnasJ · 27 June 2019 09:57

The one that resets at stream start is here:

github.com

myriadrf/LimeSuite/blob/master/src/protocols/Streamer.cpp#L609


    fpga->WriteRegister(0x0008, mode | smpl_width);


    const uint16_t channelEnables = (mRxStreams[0].used||mTxStreams[0].used) + 2 * (mRxStreams[1].used||mTxStreams[1].used);
    fpga->WriteRegister(0x0007, channelEnables);


    uint32_t reg9 = fpga->ReadRegister(0x0009);
    const uint32_t addr[] = {0x0009, 0x0009};
    const uint32_t data[] = {reg9 | (5 << 1), reg9 & ~(5 << 1)};
    fpga->StartStreaming();
    fpga->WriteRegisters(addr, data, 2);
    lms->ResetLogicregisters();
}
else if(not needTx and not needRx)
{
    //disable FPGA streaming
    fpga->WriteRegister(0xFFFF, 1 << chipId);
    fpga->StopStreaming();
}


//FPGA should be configured and activated, start needed threads
if(needRx && (!rxThread.joinable()))

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.

mauro · 29 June 2019 19:08

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).

IgnasJ · 1 July 2019 09:22

Channel alignment is done here:

github.com

myriadrf/LimeSuite/blob/master/src/protocols/Streamer.cpp#L565


    terminateRx.store(true, std::memory_order_relaxed);
    rxThread.join();
}


//configure FPGA on first start, or disable FPGA when not streaming
if((needTx || needRx) && (!txThread.joinable()) && (!rxThread.joinable()))
{
    ResizeChannelBuffers();
    fpga->WriteRegister(0xFFFF, 1 << chipId);
    if (mRxStreams[0].used && mRxStreams[1].used)
        AlignRxRF(true);
    //enable FPGA streaming
    fpga->StopStreaming();
    fpga->ResetTimestamp();
    rxLastTimestamp.store(0, std::memory_order_relaxed);
    //Clear device stream buffers
    dataPort->ResetStreamBuffers();


    //enable MIMO mode, 12 bit compressed values
    dataLinkFormat = StreamConfig::FMT_INT12;
    //by default use 12 bit compressed, adjust link format for stream

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

mauro · 1 July 2019 16:22

Why they wont be the same?
Can you explain?

IgnasJ · 2 July 2019 08:53

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.

mauro · 3 July 2019 02:57

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?

mauro · 8 July 2019 22:23

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?

IgnasJ · 9 July 2019 07:10

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