Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[Piotr Krysik]

Is there some good candidate that can be asked to do that? When I search
for rtlsdr driver the first page with actual source code is osmocom's site:

sdr.osmocom.org/trac/wiki/rtl-sdr

Maybe they have the maintainer who feels responsible for how this code
works?
I can try to correct this offset in software (especially if it doesn't
change too often) but it doesn't seem as the optimal solution. Frequency
offset estimation might not be perfect either.

--
Piotr

W dniu 25.05.2016 o 21:36, mle...@ripnet.com pisze:
>
> The AirSpy uses the R820T2 chip for the tuner, but a different
> sampling/DSP "engine".
>
> Yes, making the charge-pump and "dither" mods will help with
> phase-coherence.
>
> Somebody needs to "own" the rtlsdr driver, and merge in the last
> couple of years of field experience and branching that has gone on
> with it.
>
>  
>
>  
>
>  
>
> On 2016-05-25 15:04, Piotr Krysik wrote:
>
>> Hi Marcus,
>>
>> I don't know much about AirSpy.
>>
>> Does it use the same demodulator chip as current RTL-SDR dongles?
>> And does it mean that change to low level part of rtlsdr driver might
>> help to get rid of that frequency offset?
>>
>> --
>> Piotr
>>
>> W dniu 25.05.2016 o 16:35, mle...@ripnet.com
>>  pisze:
>>>
>>> There are a couple of issues with the rtlsdr driver used by gr-osmocom
>>> in this regard:
>>>
>>>  
>>>
>>>   (A) The charge-pump loop current is too constrained for the higher
>>> frequencies
>>>
>>>   (B) The "dither" option appears to have a bias that causes a (small)
>>> frequency offset.
>>>
>>>  
>>>
>>> The driver that AirSpy uses fixes both of these, although without
>>> "dither", the tuning granularity is worse.  Not sure this matters.
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>> On 2016-05-25 09:28, Marcus Müller wrote:
>>>
 That, or simply, the output clock VCO changes its reaction to the
 control voltage under certain circumstances (temperature, frequency) so
 much that the control loop loses the ability to reach stationary
 exactness (e.g. due to natural limits on the magnitude of the VCO
 voltage). These devices definitely were made with cost in mind – not
 with maximum reliability, and hence I can believe that for example with
 the Elonics E4000 tuner, the charge pump used to generate the VCO
 voltage simply might deteriorate with temperature.

 Cheers,
 Marcus

 On 25.05.2016 14:25, Sylvain Munaut wrote:
> Hi,
>
>> of the drift remains a mistery (probably due to the implementation
>> of the PLL,
>> but I cannot understand why Phase Locked Loops would drift in
>> Phase !).
> If the phase comparator is digital ( i.e. a XOR ) and the input clock
> is somewhat analog, the gate thresholds might vary depending on
> temperature, thus shifting the cycle a bit.
>
> Just a thought.
>
> Cheers,
>
> Sylvain
>
> ___
>>


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

Re: [Discuss-gnuradio] Syncronization issues, using a GPSDO

[Meelis Nõmm]

@Nick No this effect I see after the GPSDO already has a lock and is
running (is powered) for more than 30min.

@Andy Interesting. I agree, I also plan to use the hack, but would really
like to try to find the root cause. Also, maybe I stumbled on something
useful that the Ettus guys can use to improve the USRPs.

@Marcus I'm using both N200 and N210.
I just wonder that could it be that once the program is started, either in
the GPSDO oscillator control loop or in the USRP motherboard clock
generator a sync process is started that otherwise in standby mode is not
running.

I expect that while powered the GPSDO module continuously receives the GPS
signals and syncs the 10MHz reference, irrelevant of the FPGA running a
program (using the 10MHz) or not . If this is so, then this effect is not
related to the GPSDO. Unless, this is not true and the GPSDO is affected by
the motherboard starting to use the 10 MHz reference. [Another topic, but I
have also witnessed that if a signal is fed to 2 USRPs through a splitter,
in the received signals I can see when the other USRP starts its program.
In the one that starts before, the received signal level is reduced, once
the other starts].

This leaves us the USRP motherboard clock generation circuitry that uses
the GPSDO 10MHz reference to derive the 100MHz ADC clock, from where
finally we get to the 10 MSps. I do not know the inner behaviour of the
clock generation circuitry, but to me it seems that once a program is
started in the FPGA, a certain process is started that slightly affects the
ADC clock over the first 3-5 minutes. Only after this period the clock is
truly stable and synced with the GPSDO. Once the program is stopped the
clock is "released" from the GPSDO ref and starts to diverge again, if the
program is restarted quickly, the clock is still synced well enough and we
don't see the given effect, but if the pause is longer the circuitry starts
syncing again and we see the effect in the delays.

If this is true. I wonder if there was a way to keep the USRP motherboard
syncing the clock in the clock generation unit all the time?

Meelis


On Tue, May 24, 2016 at 7:34 PM, Andy Walls 
wrote:

> On Tue, 2016-05-24 at 10:37 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:
> > Date: Tue, 24 May 2016 17:37:35 +0300
> > From: Meelis N?mm 
>
> > Hello everyone,
> >
> >
> > I have been working on a positioning implementation and for that I need
> > very good time synchronization between the USRPs that are geographically
> > not in the same location. Considered a few possibilities, but decided to
> > test out the GPSDO modules for the time sync (also provides the needed 10
> > MHz). In order to measure the time sync, I?m periodically feeding both
> > USRPs with the same frequency sweep signal, storing the interesting
> > sections and calculating the delay between them via correlation.
> >
> >
> > Overall it seems to work, but I?m witnessing an interesting effect. As I
> > start the program, within the first 4-5 minutes the time delay between
> the
> > USRPs increases from (near) 0 to about 4-5 samples (400-500ns, with 10
> > MSps). Once this phase is done, the delay between the USRPs stabilizes
> and
> > the two seem to be quite well synchronized. I have attached delay plots
> > from 2 different runs (this behavior I can reproduce every time).  If I
> > restart the python program after the ?warmup? phase, the delay is very
> well
> > restricted and clocks seem well synchronized (restart is denoted by the
> > vertical line). It is also worth pointing out that the pause between the
> > restarts is short (around 15 seconds), if I make the pause longer (more
> > than 60 seconds or so) the results again exhibit a ?warmup? phase (figure
> > "delays_result65_1"), but usually a bit less emphasized.
>
> I've run into a similar effect with a host using NTP and the PPS and
> $GPRMC sentence from X310 USRP.
>
> I have a USRP-time vs. Host-time monitoring loop, and I see the USRP
> time diverge from NTP time usually twice after startup: once immediately
> after the streaming initialization (understandable), and then another
> smaller jump some time later (I can't explain).
>
> https://lists.gnu.org/archive/html/discuss-gnuradio/2014-06/msg00326.html
>
> >
> > Would like to know what causes this effect? It does not seem to come from
> > the USRP clock sync python code (relevant code given below), as after the
> > fast restart the effect is not present. Right now to me, it seems that in
> > the GPSDO, or in the FPGA clock sync, a certain (lock) ?warmup? phase is
> > done, once the FPGA starts to use the 10 MHz output. If the program is
> > restarted fast enough, the clocks are still in sync, but if the pause is
> > long enough the clock sync process(es) can be seen again?
>
> >Any thoughts?
>
> I was lucky enough to work up a fix with a USRP-time vs. Host-time
> tracking loop, without knowing the root cause.
>
> If you can find a solution for your problem without knowing the root
>

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi Ben,

thank you for your interest and feedback!

To your first question: The desired behaviour of the signal detector would
be to recognize a multi-carrier system (like OFDM) as one signal, since all
the carriers are needed to transmit the information. If the frequency
resolution is very fine, as you mentioned, the problem occurs that
different subcarriers get interpreted as different signals since low-energy
bins occur between them.
To be honest, a software will not be able to distinguish between two close
incoherent signals and two subcarriers in a multi-carrier system, unless
additional information is provided. One way to do this is to do further
analysis of the signals and determine wether they "belong together", but
I'm afraid this is much more work than I can do during the GSoC program.
Another way would be to set a minimum absolute frequency spacing, under
which the signals get interpreted as one. But I really don't want to
hard-code any values in order to maintain maximum versatility of the
inspector.
So, to come to an actual answer, at this point the user has to find out by
himself for now. For this reason it will be possible to select the signals
manually in the GUI and select what gets mixed down and filtered for the
succeeding signal chain.

Your second question targets the waterfall ability of the toolbox. The idea
is (if time allows) to use a waterfall plot instead of a spectrum plot in
order to be able to analyze signals from the past (imagine the waterfall
plot with red rectangles where signals were detected). This can become
handy if signals are only present for a short time. In this case, an
observation will be characterized by frequency band and start/stop time,
instead of only frequency band as it is for now. If such a burst signal is
detected, it will be filtered by the Signal Separator and will be stored
until it disappears from the waterfall plot, so it will be analyzable for a
much longer time period.
Nevertheless the inspector will of course be able to work on file sources
with manually recorded signals.

I hope I could provide sufficient answers to your questions!

Also, I want to encourage the whole community to give feedback, especially
on the mentioned questions at the end of the blog post:
https://grinspector.wordpress.com/2016/05/20/let-the-coding-begin/

Stay tuned for this week's blog post (likely on friday).

Cheers,
Sebastian

2016-05-25 16:19 GMT+02:00 Ben Hilburn :

> Hi Sebastian -
>
> Thanks so much for the great update! I have two questions:
>
> You mentioned in your blog post that all adjacent bins will be interpreted
> as one signal in your detection block, which then gets passed downstream to
> the analysis portion of your design. Can you comment on how this might be
> affected by multi-carrier systems, especially if the user has selected a
> bin count high enough to push apart the carriers?
>
> You also mentioned the ability to analyze past signals in a waterfall
> plot. In this workflow, would you basically be playing back a recorded file
> and doing off-line analysis?
>
> It looks like things are coming along really nicely. Great mock-ups, by
> the way!
>
> Cheers,
> Ben
>
> On Fri, May 20, 2016 at 6:31 AM, Sebastian Müller 
> wrote:
>
>> Hey list,
>>
>> there are some news regarding the gr-inspector toolbox, please check out
>> my blog if you’re interested:
>> https://grinspector.wordpress.com/
>>
>> The strategy for the first big task, signal detection, is nearly finished
>> thanks to the great feedback from my mentors. But still, there are some
>> questions remaining on which I would love to get feedback from the
>> community. The explicit questions are at the end of the newest blog post.
>>
>> Beginning with the coding period on monday, weekly updates will be
>> published on the blog along with a short mail on the list. Stay tuned!
>>
>> Cheers,
>> Sebastian
>>
>> ___
>> 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] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[Juha Vierinen]

I was using a dongle with r820.

juha

> On May 25, 2016, at 23:27, Piotr Krysik  wrote:
> 
> Juha,
> 
> What type of demodulator did you have in the dongles used for the test?
> 
> --
> Piotr
> 
> W dniu 25.05.2016 o 14:46, Juha Vierinen pisze:
>> In my testing, this phase rate difference seemed constant and I could
>> simply calibrate it out by looking at the phase rate term estimated
>> from the phase of the cross-correlated noise. The samples stay aligned
>> for hours, so the issue is caused by the tuner or the DDC. One theory
>> that I had was that the multi-rtl driver somehow sets up the dongles
>> differently, but I never got around to looking at the code. 
>> 
>> I think this was the script I used to figure out what the phase drift was:
>> https://github.com/jvierine/chirpsounder/blob/master/apps/passive_radar/rnoise.py
>> 
>> Here's the IQ plot to prove that the cross correlated phase is stable
>> over 6000 seconds:
>> 
>> http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html
>> 
>> juha
>> 
>> On Wed, May 25, 2016 at 12:14 PM, > > wrote:
>> 
>>From our own experience with dual-dongle measurements, the phase drift
>>seems to be strongly related to R820T(2) temperature. We reduced
>>significantly
>>the phase drift by gluing a large heat sink common to both chips
>>on both
>>dongles, without completely removing this effect (we aim at
>>measurements lasting
>>multiple hours). At the moment the only option we could think of
>>(mail to this
>>mailing list dated 28 May 2015) is switching to a reference clock
>>to calibrate
>>for the phase difference between the local oscillators, but the
>>actual cause
>>of the drift remains a mistery (probably due to the implementation
>>of the PLL,
>>but I cannot understand why Phase Locked Loops would drift in
>>Phase !).
>> 
>>JM
>> 
>>> It wouldn't be as simple as it was for me as a developer and as it
>>> (hopefully) is for the end user without your hardware mod.
>>> 
>>> Can you say something more about the residual center frequency
>>> difference? Where might it come from? I prepared little test of
>>> coherency between the receivers
>>(multi-rtl/examples/test_multirtl.m).
>>> Among all the figures that it shows there is a plot of relative
>>phase
>>> offset of signals coming from the receivers. In fact I have seen
>>linear
>>> phase change on that plot - that corresponds to some central
>>frequency
>>> offset. If I know what is the source of this offset maybe I will
>>be able
>>> to find some way to fix it in software.
>>> 
>>> --
>>> Piotr
>>> 
>>> W dniu 25.05.2016 o 08:24, Juha Vierinen pisze:
 This is awesome! I'll definitely try this out soon. I use one off
 python scripts to find the sample offset and the small
>>residual center
 frequency difference. This simplifies the process significantly.
 
 This should make it much easier to implement a passive radar
>>block, or
 an interferometry block.
 
 juha
 
 On Tue, May 24, 2016 at 4:03 PM, Piotr Krysik >
 >> wrote:
 
Hi all,
 
I want to announce new GNU Radio related project prepared
>>by me -
Multi-rtl:
https://github.com/ptrkrysik/multi-rtl
 
It is a Gnu Radio block that combines multiple RTL-SDR
>>receivers into
one multi-channel receiver.
 
Only hardware modification to RTL-SDR dongles required is
>>connecting
them to a common clock source (i.e. one of the dongles'
>>oscillator as
Juha Verinen showed once). Each channel can work on a
>>different
central
frequency.
 
Everyone who wants to know how it was achieved is invited
>>to read my
github page:
 
https://ptrkrysik.github.io
 
Best Regards,
Piotr Krysik
 
___
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
>> 
>> 
>>--
>>JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de
>>l'Epitaphe, 25000 Besancon, France
> 

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

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Ben Hilburn]

Hi Richard -

Can you try peeking into the CMAKE madness to see what paths it selected
for those two gnuradio libraries? I've found the curses-based CMAKE UI to
be pretty helpful in seeing what the build parameters are: $ ccmake

Cheers,
Ben

On Wed, May 25, 2016 at 4:19 PM, Richard Bell 
wrote:

> I'm trying to compile one of my custom OOT modules on this new Ubuntu
> 16.04 install and I wonder if I'm having compatibility issues. I'm getting
> what looks like cmake issues that cause make to error out. I made sure to
> feed the prefix location into cmake. There are warnings that I'm not used
> to seeing in the cmake output. make says it can't find a few required
> libraries that cmake reported it found. Here is the full cmake and make
> output:
>
> rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
> cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
> -- The CXX compiler identification is GNU 5.3.1
> -- The C compiler identification is GNU 5.3.1
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Build type not specified: defaulting to release.
> -- Boost version: 1.58.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
> -- Checking for module 'cppunit'
> --   Found cppunit, version 1.13.2
> -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
> Checking for GNU Radio Module: RUNTIME
> -- Checking for module 'gnuradio-runtime'
> --   Found gnuradio-runtime, version 3.7.10git
>  * INCLUDES=/home/rbell/Documents/grprefix/include
>  *
> LIBS=/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
> -- Found GNURADIO_RUNTIME:
> /home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>
> GNURADIO_RUNTIME_FOUND = TRUE
> CMake Warning (dev) at
> /home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
> (get_target_property):
>   Policy CMP0026 is not set: Disallow use of the LOCATION target property.
>   Run "cmake --help-policy CMP0026" for policy details.  Use the
> cmake_policy
>   command to set the policy and suppress this warning.
>
>   The LOCATION property should not be read from target
>   "test-add_tagged_stream_once".  Use the target name directly with
>   add_custom_command, or use the generator expression $, as
>   appropriate.
>
> Call Stack (most recent call first):
>   lib/CMakeLists.txt:79 (GR_ADD_TEST)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> --
> -- Checking for module SWIG
> -- Found SWIG version 2.0.12.
> -- Found SWIG: /usr/bin/swig2.0
> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
> suitable version "2.7.11+", minimum required is "2")
> -- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.11",
> minimum required is "2")
> -- Looking for sys/types.h
> -- Looking for sys/types.h - found
> -- Looking for stdint.h
> -- Looking for stdint.h - found
> -- Looking for stddef.h
> -- Looking for stddef.h - found
> -- Check size of size_t
> -- Check size of size_t - done
> -- Check size of unsigned int
> -- Check size of unsigned int - done
> -- Check size of unsigned long
> -- Check size of unsigned long - done
> -- Check size of unsigned long long
> -- Check size of unsigned long long - done
> -- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE
> -- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE - Success
> CMake Warning (dev) at
> /home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
> (get_target_property):
>   Policy CMP0026 is not set: Disallow use of the LOCATION target property.
>   Run "cmake --help-policy CMP0026" for policy details.  Use the
> cmake_policy
>   command to set the policy and suppress this warning.
>
>   The LOCATION property should not be read from target
>   "gnuradio-add_tagged_stream_once".  Use the target name directly with
>   add_custom_command, or use the generator expression $, as
>   appropriate.
>
> Call Stack (most recent call first):
>   python/CMakeLists.txt:44 (GR_ADD_TEST)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at
> /home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
> (get_target_property):
>   Policy CMP0045 is not set: Error on non-existent target in
>   get_target_property.  Run "cmake --help-policy

Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[Juha Vierinen]

Would either of these issues in the rtlsdr driver consistently tune the two
dongles on slightly different frequencies, even if you ask them to tune to
exactly the same frequency? This is what the problem seems to be.

juha

On Wed, May 25, 2016 at 10:35 AM,  wrote:

> There are a couple of issues with the rtlsdr driver used by gr-osmocom in
> this regard:
>
>
>
>   (A) The charge-pump loop current is too constrained for the higher
> frequencies
>
>   (B) The "dither" option appears to have a bias that causes a (small)
> frequency offset.
>
>
>
> The driver that AirSpy uses fixes both of these, although without
> "dither", the tuning granularity is worse.  Not sure this matters.
>
>
>
>
>
>
> On 2016-05-25 09:28, Marcus Müller wrote:
>
> That, or simply, the output clock VCO changes its reaction to the
> control voltage under certain circumstances (temperature, frequency) so
> much that the control loop loses the ability to reach stationary
> exactness (e.g. due to natural limits on the magnitude of the VCO
> voltage). These devices definitely were made with cost in mind – not
> with maximum reliability, and hence I can believe that for example with
> the Elonics E4000 tuner, the charge pump used to generate the VCO
> voltage simply might deteriorate with temperature.
>
> Cheers,
> Marcus
>
> On 25.05.2016 14:25, Sylvain Munaut wrote:
>
> Hi,
>
> of the drift remains a mistery (probably due to the implementation of the
> PLL,
> but I cannot understand why Phase Locked Loops would drift in Phase !).
>
> If the phase comparator is digital ( i.e. a XOR ) and the input clock
> is somewhat analog, the gate thresholds might vary depending on
> temperature, thus shifting the cycle a bit.
>
> Just a thought.
>
> Cheers,
>
> Sylvain
>
> ___
> 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Why add d_nbits two times at ofdm_mapper_bcv ?

[Martin Braun]

Also, that block is going away soon.

I recommend looking at the carrier allocator block instead.

M

On 05/25/2016 10:20 PM, SangHyuk Kim wrote:
> Dear all,
> 
> Sorry, my source code was wrong.
> 
> There is only one /d_bit_offset += d_nbits;
> 
> /
> /Thanks .
> /
> 
> 2016-05-26 10:38 GMT+09:00 SangHyuk Kim  >:
> 
> Hi all,
> 
> I'm tracing how OFDM modulation is done by /ofdm/benchmark_tx.py.
> 
> The file, ofdm.py indicates ofdm modulation is composed of like :
> 
> modulation - mapper - preamble - IFFT - CP - scale
> |- mapper - preamble -|
> 
> And I have a question at ofdm_mapper_bcv.
> 
> In ofdm_mapper_bcv_impl::work, I can find making symbol part :
> 
> /while(..){
> /
> /if((8-d_bit_offset) >= d_nbits) {
> /
> /bits = ((1 << d_nbits)-1) & (d_msgbytes >> d_bit_offset);
> d_bit_offset += d_nbits;
> d_bit_offset += d_nbits;
> out[d_subcarrier_map[i]] = d_constellation[bits];
> /
> /}
> /
> /}
> 
> /
> For example, using BPSK :
> - d_nbits = 1
> - d_msgbytes = 94 (0101 1110)
> 
> 1st loop:
> - bits = ( 0001) & (0101 1110) = 0  // takes right-most bit
> - d_bit_offset = 2
> - out[..] = d_constellation[0]
> 
> 2nd loop:
> - bits = ( 0001) & (0001 0111) = 1
> - d_bit_offset = 4
> - out[..] = d_constellation[1]
> 
> 3rd & 4th same like above.
> 
> In this example, it just takes odd parts of byte (0, 1, 1, 1).
> 
> How can receiver deduce even part (1, 1, 0, 0) ?
> 
> I don't know why /d_bit_offset += d_nbits/ double times, not an one.
> 
> Is this related with two mapping & preamble blocks ? (I/Q ch?)
> 
> If right, these two mapping handle even or odd part of byte
> respectively ?
> 
> Thanks.
> 
> 
> 
> 
> 
> ___
> 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] FSK modulation/demodulation for Universal Access Transceiver

[Marcus Müller]

Hi Olivier!

Nice to meet you.
So, first off, a hint: GRC has a "screen capture" menu / toolbar button
that lets you just export your GRC canvas, so you don't have to make a
screenshot of your whole dual-desktop screen (by the way, cropping that
would have worked, too ;) ).

UAT == ADS-B transmitter, right? Have you seen [1], and are you aware of
Nick Foster's gr-air-modes, an ADS-B receiver?

So, we'd love to help you, but "only gibberish" is hardly a good error
description. Does the RX signal in time domain look OK, or is there very
little amplitude, or values close to 1, indicating clipping? What about
frequency domain, does the RX signal resemble the TX signal?

Then: UHD specifically tells you there is something wrong with how
you've configured things. You will need to fix that first.

Best regards,
Marcus

[1] https://www.youtube.com/watch?v=NSLqRXyxiBo

On 26.05.2016 17:03, Olivier Goyette wrote:
> Hi everyone,
>
> I'm currently doing an internship at school and i'm working with USRP
> N210 and GNUradio. It's been a month since I began working with these
> 2 tools, so excuse me if I may sound noob, but I really need some
> help. I've been asked to start thinking about developing an UAT for
> civil aviation. I've read a ton of standards and papers concerning
> this new technology, so I won't relate it all over here, but the main
> thing about it is that it uses FSK mod/demod for the information to be
> transmitted and received.
>
> I'm currently stuck on a problem that's been haunting me for the last
> 2 weeks and that's why i'm asking for your guidance. When I run the
> mod/demod on simulation(attached #1), everything works fine. I'm
> sending /abcdefghijklmopqr /and on the receiving side i got the same
> thing. Now the problem is that when i'm trying to send it via the USRP
> with a cable between RX and TX(attached #2), i only get gibberish on
> the receiving side !
>
> What have I done wrong ? I don't get why it's not working.
>
> Thank you for your time, your help will be more than welcome
>
> Olivier
>
>
>
> ___
> 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] Why add d_nbits two times at ofdm_mapper_bcv ?

[Marcus Müller]

That's pretty much what I wanted to stress:

Dear SangHyuk,

as you've been told you multiple times:
> Martin, 25. March 2016:
> you're not using the more recent OFDM blocks, so you won't get a lot of
> support here -- I recommend moving to the tx_ofdm and rx_ofdm stuff
> instead.
> I, 10. April 2016:
> Also, we have already discussed with you multiple times that
> benchmark_tx is not what you should be using, and that you should have
> a look at the ofdm_{rx,tx,loopback}.grc examples.
> I, 7. April 2016
> As said on numerous occassions, go ahead and try the rx_ofdm.grc and
> tx_ofdm.grc examples from gr-digital. They are much more modern.

So really, migrate to the examples Martin, I and others have pointed out
multiple times. You *will not* get competent help with the things you use.

Best regards,
Marcus


On 26.05.2016 17:52, Martin Braun wrote:
> Also, that block is going away soon.
>
> I recommend looking at the carrier allocator block instead.
>
> M
>
> On 05/25/2016 10:20 PM, SangHyuk Kim wrote:
>> Dear all,
>>
>> Sorry, my source code was wrong.
>>
>> There is only one /d_bit_offset += d_nbits;
>>
>> /
>> /Thanks .
>> /
>>
>> 2016-05-26 10:38 GMT+09:00 SangHyuk Kim > >:
>>
>> Hi all,
>>
>> I'm tracing how OFDM modulation is done by /ofdm/benchmark_tx.py.
>>
>> The file, ofdm.py indicates ofdm modulation is composed of like :
>>
>> modulation - mapper - preamble - IFFT - CP - scale
>> |- mapper - preamble -|
>>
>> And I have a question at ofdm_mapper_bcv.
>>
>> In ofdm_mapper_bcv_impl::work, I can find making symbol part :
>>
>> /while(..){
>> /
>> /if((8-d_bit_offset) >= d_nbits) {
>> /
>> /bits = ((1 << d_nbits)-1) & (d_msgbytes >> d_bit_offset);
>> d_bit_offset += d_nbits;
>> d_bit_offset += d_nbits;
>> out[d_subcarrier_map[i]] = d_constellation[bits];
>> /
>> /}
>> /
>> /}
>>
>> /
>> For example, using BPSK :
>> - d_nbits = 1
>> - d_msgbytes = 94 (0101 1110)
>>
>> 1st loop:
>> - bits = ( 0001) & (0101 1110) = 0  // takes right-most bit
>> - d_bit_offset = 2
>> - out[..] = d_constellation[0]
>>
>> 2nd loop:
>> - bits = ( 0001) & (0001 0111) = 1
>> - d_bit_offset = 4
>> - out[..] = d_constellation[1]
>>
>> 3rd & 4th same like above.
>>
>> In this example, it just takes odd parts of byte (0, 1, 1, 1).
>>
>> How can receiver deduce even part (1, 1, 0, 0) ?
>>
>> I don't know why /d_bit_offset += d_nbits/ double times, not an one.
>>
>> Is this related with two mapping & preamble blocks ? (I/Q ch?)
>>
>> If right, these two mapping handle even or odd part of byte
>> respectively ?
>>
>> Thanks.
>>
>>
>>
>>
>>
>> ___
>> 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] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[mleech]

A bias in the dither algorithm could explain that, which is why turning
off dither clears up the problem.  The drifting-out-of-lock problem is
due to charge-pump current settings being too low in some cases. 

On 2016-05-26 11:47, Juha Vierinen wrote:

> Would either of these issues in the rtlsdr driver consistently tune the two 
> dongles on slightly different frequencies, even if you ask them to tune to 
> exactly the same frequency? This is what the problem seems to be.  
> 
> juha 
> 
> On Wed, May 25, 2016 at 10:35 AM,  wrote:
> 
> There are a couple of issues with the rtlsdr driver used by gr-osmocom in 
> this regard: 
> 
> (A) The charge-pump loop current is too constrained for the higher 
> frequencies 
> 
> (B) The "dither" option appears to have a bias that causes a (small) 
> frequency offset. 
> 
> The driver that AirSpy uses fixes both of these, although without "dither", 
> the tuning granularity is worse.  Not sure this matters.
> 
> On 2016-05-25 09:28, Marcus Müller wrote: 
> That, or simply, the output clock VCO changes its reaction to the
> control voltage under certain circumstances (temperature, frequency) so
> much that the control loop loses the ability to reach stationary
> exactness (e.g. due to natural limits on the magnitude of the VCO
> voltage). These devices definitely were made with cost in mind - not
> with maximum reliability, and hence I can believe that for example with
> the Elonics E4000 tuner, the charge pump used to generate the VCO
> voltage simply might deteriorate with temperature.
> 
> Cheers,
> Marcus
> 
> On 25.05.2016 14:25, Sylvain Munaut wrote: Hi,
> 
> of the drift remains a mistery (probably due to the implementation of the PLL,
> but I cannot understand why Phase Locked Loops would drift in Phase !). If 
> the phase comparator is digital ( i.e. a XOR ) and the input clock
> is somewhat analog, the gate thresholds might vary depending on
> temperature, thus shifting the cycle a bit.
> 
> Just a thought.
> 
> Cheers,
> 
> Sylvain
> 
> ___
> 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___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Richard Bell]

It seems to be looking into the grprefix directory, this is what I get from
ccmake:

 CMAKE_BUILD_TYPE
*
 CMAKE_INSTALL_PREFIX
*/usr/local
 ENABLE_DOXYGEN
*ON
 GNURADIO_RUNTIME_LIBRARIES_gnu
*/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
 GNURADIO_RUNTIME_LIBRARIES_gnu
*/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
 Gnuradio_DIR
*/home/rbell/Documents/grprefix/lib/cmake/gnuradio
 LIB_SUFFIX
*
 QA_PYTHON_EXECUTABLE
*/usr/bin/python2
 SHELL  */bin/sh

On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn  wrote:

> Hi Richard -
>
> Can you try peeking into the CMAKE madness to see what paths it selected
> for those two gnuradio libraries? I've found the curses-based CMAKE UI to
> be pretty helpful in seeing what the build parameters are: $ ccmake
>
> Cheers,
> Ben
>
> On Wed, May 25, 2016 at 4:19 PM, Richard Bell 
> wrote:
>
>> I'm trying to compile one of my custom OOT modules on this new Ubuntu
>> 16.04 install and I wonder if I'm having compatibility issues. I'm getting
>> what looks like cmake issues that cause make to error out. I made sure to
>> feed the prefix location into cmake. There are warnings that I'm not used
>> to seeing in the cmake output. make says it can't find a few required
>> libraries that cmake reported it found. Here is the full cmake and make
>> output:
>>
>> rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
>> cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
>> -- The CXX compiler identification is GNU 5.3.1
>> -- The C compiler identification is GNU 5.3.1
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Detecting CXX compile features
>> -- Detecting CXX compile features - done
>> -- Check for working C compiler: /usr/bin/cc
>> -- Check for working C compiler: /usr/bin/cc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Detecting C compile features
>> -- Detecting C compile features - done
>> -- Build type not specified: defaulting to release.
>> -- Boost version: 1.58.0
>> -- Found the following Boost libraries:
>> --   filesystem
>> --   system
>> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
>> -- Checking for module 'cppunit'
>> --   Found cppunit, version 1.13.2
>> -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
>> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
>> Checking for GNU Radio Module: RUNTIME
>> -- Checking for module 'gnuradio-runtime'
>> --   Found gnuradio-runtime, version 3.7.10git
>>  * INCLUDES=/home/rbell/Documents/grprefix/include
>>  *
>> LIBS=/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>> -- Found GNURADIO_RUNTIME:
>> /home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>
>> GNURADIO_RUNTIME_FOUND = TRUE
>> CMake Warning (dev) at
>> /home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
>> (get_target_property):
>>   Policy CMP0026 is not set: Disallow use of the LOCATION target property.
>>   Run "cmake --help-policy CMP0026" for policy details.  Use the
>> cmake_policy
>>   command to set the policy and suppress this warning.
>>
>>   The LOCATION property should not be read from target
>>   "test-add_tagged_stream_once".  Use the target name directly with
>>   add_custom_command, or use the generator expression $, as
>>   appropriate.
>>
>> Call Stack (most recent call first):
>>   lib/CMakeLists.txt:79 (GR_ADD_TEST)
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>
>> --
>> -- Checking for module SWIG
>> -- Found SWIG version 2.0.12.
>> -- Found SWIG: /usr/bin/swig2.0
>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
>> suitable version "2.7.11+", minimum required is "2")
>> -- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.11",
>> minimum required is "2")
>> -- Looking for sys/types.h
>> -- Looking for sys/types.h - found
>> -- Looking for stdint.h
>> -- Looking for stdint.h - found
>> -- Looking for stddef.h
>> -- Looking for stddef.h - found
>> -- Check size of size_t
>> -- Check size of size_t - done
>> -- Check size of unsigned int
>> -- Check size of unsigned int - done
>> -- Check size of unsigned long
>> -- Check size of unsigned long - done
>> -- Check size of unsigned long long
>> -- Check size of unsigned long long - done
>> -- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE
>> -- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE - Success
>> CMake Warning (dev) at
>> /home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
>> (get_target_property):
>>   Policy CMP0026 is not set: Disallow use of the LOCATION target property.
>>   Run "cmake --help-policy CMP0026" for policy details.  Use

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Richard Bell]

Then it spit out this error message:

 CMake Error at
/usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
 (CMAKE_PARSE_ARGUMENTS):
   Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
 Call Stack (most recent call first):
   /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:52
(find_package_handle_standard_args)
   cmake/Modules/FindCppUnit.cmake:12 (INCLUDE)
   CMakeLists.txt:106 (find_package)

I don't know what to make of this, do you?

On Thu, May 26, 2016 at 9:45 AM, Richard Bell 
wrote:

> It seems to be looking into the grprefix directory, this is what I get
> from ccmake:
>
>  CMAKE_BUILD_TYPE
> *
>  CMAKE_INSTALL_PREFIX
> */usr/local
>  ENABLE_DOXYGEN
> *ON
>  GNURADIO_RUNTIME_LIBRARIES_gnu
> */home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>  GNURADIO_RUNTIME_LIBRARIES_gnu
> */home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
>  Gnuradio_DIR
> */home/rbell/Documents/grprefix/lib/cmake/gnuradio
>  LIB_SUFFIX
> *
>  QA_PYTHON_EXECUTABLE
> */usr/bin/python2
>  SHELL  */bin/sh
>
> On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn 
> wrote:
>
>> Hi Richard -
>>
>> Can you try peeking into the CMAKE madness to see what paths it selected
>> for those two gnuradio libraries? I've found the curses-based CMAKE UI to
>> be pretty helpful in seeing what the build parameters are: $ ccmake
>>
>> Cheers,
>> Ben
>>
>> On Wed, May 25, 2016 at 4:19 PM, Richard Bell 
>> wrote:
>>
>>> I'm trying to compile one of my custom OOT modules on this new Ubuntu
>>> 16.04 install and I wonder if I'm having compatibility issues. I'm getting
>>> what looks like cmake issues that cause make to error out. I made sure to
>>> feed the prefix location into cmake. There are warnings that I'm not used
>>> to seeing in the cmake output. make says it can't find a few required
>>> libraries that cmake reported it found. Here is the full cmake and make
>>> output:
>>>
>>> rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
>>> cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
>>> -- The CXX compiler identification is GNU 5.3.1
>>> -- The C compiler identification is GNU 5.3.1
>>> -- Check for working CXX compiler: /usr/bin/c++
>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- Detecting CXX compile features
>>> -- Detecting CXX compile features - done
>>> -- Check for working C compiler: /usr/bin/cc
>>> -- Check for working C compiler: /usr/bin/cc -- works
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Detecting C compile features
>>> -- Detecting C compile features - done
>>> -- Build type not specified: defaulting to release.
>>> -- Boost version: 1.58.0
>>> -- Found the following Boost libraries:
>>> --   filesystem
>>> --   system
>>> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
>>> -- Checking for module 'cppunit'
>>> --   Found cppunit, version 1.13.2
>>> -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
>>> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
>>> Checking for GNU Radio Module: RUNTIME
>>> -- Checking for module 'gnuradio-runtime'
>>> --   Found gnuradio-runtime, version 3.7.10git
>>>  * INCLUDES=/home/rbell/Documents/grprefix/include
>>>  *
>>> LIBS=/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>> -- Found GNURADIO_RUNTIME:
>>> /home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>>
>>> GNURADIO_RUNTIME_FOUND = TRUE
>>> CMake Warning (dev) at
>>> /home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
>>> (get_target_property):
>>>   Policy CMP0026 is not set: Disallow use of the LOCATION target
>>> property.
>>>   Run "cmake --help-policy CMP0026" for policy details.  Use the
>>> cmake_policy
>>>   command to set the policy and suppress this warning.
>>>
>>>   The LOCATION property should not be read from target
>>>   "test-add_tagged_stream_once".  Use the target name directly with
>>>   add_custom_command, or use the generator expression $, as
>>>   appropriate.
>>>
>>> Call Stack (most recent call first):
>>>   lib/CMakeLists.txt:79 (GR_ADD_TEST)
>>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>>
>>> --
>>> -- Checking for module SWIG
>>> -- Found SWIG version 2.0.12.
>>> -- Found SWIG: /usr/bin/swig2.0
>>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
>>> suitable version "2.7.11+", minimum required is "2")
>>> -- Found PythonInterp: /usr/bin/python2 (found suitable version
>>> "2.7.11", minimum required is "2")
>>> -- Looking for sys/types.h
>>> -- Looking for sys/types.h - found
>>> -- Looking for stdint.h
>>> -- Looking for stdint.h - found
>>> -- Looking for stddef.h
>>> -- Looking for stddef.h - found
>>> -- Check size of size_t

Re: [Discuss-gnuradio] Why add d_nbits two times at ofdm_mapper_bcv ?

[West, Nathan]

On Thu, May 26, 2016 at 12:06 PM, Marcus Müller 
wrote:

> That's pretty much what I wanted to stress:
>
> Dear SangHyuk,
>
> as you've been told you multiple times:
> > Martin, 25. March 2016:
> > you're not using the more recent OFDM blocks, so you won't get a lot of
> > support here -- I recommend moving to the tx_ofdm and rx_ofdm stuff
> > instead.
> > I, 10. April 2016:
> > Also, we have already discussed with you multiple times that
> > benchmark_tx is not what you should be using, and that you should have
> > a look at the ofdm_{rx,tx,loopback}.grc examples.
> > I, 7. April 2016
> > As said on numerous occassions, go ahead and try the rx_ofdm.grc and
> > tx_ofdm.grc examples from gr-digital. They are much more modern.
>
> So really, migrate to the examples Martin, I and others have pointed out
> multiple times. You *will not* get competent help with the things you use.
>
> Best regards,
> Marcus
>
>
> On 26.05.2016 17:52, Martin Braun wrote:
> > Also, that block is going away soon.
> >
> > I recommend looking at the carrier allocator block instead.
> >
> > M
> >
> > On 05/25/2016 10:20 PM, SangHyuk Kim wrote:
> >> Dear all,
> >>
> >> Sorry, my source code was wrong.
> >>
> >> There is only one /d_bit_offset += d_nbits;
> >>
> >> /
> >> /Thanks .
> >> /
> >>
> >> 2016-05-26 10:38 GMT+09:00 SangHyuk Kim  >> >:
> >>
> >> Hi all,
> >>
> >> I'm tracing how OFDM modulation is done by /ofdm/benchmark_tx.py.
> >>
> >> The file, ofdm.py indicates ofdm modulation is composed of like :
> >>
> >> modulation - mapper - preamble - IFFT - CP - scale
> >> |- mapper - preamble -|
> >>
> >> And I have a question at ofdm_mapper_bcv.
> >>
> >> In ofdm_mapper_bcv_impl::work, I can find making symbol part :
> >>
> >> /while(..){
> >> /
> >> /if((8-d_bit_offset) >= d_nbits) {
> >> /
> >> /bits = ((1 << d_nbits)-1) & (d_msgbytes >> d_bit_offset);
> >> d_bit_offset += d_nbits;
> >> d_bit_offset += d_nbits;
> >> out[d_subcarrier_map[i]] = d_constellation[bits];
> >> /
> >> /}
> >> /
> >> /}
> >>
> >> /
> >> For example, using BPSK :
> >> - d_nbits = 1
> >> - d_msgbytes = 94 (0101 1110)
> >>
> >> 1st loop:
> >> - bits = ( 0001) & (0101 1110) = 0  // takes right-most bit
> >> - d_bit_offset = 2
> >> - out[..] = d_constellation[0]
> >>
> >> 2nd loop:
> >> - bits = ( 0001) & (0001 0111) = 1
> >> - d_bit_offset = 4
> >> - out[..] = d_constellation[1]
> >>
> >> 3rd & 4th same like above.
> >>
> >> In this example, it just takes odd parts of byte (0, 1, 1, 1).
> >>
> >> How can receiver deduce even part (1, 1, 0, 0) ?
> >>
> >> I don't know why /d_bit_offset += d_nbits/ double times, not an one.
> >>
> >> Is this related with two mapping & preamble blocks ? (I/Q ch?)
> >>
> >> If right, these two mapping handle even or odd part of byte
> >> respectively ?
> >>
> >> Thanks.
> >>
> >>
>
>
This is admittedly frustrating from a new-user perspective that we have
"examples" of how to do a thing and then we tell you  not to use it when
you ask about it. Hopefully as we get more serious about 3.8 we can start
to revamp examples in our next branch to show off better ways.

For now Marcus and Martin have given pretty good suggestions for this
particular case.

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

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Ben Hilburn]

Pretty strange. Stupid question: I assume you have tried blowing away the
build directory and giving it another go? Wondering if this is the CMake
cache mucking you up.

This might be worth a try?
https://github.com/dmlc/mxnet/issues/1131

Cheers,
Ben

On Thu, May 26, 2016 at 12:47 PM, Richard Bell 
wrote:

> Then it spit out this error message:
>
>  CMake Error at
> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
>  (CMAKE_PARSE_ARGUMENTS):
>Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
>  Call Stack (most recent call first):
>/usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:52
> (find_package_handle_standard_args)
>cmake/Modules/FindCppUnit.cmake:12 (INCLUDE)
>CMakeLists.txt:106 (find_package)
>
> I don't know what to make of this, do you?
>
> On Thu, May 26, 2016 at 9:45 AM, Richard Bell 
> wrote:
>
>> It seems to be looking into the grprefix directory, this is what I get
>> from ccmake:
>>
>>  CMAKE_BUILD_TYPE
>> *
>>  CMAKE_INSTALL_PREFIX
>> */usr/local
>>  ENABLE_DOXYGEN
>> *ON
>>  GNURADIO_RUNTIME_LIBRARIES_gnu
>> */home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>  GNURADIO_RUNTIME_LIBRARIES_gnu
>> */home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
>>  Gnuradio_DIR
>> */home/rbell/Documents/grprefix/lib/cmake/gnuradio
>>  LIB_SUFFIX
>> *
>>  QA_PYTHON_EXECUTABLE
>> */usr/bin/python2
>>  SHELL  */bin/sh
>>
>> On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn 
>> wrote:
>>
>>> Hi Richard -
>>>
>>> Can you try peeking into the CMAKE madness to see what paths it selected
>>> for those two gnuradio libraries? I've found the curses-based CMAKE UI to
>>> be pretty helpful in seeing what the build parameters are: $ ccmake
>>>
>>> Cheers,
>>> Ben
>>>
>>> On Wed, May 25, 2016 at 4:19 PM, Richard Bell 
>>> wrote:
>>>
 I'm trying to compile one of my custom OOT modules on this new Ubuntu
 16.04 install and I wonder if I'm having compatibility issues. I'm getting
 what looks like cmake issues that cause make to error out. I made sure to
 feed the prefix location into cmake. There are warnings that I'm not used
 to seeing in the cmake output. make says it can't find a few required
 libraries that cmake reported it found. Here is the full cmake and make
 output:

 rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
 cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
 -- The CXX compiler identification is GNU 5.3.1
 -- The C compiler identification is GNU 5.3.1
 -- Check for working CXX compiler: /usr/bin/c++
 -- Check for working CXX compiler: /usr/bin/c++ -- works
 -- Detecting CXX compiler ABI info
 -- Detecting CXX compiler ABI info - done
 -- Detecting CXX compile features
 -- Detecting CXX compile features - done
 -- Check for working C compiler: /usr/bin/cc
 -- Check for working C compiler: /usr/bin/cc -- works
 -- Detecting C compiler ABI info
 -- Detecting C compiler ABI info - done
 -- Detecting C compile features
 -- Detecting C compile features - done
 -- Build type not specified: defaulting to release.
 -- Boost version: 1.58.0
 -- Found the following Boost libraries:
 --   filesystem
 --   system
 -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
 -- Checking for module 'cppunit'
 --   Found cppunit, version 1.13.2
 -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
 -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
 Checking for GNU Radio Module: RUNTIME
 -- Checking for module 'gnuradio-runtime'
 --   Found gnuradio-runtime, version 3.7.10git
  * INCLUDES=/home/rbell/Documents/grprefix/include
  *
 LIBS=/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
 -- Found GNURADIO_RUNTIME:
 /home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so

 GNURADIO_RUNTIME_FOUND = TRUE
 CMake Warning (dev) at
 /home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
 (get_target_property):
   Policy CMP0026 is not set: Disallow use of the LOCATION target
 property.
   Run "cmake --help-policy CMP0026" for policy details.  Use the
 cmake_policy
   command to set the policy and suppress this warning.

   The LOCATION property should not be read from target
   "test-add_tagged_stream_once".  Use the target name directly with
   add_custom_command, or use the generator expression $, as
   appropriate.

 Call Stack (most recent call first):
   lib/CMakeLists.txt:79 (GR_ADD_TEST)
 This warning is for project developers.  Use -Wno-dev to suppress it.

 --
 -- Checking for module SWIG
 -- Found SWIG version 2.0.12.
 -- Found SWIG: /usr/bin/swig2.0
 -- Found PythonLi

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Richard Bell]

Yeah I've blown away build a few times now. I tried this to a few different
OOT modules as well. They all produce the same output I've posted. Weird
how GNU Radio istelf had no cmake issues but child OOT modules do.

On Thu, May 26, 2016 at 10:52 AM, Ben Hilburn  wrote:

> Pretty strange. Stupid question: I assume you have tried blowing away the
> build directory and giving it another go? Wondering if this is the CMake
> cache mucking you up.
>
> This might be worth a try?
> https://github.com/dmlc/mxnet/issues/1131
>
> Cheers,
> Ben
>
> On Thu, May 26, 2016 at 12:47 PM, Richard Bell 
> wrote:
>
>> Then it spit out this error message:
>>
>>  CMake Error at
>> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
>>  (CMAKE_PARSE_ARGUMENTS):
>>Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
>>  Call Stack (most recent call first):
>>/usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:52
>> (find_package_handle_standard_args)
>>cmake/Modules/FindCppUnit.cmake:12 (INCLUDE)
>>CMakeLists.txt:106 (find_package)
>>
>> I don't know what to make of this, do you?
>>
>> On Thu, May 26, 2016 at 9:45 AM, Richard Bell 
>> wrote:
>>
>>> It seems to be looking into the grprefix directory, this is what I get
>>> from ccmake:
>>>
>>>  CMAKE_BUILD_TYPE
>>> *
>>>  CMAKE_INSTALL_PREFIX
>>> */usr/local
>>>  ENABLE_DOXYGEN
>>> *ON
>>>  GNURADIO_RUNTIME_LIBRARIES_gnu
>>> */home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>>  GNURADIO_RUNTIME_LIBRARIES_gnu
>>> */home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
>>>  Gnuradio_DIR
>>> */home/rbell/Documents/grprefix/lib/cmake/gnuradio
>>>  LIB_SUFFIX
>>> *
>>>  QA_PYTHON_EXECUTABLE
>>> */usr/bin/python2
>>>  SHELL  */bin/sh
>>>
>>> On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn 
>>> wrote:
>>>
 Hi Richard -

 Can you try peeking into the CMAKE madness to see what paths it
 selected for those two gnuradio libraries? I've found the curses-based
 CMAKE UI to be pretty helpful in seeing what the build parameters are: $
 ccmake

 Cheers,
 Ben

 On Wed, May 25, 2016 at 4:19 PM, Richard Bell 
 wrote:

> I'm trying to compile one of my custom OOT modules on this new Ubuntu
> 16.04 install and I wonder if I'm having compatibility issues. I'm getting
> what looks like cmake issues that cause make to error out. I made sure to
> feed the prefix location into cmake. There are warnings that I'm not used
> to seeing in the cmake output. make says it can't find a few required
> libraries that cmake reported it found. Here is the full cmake and make
> output:
>
> rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
> cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
> -- The CXX compiler identification is GNU 5.3.1
> -- The C compiler identification is GNU 5.3.1
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Build type not specified: defaulting to release.
> -- Boost version: 1.58.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
> -- Checking for module 'cppunit'
> --   Found cppunit, version 1.13.2
> -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
> Checking for GNU Radio Module: RUNTIME
> -- Checking for module 'gnuradio-runtime'
> --   Found gnuradio-runtime, version 3.7.10git
>  * INCLUDES=/home/rbell/Documents/grprefix/include
>  *
> LIBS=/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
> -- Found GNURADIO_RUNTIME:
> /home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>
> GNURADIO_RUNTIME_FOUND = TRUE
> CMake Warning (dev) at
> /home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
> (get_target_property):
>   Policy CMP0026 is not set: Disallow use of the LOCATION target
> property.
>   Run "cmake --help-policy CMP0026" for policy details.  Use the
> cmake_policy
>   command to set the policy and suppress this warning.
>
>   The LOCATION property should not be read from target
>   "test-add_tagged_stream_once".  Use the target na

Re: [Discuss-gnuradio] FSK modulation/demodulation for Universal Access Transceiver

[Andy Walls]

On Thu, 2016-05-26 at 11:04 -0400, discuss-gnuradio-requ...@gnu.org
wrote:

> Date: Thu, 26 May 2016 11:03:55 -0400
> From: Olivier Goyette 

> Hi everyone,
> 
> I'm currently doing an internship at school and i'm working with USRP N210
> and GNUradio. It's been a month since I began working with these 2 tools,
> so excuse me if I may sound noob, but I really need some help. I've been
> asked to start thinking about developing an UAT for civil aviation. I've
> read a ton of standards and papers concerning this new technology, so I
> won't relate it all over here, but the main thing about it is that it uses
> FSK mod/demod for the information to be transmitted and received.
> 
> I'm currently stuck on a problem that's been haunting me for the last 2
> weeks and that's why i'm asking for your guidance. When I run the mod/demod
> on simulation(attached #1), everything works fine. I'm sending
> *abcdefghijklmopqr
> *and on the receiving side i got the same thing.

Isn't simulation great. ;)


>  Now the problem is that
> when i'm trying to send it via the USRP with a cable between RX and
> TX(attached #2), i only get gibberish on the receiving side !

The real-world always ruins things!

> What have I done wrong ? I don't get why it's not working.

Three things:

1. On Tx you only appear to be using 1 sample/symbol.  That doesn't let
you do any pulse shaping.

2. On Rx you appare to be using only 1 sample/symbol, which makes symbol
clock recovery nearly impossible.

3. On Rx you're not performing symbol clock recovery  (M&M clock
recovery block or PFB clock recovery block).

4. On RX you're performing neither coarse nor fine frequency
synchronization.

5. Your USRP is unhappy with your configuration of the USRP blocks:
"The hardware does not support the requested Tx sample rate:
Target sample rate: 0.01 Msps  (<- 1 sample per second?!)
Actual sample rate: 0.195312 Msps  (<- 195.312 ksps is the slowest the USRP can 
go apparently)"



> Thank you for your time, your help will be more than welcome

As Marcus said, yo can look at Nick Foster's gr-air-modes to see how he
handles Mode S/ADS-B (which is ASK/OOK).

You can also look at Nick's gr-ais, which is a GMSK receiver (GMSK is
GMSK with a modulation index of 0.5). 

This set of class notes talks about receiver timing synchronization:
http://www.cs.tut.fi/kurssit/TLT-5806/Synch.pdf

Also fred harris' article "Let's Assume the System is Synchronized" is
good reading about receiver synchronization (although not specifically
geared towards FSK):
https://www.researchgate.net/publication/278639495_Let%
27s_Assume_the_System_Is_Synchronized
http://eclass.uth.gr/eclass/modules/document/file.php/MHX302/Lecture12%
20-%20Wireless%20signal%20processing%20%28Synchronization%29.pdf

-Andy

> Olivier



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

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Richard Bell]

I tried making a fresh OOT module and I get the same problem. So it seems
to be connected to gr_modtool.

On Thu, May 26, 2016 at 11:05 AM, Richard Bell 
wrote:

> Yeah I've blown away build a few times now. I tried this to a few
> different OOT modules as well. They all produce the same output I've
> posted. Weird how GNU Radio istelf had no cmake issues but child OOT
> modules do.
>
> On Thu, May 26, 2016 at 10:52 AM, Ben Hilburn 
> wrote:
>
>> Pretty strange. Stupid question: I assume you have tried blowing away the
>> build directory and giving it another go? Wondering if this is the CMake
>> cache mucking you up.
>>
>> This might be worth a try?
>> https://github.com/dmlc/mxnet/issues/1131
>>
>> Cheers,
>> Ben
>>
>> On Thu, May 26, 2016 at 12:47 PM, Richard Bell 
>> wrote:
>>
>>> Then it spit out this error message:
>>>
>>>  CMake Error at
>>> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
>>>  (CMAKE_PARSE_ARGUMENTS):
>>>Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
>>>  Call Stack (most recent call first):
>>>/usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:52
>>> (find_package_handle_standard_args)
>>>cmake/Modules/FindCppUnit.cmake:12 (INCLUDE)
>>>CMakeLists.txt:106 (find_package)
>>>
>>> I don't know what to make of this, do you?
>>>
>>> On Thu, May 26, 2016 at 9:45 AM, Richard Bell 
>>> wrote:
>>>
 It seems to be looking into the grprefix directory, this is what I get
 from ccmake:

  CMAKE_BUILD_TYPE
 *
  CMAKE_INSTALL_PREFIX
 */usr/local
  ENABLE_DOXYGEN
 *ON
  GNURADIO_RUNTIME_LIBRARIES_gnu
 */home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
  GNURADIO_RUNTIME_LIBRARIES_gnu
 */home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
  Gnuradio_DIR
 */home/rbell/Documents/grprefix/lib/cmake/gnuradio
  LIB_SUFFIX
 *
  QA_PYTHON_EXECUTABLE
 */usr/bin/python2
  SHELL  */bin/sh

 On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn 
 wrote:

> Hi Richard -
>
> Can you try peeking into the CMAKE madness to see what paths it
> selected for those two gnuradio libraries? I've found the curses-based
> CMAKE UI to be pretty helpful in seeing what the build parameters are: $
> ccmake
>
> Cheers,
> Ben
>
> On Wed, May 25, 2016 at 4:19 PM, Richard Bell  > wrote:
>
>> I'm trying to compile one of my custom OOT modules on this new Ubuntu
>> 16.04 install and I wonder if I'm having compatibility issues. I'm 
>> getting
>> what looks like cmake issues that cause make to error out. I made sure to
>> feed the prefix location into cmake. There are warnings that I'm not used
>> to seeing in the cmake output. make says it can't find a few required
>> libraries that cmake reported it found. Here is the full cmake and make
>> output:
>>
>> rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
>> cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
>> -- The CXX compiler identification is GNU 5.3.1
>> -- The C compiler identification is GNU 5.3.1
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Detecting CXX compile features
>> -- Detecting CXX compile features - done
>> -- Check for working C compiler: /usr/bin/cc
>> -- Check for working C compiler: /usr/bin/cc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Detecting C compile features
>> -- Detecting C compile features - done
>> -- Build type not specified: defaulting to release.
>> -- Boost version: 1.58.0
>> -- Found the following Boost libraries:
>> --   filesystem
>> --   system
>> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
>> -- Checking for module 'cppunit'
>> --   Found cppunit, version 1.13.2
>> -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
>> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
>> Checking for GNU Radio Module: RUNTIME
>> -- Checking for module 'gnuradio-runtime'
>> --   Found gnuradio-runtime, version 3.7.10git
>>  * INCLUDES=/home/rbell/Documents/grprefix/include
>>  *
>> LIBS=/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>> -- Found GNURADIO_RUNTIME:
>> /home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>
>> GNURADIO_RUNTIME_FOUND = TRUE
>> CMake Warning (dev) at
>> /home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
>> (get_target_property):
>>   Policy CMP0026 is not set: Disallow use of the LOCATION

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Ben Hilburn]

What release / branch of GNU Radio are you using?

Cheers,
Ben

On Thu, May 26, 2016 at 2:41 PM, Richard Bell 
wrote:

> I tried making a fresh OOT module and I get the same problem. So it seems
> to be connected to gr_modtool.
>
> On Thu, May 26, 2016 at 11:05 AM, Richard Bell 
> wrote:
>
>> Yeah I've blown away build a few times now. I tried this to a few
>> different OOT modules as well. They all produce the same output I've
>> posted. Weird how GNU Radio istelf had no cmake issues but child OOT
>> modules do.
>>
>> On Thu, May 26, 2016 at 10:52 AM, Ben Hilburn 
>> wrote:
>>
>>> Pretty strange. Stupid question: I assume you have tried blowing away
>>> the build directory and giving it another go? Wondering if this is the
>>> CMake cache mucking you up.
>>>
>>> This might be worth a try?
>>> https://github.com/dmlc/mxnet/issues/1131
>>>
>>> Cheers,
>>> Ben
>>>
>>> On Thu, May 26, 2016 at 12:47 PM, Richard Bell 
>>> wrote:
>>>
 Then it spit out this error message:

  CMake Error at
 /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
  (CMAKE_PARSE_ARGUMENTS):
Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
  Call Stack (most recent call first):
/usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:52
 (find_package_handle_standard_args)
cmake/Modules/FindCppUnit.cmake:12 (INCLUDE)
CMakeLists.txt:106 (find_package)

 I don't know what to make of this, do you?

 On Thu, May 26, 2016 at 9:45 AM, Richard Bell 
 wrote:

> It seems to be looking into the grprefix directory, this is what I get
> from ccmake:
>
>  CMAKE_BUILD_TYPE
> *
>  CMAKE_INSTALL_PREFIX
> */usr/local
>  ENABLE_DOXYGEN
> *ON
>  GNURADIO_RUNTIME_LIBRARIES_gnu
> */home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>  GNURADIO_RUNTIME_LIBRARIES_gnu
> */home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
>  Gnuradio_DIR
> */home/rbell/Documents/grprefix/lib/cmake/gnuradio
>  LIB_SUFFIX
> *
>  QA_PYTHON_EXECUTABLE
> */usr/bin/python2
>  SHELL  */bin/sh
>
> On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn 
> wrote:
>
>> Hi Richard -
>>
>> Can you try peeking into the CMAKE madness to see what paths it
>> selected for those two gnuradio libraries? I've found the curses-based
>> CMAKE UI to be pretty helpful in seeing what the build parameters are: $
>> ccmake
>>
>> Cheers,
>> Ben
>>
>> On Wed, May 25, 2016 at 4:19 PM, Richard Bell <
>> richard.be...@gmail.com> wrote:
>>
>>> I'm trying to compile one of my custom OOT modules on this new
>>> Ubuntu 16.04 install and I wonder if I'm having compatibility issues. 
>>> I'm
>>> getting what looks like cmake issues that cause make to error out. I 
>>> made
>>> sure to feed the prefix location into cmake. There are warnings that I'm
>>> not used to seeing in the cmake output. make says it can't find a few
>>> required libraries that cmake reported it found. Here is the full cmake 
>>> and
>>> make output:
>>>
>>> rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
>>> cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
>>> -- The CXX compiler identification is GNU 5.3.1
>>> -- The C compiler identification is GNU 5.3.1
>>> -- Check for working CXX compiler: /usr/bin/c++
>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- Detecting CXX compile features
>>> -- Detecting CXX compile features - done
>>> -- Check for working C compiler: /usr/bin/cc
>>> -- Check for working C compiler: /usr/bin/cc -- works
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Detecting C compile features
>>> -- Detecting C compile features - done
>>> -- Build type not specified: defaulting to release.
>>> -- Boost version: 1.58.0
>>> -- Found the following Boost libraries:
>>> --   filesystem
>>> --   system
>>> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
>>> -- Checking for module 'cppunit'
>>> --   Found cppunit, version 1.13.2
>>> -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
>>> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
>>> Checking for GNU Radio Module: RUNTIME
>>> -- Checking for module 'gnuradio-runtime'
>>> --   Found gnuradio-runtime, version 3.7.10git
>>>  * INCLUDES=/home/rbell/Documents/grprefix/include
>>>  *
>>> LIBS=/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>> -- Found GNURADIO_RUNTIME:
>>> /home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/hom

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Ron Economos]

You probably don't have a path to the GNU Radio libraries for the 
linker. Try this command:


sudo ldconfig -v | grep gnuradio

The way I like to resolve this is to add a file to /etc/ld.so.conf.d 
called gnuradio.conf with the path to the libraries. On my setup, it 
contains:


/opt/gnuradio-3.7.10git/lib

Ron

On 05/26/2016 11:05 AM, Richard Bell wrote:
Yeah I've blown away build a few times now. I tried this to a few 
different OOT modules as well. They all produce the same output I've 
posted. Weird how GNU Radio istelf had no cmake issues but child OOT 
modules do.


On Thu, May 26, 2016 at 10:52 AM, Ben Hilburn > wrote:


Pretty strange. Stupid question: I assume you have tried blowing
away the build directory and giving it another go? Wondering if
this is the CMake cache mucking you up.

This might be worth a try?
https://github.com/dmlc/mxnet/issues/1131

Cheers,
Ben

On Thu, May 26, 2016 at 12:47 PM, Richard Bell
mailto:richard.be...@gmail.com>> wrote:

Then it spit out this error message:

 CMake Error at
/usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
 (CMAKE_PARSE_ARGUMENTS):
   Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
 Call Stack (most recent call first):
/usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:52
(find_package_handle_standard_args)
   cmake/Modules/FindCppUnit.cmake:12 (INCLUDE)
   CMakeLists.txt:106 (find_package)

I don't know what to make of this, do you?

On Thu, May 26, 2016 at 9:45 AM, Richard Bell
mailto:richard.be...@gmail.com>> wrote:

It seems to be looking into the grprefix directory, this
is what I get from ccmake:

 CMAKE_BUILD_TYPE *
 CMAKE_INSTALL_PREFIX */usr/local
 ENABLE_DOXYGEN *ON
 GNURADIO_RUNTIME_LIBRARIES_gnu
*/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
 GNURADIO_RUNTIME_LIBRARIES_gnu
*/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
 Gnuradio_DIR
*/home/rbell/Documents/grprefix/lib/cmake/gnuradio
 LIB_SUFFIX *
 QA_PYTHON_EXECUTABLE */usr/bin/python2
 SHELL   */bin/sh

On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn
mailto:bhilb...@gnuradio.org>> wrote:

Hi Richard -

Can you try peeking into the CMAKE madness to see what
paths it selected for those two gnuradio libraries?
I've found the curses-based CMAKE UI to be pretty
helpful in seeing what the build parameters are: $ ccmake

Cheers,
Ben

On Wed, May 25, 2016 at 4:19 PM, Richard Bell
mailto:richard.be...@gmail.com>> wrote:

I'm trying to compile one of my custom OOT modules
on this new Ubuntu 16.04 install and I wonder if
I'm having compatibility issues. I'm getting what
looks like cmake issues that cause make to error
out. I made sure to feed the prefix location into
cmake. There are warnings that I'm not used to
seeing in the cmake output. make says it can't
find a few required libraries that cmake reported
it found. Here is the full cmake and make output:


rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
cmake
-DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/
..
-- The CXX compiler identification is GNU 5.3.1
-- The C compiler identification is GNU 5.3.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ --
works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   filesystem
--   system
-- Found PkgConfig: /usr/bin/pkg-config (found
 

Re: [Discuss-gnuradio] FSK modulation/demodulation for Universal Access Transceiver

[Nick Foster]

Everyone's tips here are great. A minor clarification:

UAT is not Mode S. UAT is 978MHz FSK at 1.041667Ms/s. Mode S (and thus,
ADS-B) is 1090MHz PPM OOK at 1Ms/s. I'm unaware of any existing Gnuradio
UAT implementations, although there are a couple of prototype scratch-built
decoders (https://github.com/mutability/dump978 for instance) that could be
used for reference.

UAT is intended for civil aviation applications and (usually) provides
local traffic synthesized from ATC sources (TIS-B) as well as weather
(radar and forecast) services (FIS-B).

The best advice I can offer when getting started writing Gnuradio
applications is to know what you're expecting before you try something, and
be rigorous in your experimentation. At every step of the demodulation
process be looking at the raw data, and be able to explain why it looks
like it does.

--n

On Thu, May 26, 2016 at 11:32 AM Andy Walls 
wrote:

> On Thu, 2016-05-26 at 11:04 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:
>
> > Date: Thu, 26 May 2016 11:03:55 -0400
> > From: Olivier Goyette
>
> > Hi everyone,
> >
> > I'm currently doing an internship at school and i'm working with USRP
> N210
> > and GNUradio. It's been a month since I began working with these 2 tools,
> > so excuse me if I may sound noob, but I really need some help. I've been
> > asked to start thinking about developing an UAT for civil aviation. I've
> > read a ton of standards and papers concerning this new technology, so I
> > won't relate it all over here, but the main thing about it is that it
> uses
> > FSK mod/demod for the information to be transmitted and received.
> >
> > I'm currently stuck on a problem that's been haunting me for the last 2
> > weeks and that's why i'm asking for your guidance. When I run the
> mod/demod
> > on simulation(attached #1), everything works fine. I'm sending
> > *abcdefghijklmopqr
> > *and on the receiving side i got the same thing.
>
> Isn't simulation great. ;)
>
>
> >  Now the problem is that
> > when i'm trying to send it via the USRP with a cable between RX and
> > TX(attached #2), i only get gibberish on the receiving side !
>
> The real-world always ruins things!
>
> > What have I done wrong ? I don't get why it's not working.
>
> Three things:
>
> 1. On Tx you only appear to be using 1 sample/symbol.  That doesn't let
> you do any pulse shaping.
>
> 2. On Rx you appare to be using only 1 sample/symbol, which makes symbol
> clock recovery nearly impossible.
>
> 3. On Rx you're not performing symbol clock recovery  (M&M clock
> recovery block or PFB clock recovery block).
>
> 4. On RX you're performing neither coarse nor fine frequency
> synchronization.
>
> 5. Your USRP is unhappy with your configuration of the USRP blocks:
> "The hardware does not support the requested Tx sample rate:
> Target sample rate: 0.01 Msps  (<- 1 sample per second?!)
> Actual sample rate: 0.195312 Msps  (<- 195.312 ksps is the slowest the
> USRP can go apparently)"
>
>
>
> > Thank you for your time, your help will be more than welcome
>
> As Marcus said, yo can look at Nick Foster's gr-air-modes to see how he
> handles Mode S/ADS-B (which is ASK/OOK).
>
> You can also look at Nick's gr-ais, which is a GMSK receiver (GMSK is
> GMSK with a modulation index of 0.5).
>
> This set of class notes talks about receiver timing synchronization:
> http://www.cs.tut.fi/kurssit/TLT-5806/Synch.pdf
>
> Also fred harris' article "Let's Assume the System is Synchronized" is
> good reading about receiver synchronization (although not specifically
> geared towards FSK):
> https://www.researchgate.net/publication/278639495_Let%
> 27s_Assume_the_System_Is_Synchronized
> http://eclass.uth.gr/eclass/modules/document/file.php/MHX302/Lecture12%
> 20-%20Wireless%20signal%20processing%20%28Synchronization%29.pdf
> 
>
> -Andy
>
> > Olivier
>
>
>
> ___
> 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] FSK modulation/demodulation for Universal Access Transceiver

[Marcus Müller]

Hi Olivier,

thanks for the reply! Ah, I was confusing UAT and ADS-B then, sorry!

You should really be sending this email to the discuss-gnuradio@gnu.org
list - with the graphs attached, it's much easier for the others to help!
Just a question: the time_dom.png indeed looks like there's something
wrong. Is the upper signal display TX, the lower display RX? In that
case, make sure you have proper pulse shaping enabled. This looks like
you have samples_per_symbol=1. Also, yes, it's a good idea not to drive
frontends with their maximum amplitude, but that can easily remedied
with a multiply_const block with e.g. 0.7.

Best regards,
Marcus

PS: Amazing project!

On 26.05.2016 18:32, Olivier Goyette wrote:
> Thank you for your reply.
>
> I'm aware of gr-air-modes but the thing is that UAT and ADS-B are not
> working on the same medium. UAT is using 978 MHz carrier and ADS-B is
> using 1090 MHz. ADS-B messages for UAT are not using the same message
> format so, i'll need to interpret them using another format, that's
> why i'm starting from zero.
>
> Concerning RX and TX for time and frequency domain, by looking at the
> time domain at TX, there seem to be clipping?? How do I fix it ? I've
> tried to play with the gain but it doesn't seem to be working..
>
> 2016-05-26 11:59 GMT-04:00 Marcus Müller  >:
>
> Hi Olivier!
>
> Nice to meet you.
> So, first off, a hint: GRC has a "screen capture" menu / toolbar
> button that lets you just export your GRC canvas, so you don't
> have to make a screenshot of your whole dual-desktop screen (by
> the way, cropping that would have worked, too ;) ).
>
> UAT == ADS-B transmitter, right? Have you seen [1], and are you
> aware of Nick Foster's gr-air-modes, an ADS-B receiver?
>
> So, we'd love to help you, but "only gibberish" is hardly a good
> error description. Does the RX signal in time domain look OK, or
> is there very little amplitude, or values close to 1, indicating
> clipping? What about frequency domain, does the RX signal resemble
> the TX signal?
>
> Then: UHD specifically tells you there is something wrong with how
> you've configured things. You will need to fix that first.
>
> Best regards,
> Marcus
>
> [1] https://www.youtube.com/watch?v=NSLqRXyxiBo
>
>
> On 26.05.2016 17:03, Olivier Goyette wrote:
>> Hi everyone,
>>
>> I'm currently doing an internship at school and i'm working with
>> USRP N210 and GNUradio. It's been a month since I began working
>> with these 2 tools, so excuse me if I may sound noob, but I
>> really need some help. I've been asked to start thinking about
>> developing an UAT for civil aviation. I've read a ton of
>> standards and papers concerning this new technology, so I won't
>> relate it all over here, but the main thing about it is that it
>> uses FSK mod/demod for the information to be transmitted and
>> received.
>>
>> I'm currently stuck on a problem that's been haunting me for the
>> last 2 weeks and that's why i'm asking for your guidance. When I
>> run the mod/demod on simulation(attached #1), everything works
>> fine. I'm sending /abcdefghijklmopqr /and on the receiving side i
>> got the same thing. Now the problem is that when i'm trying to
>> send it via the USRP with a cable between RX and TX(attached #2),
>> i only get gibberish on the receiving side !
>>
>> What have I done wrong ? I don't get why it's not working.
>>
>> Thank you for your time, your help will be more than welcome
>>
>> Olivier
>>
>>
>>
>> ___
>> 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

[Discuss-gnuradio] FSK modulation/demodulation for Universal Access Transceiver

[Olivier Goyette]

Thanks everyone for your support !
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Richard Bell]

Thanks Ron. I think this is narrowing down the issue. When I ran that
command, I did not get any entries containing libgnuradio back. When I run
the same command on a working Ubuntu 14.04 install, I get many of those
entries.

I added the file you mentioned with the path to the base install gnuradio
libraries and they then show up in the output list. The question is, why
was base install gnuradio working at all without knowing the location to
those libraries?

Second question, why do I have to do this at all, shouldn't Pybombs have
handled this for me?

Lastly, even after adding this gnuradio.conf file, I am still unable to
compile OOT. The process returns the same cmake warnings and make error as
it did before. No change at all.

On Thu, May 26, 2016 at 11:46 AM, Ron Economos  wrote:

> You probably don't have a path to the GNU Radio libraries for the linker.
> Try this command:
>
> sudo ldconfig -v | grep gnuradio
>
> The way I like to resolve this is to add a file to /etc/ld.so.conf.d
> called gnuradio.conf with the path to the libraries. On my setup, it
> contains:
>
> /opt/gnuradio-3.7.10git/lib
>
> Ron
>
>
> On 05/26/2016 11:05 AM, Richard Bell wrote:
>
> Yeah I've blown away build a few times now. I tried this to a few
> different OOT modules as well. They all produce the same output I've
> posted. Weird how GNU Radio istelf had no cmake issues but child OOT
> modules do.
>
> On Thu, May 26, 2016 at 10:52 AM, Ben Hilburn 
> wrote:
>
>> Pretty strange. Stupid question: I assume you have tried blowing away the
>> build directory and giving it another go? Wondering if this is the CMake
>> cache mucking you up.
>>
>> This might be worth a try?
>> https://github.com/dmlc/mxnet/issues/1131
>>
>> Cheers,
>> Ben
>>
>> On Thu, May 26, 2016 at 12:47 PM, Richard Bell <
>> richard.be...@gmail.com> wrote:
>>
>>> Then it spit out this error message:
>>>
>>>  CMake Error at
>>> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
>>>  (CMAKE_PARSE_ARGUMENTS):
>>>Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
>>>  Call Stack (most recent call first):
>>>/usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:52
>>> (find_package_handle_standard_args)
>>>cmake/Modules/FindCppUnit.cmake:12 (INCLUDE)
>>>CMakeLists.txt:106 (find_package)
>>>
>>> I don't know what to make of this, do you?
>>>
>>> On Thu, May 26, 2016 at 9:45 AM, Richard Bell 
>>> wrote:
>>>
 It seems to be looking into the grprefix directory, this is what I get
 from ccmake:

  CMAKE_BUILD_TYPE
 *
  CMAKE_INSTALL_PREFIX
 */usr/local
  ENABLE_DOXYGEN
 *ON
  GNURADIO_RUNTIME_LIBRARIES_gnu
 */home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
  GNURADIO_RUNTIME_LIBRARIES_gnu
 */home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
  Gnuradio_DIR
 */home/rbell/Documents/grprefix/lib/cmake/gnuradio
  LIB_SUFFIX
 *
  QA_PYTHON_EXECUTABLE
 */usr/bin/python2
  SHELL  */bin/sh

 On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn < 
 bhilb...@gnuradio.org> wrote:

> Hi Richard -
>
> Can you try peeking into the CMAKE madness to see what paths it
> selected for those two gnuradio libraries? I've found the curses-based
> CMAKE UI to be pretty helpful in seeing what the build parameters are: $
> ccmake
>
> Cheers,
> Ben
>
> On Wed, May 25, 2016 at 4:19 PM, Richard Bell <
> richard.be...@gmail.com> wrote:
>
>> I'm trying to compile one of my custom OOT modules on this new Ubuntu
>> 16.04 install and I wonder if I'm having compatibility issues. I'm 
>> getting
>> what looks like cmake issues that cause make to error out. I made sure to
>> feed the prefix location into cmake. There are warnings that I'm not used
>> to seeing in the cmake output. make says it can't find a few required
>> libraries that cmake reported it found. Here is the full cmake and make
>> output:
>>
>> rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
>> cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
>> -- The CXX compiler identification is GNU 5.3.1
>> -- The C compiler identification is GNU 5.3.1
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Detecting CXX compile features
>> -- Detecting CXX compile features - done
>> -- Check for working C compiler: /usr/bin/cc
>> -- Check for working C compiler: /usr/bin/cc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Detecting C compile features
>> -- Detecting C compile features - done
>> -- Build type not specified: defaulting to release.
>> -- Boost version: 1.58.0
>> -- Found the