This is the
talk page for discussing improvements to the
Software-defined radio article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
The link for SDR Forum Software Defined Radio Design Process and Tools Work Group Wiki was removed. This was a valuable link to a collaborative forum for the SDR community. I do not see this as spam. It is a place to discuss how to design and implement SDR's. How do we get it added back in? AndrewDauman 22:02, 19 June 2007 (UTC)AndrewDauman
Can we whittle down the list of external links. It would be better to cite some of these as references at specific points in the article, while removing the rest. Jehochman ( Talk/ Contrib) 16:55, 20 December 2006 (UTC)
Can I add a Seminar Paper Presented On SDR?
Virtual11234
03:55, 5 March 2007 (UTC)
The title of Mitola's paper seems to be wrong. It is: "Software radios - survey, critical evaluation and future directions". 2008-11-18
It appears that there are three pages for Software Defined Radio. http://en.wikipedia.org/wiki/Software_radio http://en.wikipedia.org/wiki/Software-defined_radio http://en.wikipedia.org/wiki/Software_defined_radio Even though it appears as though they somehow sync-up, I suggest one be maintained and the other two deleted Jennifersteinberg 20:31, 4 June 2007 (UTC)
Current (2003) digital electronics is to slow to process signals from 10kHz to 2.4GHz? Might be a bit outdated. In 2007, I think we're either there or getting there, and while we cannot receive the entire radio spectrum, projects such as HPSDR are developing hardware (the mercury board) that can directly sample the radio spectrum from 0-65MHz. - Ryan 19:26, 15 June 2007 (UTC)
from the intro: SDR [uses] … the soundcard of a general purpose computer (PC), or a reconfigurable home-made piece of digital electronics. But, the military examples given don't sound like either 'a soundcard' or 'home-made digital electronics'. Should it instead say that the processing is done in a type of computer hardware known as a DSP such as what is found in soundcards? 「 ѕʀʟ· ✎」 06:21, 24 September 2007 (UTC)
In the second paragraph: "An SDR performs significant amounts of signal processing with the soundcard of a general purpose computer (PC)..." Why soundcard? In my opinion soundcard equals to audio card. It's kind of confusing here. —Preceding unsigned comment added by 202.40.139.171 ( talk) 08:06, 4 October 2007 (UTC)
It seems that digital oscilloscopes and function-genertors are bit similar to sdr. any comments? 193.167.107.251 ( talk) 19:25, 28 January 2008 (UTC) <---- This assertion is too vague to respond to.
There are several technical inaccuracies in the section on practical receivers. The statement that digital electronics are too slow to receive signals over 40 MHz is incorrect. Remember that the Nyquist Theorem states that the sampling rate must be at least twice the bandwidth of the signal. This means that, in theory, we can sample signals anywhere in the spectrum (with some limitations depending on where the signal is located in relation to the sampling frequency). The limiting factor in actual radios is a measure called the aperture jitter, which quantifies the ability of the ADC to sample at a precise interval (assuming a jitter-free sampling clock, of course). If you are interested more in the subject a google of "undersampling" turns up several excellent references.
The statements on recovering the phase and bit timing are also incorrect. The reason we need to recover phase and bit information is that the transmitter and receiver clocks are not in sync with each other. By recovering this information we will be able to integrate over the entire bit and thus receive the most power and improve the accuracy of the entire radio.
As far as authority goes, I am an electrical engineer who designs digital radios for a living. Roddefig ( talk) 07:06, 23 May 2008 (UTC)
Can someone define radio protocol, as used several times in the article? -- Abdull ( talk) 12:49, 24 August 2008 (UTC)
The part "Receivers" is copied from NXP itself.
There are more companies claiming to have a chip implementation of SDR for a handset soc.
from google
217.140.96.21 (
talk)
07:51, 3 April 2009 (UTC)
In the section "SPEAKeasy phase II", at the end, it is claimed that "The time to reprogram these [FPGAs] is an issue limiting application of the radio." This is misleading. The time to write a program for an FPGA is significant; the time to download a stored FPGA program is around 20 milliseconds. This means an SDR could change transmission protocols and frequencies in one fiftieth of a second, probably not an intolerable interruption for that task. I am speaking from my experience with Gigaoperations, the maker of the FPGA computing platform chosen by Xilinx in the 1990s. I imagine with much bigger, but faster, FPGAS today, download times are similar. Rhodesh ( talk) 22:43, 10 August 2010 (UTC)
It's half past 2011 at the moment and there are lots of citations. The box should be deleted immediately. It's pure gnome shit.
Because of his many publications on the subject, Joseph Mitola III is sometimes called " the father of the software radio." Joe worked, off and on, at E-Systems. In 1984 the phrase "software radio" was defined by members of a team of E-Systems Garland Division employees to describe a large baseband receiver they designed and built. I was a member of that team. Joe was not. We never saw him around and as far as I know he wasn't even cleared to enter the room. He had nothing whatsoever to do with development of the 1984 E-Systems software radio. In the years since then it has annoyed some of us whenever Joe claims he later coined the term software radio (for instance here).
By the way "software defined radio" kind of sucks since it could (and sometimes does) just mean using a GUI to set the knobs, so to speak, on an analog receiver. — Preceding unsigned comment added by 24.251.186.204 ( talk) 18:22, 29 August 2011 (UTC)
Today I note somebody (could it have been Joe? ;-) has massively and strangely rewritten the History section. Joe, like you, Midas had nothing to do with the '84 E-Systems radio. We necessarily wrote our own software for all that parallel processing. Garland never used Midas and I don't think we even had it available. When we saw it used at other facilities we considered it awkward, inflexible and, frankly, a little weird. We didn't need no stinking audit trails. — Preceding unsigned comment added by 24.251.169.182 ( talk) 14:04, 10 February 2013 (UTC)
Joe, are you saying that a software transceiver is a software radio but a software receiver is not? That would be silly. You wouldn't argue that a hardware receiver isn't a radio. Would you?
The '84 E-Systems Garland Space Systems (hereafter ESY) radio was a surprise to the customer and the relevant community. TTBOMK, ESY at that time was not involved in data analysis. ESY was strictly a system integrator, receiving boxes, designing interfaces and hooking them together. Assemble it, smoke test it, ship it --- that sort of thing. As such, ESY had no need of the Midas analysis software and AFAIK didn't have it.
Now as is well known, the government likes to keep a stable of vendors on call and ready to respond to RFPs. To keep those vendors sweet, projects sometimes seem to be assigned sort of round robin rather than strictly on the merits of the proposals. Anyway, on one particular project, we, ESY, proposed what we called the software radio, which was a great pile of array processors working on the shared memory of an Aptec box, running our unique algorithms effected as data flow programming. This was a front-to-back production engine which necessarily embodied some functions previously performed elsewhere. Tape recordings in, paper out.
Turned out the customer loved the proposal but apparently it wasn't our turn. So somebody else got that contract but the customer gave ESY a special contract to build the radio anyway. And the rest --- say it with me --- was history. My name is John McKown and I approved this message.
The definition of SDR used in this article is basically that used by black box consumers in the amateur radio market. The professional definition of SDR would actually cover nearly all modern, commercially produced, HF amateur radio equipment, and an increasing amount of VHF and UHF equipment.
An SDR is a radio that uses software for back end signal processing, what people are really referring to here are not SDRs, because they actually do not run any software, but rather RF and IF front ends, which can be combined with the A/D converter in a PC sound card, and a general purpose computer, to produce a complete system which is a software defined radio. The definition used here refers to essentially purely analogue devices (although some integrate the A/D converter).
As used here, it is either a marketing term for a specific sub-market, or simply a misunderstanding of the terminology in that market.
-- David Woolley ( talk) 12:41, 22 January 2012 (UTC)
I propose that Software GNSS Receiver be merged into Software-defined radio. As an alternative we could just delete Software GNSS Receiver which is more about the technology of hardware vs software radios, than it is about something specific to GPS or GNSS. ★NealMcB★ ( talk) 20:16, 24 April 2012 (UTC)
I propose to branch the ham radio SDR software to a new article. Furthermore it would be helpful to include a list of the software available on Linux, OSX, Windows as entry points for the interested reader. A list like the revision control software overview would be great. :) 2A4Fh56OSA ( talk) 09:21, 29 September 2012 (UTC)
Does anybody really consider DSP operations to a baseband signal to be SDR? I would expect that a SDR should be able to encode or decode an AM, FM, or QAM signal by changing the software. If the input to a DSP is via a sound card, then how can the IF frequencies of 455 KHz on AM broadcast and 10.7 MHz on FM broadcast be captured? Does one mix down to a 20 KHz IF? Is it really practical to generate a 20 KHz IF that a sound card could digitize? And could any useful info be extracted from that low, low IF?
I suspect anything that uses the A/D on a sound card is merely a fancy tone control for a baseband signal. That stuff belongs in Audio filter. RastaKins ( talk) 21:49, 26 October 2013 (UTC)
Seems to me that the definition of SDR excludes the use of programmable hardware (FPGAs). Maybe this is an accident due to the history of the path leading to current technology. The important distinction should be doing radio operations, such as mixers and filters, in the programmable digital domain, not software vs. hardware. Under the ideal assumptions, you should be able to connect an ADC to an FPGA, and demodulate most radio signals up to hundreds of megahertz, with all the SDR advantages but no software. (In actual implementations, you probably need some filters, though.) Why the restriction to software? Gah4 ( talk) 19:38, 14 September 2015 (UTC)
I come back to this article every few months, and lately it seems like there is more and more marketing copy in the text. A lot of it is fairly conspicuous and lacks references (or when references are provided, they are to product / company pages).
Some examples:
Beginning of the History Section:
Basically the entirety of the "Current Usage - Military - USA" section. Here's a portion:
The program is providing a flexible new approach to meet diverse soldier communications needs through software programmable radio technology. All functionality and expandability is built upon the SCA.
“SDRs flexibility results in expensive complexity, inability to optimize, slower ability to apply the latest technology, and rarely a tactical user need (since all users must pick and stay with the one, same radio if they're to communicate).” — Preceding unsigned comment added by 2600:6C64:507F:FFF2:D859:C05A:8AE0:1746 ( talk) 21:11, 7 March 2021 (UTC)
The later "Amateur and home use" section also has a lot of stuff like this, where it calls out specific examples of products from SDR vendors, which is a very large market
I'd like to point out that I actually run the GNU Radio project, also listed in this section, and I think the way it is used here is poor form for a Wikipedia page.
The long & short of it is that I think this page needs significant clean-up, but perhaps I'm alone in that opinion.
Also, tangentially, why this article is under the Multiplexing category on Wikipedia is rather confusing to me. — Preceding unsigned comment added by Bhilburn ( talk • contribs) 22:54, 6 November 2017 (UTC)
The article says: Real analog-to-digital converters lack the dynamic range to pick up sub-microvolt, nanowatt-power radio signals. Therefore, a low-noise amplifier must precede the conversion step and this device introduces its own problems. For example, if spurious signals are present (which is typical), these compete with the desired signals within the amplifier's dynamic range. They may introduce distortion in the desired signals, or may block them completely. It seems to me that this is mixing dynamic range and signal level. To start, microvolt and nanowatt means that the impedance is in milliohms, which is pretty low. One can build 24 bit ADC, though maybe not at the higher speeds. Building an amplifier with noise that low is difficult, and maybe impossible. But the ability to pick up microvolt/nanowatt signals is often due to high power signals, such as nearby transmitters. Without that, an appropriate amplifier isn't so hard to build. Gah4 ( talk) 04:41, 1 April 2018 (UTC)
Since Wikipedia is for promotion of progress in science and technology.
I would dare to ask, can someone know about mod/hack needed to make such device:
telestar . de / produkt / digiporty-t2 /
into SDR over IP. It does not need to be this exact product, but It need to be stand alone broadcast receiver over IP.
Forgive me for giving description of link, but my English is too poor to describe it in other way, and the Idea is foreign enough for general population.
I am searching for such solution in order to be able to receive AM digital Radio over IP, DLNA.
And I suppose only products of this type/segment can have potential to be cheap enough receiver in order to boost digitalization of radio, and Save Digital Radio Mondiale+ standard from dying out and other standard of digital broadcast over AM.
I have seen so far only raspberry pi with usb dvb-t tuner pluged in used as drm+ over IP server.
But solution seemed amatoure and elaborate.
I do not think people in poor countries could have knowledge how to setup.
And I suppose such type of device have potential to become the cheapest way to receive am digital radio mondiale+ and even dab+.
And I only humbly suppose all mod to achieve desired reception would be to install alternative software on the phone. — Preceding unsigned comment added by 109.173.159.109 ( talk) 20:38, 25 August 2018 (UTC)
I reverted a bunch of edits by User:Maestro2016 mostly because I believe that they need discussion before being added. They have also recently been added to, and I believe reverted, from History of radio. I believe that History of radio could use some updating for modern radio systems, though that isn't the question here. I do have some questions for what does and doesn't belong here, and maybe some of the ones I revert really belong. There is a big difference between the ideal SDR and what one really can do, and some existing ICs could be very useful. Lets do some discussing and see what is reasonable. Gah4 ( talk) 11:34, 11 December 2019 (UTC)
{{u|
Mark viking}} {
Talk}
01:43, 12 December 2019 (UTC)It seems to me that, as described, SDR is for digital receivers of analog radio signals. That is, traditional modulation systems such as AM, FM, PM, or SSB. But more and more, radio systems are going digital. In other words, there is no ADC in the receiver, but most often some type of spread spectrum system. Programmable digital receivers are now common in, for example, cell phones which need to be able to be used with different cell systems. Only in the case where one needs a receiver for an existing system, such as broadcast AM or FM, or ones such as marine or aviation radio. As I understand it, aviation radio uses AM, as it allows for emergency override, where when two are transmitting on the same frequency, the receiver gets some of each. I suspect, though, that for military applications, they are going digital more and more. Gah4 ( talk) 23:14, 3 March 2020 (UTC)
KiwiSDR is similar to WebSDR (which can use any SDR radio) but it uses a specific piece of hardware that allows individual 0-30 MHz tuning for each user. Link to website: http://www.kiwisdr.com/ — Preceding unsigned comment added by 194.193.212.24 ( talk) 05:16, 17 October 2020 (UTC)
There is a very interesting GS1299 single chip FM radio receiver. The data sheet doesn't give much details, but it goes from antenna with a fixed LC filter on one side, to stereo audio outputs, able to drive headphones, on the other side. The only tuned circuit is a 32768Hz crystal oscillator. I don't see any mention or reason for software, though. It does say CMOS, and much of the processing can be done in digital CMOS hardware without any software. It is fixed for the FM band, so no software programming needed. As far as I know, though, there is no article on non-software digital receivers for analog radio signals. In any case, I assembled a kit with this chip, and it works just fine. Gah4 ( talk) 02:18, 24 February 2021 (UTC)
Text excerpt: "widely different radio protocols (sometimes referred to as waveforms)" Yrs trly is an old–timer; that ref. to waveforms looks strikingly peculiar. If it has a special meaning within the context of SDR, please clarify. Nevertheless, especially after watching two videos about specific SDRs, I know that I want to learn more! Nikevich 05:59, 1 December 2021 (UTC)
{{u|
Mark viking}} {
Talk}
06:46, 1 December 2021 (UTC)
Hi. "The" GNU Radio: I was the head maintainer for GNU Radio, nobody uses it with the "the" article; it's a software project, just like "the libreoffice".
I also been a Support Engineer for Ettus for nearly a decade. There's several separate USRP models, but none correctly match the technical data given in the section.
The only forgivable sin here is that GNU Radio used to be predominantly used with USRP hardware. That isn't as strongly the case anymore, since better integration of other SDR hardware has arrived.
I'm hence reworking that section. Marcusmueller ettus ( talk) 12:09, 3 January 2023 (UTC)
There's absolutely no need to bring a bullet list of arbitrarily chosen waveforms to say "SDR enables usage of different waveforms"; it actively makes the article worse.
I'm removing that list, it has no business being in this article. A link to Modulation serves the same purpose, just better! Marcusmueller ettus ( talk) 12:24, 3 January 2023 (UTC)
This is the
talk page for discussing improvements to the
Software-defined radio article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This ![]() It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The link for SDR Forum Software Defined Radio Design Process and Tools Work Group Wiki was removed. This was a valuable link to a collaborative forum for the SDR community. I do not see this as spam. It is a place to discuss how to design and implement SDR's. How do we get it added back in? AndrewDauman 22:02, 19 June 2007 (UTC)AndrewDauman
Can we whittle down the list of external links. It would be better to cite some of these as references at specific points in the article, while removing the rest. Jehochman ( Talk/ Contrib) 16:55, 20 December 2006 (UTC)
Can I add a Seminar Paper Presented On SDR?
Virtual11234
03:55, 5 March 2007 (UTC)
The title of Mitola's paper seems to be wrong. It is: "Software radios - survey, critical evaluation and future directions". 2008-11-18
It appears that there are three pages for Software Defined Radio. http://en.wikipedia.org/wiki/Software_radio http://en.wikipedia.org/wiki/Software-defined_radio http://en.wikipedia.org/wiki/Software_defined_radio Even though it appears as though they somehow sync-up, I suggest one be maintained and the other two deleted Jennifersteinberg 20:31, 4 June 2007 (UTC)
Current (2003) digital electronics is to slow to process signals from 10kHz to 2.4GHz? Might be a bit outdated. In 2007, I think we're either there or getting there, and while we cannot receive the entire radio spectrum, projects such as HPSDR are developing hardware (the mercury board) that can directly sample the radio spectrum from 0-65MHz. - Ryan 19:26, 15 June 2007 (UTC)
from the intro: SDR [uses] … the soundcard of a general purpose computer (PC), or a reconfigurable home-made piece of digital electronics. But, the military examples given don't sound like either 'a soundcard' or 'home-made digital electronics'. Should it instead say that the processing is done in a type of computer hardware known as a DSP such as what is found in soundcards? 「 ѕʀʟ· ✎」 06:21, 24 September 2007 (UTC)
In the second paragraph: "An SDR performs significant amounts of signal processing with the soundcard of a general purpose computer (PC)..." Why soundcard? In my opinion soundcard equals to audio card. It's kind of confusing here. —Preceding unsigned comment added by 202.40.139.171 ( talk) 08:06, 4 October 2007 (UTC)
It seems that digital oscilloscopes and function-genertors are bit similar to sdr. any comments? 193.167.107.251 ( talk) 19:25, 28 January 2008 (UTC) <---- This assertion is too vague to respond to.
There are several technical inaccuracies in the section on practical receivers. The statement that digital electronics are too slow to receive signals over 40 MHz is incorrect. Remember that the Nyquist Theorem states that the sampling rate must be at least twice the bandwidth of the signal. This means that, in theory, we can sample signals anywhere in the spectrum (with some limitations depending on where the signal is located in relation to the sampling frequency). The limiting factor in actual radios is a measure called the aperture jitter, which quantifies the ability of the ADC to sample at a precise interval (assuming a jitter-free sampling clock, of course). If you are interested more in the subject a google of "undersampling" turns up several excellent references.
The statements on recovering the phase and bit timing are also incorrect. The reason we need to recover phase and bit information is that the transmitter and receiver clocks are not in sync with each other. By recovering this information we will be able to integrate over the entire bit and thus receive the most power and improve the accuracy of the entire radio.
As far as authority goes, I am an electrical engineer who designs digital radios for a living. Roddefig ( talk) 07:06, 23 May 2008 (UTC)
Can someone define radio protocol, as used several times in the article? -- Abdull ( talk) 12:49, 24 August 2008 (UTC)
The part "Receivers" is copied from NXP itself.
There are more companies claiming to have a chip implementation of SDR for a handset soc.
from google
217.140.96.21 (
talk)
07:51, 3 April 2009 (UTC)
In the section "SPEAKeasy phase II", at the end, it is claimed that "The time to reprogram these [FPGAs] is an issue limiting application of the radio." This is misleading. The time to write a program for an FPGA is significant; the time to download a stored FPGA program is around 20 milliseconds. This means an SDR could change transmission protocols and frequencies in one fiftieth of a second, probably not an intolerable interruption for that task. I am speaking from my experience with Gigaoperations, the maker of the FPGA computing platform chosen by Xilinx in the 1990s. I imagine with much bigger, but faster, FPGAS today, download times are similar. Rhodesh ( talk) 22:43, 10 August 2010 (UTC)
It's half past 2011 at the moment and there are lots of citations. The box should be deleted immediately. It's pure gnome shit.
Because of his many publications on the subject, Joseph Mitola III is sometimes called " the father of the software radio." Joe worked, off and on, at E-Systems. In 1984 the phrase "software radio" was defined by members of a team of E-Systems Garland Division employees to describe a large baseband receiver they designed and built. I was a member of that team. Joe was not. We never saw him around and as far as I know he wasn't even cleared to enter the room. He had nothing whatsoever to do with development of the 1984 E-Systems software radio. In the years since then it has annoyed some of us whenever Joe claims he later coined the term software radio (for instance here).
By the way "software defined radio" kind of sucks since it could (and sometimes does) just mean using a GUI to set the knobs, so to speak, on an analog receiver. — Preceding unsigned comment added by 24.251.186.204 ( talk) 18:22, 29 August 2011 (UTC)
Today I note somebody (could it have been Joe? ;-) has massively and strangely rewritten the History section. Joe, like you, Midas had nothing to do with the '84 E-Systems radio. We necessarily wrote our own software for all that parallel processing. Garland never used Midas and I don't think we even had it available. When we saw it used at other facilities we considered it awkward, inflexible and, frankly, a little weird. We didn't need no stinking audit trails. — Preceding unsigned comment added by 24.251.169.182 ( talk) 14:04, 10 February 2013 (UTC)
Joe, are you saying that a software transceiver is a software radio but a software receiver is not? That would be silly. You wouldn't argue that a hardware receiver isn't a radio. Would you?
The '84 E-Systems Garland Space Systems (hereafter ESY) radio was a surprise to the customer and the relevant community. TTBOMK, ESY at that time was not involved in data analysis. ESY was strictly a system integrator, receiving boxes, designing interfaces and hooking them together. Assemble it, smoke test it, ship it --- that sort of thing. As such, ESY had no need of the Midas analysis software and AFAIK didn't have it.
Now as is well known, the government likes to keep a stable of vendors on call and ready to respond to RFPs. To keep those vendors sweet, projects sometimes seem to be assigned sort of round robin rather than strictly on the merits of the proposals. Anyway, on one particular project, we, ESY, proposed what we called the software radio, which was a great pile of array processors working on the shared memory of an Aptec box, running our unique algorithms effected as data flow programming. This was a front-to-back production engine which necessarily embodied some functions previously performed elsewhere. Tape recordings in, paper out.
Turned out the customer loved the proposal but apparently it wasn't our turn. So somebody else got that contract but the customer gave ESY a special contract to build the radio anyway. And the rest --- say it with me --- was history. My name is John McKown and I approved this message.
The definition of SDR used in this article is basically that used by black box consumers in the amateur radio market. The professional definition of SDR would actually cover nearly all modern, commercially produced, HF amateur radio equipment, and an increasing amount of VHF and UHF equipment.
An SDR is a radio that uses software for back end signal processing, what people are really referring to here are not SDRs, because they actually do not run any software, but rather RF and IF front ends, which can be combined with the A/D converter in a PC sound card, and a general purpose computer, to produce a complete system which is a software defined radio. The definition used here refers to essentially purely analogue devices (although some integrate the A/D converter).
As used here, it is either a marketing term for a specific sub-market, or simply a misunderstanding of the terminology in that market.
-- David Woolley ( talk) 12:41, 22 January 2012 (UTC)
I propose that Software GNSS Receiver be merged into Software-defined radio. As an alternative we could just delete Software GNSS Receiver which is more about the technology of hardware vs software radios, than it is about something specific to GPS or GNSS. ★NealMcB★ ( talk) 20:16, 24 April 2012 (UTC)
I propose to branch the ham radio SDR software to a new article. Furthermore it would be helpful to include a list of the software available on Linux, OSX, Windows as entry points for the interested reader. A list like the revision control software overview would be great. :) 2A4Fh56OSA ( talk) 09:21, 29 September 2012 (UTC)
Does anybody really consider DSP operations to a baseband signal to be SDR? I would expect that a SDR should be able to encode or decode an AM, FM, or QAM signal by changing the software. If the input to a DSP is via a sound card, then how can the IF frequencies of 455 KHz on AM broadcast and 10.7 MHz on FM broadcast be captured? Does one mix down to a 20 KHz IF? Is it really practical to generate a 20 KHz IF that a sound card could digitize? And could any useful info be extracted from that low, low IF?
I suspect anything that uses the A/D on a sound card is merely a fancy tone control for a baseband signal. That stuff belongs in Audio filter. RastaKins ( talk) 21:49, 26 October 2013 (UTC)
Seems to me that the definition of SDR excludes the use of programmable hardware (FPGAs). Maybe this is an accident due to the history of the path leading to current technology. The important distinction should be doing radio operations, such as mixers and filters, in the programmable digital domain, not software vs. hardware. Under the ideal assumptions, you should be able to connect an ADC to an FPGA, and demodulate most radio signals up to hundreds of megahertz, with all the SDR advantages but no software. (In actual implementations, you probably need some filters, though.) Why the restriction to software? Gah4 ( talk) 19:38, 14 September 2015 (UTC)
I come back to this article every few months, and lately it seems like there is more and more marketing copy in the text. A lot of it is fairly conspicuous and lacks references (or when references are provided, they are to product / company pages).
Some examples:
Beginning of the History Section:
Basically the entirety of the "Current Usage - Military - USA" section. Here's a portion:
The program is providing a flexible new approach to meet diverse soldier communications needs through software programmable radio technology. All functionality and expandability is built upon the SCA.
“SDRs flexibility results in expensive complexity, inability to optimize, slower ability to apply the latest technology, and rarely a tactical user need (since all users must pick and stay with the one, same radio if they're to communicate).” — Preceding unsigned comment added by 2600:6C64:507F:FFF2:D859:C05A:8AE0:1746 ( talk) 21:11, 7 March 2021 (UTC)
The later "Amateur and home use" section also has a lot of stuff like this, where it calls out specific examples of products from SDR vendors, which is a very large market
I'd like to point out that I actually run the GNU Radio project, also listed in this section, and I think the way it is used here is poor form for a Wikipedia page.
The long & short of it is that I think this page needs significant clean-up, but perhaps I'm alone in that opinion.
Also, tangentially, why this article is under the Multiplexing category on Wikipedia is rather confusing to me. — Preceding unsigned comment added by Bhilburn ( talk • contribs) 22:54, 6 November 2017 (UTC)
The article says: Real analog-to-digital converters lack the dynamic range to pick up sub-microvolt, nanowatt-power radio signals. Therefore, a low-noise amplifier must precede the conversion step and this device introduces its own problems. For example, if spurious signals are present (which is typical), these compete with the desired signals within the amplifier's dynamic range. They may introduce distortion in the desired signals, or may block them completely. It seems to me that this is mixing dynamic range and signal level. To start, microvolt and nanowatt means that the impedance is in milliohms, which is pretty low. One can build 24 bit ADC, though maybe not at the higher speeds. Building an amplifier with noise that low is difficult, and maybe impossible. But the ability to pick up microvolt/nanowatt signals is often due to high power signals, such as nearby transmitters. Without that, an appropriate amplifier isn't so hard to build. Gah4 ( talk) 04:41, 1 April 2018 (UTC)
Since Wikipedia is for promotion of progress in science and technology.
I would dare to ask, can someone know about mod/hack needed to make such device:
telestar . de / produkt / digiporty-t2 /
into SDR over IP. It does not need to be this exact product, but It need to be stand alone broadcast receiver over IP.
Forgive me for giving description of link, but my English is too poor to describe it in other way, and the Idea is foreign enough for general population.
I am searching for such solution in order to be able to receive AM digital Radio over IP, DLNA.
And I suppose only products of this type/segment can have potential to be cheap enough receiver in order to boost digitalization of radio, and Save Digital Radio Mondiale+ standard from dying out and other standard of digital broadcast over AM.
I have seen so far only raspberry pi with usb dvb-t tuner pluged in used as drm+ over IP server.
But solution seemed amatoure and elaborate.
I do not think people in poor countries could have knowledge how to setup.
And I suppose such type of device have potential to become the cheapest way to receive am digital radio mondiale+ and even dab+.
And I only humbly suppose all mod to achieve desired reception would be to install alternative software on the phone. — Preceding unsigned comment added by 109.173.159.109 ( talk) 20:38, 25 August 2018 (UTC)
I reverted a bunch of edits by User:Maestro2016 mostly because I believe that they need discussion before being added. They have also recently been added to, and I believe reverted, from History of radio. I believe that History of radio could use some updating for modern radio systems, though that isn't the question here. I do have some questions for what does and doesn't belong here, and maybe some of the ones I revert really belong. There is a big difference between the ideal SDR and what one really can do, and some existing ICs could be very useful. Lets do some discussing and see what is reasonable. Gah4 ( talk) 11:34, 11 December 2019 (UTC)
{{u|
Mark viking}} {
Talk}
01:43, 12 December 2019 (UTC)It seems to me that, as described, SDR is for digital receivers of analog radio signals. That is, traditional modulation systems such as AM, FM, PM, or SSB. But more and more, radio systems are going digital. In other words, there is no ADC in the receiver, but most often some type of spread spectrum system. Programmable digital receivers are now common in, for example, cell phones which need to be able to be used with different cell systems. Only in the case where one needs a receiver for an existing system, such as broadcast AM or FM, or ones such as marine or aviation radio. As I understand it, aviation radio uses AM, as it allows for emergency override, where when two are transmitting on the same frequency, the receiver gets some of each. I suspect, though, that for military applications, they are going digital more and more. Gah4 ( talk) 23:14, 3 March 2020 (UTC)
KiwiSDR is similar to WebSDR (which can use any SDR radio) but it uses a specific piece of hardware that allows individual 0-30 MHz tuning for each user. Link to website: http://www.kiwisdr.com/ — Preceding unsigned comment added by 194.193.212.24 ( talk) 05:16, 17 October 2020 (UTC)
There is a very interesting GS1299 single chip FM radio receiver. The data sheet doesn't give much details, but it goes from antenna with a fixed LC filter on one side, to stereo audio outputs, able to drive headphones, on the other side. The only tuned circuit is a 32768Hz crystal oscillator. I don't see any mention or reason for software, though. It does say CMOS, and much of the processing can be done in digital CMOS hardware without any software. It is fixed for the FM band, so no software programming needed. As far as I know, though, there is no article on non-software digital receivers for analog radio signals. In any case, I assembled a kit with this chip, and it works just fine. Gah4 ( talk) 02:18, 24 February 2021 (UTC)
Text excerpt: "widely different radio protocols (sometimes referred to as waveforms)" Yrs trly is an old–timer; that ref. to waveforms looks strikingly peculiar. If it has a special meaning within the context of SDR, please clarify. Nevertheless, especially after watching two videos about specific SDRs, I know that I want to learn more! Nikevich 05:59, 1 December 2021 (UTC)
{{u|
Mark viking}} {
Talk}
06:46, 1 December 2021 (UTC)
Hi. "The" GNU Radio: I was the head maintainer for GNU Radio, nobody uses it with the "the" article; it's a software project, just like "the libreoffice".
I also been a Support Engineer for Ettus for nearly a decade. There's several separate USRP models, but none correctly match the technical data given in the section.
The only forgivable sin here is that GNU Radio used to be predominantly used with USRP hardware. That isn't as strongly the case anymore, since better integration of other SDR hardware has arrived.
I'm hence reworking that section. Marcusmueller ettus ( talk) 12:09, 3 January 2023 (UTC)
There's absolutely no need to bring a bullet list of arbitrarily chosen waveforms to say "SDR enables usage of different waveforms"; it actively makes the article worse.
I'm removing that list, it has no business being in this article. A link to Modulation serves the same purpose, just better! Marcusmueller ettus ( talk) 12:24, 3 January 2023 (UTC)