Skip to content

GNRC Tutorial Wiki Part 1: Data Types

Jump to bottom
tandersn edited this page Nov 27, 2022 · 4 revisions

Data Types

Data types are very important in GNU Radio Companion, and in the the *-decode projects. This section will give an overview of data types used in GNRC and *-decode. If you want more info, you should look elsewhere for detailed documentation.

Data types signify at least 3 important attributes of numbers used by computers:

  • The the amount of bits used to store them (8, 16, 32, 64 etc. etc.)
  • Whether or not they are signed numbers (unsigned = only positive numbers, signed = positive and negative numbers)
  • Whether they may contain decimal points (no decimal point = only integer numbers, has decimal point = integers and decimals)

GNRC has adopted a convenient convention of associating data types with "colors". You cannot connect blocks of different data types directly (with different color connectors). Data type conversions must be done first, with special conversion blocks that take one data type in, and output the desired data type, these blocks have different input and output "colors":

The data types in the *-decode suite and GNRC have overlap, but are not identical. Following are a list of common data types used and their GNRC name, GNRC block identifying color, associated file name extensions, numerical range, and example of where it might be used (this list is NOT all inclusive, and only contains data types commonly used in processing *-decode files):

Unsigned 8 bit:

  • GNRC name: uchar
  • GNRC color: purple (see note 1 below)
  • Common raw file extensions: .u8 and .r8
  • Numerical range: 0 to 255
  • Commonly used: cx card 8 bit capture
  • Integer only

Signed 8 bit:

  • GNRC name: char
  • GNRC color: purple (see note 1 below)
  • Common raw file extension: .s8
  • Numerical range: -128 to +127
  • Commonly used: FL2K raw input file (fl2k_file2 forked by Vrunk11 can accept more data types)
  • Integer only

Unsigned 16 bit

  • GNRC name: NONE, GNRC does not natively support this data type, but there is a work-around (described later), sometimes referred to as ushort
  • GNRC color: NONE, not natively supported in GNRC (see note 2 below)
  • Common raw file extensions: .u16 and .tbc
  • Numerical range: 0 to 65,536
  • Commonly used: cx card 16 bit capture and .tbc files
  • Integer only

Signed 16 bit

  • GNRC name: short
  • GNRC color: yellow
  • Common raw file extensions: .s16 (also .raw by DdD application, but other programs, like audacity and ffmpeg, do not explicitly make this association)
  • Numerical range: -32,768 to +32,767
  • Commonly used: DdD raw capture
  • Integer only

Float 32 bit

  • GNRC name: float (32 bit is implied, but 64 bit float does exist)
  • GNRC color: orange
  • Common raw file extensions: .rf
  • Numerical range: "it's complicated..." 3.4e+38 to 3.4e+38 (see Note 3 below)
  • Commonly used: inside GNRC for processing, storing SDR file captures
  • Integers and Decimals

Complex Float 32 bit (which uses 2 float 32 items interleaved Note 4)

  • GNRC name: complex (32 bit is implied, but 64 bit float does exist)
  • GNRC color: blue
  • Numerical range: (same as float)
  • Common raw file extensions: .rf (?)
  • Commonly used: inside GNRC for processing, SDR applications
  • Integers and Decimals

Note 1: GNRC uses purple for BOTH uchar and char (usigned 8 bit and signed 8 bit). This can lead to issues if you aren't careful. Some blocks don't care between the 2 and only refer to them both as "byte" (file source, file sink). Some blocks don't support this data type at all, so best to convert to something else first thing.

Note 2: u16 is commonly used in relation to the *-decode project. I have found a way to input u16 files by reading in 2 bytes, multiplying one, and then adding the values. We will get to this below. I also found a way to output u16, however it is so complicated i recommend you just output s16 and if you need u16, convert with sox.

Note 3: In a lot of contexts (like .WAV files) "float" usually represents -1.0000000 to + 1.0000000, and people often get used to that, and always think of float to only include that range. Float (float32) however, can actually have a much bigger range. The range is big enough that it can contain all the values of the aforementioned data types. The nitty gritty details of float data types is outside the scope of this wiki, see: https://en.wikipedia.org/wiki/Single-precision_floating-point_format

Note 4: Complex number are... complicated. Complex numbers are a set of 2 numbers, which in this context, represent 2 different sample points of a signal exactly 90 degrees from each other related to the sample rate. These 2 numbers are often refereed to as IQ (In-phase and Quadrature), but NOT to be confused with the IQ term related to NTSC color. It's a chicken and egg thing, NTSC color is IQ, but IQ is not always NTSC color. Some blocks in GNRC only work with complex numbers (like FM Demod and such). We use a special "hilbert transform" block to generate the second number when we don't have it. The explanation of how all this works, is way way beyond the scope of this page, and i suggest further reading if you are interested. You don't have to completely understand this to work with GNRC though, so maybe save that for later...

Using u16 data types in GNRC

As mentioned before, you CAN use u16 data types in GNRC if you make them yourself. The following set of blocks uses the 2 uchar components of a u16 data type to make the actual value of the u16 number.

It is not imperative that you understand what is going on here, it is just taking advantage how 16 bit numbers are stored in 2 bytes. This method is used for reading 16 bit cx card captures, and for reading .tbc files.

Clone this wiki locally