Speaking as the CEO of The SDR Forum (www.sdrforum.org), I can say that while this definition of SDR is interesting, it is not totally accurate. The 105 member organizations of the SDR Forum, working in cooperation with the Institute of Electrical and Electronic Engineers (IEEE) P1900.1 group, has established a definition of SDR that provides consistency and a clear overview of the technology and its associated benefits.
Simply put Software Defined Radio is defined as :
"Radio in which some or all of the physical layer functions are software defined"
A radio, in this definition, is any kind of device that wirelessly transmits or receives signals in the radio frequency (RF) part of the electromagnetic spectrum to facilitate the transfer of information. In today's world, radios exist in a multitude of items such as cell phones, computers, car door openers, vehicles, and televisions.
Traditional hardware based radio devices limit cross-functionality and can only be modified through physical intervention. This results in higher production costs and minimal flexibility in supporting multiple air interface standards. By contrast, software defined radio technology provides an efficient and comparatively inexpensive solution to this problem, allowing multi-mode, multi-band and/or multi-functional wireless devices that can be enhanced using software upgrades.
SDR defines a collection of hardware and software technologies where some or all of the radio?s operating functions (also referred to as physical layer processing) are implemented through modifiable software or firmware operating on programmable processing technologies. These devices include field programmable gate arrays (FPGA), digital signal processors (DSP), general purpose processors (GPP), programmable System on Chip (SoC) or other application specific programmable processors. Companies producing SDR enabled device technologies, at various levels, include Infineon, Sandbridge, ST Microelectronics, Xilinx, and others, all SDR Forum member companies. The use of these technologies allows new wireless features and capabilities to be added to existing radio systems without requiring new hardware.
There are a host of wireless systems and devices on the market in commercial, civil, and defense sectors that make use of SDR technologies in one form or another are not referred to as SDR. The reason for this is simple: the benefits of SDR, to date, have largely accrued by radio manufacturers, allowing a family of radio ?products? to be implemented using a common platform architectures, allowing new products to be more quickly introduced into the market without having to wait through an ASIC design cycle, and allowing Software to be reused across radio "products", reducing development costs dramatically. As technologies mature over the next few years, our market research has shown that we can expect to see operators and end-users accruing more and more of these benefits as well, allowing true multi-mode/multi-protocol operation.
The definition of SDR in the true sense is that every aspect is "software defined". Without a doubt Imagination has done a good job, but i will not go to the extent of saying that it has embraced the principles of SDR. A closer look at the product website shows that a significant portion of the Ensigma's platform the Signal Conditioning and Error Correction processor is termed as "reconfigurable hardware". By no stretch are these even CPU's,so we should forget calling this product as software defined. I would rather term them as software controlled strictly speaking, which is no different than many other guys in market who use CPU's to control demodulation functions. The only real cpu in the Ensigma platform is the Modulation processor which is capable of doing everything which looks OFDM like with its DVBT,ISDB-T. Again a person who knows about OFDM function can tell you that the core functions are not very different even across standards. I am very sure that if the front end ADC's sampling rate changes the entire Signal conditioning processor (so called) would need a change.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.