Re: [Discuss-gnuradio] re: Low cost hardware option, the "total GNU solution"
On 15.01.2011 16:17, Marcus D. Leech wrote: >> It would be really cool to create a "total GNU" solution for the GNURADIO. >> GNU EDA tools, GNU-like Hardware (open-source community license), >> GNU FPGA-code, GNU µC-Code, GNU signal processing (the existing Gnuradio), >> GNU operating system, GNU postprocessing (GNU Octave), GNU visualization >> (gnuplot) ... >> >> I have only worked with Mentor Graphics and Protel before. Don't know if gEDA >> is really suitable to handle all the EDA processes to prepare manufacturing >> (auto-routing, EMI analysis and simulations, prepare the CNC drilling ... ?) >> >> > Of course, there's no such thing as a "total Gnu Solution". Not unless > we start > producing VLSI ourselves, etc, etc. :-) > Do you think GNU should go into the semiconductor business :-) A semiconductor fab is more than a hobby. But it's a still lot of GNU, if only the components and PCB production will be commercially outsourced. I like the idea of a GNU EDA and GNU software combination. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] re: Low cost hardware option, the "total GNU solution"
On 15.01.2011 15:46, Marcus D. Leech wrote: >> It would be really cool to create a "total GNU" solution for the GNURADIO. >> GNU EDA tools, GNU-like Hardware (open-source community license), >> GNU FPGA-code, GNU µC-Code, GNU signal processing (the existing Gnuradio), >> GNU operating system, GNU postprocessing (GNU Octave), GNU visualization >> (gnuplot) ... > My most recent paid-work project was both a hardware and software > project, and > the RF front-end was done entirely in Kicad, which is an open-source > environment. > It produces professional-quality schematics, BOMs, PCB layouts, gerber > and drill > files, etc, etc. It's not called "GNU", but at least Kicad has a GPL license, so it will not break the "GNU toolchain". I downloaded and played around with KiCad a bit. >From the first impression, it's more intuitive than gEDA. It has an autorouter, but also external routing programs can do the job. There are lots of component libraries, all Eagle libs converted and much more in http://kicadlib.org/ Does anybody have experiences with both tools, gEDA and KiCad? Which one is more comfortable, which one more powerful, better suited for a Gnuradio? The advantage of KiCad is that it runs on Windows and Unix. I'm using Linux only for server- and number crunching jobs, but not as a desktop. gEDA on Windows is really a pain. With gEDA I like that spice and verilog simulations can be integrated, signal visualization with wave and wcalc EM analysis. KiCad has no simulation capabilities. It might be a critical aspect for RF circuits. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to run gnuradio application with a file input and no physical receiver?
Hello and thanks for your guidance: I would like to run the gnuradio software package with an input file and other input data. So far, when I run examples in gnuradio-examples the application stops because no USRP is found. A short term goal is to learn about the process of digital signal recovery. The long term goal is to use input data from a breadboarded digital radio gadget. Thanks again, Lee McKusick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to run gnuradio application with a file input and no physical receiver?
Hi Lee, On Sun, Jan 16, 2011 at 3:25 PM, Lee McKusick wrote: > Hello and thanks for your guidance: > > I would like to run the gnuradio software package with an input file and > other input data. > > So far, when I run examples in gnuradio-examples the application stops > because no USRP is found. Try using the audio examples, or bypass the examples all together and use gnuradio-companion to setup your signal flow. Feel free to change the audio sources from those examples and replace them with generated signal sources. > A short term goal is to learn about the process of digital signal > recovery. The long term goal is to use input data from a breadboarded > digital radio gadget. > > Thanks again, Lee McKusick Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] constellation object
On Sat, Jan 15, 2011 at 1:40 AM, Ben Reynwar wrote: > Hi all, > > What do people think of introducing a constellation object into gnuradio? > > It would hold the constellation points and also a decision-making function. > New modulations could then be easily created by subclassing a constellation. > > It would also mean that the decision-making function for a given > modulation could > easily be used by different receivers (i.e. the standard receiver and > the ofdm receiver would > both use the same decision making code for a given modulation). > > I've already had a go at implementing this on my repo. > > https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/lib/general/gr_constellation.h > https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/lib/general/gr_constellation_receiver_cb.h > https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/python/gnuradio/blks2impl/qam.py > https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/python/gnuradio/blks2impl/generic_mod_demod.py > > Cheers, > Ben Ben, Are you talking about something different than gr_constellation_decoder_cb? I haven't looked at your code, but it strikes me that what you want is similar to that decoder code (you can find its use in dbpsk.py and dbpsk2.py in gnuradio-core/src/python/gnuradio/blks2impl). My only suggestion for this part is to have a constellation_decoder_cf that would output soft symbols instead of hard symbols. Let me know if I've missed something in what you are asking. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DDC and Polyphase Channelizer
Hi, Tom: Thank you for the suggestion, I'll review the code and examples again to see what I missed. Thanks On 1/14/2011 7:03 AM, Tom Rondeau wrote: On Wed, Jan 5, 2011 at 4:14 AM, Jimmy Richardson wrote: Hi, Tom: Please see my comments below. Thanks On 1/4/2011 11:44 PM, Tom Rondeau wrote: On Mon, Jan 3, 2011 at 11:25 PM, Jimmy Richardson wrote: Indeed. Very strange. My guess is that there is a misconception somewhere in the code about sample rate. I can't quite see it in my head, but I'm guessing that the channel spacing isn't exactly the channel spacing you think it is. You mean the oversample rate O = N/i is wrong? As far as I can see, that's the only number that could go wrong, since pfb_channelizer_ccf only takes 3 parameters, # of channels, taps and oversample rate, and it doesn't look like the other two can be wrong. I checked the calculation of O again, but couldn't find the problem. In the Matlab code, harris uses loops "for nn=1:28:5600-28" to do the processing, so it does seems a 28-to-1 downsampling in 40 channels. No, not the oversample rate, just the sample rate. I'm thinking that there is some misunderstanding somewhere about the actual sample rate and the therefore the channel bandwidths such that the channels you are pulling out are not covering the same frequencies that you think they are. Sorry, maybe I didn't get how the algorithm works, but it looks to me the actual sample rate does not enter into the equation, except in the filter generation part? If we use the same filter on both methods, then the actual sample rate should not cause the difference? No, the sample rate as a real number doesn't enter into the code, but it does abstractly in where the signals exist, what the channel bandwidths mean, etc. I'm not sure what else to say here, really, just to think closely about the signals and the channelizer. Again, it could be that there is a bug in the code that only worked for my cases. On the other hand, it could be a miscalculation in the pfb_channelizer, although all of my tests with it came out fine. Is the test cases included in the GNURadio source code? Also if I want to understand the logic inside pfb_channelizer implementation, are there any book or paper I should review besides harris' paper and book? No, they aren't. It shouldn't be difficult to modify the example codes that are there, though, to see what happens and make sure it makes sense. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] constellation object
On Sun, Jan 16, 2011 at 2:52 PM, Tom Rondeau wrote: > On Sat, Jan 15, 2011 at 1:40 AM, Ben Reynwar wrote: >> Hi all, >> >> What do people think of introducing a constellation object into gnuradio? >> >> It would hold the constellation points and also a decision-making function. >> New modulations could then be easily created by subclassing a constellation. >> >> It would also mean that the decision-making function for a given >> modulation could >> easily be used by different receivers (i.e. the standard receiver and >> the ofdm receiver would >> both use the same decision making code for a given modulation). >> >> I've already had a go at implementing this on my repo. >> >> https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/lib/general/gr_constellation.h >> https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/lib/general/gr_constellation_receiver_cb.h >> https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/python/gnuradio/blks2impl/qam.py >> https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/python/gnuradio/blks2impl/generic_mod_demod.py >> >> Cheers, >> Ben > > > Ben, > Are you talking about something different than > gr_constellation_decoder_cb? I haven't looked at your code, but it > strikes me that what you want is similar to that decoder code (you can > find its use in dbpsk.py and dbpsk2.py in > gnuradio-core/src/python/gnuradio/blks2impl). > > My only suggestion for this part is to have a constellation_decoder_cf > that would output soft symbols instead of hard symbols. > > Let me know if I've missed something in what you are asking. > > Thanks, > Tom > gr_constellation_decoder_cb uses minimum distance to determine the correct symbol. I would guess this would become a bottleneck for large constellations. My suggestion was to create c++ classes representing constellations which would contain both the constellation points and a function to determine what point a given complex number corresponded to. This way different decision making functions could be written for each modulation (e.g. for PSK you just bin based on the phase, for QAM you bin based on the real and imag components.) These classes would not be signal-processing blocks, but rather would be passed to blocks as arguments. Separating out this code from the receivers would mean that it didn't have to be implemented separately for each receiver. This would effect gr_constellation_decoder_cb in that it would take a constellation object when initialized, e.g. gr_constellation_decoder_cb::gr_constellation_decoder(const gr_constellation_sptr constell) and would use constell.decision_maker to determine what symbol value to return. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
