Re: [Discuss-gnuradio] [UHD] Announcing 3.14.0.0 Release Candidate 1

[Andre Puschmann]

Hey guys,

any idea or numbers on the performance improvement using DPDK, e.g. CPU
usage during rx/tx streaming, when compared to the legacy approach?
Would be great to get a feeling for the achievable gains.

Thanks
Andre


On 13/2/19 20:58, Nick Foster via USRP-users wrote:
> Any plans to update to the latest API? Won't compile with anything after
> 17.05.
> 
> On Wed, Feb 13, 2019, 11:33 AM Michael West
>  > wrote:
> 
> Hi Nick,
> 
> Information on using DPDK can be found here: 
> http://files.ettus.com/manual/page_dpdk.html
> 
> DPDK can be used with any example.  Think of it as an accelerator
> for Ethernet transports if using Intel NICs.
> 
> Regards,
> Michael
> 
> On Thu, Feb 7, 2019 at 10:29 AM Nick Foster
>  > wrote:
> 
> Great news! DPDK support is an interesting development. Is there
> any documentation or examples which show this capability?
> 
> Nick
> 
> 
> On Thu, Feb 7, 2019 at 10:05 AM Michael West via USRP-users
>  > wrote:
> 
> The release candidate of UHD version 3.14.0.0 has been
> tagged and is available for testing.  This API release
> introduces support for the N320 and N321 USRPs soon to be
> released (watch for the announcement on ettus.com
> !), a DPDK-based transport, and several
> other features and bug fixes.  This release includes all bug
> fixes and enhancements in the 3.13.0.1, 3.13.0.2, and
> 3.13.1.0 maintenance releases.
> 
> The tag for this release candidate:
> https://github.com/EttusResearch/uhd/releases/tag/v3.14.0.0-rc1
> 
> There have been 406 commits since the last API release
> (3.13.0.0)which can be viewed here:
> 
> https://github.com/EttusResearch/uhd/compare/v3.13.0.0...v3.14.0.0-rc1
> 
> Please report any bugs found on the UHD issue tracker:
> http://github.com/EttusResearch/uhd/issues
> * Please do not use the issue tracker for help or support.
> 
> Pull requests for direct code changes may be submitted to
> the UHD or FPGA repositories:
> http://github.com/EttusResearch/uhd/pulls
> http://github.com/EttusResearch/fpga/pulls
> 
> CHANGELOG:
> ## 003.014.000.000
> * N320: Add N320 and N321
> * Test: Add Python API test
> * Device3: Move from packet-based to byte-based flow control
> * X300: Reduce default send_frame_size to 4000 over Ethernet
> * UHD: Release recv buffers earlier in rx_streamer
> * Device3: Constrain send_buff_size to input fifo size
> * X300: Change Ethernet buffering
> * MPMD: Parallelize broadcast-finding
> * Device: Parallelize device discovery
> * Docs: Fix Doxygen warnings
> * B100: Move fifo_ctrl_excelsior to b100 subdir
> * B100: Fix fifo_ctrl_excelsior not exiting
> * B100: Remove all Boostisms from fifo_ctrl_excelsior
> * B100: Demote some clocking-related log messages to trace
> * X300: Log git hash and compat number as debug message
> * N310: Modify AD9371 reset function to keep it in reset
> * N3xx: clocking API changes for transitioning clock and
> time sources
> * E320: bist: Fix ref_clock lock test implementation
> * UHD: Fix ADF400x driver for ref counter and charge pump mode
> * E320: bist: Add link_up test
> * MPM: Get list of temperatures from all thermal zones
> * E320: Add all 5 temp sensors, fan sensor and rssi sensors
> per channel
> * E320: Fix tx/rx atr - antenna and frequency settings
> * E320: Enable devtest for E320
> * X300: Move defaults to their own header
> * UHD: Improve constrained_device_args_t
> * X300: Use constrained_args
> * X300: Enable clock_source and time_source device args
> * Test: Integrate Python API Tester into Devtest
> * N3xx: Bump max rev to G/6
> * N3xx: Improve error messages for invalid clock/time settings
> * E320: images: Separate images package for Aurora image
> * B200: Remove superfluous fake lambda
> * B200: Add support for user regs
> * Docs: Add info on how to implement user regs on B200
> * UHD API: Add multi_usrp::get_user_settings_iface()
> * N310: move init_rf_cal before JESD de/framer bringup
> * UHD: Remove usage of time_t (except when required)
> * NIRIO: Demote RPC client cancel/abort to TRACE
> * RFNoC: Convert 

Re: [Discuss-gnuradio] CC1101 GFSK packet decode with variable length

[Andre Puschmann]

Hey,
not sure if this still works but I've worked on a CC1101 receiver a
while ago. Have a look here [1] if you're interested.

Cheers
Andre


[1] https://github.com/andrepuschmann/gr-cc11xx

On 31/12/18 1:00, Alban Meffre wrote:
> Hi
> I would like to decode a simple GFSK packet
> 
> here is the packet structure :
> preamble : AAh x 4
> sync word : D391h
> length byte : 1 byte
> payload : 1 to 64 bytes
> CRC : 2 bytes
> 
> TX : arduino + CC1101 module, 2GFSK, 100kbps, excursion 50kHz, carrier
> 433 MHz
> RX : RTLSDR
> 
> until now i was able to demodulate the signal and add a "sync" tag using
> the correlate access code.
> 
> my goal is to extract the payload and send it to a file or a socket.
> is there a simple way to do that without writing my own block ?
> 
> i can't go further, because i do not manage to find the info i need
> i do not know where to start : stream, tagged stream, PDU, messages, etc..
> i do not figure out how to use these tag for variable length. nothing
> clear in the doc
> 
> i'd be glad if someone helps me
> best regards
> bob
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [VOLK] SIMD accelerated Mersenne-Twister

[Andre Puschmann]

Hi Stefan,

great work! As Martin said, the copyright is the actual issue. Have you
tried to contact the authors? The fact that they seem to be working at a
university rather than a company is at least promising.

Cheers
Andre

On 11.11.2015 19:47, Martin Braun wrote:
> Stefan,
> 
> **THIS IS NOT LEGAL ADVICE ETC.
> 
> the license isn't the issue, but the copyright. Code that goes into GNU
> Radio is copyrighted by the FSF (that's why you signed that CLA). This
> is becoming a more and more common thing, btw, see the recent
> discussions on the LLVM project.
> 
> Since you're not the copyright holder of the original code, you have no
> way of transferring said copyright to the FSF.
> 
> I'm not sure what the correct way to do this is. An out-of-tree approach
> will definitely work, since the licenses are compatible according to
> lists provided by e.g. the FSF.
> If the authors would agree to a copyright transfer of this copy of the
> code, that'll also work but it's annoying to get that.
> 
> On a different note, this is really great work, Stefan!
> 
> Cheers,
> Martin
> 
> On 11.11.2015 05:57, Stefan Wunsch wrote:
>> Hi!
>>
>> I have implemented a SIMD accelerated Mersenne-Twister as a VOLK kernel.
>> The performance is pretty good with up to 350% performance increase
>> compared to a conventional Mersenne-Twister (used is the boost.random
>> implementation with O3 compiler flag).
>>
>> Now the problem: The code isn't completely mine. It is done by the
>> author of this [0]. The code says that it is published under the
>> 3-clause BSD licence [1].
>>
>> Is it possible to contribute this to VOLK? Or do I violate the BSD
>> licence (or the GPL)?
>>
>> Greetings
>> Stefan
>>
>> [0] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/
>> [1]
>> /*
>>  * Copyright (C) 2006, 2007 Mutsuo Saito, Makoto Matsumoto and Hiroshima
>>  * University.
>>  * Copyright (C) 2012 Mutsuo Saito, Makoto Matsumoto, Hiroshima
>>  * University and The University of Tokyo.
>>  * Copyright (C) 2013 Mutsuo Saito, Makoto Matsumoto and Hiroshima
>>  * University.
>>  * All rights reserved.
>>  *
>>  * The 3-clause BSD License is applied to this software, see
>>  * LICENSE.txt
>>  */
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Release v.3.7.8.1

[Andre Puschmann]

On 02.11.2015 10:45, Marcus Müller wrote:
> Hey Andre,
> 
> I think you're looking for https://github.com/gnuradio/gnuradio-livesdr
> (though I've never worked with that myself),
> and specifically
> config/pybombs.d/install.conf

Jep, that's it. Thanks Marcus.

Cheers
Andre

> 
> Cheers,
> Marcus
> 
> On 02.11.2015 09:52, Andre Puschmann wrote:
>> Hi,
>>
>> thanks Nathan for the update.
>>
>> I got a question regarding the Live SDR packaging. I'd like to recommend
>> a few changes and additional packages to be added, for example for
>> gr-ieee80211 that requires gr-foo. Is there a specific git repo that is
>> used for compiling the images that I can send a pull request to?
>>
>> Cheers
>> Andre
>>
>>
>> On 01.11.2015 00:58, West, Nathan wrote:
>>> GNU Radio release v.3.7.8.1 is available for download.
>>>
>>> Tarball:
>>> http://gnuradio.org/releases/gnuradio/gnuradio-3.7.8.1.tar.gz
>>>
>>> MD5sum:|
>>> 961d5ba5089f409f0c9e5e5b7f6ee0f2|
>>>
>>> The Live SDR has been updated with this release. Please see:
>>>
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
>>>
>>> ...for details on how to obtain and use the Live SDR environment.
>>>
>>> Release notes for v.3.7.8.1 follow:
>>>
>>> Contributors
>>> 
>>>
>>>  * Ben Hilburn <ben.hilb...@ettus.com <mailto:ben.hilb...@ettus.com>>
>>>  * Doug Geiger <doug.gei...@bioradiation.net
>>> <mailto:doug.gei...@bioradiation.net>>
>>>  * Gwenhael Goavec-Merou <gwenhael.goavec-me...@trabucayre.com
>>> <mailto:gwenhael.goavec-me...@trabucayre.com>>
>>>  * Johannes Demel <uf...@student.kit.edu <mailto:uf...@student.kit.edu>>
>>>  * Johannes Schmitz <schm...@ti.rwth-aachen.de
>>> <mailto:schm...@ti.rwth-aachen.de>>
>>>  * Johnathan Corgan <johnat...@corganlabs.com
>>> <mailto:johnat...@corganlabs.com>>
>>>  * Martin Braun <martin.br...@ettus.com <mailto:martin.br...@ettus.com>>
>>>  * Nathan West <nathan.w...@okstate.edu <mailto:nathan.w...@okstate.edu>>
>>>  * Paul Cercueil <paul.cercu...@analog.com
>>> <mailto:paul.cercu...@analog.com>>
>>>  * Philip Balister <phi...@balister.org <mailto:phi...@balister.org>>
>>>  * Sean Nowlan <sean.now...@gtri.gatech.edu
>>> <mailto:sean.now...@gtri.gatech.edu>>
>>>  * Sebastian Koslowski <koslow...@kit.edu <mailto:koslow...@kit.edu>>
>>>  * Jan Krämer <kraemer...@gmail.com <mailto:kraemer...@gmail.com>>
>>>  * Sylvain Munaut <t...@246tnt.com>
>>>  * Tom Rondeau <t...@trondeau.com <mailto:t...@trondeau.com>>
>>>
>>> Ben Hilburn <ben.hilb...@ettus.com <mailto:ben.hilb...@ettus.com>> (6):
>>>
>>>   Fixes Coverity Defect 1229872: Memory leak in
>>> `atsci_equalizer_lms2` DTOR
>>>   lms_dd_equalizer_cc.h: Fixing simple documentation typo.
>>>   Addresses Defects 1046385 & 1046340: Out-of-bounds access
>>>   Addresses Defects 1046385 & 1046340: Buffer not NULL-terminated
>>>   Fixes Cov Defect 1046011: Resource Leak
>>>   Fixes Cov Defect 1043301: Unitialized Variable in Conditional
>>>
>>> Doug Geiger <doug.gei...@bioradiation.net
>>> <mailto:doug.gei...@bioradiation.net>> (1):
>>>
>>>   Bring fix from other pfb_arb_resampler_* variants
>>>
>>> Gwenhael Goavec-Merou <gwenhael.goavec-me...@trabucayre.com
>>> <mailto:gwenhael.goavec-me...@trabucayre.com>> (1):
>>>
>>>   logger.h.in <http://logger.h.in>: sys/types.h is needed for mode_t
>>>
>>> Johannes Demel <uf...@student.kit.edu <mailto:uf...@student.kit.edu>> (1):
>>>
>>>   fec: xml template doesn't produce duplicate var def's anymore
>>>
>>> Johannes Schmitz <schm...@ti.rwth-aachen.de
>>> <mailto:schm...@ti.rwth-aachen.de>> (1):
>>>
>>>   gr-zeromq: fix python examples
>>>
>>> Johnathan Corgan <johnat...@corganlabs.com
>>> <mailto:johnat...@corganlabs.com>> (12):
>>>
>>>   qtgui: install vector sink example
>>>   blocks: enable missing multiply_matrix_cc and backport fixes
>>>
>>> Martin Braun <martin.br...@ettus.com <mailto:martin.br...@ettus.com>&g

Re: [Discuss-gnuradio] GNU Radio Release v.3.7.8.1

[Andre Puschmann]

Hi,

thanks Nathan for the update.

I got a question regarding the Live SDR packaging. I'd like to recommend
a few changes and additional packages to be added, for example for
gr-ieee80211 that requires gr-foo. Is there a specific git repo that is
used for compiling the images that I can send a pull request to?

Cheers
Andre


On 01.11.2015 00:58, West, Nathan wrote:
> GNU Radio release v.3.7.8.1 is available for download.
> 
> Tarball:
> http://gnuradio.org/releases/gnuradio/gnuradio-3.7.8.1.tar.gz
> 
> MD5sum:|
> 961d5ba5089f409f0c9e5e5b7f6ee0f2|
> 
> The Live SDR has been updated with this release. Please see:
> 
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
> 
> ...for details on how to obtain and use the Live SDR environment.
> 
> Release notes for v.3.7.8.1 follow:
> 
> Contributors
> 
> 
>  * Ben Hilburn >
>  * Doug Geiger  >
>  * Gwenhael Goavec-Merou  >
>  * Johannes Demel >
>  * Johannes Schmitz  >
>  * Johnathan Corgan  >
>  * Martin Braun >
>  * Nathan West >
>  * Paul Cercueil  >
>  * Philip Balister >
>  * Sean Nowlan  >
>  * Sebastian Koslowski >
>  * Jan Krämer >
>  * Sylvain Munaut 
>  * Tom Rondeau >
> 
> Ben Hilburn > (6):
> 
>   Fixes Coverity Defect 1229872: Memory leak in
> `atsci_equalizer_lms2` DTOR
>   lms_dd_equalizer_cc.h: Fixing simple documentation typo.
>   Addresses Defects 1046385 & 1046340: Out-of-bounds access
>   Addresses Defects 1046385 & 1046340: Buffer not NULL-terminated
>   Fixes Cov Defect 1046011: Resource Leak
>   Fixes Cov Defect 1043301: Unitialized Variable in Conditional
> 
> Doug Geiger  > (1):
> 
>   Bring fix from other pfb_arb_resampler_* variants
> 
> Gwenhael Goavec-Merou  > (1):
> 
>   logger.h.in : sys/types.h is needed for mode_t
> 
> Johannes Demel > (1):
> 
>   fec: xml template doesn't produce duplicate var def's anymore
> 
> Johannes Schmitz  > (1):
> 
>   gr-zeromq: fix python examples
> 
> Johnathan Corgan  > (12):
> 
>   qtgui: install vector sink example
>   blocks: enable missing multiply_matrix_cc and backport fixes
> 
> Martin Braun > (2):
> 
>   qtgui: Fixed vector sink example (block not showing)
>   modtool: Add hint regarding python blocks + makexml
> 
> Nathan West > (5):
> 
>   blocks: add socket_pdu qa
>   blocks: fix destruction and shutdown for socket_pdu
>   blocks: add socket_pdu test using a flowgraph
> 
> Paul Cercueil  > (1):
> 
>   blocks: Fix incorrect size check
> 
> Philip Balister > (1):
> 
>   Fix uhd_rx_nogui so it runs.
> 
> Sean Nowlan  > (2):
> 
>   blocks: import pmt to get GRC to recognize defaults in Tag Object
> GRC bindings
>   trellis: fixed pulse normalization in CPM test script
> 
> Sebastian Koslowski > (7):
> 
>   grc: fix for reverted commit f184ccf 'better Popen argument
> handling...'
>   grc: fix printing empty traceback when a block is missing
>   grc: no block alias param for Options blocks
>   qtgui: indentation fix for number sink GRC wrapper
>   grc: update port key on domain change
>   grc: fix port placement for hidden ports
>   grc: disconnect hidden blocks
> 
> Sylvain Munaut  (2):
> 
>   cmake: Fix warning related to GrSetupQt4 in modern CMake
>   grc/blocks: Fix XML RPC server to allow proper flowgraph termination
> 
> Tom Rondeau > (3):
> 
>   

Re: [Discuss-gnuradio] New random number generator

[Andre Puschmann]

Hi guys,

a few days ago I stumbled over an RNG implementation [2] that uses some
of the newer AVX2 instructions. I guess this would improve performance
radically. There is also a paper on the matter [1].

Cheers
Andre


[1] http://agner.org/random/theory/randomvector.pdf
[2] http://agner.org/random/


On 02.09.2015 15:28, Marcus Müller wrote:
> Hi Stefan,
> 
> strange, I was looking at the same code just a few days ago, when I
> needed to find out whether I understood filters well enough by pushing
> noise through. Here's my small testcases (thankfully I didn't restart my
> machine since then -- these were still in /tmp).
> 
> So, in fact, I tested the performance of boost's mt19937 + boost's
> normal distribution variate, and basically, it's relatively slow,
> indeed; generating 1e8 complex random numbers (meaning 200e8 random
> floats) with a single thread takes
> 
> g++ (GCC) 5.1.1 20150618 (x86_64)
>   test_rnd (Boost)
> g++ -OXXX test_rnd.cpp
>   test_gr (gr::random)
> g++ $(pkg-config --cflags --libs gnuradio-runtime) -OXXX te_gr.cpp
> -O3 (optimized for speed)
>   1.25 s
>   5.92 s
> -O0 (explicitly unoptimized) (default)
>   23.62 s
>   7.13 s
> 
> 
> Someone who cares for speed could get a 5x increase of speed by using
> boost, because that person would be using optimization, anyways.
> However, I can't really explain what happens with boost and the
> unoptimized case; it's really three times as bad as the current
> implementation.
> However, asking perf about this, the -O3 version spends nearly all of
> its time in main(), whereas the -O0 spends most of it in some boost
> functions -- which means that -O3 definitely inlines the calculations,
> and from the disassembly alone I'd say all the stack operations needed
> to jump in and out of routines seem to contribute significantly to the
> problem.
> 
> Of course, that's not really a benchmark for all systems. What about 32
> bit? What about ARM? What about clang? Can anyone try to make a Windows
> build?
> 
> Best regards,
> Marcus
> 
> On 02.09.2015 14:10, Stefan Wunsch wrote:
>> Hi!
>>
>> I have discovered that the implemented random number generator in
>> gnuradio (see file [0]) is almost older than me. As written in the code,
>> the implementation is taken from 'Numerical recipes in C' (see version
>> from 1992). The problem is that this algorithm is really bad compared to
>> current algorithms. E.g. the period length is 1e8 compared to an
>> up-to-date algorithm (Mersenne twister) with a period length of about
>> 1e6000.
>>
>> I have fixed this [1] using boost.random and the mentioned Mersenne
>> twister. Furthermore I have written some test-cases and fixed the
>> transformation to Laplacian random numbers (the current implementation
>> is wrong). As well, I have added the random class to swig so that you
>> can use this in python.
>>
>> Now my question: Before doing a pull request, do you have any concerns
>> regarding memory use or processing load? Obviously the new
>> implementation isn't that light-weight as the ten lines of code before.
>> But the current implementation can not be used in any serious simulation
>> or publication, which is highly dependent on good random numbers. Some
>> information about the performance is given on this page: [2]. Look for
>> the generator mt19937 in table 24.5.
>>
>> Best regards
>> Stefan
>>
>> [0] gnuradio/gnuradio-runtime/lib/math/random.cc
>> [1] https://github.com/stwunsch/gnuradio/tree/newRandom
>> [2]
>> http://www.boost.org/doc/libs/1_59_0/doc/html/boost_random/reference.html
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simulation with MAVLink protocol

[Andre Puschmann]

Hey,

I have the feeling that there maybe a misunderstanding about what
MAVlink really is. The MAVlink protocol as such is serialization library
that is used to transfer information, i.e. serialized data structures,
between mobile and stationary devices rather than a whole communication
system. You can transfer MAVlink messages over any kind of transport
system such as Wifi, bluetooth, Zigbee or any proprietary system.
So what you probably want is to receive and decode the communication of
that transfer system, maybe using GR, and then decode the actual payload
with the MAVlink library.

Cheers
Andre



On 28.06.2014 08:07, Marcus Müller wrote:
 Hi!
 Of course it would be helpful if you had a capture device if your
 motivation was to capture signals of a system. Also, it will give you
 something to test your reception algorithms on.
 Greetings,
 Marcus
 
 On June 28, 2014 6:18:36 AM CEST, Paulo Roberto
 bad_boy_...@hotmail.com wrote:
 
 Hello Marcus, thanks for your answer.
 I have another question, if I have a sdr device like BladeRF or
 HackRF, I will capture the signals without the need of simulating.
 But I will need to decode received signals (what it's not a good
 task), am I correct? In other words, would help me to have the sdr
 device?
 
 Thank you so much.
 
 Paulo.
 
 
 Date: Sat, 28 Jun 2014 02:52:58 +0200
 From: marcus.muel...@ettus.com
 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Simulation with MAVLink protocol
 
 Hi Paulo,
 
 GNU Radio gives you but the framework to write and connect signal
 processing blocks, as well as a nice set of standard blocks.
 Among the functionalities available there are means to generate
 packets and process the same.
 If you know that if you can capture the signal, you could
 mathematically/algorithmically analyze it, it's basically possible
 to implement this in GNU Radio.
 That being said, it's not really easy to implement a complete
 packeted standard in GNU Radio since that might be a logically
 complex task, involving different modulations, synchronization,
 collision detection, arbitration, resend requests and much more.
 However, there are several examples of people being able to decode
 received signals. I like to point gr-ieee802-11 (WLAN packets
 *transceiver*), and for a simpler system gr-air-modes (air traffic
 control message decoding).
 
 Greetings,
 Marcus
 On 27.06.2014 23:12, Paulo Roberto wrote:
 
 Hello, I have some needs and I'd like to know if GnuRadio can help me 
 with it. I have already read some material at GR website and I didn't get the 
 answer.I need to receive and send packets with a specific protocol called 
 MAVLink, used in mini UAVs. More specifically I am thinking about developing 
 a sniffer.I don't have sdr hardware for now, then for starting I am thinking 
 on simulation. My doubts are as follows:
 - Is it possible to implement a new protocol for sending and receive 
 packets? (MAVLink protocol)
 - My idea is to simulate the exchange between a UAV and a control 
 ground station. Would it possible to do it?
 Thanks in advance.
 
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
 
 ___ Discuss-gnuradio
 mailing list Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
 -- 
 Sent from my Android device with K-9 Mail. Please excuse my brevity.
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Post Binary Slicer question

[Andre Puschmann]

Hi,

as I have mentioned a few weeks ago I was working on a GR module that
can be used for receiving and decoding messages sent from TI CC11xx
based devices.

I've now pushed a first version of it to my github repo [1]. It features
a 2-FSK receiver entirely built from stock GR blocks and a deframer with
a message output port that also does de-whitening and CRC checking.

Hope anybody else has use for it.

Cheers
Andre


[1] https://github.com/andrepuschmann/gr-cc11xx


On 02.05.2014 14:46, Andre Puschmann wrote:
 Hi,
 
 By chance I am also working on an OOT module for a CC1100-based device.
 I started out with a Python version as Michael also suggested, but now I
 am migrating it to C++. I actually plan working on it during the EU
 Hackfest next week in Karlsruhe.
 
 John, Jay, perhaps we can create a single module for this as those chips
 are very similar, something like gr-cc110x perhaps.
 
 Cheers,
 Andre
 
 
 
 On 30.04.2014 18:15, John Malsbury wrote:
 Jay,

 As it turns out I am working on an out-of-tree module to work with the
 CC1101, which I think I'll be able to release.  The number of possible
 formats for the frame are relatively few if you know they are using CRC
 and you know the packets aren't fixed length. (use_sequence_number?,
 use_address_field?).  By definition, we know there will be length field
 since these are not fixed length packets.  It would probably just make
 sense to test the handful of options until CRC passes.

 Of course, this changes if the device isn't taking advantage of CC1101s
 packet handling functionality, and instead the MCU is providing more
 than just the payload.  In such a case, there is potentially larger
 feature space for the frame.

 I'll let you know about the CC1101 OOT.

 -John


 On Wed, Apr 30, 2014 at 8:22 AM, Jay Radcliffe jay.radcli...@gmail.com
 mailto:jay.radcli...@gmail.com wrote:

 Maybe I should rephrase: I don't know the entire protocol. I know
 there is a preamble, and I know the sync word.  I know the packets
 are not fixed length, I know there is a CRC. This can all be
 determined from looking at the register settings for the CC1101
 chip.  The format of the data portion of transmission I do not know.
 In order to reverse that I need raw data for analysis. 

 That is how I am handling it right now.  I stream the output of the
 Correlate Access Code to a file sink.  What is in that file though
 is data, not readable binary stream (or readable hex stream). What I
 want is tcpdump like output. 

 Jay Radcliffe
 Twitter: @jradcliffe02
 E-Mail: jay.radcli...@gmail.com mailto:jay.radcli...@gmail.com
 LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02


 On Wed, Apr 30, 2014 at 9:09 AM, John Malsbury
 john.malsb...@ettus.com mailto:john.malsb...@ettus.com wrote:

 Jay,

 If you stream the output of the correlate access code to file,
 and you leave them unpacked, Bit 1 being set will show where the
 sync word is (I think the bit after).  Of course Bit 0 will be
 the data.  This assumes you're using correlate access code, and
 not correlate access code - tag.  This should allow you to
 store everything including the preamble. 

 Also, if you don't know the protocol, how do you know what the
 preamble is?

 -John


 On Tue, Apr 29, 2014 at 1:43 PM, Jay Radcliffe
 jay.radcli...@gmail.com mailto:jay.radcli...@gmail.com wrote:

 The protocol is unknown at this time.  I need to see the
 packets to figure some of this out. 

 Ideally, I would like to see the entire packet (including
 the preamble and sync word) to start to work my way to the
 format of the packets from there.  I am using the power
 squelch with the gate to limit the captures to just when a
 signal is over a certain strength. In a perfect world, I
 would like to have Binary Slicer - File Sink where the
 file contents are the binary stream (10101010101010 not to
 be confused for a binary file) or hex output (0xAA 0xAA).  I
 could probably tag the preamble in with the Correlate Access
 Code? 

 Jay Radcliffe
 Twitter: @jradcliffe02
 E-Mail: jay.radcli...@gmail.com mailto:jay.radcli...@gmail.com
 LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02


 On Sun, Apr 27, 2014 at 9:28 PM, John Malsbury
 john.malsb...@ettus.com mailto:john.malsb...@ettus.com
 wrote:

 Jay,

 Thanks for the inquiry.  Is there a specific protocol or
 format you are trying to work with?  Are the frame size
 fixed in length or variable?  The answers to these
 questions will dictate whether you can use an existing
 block or if you

Re: [Discuss-gnuradio] Post Binary Slicer question

[Andre Puschmann]

Hi,

By chance I am also working on an OOT module for a CC1100-based device.
I started out with a Python version as Michael also suggested, but now I
am migrating it to C++. I actually plan working on it during the EU
Hackfest next week in Karlsruhe.

John, Jay, perhaps we can create a single module for this as those chips
are very similar, something like gr-cc110x perhaps.

Cheers,
Andre



On 30.04.2014 18:15, John Malsbury wrote:
 Jay,
 
 As it turns out I am working on an out-of-tree module to work with the
 CC1101, which I think I'll be able to release.  The number of possible
 formats for the frame are relatively few if you know they are using CRC
 and you know the packets aren't fixed length. (use_sequence_number?,
 use_address_field?).  By definition, we know there will be length field
 since these are not fixed length packets.  It would probably just make
 sense to test the handful of options until CRC passes.
 
 Of course, this changes if the device isn't taking advantage of CC1101s
 packet handling functionality, and instead the MCU is providing more
 than just the payload.  In such a case, there is potentially larger
 feature space for the frame.
 
 I'll let you know about the CC1101 OOT.
 
 -John
 
 
 On Wed, Apr 30, 2014 at 8:22 AM, Jay Radcliffe jay.radcli...@gmail.com
 mailto:jay.radcli...@gmail.com wrote:
 
 Maybe I should rephrase: I don't know the entire protocol. I know
 there is a preamble, and I know the sync word.  I know the packets
 are not fixed length, I know there is a CRC. This can all be
 determined from looking at the register settings for the CC1101
 chip.  The format of the data portion of transmission I do not know.
 In order to reverse that I need raw data for analysis. 
 
 That is how I am handling it right now.  I stream the output of the
 Correlate Access Code to a file sink.  What is in that file though
 is data, not readable binary stream (or readable hex stream). What I
 want is tcpdump like output. 
 
 Jay Radcliffe
 Twitter: @jradcliffe02
 E-Mail: jay.radcli...@gmail.com mailto:jay.radcli...@gmail.com
 LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
 
 
 On Wed, Apr 30, 2014 at 9:09 AM, John Malsbury
 john.malsb...@ettus.com mailto:john.malsb...@ettus.com wrote:
 
 Jay,
 
 If you stream the output of the correlate access code to file,
 and you leave them unpacked, Bit 1 being set will show where the
 sync word is (I think the bit after).  Of course Bit 0 will be
 the data.  This assumes you're using correlate access code, and
 not correlate access code - tag.  This should allow you to
 store everything including the preamble. 
 
 Also, if you don't know the protocol, how do you know what the
 preamble is?
 
 -John
 
 
 On Tue, Apr 29, 2014 at 1:43 PM, Jay Radcliffe
 jay.radcli...@gmail.com mailto:jay.radcli...@gmail.com wrote:
 
 The protocol is unknown at this time.  I need to see the
 packets to figure some of this out. 
 
 Ideally, I would like to see the entire packet (including
 the preamble and sync word) to start to work my way to the
 format of the packets from there.  I am using the power
 squelch with the gate to limit the captures to just when a
 signal is over a certain strength. In a perfect world, I
 would like to have Binary Slicer - File Sink where the
 file contents are the binary stream (10101010101010 not to
 be confused for a binary file) or hex output (0xAA 0xAA).  I
 could probably tag the preamble in with the Correlate Access
 Code? 
 
 Jay Radcliffe
 Twitter: @jradcliffe02
 E-Mail: jay.radcli...@gmail.com mailto:jay.radcli...@gmail.com
 LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
 
 
 On Sun, Apr 27, 2014 at 9:28 PM, John Malsbury
 john.malsb...@ettus.com mailto:john.malsb...@ettus.com
 wrote:
 
 Jay,
 
 Thanks for the inquiry.  Is there a specific protocol or
 format you are trying to work with?  Are the frame size
 fixed in length or variable?  The answers to these
 questions will dictate whether you can use an existing
 block or if you will need to write your own.
 
 Writing a block to parse things after the correlate
 access code block is relatively straight-forward.  If
 you are using the (tag) version of that block, you
 simply need to look for the presence of that tag to
 delineate the start of a frame. 
 
 -John
 
 
 On Sun, Apr 27, 2014 at 4:27 PM, Jay Radcliffe
 jay.radcli...@gmail.com
 

[Discuss-gnuradio] Decoding FSK modulated signal

[Andre Puschmann]

Hey,

I've some home automation equipment here using the sub-ghz band that I
managed to capture with a RTL dongle. From the data sheet and the
register settings of the TI CC1100 transceiver chip that is used inside
the device I figured out the RF parameters used, i.e. 102kHz channel
bandwidth, 2-FSK modulation, 19.2k baudrate, syncbyte etc.

Attached is a screenshot of a GRC waveform I used to capture the
preamble of a single packet. Channel 2 is simply the output of a
quadrature demod block connected to a scope GUI block. I'd like to
decode that into a sequence of bits to run preamble detection etc.

I've seen a few OOT modules that do similar stuff but was wondering if
there is a GR'ish way to this, maybe a set of generic blocks that could
be used for that?

Thanks
Andre

[1] http://i61.tinypic.com/35mjm08.png


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ISWCS 2013 Call for Demonstrations

[Andre Puschmann]

Call for Demonstrations for ISWCS 2013

The Tenth International Symposium on Wireless Communication Systems
(ISWCS) to be held in Ilmenau, Germany, 27-30 August 2013 will offer the
invaluable opportunity to demonstrate novel, innovative and original
research in the area of Software Defined Radio/Cognitive Radio as well
as Future Internet technologies. The goal
of this demonstration session is to provide an opportunity to bridge the
gap between both research fields and to connect world-wide technical
researchers in both areas. Therefore, the session will welcome
contributions presenting novel and innovative demonstrations in one or
both of the above mentioned areas of interest.


Submission Requirements:

The submissions should include an extended abstract of two pages in
accordance with the IEEE author guidelines. The authors should
explicitly state what will be demonstrated to the ISWCS audience, and
how the attendees will be able to interact, enjoy, and experiment. All
submissions must be submitted through EDAS.

The proposals will be evaluated by the ISWCS 2013 demo review committee
based on the following criteria:
– Relevance and novelty of the topic: How important and novel is the
proposed demonstration to the community?
– Interactivity and originality of the idea: What can the conference
attendees observe and how can they interact with the proposed demo?

The extended abstracts of accepted demonstrations will be included in
the proceedings of ISWCS 2013 and in the IEEE Xplore database. The
abstract should include a full list of authors with complete
affiliations. At least one author of each accepted demo is required to
register and present the demo at the conference.


Important Links:

- Conference website: http://www.iswcs2013.org
- EDAS submission: https://edas.info/newPaper.php?c=13295track=32879


Important Dates:

– Demo proposal submission deadline:May 8, 2013
– Notification of acceptance:   May 29, 2013
– Camera-ready version of demo papers:  June 24, 2013


Demonstration Chairs:
-
– Andre Puschmann, Ilmenau University of Technology, Germany
– Thomas Volkert, Ilmenau University of Technology, Germany

Demo Review Committee:
--
– Martin Braun, Karlsruhe Institute of Technology, Germany
– Paul Sutton, CTVR, Trinity College, Ireland
– Joseph Gaeddert, Virginia Tech, USA
– Tomaž Šolc, Jožef Stefan Institute, Slovenia
– Oliver Waldhorst, Karlsruhe Institute of Technology, Germany
– Paul Müller, University of Kaiserslautern, Germany
– Thomas Magedanz, TU Berlin/Fraunhofer FOKUS, Germany
– Thomas Dreibholz, Simula Innovation AS, Norway
– Florian Liers, Ilmenau University of Technology, Germany


-- 
Andre Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Cognitive Radio Network Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: andre.puschm...@tu-ilmenau.de, Web: http://www.tu-ilmenau.de/crng
Office: Zuse Building, corridor f, room 1071

PGP/GnuPG key: 2C734140
fingerprint: 546F F71F 3185 0388 94C3 FA7A DDE6 00B9 2C73 4140


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Updated UCLA ZigBee / IEEE802.15.4 blocks

[Andre Puschmann]

On 03/05/2013 06:16 PM, Bastian Bloessl wrote:
 I updated the UCLA ZigBee blocks[1] to GNU Radio v3.6.4 (current master
 branch) and uploaded them to Github:

Great! Thanks for your effort Bastian. I always wanted to do this but
actually never found the time

-Andre


-- 
Andre Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Cognitive Radio Network Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: andre.puschm...@tu-ilmenau.de, Web: http://www.tu-ilmenau.de/crng
Office: Zuse Building, corridor f, room 1071

PGP/GnuPG key: 2C734140
fingerprint: 546F F71F 3185 0388 94C3 FA7A DDE6 00B9 2C73 4140


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tunnel.py command not working.

[Andre Puschmann]

On 02/26/2013 06:55 PM, Sajjad Safdar wrote:
 HI,
 I am using tunnel.py command to setup a TCP/IP link between two usrp1.
 When i try to use the command , i get this error
 
 ./tunnel.py
 linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.001-29-g3cb515f7
 
 Traceback (most recent call last):
   File ./tunnel.py, line 295, in module
 main()
   File ./tunnel.py, line 241, in main
 (tun_fd, tun_ifname) = open_tun_interface(options.tun_device_filename)
   File ./tunnel.py, line 79, in open_tun_interface
 ifs = ioctl(tun, TUNSETIFF, struct.pack(16sH, gr%d, mode))
 IOError: [Errno 1] Operation not permitted

Try running it with root rights, i.e. sudo ./tunnel.py. Also make sure
that the device actually exists, run ifconfig tun0.

-Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] VTC Québec user meeting

[Andre Puschmann]

Hi all,

I was just wondering whether anybody of you guys is going to attend the
IEEE VTC conference next week in Québec, Canada. If yes, would anybody
be interested in having an informal GNU Radio/USRP/SDR community meeting
or anything like this?

Thanks
-Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[Andre Puschmann]

George,

On 03/04/2012 12:51 AM, George Nychis wrote:
 Hi all,
 
 I'm going to be hacking carrier sense in to the FPGA on the USRP2 very
 soon.  Basically, taking what I did with the in-band project from the
 USRP1 with carrier sense, and moving it forward to USRP2. 
 
 The idea is, just like you can set a timestamp to gate a packet on its
 way out: only transmit it at time X, you can do something similar with
 carrier sense.  If the burst has the carrier sense flag set, then you
 wait for the carrier to become idle, then transmit the packet.
 
 For the in-band implementation, I had a command to set the value at
 which the carrier is determined to be busy/idle.  This was stored in
 memory in the FPGA.  Then, when bursts came with a carrier sense bit
 set, that value is used.
 
 OK:  so I'd like to re-do this implementation to keep this kind of stuff
 alive, and I will use it myself.  But in doing so, I'd like to implement
 it in a way that jives well with the higher ups.  If I'm going to do it,
 I'd like to do it right so that it lives on through future versions of
 GNU Radio.  So that means doing it using UHD.
 
 For the life of me, I can't find the UHD header spec.  But I imagine
 somewhere in there we can fit a bit to gate based on carrier sense, and
 a new command to set the carrier sense threshold.
 
 If you have any advice/guidance on how you'd like to see this
 implemented, let me know.  I sincerely would like this to live long and
 prosper in GNU Radio and the USRPs.

I totally like and support your idea and would love to help realizing
it. Using the timestamp logic inside UHD as a reference is a great idea
that also came to my mind a while ago.
There are a few things from the architecture point of view though that
need to be discussed. Let's take a CSMA MAC as an example, I guess that
goes into the right direction :-) Just having the if channel free,
transmit packet-logic inside the FPGA wouldn't make much sense in a
multi-user environment. What would happen is that if the channel is busy
and multiple nodes have packets in their tx queues, they would all end
up sending their packets more or less at the same time after the channel
gets idle again (assuming all nodes are in sensing range). In a
practical system, one would now start to move parts of the CSMA state
machine, i.e the random backoff, into the FPGA. Trying to control this
via UHD is probably a bad idea as UHD's main business is transportation.

I do think we need something like what you have suggested but I am still
a bit puzzled about the right way of implementing it.

Best regards,
Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[Andre Puschmann]

On 03/04/2012 04:01 PM, Marcus D. Leech wrote:
 George,

 I do think we need something like what you have suggested but I am still
 a bit puzzled about the right way of implementing it.

 Best regards,
 Andre

 I think a more fundamental issue is that carrier sense isn't actually
 defined in any kind of general way.  Certainly for *some* types of
   PHYs, you can do simple energy-presence detection.  But usually, it's
 more complicated than that, and it varies widely from PHY to
   PHY.  In some, you'll need to run a correlator before you even know
 whether the channel is busy or not.  In others, simple energy
   detection works.
 
 I don't think there's a general-purpose way of doing this, but that's
 just my POV.

You're absolutely right, Marcus. I also think it'd be quite difficult to
find a truly general-purpose solution to that.

Knowing George's field of interested, I was assuming something like a
simple energy detector. I think even this simple example shows the
difficulties quite clearly.

-Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[Andre Puschmann]

On 03/04/2012 04:10 PM, George Nychis wrote:
 
 I totally like and support your idea and would love to help realizing
 it. Using the timestamp logic inside UHD as a reference is a great idea
 that also came to my mind a while ago.
 There are a few things from the architecture point of view though that
 need to be discussed. Let's take a CSMA MAC as an example, I guess that
 goes into the right direction :-) Just having the if channel free,
 transmit packet-logic inside the FPGA wouldn't make much sense in a
 multi-user environment. What would happen is that if the channel is busy
 and multiple nodes have packets in their tx queues, they would all end
 up sending their packets more or less at the same time after the channel
 gets idle again (assuming all nodes are in sensing range). In a
 practical system, one would now start to move parts of the CSMA state
 machine, i.e the random backoff, into the FPGA. Trying to control this
 via UHD is probably a bad idea as UHD's main business is transportation.
 
 I do think we need something like what you have suggested but I am still
 a bit puzzled about the right way of implementing it.
 
 
 Hi Andre,
 
 Yeppp, the idea is to build part of the MAC in to the FPGA... the part
 that requires low latency operation.  So, after the simple transmit
 when idle logic, you put some basic form of back off in to the logic
 also.  
 
 I have a paper which argues low latency MAC functionality should be
 built in to the FPGA, but controlled from the host, otherwise it's as
 good as worthless implementing it on the host.  If you try to build this
 part of the MAC at the host, the latency of receiving the channel state
 (latency from FPGA - host), making a decision and performing an action
 (host - FPGA), completely makes the information stale.  You end up with
 a decision that is something like 1-2ms old, which clearly the state of
 the channel changes at a more finer-grain than that.

Well, I believe it's just a matter of scaling the whole system by the
right factor. Information that is 1ms old can still be valuable if it
still represents the truth.

I just don't want to loose all the flexibility of software by moving the
critical but interesting things to hardware.

But of course, it all depends upon your goals.

-Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs

[Andre Puschmann]

On 02/26/2012 10:38 AM, Apurv Bhartia wrote:
 Hi,
 
 I'm running Ubuntu 11.10 + UHD 003.004.000 + USRP2.
 
 I'm trying to run a transceiver script for OFDM, which has both the tx
 and rx flowgraphs (very similar to tunnel.py except the TUN interface).
 But, I can't seem to receive anything successfully in that case. Even
 the preamble correlation fails, it barely sees anything substantial in
 the air at the RF end.
 On the other hand, if I just disable the uhd_transmitter in the script,
 the receiver then works just about great.
 
 I've run the transceiver script earlier on USRP2 with the eth driver -
 could it be something to do with the UHD? Is it possible that the
 transmitter is in some way locking the receiver?
 
 P.S: Individually, tx and rx work just fine.

You did not mention which daughterboard you're using. If it's the
XCVR2450 db and you continuously transmit you sort of block your
receiver indeed. That's because the XCVR2450 is only half-duplex.

-Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Meet SDR guys IRL: Karlsruhe WSR

[Andre Puschmann]

On 02/15/2012 12:25 PM, Martin Braun wrote:
 Hi everyone,
 
 some updates: I have booked a table at Vogelbräu for 19:30 on Tuesday
 6 March.
 The adress is Kapellenstrasse 50 (or www.vogelbraeu.de for an
 IP-compatible adress :).
 It's a pretty decent Microbrewery, the food's good, so if you've been
 travelling, here's the place to get that stomach filled.

Thanks. Added to my calendar.

-Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] E100 compile error: trondeau safe_align branch

[Andre Puschmann]

On 02/16/2012 07:16 PM, Philip Balister wrote:
 /tmp/cct93Ve1.s:37: Error: bad instruction `vpadd.f32 d0,d16,d17'
 /tmp/cct93Ve1.s:38: Error: bad instruction `vadd.f32 s16,s0,s1'
 make[2]: *** 
 [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o]
  Error 1
 make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2
 make: *** [all] Error 2

 Any hints/ideas? Thanks!
 
 I feel like the flags from the toolchain file are not getting through to
 gcc, try passing the compiler flags via the command line.

For some reason it's not working for me either. I'm always passing the
parameters via command line. Not sure whether it's a CMake issue. Is it
working for everybody else?

-Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Meet SDR guys IRL: Karlsruhe WSR

[Andre Puschmann]

On 02/02/2012 01:30 PM, Martin Braun wrote:
 Hope to see some of you guys there!

We'll be there, really looking forward to meeting you guys! I guess most
of the attendees arrive the day before, i.e. March 6. How about a warm
glass of milk the night before the workshop? Anybody interested?

-Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Meet SDR guys IRL: Karlsruhe WSR

[Andre Puschmann]

On 02/03/2012 11:41 AM, Martin Braun wrote:
 that's a great idea. Some might disagree about the choice of beverage,

I reckon you're right! I might revise my choice as well :-)


 I'll book a table somewhere downtown and answer here about the location

Awesome!

-Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [gnuradio 3.5.0] libgnuradio-core.so: undefined reference to `fftwf_free'

[Andre Puschmann]

On 12/27/2011 12:16 PM, klo uo wrote:
 If you build fftw manually, please check if you configured it with
 '--enable-single --enable-shared' otherwise, only the fixed-point
 version will be built.
 
 
 I did build fftw manually with noted switches as I wrote in my first mail:
 
 ./configure --enable-single --enable-shared --enable-sse2
 --prefix=$HOME/.local
 
  
 
 Also, you can verify after installation via 'ls
 -l /usr/local/lib/libfftw*'. I assume you only see libfftw3.so not
 libfftw3f.so, right?
 
  
 Here is output of `ls -l ~/.local/lib/libbfft*` as I configured gnuradio
 as explained in my first mail:
 
 $ *ls -l ~/.local/lib/libfftw**
 -rw-r--r-- 1 klonuo klonuo 2283452 2011-12-27 08:14
 /home/klonuo/.local/lib/libfftw3f.a
 -rwxr-xr-x 1 klonuo klonuo 962 2011-12-27 08:14
 /home/klonuo/.local/lib/libfftw3f.la http://libfftw3f.la
 lrwxrwxrwx 1 klonuo klonuo  18 2011-12-27 08:14
 /home/klonuo/.local/lib/libfftw3f.so - libfftw3f.so.3.3.0
 lrwxrwxrwx 1 klonuo klonuo  18 2011-12-27 08:14
 /home/klonuo/.local/lib/libfftw3f.so.3 - libfftw3f.so.3.3.0
 -rwxr-xr-x 1 klonuo klonuo 1419867 2011-12-27 08:14
 /home/klonuo/.local/lib/libfftw3f.so.3.3.0

Ok, then according to your output in the last post, gnuradio
configuration did not set the paths correctly.

 libtool: link: g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o
 .libs/gnuradio-config-info gnuradio-config-info.o
 ./.libs/libgnuradio-core.so -L/usr/lib -lboost_program_options-mt
 -lboost_filesystem-mt /usr/lib/libltdl.so -pthread -Wl,-rpath
 -Wl,/home/klonuo/.local/lib


Two things are missing, the linker command does not include the library
(i.e. -lfftw3f) and not the library path (-L/home/klonuo/.local/lib).
The latter is instead just appended to that last command which is wrong.

FFTW3F_LIBS should be something like this '-L$HOME/.local/lib -lfftw3f'

BR
Andre


 
 
 
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MAC layer questions

[Andre Puschmann]

On 07/06/2011 07:33 PM, Morgan Redfield wrote:
 I'm still working on my MAC, and there's a lot of room for
 improvement. At the moment, I get throughput of about 1kbps. What kind
 of throughput are you getting?

In a setup of two nodes we have a end-to-end throughput (measured using
iperf using TCP as transport protocol) of around 150-200 kbps. But that
certainly depends on physical layer parameters as well. At the moment we
use a sampling rate of 1Mbps and Bpsk modulation.
Parameters still need to be fine-tuned (SIFS, DIFS, etc.), so there is
definitely room for improvements. What PHY are you using?

Regards,
Andre



 
 Andre and George, thanks for pointing me to those papers. I'll look
 through them and see if I can figure out any ways to improve my MAC.
 
 Morgan
 
 On Tue, Jul 5, 2011 at 4:30 AM, Andre Puschmann
 andre.puschm...@tu-ilmenau.de wrote:
 On 07/01/2011 03:16 AM, Morgan Redfield wrote:
 Hi,

 I've been working on building a CSMA/CA MAC for the past couple of
 weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's
 working now, but I don't think it's very efficient. I ended up having
 to relax a lot of timing parameters to get it working, so my
 throughput is pretty bad. I also get a lot of dropped packets. I think
 this is also because my timing isn't very accurate, and I end up with
 more collisions than I would expect.

 I was wondering if anyone else had had any luck building a CSMA/CA
 MAC. I saw a few posts on the mailing list from several years ago
 about people who were working on it, but I don't see any example code
 anywhere. I also checked out CMUmacs on CGRAN, but that relies on a
 deprecated version of GNURadio.

 Is my best bet to rewrite the MAC as a block in C++? Can anyone tell
 me what kind of speedup that's likely to get me?

 Thanks,
 Morgan Redfield

 Hi Morgan,

 we are also working on a CSMA/CA MAC here using a SDR software called
 Iris (I know that's the GNU radio list but problems are pretty much the
 same in terms of timing). The implementation is still not perfect but we
 got some nice results already.

 May I ask you about the throughput of your system? I would really like
 to compare them with our setup.

 There is also another paper titled An IEEE 802.11 MAC Software Defined
 Radio Implementation for Experimental Wireless Communications and
 Networking Research which might be of interest for you.


 Regards,
 Andre


 --
 André Puschmann
 Ilmenau University of Technology, Integrated Communication Systems Group
 Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
 Email: andre.puschm...@tu-ilmenau.de, Web: http://www.tu-ilmenau.de/ics
 Office: Zuse Building, room 1071


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-- 
André Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: andre.puschm...@tu-ilmenau.de, Web: http://www.tu-ilmenau.de/ics
Office: Zuse Building, room 1071


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MAC layer questions

[Andre Puschmann]

On 07/06/2011 07:33 PM, Morgan Redfield wrote:
 I'm still working on my MAC, and there's a lot of room for
 improvement. At the moment, I get throughput of about 1kbps. What kind
 of throughput are you getting?

In a setup of two nodes we have a end-to-end throughput (measured using
iperf using TCP as transport protocol) of around 150-200 kbps. But that
certainly depends on physical layer parameters as well. At the moment we
use a sampling rate of 1Mbps and Bpsk modulation.
Parameters still need to be fine-tuned (SIFS, DIFS, etc.), so there is
definitely room for improvements. What PHY are you using?

Regards,
Andre



 
 Andre and George, thanks for pointing me to those papers. I'll look
 through them and see if I can figure out any ways to improve my MAC.
 
 Morgan
 
 On Tue, Jul 5, 2011 at 4:30 AM, Andre Puschmann
 andre.puschm...@tu-ilmenau.de wrote:
 On 07/01/2011 03:16 AM, Morgan Redfield wrote:
 Hi,

 I've been working on building a CSMA/CA MAC for the past couple of
 weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's
 working now, but I don't think it's very efficient. I ended up having
 to relax a lot of timing parameters to get it working, so my
 throughput is pretty bad. I also get a lot of dropped packets. I think
 this is also because my timing isn't very accurate, and I end up with
 more collisions than I would expect.

 I was wondering if anyone else had had any luck building a CSMA/CA
 MAC. I saw a few posts on the mailing list from several years ago
 about people who were working on it, but I don't see any example code
 anywhere. I also checked out CMUmacs on CGRAN, but that relies on a
 deprecated version of GNURadio.

 Is my best bet to rewrite the MAC as a block in C++? Can anyone tell
 me what kind of speedup that's likely to get me?

 Thanks,
 Morgan Redfield

 Hi Morgan,

 we are also working on a CSMA/CA MAC here using a SDR software called
 Iris (I know that's the GNU radio list but problems are pretty much the
 same in terms of timing). The implementation is still not perfect but we
 got some nice results already.

 May I ask you about the throughput of your system? I would really like
 to compare them with our setup.

 There is also another paper titled An IEEE 802.11 MAC Software Defined
 Radio Implementation for Experimental Wireless Communications and
 Networking Research which might be of interest for you.


 Regards,
 Andre


 --
 André Puschmann
 Ilmenau University of Technology, Integrated Communication Systems Group
 Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
 Email: andre.puschm...@tu-ilmenau.de, Web: http://www.tu-ilmenau.de/ics
 Office: Zuse Building, room 1071


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-- 
André Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: andre.puschm...@tu-ilmenau.de, Web: http://www.tu-ilmenau.de/ics
Office: Zuse Building, room 1071


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MAC layer questions

[Andre Puschmann]

On 07/06/2011 07:33 PM, Morgan Redfield wrote:
 I'm still working on my MAC, and there's a lot of room for
 improvement. At the moment, I get throughput of about 1kbps. What kind
 of throughput are you getting?

In a setup of two nodes we have a end-to-end throughput (measured using
iperf using TCP as transport protocol) of around 150-200 kbps. But that
certainly depends on physical layer parameters as well. At the moment we
use a sampling rate of 1Mbps and Bpsk modulation.
Parameters still need to be fine-tuned (SIFS, DIFS, etc.), so there is
definitely room for improvements. What PHY are you using?

Regards,
Andre



 
 Andre and George, thanks for pointing me to those papers. I'll look
 through them and see if I can figure out any ways to improve my MAC.
 
 Morgan
 
 On Tue, Jul 5, 2011 at 4:30 AM, Andre Puschmann
 andre.puschm...@tu-ilmenau.de wrote:
 On 07/01/2011 03:16 AM, Morgan Redfield wrote:
 Hi,

 I've been working on building a CSMA/CA MAC for the past couple of
 weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's
 working now, but I don't think it's very efficient. I ended up having
 to relax a lot of timing parameters to get it working, so my
 throughput is pretty bad. I also get a lot of dropped packets. I think
 this is also because my timing isn't very accurate, and I end up with
 more collisions than I would expect.

 I was wondering if anyone else had had any luck building a CSMA/CA
 MAC. I saw a few posts on the mailing list from several years ago
 about people who were working on it, but I don't see any example code
 anywhere. I also checked out CMUmacs on CGRAN, but that relies on a
 deprecated version of GNURadio.

 Is my best bet to rewrite the MAC as a block in C++? Can anyone tell
 me what kind of speedup that's likely to get me?

 Thanks,
 Morgan Redfield

 Hi Morgan,

 we are also working on a CSMA/CA MAC here using a SDR software called
 Iris (I know that's the GNU radio list but problems are pretty much the
 same in terms of timing). The implementation is still not perfect but we
 got some nice results already.

 May I ask you about the throughput of your system? I would really like
 to compare them with our setup.

 There is also another paper titled An IEEE 802.11 MAC Software Defined
 Radio Implementation for Experimental Wireless Communications and
 Networking Research which might be of interest for you.


 Regards,
 Andre


 --
 André Puschmann
 Ilmenau University of Technology, Integrated Communication Systems Group
 Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
 Email: andre.puschm...@tu-ilmenau.de, Web: http://www.tu-ilmenau.de/ics
 Office: Zuse Building, room 1071


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-- 
André Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: andre.puschm...@tu-ilmenau.de, Web: http://www.tu-ilmenau.de/ics
Office: Zuse Building, room 1071


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MAC layer questions

[Andre Puschmann]

On 07/01/2011 03:16 AM, Morgan Redfield wrote:
 Hi,
 
 I've been working on building a CSMA/CA MAC for the past couple of
 weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's
 working now, but I don't think it's very efficient. I ended up having
 to relax a lot of timing parameters to get it working, so my
 throughput is pretty bad. I also get a lot of dropped packets. I think
 this is also because my timing isn't very accurate, and I end up with
 more collisions than I would expect.
 
 I was wondering if anyone else had had any luck building a CSMA/CA
 MAC. I saw a few posts on the mailing list from several years ago
 about people who were working on it, but I don't see any example code
 anywhere. I also checked out CMUmacs on CGRAN, but that relies on a
 deprecated version of GNURadio.
 
 Is my best bet to rewrite the MAC as a block in C++? Can anyone tell
 me what kind of speedup that's likely to get me?
 
 Thanks,
 Morgan Redfield

Hi Morgan,

we are also working on a CSMA/CA MAC here using a SDR software called
Iris (I know that's the GNU radio list but problems are pretty much the
same in terms of timing). The implementation is still not perfect but we
got some nice results already.

May I ask you about the throughput of your system? I would really like
to compare them with our setup.

There is also another paper titled An IEEE 802.11 MAC Software Defined
Radio Implementation for Experimental Wireless Communications and
Networking Research which might be of interest for you.


Regards,
Andre


-- 
André Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: andre.puschm...@tu-ilmenau.de, Web: http://www.tu-ilmenau.de/ics
Office: Zuse Building, room 1071


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Latency measurements with Unix-domain sockets

[Andre Puschmann]

On 05/31/2011 10:54 AM, Alexander Chemeris wrote:
 On Tue, May 31, 2011 at 03:07, Marcus D. Leech mle...@ripnet.com wrote:
 I used the following two little programs:
 skip

 And found no significant difference in peak and average latencies
 between them.

 The unixdomain_server takes a single command-line argument which tells
 it how many samples
  to average over before producing a printed result.

 So this confirms my earlier assertion that I would be surprised to find
 a significant latency difference
  between Unix-domain sockets and FIFOs, since the interior kernel
 mechanisms are broadly similar.
  Basically--some chunk of memory is copied from one place to another,
 there's some housekeeping, and
  the system-call interface is traversed a couple of times.
 
 Let me contradict. Maximum latency is *much* better - less then 80us
 instead of 3ms.
 
 Data attached as usual.  Tests were run with 'chrt 80 ./runtest_sh'
 
 PS I test on Core 2 Duo 1.6 GHz with all the GUI stuff running.

Just did both tests on my machine here, Intel Core i5 notebook.

I couldn't find such a high latency (3ms). Indeed, both are performing
pretty much the same. I would even say that on my box, the pipe
mechanism does even better in terms of jitter. I didn't calculate mean
and standard deviation but from the plot it looks like the values are
closer together.

Cheers,
Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FIFO latency

[Andre Puschmann]

On 05/29/2011 10:22 AM, Alexander Chemeris wrote:
 On Sun, May 29, 2011 at 03:05, Marcus D. Leech mle...@ripnet.com wrote:
 On 05/28/2011 04:28 PM, Alexander Chemeris wrote:

 So, while this method is simple and good for non-realtime
 applications, it doesn't fit our needs. It may be usable for PHY-MAC
 interaction, but even here I'm not sure it would work well.

 PS I test on Core 2 Duo 1.6 GHz with all the GUI stuff running.

 Ok, setting CPU affinity and cutting off startup artifacts definitely
 helps.
 Results are in attachment.
 Still you can see quite some uncertainty.

 OK, so a roughly 3:1 improvement in peak latency, and somewhat better
 predicability.

 But I'd still counter-assert, to your assertion, that latencies in the
 10s-of-usec are entirely acceptable for
  a wide-range of real-time applications, even with occasional latency
 excursions that increase the variability
  by 50:1 or so.

 I can well imagine that they aren't acceptable for *your* application.  I
 mean, if all applications were the same, it would
  be a very boring world, with most of us working at fast-food restaurants
 :-)

 But I'll stand by my original suggestion that use of FIFOs are an acceptable
 technique for a wide variety of applications, including
  real-time applications, depending on constraints and requirements.
 
 Sure, I don't say that no one should use queues :)
 I just want to say that it may not be suitable for applications with
 more tight requirements - i.e. some alternative may be needed.
 
 But to say truth - I'm surprised by their performance, I thought it
 would be much worse. So it may be a good starting point from which we
 could refine later.
 

Linux' pipe implementation is known to be quite slow. I would suggest to
use UNIX sockets instead. They should perform much better in terms of
latency and performance.

Cheers,
Andre


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FIFO latency

[Andre Puschmann]

On 05/30/2011 03:55 PM, Marcus D. Leech wrote:
 On 30/05/2011 9:51 AM, Alexander Chemeris wrote:

 Linux' pipe implementation is known to be quite slow. I would suggest to
 use UNIX sockets instead. They should perform much better in terms of
 latency and performance.
 Good idea.

 I'm dubious of such a claim--the core mechanisms between Unix-domain
 sockets and FIFOs are very similar.
 
 While it's true that it *used* to be the case that pipes/FIFOs were
 handled as disk files, that's no longer true--they
   just implement ring-buffer objects within the kernel, and Unix-domain
 sockets are also quite similar--in fact, they
   are likely higher overhead, because they have to go through the
 labyrinthine socket stack, which FIFOs don't.
 
 I did my part to put together a FIFO test, so if someone wants to do a
 Unix-domain socket benchmark we could settle
   that question.

There are various papers out there dealing with IPC mechanisms in Linux.
There is at least one [1] that indicates that IPC is performing quite
good. On the other hand, I've seen others claiming the opposite.
Unfortunately, I don't have any recent performance measurements
available personally. But I agree, would be interesting to see some
up-to-date benchmark results.

Cheers,
Andre


[1] http://osnet.cs.binghamton.edu/publications/TR-20070820.pdf




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio