# Data format of samples

**URL:** <https://discourse.myriadrf.org/t/data-format-of-samples/6487>\
**Category:** LimeSDR\
**Created:** [28 August 2020 20:22 UTC](https://discourse.myriadrf.org/t/data-format-of-samples/6487 "2020-08-28T20:22:37Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![kohlsn](https://avatars.discourse-cdn.com/v4/letter/k/eb9ed0/32.png) [@kohlsn](https://discourse.myriadrf.org/u/kohlsn)\
**Post date:** [28 August 2020 20:22 UTC](https://discourse.myriadrf.org/t/data-format-of-samples/6487/1 "2020-08-28T20:22:37Z")

</div>

Using the c++ limesuite library

Since the LimeSDR uses a 12 bit ADC, is there any difference in the amount of information that can be represented between the LMS\_FMT\_I12 and LMS\_FMT\_I16 data type?

I understand that LMS\_FMT\_I12 is used in the hardware with 3 bytes representing 1 IQ sample and the LMS\_FMT\_I16 uses 4 bytes to represent 1 IQ sample as shown [here](https://github.com/myriadrf/LimeSuite/blob/master/docs/StreamProtocol.pdf). So what is the advantage of using LMS\_FMT\_I16 instead of LMS\_FMT\_I12?

> [@\[SOLVED\] Wire format and linkRate](https://discourse.myriadrf.org/t/solved-wire-format-and-linkrate/2048/2):
>
> the hardware works only with samples in I12 and I16 formats, when F32 is selected it still uses I16 as source for transferring, but on PC side values are just recalculated to floating point values.

The F32 outputs normalized values [-1:1] of the LMS\_FMT\_I16 data type. How does the software do this? Is it as simple as taking a sample from the I16 format and dividing it by 0x7fff?

---

<div class="post-metadata">

**Author:** ![andrewback](https://avatars.discourse-cdn.com/v4/letter/a/22d042/32.png) [@andrewback](https://discourse.myriadrf.org/u/andrewback)\
**Post date:** [29 August 2020 08:55 UTC](https://discourse.myriadrf.org/t/data-format-of-samples/6487/2 "2020-08-29T08:55:58Z")

</div>

One for @Zack I think.

---

<div class="post-metadata">

**Author:** ![Gluttton](https://avatars.discourse-cdn.com/v4/letter/g/b38774/32.png) [@Gluttton](https://discourse.myriadrf.org/u/Gluttton)\
**Post date:** [30 August 2020 12:27 UTC](https://discourse.myriadrf.org/t/data-format-of-samples/6487/3 "2020-08-30T12:27:57Z")

</div>

Hello @kohlsn,

> How does the software do this? Is it as simple as taking a sample from the I16 format and dividing it by 0x7fff?

Exactly. You can find more details in the Read/Write functions implementation ([LimeSuite/src/protocols/Streamer.cpp at master · myriadrf/LimeSuite · GitHub](https://github.com/myriadrf/LimeSuite/blob/master/src/protocols/Streamer.cpp#L74)) :

```
if(config.format == StreamConfig::FMT_FLOAT32 && !config.isTx)
{
    //in place conversion
    complex16_t* ptr = (complex16_t*)samples;
    int16_t* samplesShort = (int16_t*)samples;
    float* samplesFloat = (float*)samples;
    popped = fifo->pop_samples(ptr, count, &meta->timestamp, timeout_ms);
    for(int i=2*popped-1; i>=0; --i)
        samplesFloat[i] = (float)samplesShort[i]/32767.0f;
}

```

> So what is the advantage of using LMS\_FMT\_I16 instead of LMS\_FMT\_I12?

Some hints can be found in comments ([LimeSuite/src/protocols/Streamer.h at master · myriadrf/LimeSuite · GitHub](https://github.com/myriadrf/LimeSuite/blob/master/src/protocols/Streamer.h#L61)):

```
Choosing a compressed format can decrease link use
at the expense of additional processing on the PC.

```

> Since the LimeSDR uses a 12 bit ADC, is there any difference in the amount of information that can be represented between the LMS\_FMT\_I12 and LMS\_FMT\_I16 data type?

It’s difficult to say for sure, but according to the comments mentioned above both formats contain the same data and LMS\_FMT\_I16 is just a “16-bit container” for “12-bit values”.

I’m not sure in the last statement, so it would be great to get the correct answer from @Zack.

---

<div class="post-metadata">

**Author:** ![Zack](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/zack/32/89_2.png) [@Zack](https://discourse.myriadrf.org/u/Zack)\
**Post date:** [31 August 2020 12:00 UTC](https://discourse.myriadrf.org/t/data-format-of-samples/6487/4 "2020-08-31T12:00:44Z")

</div>

> [@kohlsn](#):
>
> So what is the advantage of using LMS\_FMT\_I16 instead of LMS\_FMT\_I12?

You can send I and Q sample (12 bits each) using 3 or 4 bytes:

1. When sending using 4 bytes each of I and Q sample is send using 2 bytes, hence 4 bits not used i.e. link (USB/PCIe) throughput waste.
2. When sending using 3 bytes there are all the bits of 3 bytes occupied. Hence no link throughput waste, but there is more processing involved at host side for I and Q samples unscrambling.

---

<div class="post-metadata">

**Author:** ![kohlsn](https://avatars.discourse-cdn.com/v4/letter/k/eb9ed0/32.png) [@kohlsn](https://discourse.myriadrf.org/u/kohlsn)\
**Post date:** [31 August 2020 18:00 UTC](https://discourse.myriadrf.org/t/data-format-of-samples/6487/5 "2020-08-31T18:00:24Z")

</div>

Thank you, that makes a lot of sense.

I did some testing with the data types.

I found that I can normalize the LMS\_FMT\_I16 data type to produce the same result as using the LMS\_FMT\_F32.

However, when I normalize the LMS\_FMT\_I12 data type I get a result of a increased [delay](https://discourse.myriadrf.org/t/synchronizing-the-limesdr-transmitter-and-receive-using-timestamps/6465) between the transmitter and receiver. Is this because of the I and Q unscrambling? Data being truncated? Or some other reason?

The LMS\_FMT\_I16 data type is just the LMS\_FMT\_I12 data type shifted 4 bits so that the least significant 4 bits are 0. If this is the case wouldn’t it make more sense to normalize the LMS\_FMT\_I16 to LMS\_FMT\_F32 by dividing the samples by 32752 (0x7FF0) and not 32767 (0x7FFF)?