Re: Complex in/Complex out Hilbert?
Perhaps I'm misunderstanding what you're saying, but isn't the received signal already analytic? The goal is to step it down to real baseband. You don't need a Hilbert transform going in that direction. So, to demodulate, you'd just spin the signal to baseband, filter, and throw away the imaginary part of the result. Voilá, real demodulated signal. On Sat, Apr 18, 2020 at 7:07 PM David Hagood wrote: > I noticed that the version of GnuRadio that is released in Ubuntu 20.04 > has a real-in/Complex out Hilbert block, which is great for modulating > SSB. But it lacks a complex-in/complex-out Hilbert for doing the > demodulation side. Is there any package with the complex/complex form of > the Hilbert? Or has anybody given thought to having an option in the > Hilbert module for doing complex in? > > > > -- Tell me, what is it you plan to do with your one wild and precious life? -- Mary Oliver
Re: Generating CW-morse signals with a straight key
All right. Give me a day or two and I think I can find an archive of all that stuff to pass along. 73 Frank AB2KT/VE7 On Sat, Dec 28, 2019 at 1:40 PM Cinaed Simson wrote: > Cool! I would definitely be interested in the last option "generated CW > tone from text input, either from a file" > > -- Cinaed > > > > On 12/28/19 11:18 AM, Frank Brickle wrote: > > Is there a JACK audio sink in Gnuradio these days? > > > > I'm not sure where they are housed, now, but I wrote a few programs to > > generate CW this way some years ago. They depended on having JACK audio > > input to the application. One of them could use either a straight key or > > would work as a decent iambic keyer. The other generated CW tone from > > text input, either from a file or directly from stdin and therefore from > > a keyboard. > > > > If there were any interest I could probably dig up the source. > > > > 73 > > Frank > > AB2KT/VE7 > > > > > > On Sat, Dec 28, 2019 at 11:06 AM Gorkem Ozcelebi > <mailto:gor...@gmail.com>> wrote: > > > > If I've understood your question correctly, how about the microphone > > / audio input? If it's ac-coupled, you could use a simple > > oscillator. The presence of the tone, gated by your morse key, > > triggers the cw. If you don't want to build / provide an external > > oscillator, how about a software oscillator fed through one of the > > audio output channels of the same PC, going back in thru your morse > > key. The other audio channel is left available for the audio output > > of your receiver. > > > > Gorkem > > > > On Sat, Dec 28, 2019, 7:25 PM Harald Fritzsche (DD0VS) > > mailto:dd...@dd0vs.de>> wrote: > > > > Hello All, > > > > Hoping that amateur radio is not to far away from common use of > > Gnuradio mailing list, but amateur radio is making me looking to > GR > > since 2001. > > There is a plan to use a Gnuradio based transceiver for µ-wave > > contesting, as it has been shown by W7FU or KB1VC (SoDaRadio) or > > DL9SW. > > A needed condition is, to key HF with morse code using a > straigth or > > simple morse key. > > > > Doing this with just looking to the status of /dev/ttyUSB0-CTS > > pin is > > not sufficient, basically some of the keyed code is somehow > > swalloed. > > Neither with python code or with a C++ OOT module i got it > solved. > > > > How to get this solved? (Hardware keying or modulated cw is not > > a real > > option). > > > > Regards and vy73 > > Harald > > DD0VS > > > > > > > > -- > > Tell me, what is it you plan to do with your one wild and precious life? > > -- Mary Oliver > > -- Tell me, what is it you plan to do with your one wild and precious life? -- Mary Oliver
Re: Generating CW-morse signals with a straight key
Is there a JACK audio sink in Gnuradio these days? I'm not sure where they are housed, now, but I wrote a few programs to generate CW this way some years ago. They depended on having JACK audio input to the application. One of them could use either a straight key or would work as a decent iambic keyer. The other generated CW tone from text input, either from a file or directly from stdin and therefore from a keyboard. If there were any interest I could probably dig up the source. 73 Frank AB2KT/VE7 On Sat, Dec 28, 2019 at 11:06 AM Gorkem Ozcelebi wrote: > If I've understood your question correctly, how about the microphone / > audio input? If it's ac-coupled, you could use a simple oscillator. The > presence of the tone, gated by your morse key, triggers the cw. If you > don't want to build / provide an external oscillator, how about a software > oscillator fed through one of the audio output channels of the same PC, > going back in thru your morse key. The other audio channel is left > available for the audio output of your receiver. > > Gorkem > > On Sat, Dec 28, 2019, 7:25 PM Harald Fritzsche (DD0VS) > wrote: > >> Hello All, >> >> Hoping that amateur radio is not to far away from common use of >> Gnuradio mailing list, but amateur radio is making me looking to GR >> since 2001. >> There is a plan to use a Gnuradio based transceiver for µ-wave >> contesting, as it has been shown by W7FU or KB1VC (SoDaRadio) or DL9SW. >> A needed condition is, to key HF with morse code using a straigth or >> simple morse key. >> >> Doing this with just looking to the status of /dev/ttyUSB0-CTS pin is >> not sufficient, basically some of the keyed code is somehow swalloed. >> Neither with python code or with a C++ OOT module i got it solved. >> >> How to get this solved? (Hardware keying or modulated cw is not a real >> option). >> >> Regards and vy73 >> Harald >> DD0VS >> >> -- Tell me, what is it you plan to do with your one wild and precious life? -- Mary Oliver
Re: [Discuss-gnuradio] Piping output of, e.g., Audacity to GNURadio examples
On Wed, May 26, 2010 at 7:37 PM, Joel Koltner zapwire-gro...@yahoo.com wrote: -- For GNURadio examples that are expecting to receive their input from a sound card, use the JACK plug-in for ALSA... Right... -- If writing your own applications, GNURadio can use JACK directly via, e.g., gnuradio-audio-jack ...also right... ...I don't suppose there's a Wiki entry or Web page somewhere that goes through exactly how to do all this? qjackctl makes it all a little simpler. (And there isn't really an easy way to do what I'm asking directly with ALSA alone, is there?) No. Frank -- Go listen: http://www.wqxr.org/q2 Please note new phone numbers: mobile: (908) 442-8863 work: (908) 428-4916 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re: [Discuss-gnuradio] Correct method for compressing a power spectrum
On Tue, Mar 10, 2009 at 9:39 AM, rwmcgw...@gmail.com wrote: Oh horrors. Please let it not be true that the phrase I am remembered most for is heuristic grass. Isn't heuristic grass what gives absinthe the green color? Frank -- For an omnipotent and omniscient being, God has made some really lousy earthly staffing decisions. -- John Cole ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Correct method for compressing a power spectrum
On Tue, Mar 10, 2009 at 10:02 AM, John Ackermann N8UR j...@febo.com wrote: Just remember -- absinthe makes the tart grow blonder. Sigh. With fronds like these, who needs anemones? (Sorry -- done now.) Frank -- For an omnipotent and omniscient being, God has made some really lousy earthly staffing decisions. -- John Cole ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Correct method for compressing a power spectrum
On Tue, Mar 10, 2009 at 11:10 AM, Marcus D. Leech mle...@ripnet.com wrote: OK, so I decided to use the averaging method, rather than the maximum method. It produces reasonably good looking plots: http://www.science-radio-labs.com/files/spectral_example.ps True, not bad. One surprise, though -- what's that notch around 1420.5? It definitely has an averaged look to it -- much like what you'd expect from time smoothing and not frequency necessarily. One thing that low-level heuristic grass might give you is a feeling that the relatively flat segments are alive at least, sort of like comfort noise during vocoder silence. If that matters. Frank -- For an omnipotent and omniscient being, God has made some really lousy earthly staffing decisions. -- John Cole ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Correct method for compressing a power spectrum
On Sun, Mar 8, 2009 at 6:13 PM, Marcus D. Leech mle...@ripnet.com wrote: Seems to me that if I have 4000 1Hz-wide bins, I should sum them to give me the total power in a single bin that represents the same amount of bandwidth. But is it more subtle than that? As usual, yes and no. If you're concerned with statistical hygiene, then the mean (averaging over multiple bins) is defensible. And if you wanted to add a dimension to each reduced output bin, like color, you might want to throw in the variance within each set of sub-bins contributing to the average. The most robust estimator would be the median, though, probably -- the exact midpoint between the lowest and highest values in each set of sub-bins. However it sounds like what you're going for is a kind of compression that's lossy but optimizes for visual properties, not statistical robustness. That's usually highly non-linear and very subjective. In that case, why not pick what just looks good on your data? The algorithm that John Ackermann suggests is likely to be as good as anything else. Frank -- One, two, three, four, monsters walking 'cross the floor... -- Leslie Feist ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Correct method for compressing a power spectrum
On Mon, Mar 9, 2009 at 8:49 AM, Bob McGwier rwmcgw...@gmail.com wrote: Let [B1, B2, B3, B4, ... BN] be powers of five adjacent bins. Put them in rank order [R1, R2, R3, R4, ... RN] If N is even, the rank order mean is (R_(N/2) + R_/(N/2 +1))*0.5. If N is odd, the rank order mean is R_(N/2 +0.5) Here the rank-order mean *is* the median: the quantile value for #quantiles = 2. But I still see a problem: I suggest that in order to prevent scalloping of a swept tone across this algorithm or any other like it, that some bin in the lossy compression set of bins must ALWAYS be forced to take on the large of the power spectrum otherwise your alternative min/max/min/max might jump up and down as you sweep a tone through it. Or did I miss something? Most surely. Why not some kind of VQ-codebook based on deltas between successive frames? Apart from the amount of the research required to build it, of course... Neural net fans invited to take this on also! ;-) Frank -- For an omnipotent and omniscient being, God has made some really lousy earthly staffing decisions. -- John Cole ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Correct method for compressing a power spectrum
On Mon, Mar 9, 2009 at 1:08 PM, Bob McGwier rwmcgw...@gmail.com wrote: So, pardon me but, is this a pretty picture exercise or a real detection problem? If it is a detection problem, then you might as well just compress to the largest value in the bins to be pushed together so you assure that your threshold is exceeded when it should be. If it is a pretty picture problem, just prevent scalloping by any old heuristic, just make it as fleet of calculation feet as possible and throw in some pretty grassy stuff to make it look nice. Amen to that. To say so is not to dismiss the level of art required by heuristic grass, however. That's pretty much what MELP adds, and it makes a world of difference to the user. Frank -- For an omnipotent and omniscient being, God has made some really lousy earthly staffing decisions. -- John Cole ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [dttsp-linux] Intel ATOM WHOOAAAAA Nellie
On Thu, Feb 19, 2009 at 11:17 PM, Bob McGwier rwmcgw...@gmail.com wrote: ...HOWEVER, for those folks who want to build an small board computer for supporting the Flex family of firewire devices, the Intel motherboards are your only choice. You need the PCI slot to get the firewire support... For DttSP apps it's not a real choice. You will need a PCI slot, either for FireWire audio like the Edirol FA-66 or the PreSonus FireBox, or merely for some other halfway decent soundcard like the M-Audio Delta 44. This is a required configuration for effectively using sdr-shell, sdr-core, and the sdrTEC board, for example. A reference Linux implementation for this combination, with a cost of around $800US total for the RF front end + computer, is about ready to go up on CGRAN. The FireWire+Flex option is moot for dttsp-linux and vrk, but the other FireWire/PCI addons are critical. DttSP apps using the USRP1+GNU Radio are fine. USRP2 is an open question, for now. Short form: for dttsp-linux and general RF hardware, the Atom 330 is unquestionably the more utilitarian alternative. This is especially so when, given Nvidia's history regarding Open drivers, Linux support for ION is very uncertain in the near term (6-9 months). 73 Frank AB2KT -- Some people are like slinkies...not really good for anything, but they still bring a smile to your face when you push them down a flight of stairs. -- Anon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Filterbank stuff
On Fri, Feb 13, 2009 at 10:28 AM, Marcus D. Leech mle...@ripnet.com wrote: So, just feed the audio as if it's a baseband signal right into the USRP? Or do I need to put it through an SSB modulator first? You'll want to modulate it. WSJT gives real output. Of course modulating here means not much more than complexifying and filtering, since WSJT will do the tuning on its own. BTW if sample rates do turn out to be an issue with JACK, you can always use the dummy driver simply for connecting your GR program and WSJT. Dummy will take whatever sample rate you tell it, within reason. You can't monitor the signal by ear that way, but in this case, big deal. Frank -- ...we ain't going to hell, we're going to the rebel side of heaven. -- Langhorne Slim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Filterbank stuff
On Thu, Feb 12, 2009 at 7:59 PM, Marcus D. Leech mle...@ripnet.com wrote: I'm looking into this for a friend who wants to use his USRP2 for EME. I'll see if I can do something JT65-like (or exactly that!) in Gnu Radio. You should be able to just use it via portaudio on top of JACK, talking to the USRP through GNU Radio. There may be some sample rate issues that need to be solved in GNU Radio -- last time I looked, WSJT only pretended to handle variable sample rates. Frank -- ...we ain't going to hell, we're going to the rebel side of heaven. -- Langhorne Slim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Filterbank stuff
On Thu, Feb 12, 2009 at 11:15 PM, Bob McGwier rwmcgw...@gmail.com wrote: WSJT uses portaudio directly and that can talk to jack through its portaudio host if jack has been compiled with that support in it. Ideally, yes. However, unless some of the WSJT code has been rewritten, despite appearances, you're limited to using the WSJT default sample rate. Sample rate choices made in the audio subsystem aren't actually propagated correctly through the entire DSP chain. This causes problems with JACK in a number of situations, depending on which driver (ALSA, FFADO, etc.) JACK itself is using. Frank -- ...we ain't going to hell, we're going to the rebel side of heaven. -- Langhorne Slim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_siggen.py underruns
On Wed, Feb 11, 2009 at 6:03 PM, Eric Blossom e...@comsec.com wrote: Are you really trying to use the Gaussian PRNG? If so you'll have to fix it. If you look at the code for it, you'll see that it samples a distribution until it gets something it likes. A classical reference for fast generation of random numbers under various distributions is Lorrain, D. 1980. *A Panoply of Stochastic 'Cannons'.* Computer Music Journal 4(1) The common shortcut to Gaussian random sequences is to sum some number of uniform variates, usually 12, for each Gaussian output. Frank -- When small birds sighed, she would sigh back at them. -- Theodore Roethke ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CGRAN downtime
On Tue, Feb 10, 2009 at 11:12 PM, George Nychis gnyc...@cmu.edu wrote: Due to this, I could make our base SVN URL: https://www.cgran.org/ ...instead of: https://www.cgran.org/cgran/ But, this would mean that everyone would need to re-checkout anything outstanding. I think our biggest user set is DttSP. Bob, Frank? George -- Please go ahead and make the change. It's sensible and only hurts once :-) Also, there's a fair bit of new stuff coming in the next few weeks, so better now than later. Many thanks for providing such an excellent home. Frank -- When small birds sighed, she would sigh back at them. -- Theodore Roethke ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Intel Atom is NICE.
On Sun, Jan 11, 2009 at 3:00 PM, Bob McGwier rwmcgw...@gmail.com wrote: IF ANYONE CAN SHOW ME WHERE IN THE INSTRUCTIONS IT SAYS THIS IS A TWO PASS PROCESS OR WHERE DURING THE COURSE OF DOING THE FLASH IT SAYS THIS IS A TWO STEP PROCESS, I WOULD BE PLEASED TO BE TOLD I AM BLIND. Well, sort of. I'd posted a note about this somewhat in advance of yours, with a link to the PDF directions. It's mentioned there that the update takes a fair amount of time, at least 5 minutes, and the process isn't complete if it hasn't taken that long. Nothing explicit about a two-step process, though. Quite misleading. 73 Frank AB2KT -- Designing software that works on the assumption that everyone will have your client is like designing a society on the assumption that everyone will just be honest. -- Paul Graham ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [dttsp-linux] Fwd: Ubuntu 8.10
8.10 seems to be delivering equal or better performance to 8.04 except in two areas: (1) Java (2) hardware functions that need proprietary binary drivers (video, wireless). 73 Frank AB2KT On Sun, Nov 23, 2008 at 12:41 AM, n4hy [EMAIL PROTECTED] wrote: Leif runs Linrad and is a code efficiency freak. He hand codes EVERYTHING in his system that is a hot spot. This note bears paying attention to. -- Forwarded message -- From: Leif Asbrink [EMAIL PROTECTED] Date: Nov 16, 8:50 pm Subject: Ubuntu 8.10 To: Linrad Hi All, The latest version of Ubuntu is extremely CPU hungry when used with X11. Just running the system monitor loads the CPU with 20%. Xorg, the X11 server uses 15% and the system monitor uses 4%. Debian unstable which has the same system monitor uses 6% for Xorg and 4% for the system monitor. Debian stable uses the older system monitor which is far less CPU hungry. It moves the curves horizontally step-wize and uses 4% for Xorg and only 1% for the monitor itself. The above numbers are for a 2.6GHz Pentium IV. The very high load caused by the X11 server may make it necessary to increase the output delay margin and to decrease the max DMA rate. I would recommend Ubuntu 8.04 or any other Linux distribution if you want to run Linrad under X11. In case you love Ubuntu 8.10 for some reason, download svgalib1925-1.tbz from here:http://www.sm5bsz.com/linuxdsp/install/ svgainst.htm http://www.sm5bsz.com/linuxdsp/install/svgainst.htm The modified svgalib-1.9.25 package will compile under Ubuntu 8.10 Press Ctrl Alt F1 to get into terminal mode and run Linrad from there (do not forget sudo.) Ubuntu 8.10 runs at full speed With svgalib in terminal mode:-) 73 Leif / SM5BSZ Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/dttsp-linux/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/dttsp-linux/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ -- Nicolas Sarkozy: Oui, mais voulez-tu finir comme Bush? Vladimir Putin: Ah -- tu avez marqué un point là-bas. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated BBN 80211 code?
On Thu, Oct 16, 2008 at 10:02 AM, Eric Blossom [EMAIL PROTECTED] wrote: The understanding, then, is that it's explicitly OK for non-FSF-assigned code to go into dev branches of the official repo. That's news to me, and I'm glad to have it cleared up. Nope, sorry for the confusion. Code in gnuradio.org should be GPLv3 and assigned to FSF. Using code outside of the repo is fine as long as the outside code has a license that is compatible with the GPLv3. http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses You just reinforced the confusion. I say, The understanding, then, is that it's explicitly OK for non-FSF-assigned code to go into dev branches of the official repo. This branch: http://gnuradio.org/trac/browser/gnuradio/branches/developers/brickle *is*, obviously, on gnuradio.org. However, you then say: Code in gnuradio.org should be GPLv3 and assigned to FSF. I invoke the law of the excluded middle and claim that both assertions -- non-FSF-assigned is OK, and Code...should be...assigned to FSF -- cannot hold at the same time :-) What am I missing? Frank -- I have taken the stand that nobody can be always wrong, but it does seem to me that I have approximated so highly that I am nothing short of a negative genius. -- Charles Fort ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated BBN 80211 code?
On Wed, Oct 15, 2008 at 9:11 AM, Greg Troxel [EMAIL PROTECTED] wrote: So I think the top-level question is whether CGRAN is for code that isn't assigned. I think that's the only thing that makes sense; people with assignments can more or less work directly in the gnuradio.org repository. Maybe there are some overlapping issues here. Suppose, for example, I have some code that's more Cognitive-Radio-related than Software-Defined-Radio, really. It uses Orange http://www.ailab.si/orange, which is GPL but not assigned to FSF. At least for now it can't go into the GNU Radio tree. Probably it never will. It's also true that this (my) code is experimental and provisional. It's nothing more than a steppingstone. (The obvious place to put it would be a developer branch, but that's part of the tree.) Perhaps I doubt whether, in its current form, it *should* go into the tree. But that's no reason not to make it visible and easily accessible, if only as a scaffolding for later code destined for the tree. There is also some quantity of code which is useful and usable right now, but which doesn't currently fit well with the unified installation procedure for the GR tree. I'm thinking here primarily of Linux audio subsystem code that uses scons. It seems obvious there has to be a place for GNU Radio code that's GPL but will not be assigned to FSF, with certainty. I believe there should also be a place for code whose status is *uncertain* -- in short, a place with minimal obstacles to publishing early and often. Frank -- I have taken the stand that nobody can be always wrong, but it does seem to me that I have approximated so highly that I am nothing short of a negative genius. -- Charles Fort ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] alsa_sink busy
You might need to set your default ALSA device to be the virtual PulseAudio device. See for example http://www.pulseaudio.org/wiki/PerfectSetup#ThirdPartyApplications Frank On Thu, Sep 25, 2008 at 10:01 AM, Dimitris Symeonidis [EMAIL PROTECTED]wrote: I just noticed that, if listening to an mp3 while trying to run a gnuradio script that outputs audio, I get the error message: audio_alsa_sink[plughw:0,0]: Device or resource busy This appears both with ok_to_block=True and False… I'm using Ubuntu 8.04.1 Should it not be possible to do both? Any ideas? Dimitris Symeonidis If you think you're too small to make a difference, try sleeping with a mosquito! - Amnesty International ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- To me faith means not worrying. -- John Dewey ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP vs alternatives
On Thu, Sep 25, 2008 at 12:57 PM, Chris Albertson [EMAIL PROTECTED] wrote: Many people are using other software with softrock hardware. However I think most of that other software is Dttsp based rather then gnuradio based. The hardware is designed to be connected to a sound card and outputs I and Q over a pair of analog outputs. So what ever software you use it would not have to talk to the softrock, it would talk to your computer's audio subsystem. Connections to the SR are all analog Most of the other software definitely uses DttSP, either bare (on Linux or OS X) or inside PowerSDR (Windows). It does the job pretty well, if I say so myself, speaking as one of the authors, along with Bob McGwier, N4HY. But messing around on the inside is not for the faint-hearted and the learning curve is steep. The design is determined overwhelmingly by the need for minimal latency in full-duplex, together with tight asynchronous control of the lowest-level parameters. It isn't and wasn't ever meant for experimentation. You need to have a pretty clear idea of where you're going before you ever lift the hood to change something. If what you want is to get your fingers into the software, assemble your own soft radios, you definitely, positively, absolutely want to use GNU Radio as the software backend. That's one of the things it's for and it does the job wonderfully. Once you get the hang you can put together a new application in minutes. I myself am right now in the process of developing some new features for DttSP and am prototyping them all in GNU Radio first. A decent soundcard is a must, though. Frank The kit costs only $8 for the receiver and even with it's use of SMD is not hard to build. On Thu, Sep 25, 2008 at 6:55 AM, Paul Miller [EMAIL PROTECTED] wrote: Because of the very high cost of the USRP, I'm looking for alternatives. I found this gadget and I wondered if GNUradio is setup to use devices like this: http://www.amqrp.org/kits/softrock40/ It appears to have its own software, but I'd rather get it to work with gnuradio if it's possible to do so. Am I better of adapting the software they provide? Am I better of trying to find the money for a USRP? I don't know enough to even know how to approach these questions. It seems like everything I read in SDR turns into a very deep rabbit hole. -- If riding in an airplane is flying, then riding in a boat is swimming. 107 jumps, 43.5 minutes of freefall, 83.4 freefall miles. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- = Chris Albertson Redondo Beach, California ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- To me faith means not worrying. -- John Dewey ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] python editor
Emacs. Frank On Tue, Sep 2, 2008 at 12:20 PM, Dimitris Symeonidis [EMAIL PROTECTED]wrote: I wanted to ask the list, what editor are you using for python? Gedit? SPE? Editra? something else? I am still trying to figure out what works best for me, and hearing from the list would be helpful... Thanx -- Dimitris Symeonidis If you think you're too small to make a difference, try sleeping with a mosquito! - Amnesty International ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Computer Science is no more about computers than astronomy is about telescopes. -- E. W. Dijkstra ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atan2 problem
arctan = [math.atan2(x,y) for x in x_hyd_filter for y in y_hyd_filter] ? Frank On Tue, Sep 2, 2008 at 12:28 PM, Dan Halperin [EMAIL PROTECTED]wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 2, 2008, at 8:58 AM, Brian Padalino wrote: On Tue, Sep 2, 2008 at 11:51 AM, Engin Karabulut [EMAIL PROTECTED] wrote: hi all, I have two signal which is float and I want to use atan2 fuction like this, self.arctan = math.atan2(x_hyd_filter, y_hyd_filter) but gnuradio gives error given below, ... self.arctan = math.atan2(x_hyd_filter, y_hyd_filter) TypeError: a float is required. In your opinion what is the problem? Are you sure x_hyd_filter and y_hyd_filter are, in fact, floats? If you're trying to do arctan on 2 __streams__ of floats, you can't use the Python math.atan2 function to do this operation -- you need a gnuradio processing block. I'm not even sure we have such a block yet, you might have to write it yourself. - -Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAki9aZAACgkQy9GYuuMoUJ6HbwCfYFLDiXARaiz0mR+4/Zt4wwdC ZiMAnRsLLldSLsbfM2Eq5X020LccWgI9 =jU0p -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Computer Science is no more about computers than astronomy is about telescopes. -- E. W. Dijkstra ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] boost 1.35
In /opt/boost_1_36_beta on 8.04 with kernel 2.6.24-21-rt. ./configure --with-boost=/opt/boost_1_36_beta --enable-doxygen --no-create --no-recursion Frank On Fri, Aug 22, 2008 at 2:37 AM, Firas A. [EMAIL PROTECTED] wrote: Hi, Has anyone been able to install boost 1.35 or 1.36 on Ubuntu OS system? Regards, Firas -- View this message in context: http://www.nabble.com/boost-1.35-tp19100103p19104236.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- All who think cannot but see there is a sanction like that of religion which binds us in partnership in the serious work of the world. -- B. Franklin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using USRP/GNURADIO Commercially
On Sun, Jul 20, 2008 at 7:49 AM, Eric Blossom [EMAIL PROTECTED] wrote: You should seek professional legal advice and be sure that you understand the terms of the license. The problem is finding a lawyer who truly, actually understands the GPL. They're both pretty busy these days. ;-) Having been through this drill, I can tell you that IP lawyers generally do *not* know squat about Open Source issues, and hence will tell you to stay away from the GPL in toto. Those who claim expertise are in fact telling you they'd be happy to take your money to spend the time learning what they're implying they already know. Frank -- Travelling by airplane in the US is nothing more than mass training of Americans to the requirements of the coming police state. The whole point is to make you learn to acquiesce without question, en masse, to completely absurd directives by dull functionaries wearing uniforms. -- Atrios ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using USRP/GNURADIO Commercially
On Sun, Jul 20, 2008 at 3:30 PM, Michael Ossmann [EMAIL PROTECTED] wrote: ...An educated lawyer is going to be able to provide insights into how a particular license or contract affects his or her client, even after a single reading, that a layman would not notice... The complaint is aimed at a general tendency of the lawyers I've actually dealt with, repeatedly, in connection with dual-licensing issues involving code of my own already under GPL. That's around 3/4 dozen attorneys. Of that group, only one was candid enough to admit up-front to ignorance concerning the GPL. The remainder basically engaged in elaborate handwaving. (Full disclosure: some of them were on the *other* side of the negotiation, and not doing their clients any favors.) The problem isn't not knowing, the problem is dissembling about not knowing. The point is, caveat emptor. Frank -- Travelling by airplane in the US is nothing more than mass training of Americans to the requirements of the coming police state. The whole point is to make you learn to acquiesce without question, en masse, to completely absurd directives by dull functionaries wearing uniforms. -- Atrios ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using USRP/GNURADIO Commercially
On Sun, Jul 20, 2008 at 3:09 PM, Rudy Moore [EMAIL PROTECTED] wrote: Okay you got me. But answer me this: Why did we (the gnuradio experts) select a license that does not provide a clear answer to Matt's question? The answer *is* clear. It's not even very complicated. Nevertheless, for one's own protection, the validation of that claim should come from a licensed attorney. Just be very sure the attorney actually knows the answer. Frank -- Travelling by airplane in the US is nothing more than mass training of Americans to the requirements of the coming police state. The whole point is to make you learn to acquiesce without question, en masse, to completely absurd directives by dull functionaries wearing uniforms. -- Atrios ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Standardized indentation?
Some incantation like indent -br -brs -cdw -ce -cs -hnl -i2 -lp -nbad -nbbo -nprs -psl -saf -sai -saw -nss -npcs works well for most C-ish code. Substitute -i4 if you don't use graduated lenses in your glasses. Frank On Thu, Jun 5, 2008 at 6:00 PM, Josh Blum [EMAIL PROTECTED] wrote: Steven Clark wrote: I noticed that many gnuradio files (gmsk.py for example) contain an unholy mix of spaces and tabs for indentation. Is there any easy way to standardize our indentation? Many text editors can make it so hitting tab creates 4 spaces instead of the tab character. You can fix these files with the expand tool. http://webtools.live2support.com/linux/expand.php (I like 4 spaces per indent, what about you guys?) Raw tab characters for me. You can configure your editor to display the tab as any width. And you can always convert the code to spaced based indentation with expand. -Josh http://www.python.org/dev/peps/pep-0008/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- The only thing we have to fear is whatever comes along next. -- Austin Cline ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio C++ engineer wanted
On Jan 31, 2008 12:52 PM, Jeff Brower [EMAIL PROTECTED] wrote: Maybe you're right, it's inevitable. But I don't think it helps the cause of GNU radio at government agencies... I for one would be far more interested in using gnuradio to *spoof* the surveillance. That would really endear the gnuradio community to the agencies, wouldn't it? ;-) Frank -- The only thing we have to fear is whatever comes along next. -- Austin Cline ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] anyone implement the Raleigh fading model / multi-path?
There is a standalone, offline HF channel simulator in C for Linux, available through http://www.johanforrer.net/SIMULR/. The code is GPL 2. It might give a head start to anybody developing a gnuradio block. 73 Frank AB2KT On Jan 24, 2008 12:34 AM, George Nychis [EMAIL PROTECTED] wrote: Lord Rayleigh called, he wants his fading model in GNU Radio :) In all seriousness, has anyone implemented the Rayleigh fading model in GNU Radio and just not released it? It's kind of a shot in the dark, but from reading the list people seem to do extensive work in GNU Radio and not contribute it back to the project. I'm hoping this might be one of those cases. If not, anyone interested in possibly tackling it with me? Caveat: my EE knowledge is low but growing. Benefit: my understanding of GNU Radio conventions is high :) ... or so I like to think! In terms of variables in the system, it would be beneficial to specify the multipath time (time between received impulses), and the number of impulses. This allows the end user to vary the severity. Well, if anyone is interested in hopping in the boat, let me know and we can discuss it. I know it is by no means a trivial task, which is why I'm asking for help, but the benefits of such a model in the project in my opinion would be great. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- The only thing we have to fear is whatever comes along next. -- Austin Cline ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OLPC - next generation with SDR?
John -- Have you looked at all at the Siren board? It's part of the HPSDR and Suitsat II projects: a low-power, low-cost SDR engine using the dsPIC33F embedded controller from Microchip. The current design uses 10 MHz RF in and out, and the QSD and QSE for complex sampling and excitation. There is also an onboard TI stereo codec for I/O in the audio range. Digital data can be synchronously imported and exported over one or more SPI buses. It's not perfectly general. Many of the algorithms we'd like to run on it need to be tailored to the hardware in a way that's more constrained than we'd like in general. That notwithstanding, it should be capable of handling 48 kHz bandwidth, and muxing and demuxing several channels within that span. So far, as far as I know, only prototypes and first-gen boards are in circulation. The power consumption is already very low; there's a lot of board real estate eligible for shrinking as well. Frank On Dec 21, 2007 11:02 PM, John Gilmore [EMAIL PROTECTED] wrote: The thing does appear to have sufficient horsepower to do some DSP. ... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Removing '.py' from system path installed Python scripts
Greg Troxel wrote: ... Given that new versions of python can be installed and made default (meaning invoked as 'python'), it's necessary to bind the scripts to the same version of python used to build .so modules and install .py files in site-packages... I'm curious -- really just curious -- why not create a chroot environment for gnuradio? Or, where the kernel and the CPU allow, a fully virtualized stable OS install simply for gnuradio? Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] For those who are keeping up on various cognative radio projects.
John Clark wrote: Here's a paper written on a research project on the topic. http://research.microsoft.com/research/netres/publications/lanman07.pdf Stand back in awe, my friends. Microsoft has innovated *both* spectral activity detection *and* the transverter. Yeesh. Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb parameters
Hsin-mu Tsai wrote: I didn't change the nice value (with top or nice, etc.). I thought enabling the real time setting (gr.enable_realtime_scheduling) in the script will automatically change priority to (max + min) /2. I don't actually know what the gr.enable_realtime_scheduling function does; you're probably right. On the other hand I'm not sure that effect is sufficient to get what you want. As I understand it, what the low-latency/realtime scheduling provide are more frequent opportunities for high-priority processes to run. It's sheer speculation but I wonder whether your gnuradio process isn't competing with something else at the same priority, so that giving your process a slight edge in priority might take care of the problem. I spent a great deal of time a couple of years ago trying to balance the JACK daemon against the X server, without much success and a with lot of frozen mice. It's only the most recent patches that really give solid low-latency performance with the current audio subsystems. The performance is very good now, though. are 'priority' and 'nice' the same thing? Niceness is an increment to the priority value. Nice-ing in the negative direction improves the priority. -- Managing developers is like herding cats. Managing volunteer developers is like herding bats, in the dark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb parameters
Hsin-mu Tsai wrote: This is my limits.conf @usrp - rtprio 90 @usrp - memlock 2048000 @usrp - nice-19 The user running the code is in usrp group. I'm running kernel 2.6.20-0119.rt8 from http://people.redhat.com/mingo/realtime-preempt/. (Ingo Molnar's realtime preempt kernel) That all looks well-formed. Are you then running the gnuradio process with an explicit nice value? Frank -- Managing developers is like herding cats. Managing volunteer developers is like herding bats, in the dark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb parameters
Hsin-mu Tsai wrote: I don't think my problem is related to the CPU. Here are my reasons: 1. I tried overclock my CPU from 2.6 GHz to 3.2 GHz in order to see if an increase of CPU performance can decrease the packet loss ratio. However, no significant change was observed. And I'm using Intel Core 2 Extreme QX6700 at 2.6 GHz, which is one of the most powerful CPU we can get currently. Have you tried running the latest low-latency kernel, with modified settings in /etc/security/limits.conf? Frank -- Managing developers is like herding cats. Managing volunteer developers is like herding bats, in the dark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A problem with ALSA
Check the running processes. If there are any sound daemons such as esd running, kill them and give it another try. Frank ??? (Yuankai Ge) wrote: Hi, I'm also tring to making some sound out of the USRP box, however, even test with the most simple script to generate a dial tone given by http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html the alsa seems can not work as expected. I could listen to music successfully under my Ubuntu 7.04 and gnuradio-alsa is successfully configured and compiled. I've checked some old maillist record to solve this problem but nothing helps. And I'm not using any music player at the same time when test the python script (Maybe my Ubuntu occupies it? I don't know) Hope here someone encountered the same newbie question as mine~ ^_^ === audio_alsa_sink[hw:0,0]: Device or resource busy Traceback (most recent call last): File ./dial_tone.py, line 20, in module fg = build_graph () File ./dial_tone.py, line 13, in build_graph dst = audio.sink (sampling_freq) File /usr/local/lib/python2.5/site-packages/gnuradio/audio_alsa.py, line 236, in sink return _audio_alsa.sink(*args) RuntimeError: audio_alsa_sink ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Managing developers is like herding cats. Managing volunteer developers is like herding bats, in the dark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [dttsp-linux] Re: Feisty Fawn updates
Eric Blossom wrote: Is your udev usrp rule still in place? Aha, that's a very good question. I'll be able to check this out yet today myself. Which kernel comes with Feisty Fawn? 2.6.29-15 Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [dttsp-linux] Re: Feisty Fawn updates
/etc/udev/rules.d/10-usrp.rules
which sez
ACTION==add, BUS==usb, SYSFS{idVendor}==fffe,
SYSFS{idProduct}==0002, GROUP:=usrp, MODE:=0660
Frank
On 4/23/07, Bob McGwier [EMAIL PROTECTED] wrote:
I will profess complete ignorance. What udev rule?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Polymorphic Computer:
Martin Dvh wrote: Typically, a chip is optimally designed either for front-end signal processing or back-end control and data processing, The MONARCH micro-architecture is unique in its ability to reconfigure itself to optimize processing on the fly. MONARCH provides exceptional compute capacity and highly flexible data bandwidth capability with beyond state-of-the-art power efficiency, and it's fully programmable. ...and it GENERATES more power than it CONSUMES!!! ;-) Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Software stopping of runaway realtime processes?
Dan Halperin wrote: I can't think of what else to try... /etc/security/limits.conf? Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Playstation 3
Robert McGwier wrote: They are $599 at my local Target. So much for bargains at Costco. Eric A. Cottrell wrote: I was at my local Costco tonight and noticed they have the 60GB PS3 for $699. I almost bought one but decided to check a Costco in NH first. $699 gets you one from Terrasoft with Yellow Dog Linux installed. Mine shipped this afternoon. Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ALSA/jack
For those of you using ALSA and jack there may be immediate relief.
The ALSA jack plug slave PCM device and the aoss dspN devices
appear to work together without incident. So, if you put the
following in $HOME/.asoundrc:
pcm.jackplug {
type plug
slave { pcm jack }
}
pcm.jack {
type jack
playback_ports {
0 alsa_pcm:playback_1
1 alsa_pcm:playback_2
}
capture_ports {
0 alsa_pcm:capture_1
1 alsa_pcm:capture_2
}
}
pcm.dsp0 {
type plug
slave.pcm jack
}
you can run any ALSA-based program with jack using 'jackplug' as
the device. You can run an OSS-based program under jack via oss.
For example, the digital mode program gmfsk can be run with
aoss gmfsk
This doesn't solve all jack ills, but it does satisfy a number of
important cases without drastic rewriting or kludging.
Frank
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Heard FM on the basic RX hooray!
Johnathan Corgan wrote: On Fri, 2007-01-05 at 13:35 -0500, M. Ranganathan wrote: ...I have the worlds most expensive FM radio finally That's okay, I sometimes listen to the local AM BCB on my Icom PRO II HF transceiver--that's a (US) $2K+ equivalent of a crystal set :-) It has the nicest display of any crystal set you ever saw, however! Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interfacing GNURadio with other software
Eric A. Cottrell wrote: Is there a loopback audio device, maybe using Jack? This is exactly the sort of thing jack was designed to do. You can think of jack as providing virtual patchcords among the inputs and/or outputs of all the audio applications you have running. What you have to be aware of is that all the applications using jack have to share a common sampling rate and fundamental buffer size. An individual app that uses a different rate or internal buffer size is reponsible for rebuffering and resampling. Jack provides lock-free ringbuffers to smooth out things like that. In addition, each link in a chain of jack-connected applications increases the latency of the final output by one buffer. If you want to minimize total latency, it's best to put as many processing steps as possible into a single jack application. For that reason, some algorithms are better realized as plugins rather than standalone applications. The plugin API's are well-developed and straightforward, and there are a number of existing applications which act as little more than skeletons for plugins. 73 Frank AB2KT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Squelch developments
Johnathan Corgan wrote: Good catch. Would a linear ramp from 0.0 to 1.0 as a multiplier against the audio stream, applied over a user specified number of samples, be sufficient? Yes, although half a cycle of a raised cosine is almost as easy, and analytically correct. 73 Frank AB2KT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] EDACS Control Channel
If you poke around the net, you will probably be able to find the source for an old DOS program that decodes EDACS control channel. It's called Trunk Tracker. I also have original source for an EDACS control channel decoder of my own from a number of years ago. Unfortunately all that remains is a hardcopy, but if you want, I can scan and provide that, probably. Both of these assume that the demod and bitsync have been performed already and are being fed to their inputs as binary streams. Frank Ryan Pape wrote: Finally having all the pieces in place I need, I want to use the new GMSK code to decode an EDACS trunked radio control channel. Given my rudimentary knowledge on the topic (and gnuradio in general) which (if any) of the examples present would be my best starting point given that I'm hoping to do this, even initially, right off the air with the TV RX? Some details at http://users.netropolis.net/maverick/scanners/edacs.htm for anyone interested. Most relevant snippet for the uninitiated: Modulation: It looks like GMSK (Gaussian Minimum Shift Keying) which is basically the same thing as two level FSK keying except that the data stream is passed through a low pass filter before modulating the carrier. This reduces the high frequency components allowing the control channel to fit within a 12.5KHz channel. Accordingly, a simple data-slicer circuit can be used to receive the control channel information. Baud Rate 9600 Baud Frame Sync Frame synchronization is achieved by sending the following 48 bit sequence: 000101010101010101010111000100100101010101010101 or 0x1712 Hexadecimal Data Frames After transmission of the frame synchronization sequence TWO data frames will be transmitted and then the whole cycle repeats ad infinitum. Each data frame is 120 bits long; this means 288 bits are transmitted in each cycle (2x120 bits for the data frames and 48 bits for frame sync). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] EDACS Control Channel
Rick Parrish wrote: I think Trunk Tracker is a trademark of Uniden. See http://www.trunktracker.com/ ... Yes, right, sorry. It's been awhile. Things to be wary of the code: It was written for Borland's Turbo-C compiler as a 16 bit DOS program. The size of a C int is 16 bits here. The program assumes direct access to an 8250 compatible UART. It installs it's own interrupt service routine. It uses the progammable timer-counter as a time-reference. IIRC the bitslicing code is separable from the decoding functions, and the 16-bit-itude isn't a huge obstacle. The hardest thing to get your mind around is the fact that the decoding algorithm uses the sync vector as a terminator, not a header. That is, it uses the sync vector of the (logically) upcoming frame to cue the decoding of the data from the current frame. There's a lot of UI goo also, but not too hard to ignore. The guts are pretty straightforward. Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL
Eric Blossom wrote: ... I ended up remounting the relevant filesystem as ext2 to avoid the problem...If we never go to the disk, it might not matter at all. ... It's been a long time since I looked at these pages: http://ardour.org/requirements.php http://ccrma.stanford.edu/planetccrma/software/tunesystem.html however they're very informative and probably required reading. The key point in connection with what we've been grousing about today is this. The essential thing isn't altering the scheduler. It's getting the scheduler to run often enough. Also I haven't been able to track it down but the other (d'oh) point is, if you're streaming to disk, why write to a journaling filesystem? They seem to be big fans of external FireWire drives for this kind of thing. 73 Frank AB2KT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL
Eric Blossom wrote: Using LD_ASSUME_KERNEL=2.4.19 effectively forces the old (pre-NPTL) behavior, which means that acquiring an uncontested mutex requires a trip to the kernel. I believe it also means that mutexes won't work in shared memory across process boundaries. Those seem like total losers to me... This adds up to: futexes don't work (yet). Is that right? I'm still confused about a couple of things. On one hand the holy grail appears to be getting the number of frames in a jack buffer down to 64 so as to minimize the roundtrip latency. On the other hand you want to eliminate xruns. They aren't the same by any means. It's not clear that minimizing roundtrip latency means much when you're using DSP buffers of 512 frames or more. By the same token, in what I've observed, the chief culprit for the xruns is the X window system. There is a very delicate balancing act going on in the process priorities between the audio subsystem and the video subsystem. I'm not convinced that running SCHED_FIFO is going to routinely enable the audio subsystem to slide in under the video action under all circumstances. Bottom line, it hasn't actually been proved that running SCHED_FIFO will squash the existing latency and continuity problems, so I'm not at all sure much is missing without that capability. 73 Frank AB2KT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: gr-audio-jack - mono only?
Stephane Fillod wrote: The fact the port names of the jackified alsa application (ie. the GR app) are not known before runtime is one drawback. The name is derived from application name, PID, whatnot. Maybe I haven't found yet the option to specify it through alsa manipulators. I believe the patchbay in qjackctl is capable of finding the jack ports using regexes. 73 Frank AB2KT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Thread-Safe Blocking?
Robert McGwier wrote: ...A sound system callback wants to feed and be fed and never get blocked. When it has new data, it should issue a semaphore release on the dsp/data processing system... To generalize this just a very little bit: any sort of mechanism will do, that will let the DSP processing block until the arrival of new data from the audio subsystem. We happen to prefer semaphores when using pthreads, but that's entirely because the alternative under pthreads would be a combination of mutexes and condition variables. The alternative would mean more lines of code to accomplish exactly the same effect as semaphores. For uniformity we also use semaphores to guard critical sections, since there's no real overhead incurred over mutexes. Along the same lines, where there are native blocking message queues, or an attractive library implementation like Eric is providing, that might be an even better choice than semaphores. The basic point is that barriers or mutexes are not rich enough on their own for the callback/client DSP processing model. Some additional scheduling mechanism is necessary. It's most sensible to take advantage of whatever the OS or application environment provides for that purpose. If you're slightly crafty the implementation details will be hidden behind an opaque API layer anyway. Frank AB2KT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FFT of FFTs
Eric Blossom wrote: Once you've got your individual streams of signals, for each one I would compute an estimate of whether it is occupied. Good suggestions. Elaborating on this a little, you might consider taking differences of successive magnitude or power spectra. If you're actually looking for periodicities in the onsets and releases, the resulting positive and negative pulses are very easy to track. This is a standard technique for first-order activity detection in spectral measurements. Another productive technique is to take the wavelet transform of the magnitude, power, or difference spectrum, especially when the signals of interest are smeared over several bins. In this case you are looking for large wavelet coefficient magnitudes in the dilation region of the wavelet transform that corresponds to the spreading bandwidth in the original spectrum. There is yet another arsenal of methods to throw at this problem if you are in a position to keep a full tableau of past spectra in three-dimensional form. For example, a conventional histogram equalization on such a tableau of past spectra is quite effective at bringing activity stripes out of the noise, and there is a robust likelihood score comparing before- and after-equalization densities. But that's really getting ahead of the subject... Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio/usrp (almost) working / IIR filter design code
Eric Blossom wrote: There are at least two existing packages we might want to use: libfilth and part of scipy. gmeteor is also worth a serious look. It's currently embedded in guile; a Python embedding would be very natural. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] *much* faster filtering --- plus vhf mountaintopping
James Cooley wrote: ...I'm sure there's a way to come up with a compression scheme that's tailored to the sort of sample data we see... A topic for a dissertation if ever there was one :-) In the general case, you're going to have to work hard to beat Ziv-Lempel. You might improve the performance somewhat by tweaking the parameters, but probably not a lot. The problem is that, as we know, in the general case, compressibility is basically the reciprocal of entropy. Ziv-Lempel depends on conditional entropy being lower, and thus compressibility being higher, through markovity. For most human-generated signals, the influence of the past (the markovity) decays exponentially towards the past. For general signals, the decay is very rapid, so there's going to be a lot of slop at the boundaries of the underlying markov model. There's also a theorem in there somewhere (due to Rissanen, I think) that says there's a limit on how much slop you can trim by tuning the adaptation. Where you might win is by picking different compression algorithms depending on the signals. For example, for voice-bandwidth channels, you might gain a lot from first converting to mu-law and then gzipping. And so on. For wide, densely-packed signals, you can probably forget it. The fact that they're densely packed means they're already high-entropy. Regards Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP and GnuRadio for OSX
FWIW the version of jack that runs on OSX appears to have matured quite a bit. PortAudio also has an OSX version, but given a choice, I'd bet more on jack. Matt Ettus wrote: Also, there is no audio support for OS X yet. I was under the impression that OS X offered OSS (Open Sound System) emulation, in which case our gr-audio-oss module would work. Can someone confirm this? If not, is there a good reference online about sound programming for OS X? Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Raw sample storage format
Is there some reason not to use a standard format like .au or .wav, seeing as either of these is supported in Python (wave.py and sunau.py)? Chuck Swiger wrote: At 12:38 AM 3/10/2005 +, you wrote: A standard header for data files makes a lot of sense. It sure does - as it is I put clues in the filename but that's very prone to human error. By the way, if anybody could use a DVD of raw samples I could mail some for a small paypal fee. No need to let lack of hardware stop any research. I just sent out a bunch of Amiga history DVD's to some classic collectors for $5 each (copied from a vhs tape). --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
