Re: NEW: comms/gnuradio

2018-09-08 Thread Anthony J. Bentley 
On Wed, Sep 5, 2018 at 2:50 AM, Stuart Henderson  wrote:
> I think this is nearly in shape for committing and it would be nice to
> have in tree (though like you I've not tested hardware - currently I have
> SDRplay [looks to be a pain with not-really-open code] and RTL-SDR [iirc
> this wanted async support in libusb] so there's not a lot I can do without
> a bunch more work).

New tarball with some changes:

- reflowed DESCR
- dropped rand patch
- added missed log4cpp dependency
- took maintainership (haven't heard from Aaron)
- switched /usr/local/etc to SYSCONFDIR + @sample

ok?

-- 
Anthony J. Bentley


gnuradio.tar.gz
Description: application/gzip

Re: NEW: comms/gnuradio

2018-09-05 Thread Stuart Henderson 
On 2018/08/25 09:23, Anthony J. Bentley wrote:
> Hi,
> 
> GNU Radio is a software development toolkit that provides signal processing
> blocks to implement software radios. It can be used with readily-available
> low-cost external RF hardware to create software-defined radios, or
> without hardware in a simulation-like environment. It is widely used in
> hobbyist, academic and commercial environments to support both wireless
> communications research and real-world radio systems.
> 
> GNU Radio has filters, channel codes, synchronisation elements,
> equalizers, demodulators, vocoders, decoders, and many other elements
> (in the GNU Radio jargon, we call these elements blocks) which are
> typically found in radio systems. More importantly, it includes a method
> of connecting these blocks and then manages how data is passed from one
> block to another. Extending GNU Radio is also quite easy; if you find a
> specific block that is missing, you can quickly create and add it.
> 
> GNU Radio applications are primarily written using the Python programming
> language, while the supplied, performance-critical signal processing
> path is implemented in C++ using processor floating point extensions,
> where available.
> 
> 
> Aaron Poffenberger submitted a port two years ago, but it had random
> crashes somewhere in the intersection of boost, swig, and gnuradio.
> All three have had several releases since then and I can no longer
> reproduce the crash, so I think it's gone away.
> 
> I haven't tested this with hardware, only played around with block
> designs in gnuradio-companion.
> 
> Aaron, are you still interested in maintaining this port?
> 
> -- 
> Anthony J. Bentley

I think this is nearly in shape for committing and it would be nice to
have in tree (though like you I've not tested hardware - currently I have
SDRplay [looks to be a pain with not-really-open code] and RTL-SDR [iirc
this wanted async support in libusb] so there's not a lot I can do without
a bunch more work).

I think the main issue is the /usr/local/etc use which needs fixing.

The patches for rand don't seem worth the maintenance to me, srand is
a noop on OpenBSD, there's no modulo bias with % 256, and rand already
uses the "good" random generator unless srand_deterministic was used.

DESCR looks a bit nicer reflowed:

--
GNU Radio is a software development toolkit that provides signal processing
blocks to implement software radios. It can be used with readily-available
low-cost external RF hardware to create software-defined radios, or without
hardware in a simulation-like environment. It is widely used in hobbyist,
academic and commercial environments to support both wireless communications
research and real-world radio systems.

GNU Radio has filters, channel codes, synchronisation elements, equalizers,
demodulators, vocoders, decoders, and many other elements (in the GNU Radio
jargon, we call these elements blocks) which are typically found in radio
systems. More importantly, it includes a method of connecting these blocks
and then manages how data is passed from one block to another. Extending GNU
Radio is also quite easy; if you find a specific block that is missing, you
can quickly create and add it.

GNU Radio applications are primarily written using the Python programming
language, while the supplied, performance-critical signal processing path
is implemented in C++ using processor floating point extensions, where
available.
--

Re: NEW: comms/gnuradio

2016-09-20 Thread Aaron Poffenberger 
Hi Stuart,

Fixed.

Crashing problem, not yet.

Cheers,

--Aaron

* Stuart Henderson  [2016-09-16 09:29:00 +0100]:

> On 2016/09/15 23:59, Anthony J. Bentley wrote:
> > From pkg/PLIST:
> > 
> > share/doc/${FULLPKGNAME}/
> > ...
> > 
> > FULLPKGNAME incorporates REVISION and EPOCH, so this will break as soon
> > as the package is bumped.
> 
> Please adjust the build to use a directory name without the version
> number, e.g. share/doc/gnuradio.
> 
> > Aside from that, something weird is going on:
> > 
> > $ gnuradio-companion
> > Warning: restarting the docstring loader (crashed while loading 
> > 'analog_agc2_xx')
> > RuntimeError('boost::filesystem::status: File name too long: 
> > "\xdf\xdf\xdf\xdf
> > \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> 
> When you see a bunch of 0xdf like this (also sometimes shows up as
> ß), it's often a use-after-free or code not zeroing newly malloc()ed
> memory.
>

Re: NEW: comms/gnuradio

2016-09-20 Thread Aaron Poffenberger 
Thanks for trying the port and the feedback.

It's very odd. I sometimes get this error. Sometimes I don't. It
appears to be happening in some of the SWIG integration between C++
and Python. I'm still sorting it out.

Cheers,

--Aaron

* Anthony J. Bentley  [2016-09-15 23:59:56 -0600]:

> Aaron Poffenberger writes:
> > * Aaron Poffenberger  [2016-09-09 09:53:10 -0500]:
> > 
> > > Hello ports@,
> > > 
> > > Here is a new port : comms/gnuradio
> > > 
> > > Tested on: amd64.
> > > 
> > > From DESCR:
> > > 
> > > GNU Radio is a software development toolkit that provides signal 
> > > processing
> > > blocks to implement software radios. It can be used with readily-available
> > > low-cost external RF hardware to create software-defined radios, or
> > > without hardware in a simulation-like environment. It is widely used in
> > > hobbyist, academic and commercial environments to support both wireless
> > > communications research and real-world radio systems.
> 
> From pkg/PLIST:
> 
> share/doc/${FULLPKGNAME}/
> ...
> 
> FULLPKGNAME incorporates REVISION and EPOCH, so this will break as soon
> as the package is bumped.
> 
> 
> Aside from that, something weird is going on:
> 
> $ gnuradio-companion
> Warning: restarting the docstring loader (crashed while loading 
> 'analog_agc2_xx')
> RuntimeError('boost::filesystem::status: File name too long: "\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
> \xdf\xdf\x18\x0f\xcf\xeb\xdb\x19/config.conf"',)
> 
> -- 
> Anthony J. Bentley
>

Re: NEW: comms/gnuradio

2016-09-16 Thread Stuart Henderson 
On 2016/09/15 23:59, Anthony J. Bentley wrote:
> From pkg/PLIST:
> 
> share/doc/${FULLPKGNAME}/
> ...
> 
> FULLPKGNAME incorporates REVISION and EPOCH, so this will break as soon
> as the package is bumped.

Please adjust the build to use a directory name without the version
number, e.g. share/doc/gnuradio.

> Aside from that, something weird is going on:
> 
> $ gnuradio-companion
> Warning: restarting the docstring loader (crashed while loading 
> 'analog_agc2_xx')
> RuntimeError('boost::filesystem::status: File name too long: "\xdf\xdf\xdf\xdf
> \xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf

When you see a bunch of 0xdf like this (also sometimes shows up as
ß), it's often a use-after-free or code not zeroing newly malloc()ed
memory.

Re: NEW: comms/gnuradio

2016-09-16 Thread Anthony J. Bentley 
Aaron Poffenberger writes:
> * Aaron Poffenberger  [2016-09-09 09:53:10 -0500]:
> 
> > Hello ports@,
> > 
> > Here is a new port : comms/gnuradio
> > 
> > Tested on: amd64.
> > 
> > From DESCR:
> > 
> > GNU Radio is a software development toolkit that provides signal processing
> > blocks to implement software radios. It can be used with readily-available
> > low-cost external RF hardware to create software-defined radios, or
> > without hardware in a simulation-like environment. It is widely used in
> > hobbyist, academic and commercial environments to support both wireless
> > communications research and real-world radio systems.

>From pkg/PLIST:

share/doc/${FULLPKGNAME}/
...

FULLPKGNAME incorporates REVISION and EPOCH, so this will break as soon
as the package is bumped.


Aside from that, something weird is going on:

$ gnuradio-companion
Warning: restarting the docstring loader (crashed while loading 
'analog_agc2_xx')
RuntimeError('boost::filesystem::status: File name too long: "\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf\xdf
\xdf\xdf\x18\x0f\xcf\xeb\xdb\x19/config.conf"',)

-- 
Anthony J. Bentley

Re: NEW: comms/gnuradio

2016-09-13 Thread Aaron Poffenberger 
Has anyone tried this? Any feedback?

--Aaron

* Aaron Poffenberger  [2016-09-09 09:53:10 -0500]:

> Hello ports@,
> 
> Here is a new port : comms/gnuradio
> 
> Tested on: amd64.
> 
> From DESCR:
> 
> GNU Radio is a software development toolkit that provides signal processing
> blocks to implement software radios. It can be used with readily-available
> low-cost external RF hardware to create software-defined radios, or
> without hardware in a simulation-like environment. It is widely used in
> hobbyist, academic and commercial environments to support both wireless
> communications research and real-world radio systems.
> 
> 
> 
> This port is based on commits to openbsd-wip by sthen@, bentley@ and
> Aaron Bieber.
> 
> I've updated the port to the latest from gnuradio (3.7.10.1).
> 
> This port of gnuradio is first in a series of ports and updates to get
> the key SDR projects working on OpenBSD. I have an update for rtl-sdr
> I'll send shortly. gr-osmosdr is almost ready. I'll follow that with
> gqrx.
> 
> If anyone is already working on those, please let me know.
> 
> N.B., SDR on OpenBSD may require more work to be fully functional.
> sthen@ pointed out to me that our libusb doesn't support async yet.
> Still, having the software and drivers available may help in that
> regard.
> 
> Cheers,
> Aaron

Re: NEW: comms/gnuradio

2016-09-09 Thread noah pugsley 
On Fri, Sep 9, 2016 at 7:53 AM, Aaron Poffenberger 
wrote:

> Hello ports@,
>
> Here is a new port : comms/gnuradio
>
> Tested on: amd64.
>
> From DESCR:
>
> GNU Radio is a software development toolkit that provides signal processing
> blocks to implement software radios. It can be used with readily-available
> low-cost external RF hardware to create software-defined radios, or
> without hardware in a simulation-like environment. It is widely used in
> hobbyist, academic and commercial environments to support both wireless
> communications research and real-world radio systems.
>
> 
>
> This port is based on commits to openbsd-wip by sthen@, bentley@ and
> Aaron Bieber.
>
> I've updated the port to the latest from gnuradio (3.7.10.1).
>
> This port of gnuradio is first in a series of ports and updates to get
> the key SDR projects working on OpenBSD. I have an update for rtl-sdr
> I'll send shortly. gr-osmosdr is almost ready. I'll follow that with
> gqrx.
>
> If anyone is already working on those, please let me know.
>
> N.B., SDR on OpenBSD may require more work to be fully functional.
> sthen@ pointed out to me that our libusb doesn't support async yet.
> Still, having the software and drivers available may help in that
> regard.
>
> Cheers,
> Aaron
>

Very excited to see this. Thank you.