As a ham radio operator, electrical engineer, and part time amateur radio designer hack, I have been kicking around the idea of a small low frequency (30 kHz to 100ish MHz) sampling device for the front end of a software defined radio (SDR). I envision the front end being similar to the system designed by Sinisa Tasic (YU1LM out of Serbia), except built exclusively with surface mount components to minimize size, and laid out on a board the size of the Raspi. See http://yu1lm.qrpradio.com/SDR&.....-YU1LM.pdf for a detailed description of what the RF front end would likely resemble.
I imagine that a PIC could be used to perform the analog sampling of the down-converted RF, and to convert the samples to I2C or SPI (since there is no analog capability available directly on the board. The PIC would also talk to a programmable crystal oscillator to be used for the local oscillator. A small amount of ham radio SDR software for Linux already exists, and it may be executable directly on the Raspi board. If not, some coding would have to be done, possibly making use of the onboard DSP once the DSP folks let us see behind the curtain.
This seams like a natural thing to do with a board built around a cellphone processor anyway...
Re: Software Defined Radio
Isn't 100ish MHz a bit too much for such a limited CPU?
Re: Software Defined Radio
I will have fun with the funcube dongle sdr with the raspberry.
Re: Software Defined Radio
Quote from radu on November 23, 2011, 05:53
Isn't 100ish MHz a bit too much for such a limited CPU?
The CPU wouldn't have to sample at 100 MHz. The 100 MHz signal would be down-converted to the audio range (0 - 10 kHz) which would be sampled at 40ish kHz. The CPU would be processing the 40 kHz sample stream.
Isn't 100ish MHz a bit too much for such a limited CPU?
The CPU wouldn't have to sample at 100 MHz. The 100 MHz signal would be down-converted to the audio range (0 - 10 kHz) which would be sampled at 40ish kHz. The CPU would be processing the 40 kHz sample stream.
Re: Software Defined Radio
Quote from dattaway on November 23, 2011, 08:10
I will have fun with the funcube dongle sdr with the raspberry.
WOW the funcube dongle looks nifty. The main problems I have with it is that it only goes down to 64 MHz, and that it costs 113 pounds ($175). I am interested in receiving HF signals (3.5 MHz to 50 MHz) since this is where most of the long distance terrestrial RF communication happens. I am also have a kid, and am therefore short on cash, so $50 is easier to come up with than $175, and I think I could design the board to cost less than $50. I wonder if there are any other low price USB interface SDR interfaces out there. I know there are plenty in the $500-$1000 range.
I will have fun with the funcube dongle sdr with the raspberry.
WOW the funcube dongle looks nifty. The main problems I have with it is that it only goes down to 64 MHz, and that it costs 113 pounds ($175). I am interested in receiving HF signals (3.5 MHz to 50 MHz) since this is where most of the long distance terrestrial RF communication happens. I am also have a kid, and am therefore short on cash, so $50 is easier to come up with than $175, and I think I could design the board to cost less than $50. I wonder if there are any other low price USB interface SDR interfaces out there. I know there are plenty in the $500-$1000 range.
Re: Software Defined Radio
I'd like to do something similar.
I think using YU1LM's front ends is a good idea. I'd put them on a board with a high quality DAC/ADC and a dsPic (to do the heavy lifting of modulating and demodulating the I/Q signals to audio.)
It could even be designed to have a front-end mixer stage using a DDS and an SBL-1 to give a tiny radio with 0-500MHz transceive capabilities.
73,
Dan MD1CLV
I think using YU1LM's front ends is a good idea. I'd put them on a board with a high quality DAC/ADC and a dsPic (to do the heavy lifting of modulating and demodulating the I/Q signals to audio.)
It could even be designed to have a front-end mixer stage using a DDS and an SBL-1 to give a tiny radio with 0-500MHz transceive capabilities.
73,
Dan MD1CLV
Re: Software Defined Radio
I already bought the Funcube Dongle. Now it's time for the raspberry pi to be shipped. 
http://www.george-smart.co.uk/.....pconverter
May that's an option for you.
http://www.george-smart.co.uk/.....pconverter
May that's an option for you.
Re: Software Defined Radio
Oh cool, have you had a chance to play with it on a computer you already have set up?
Dear forum: Play nice
Re: Software Defined Radio
Of course, I have until now a little bit troubles with the compiling of gnuradio for arch linux cause arch linux has to new packages, but the stick works well with Windows 7 x64, here a screenshot while receiving a GSM signal from my mobile phone.
http://joph.de/pics/gsm1.png
http://joph.de/pics/gsm1.png
Re: Software Defined Radio
I originally intended to use the rpi with something like the funcube dongle, just better, but that very much depends on the availability of the gpu's dsp resources...
Re: Software Defined Radio
Im not sure why you would want the dspPIC to demodulate the signal then output it as audio. you may as well just plug in some headphones to the dspPIC in that case.
the point of using a quadrature mixer is to downmix the RF freq to a low enough frequency that the I/Q signals can be picked up by an audio freq ADC. Then let the PC decode the signal, this allows you todo all your demodulation in software, vs fixed unchangeable hardware.
The audio-in on the raspberry-pi is going to be pretty much unusable for a SDR. You would need to use a usb soundcard. The GPIO's from what Ive read wont be able to maintain even 1/10th the speed required to receive input from an ADC.
There are usb adc all-in-one chipsets out there, their samplerate isnt great but it would do. You just wont get the same dynamic range as you would from some of the higher end ADC's
The real trick to SDR is retaining as much of the quality of the signal as you can, once its gone it cant be recovered. You can have the best antenna, feedline, quadrature downconvert, and a crappy ADC and your signal will be crap.
I dont really think the raspberrypi has enough processing power to decode quadrature signals anyways, but I am going to give it a good go. start with prerecorded I/Q samples to eliminate the ADC. the r-pi doesnt have a VFPU nor support NEON, runs at a lower clock then beagleboards or pandaboards or the overo that ettus uses in the E100/B100. It also uses older armv7 tech vs the newer cortex-M processors used in higher end embedded units.
Everything would need to be done in integer math vs FP. Pretty much every fft lib out there uses FP for good reason. Not a fun task to convert.
What gets me to want to try is the fact that its dirt cheap and man would it make a great portable unit being so small, cheap, and power friendly. At the price these are supposed to sell for how could someone NOT buy one and try it out eh ?
Chris Lee
VE6UDL
the point of using a quadrature mixer is to downmix the RF freq to a low enough frequency that the I/Q signals can be picked up by an audio freq ADC. Then let the PC decode the signal, this allows you todo all your demodulation in software, vs fixed unchangeable hardware.
The audio-in on the raspberry-pi is going to be pretty much unusable for a SDR. You would need to use a usb soundcard. The GPIO's from what Ive read wont be able to maintain even 1/10th the speed required to receive input from an ADC.
There are usb adc all-in-one chipsets out there, their samplerate isnt great but it would do. You just wont get the same dynamic range as you would from some of the higher end ADC's
The real trick to SDR is retaining as much of the quality of the signal as you can, once its gone it cant be recovered. You can have the best antenna, feedline, quadrature downconvert, and a crappy ADC and your signal will be crap.
I dont really think the raspberrypi has enough processing power to decode quadrature signals anyways, but I am going to give it a good go. start with prerecorded I/Q samples to eliminate the ADC. the r-pi doesnt have a VFPU nor support NEON, runs at a lower clock then beagleboards or pandaboards or the overo that ettus uses in the E100/B100. It also uses older armv7 tech vs the newer cortex-M processors used in higher end embedded units.
Everything would need to be done in integer math vs FP. Pretty much every fft lib out there uses FP for good reason. Not a fun task to convert.
What gets me to want to try is the fact that its dirt cheap and man would it make a great portable unit being so small, cheap, and power friendly. At the price these are supposed to sell for how could someone NOT buy one and try it out eh ?
Chris Lee
VE6UDL
Re: Software Defined Radio
The GPIO's from what Ive read wont be able to maintain even 1/10th the speed required to receive input from an ADC.
Won't the SPI go at 1 MHz or more? .
I have (had?) a lot planned for the GPIO......
Won't the SPI go at 1 MHz or more? .
I have (had?) a lot planned for the GPIO......
Re: Software Defined Radio
ya but your going to need alot more then that for a quality ADC
192,000x24x2 = 9,216,000bit/sec
just from reading around the internet 1mhz can be done on some units, we;ll just have to wait and see if the r-pi can do it. but I have no pipe dreams of faster.
Chris Lee
VE6UDL
192,000x24x2 = 9,216,000bit/sec
just from reading around the internet 1mhz can be done on some units, we;ll just have to wait and see if the r-pi can do it. but I have no pipe dreams of faster.
Chris Lee
VE6UDL
Re: Software Defined Radio
ya but your going to need alot more then that for a quality ADC
192,000x24x2 = 9,216,000bit/sec
just from reading around the internet 1mhz can be done on some units,
Great, long as we have 1 MHz I am happy.
Forgot to *2 for stereo :-X
But CDx1 is about 1 or 2 Mb/s, so ball park I would still say he's there.
-
WizardOfOZ
- Posts: 76
- Joined: Thu Oct 13, 2011 8:08 am
Re: Software Defined Radio
One thing to keep in mind is that many of the super integrated VHF/UHF chip radio receivers, as I assume is used in the FunCube, can suffer from very bad oscillator phase noise. If it is one thing you want below 30MHz these days, then it is low phase noise, combined with high intermodulation intercept point. A receiver like the FunCube, when combined with an up-converter, may be suitable as a beginner receiver, but I would be surprised if it performed like a properly designed communication receiver front end for shortwave (3-30Mhz).
Re: Software Defined Radio
It seems to me that this is again a matter of philosophy. Do I (or does the average person) want a top of the line receiver with all the bells and whistles, or do I want a basic, inexpensive system that gets me into the SDR game? When I thought of this, I was (and still am) inclined to the entry level type setup, and I accepted the limited performance that a low cost system would likely have. On the other hand, I was (and still am) willing to be foolishly optimistic that a low cost system *might* be able to provide outstanding performance (or at least outstanding value). Either way, it would be an enjoyable and educational endeavor.
-
WizardOfOZ
- Posts: 76
- Joined: Thu Oct 13, 2011 8:08 am
Re: Software Defined Radio
I'm sorry if I didn't explain myself clearly in my previous post.
As a rule of thumb, then VHF and UHF receivers are designed with different priorities, compared to those for shortwave. Price point has little to do with it. At VHF and higher you generally want wide tuning range, high sensitivity and low receiver amplifier noise (as that is likely to be the dominant factor for weak signal reception). Additionally, as a consequence of the laws of nature, an oscillator running at a higher frequency will have higher phase noise compared to a low frequency counterpart. This problem is compounded by requirements of small physical size and low power consumption. Higher phase noise in an oscillator ruins a receiver's ability to separate closely spaced transmitters.
All of this is because signals tend to be both weak and well spaced out at VHF and up. The antennas themselves are frequently very directional, in addition to being frequency selective, acting as front-end filters for the receiver. So a wide-band front-end is rarely a problem. An omni-directional wide-band antenna, like a discone, would not give very strong signals, so that isn't much of an issue either.
Conversely, for shortwave below 30 MHz, your receiver oscillator(s) are inherently less noisy, cheap or otherwise, simply because they run at a lower frequency and through the use of physically larger components (high Q). Even beginner receivers tend to have a 'strong' (or at least stronger) front end through the omission of super sensitive pre-amps (one of the rare cases of having your cake and eating it too - no preamp being better than having one), compared to an average VHF receiver. Narrow bandpass filters in the front-end are also very common, like the manually tuned, high-Q preselector on receivers of yesteryear. You often also see fixed tuned bandpass filters switched in at need in general coverage receivers.
This is because of the wall-to-wall signals you will find on shortwave, especially below 12-14MHz on the broadcast bands. Noise (figure) in amplifiers is not the limiting factor, oscillator noise and dynamic range is, as the atrocious signal levels will crush many a receiver not prepared for the onslaught. Here in Europe you can actually rectify the antenna signal from a reasonably sized wire antenna, and having it move a needle on a moving coil meter.
Yet for at least 25 years, ever since wideband synthesized VHF rigs became commonplace, people have been trying to add an up-converter to their VHF receiver, generally giving a very poor result for the reasons just outlined. They wish to gain an general coverage receiver, and that they get: They can receive all of shortwave, at once. Simultaneously.
If you want a simple SDR receiver for shortwave, then I'd suggest you go look for one designed for the job, cheap or otherwise. If you insist on using the FunCube plus an up-converter, then do at least consider giving it a sharply tuning, high Q preselector instead of a low-pass filter in the front-end. Otherwise the pre-amp is very likely to be crushed, causing spurious mixer products all over the place.
As a rule of thumb, then VHF and UHF receivers are designed with different priorities, compared to those for shortwave. Price point has little to do with it. At VHF and higher you generally want wide tuning range, high sensitivity and low receiver amplifier noise (as that is likely to be the dominant factor for weak signal reception). Additionally, as a consequence of the laws of nature, an oscillator running at a higher frequency will have higher phase noise compared to a low frequency counterpart. This problem is compounded by requirements of small physical size and low power consumption. Higher phase noise in an oscillator ruins a receiver's ability to separate closely spaced transmitters.
All of this is because signals tend to be both weak and well spaced out at VHF and up. The antennas themselves are frequently very directional, in addition to being frequency selective, acting as front-end filters for the receiver. So a wide-band front-end is rarely a problem. An omni-directional wide-band antenna, like a discone, would not give very strong signals, so that isn't much of an issue either.
Conversely, for shortwave below 30 MHz, your receiver oscillator(s) are inherently less noisy, cheap or otherwise, simply because they run at a lower frequency and through the use of physically larger components (high Q). Even beginner receivers tend to have a 'strong' (or at least stronger) front end through the omission of super sensitive pre-amps (one of the rare cases of having your cake and eating it too - no preamp being better than having one), compared to an average VHF receiver. Narrow bandpass filters in the front-end are also very common, like the manually tuned, high-Q preselector on receivers of yesteryear. You often also see fixed tuned bandpass filters switched in at need in general coverage receivers.
This is because of the wall-to-wall signals you will find on shortwave, especially below 12-14MHz on the broadcast bands. Noise (figure) in amplifiers is not the limiting factor, oscillator noise and dynamic range is, as the atrocious signal levels will crush many a receiver not prepared for the onslaught. Here in Europe you can actually rectify the antenna signal from a reasonably sized wire antenna, and having it move a needle on a moving coil meter.
Yet for at least 25 years, ever since wideband synthesized VHF rigs became commonplace, people have been trying to add an up-converter to their VHF receiver, generally giving a very poor result for the reasons just outlined. They wish to gain an general coverage receiver, and that they get: They can receive all of shortwave, at once. Simultaneously.
If you want a simple SDR receiver for shortwave, then I'd suggest you go look for one designed for the job, cheap or otherwise. If you insist on using the FunCube plus an up-converter, then do at least consider giving it a sharply tuning, high Q preselector instead of a low-pass filter in the front-end. Otherwise the pre-amp is very likely to be crushed, causing spurious mixer products all over the place.
Re: Software Defined Radio
OK. I see your point. I also now understand the difficulties of an up-converter to FunCube architecture. I was planning on designing (or “borrowing” the design for) a commutation type sampling system. The front end would be a 1:4 (SP4T) analog switch driven by a clock running at 4 times the frequency of interest (this is sometimes called a Tayloe mixer even though Dan Tayloe was not the guy that originally thought of it). I was going to use a Silicon Labs Si598 oscillator (http://www.silabs.com/products.....fault.aspx) driving a pair of D flip flops to switch the select inputs on the mux. The 4 outputs of the analog switch would then produce 0, 90, 180, and 270 degree baseband (audio frequency) output which would drive a pair of differential amplifiers to produce a quadrature audio frequency signal at 0 degrees and 90 degrees (I/Q signal for the radio geeks out there).
The quadrature signal would be sampled by a ADC and sent to the Raspi via the onboard SPI bus. I am still trying to get specs on the Raspi SPI capabilities ***any help with this would be GREATLY appreciated***. In response to earlier posts, the audio would not need to be sampled at 196 kHz, 48 kHz would work just fine for the SSB voice (3kHz bandwidth) or CW (100 Hz bandwidth) or digital signal (PSK31 (50 Hz bandwidth), RTTY (200 Hz bandwidth), etc…) which the processor would be decoding. Using a slower sample rate would free up resources on the Raspi as well as reduce the demand on the SPI bus. Also, I am pretty sure a 16 bit ADC would work just fine as well. {48,000 * 16 * 2 = 1.536 Mbits per second which the SPI bus should be able to handle.} Of course the faster the sample rate and more bits the better, which is why another option would be to sample the I/Q audio using a USB sound device. Adding an audio device does add to the price, however. To date I have purchased an HDMI cable ($20), a wireless keyboard/mouse ($26) and will shortly purchase a USB WiFi dongle ($35), so I am $81 into my Raspi setup and I haven’t even bought the $35 device itself =] !
There is a variety of software available which can demodulate an I/Q signal in any number of ways. I am a QRP kind of guy, so if I can get a CW signal out of a simple, inexpensive setup then I would consider my efforts a success. If I can get a SSB signal out, then I will be ecstatic! If I can couple a Raspi to an RF daughter board and a tablet type display, then I will be firmly convinced that I have died and gone to heaven, but that’s just me.
The quadrature signal would be sampled by a ADC and sent to the Raspi via the onboard SPI bus. I am still trying to get specs on the Raspi SPI capabilities ***any help with this would be GREATLY appreciated***. In response to earlier posts, the audio would not need to be sampled at 196 kHz, 48 kHz would work just fine for the SSB voice (3kHz bandwidth) or CW (100 Hz bandwidth) or digital signal (PSK31 (50 Hz bandwidth), RTTY (200 Hz bandwidth), etc…) which the processor would be decoding. Using a slower sample rate would free up resources on the Raspi as well as reduce the demand on the SPI bus. Also, I am pretty sure a 16 bit ADC would work just fine as well. {48,000 * 16 * 2 = 1.536 Mbits per second which the SPI bus should be able to handle.} Of course the faster the sample rate and more bits the better, which is why another option would be to sample the I/Q audio using a USB sound device. Adding an audio device does add to the price, however. To date I have purchased an HDMI cable ($20), a wireless keyboard/mouse ($26) and will shortly purchase a USB WiFi dongle ($35), so I am $81 into my Raspi setup and I haven’t even bought the $35 device itself =] !
There is a variety of software available which can demodulate an I/Q signal in any number of ways. I am a QRP kind of guy, so if I can get a CW signal out of a simple, inexpensive setup then I would consider my efforts a success. If I can get a SSB signal out, then I will be ecstatic! If I can couple a Raspi to an RF daughter board and a tablet type display, then I will be firmly convinced that I have died and gone to heaven, but that’s just me.
Re: Software Defined Radio
WizardOfOz: Does it have to be that way with SDR, though?
A very simple DDC receiver could consist of switchable front-end consisting of preamp/attenuator and anti-aliasing filter going into a wideband ADC. If we take the TI ADS5400 (the first thing that Google found for me,) it samples at 1Gsps, so with the right filters could receive blocks of 0-500MHz, 500MHz-1GHz, 1-1.5GHz and 1.5-2GHz.
In this case, we would want appropriate attenuators or preamps depending on the frequency to ensure that the sampler wasn't overloaded, and we've got got 12 bits of dynamic range - about 75dB at 10MHz according to the datasheet. Close in filtering can be done in DSP giving Q-factors which are difficult to achieve in hardware.
Of course, this is just theoretical and not something I'm advocating building for the RPi.
I think the ideal thing for ai5eedave is a SoftRock RXTX Ensemble and a USB soundcard - I'd guess about $130 for those two plus a USB hub, plus the cost for the display to give a 1W all mode transceiver for up to 3 HF bands. The big problem will then be finding (or writing) fixed point SDR software.
A very simple DDC receiver could consist of switchable front-end consisting of preamp/attenuator and anti-aliasing filter going into a wideband ADC. If we take the TI ADS5400 (the first thing that Google found for me,) it samples at 1Gsps, so with the right filters could receive blocks of 0-500MHz, 500MHz-1GHz, 1-1.5GHz and 1.5-2GHz.
In this case, we would want appropriate attenuators or preamps depending on the frequency to ensure that the sampler wasn't overloaded, and we've got got 12 bits of dynamic range - about 75dB at 10MHz according to the datasheet. Close in filtering can be done in DSP giving Q-factors which are difficult to achieve in hardware.
Of course, this is just theoretical and not something I'm advocating building for the RPi.
I think the ideal thing for ai5eedave is a SoftRock RXTX Ensemble and a USB soundcard - I'd guess about $130 for those two plus a USB hub, plus the cost for the display to give a 1W all mode transceiver for up to 3 HF bands. The big problem will then be finding (or writing) fixed point SDR software.
Re: Software Defined Radio
the nysquist rate is generally considered to be 2x to 2.5x less then the samplerate. http://en.wikipedia.org/wiki/N.....quist_rate
so 400mhz would be the top end of a 1gs/s adc, unless you want todo undersampling. Also there is no computer on the market at all no matter if your dual 8 core processors, that can accept 1G * 12 * 2 = 24Gbit/sec thats insane. Even if you could get the data into the processor that fast, it wouldnt be able todo anything with it. my siz core AMD can barley do a basic 1024 point FFT at 3fps display rate at 10M sample rate. (also 12bit) you would need to use a FPGA to desceminate the datarate much much lower.
at 48ksps adc will ultimatly give you worse performance then a 192k sps adc not because of dynamic range, but because of the noise floor.
http://www.maxim-ic.com/app-no.....vp/id/1870
I'll give it a go with 48khz/16bit why not right ? would be nice to have a little portable sdr, but I dont have alot of hopes for it, maybe Im just a perfectionist but it would just bug me knowing I designed something that had so much more potential but doesnt.
Either way, getting any SDR to work on ARM isnt an easy process. Gnuradio is working hard on the overo platform to get SDR onto arm, its really your best bet. They are working hard on getting optimizations running, like NEON and using the VFP. neither of which the ARM11 processors have. Todo SDR on the ARM11 your going to as stated use much lower sample rates and bitrates and rewrite everything into integer math from floating point. You'll never get anywhere using exsisting fp libraries if your processor doesnt have a hardware fp processor. Ive done implimentations of fp math in software, painfully slow.
Its just the price thats so attractive, $25 is piss cheap ! its awesome. I'll buy a few if I can when they are released. Im posative I can come up with some really cool uses for a $25 computer !
Chris Lee
VE6UDL
so 400mhz would be the top end of a 1gs/s adc, unless you want todo undersampling. Also there is no computer on the market at all no matter if your dual 8 core processors, that can accept 1G * 12 * 2 = 24Gbit/sec thats insane. Even if you could get the data into the processor that fast, it wouldnt be able todo anything with it. my siz core AMD can barley do a basic 1024 point FFT at 3fps display rate at 10M sample rate. (also 12bit) you would need to use a FPGA to desceminate the datarate much much lower.
at 48ksps adc will ultimatly give you worse performance then a 192k sps adc not because of dynamic range, but because of the noise floor.
http://www.maxim-ic.com/app-no.....vp/id/1870
I'll give it a go with 48khz/16bit why not right ? would be nice to have a little portable sdr, but I dont have alot of hopes for it, maybe Im just a perfectionist but it would just bug me knowing I designed something that had so much more potential but doesnt.
Either way, getting any SDR to work on ARM isnt an easy process. Gnuradio is working hard on the overo platform to get SDR onto arm, its really your best bet. They are working hard on getting optimizations running, like NEON and using the VFP. neither of which the ARM11 processors have. Todo SDR on the ARM11 your going to as stated use much lower sample rates and bitrates and rewrite everything into integer math from floating point. You'll never get anywhere using exsisting fp libraries if your processor doesnt have a hardware fp processor. Ive done implimentations of fp math in software, painfully slow.
Its just the price thats so attractive, $25 is piss cheap ! its awesome. I'll buy a few if I can when they are released. Im posative I can come up with some really cool uses for a $25 computer !
Chris Lee
VE6UDL
Re: Software Defined Radio
Hi Chris,
As I said, I wasn't suggesting connecting a 1Gsps sampler to the RPi - that would not be a sensible way to do things. However, there's a couple of technical points with your numbers that I'd like to address. The Nyquist rate is 2x the bandwidth of the signal you are sampling - this is the rate you need to sample at in order to unambiguously reconstruct the original signal. The "2x to 2.5x" comes from the fact that in practice you can't have a perfect anti-aliasing filter - but it should be possible to create one which is good enough.
Since I'd suggested DDC (digital downconversion) instead of QSD (quadrature sampling detection) then we only have one stream of samples - the data rate is therefore 1G * 12 = 12Gbps. This is still a lot, but there are interfaces which will put that sort of data rate into memory. A 64 bit computer would therefore need to be running at about 12Gbps / 64 bits = 190MHz to read this data. FFTs can be run by parallel processors, so it shouldn't stretch a multicore machine to process this data if that was what it was dedicated to doing.
Anyway, back to Raspberry Pi stuff...
I've done some Googling and there is a library called "kissfft" which can do FFT transforms using fixed point arithmatic - far more suitable for the RPi than libraries such as fftw. If I finish my current hobby coding project then I'll have a go at changing some simple SDR programs to use kissfft instead of their default libraries. GNURadio is a fantistic platform for experimenting with SDR, but I don't think it would be the best choice if you were making an embedded radio.
I love the price too - I can think of all sorts of things to do with this, and although I'll restrict myself to one of the first 10000 (if I'm that lucky!) I can see myself getting several over the next couple of years.
Dan Ankers
MD1CLV
As I said, I wasn't suggesting connecting a 1Gsps sampler to the RPi - that would not be a sensible way to do things. However, there's a couple of technical points with your numbers that I'd like to address. The Nyquist rate is 2x the bandwidth of the signal you are sampling - this is the rate you need to sample at in order to unambiguously reconstruct the original signal. The "2x to 2.5x" comes from the fact that in practice you can't have a perfect anti-aliasing filter - but it should be possible to create one which is good enough.
Since I'd suggested DDC (digital downconversion) instead of QSD (quadrature sampling detection) then we only have one stream of samples - the data rate is therefore 1G * 12 = 12Gbps. This is still a lot, but there are interfaces which will put that sort of data rate into memory. A 64 bit computer would therefore need to be running at about 12Gbps / 64 bits = 190MHz to read this data. FFTs can be run by parallel processors, so it shouldn't stretch a multicore machine to process this data if that was what it was dedicated to doing.
Anyway, back to Raspberry Pi stuff...
I've done some Googling and there is a library called "kissfft" which can do FFT transforms using fixed point arithmatic - far more suitable for the RPi than libraries such as fftw. If I finish my current hobby coding project then I'll have a go at changing some simple SDR programs to use kissfft instead of their default libraries. GNURadio is a fantistic platform for experimenting with SDR, but I don't think it would be the best choice if you were making an embedded radio.
I love the price too - I can think of all sorts of things to do with this, and although I'll restrict myself to one of the first 10000 (if I'm that lucky!) I can see myself getting several over the next couple of years.
Dan Ankers
MD1CLV
Re: Software Defined Radio
Will look forward to seeing what you guys get running on the RasPi. Nice to see a few Hams on here!
73
James 2E0JCA
73
James 2E0JCA
Re: Software Defined Radio
Ooh, it looks like I made a mistake. I was sure I'd read that the processor on the RasPi didn't have a floating point unit.
In fact, it does have the VFP11 coprocessor. Which makes life a lot easier
In fact, it does have the VFP11 coprocessor. Which makes life a lot easier
Re: Software Defined Radio
I swore I had read that as well, I'll look into it further. That'll help things out ALOT if it does.
Chris Lee
VE6UDL
Chris Lee
VE6UDL