|
SDR(Software Defined Radio) |
||
|
Overview
Followings are the topics that I will discuss on this page. These tend to be very casual talks and I will keep adding topics as they pop up in my mind.
What is SDR ? SDR stands for Software Defined Radio. What does it mean ? Theoretically... a radio that is implemented purely in Software ? Does it mean a radio that does not use any hardware at all ? I wish it could be possible. But in reality, it is not possible to remove all the hardware in Radio even in the most advanced SDR now. Then a questions comes .. which part of the Radio would be replaced (implemented) by Software to be labeled as a SDR ?
Let's look into general structure of a Radio Communication Device. It would be illustrated as shown below. As you see, you see pretty complicated hardware structure and relatively small portions of the software at the very end.
< Figure 1 : General Architecture of Radio Transceiver >
The evolution of Radio Communication Device has been done to simply these structure. In one aspect, this effort of simplification has been done on hardware side as described in RF System Introduction page (Type 1 -> Type 2 -> Type 3). And in the other espect, the effort has been done on Software Side trying to replace some of the hardware with a software (basically Digital Signal Processing). Which part of the hardware can be replaced by Software ? The ideal solution that you may want to get would be as follows. Basically this is for replacing almost all the hardware except the antenna and ADC/DAC. This would be the goal for current SDR. You want to remove even those Antenna and ADC/DAC ? Don't dream about this. It is theoretically not possible unless some people came out with a super smart idea.
< Figure 2 : Ideal structure of SDR >
Even though we have such a goal as shown above, it will be tricky to implement this kind of SDR unless you have ADC/DAC with super wide dynamic range and extremely high resolution. In addition, the ADC/DAC sampling rate should be extremely high if RF frequency is very high. With various technical challenges, SDR has been evolved in multiple steps.
The first stage of SDR has been as follows. At this stage, ADC and DAC is done at IF stage and removes the most of hardwares (Downconvert/upconvert for IF to Baseband and various filters) for baseband processing.
< Figure 3 : First Evolution of SDR >
Next stage of evolution would look as shown below. As shown here, ADC and DAC is done directly at the RF stage, but a couple of Amplifiers are still remaining at hardware stage.
< Figure 4 : Second Evolution of SDR >
As of now, you would see SDR in both as in Figure 3 and Figure 4 depending on the application.
It is said that SDR emerged around the end of 1990s([1]).. meaning it is approaching almost 20 years by now (2016). It is supposed to be pretty mature technology by now. However I still see a couple of extreme perception of SDR.
Pro SDR : Now it is the era of software and we have extremely powerful microprocessors anywhere even in personal computer and in mobile phone. We can remove all the hardware except antenna and ADC/DAC if we decided to do.
Anti SDR : SDR guys has said they can do everything with software and they will replace all the hardware from day 1, but even now they are not showing any powerful SDR solution implementing the latest technology as effectively as hardware solution.
Which side am I on ? I am in between them :).
I don't think we can implement every radio systems with SDR. It is not because the concept of SDR is bluffing and never been mature in terms of real technology but because the requirement of radio system has been expanded so fast. However, if you set a reasonable goal for the requirement, SDR can be a really meaningful/feasible solution.
Let me give you some practical examples that might give you more practical understanding of current SDR. Would give me an example of the most advanced Radio Technology ? I think LTE can be a good example. Considering the data throughput (over 100 Mbps) and timing requirement (1 ms TTI), you might think it would be hard to implement this in SDR. It is not true. Trust me, there are already several LTE Network Simulator (from eNB to Core network) purely based on SDR. You may purchase them with low cost for general function testing or even building your own private LTE network. You might see solutions with small hardware + a PC or small hardware with an embedded process fully functioning as a complete LTE Network (Just try google 'LTE SDR', 'LTE Private Network' etc). I heard aready 300 Mbps IP layer throughput has been tried and confirmed working in a commerical LTE SDR and will soon achieve 450 Mbps.
Then can we remove the cellular chipset completely from our Smart phone ? Probably it would be a little tricky considering the fact that we need multiple cellular technology in a mobile phone and the processing power of a mobile phone might not be powerful enough to perform radio protocol in the background and do all such a complicated graphic processing. Even more importantly, you may have to recharge the bettery several times even in an hour if those radio stack is running in SDR.
How about 5G ? Can SDR meet the 5G requirement ? We don't know what the 5G requirement is for now, but it is highly likely that SDR will play an important role especially on network side. Even though eMBB (enhanced Mobile Broadband, super high data rate in layman term) or mission critical latency would be hard to be implemented by SDR, many of other features can more easily and more efficiently done by SDR.
Open Source vs Commercial Product
First of all, I would like to express my sincere appreciation and respect for those who is contributing any open source project. After I struggled for a couple of years trying to understand the details of radio protocol, I came across an open Source project about the field that I was interested in. You might think ... Now I have the full source code and the project provides even hardware information as well. I would have fully functioning SDR system if I buy the hardware and compile the source code and just run it.
However, as I always says... nothings goes as textbook says in engineering... probably same in our life. Once you really try it and you will learn it is start of another big, big problem... (but every problem .. you will learn new things .. I don't have any intention of discouraging you here). You might learn that even software compilation would not go as expected .. and had to spend a lot of time and effort just to compile it. And then you get the hardware, you would learn what the 'hard' life is. You need to do some of assembly job for several components that are delivered seperately. If you are not a hardware people (like me), even opening the shield case and connecting a daughter board and connect some of wires.. this kind of simple things for hardware experts will be like bulding a rocket. And the it will take another long time and effort until you see the small led lit on the hardware... Now let's look into the source code. After spending too long time on struggling with 3GPP specification which looks like an encrypted text to me, I expected that I would be able to decrypt all those secretes right away if I see the source code. But I soon relealized that the source code is also another type of encryption that I need to make a lot of effort to make sense out of it. Again I am not trying to discourage you in any way.. all of every single trial and error would teach you and raise you as an engineer.
As far as I experienced in the industry as an engineer working in companies who is under consistant pressure for commercialization, the typical procedure of product cycle can be described as follows. i) building up core knowledge ii) Initial implementation (Just make it work in very controlled/restricted condition) iii) testing ... testing ... testing ... testing ... iv) fixing..., updating.. updatating ... and make it more reliable/stable v) testing.. testing ... testing ... vi) bug report from outside of development team (mostly from the customer) .. vii) debugging ... fixing ... debugging ... fixing ... viii) testing with another device ...,testing with other settings ... to extend the coverage of the product ix) implemeting new feature added to international specification x) go to step iii) I think step i) and ii) can be done by one or a few genius or dedicated person, but it will be difficult to go through the endless cycle of iii) through x) with a relatively small/limited resource. Especially for those product which requires hardware as part of product (SDR is also fall into this category), it would require many people, team work and budget to survive to repeat these cycle. Purchasing a commericialized product means purchasing the result of these full cycle and more importantly purchasing the commitment to support you (the customer).
If your current goal is just to understand the core knowledge and accumulate the initial experience, I think OpenSource can be a good economic solution. However, if you need to do any mission critical task especially winthin a certain deadline, I would recommend to try with commercialized product. I think getting direct access to technical support provided by the commercial product would also be a strong motivation for the commercial product.
My personal experience of switching back and forth between OpenSource and commercial product is as follows. I am going back to the time when I have no (or almost no) knowledge about the radio protocol.
At this stage, Open Source SDR was not so much help for me since my knowledge level was so low and I couldn't make sense out of the source code and couldn't understand the technical documents (unlike commercialized product provide a lot of beginer level of document, OpenSource document usually requires a certain level of knowledge to understand the document). Then, I was given chance with playing with various commercial product about Radio product, mostly Cellular communication related product. With these product, I learned many things about cellular technology just as if many kids learn how to use joy stick and how a button/stick is associated movements in a Game character. It is completely like blackbox analysis approach. Starting from a given configuration which is proven to be working and change the parameter one by one and see how those changed parameter changes the communication process. With these practice, some of technical documents (e.g, technical specification or product document) started making sense to me. Repeating these practice, accumulating knowledge in the field and reading a lot of documents, I got pretty good understandings on what's going on during the radio communication process. I wanted to know about the every details of the process and I realize that it would be almost impossible to understand all those details without implementing it on your own or look into the source code. However, in most case commercialized product does not disclose their source code (To be honest, at least more than 60 % of those source code would be almost same as OpenSource code and no harm to the intellectual properties of the company, but I haven't seen any company (at least in Radio/Cellular area) to open even a part of the source code). There is where I turned again to OpenSource. The source code and technical document really helps me to broaden and deepen my knowledge.
[1] Software-Defined Radio Using MATLAB & Simulink and the RTL-SDR
YouTube
[1] Software Defined Radio (MIT Student Cable) [2] Radio Hacking: Cars, Hardware, and more! - Samy Kamkar - AppSec California 2016 [3] Hacking the Wireless World with Software Defined Radio - 2.0 [4] Defcon 21 - All Your RFz Are Belong to Me - Hacking the Wireless World with Software Defined Radio [5] What's on the Wireless? Automating RF Signal Identification [6] #HITB2017AMS​ COMMSEC D1 - So You Want To Hack Radios? Matt Knight and Marc Newlin [7] FM Transmitter in GNU Radio with HackRF [8] Software Defined Radio with HackRF - Lesson 1 Welcome [9] Software Defined Radio with HackRF - Lesson 5 HackRF One [10] Software Defined Radio with HackRF - Lesson 8 On-Off Keying [11] Python FM - listening to radio with Python [12] Capture and decode FM radio
|
||
