Re: wimax chain

2019-12-22 Thread Eitan Hetzroni
anyone with any progress on the wimax?will to even pay for a working chain
- cant figure out where to find a grc chain.

On Wed, Nov 20, 2019 at 3:29 PM Müller, Marcus (CEL) 
wrote:

> Hi,
> ah! OK, yeah, that's unfortunate.
>
> So, the easy thing about OFDM: as soon as you know where your symbol
> starts, all you need to do is apply an FFT – and you're done. (you will
> still have to "equalize" your reception, but that is a point-wise
> multiplication at the output of the FFT.)
>
> So, if I was to recommend a methodology for solving this: Start with
> building a fixed-lag correlator to find the beginning of symbols.
> You're not the first person to have to do that:
> The gr-dab module [1] contains one such, that you'd only have to
> parameterize to use the length and sizes of OFDM symbols in WiMaX
> instead of these in DAB+. (I actually recommend looking at gr-dab's
> receiver; it's a nice display of how to demodulate OFDM downlinks.)
> You'll be getting output that you can threshold to get the beginnings
> of symbols, then you just start taking FFTs at these positions, and in
> those, you look for the preamble symbols to get the equalizer taps.
>
> Best regards,
> Marcus
>
> [1] https://github.com/kit-cel/gr-dab
> On Wed, 2019-11-20 at 15:19 +0200, Eitan Hetzroni wrote:
> > hello,
> > it is an ofdm system, but i could not get to tweak the ofdm_Rx example
> to find the preamble in the transmission i was looking to capture.
> >
> > On Wed, Nov 20, 2019 at 3:16 PM Müller, Marcus (CEL) 
> wrote:
> > > Hi Eitan,
> > >
> > > please keep replies on the list!
> > > I don't think there's a readymade solution for you.
> > >
> > > I'm not quite sure what you mean with "resemble OFDM": could you
> > > elaborate? I really thought that IEEE802.16 is a pure OFDM system, so
> > > this comes as a surprise. In which way is it not?
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Wed, 2019-11-20 at 15:13 +0200, Eitan Hetzroni wrote:
> > > > thanks for the rapid reply,
> > > > it does resemble ofdm, however as a beginner in the field i was
> hoping to find a readymade chain to tweak with?
> > > >
> > > >
> > > > On Wed, Nov 20, 2019 at 3:11 PM Müller, Marcus (CEL) <
> muel...@kit.edu> wrote:
> > > > > Hi Eitan,
> > > > >
> > > > > it's been a while since I've looked into IEEE802.16, but that's a
> very
> > > > > regular OFDM system, isn't it, with a fixed OFDM symbol as short
> > > > > preamble (for the downlink bursts), and a 2-symbol preamble for the
> > > > > start of frame?
> > > > >
> > > > > A simple correlation detector might do in that case; a bit nicer
> on the
> > > > > acquisition speed per computational effort might be a fixed-length
> > > > > correlator that detects the position of cyclic prefixes and could
> be
> > > > > applied to a whole burst or even frame to get a good timing
> estimate
> > > > > before you start decoding OFDM symbols.
> > > > >
> > > > > Best regards,
> > > > > Marcus
> > > > >
> > > > > PS: Your email signature is kinda funny on a publicly archived
> mailing
> > > > > list :D
> > > > >
> > > > >
> > > > > On Wed, 2019-11-20 at 14:43 +0200, Eitan Hetzroni wrote:
> > > > > > Hi,
> > > > > > any solution to the reception (rx) or tx of wimax using gnuradio?
> > > > > > could not find any proper chain that finds the preamble.
> > > > > >
> > > > > > The information transmitted is intended only for the person or
> entity to which it is addressed and may contain confidential and/or
> privileged material. Any review, retransmission, dissemination or other use
> of, or taking of any action in reliance upon, this information by persons
> or entities other than the intended recipient is prohibited. If you
> received this in error, please contact the sender and delete all copies of
> the message.
> > > >
> > > > The information transmitted is intended only for the person or
> entity to which it is addressed and may contain confidential and/or
> privileged material. Any review, retransmission, dissemination or other use
> of, or taking of any action in reliance upon, this information by persons
> or entities other than the intended recipient is prohibited. If you
> received this in error, please contact the sender and delete all copies of
> the message.
> >
> > The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete all copies of the
> message.
>

-- 
The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential and/or privileged 
material. Any review, retransmission, dissemination or other use of, or 
taking of any action in reliance upon, this information by persons or 
enti

Re: wimax chain

2019-12-22 Thread Eitan Hetzroni
specifically - mimo-ofdm over wimax

On Sun, Dec 22, 2019 at 1:13 PM Eitan Hetzroni  wrote:

> anyone with any progress on the wimax?will to even pay for a working chain
> - cant figure out where to find a grc chain.
>
> On Wed, Nov 20, 2019 at 3:29 PM Müller, Marcus (CEL) 
> wrote:
>
>> Hi,
>> ah! OK, yeah, that's unfortunate.
>>
>> So, the easy thing about OFDM: as soon as you know where your symbol
>> starts, all you need to do is apply an FFT – and you're done. (you will
>> still have to "equalize" your reception, but that is a point-wise
>> multiplication at the output of the FFT.)
>>
>> So, if I was to recommend a methodology for solving this: Start with
>> building a fixed-lag correlator to find the beginning of symbols.
>> You're not the first person to have to do that:
>> The gr-dab module [1] contains one such, that you'd only have to
>> parameterize to use the length and sizes of OFDM symbols in WiMaX
>> instead of these in DAB+. (I actually recommend looking at gr-dab's
>> receiver; it's a nice display of how to demodulate OFDM downlinks.)
>> You'll be getting output that you can threshold to get the beginnings
>> of symbols, then you just start taking FFTs at these positions, and in
>> those, you look for the preamble symbols to get the equalizer taps.
>>
>> Best regards,
>> Marcus
>>
>> [1] https://github.com/kit-cel/gr-dab
>> On Wed, 2019-11-20 at 15:19 +0200, Eitan Hetzroni wrote:
>> > hello,
>> > it is an ofdm system, but i could not get to tweak the ofdm_Rx example
>> to find the preamble in the transmission i was looking to capture.
>> >
>> > On Wed, Nov 20, 2019 at 3:16 PM Müller, Marcus (CEL) 
>> wrote:
>> > > Hi Eitan,
>> > >
>> > > please keep replies on the list!
>> > > I don't think there's a readymade solution for you.
>> > >
>> > > I'm not quite sure what you mean with "resemble OFDM": could you
>> > > elaborate? I really thought that IEEE802.16 is a pure OFDM system, so
>> > > this comes as a surprise. In which way is it not?
>> > >
>> > > Best regards,
>> > > Marcus
>> > >
>> > > On Wed, 2019-11-20 at 15:13 +0200, Eitan Hetzroni wrote:
>> > > > thanks for the rapid reply,
>> > > > it does resemble ofdm, however as a beginner in the field i was
>> hoping to find a readymade chain to tweak with?
>> > > >
>> > > >
>> > > > On Wed, Nov 20, 2019 at 3:11 PM Müller, Marcus (CEL) <
>> muel...@kit.edu> wrote:
>> > > > > Hi Eitan,
>> > > > >
>> > > > > it's been a while since I've looked into IEEE802.16, but that's a
>> very
>> > > > > regular OFDM system, isn't it, with a fixed OFDM symbol as short
>> > > > > preamble (for the downlink bursts), and a 2-symbol preamble for
>> the
>> > > > > start of frame?
>> > > > >
>> > > > > A simple correlation detector might do in that case; a bit nicer
>> on the
>> > > > > acquisition speed per computational effort might be a fixed-length
>> > > > > correlator that detects the position of cyclic prefixes and could
>> be
>> > > > > applied to a whole burst or even frame to get a good timing
>> estimate
>> > > > > before you start decoding OFDM symbols.
>> > > > >
>> > > > > Best regards,
>> > > > > Marcus
>> > > > >
>> > > > > PS: Your email signature is kinda funny on a publicly archived
>> mailing
>> > > > > list :D
>> > > > >
>> > > > >
>> > > > > On Wed, 2019-11-20 at 14:43 +0200, Eitan Hetzroni wrote:
>> > > > > > Hi,
>> > > > > > any solution to the reception (rx) or tx of wimax using
>> gnuradio?
>> > > > > > could not find any proper chain that finds the preamble.
>> > > > > >
>> > > > > > The information transmitted is intended only for the person or
>> entity to which it is addressed and may contain confidential and/or
>> privileged material. Any review, retransmission, dissemination or other use
>> of, or taking of any action in reliance upon, this information by persons
>> or entities other than the intended recipient is prohibited. If you
>> received this in error, please contact the sender and delete all copies of
>> the message.
>> > > >
>> > > > The information transmitted is intended only for the person or
>> entity to which it is addressed and may contain confidential and/or
>> privileged material. Any review, retransmission, dissemination or other use
>> of, or taking of any action in reliance upon, this information by persons
>> or entities other than the intended recipient is prohibited. If you
>> received this in error, please contact the sender and delete all copies of
>> the message.
>> >
>> > The information transmitted is intended only for the person or entity
>> to which it is addressed and may contain confidential and/or privileged
>> material. Any review, retransmission, dissemination or other use of, or
>> taking of any action in reliance upon, this information by persons or
>> entities other than the intended recipient is prohibited. If you received
>> this in error, please contact the sender and delete all copies of the
>> message.
>>
>

-- 
The information transmitted is intended only for the person or entity to 
whi

[VOLK] Release v2.1.0

2019-12-22 Thread Johannes Demel
Hi everyone,

we just released VOLK v2.1.0!

we would like to announce that Michael Dickens and Johannes Demel are
the new VOLK maintainers. We want to review and merge PRs in a timely
manner as well as commenting on issues in order to resolve them.

We want to thank all contributors. This release wouldn't have been
possible without them.

We're curious about VOLK users. Especially we'd like to learn about VOLK
users who use VOLK outside GNU Radio.

If you have ideas for VOLK enhancements, let us know. Start with an
issue to discuss your idea. We'll be happy to see new features get
merged into VOLK.

## Highlights

VOLK v2.1.0 is a collection of really cool changes. We'd like to
highlight some of them.

- The AVX FMA rotator bug is fixed
- VOLK offers `volk::vector<>` for C++ to follow RAII
- Move towards modern dependencies
- CMake 3.8
- Prefer Python3
- We will drop Python2 support in a future release!
- Use C++17 `std::filesystem`
- This enables VOLK to be built without Boost if available!
- more stable CI
- lots of bugfixes
- more optimized kernels, especially more NEON versions

## Contributors

*  Albin Stigo 
*  Amr Bekhit 
*  Andrej Rode 
*  Carles Fernandez 
*  Christoph Mayer 
*  Clayton Smith 
*  Damian Miralles 
*  Johannes Demel  
*  Marcus Müller 
*  Michael Dickens 
*  Philip Balister 
*  Takehiro Sekine 
*  Vasil Velichkov 
*  luz.paz 


## Changes

* Usage
- Update README to reflect how to build on Raspberry Pi and the
importance of running volk_profile

* Toolchain
-  Add toolchain file for Raspberry Pi 3
-  Update Raspberry 4 toolchain file

* Kernels
- Add neonv7 to volk_16ic_magnitude_16i
- Add neonv7 to volk_32fc_index_max_32u
- Add neonv7 to volk_32fc_s32f_power_spectrum_32f
- Add NEONv8 to volk_32f_64f_add_64f
- Add Neonv8 to volk_32fc_deinterleave_64f_x2
- Add volk_32fc_x2_s32fc_multiply_conjugate_add_32fc
- Add NEONv8 to volk_32fc_convert_16ic

* CI
- Fix AVX FMA rotator
- appveyor: Enable testing on windows
- Fixes for flaky kernels for more reliable CI
- volk_32f_log2_32f
- volk_32f_x3_sum_of_poly_32f
- volk_32f_index_max_{16,32}u
- volk_32f_8u_polarbutterflypuppet_32f
- volk_8u_conv_k7_r2puppet_8u
- volk_32fc_convert_16ic
- volk_32fc_s32f_magnitude_16i
- volk_32f_s32f_convert_{8,16,32}i
- volk_16ic_magnitude_16i
- volk_32f_64f_add_64f
- Use Intel SDE to test all kernels
- TravisCI
- Add native tests on arm64
- Add native tests on s390x and ppc64le (allow failure)

* Build
- Build Volk without Boost if C++17 std::filesystem or
std::experimental::filesystem is available
- Update to more modern CMake
- Prevent CMake to choose previously installed VOLK headers
- CMake
- bump minimum version to 3.8
- Use sha256 instead of md5 for unique target name hash
- Python: Prefer Python3 over Python2 if available

* C++
- VOLK C++ allocator and C++11 std::vector type alias added


Re: wimax chain

2019-12-22 Thread CEL
Hi Eitan,

> specifically - mimo-ofdm over wimax

As I said, it's unlikely someone else wrote exactly what you're
supposed to build before.

I'm currently not taking development projects, but: it's a pretty
normal thing to pay for contract GNU Radio development, so I'm sure we
can help you find someone to work for you!

Of course, the mailing list is always open to your questions, so if you
have any questions to what I (or others) have written here before, do
not hesitate to ask about specifics!

Best regards,
Marcus

On Sun, 2019-12-22 at 14:17 +0200, Eitan Hetzroni wrote:
> specifically - mimo-ofdm over wimax
> 
> On Sun, Dec 22, 2019 at 1:13 PM Eitan Hetzroni 
> wrote:
> > anyone with any progress on the wimax?will to even pay for a
> > working chain - cant figure out where to find a grc chain.
> > 
> > On Wed, Nov 20, 2019 at 3:29 PM Müller, Marcus (CEL) <
> > muel...@kit.edu> wrote:
> > > Hi,
> > > ah! OK, yeah, that's unfortunate. 
> > > 
> > > So, the easy thing about OFDM: as soon as you know where your
> > > symbol
> > > starts, all you need to do is apply an FFT – and you're done.
> > > (you will
> > > still have to "equalize" your reception, but that is a point-wise
> > > multiplication at the output of the FFT.)
> > > 
> > > So, if I was to recommend a methodology for solving this: Start
> > > with
> > > building a fixed-lag correlator to find the beginning of
> > > symbols. 
> > > You're not the first person to have to do that:
> > > The gr-dab module [1] contains one such, that you'd only have to
> > > parameterize to use the length and sizes of OFDM symbols in WiMaX
> > > instead of these in DAB+. (I actually recommend looking at gr-
> > > dab's
> > > receiver; it's a nice display of how to demodulate OFDM
> > > downlinks.)
> > > You'll be getting output that you can threshold to get the
> > > beginnings
> > > of symbols, then you just start taking FFTs at these positions,
> > > and in
> > > those, you look for the preamble symbols to get the equalizer
> > > taps.
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > [1] https://github.com/kit-cel/gr-dab
> > > On Wed, 2019-11-20 at 15:19 +0200, Eitan Hetzroni wrote:
> > > > hello,
> > > > it is an ofdm system, but i could not get to tweak the ofdm_Rx
> > > example to find the preamble in the transmission i was looking to
> > > capture.
> > > > 
> > > > On Wed, Nov 20, 2019 at 3:16 PM Müller, Marcus (CEL) <
> > > muel...@kit.edu> wrote:
> > > > > Hi Eitan,
> > > > > 
> > > > > please keep replies on the list!
> > > > > I don't think there's a readymade solution for you. 
> > > > > 
> > > > > I'm not quite sure what you mean with "resemble OFDM": could
> > > you
> > > > > elaborate? I really thought that IEEE802.16 is a pure OFDM
> > > system, so
> > > > > this comes as a surprise. In which way is it not?
> > > > > 
> > > > > Best regards,
> > > > > Marcus
> > > > > 
> > > > > On Wed, 2019-11-20 at 15:13 +0200, Eitan Hetzroni wrote:
> > > > > > thanks for the rapid reply,
> > > > > > it does resemble ofdm, however as a beginner in the field i
> > > was hoping to find a readymade chain to tweak with?
> > > > > > 
> > > > > > 
> > > > > > On Wed, Nov 20, 2019 at 3:11 PM Müller, Marcus (CEL) <
> > > muel...@kit.edu> wrote:
> > > > > > > Hi Eitan,
> > > > > > > 
> > > > > > > it's been a while since I've looked into IEEE802.16, but
> > > that's a very
> > > > > > > regular OFDM system, isn't it, with a fixed OFDM symbol
> > > as short
> > > > > > > preamble (for the downlink bursts), and a 2-symbol
> > > preamble for the
> > > > > > > start of frame?
> > > > > > > 
> > > > > > > A simple correlation detector might do in that case; a
> > > bit nicer on the
> > > > > > > acquisition speed per computational effort might be a
> > > fixed-length
> > > > > > > correlator that detects the position of cyclic prefixes
> > > and could be
> > > > > > > applied to a whole burst or even frame to get a good
> > > timing estimate
> > > > > > > before you start decoding OFDM symbols.
> > > > > > > 
> > > > > > > Best regards,
> > > > > > > Marcus
> > > > > > > 
> > > > > > > PS: Your email signature is kinda funny on a publicly
> > > archived mailing
> > > > > > > list :D
> > > > > > > 
> > > > > > > 
> > > > > > > On Wed, 2019-11-20 at 14:43 +0200, Eitan Hetzroni wrote:
> > > > > > > > Hi,
> > > > > > > > any solution to the reception (rx) or tx of wimax using
> > > gnuradio?
> > > > > > > > could not find any proper chain that finds the
> > > preamble.
> > > > > > > > 
> > > > > > > > The information transmitted is intended only for the
> > > person or entity to which it is addressed and may contain
> > > confidential and/or privileged material. Any review,
> > > retransmission, dissemination or other use of, or taking of any
> > > action in reliance upon, this information by persons or entities
> > > other than the intended recipient is prohibited. If you received
> > > this in error, please contact the sender and delete all copies of
> > > the message.
> > > >

Docksphor: gr-fosphor inside docker for times of despair

2019-12-22 Thread Francisco Albani
gr-fosphor has been an invaluable tool for debugging physical layers
and enjoying the experience of exploring the EM spectrum.

Too many times I found myself or others trying to use it
in a new setup or in a fast-paced OS (like Arch Linux) just to find
it is broken, hard to install/repair or uninstallable for some hard to
debug reason.

With that in mind, I made a Dockerfile [1] for building an image
for launching a containerized gnuradio-companion
with a ready-to-go basic "ZMQ SUB source --> QT fosphor sink" flowgraph,
so you can send samples from the outside.

Hope it helps.

Comments are welcome.

[1]https://github.com/franalbani/docksphor