gr-ofdmradar: OFDM Radar in GNU Radio
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 287 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/57083 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2022252 / 287
2
4
6
8
12
17
21
23
31
35
37
41
44
45
46
47
50
62
65
66
67
68
71
73
81
84
85
86
90
92
94
100
102
105
111
114
115
116
117
118
121
122
124
127
131
133
135
137
139
140
141
142
145
149
150
156
164
165
167
169
170
171
172
174
176
178
180
183
184
189
190
192
194
198
205
206
207
208
210
218
220
224
225
229
230
232
235
236
238
239
240
242
243
244
245
246
249
250
253
260
262
264
267
273
274
277
282
283
287
00:00
Electronic meeting systemImplementationEngineering drawing
00:22
System programmingDigital signal processorSoftware-defined radioSoftware development kitInterface (computing)Software engineeringComputer hardwareMobile WebComputer networkInformationPhysical systemProcess (computing)Band matrixGame controllerCommunications protocolGradientImage resolutionRange (statistics)Domain nameSource codeFrequencyComputer-generated imageryShape (magazine)Pulse (signal processing)Parallel portCharge carrierDependent and independent variablesData miningRead-only memorySymbol tableTime domainConvolutionAnalogyRepository (publishing)Symbol tableFrequencySoftware development kitRepresentation (politics)Data miningMereologyLevel (video gaming)SoftwareNoise (electronics)SimulationComputerTransmissionskoeffizientProcess (computing)RectangleSummierbarkeitComplex (psychology)Software-defined radioGraph coloringWaveformMixed realityFehlererkennungQuicksort2 (number)ResultantBit error rateRight angleCentralizer and normalizerSlide ruleBand matrixCodecEndliche ModelltheorieBlock (periodic table)Multiplication signDomain nameComputer hardwareSubsetDirected graphImage resolutionRange (statistics)Cartesian coordinate systemPoint (geometry)Spectrum (functional analysis)Projective planePresentation of a groupComputer animation
08:12
Read-only memorySymbol tableInformationSource codeComputer-generated imageryClique-widthDivision (mathematics)Dependent and independent variablesSimulationCharge carrierBlock (periodic table)Interior (topology)FrequencyPhysical systemTransmitterGraphical user interfaceAnalog-to-digital converterProcess (computing)Random numberFront and back endsMatrix (mathematics)Alphabet (computer science)Domain nameProcess (computing)Block diagramImpulse responseTime domainAlgorithmEstimatorDistanceMultiplication signLengthSymbol tableSampling (statistics)Musical ensembleNavigationDoppler-EffektFourier transformInverse elementPhase transitionEqualiser (mathematics)Data streamDiagram2 (number)HypothesisPhysical systemDomain nameSynchronizationSound effectGraphical user interfaceFilter <Stochastik>MultiplicationInformationRange (statistics)Vector spaceTransmissionskoeffizientSpacetimeDivisorPoint (geometry)DigitizingDependent and independent variablesRandomizationFrequencyCharge carrierType theoryDirection (geometry)State of matterCoefficientResultantSoftware-defined radioOperator (mathematics)Resource allocationEndliche ModelltheorieMereologyNoise (electronics)Food energyWordFast Fourier transformESPRIT <Forschungsprogramm>Different (Kate Ryan album)Division (mathematics)Module (mathematics)Representation (politics)CASE <Informatik>Channel capacityFourier seriesBlock (periodic table)Computer animation
16:01
Matrix (mathematics)Alphabet (computer science)FrequencyDomain nameCartesian coordinate systemData transmissionInsertion lossSample (statistics)Wireless LANDependent and independent variablesConnected spaceFunction (mathematics)Range (statistics)Process (computing)Graphics processing unitGraphical user interfaceSimulationComputer hardwareBlock (periodic table)TransmitterAnalog-to-digital converterFront and back endsRandom numberParameter (computer programming)Physical systemComputer configurationVariable (mathematics)Frame problemElement (mathematics)Electronic visual displayLogical constantBit rateBoom (sailing)Data typeNumbering schemeSymbol tableOperator (mathematics)BootingStreaming mediaGastropod shellPartial derivativeSystem callMixed realityCharge carrierCore dumpForm (programming)Resource allocationCharge carrierInteractive televisionMultiplication signBlock (periodic table)CodeMatrix (mathematics)InformationGraphical user interfaceRange (statistics)Symbol tablePhysical systemWindowGraph (mathematics)DataflowLoop (music)Impulse responseDivision (mathematics)2 (number)FrequencySimilarity (geometry)Computer hardwareRepresentation (politics)Sampling (statistics)Direction (geometry)Function (mathematics)Closed setoutputDependent and independent variablesResultantEndliche ModelltheorieTransmissionskoeffizientEstimatorTransformation (genetics)Order (biology)Buffer solutionParameter (computer programming)BefehlsprozessorBlock diagramSignal processingDoppler-EffektNumbering schemeTime domainEntire functionKey (cryptography)Slide ruleSingle-precision floating-point formatSummierbarkeitLengthField (computer science)Type theoryShape (magazine)Computer animation
23:51
Function (mathematics)Variable (mathematics)Bit rateGraphical user interfaceOperator (mathematics)Digital filterStreaming mediaDoppler-EffektRange (statistics)Cartesian coordinate systemPhysical systemParameter (computer programming)GUI widgetBitSensitivity analysisTouchscreenComputer animation
24:34
Sample (statistics)SimulationStreaming mediaInformationImplementationComputer hardwareEvent horizonSoftware-defined radiooutputPhysical systemIntegrated development environmentVideo trackingSoftware development kitTemplate (C++)Computer hardwareSampling (statistics)Interactive televisionProjective planeComputing platformBlock (periodic table)Planning2 (number)SynchronizationFluid staticsSoftware-defined radioWordStreaming mediaComputer animation
26:20
VideoconferencingBand matrixAbsolute valueConnectivity (graph theory)Software-defined radioNoise (electronics)PlotterPhysical systemTransmissionskoeffizientProcess (computing)System identificationFrequencyDirection (geometry)Multiplication signComputer hardwareSynchronizationInformation2 (number)Computer animation
29:01
Computer animation
Transcript: English(auto-generated)
00:13
Hi, and welcome to this small introduction to OFDM radar and my implementation GR-OFDM radar.
00:22
I'm David, I'm currently an electrical engineering undergrad at KIT in Germany, and my interests evolve around everything software engineering, RF, radar, software-defined radio stuff. I'm also an intern at analog devices currently, which is also where I built this GR-OFDM radar.
00:46
So this was an internship project of mine at analog devices. If you look at the repository URL, this is also where this repository is located. Now, what are we going to talk about today?
01:01
I'd like to give you a small introduction and then go back and talk about OFDM radar, because everything in OFDM radar is based on the principles of OFDM. So you really have to understand what's going on with OFDM. Because once you've understood OFDM, understanding the basics of OFDM radar is really just a small step.
01:24
Then we are going to take a look at GR-OFDM radar, a small simulation example, and finally just a quick outlook at how you would integrate with the GR-OFDM radar with actual SDR hardware. Now, before I get started, I'd like to point out that everything in this presentation
01:43
and much more you can read about in Martin Braun's dissertation from 2014. So this is nothing novel. OFDM radar came about from the question of how can we share a spectrum in automotive applications where we have a radar and we maybe even want to communicate between devices, between cars and base stations.
02:07
So the more applications you have in the wireless spectrum, the more wireless spectrum you need. But if you can combine two applications into a single waveform, you can really save some bandwidth, which is what OFDM radar is doing.
02:21
Generally, there are a couple reasons why you would want to use OFDM radar, but there are also quite a few disadvantages. So, of course, there's the spectrum sharing point. And you also get some benefits like a fairly high processing gain because you're working with large bandwidths. But that also means that you need communications-grade RF electronics to amplify these signals.
02:46
You are dealing with OFDM signals, which tend to have very high peak average power ratios. So you can't just use some amplifier you would use for your FMCW radar with very narrow waveforms. But you need some quite expensive stuff.
03:01
And getting high powers out of an OFDM radar system might be difficult. The large disadvantage is really the large instantaneous bandwidth required to get acceptable range resolution. But we'll talk about that later. Now, for a small or not so small OFDM recap, let's talk about what OFDM even is.
03:24
So first off, I would like to thank my professors at KIT for letting me use their fancy pictures. I really wouldn't have had time to create all of those myself. But that's also why you may see some German axes.
03:40
So this slide really encapsulates the central idea of OFDM. You have n time domain symbols and you lay those on their sides and stretch them in the time domain and make them narrower in the frequency domain. So on the left, you can see one symbol taking up one nth of the whole time block.
04:02
But it's also taking up the full bandwidth. On the right, you see the bandwidth that's been taken up by one symbol being reduced by n. But the time it's using is multiplied by n. So we have no immediate gain. But it's much nicer to work with when we have multipathic channels, which I'll talk about in a second.
04:25
So we construct these signals by just taking time domain symbols. These may just be complex IQ symbols. Here we are just using BPSK. It doesn't really matter that they're complex.
04:43
But if you see a signal here, it's usually complex. Then we take that symbol, apply just the most basic pull shape, a rectangle. Then modulate those up to a frequency, f0, f1, and so on. Sum them all up and then we get our OFDM waveform.
05:03
And we don't just take any frequencies. We take a delta f that's defined by the amount of symbols we are adding together. And if you do it correctly, you will end up with sinks in the frequency domain. Sinks are really not something you want in the frequency domain because they're very wide.
05:23
But if you sum up a lot of sinks, you get something that's actually fairly steep. So if we sum up all those things you just saw, we get the blue signal over here, which is really almost the perfect rectangle. For comparison, if you were to just use a single rectangle as your pull shape, you would get this orange line over here.
05:48
Let's just say it's bad and it's not going to get much better if you go further to the left or right. So I have yet to talk about why OFDM is so useful. And for that, let's introduce some channel models.
06:03
In wireless communication, especially indoors, we have to assume there are multiple paths from your receiver to its transmitter. And we refer to this phenomenon as multipath channels. And these multipath channels will in essence apply some sort of convolution to your time domain signal.
06:24
Or if you look at it in the frequency domain, you may have seen this construct before as part of a FER filter. It will filter out some of the frequencies of your signal, and that's really undesirable. So if you take a look at this next slide, here you can see the result of such a convolution.
06:43
We have our original frequency domain symbols. There's no OFDM going on right now. And if you take a look at those echoes, basically, you would have to add those together and then we get some mix of the colors. It will be really hard to decipher which symbol was originally there.
07:03
We have those symbols flipped to their sides, and if we add those together, we just add a symbol to itself. We can still lose that symbol, but we won't disturb the other symbols that have good reception. So to the left, you can see the frequency domain representation of our channel. And we might use this magenta symbol, but we still have all those other symbols.
07:24
And you can use forward error correction of our methods to get our bit error rate to a level that's still acceptable. If you have one part of your frequency domain that's bad in such a time domain system,
07:41
this part, if equalized, might introduce a lot of noise that could destroy your entire symbol. Where here, you only lose a sub-carrier or two. Now there's still one thing left we have to talk about, the cyclic prefix. We need to append a cyclic prefix in front of our time domain representation of the M symbol
08:04
to make the convolution that our channel is applying to our transmit symbols cyclic. What exactly that means, I'm not going to go into right now, but really, it needs to be larger. The cyclic prefix needs to be larger than the impulse response of your channel.
08:24
The impulse response of your channel is determined by the length of the impulse response of your channel is determined by the largest distance of your target. So the first target and the last target, the distance between the two determines the length of your impulse response.
08:43
And the cyclic prefix needs to be larger. So this is something you need to take into account when designing your system later on. This is how you generate the cyclic prefix. As you can see, we really just take the last symbols out of the inverse Fourier transform and put them in front of our symbol. This is going to add a couple of extra samples which are redundant and are going to reduce the capacity of your link,
09:08
but they really make this system possible, so we can't work without them. Let's talk about channel estimation. As I alluded to earlier, we can use OFDM to make our channels flat enough
09:23
that we can just apply a single coefficient to correct the influence of the channel. And this is what I'm trying to show here. So a typical channel model without noise might be that our receive symbol is just the transmit symbol convoluted with some channel impulse response h of n.
09:45
And if you transfer this in the frequency domain, then the r is also s times h, so we are no longer talking about the convolution, but just the multiplication between the vectors.
10:02
And we can undo multiplication by just dividing. This isn't always going to work, so the transmit vector is going to have some zero symbols. We can't divide through those, but we can just say the result of dividing through zero in this case is zero. Then we get our channel response or channel state information in the frequency domain, which can also just be transformed back into a time domain.
10:33
A couple of words on carrier allocation. So if you were to just fill every single symbol in your OFDM system with data, so this would be every carrier you can see here,
10:46
you wouldn't really be able to use that signal because digital systems need some space at the edges to filter your signal. And the more space you use and the less space there is at the edges, the sharper and longer your filters need to be.
11:02
And at some point it becomes unrealistic to compute that filter response and you will get aliasing and other nasty stuff. So usually we just allocate like four-fifths of our carriers. In this case, I was a bit conservative and used three-fourths. Leave some reasonable amount of space at the edges or you may get weird effects.
11:26
Finally, this is an almost complete system diagram, a diagram of an OFDM system. There isn't any time or frequency synchronization here. We just have the effects of a multipath channel, but that's also not a very useful block diagram for our case,
11:45
because we are building a radar and the receiver and transmitter are one, so we don't need time or frequency synchronization. So, yeah, you can see we just have some data stream over here. We parallelize that data stream, run it through an inverse Fourier transform,
12:01
re-serialize it, add the cyclic prefix, as you saw earlier, then send it out onto our channel. It gets convolved with some channel impulse response. We get it back, we remove the cyclic prefix, run the FFT. There's actually an equalization step missing here and then we get our symbols back.
12:21
Maybe with some phase rotation, but pretty much that's it. Now, OFDM radar built on these ideas from OFDM and channel estimation. And with OFDM radar, we really just perform multiple channel estimations
12:41
and each channel estimation gives us a range diagram so we can tell how far away we have targets. If you do that multiple times, you can even tell information about the speed at which these targets are moving, or rather the Doppler shifts off those responses.
13:01
The interesting thing with OFDM radar is we are the transmitter and receiver in one, so we know what we sent out and estimating the channel becomes really easy because all symbols are pilot symbols. And, yeah, again, if you want to learn more about the specifics, I recommend just checking out Martin's PhD thesis.
13:20
In my case, I just implemented a periodogram-based receiver. It's not too accurate, but it's a very generic receiver algorithm. You could also use other frequency estimation algorithms like music and Esprit to estimate positions more accurately, but then you make assumptions like
13:42
I only have one, two or so on targets and that's not too flexible. Now, this is a block diagram of an OFDM radar system. It looks pretty similar to our OFDM radar system block diagram, OFDM block diagram I just showed you, but it's a bit different.
14:01
So we feed random data into a modulator that's the same. Then we perform inverse Fourier transformation. We get our time-domain signal, insert the cyclic prefix and transmit that signal out into a multipath channel. We receive that signal back, remove the cyclic prefix, perform the Fourier transformation,
14:20
but then we take the signal that we sent out and the signal that we got back in the channel estimator. The channel estimator just performs a division in the frequency domain and then what you get back is a frequency domain representation of your channel. And you don't just get a single response, but we do this multiple times,
14:44
as you will see in a second, and we can then perform some more operations to make it visually nicer to look at, perform some visual oversampling, take the energy, crop the results and so on. So in general, I would separate those, the block diagram into four parts.
15:04
We have our RF front end, which every SDR has. We have a transmitter that's responsible for generating the data, generating the symbols and inserting the cyclic prefix. We have the receiver. It takes the resulting signal, performs similar processing as a transmitter,
15:25
but in reverse, and then estimates the channel response. Then we have the graphical user interface that does the visual oversampling, energy plotting and so on. This is also how GR OFDM radar is organized, but we'll get to that in a second.
15:44
So for OFDM radar, the transmit process looks something like this. We take N times M random BPSK symbols or some other modulation type. N, because our FFT length in the length direction is N
16:00
and we just want M OFDM symbols. So we are not just sending one symbol, one single OFDM symbol out into the air, but we do it M times. So we get an entire matrix of OFDM symbols. And we are going to use this matrix in the following slides to describe the transformation process.
16:23
The second step in the transmitter is then to perform the inverse fast Fourier transformation in the column direction, where our tiny main symbols then appear. We just add some of the last symbols at the top to insert the cyclic prefix.
16:42
Then we have our transmit signal. We just need to read it out of the matrix in this order. And we really didn't have to use a matrix in the transmitter, but it makes things easier in the receiver when we work with the receive symbols. Then things pass through the multipath channel, which can be described as our symbols X being convolved with the channel input response H,
17:09
and we add some noise, some AWGN. These resulting samples can then be collected into a receive matrix. This receive matrix is also organized like our transmit matrix.
17:20
So the first sample is this one. Then we go column wise, fill this column up and go to the next column and so on. We still have a cyclic prefix in here, so we are just going to delete those samples. They are not too interesting. They're very redundant. And the resulting matrix we are going to re-index, so we just have 0 to N minus 1 again.
17:46
The receive matrix we just got can also be described mathematically as our transmit samples. Just multiply it with the channel matrix plus the free transform of some noise.
18:00
And this channel matrix is what we're after. So we have measured our receive matrix, we know the transmit matrix, and we can ignore this noise. And that gets us an estimation of our channel matrix if we just take the receive samples and divide it by our transmit samples.
18:20
So this, as I said before, there are going to be some zeros here, so we can't just divide correctly. We are going to say, in this case, we set the result of the division by 0 to 0, so it doesn't influence the rest of the signal. Then we can take that frequency representation of our channel matrix, perform a free transform in the symbol direction.
18:47
So Doppler information. And then we perform an inverse free transform, so we get the time domain representation of the impulse response. The resulting matrix is a Doppler range matrix, which is pretty much what you're used to from FMCW radars and similar radars.
19:10
Finally, let's talk about GR-of-DM radar. GR-of-DM radar obviously just implements those signal processing components, which are required by GR-of-DM radar systems.
19:23
If you take a look at this block diagram again, we have a transmitter, a receiver, and a GUI block. They each perform roughly these functions, and we will see how you can use those in a second. By default, GR-of-DM radar can only work with simulations.
19:43
So there is no hardware-specific code in GR-of-DM radar. There is no IIO or otherwise device-specific interaction there. So if you want to use this module, you will have to do some work to integrate it with other SDRs. These are the three blocks.
20:00
As you may expect, we have an-of-DM radar transmitter, receiver, and GUI block, and there is a system parameters block, which has all the shared information that both the transmitter and receiver and even GUI are going to need to calculate or to work with the signals correctly. Finally, let's take a look at an example flow graph that ships with GR-of-DM radar.
20:23
What you see here are just three main blocks of GR-of-DM radar. So our radar transmitter, our radar receiver, and radar GUI in a channel model that simulates some Doppler shift and in total four targets.
20:40
This flow graph is just used from a simulation, so it's a closed loop and doesn't interact with any hardware. Let's begin taking a look at the radar systems parameters. Here we define all the parameters which control the way the OFDM system is constructed. So we specify the amount of carriers we use, how many symbols the OFDM system should generate, how many symbols and carriers are used in the GUI.
21:10
So for oversampling purposes, as you can see on the carrier side, we are going to perform four times oversampling and on the symbol side, we're going to perform eight times oversampling.
21:21
Then we specify a cyclic prefix length, which determines the delay spread that our system can handle. These parameters determine the shape of the carrier allocation. Finally, the window type setting and modulation scheme can probably just be left as they are.
21:41
The window type, everything that's slightly conservative is going to be okay. You don't want to use a rectangle, but yeah, a Hamman window or, well, the other known windows are probably going to be fine. These OFDM radar system parameters are then just read out from all the other three blocks.
22:02
So we refer to these by the ID that's specified in the OFDM systems parameters block. This works like a variable block. Just specify a name for these parameters and then pass on that name onto the transmitter. The length tag field you may see in some of these blocks is related
22:23
to the hardware integration, but it's technically not necessary or used in the simulation. All right, so our transmitter generates our transmit samples. These are then just scaled and throttled because we are in a simulation, we don't want to fully use our CPU.
22:43
And then we apply a channel model. This channel model is built by using a long fur filter, a long impulse response that just has two non-zero tabs, so targets. You can see here one fairly strong tab and one even stronger tab with a bunch of zeros in between.
23:05
And then we also apply a Doppler shift of 30 kilohertz, which is actually quite large. Then we have a second channel in parallel that just applies a very slight Doppler shift of 10 hertz and has another two tabs over here and over here.
23:23
Finally, we add some noise, sum all of those together and feed them into the radar receiver. Radar receiver does all the receiver side processing, also takes parameters, the system parameters, takes length tag keys and a buffer size, but that's also not too important.
23:43
The output is then also just scaled and fed into the GUI. So let's run this flow graph. And what you can see is a Qt GUI widget opening up on the right. The axes are range on the vertical axis and Doppler shift on the horizontal axis, where zero Doppler shift is in the middle of the screen.
24:06
So I'm going to zoom in a bit. What you see are our four targets, one, two, three, and four. Two stronger targets, two weaker targets, to have a Doppler shift of 30 kilohertz, to have a Doppler shift of pretty much zero.
24:24
The system isn't designed for very strong Doppler sensitivity in this case, so you're not going to detect a person moving with these parameters. And that's pretty much it. Just a couple of words on hardware interaction.
24:41
The way you interact, integrate this system, GRO of the M-RADER, with hardware is that GRO of the M-RADER emits tagged streams and can work with tagged streams. So we take the sample stream, which is, in theory, continuous in radio. We add some borders or packetize those samples by just adding some stream tags.
25:04
So we say, at this sample, our packet should start, and it's going to contain 10 samples. And the next packet starts over here. And this way, our hardware can know when the packet starts, and the receiver blocks in radio can know when the packet starts.
25:26
If you want to learn more about the synchronization problem, I will also refer you to my last talk at GRCon, or the Analog Devices Wiki article on GR of the M-RADER. Some plans for this project.
25:41
I want to add calibration, custom data input, because the interesting thing about the OFDM radar is, of course, that you can also transmit data using these OFDM radar waveforms. Also interesting would be target tracking, removing static returns, and future SDR support, because currently the only hardware support I've implemented is for a high-end system, high-end platform that really not many people are going to have access to.
26:04
So it's not easy to demonstrate. Finally, thank you to all the people who've made this project possible, and I will be available for questions in a second.
26:40
All right. We're live. Hello, David. Hello, everyone else. Nice little talk. I really enjoy this kind of stuff. Okay, so we don't have a whole lot of questions. I'm hoping that more will pop up. We do have one about, do we need any kind of special hardware?
27:04
Yeah, and I guess this was for this year. Yeah, absolutely. Do you need special hardware or antenna setup to avoid the strong leakage component between TX and RX? David, what do you say? Yes, we always want to reduce the leakage between RX and TX, and there are, of course, many approaches you can take, increasing the directivity of your antennas is one approach.
27:26
You can also try to improve the receiver coupling inside of your SDR if you have access to, if you actually build the SDR yourself, but that's not something I did. I guess the typical approach is applied. The less coupling you have, the better your signal is going to be.
27:48
So, I mean, you will always have some coupling, though, if you have co-located transmitter receiver with time and frequency synchronization. So, what do you do? I mean, you're going to have a strong direct component always in your processing. How do you handle that?
28:07
One approach I tried using was to de-authorize the system for that direct component. So, the direct component basically is distributed into the noise of the system. That's going to raise your noise floor, but in some cases, that's acceptable.
28:23
Other than that, you can just try to ignore that direct component in your receiver plot. I think that's what you have to do, right? Anyway, there's another question from Jean-Michel, the benefit of OFDM over noise radar. And he goes on to say, since I'm not sure you are using the cyclic prefix for fine frequency offset identification.
28:48
Oh, can you transfer information using noise radar? But the concepts are similar. Yeah, I think that's the answer. We have two more seconds. I'm going to say bye and we'll see each other.