It's going to have to be part of UHD because a lot of programs I'm having
problems with are not using GNUradio, they just read from UHD. UHD guesses
on a lot of things ( device, sub-device, antenna, fpga image, fpga
frequency etc. ) when not defined in the program, currently it's up to the
program
On Thu, Dec 29, 2011 at 9:27 AM, Andrew Davis glneolistm...@gmail.comwrote:
It's going to have to be part of UHD because a lot of programs I'm having
problems with are not using GNUradio, they just read from UHD.
It seems like there is a lot of effort going into fixing problems with bad
Hi community,
This job opportunity was passed on to me to see if anyone out there is
looking for a position. If it's right for anyone, I'd say they are on this
list.
CTI is looking for individuals with a minimum of 3 years experience
programming in one of the following languages, C, C++, and or
I will, but a lot are unmaintained. This is something that UHD should do
anyway, and if it helps eliminate bad code then it's a win-win situation.
Theres really no reason a program should have to ask for and set every UHD
variable every time, this just adds a lot of clutter at the top of a
program
On Thu, Dec 29, 2011 at 5:15 PM, Andrew Davis glneolistm...@gmail.com
mailto:glneolistm...@gmail.com wrote:
I will, but a lot are unmaintained. This is something that UHD
should do anyway, and if it helps eliminate bad code then it's a
win-win situation. Theres really no reason a
On Thu, Dec 29, 2011 at 6:41 PM, Marcus D. Leech mle...@ripnet.com wrote:
**
On Thu, Dec 29, 2011 at 5:15 PM, Andrew Davis glneolistm...@gmail.comwrote:
I will, but a lot are unmaintained. This is something that UHD should do
anyway, and if it helps eliminate bad code then it's a win-win
On 29/12/11 06:48 PM, Tom Rondeau wrote:
I absolutely agree on this. We should definitely have a standard uhd
options parser that we can pull in to any program using a uhd device.
Excellent suggestion.
If we have/had one for GNU Radio before, I never used it or knew about
it. Having
