[Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread Lamar Owen
I have been successful in getting CentOS 7 onto an ODroid C2. This is the AArch64 version; armv8, 64-bit. I did run into a bug in build-gnuradio, however. The logic that determines the release number for CentOS/RHEL/SL 6 is flawed. The logic looks for the pattern '*elease*6*' in /etc/redhat

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread Marcus Müller
Dear Owen, I'd say the fact that you quickly eat up all your RAM is the best indication for it possibly being a good idea to cross-build for the Odroid on a PC. I've never actually did a cross-compilation for CentOS or Fedora packages (just for the same architecture), but that might just be the wa

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread mleech
Kyle Keen does GR+friends packaging for Arch/ALARM, and may have some insights. I've never tried to run build-gnuradio on ARM platforms, because the flags required vary from platform to platform, and not that many beginners are doing this for ARM platforms. YMMV, etc, etc. On 2016-04-28 12:19,

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread Sid Boyce
I haven't yet tried on the -C2 but I have built gnuradio on the ODROID-X and ODROID-U3. I found you need at least 4GB of swap or it silently dies during the build. 73 ... Sid. On 28/04/16 17:19, Marcus Müller wrote: Dear Owen, I'd say the fact that you quickly eat up all your RAM is the best

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread Anon Lister
Nice. I just did an x64 el7, so I only had to source build a few packages. I'd be curious to know what kind of performance you get on that platform. For deps, you may be able to harvest a list from the the work Geoff has been doing for the windows build scripts[1]. He also lists the versions used.

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread Lamar Owen
On 04/28/2016 12:44 PM, Anon Lister wrote: Nice. I just did an x64 el7, so I only had to source build a few packages. I'd be curious to know what kind of performance you get on that platform. I'll let you know. I am so far very pleased with the performance. Quad 2GHz ARMv8 cores with 2GB

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread Lamar Owen
On 04/28/2016 12:19 PM, Marcus Müller wrote: Dear Owen, I'd say the fact that you quickly eat up all your RAM is the best indication for it possibly being a good idea to cross-build for the Odroid on a PC. I've looked into this, but in this particular case I need to build the dependencies fir

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread Marcus Müller
Do you *really* want to use GRC on the C2? Doesn't make much sense – a flow graph designed on a normal PC works identically on your C2 (iff all the blocks are there, too). Same goes for anything that has to do with the GUI blocks – I don't really know your intended application, but as a gut feeling

[Discuss-gnuradio] 'Can't Avoid' fixes in current GNUradio 3.7.9.2

2016-04-28 Thread Lamar Owen
The EPEL repository for RHEL and its rebuilds currently has a slightly older version of GNUradio in the repo, a 3.7.5. I filed a bug in the EPEL bugzilla as an RFE to update to 3.7.9, but I got an answer back that it is EPEL policy (much like RHEL) to not update to latest version unless it 'ca

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread Lamar Owen
On 04/28/2016 01:28 PM, Marcus Müller wrote: Do you *really* want to use GRC on the C2? Doesn't make much sense – a flow graph designed on a normal PC works identically on your C2 (iff all the blocks are there, too). I'm doing the 'whole enchilada' for my own educational purposes. The produ

Re: [Discuss-gnuradio] 'Can't Avoid' fixes in current GNUradio 3.7.9.2

2016-04-28 Thread Marcus Müller
> I got an answer back that it is EPEL policy (much like RHEL) to not > update to latest version unless it 'can't be avoided.' It's not about not updating – it's about not breaking possible existing usage! RH has to make sure that software stays binary-compatible, so they can't use a different vers

Re: [Discuss-gnuradio] 'Can't Avoid' fixes in current GNUradio 3.7.9.2

2016-04-28 Thread West, Nathan
On Thu, Apr 28, 2016 at 1:31 PM, Lamar Owen wrote: > The EPEL repository for RHEL and its rebuilds currently has a slightly > older version of GNUradio in the repo, a 3.7.5. > > I filed a bug in the EPEL bugzilla as an RFE to update to 3.7.9, but I got > an answer back that it is EPEL policy (muc

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread Marcus Müller
I can really well understand the nature of "wanting to learn by doing" :) but since GNU Radio builds excellently without GRC or graphical (gr-qtgui, gr-wxgui, gr-sdl) interfaces, I'd really say: Start with GNU Radio minus graphical stuff – adding that later on when necessity dictates is probably a

Re: [Discuss-gnuradio] Question about sampling rate and center freq

2016-04-28 Thread abhinav narain
Hi Marcus, thanks for the sketch; for the next time, screenshots are best done by > using GRC's "Screen Capture" functionality, or at least with your operating > system's screenshot function. Can't be that hard. > > Not at all! Sorry, I was taking pictures of hardware and hence just took one for t

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread mleech
I use all of my Odroids that run GR in a "headless" mode--I find no reason to do flow-graph development on the device itself, and processing flowgraphs in radio astronomy just don't really need a graphical component to be running on the Odroid. On 2016-04-28 13:28, Marcus Müller wrote: > Do you

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread Lamar Owen
Marcus, Thanks for the information. Once EPEL is available for AArch64, it won't be hard at all, as there is already a GNURadio 3.7.5 package with SPEC and such, and at that point it won't be difficult to do. I sent a separate message about that, though. But at the moment EPEL is not a

Re: [Discuss-gnuradio] 'Can't Avoid' fixes in current GNUradio 3.7.9.2

2016-04-28 Thread Lamar Owen
On 04/28/2016 01:42 PM, West, Nathan wrote: On Thu, Apr 28, 2016 at 1:31 PM, Lamar Owen > wrote: Does anyone know of any fixes since 3.7.5 that might be considered 'can't avoid?' Personal opinion incoming: Normally I strongly advocate for working off of the lat

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

2016-04-28 Thread Pavan Yedavalli
Hi Derek, Sorry - just another quick addition. When I run the Tx flowgraph, I get this error: Board 0 May not be getting a PPS signal! No PPS detected within the time interval. This definitely tells me something is wrong with the Octoclock-G setup. On Thu, Apr 28, 2016 at 12:18 PM, Pavan Yedava

Re: [Discuss-gnuradio] 'Can't Avoid' fixes in current GNUradio 3.7.9.2

2016-04-28 Thread Lamar Owen
[Reply comments in-line.] On 04/28/2016 01:41 PM, Marcus Müller wrote: It's not about not updating – it's about not breaking possible existing usage! RH has to make sure that software stays binary-compatible, so they can't use a different version if it has a different ABI. I not only am aware

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread Lamar Owen
On 04/28/2016 02:56 PM, mle...@ripnet.com wrote: I use all of my Odroids that run GR in a "headless" mode--I find no reason to do flow-graph development on the device itself, and processing flowgraphs in radio astronomy just don't really need a graphical component to be running on the Odroid.

Re: [Discuss-gnuradio] 'Can't Avoid' fixes in current GNUradio 3.7.9.2

2016-04-28 Thread Tom Rondeau
On Thu, Apr 28, 2016 at 3:31 PM, Lamar Owen wrote: > [Reply comments in-line.] > > On 04/28/2016 01:41 PM, Marcus Müller wrote: > >> It's not about not updating – it's about not breaking possible existing >> usage! RH has to make sure that software stays binary-compatible, so >> they can't use a

Re: [Discuss-gnuradio] 'Can't Avoid' fixes in current GNUradio 3.7.9.2

2016-04-28 Thread Lamar Owen
On 04/28/2016 03:43 PM, Tom Rondeau wrote: You can see the criteria we have for our version numbering here: Tom, thanks for the pointer and for the answers. On Thu, Apr 28, 2016 at 3:31 PM, Lamar Owen mailto:lo...@pari.edu>> wrote: And that's the crux of my question: concisely, are

[Discuss-gnuradio] GNURadio / Debian / ham workshop Vienna, this Sunday 1 May

2016-04-28 Thread Daniel Pocock
As part of MiniDebConf[1] and Linuxwochen[2] we're running a workshop[3] on ham radio, SDR and Debian this Sunday, 1 May in Vienna Please feel free to join us and publicize the event to anybody you know in the area. If you can bring any ham radio or SDR equipment or if you would like to particip

[Discuss-gnuradio] sweep generator

2016-04-28 Thread Dan McKenna
Hi There, I am using a B210 to record band widths from 1 to 20 MHZ, center frequencies from 400Mhz to 2 Ghz. To test my post detection software I would like to use a Tx channel to make a sweep generator as a real time test source at sweep rates of around 50 Mhz/second over 1 to 20 mhz range wit

Re: [Discuss-gnuradio] sweep generator

2016-04-28 Thread Richard Bell
Do you specifically not want to use uhd_siggen_gui when you say you want to use companion? If you were not aware of uhd_siggen_gui, type that into a command line and test it out. It can generate a sweeping tone if that's all you need. Rich On Thu, Apr 28, 2016 at 3:16 PM, Dan McKenna wrote: >

Re: [Discuss-gnuradio] sweep generator

2016-04-28 Thread Chris Kuethe
You can do this with gnuradio-companion blocks. Use a signal source block to generate a sawtooth wave, feed it into an VCO block and dump its output into a probe signal (maybe call it "ramp_out"). Then use a function probe (maybe call it "tuner_freq") block to monitor the value of the probe signal

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

2016-04-28 Thread Derek Kozel
Hello Pavan, You do not need Ethernet connected to the Octoclock, so that's ok. Your cabling sounds correct. Can you please combine both UHD Sinks? Just increase the number of motherboards and channels to 2 and copy the MIMO attached USRP's settings into channel 2. Your sample rate for the receiv

Re: [Discuss-gnuradio] 'Can't Avoid' fixes in current GNUradio 3.7.9.2

2016-04-28 Thread Lamar Owen
On 04/28/2016 03:43 PM, Tom Rondeau wrote: I would think "probably not" within the 3.7 API version series. There have been plenty of additional features and bug fixes, but whether or not they are critical depends on your needs and applications. But I'd say the burden of proving "can't avoid" is

Re: [Discuss-gnuradio] sweep generator

2016-04-28 Thread Marcus D. Leech
On 04/28/2016 06:46 PM, Chris Kuethe wrote: You can do this with gnuradio-companion blocks. Use a signal source block to generate a sawtooth wave, feed it into an VCO block and dump its output into a probe signal (maybe call it "ramp_out"). Then use a function probe (maybe call it "tuner_freq")

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

2016-04-28 Thread Pavan Yedavalli
Hi Derek, I appreciate it. Okay, I will change all of those. I am using the SBX daughterboards - the ones that support phase sync. On Thu, Apr 28, 2016 at 3:55 PM, Derek Kozel wrote: > Hello Pavan, > > You do not need Ethernet connected to the Octoclock, so that's ok. Your > cabling sounds corr

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

2016-04-28 Thread Marcus Müller
Hi, before I head to bed: I was actually thinking about using a SPEC from any other platform (ie. prolly x86_64) and just fixing a few flags, if at all necessary – the cmake build system will usually deal just fine! So really, if you want bleeding edge, go for it :) and don't wait for EPEL. Cheer

Re: [Discuss-gnuradio] sweep generator

2016-04-28 Thread Dan
Thank you for this approach as it is back to my original starting point using the VCO block. Yet What I do not understand is; why the VCO is needed if you are controlling the center frequency of the Tx channel with a scaled sawtooth as a variable controlling center frequency. Vs, the output o