Re: Resending: reconfigure flowgrpah through messaging

[Nick Foster]

Achilleas,

Sure, this is possible. Through Python all things are possible, to
paraphrase. =)

The message could be, but doesn't have to be, a Gnuradio PMT message passed
via the message passing interface. It is probably easier for your sending
block to simply set a semaphore or condition variable shared by the
toplevel flowgraph and passed into the sending block at construction. The
semaphore is monitored by the toplevel main loop and triggers a
reconfiguration when set.

You could also use the "Message to Variable" block to set a variable
created in the toplevel flowgraph, and then monitor that variable's value
in the toplevel main loop to trigger reconfiguration.

The important thing to remember about the above two approaches is that
thread safety requires that you do the reconfiguration in the thread
context of the toplevel main loop. You cannot trigger a reconfiguration via
a callback as each block runs in its own thread.

You could also try using the "Selector" block to control dataflow through a
static flowgraph without reconfiguring. A pair of such selectors can be
used much the same as filterbank switches in hardware. The selection change
can be triggered via the same "Message to Variable" block.

There are probably more elegant options as well. These are just the ones
that came to mind immediately.

Hope this helps,
Nick

On Wed, Mar 27, 2024 at 9:44 AM Achilleas Anastasopoulos 
wrote:

> Hi all,
>
> I sent an email earlier but didn't get any response, so I am restating the
> problem in the hope that I will elicit some feedback.
>
> I would like to be able to reconfigure a flowgraph when a message is
> received by a block.
> Is there a mechanism to do that?
>
>
> Here is why I want to do it:
> I am building a system which uses a lot of resources for initial
> acquisition (think eg, of a FH system that tries to acquire the FH pattern,
> which I have implemented by a massively parallel filter bank).
> Once this is done, I want to "turn off" this part of the RX.
> I was thinking that a block will send an appropriate message once
> acquisition is achieved and this will trigger the reconfiguration of a
> flowgraph.
>
> thanks
> Achilleas
>
>
>
>
>
>

Re: Promblems with gr-air-modes in gnuradio 3.10

[Nick Foster]

Yep, gr-air-modes hasn't been built, installed, or tested by me. Needs the
usual rebuild-from-gr-modtool, and I haven't gotten around to it.

Nick

On Mon, Oct 3, 2022 at 11:52 AM Philip Balister  wrote:

> On 10/3/22 09:34, Michelle wrote:
> > Hi Cinaed,
> >
> > thank you for your answer, It seems like modes_rx (gr3.9 branch) under
> > GNU Radio 3.10 hangs somewhere on startup. @willcode4  will try to debug
> > it.
>
> https://github.com/bkerler/gnuradio_install/blob/main/install.sh#L275
>
> Suggests this is not fully ported to 3.10 yet.
>
> Philip
>
>
> >
> > have a good day.
> >
> > On 2022-10-02 19:52, Cinaed Simson wrote:
> >> Hi Michelle - the  source code version of gr-air-modes from github
> >>
> >>   https://github.com/bistromath/gr-air-modes.git
> >>
> >> indicates it should build under 3.9 but it doesn't build 3.10 - it
> >> can't find
> >>
> >>   GrSwig
> >>
> >> which is no longer supported.
> >>
> >> Sometimes OOT modules which work on 3.9 work on 3.10 - sometimes they
> >> don't.
> >>
> >> It's possible your version gr-air-modes has a different author from
> >> git hub version above.
> >>
> >> And I don't have a version of 3.9 either so I can't test it on 3.9 .
> >>
> >> -- Cinaed
> >>
> >>
> >>
> >> On 10/1/22 05:18, Michelle wrote:
> >>> Hello,
> >>>
> >>> I have gnuradio 3.10 and I wanted to install gr-air-modes. In the
> >>> chat one of the moderators told me the version of gr-air-modes that
> >>> is compatible with gr3.9 would work with gr3.10.
> >>> So I installed this version in my computer, the installation was
> >>> successfull however when I execute rx_modes I do not receive any
> >>> signal. The output of the command is :
> >>>
> >>> Inspiron-3793:~$ modes_rx
> >>> gr-air-modes warning: numpy+scipy not installed, FlightGear interface
> >>> not supported
> >>> [INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100;
> >>> UHD_3.15.0.0-2build5
> >>> [INFO] [B200] Loading firmware image:
> >>> /usr/share/uhd/images/usrp_b200_fw.hex...
> >>> [INFO] [B200] Detected Device: B200
> >>> [INFO] [B200] Loading FPGA image:
> >>> /usr/share/uhd/images/usrp_b200_fpga.bin...
> >>> [INFO] [B200] Operating over USB 2.
> >>> [INFO] [B200] Detecting internal GPSDO
> >>> [INFO] [GPS] No GPSDO found
> >>> [INFO] [B200] Initialize CODEC control...
> >>> [INFO] [B200] Initialize Radio control...
> >>> [INFO] [B200] Performing register loopback test...
> >>> [INFO] [B200] Register loopback test passed
> >>> [INFO] [B200] Setting master clock rate selection to 'automatic'.
> >>> [INFO] [B200] Asking for clock rate 16.00 MHz...
> >>> [INFO] [B200] Actually got clock rate 16.00 MHz.
> >>> [INFO] [B200] Asking for clock rate 32.00 MHz...
> >>> [INFO] [B200] Actually got clock rate 32.00 MHz.
> >>> Setting gain to 38
> >>> Gain is 38
> >>> Rate is 400
> >>>
> >>> please can i get some support to solve this problem?
> >>>
> >>>
> >>
> >>
> >
>
>

Re: Taylor detector

[Nick Foster]

David,

OK, I see what you're after now. Gnuradio isn't a SPICE simulator, so
getting it to fully represent your Tayloe mixer isn't really feasible.
Maybe the easiest way to accomplish what you're looking to do would be to
quantify the performance of your LTSpice simulation in a model of a
quadrature mixer that incorporates error parameters corresponding to your
mixer's simulated performance. In other words, make a Gnuradio block which
performs the job of the mixer, while adding the noise and nonlinearities
observed in your model -- conversion loss, thermal noise, and IQ imbalance,
for example. What you'd be missing is the end-to-end loop closure that lets
you make changes to the SPICE model and evaluate them easily.

You could also use GR to construct a synthetic transmission, like you
suggest, write it to disk, and convert it to a time series format that
LTSpice can ingest. I know that LTSpice's RAW data format is documented,
and it looks like there are a couple of Python packages which read and
write it. Because you can run LTSpice in batch mode, it's conceivable that
you could automate the whole process in Python -- generate a test signal,
write it to RAW, run it through LTSpice in batch mode, convert the
resulting RAW to a complex floating-point IQ signal Gnuradio can read, and
process it to extract performance parameters in Gnuradio again. Supposedly
there's also a Python LTSpice integration

that lets you do everything in Python, in which case you could make a
Python GR block that would just execute LTSpice from within the block
itself, in which case you could get really funky with parameter sweeps and
such.

Sounds like a fun project! If you do write such an integration, please
consider releasing it to the community as well.

Nick

On Fri, Aug 12, 2022 at 12:14 PM david vanhorn  wrote:

> I have built the detector in ltspice, but i was hoping to use gr to do a
> "soup to nuts" sim with multiple transmitters and various noise sources,
> feed that into the Tayloe, and then see what I could do downline from there
> to recover my signals.
>
> On Fri, Aug 12, 2022, 12:43 PM Marcus D. Leech 
> wrote:
>
>> On 2022-08-12 13:38, david vanhorn wrote:
>> > Ive been wrestling with this for a while, and im not even seeing how
>> > to get started implementing a Taylor detector in gr.
>> >
>> > Is it even possible?
>> You mean a *Tayloe* Quadrature Sampling Detector?
>>
>> This is ordinarily a *hardware component* of certain types of HF
>> direct-conversion receivers.
>>
>> Gnu Radio isn't, primarily, a hardware simulation environment, although
>> it is the case that many DSP transforms
>>have hardware analogues, it's not really a hardware simulator.
>>
>> It's probably best to tell us what you actually want to achieve, because
>> unless it's really "simulate a Tayloe QSD",
>>it's unlikely that building a Tayloe QSD in Gnu Radio is really going
>> to be that useful...
>>
>>
>>
>>

Re: Taylor detector

[Nick Foster]

David,

A Tayloe detector is of great utility in the "real world" of hardware as a
way to get a quadrature baseband signal from a real passband signal. In the
DSP world things are much easier!

If you have a real-valued signal (i.e., an audio stream), you first convert
it to a complex (quadrature) signal. You can do this in two ways. The first
way is more obvious: use a float-to-complex block and feed the real part
into the real input. Put a constant "0" into the imaginary input. The
result will have both positive and negative frequencies in it -- plot it on
a spectrogram! You can then filter out the negative frequencies with a
complex bandpass filter. Or don't, if they don't bother you: you can always
filter them out with a lowpass after mixing.

More simply, but less obviously, you can use a Hilbert filter to create a
quadrature signal from a real one while eliminating (most of) the negative
frequencies.

Once you have a complex signal, then you mix it with a complex sine wave at
the center frequency of your signal of interest. Mixing is just
multiplication, so use a multiply block with one input as your signal, and
one input the complex sine wave (i.e., from a "Signal Source" block).
Remember to mix with a *negative* frequency, as you're moving your signal
*down*. No NE602 needed! You'll have your complex signal at baseband and
can now filter, demodulate, or do whatever you want to it.

Nick

On Fri, Aug 12, 2022 at 10:43 AM david vanhorn  wrote:

> Ive been wrestling with this for a while, and im not even seeing how to
> get started implementing a Taylor detector in gr.
>
> Is it even possible?
>

Re: How to model class-B distortion of a complex signal

[Nick Foster]

Anish,

If you really just want to model crossover distortion in a class-B
amplifier, you could use a pair of Rail blocks:
[image: image.png]

If you're trying to model the distortion created by a real solid-state
amplifier, and not trying to correct it with predistortion, there are a
million different models which attempt to accurately characterize
distortion in SSPAs: Rapp, Saleh, and Ghorbani seem to be most widely used.
They're all pretty simple.

Here's a very simple, memoryless model (Ghorbani) implemented as an
embedded Python block:
https://gist.github.com/bistromath/75d30dd9691fd18211b306db630d8c4f

Some basic information about the model can be found here:
https://www.mathworks.com/help/comm/ref/memorylessnonlinearity.html

Nick

On Tue, Jan 25, 2022 at 12:03 PM Wheberth Damascena Dias 
wrote:

> Hello Anish,
>
> Non-linear  power amplifier modeling and pre-distortion is a vast subject.
>
> If you want to go deep in this matter I would suggest you to take a look
> at Baseband polinomial models.
>  Here a reference I have used some time ago:
> https://repositum.tuwien.at/handle/20.500.12708/13980
>
> If you just need something quick, you may want to lookout for AM/PM
> models, such as the Saleh model.
>
> Good luck!
>
> Best Regards
> Wheberth Dias
>
>
>
>
> On Tue, Jan 25, 2022, 20:44 Anish Mangal  wrote:
>
>> Hi,
>>
>> How should I go about modeling the distortion introduced by a class-B
>> amplifier stage that clips the signal when its value is below zero?
>>
>> Example:
>>
>> I want to combine two FM modulated signals, pass them through this
>> "class-B distorter", demodulate them, and analyze the quality of the signal
>> produced (compared with the undistorted one).
>>
>> How should I go about doing it.
>>
>> Created the flowgraph attached, but this is obviously wrong. :)
>>
>> --
>> Anish
>>
>>
>>
>>
>>

Re: VOLK C++ core

[Nick Foster]

On Tue, Dec 21, 2021 at 3:29 AM Marcus Müller  wrote:

> Hi Johannes,
>
> I, for one, like it :) Especially since I honestly find void
> volk_32fc_x2_s32fc_multiply_conjugate_add_32fc to be a teeny tiny bit
> clunky and would
> rather call a type-safe, overloaded function in a volk namespace called
> multiply_conjugate_add.
>
>
Yes, that's kind of my fault. It was the best option we could come up with
to be rigorously type-specific in C, kind of a bespoke implementation of
name mangling. The original motivation, of course, was the VOLK dispatcher.
C was a hard requirement at the time, and I confess I don't remember why. I
think it came down from namccart's original donation of vectorized code.

I would be very happy to see VOLK move to C++ (or at least provide
wrappers). I strongly advocate for using C++20 -- std::span, variadic
arguments, lambdas etc. seem tailor-made for VOLK. Runtime dispatching
could be positively elegant, compared to how it must be done in C. And
C++20 finally makes C++ a much less Lovecraftian nightmare of a language
than the one I learned from Stroustrop.

Nick


> Re: RFC: can we have something like a wiki page (maybe on the VOLK repo?)
> to collect these
> comments?
>
> You mention spans, so C++-VOLK would be >= C++20?
>
> Cheers,
> Marcus
>
> On 21.12.21 10:55, Johannes Demel wrote:
> > Hi everyone,
> >
> > today I'd like to propose an idea for the future of VOLK. Currently,
> VOLK is a C library
> > with a C++ interface and tooling that is written in C++.
> >
> > I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a
> C interface if
> > the need arises.
> >
> > This email serves as a request for comments. So go ahead.
> >
> > Benefits:
> > - sane std::complex interface.
> > - same compilation mode on all platforms.
> > - Better dynamic kernel load management.
> > - Option to use std::simd in the future
> > - Less manual memory management (think vector, ...).
> >
> > Drawbacks:
> > - It is a major effort.
> > - VOLK won't be a C project anymore.
> >
> > Why do I propose this shift?
> > VOLK segfaults on PowerPC architectures. This issue requires a breaking
> API change to be
> > fixable. I tried to update the API to fix this isse.
> > https://github.com/gnuradio/volk/pull/488
> > It works with GCC and Clang but fails on MSVC.
> > One might argue that PowerPC is an obscure architecture at this point
> but new
> > architectures might cause the same issue in the future. Also, VOLK tries
> to be portable
> > and that kind of issue is a serious roadblock.
> >
> > How did we get into this mess?
> > The current API is a workaround to make things work for a specific
> compiler: MSVC. MSVC
> > does not support C `complex.h` at all. The trick to make things work
> with MSVC is:
> > compile VOLK in C++ mode and pretend it is a C++ library anyways.
> > In turn `volk_complex.h` defines complex data types differently
> depending if VOLK is
> > included in C or C++. Finally, we just hope that the target platform
> provides the same
> > ABI for C complex and C++ complex. C complex and C++ complex are not
> compatible.
> > However, passing pointers around is.
> > Thus, the proposed change does not affect Windows/MSVC users because
> they were excluded
> > from our C API anyways. The bullet point: "same compilation mode on all
> platforms"
> > refers to this issue.
> >
> > Proposed timeline:
> > Together with our re-licensing effort, we aim for a VOLK 3.0 release.
> VOLK 3.0 is a good
> > target for breaking API changes.
> >
> > Effects:
> > I'd like to make the transition to VOLK 3.0 as easy as possible. Thus,
> I'd like to keep
> > an interface that hopefully doesn't require any code changes for VOLK
> 2.x users. A
> > re-built of your application should be sufficient. However, we'd be able
> to adopt a
> > C++-ic API as well. e.g. use vectors, spans etc.
> >
> > The current implementation to detect and load the preferred
> implementation at runtime is
> > hard to understand and easy to break. C++ should offer more accessible
> tools to make
> > this part easier.
> >
> > What about all the current kernels?
> > We'd start with a new API and hide the old kernel code behind that
> interface. We come up
> > with a new implementation structure and how to load it. Thus, we can
> progressively
> > convert to "new-style" implementations.
> >
> > Another bonus: std::simd
> > Currently, std::simd is a proposal for C++23. Making VOLK a C++ lib
> would allow us to
> > eventually use std::simd in VOLK and thus make Comms DSP algorithms more
> optimized on
> > more platforms.
> >
> > Cheers
> > Johannes
> >
>
>

Re: gnuradio compilation and also gr-air-modes issue

[Nick Foster]

This discussion probably belongs on the gr-air-modes Github issues page.
And I should probably finish testing and releasing gr-air-modes for GR 3.9.

Nick

On Mon, Nov 8, 2021 at 12:35 AM li...@lazygranch.com 
wrote:

> I always try to search for an answer before bugging a forum. Not
> knowing much about git, OK make that zero, I didn't know where to apply
> the checkout command line. Amazying how official documentation is writen
> for someone who actual knows what they are doing. Fortunately there is
> stackoverflow.
>
> https://stackoverflow.com/questions/52200308/why-git-checkout-after-git-clone
> So the procedure is:
>
> git clone xxx
> cd xxx
> git checkout yyy
>
> So it compiles using the gr3.9 checkout but I neglected to mention
> another issue because I didn't think I would need to use a GUI. Here is
> the cmake ..\
>
> ---
> cmake ../
> -- Build type not specified: defaulting to release.
> -- Found PythonInterp: /usr/bin/python3.6 (found version "3.6.12")
> -- Using GMP.
> -- User set python executable /usr/bin/python3
> -- Found PythonInterp: /usr/bin/python3 (found version "3.6.12")
> -- Extracting version information from git describe...
> -- Using install prefix: /usr/local
> -- Building for version: d6109d3c / 1.0.0git
> -- Python checking for pygccxml - not found
> CMake Warning at res/CMakeLists.txt:28 (find_package):
>   By not providing "FindPyQt4.cmake" in CMAKE_MODULE_PATH this project has
>   asked CMake to find a package configuration file provided by "PyQt4", but
>   CMake did not find one.
>
>   Could not find a package configuration file provided by "PyQt4" with any
> of
>   the following names:
>
> PyQt4Config.cmake
> pyqt4-config.cmake
>
>   Add the installation prefix of "PyQt4" to CMAKE_PREFIX_PATH or set
>   "PyQt4_DIR" to a directory containing one of the above files.  If "PyQt4"
>   provides a separate development package or SDK, be sure it has been
>   installed.
>
>
> -- PyQt4 not found, not installing GUI application
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /usr/local/src/gr-air-modes/build
>
> -
> Running modes_rx:
>
>  modes_rx --help
> Traceback (most recent call last):
>   File "/usr/local/bin/modes_rx", line 26, in 
> import air_modes
>   File "/usr/local/lib64/python3.6/site-packages/air_modes/__init__.py",
> line 31, in 
> from .air_modes_python import *
> ImportError: generic_type: type "preamble" referenced unknown base type
> "gr::block"
> 
> Using the locate command there is no FindPython4.cmake:
>
> /usr/share/cmake/Modules/FindPython.cmake
> /usr/share/cmake/Modules/FindPython2.cmake
> /usr/share/cmake/Modules/FindPython3.cmake
>
>
> On Sun, 7 Nov 2021 20:38:34 -0800
> Ron Economos  wrote:
>
> > The error message is due to trying to compile an OOT (gr-air-modes)
> > that's using GNU Radio 3.8 on your install of GNU radio 3.9.
> >
> > There is a branch on gr-air-modes called "gr3.9" that looks like it
> > could work, although the commit messages say "WIP with plenty of
> > untested code". To switch to that branch:
> >
> > git checkout gr3.9
> >
> > As for the compile taking longer with -j, this usually means you
> > don't have enough memory. GNU Radio requires about 1 GB per core.
> >
> > Ron
> >
> > On 11/7/21 6:59 PM, li...@lazygranch.com wrote:
> > > Yes I know this list is specifically for gnuradio. I just compiled
> > > 3.9.0.4 from source (github) on opensuse 15.2 and all went well.
> > > When I ran the "make test" it seemed a bit slow then I realized I
> > > forgot to specify the number of CPUs (the j option). Doing a "make
> > > clean" then the properly flaged make the compilation took way
> > > longer. Just an observation but very interesting. Next time I do a
> > > build I will save the single CPU results from the 2cpu test for
> > > comparison.
> > >
> > > Regarding compilation of code in general (not specific to gnuradio)
> > > I have noticed with gcc10 a number of compilations bomb due to
> > > changes in the compiler. Thus far I have been able to edit my way
> > > (change compiler flags) out of the problem using tips found on the
> > > internet. Just something to be on the lookout for.
> > >
> > > Now regarding gr-air-modes I did file an "issue" on github but I
> > > figured I would run the error past the hive because maybe it is
> > > another fix that can been done with editing.
> > >
> > > Here is the error:
> > >
> > > [ 11%] Building CXX object
> > > lib/CMakeFiles/air_modes.dir/preamble_impl.cc.o
> > > /usr/local/src/gr-air-modes/lib/preamble_impl.cc: In static member
> > > function ‘static gr::air_modes::preamble::sptr
> > > gr::air_modes::preamble::make(float, float)’:
> > > /usr/local/src/gr-air-modes/lib/preamble_impl.cc:38:38: error:
> > > could not convert ‘gnuradio::get_initial_sptr(T*) [with T =
> > > gr::air_modes::preamble_impl]()’ from
> > > ‘std::shared_ptr’ to
> > > ‘gr::air_modes::preamble::sptr’ {aka

Re: Proper GMSK Decoding with the Viterbi Algorithm

[Nick Foster]

There aren't blocks in Gnuradio to do this out of the box, at least not on
real signals. Unless you're working with low SNR signals, or the GMSK BT
product is very low (under 0.25, let's say), it will be of somewhat limited
benefit to use Viterbi decoding. Synchronization also becomes a limiting
factor at these low SNRs: if you are working with short packets (like, say,
AIS) you will have to use a data-aided estimator which operates on an
entire packet since a normal bit-by-bit estimator will not converge fast
enough, or accurately enough, at low SNR.

That said, a basic GMSK demodulator (without equalization, frequency offset
correction, or Viterbi decoding) would look like this: AGC -> Symbol sync
(use the D'Andrea and Mengali Gen MSK TED) -> Quadrature demod -> Binary
slicer. At this point you have bits, and you can do what you like with them.

Nick

On Fri, Sep 17, 2021 at 4:04 PM  wrote:

> Hello all,
>
>
>
> I’ve been messing around with GNU Radio for the past couple of months, and
> I’m struggling to come up with a way to properly decode GMSK using the
> Viterbi algorithm.  The GMSK Demod block works just fine, but since the
> packet decoder block is deprecated I can’t think of another way to get data
> out of the transmissions.  Basically I’m just looking for guidance in which
> blocks to use and what order to use them in, and I can handle the rest
> myself.  I’ve made a couple of flowgraphs that seem to be on to something,
> but I’m not really sure.  Any help would be appreciated.
>
>
>
> Thanks,
>
> Patrick
>

Re: USRP source starts to receive after certain samples

[Nick Foster]

I am guessing you mean X310, since E310 doesn't take daughterboards. You
are seeing the effect of FIR filter delay in the USRP's halfband filters.
You can confirm this by setting the sample rate to (for instance)
200Msps/511. The use of an odd factor will result in lower filter delay but
increased amplitude error toward the edges of the received spectrum.

This effect also occurs on the TX side, but because the timed transmission
is queued and buffered at the radio component (which operates at 200Msps)
after upconversion, the resulting latency will be much smaller: 200Msps/42,
or about 200ns.

Nick

On Wed, Jun 16, 2021 at 2:09 AM Huang Wei  wrote:

> Hi all,
>
> I am very new to Gnuradio and USRP, and I have a question about the code
> transmission delay between USRPs.
> I have two USRP E310 with UBX160 daughterboards. I send a sequence of code
> from one USRP using simple amplitude modulation, and receive it by another
> USRP. On the receiver side, I use a replica of the code to cross-correlate
> with the received code to compute the transmission delay. However, I can’t
> explain this delay I obtained:
>
>1. when I set the sample rate to 200MHz/128, the delay is 26.837 us (≈
>42 samples);
>2. Sample rate to 200 MHz/256, the delay is 0.0537 ms (≈ 42 samples);
>3. Sample rate to 200 MHz/512, the delay is 0.105 ms (≈ 41 samples).
>
> Also I recorded the date received by the USRP, it clearly shows that, no
> matter the sample rate is, the USRP source starts to receive the code after
> the 41st samples, and before are some strange values. You can find them in
> the attached plot.
>
> My questions are
>
>1. why the transmission delay of the code are based on certain number
>of samples? should it be a certain value (some micro or Pico second)? In my
>case this delay changes with the sample rate.
>2. what are those values received by USRP before the received code?
>they have some similar behaviors.
>3. Maybe it’s not the correct way to check the transmission delay. Is
>there any better method for measuring it (e.g. adding time stamps)? I used
>USRP “rx_time” stream tags, and it always shows (xxx, 5e-9), like when it
>starts to receive something, maybe only the noise.
>
> (Additionally, both USRPs have their 1 PPS and frequency ref synchronized
> to the external high quality atomic clock. And I set them to start
> transmit/receive data at exactly the same time.)
>
> I appreciate a lot for any comment or advice !
>

Re: B200 clock and pulse timing

[Nick Foster]

>
> I’d like to better understand the clock in the B200/B210.
>
> First, what is the actual resolution of the clock?  Is it any more
> precise than the 100 nanoseconds a 10 MHz external reference provides?  When
> the USRP timing is set to external, does the 10 MHz directly increment the
> clock or is the on-board oscillator still involved somehow?
>

The clock is locked to the 10MHz external reference and uses 1PPS as a
trigger to initialize the sample clock to a given time at startup. Accurate
timing requires the 1PPS trigger to be synchronous to the 10MHz source. In
practice this means they should come from the same GPSDO. The 10MHz
reference does not directly increment the sample clock. It is used to lock
the main oscillator's PLL and thus makes it also synchronous to the 1PPS
trigger.

My software begins streaming samples from the B200 at a fixed rate.
>
> Inside a loop I call uhd_rx_streamer_recv () and use the associated
> metadata timestamp to note the time the first sample in the read buffer
> arrived.  Obviously the read buffer has a fixed length and therefore
> represents a fixed amount of time at my sample rate; the software uses this
> value in the processing below.
>
> Also in that loop, the software calls get_time_last_pps() and compares the
> result to a previous get_time_last_pps() call to determine if a pulse
> arrived on the PPS port.
>
> Prior to receiving a PPS pulse, this loop continues, discarding the sample
> buffer after the PPS comparison.
>
> When a pulse arrives, the software compares the sample buffer metadata
> timestamp to the last PPS timestamp.  The software uses that time
> difference to determine if the sample buffer should be discarded; the goal
> is to discard all of the samples that arrived prior to the PPS pulse.  If
> the difference between the sample buffer timestamp and the PPS timestamp is
> greater than the buffer length time, the sample buffer is discarded and the
> uhd_rx_streamer_recv() is called again to read the next set of samples.
>
> When the difference between the most recently read sample buffer timestamp
> and the PPS timestamp is less than the buffer length time, the software
> drops the first part of the sample buffer corresponding to that difference,
> in essence dropping the samples that arrived prior to the exact PPS time.
> The software then calls uhd_rx_streamer_recv () repeatedly, appending new
> samples to the first partial sample buffer until the desired total number
> of samples are collected.
>
> Does this method make sense to achieve my goal of collecting samples
> immediately after a PPS trigger pulse?  Is there an easier way to achieve
> this goal?
>

Yes. Use the timed command functionality to trigger reception of a discrete
number of samples at the time you wish to receive them -- in this case,
1.000s, 2.000s, etc. If the sample clock is initialized using external
1PPS, and it is also locked to a synchronous 10MHz source, your samples
will be returned to you nicely aligned.


> Testing this method has shown that the number of sample buffers returned
> via the recv() call relative to the PPS pulse varies, sometimes
> significantly.  On average, discarding two or three sample buffers brings
> the subsequent sample timestamp to within the fixed buffer length (time) of
> the last PPS pulse.  However, there are circumstances when dozens or even
> a hundred sample buffers need to be discarded because their metadata
> timestamps are all prior to the PPS timestamp.
>
> Is it reasonable that the sample buffer timestamp could be so far behind
> the PPS pulse time on occasion?
>

Use timed commands to trigger reception. Ignore get_time_last_pps(). Doing
sample timing from within a loop on the host computer (behind many buffers,
operating on a different clock, nondeterministically interrupted) is asking
for lost data and race conditions. If you require very accurate
antenna-plane sample time you will need to compensate for front end, ADC,
and DSP delays in the AD9361. There are various ways of doing this, none of
them particularly convenient.

Nick


>
>
> Thanks!
>
>

Re: Is there a way to change the number of taps of the FIR filter in GNURadio while running?

[Nick Foster]

It looks like the GRC convenience blocks for the filter tap generation
don't have working callbacks -- although, from the YAML it looks like they
should work. There might be a bug in there.

The actual filter generation callbacks work -- if you replace "lp_taps" in
the low-pass filter with "firdes.low_pass(1, samp_rate, cutoff_high,
transition, firdes.WIN_HANN), for instance, then changing the parameters
with a QT GUI Range slider will work just fine. It's just the convenience
blocks which don't work.

Nick

On Wed, Mar 3, 2021 at 7:15 PM Jay Patel  wrote:

> Hi all,
>
> I am using GNURadio example Filter Introduction flow graph which shows
> basic introduction of filtering. I want to change the no. of taps while
> running the program. I tried to put the qt gui range but it looks like
> GNURadio creates/calculates taps as a static vector in the start of the
> execution of the flow graph.
>
> [image: image.png]
>
> Is there a work around this ?  I mean can I put a slider or counter for
> changing the transition_width which changes the number of taps while
> running the flow graph ?
> Thanks. Any suggestions are appreciated.
>
> *With Regards,*
> *Jay Patel*
>
>
>

Re: [Announcement] Shift in Maintainership

[Nick Foster]

Just want to chime in to say: Marcus, thank you! Your work these last few
years has been much appreciated by the community. Maintaining a large FOSS
project is a huge endeavor, and your excellent communication and inclusion
of the community has made it stronger. I'm glad for you to have the
opportunity to do some more (fun!) technical development on the project.

Nick

On Thu, Feb 18, 2021 at 10:15 AM Marcus Müller 
wrote:

> Dear GNU Radio community,
>
> at FOSDEM 2018, I was asked whether I'd be happy to take over
> maintainership of the GNU
> Radio project, something I've been very eager to do; by then, I had known
> the community
> for a little more than 8 years, and the project had grown to be an
> important factor in
> what I did on a day-to-day scale. It's been basically become family,
> anyways, and I was
> asked to play a decisive role in that.
>
> That maintainership came with a role as an software, and what's more
> important, ecosystem
> architect. That's something I quite enjoyed, as it means that as long as
> there's direction
> and progress towards that, I got to shape what my favourite software
> project looks like.
> Pair that with the incredible amount of talent and resources that go into
> the most
> prolific SDR framework in the solar system, and you've got really quite a
> grand thing
> going on there! It's really been more akin to asking giants to move hills
> in a way that
> suits the scenery than wielding a hoe to shape one's own garden. And it's
> really been a
> fun, rewarding, and hopefully productive time:
>
> In these three years, we've managed to finally move from the 3.7 era to a
> modern 3.8 era,
> by which we succeeded to get the GNU Radio cart out stasis, and we've even
> went another
> step and started the 3.9 era, where I hope modern tools and perspectives
> on software
> development allow GNU Radio to move at a high speed.
>
> This might be a good time to give the authority to be the one to make
> calls back to the
> project. This means the General Assembly and the GNU Radio board will
> figure out how to
> find a successor for my former position. For the meantime, Derek Kozel and
> Martin Braun
> will take that power and use it for the best of the project for the near
> future.
>
> I'll of course still be involved with GNU Radio (wouldn't know which other
> project could
> stand me...), but will be able to focus on concrete aspects, which might
> both be on the
> community side, as well as on technical projects. It's just that we're
> shifting away from
> me being a bottleneck to development!
>
> I'm very grateful that Martin and Derek found the time to take over this
> responsibility,
> especially since I know they share my enthusiasm for the project, SDR and
> its users.
>
> Best regards,
> Marcus
>
>

Re: release repository changed names, unwanted forced update to 3.9.0, broke all flowgraphs

[Nick Foster]

I went into this assuming it would be easy to downgrade to 3.8, and
discovered it was not. All of the individual 3.8.[1,2] packages are in
there labeled with their version in the name, but the main 'gnuradio'
package installs 3.9.

Maybe it's a good opportunity to create a gnuradio-3.8 metapackage in the
PPA? If we're going to be providing long-term support for 3.8, that should
probably include supporting its installation and update as well.

That said, you should be able to specifically install 3.8 and prevent it
from updating by doing:

$ apt-cache policy gnuradio
gnuradio:
  Installed: (none)
  Candidate: 3.9.0.0-0~gnuradio~focal-1
  Version table:
 3.9.0.0-0~gnuradio~focal-1 500
500 http://ppa.launchpad.net/gnuradio/gnuradio-releases/ubuntu
focal/main amd64 Packages
 3.8.1.0~rc1-2build2 500
500 http://us.archive.ubuntu.com/ubuntu focal/universe amd64
Packages
100 /var/lib/dpkg/status
$ sudo apt remove gnuradio
$ sudo apt install gnuradio=3.8.1.0~rc1-2build2

I don't know why 3.8.2 packages exist if the other installation candidate
for the main package is only 3.8.1. Ideally we would have a 3.8 package
which would receive updates from the maint-3.8 branch via PPA.

Nick

On Fri, Feb 19, 2021 at 7:48 AM Tom McDermott  wrote:

> In trying to update all software in Ubuntu 20.04 using the GUI updater
> tool, the updater failed due to
> unable to access some repository.   sudo apt update identified the
> gnuradio PPA focal changing the
> name of the release from something like gnuradio releasesto  gnuradio
> - releases
>
> I accepted the update and then continued the upgrade.
>
> This update downloaded and replaced gnuradio 3.8 with gnuradio 3.9Now
> all of my flowgraphs
> fail due to numerous errors, some of them are complaining filter parameter
> name errors, etc.
>
> Is there some easy way to revert this change without having to rip all of
> gnuradio out, find the 3.8
> repository, and start all over again?   If not, what did the 3.8
> repository change its name to?
>
> -- Tom, N5EG
>
>
>
>

Re: encode and modulation

[Nick Foster]

Among other things, the GMSK Mod block expects packed bytes. Remove the Map
block and add an Unpacked to Packed block in its place. The filter
parameters on the receiver are also incorrect and will filter out most of
your signal.

In general, every time you make a change you must view the baseband
spectrum and time domain signal (at least) to confirm that the change you
expect is the change you see.

Nick


On Wed, Feb 3, 2021 at 7:26 AM kaihua cheng  wrote:

> Hello, I want to build a transceiver by using CCSDS and GMSK.  I have no
> problem with running CCSDS alone.  But once I add GMSK, the decoding is
> completely off.  can someone help me with it?  below is the attachment!
> thank you
>

Re: Passing real data from a thread to the next block

[Nick Foster]

This is probably best done from the top-level flowgraph. Have the flowgraph
call a member function of your OOT block which sends the commands, before
calling start() or run() on the flowgraph.

Nick

On Tue, Nov 17, 2020 at 5:36 PM isaac mario tupac davila <
isacct...@gmail.com> wrote:

> Hi Marcus
>
> Thanks for your answer. I am restructuring the design of my OOT block.
>
> I'd like to ask a last question about it...I am trying to send some
> commands (array of bytes) to an external hardware only ONCE before starting
> with my real time data acquisition . The problem is that if I implement the
> sending of the commands in the general work of my block, the commands will
> be sent each time the general work finishes and starts again. My solution
> proposed is to begin the execution of my flowgraph and send an external
> signal (specifically kill -SIGIO PID) from terminal to call the
> implemented method which sends the commands, so that my general work will
> only focus on the data acquisition and I will send the commands only once.
>
> My question is: Is there a facility or tool that GNU Radio gives me to
> solve this situation? There should be a more suitable solution.
>
> Any help or recommendation would be appreciated.
> Thanks
>
> Regards
> Isaac.
>
>
>
> El dom., 15 nov. 2020 a las 13:50, Marcus Müller ()
> escribió:
>
>> Hello,
>>
>> On 15.11.20 06:26, isaac mario tupac davila wrote:
>> > Hello
>> >
>> > I'm Isaac.
>>
>> Hi Isaac, nice having you.
>>
>> > I have a question about threads. I've created three
>> > threads and I want to pass real data from one thread to the next block
>> > directly without returning to the general work method.
>>
>> That sounds like a misguided design approach. Please don't do that.
>>
>> The work function is meant to be seen as atomically processing a bit of
>> data from its input to its output.
>>
>> If you need asynchronous messaging, then use the msg_passing facilities.
>> These make sure you don't change the state of the block while its
>> general_work is executing.
>>
>> > I could give
>> > value to the out array in the thread but for some reason the data
>> > doesn't pass to the next block. I am not sure if it's because I didn't
>> > put: return noutput_items in the thread,
>>
>> What you describe as thread makes no sense – the way GNU Radio is,
>> there's exactly one thread executing a block's general_work at a time,
>> and that's the thread of the block_executor. And `return` ends that
>> execution; that's how C++ works.
>>
>> > as normally this is in the
>> > general work method... I also add that the function is defined in the
>> > thread as void*function and I defined the out array as a
>> complex*.
>> >
>> > Any help would be appreciated.
>>
>> I'm afraid there's something not GNU Radio-compatible in the way you've
>> architected your system, but we sadly don't know your system well enough
>> to comment on what to change.
>>
>> Best regards,
>> Marcus
>>
>>

Re: SWIG doesn't recognize argument in make()

[Nick Foster]

You're not crazy. I've seen similar behavior. Does it work if you remove
the underscore? The number?

Who can fathom the esoteric secrets of SWIG?

On Mon, Nov 16, 2020 at 3:06 PM Lukas Haase  wrote:

> Additional detail: I tried it again:
>
> $ gr_modtool rm tx_msg2tag
> $
> $ gr_modtool add test
> $ rm -rf build; mkdir build; cd build; cmake ..; make
>
> --> WORKS!!
>
> $ gr_modtool add tx_msg2tag
> $ rm -rf build; mkdir build; cd build; cmake ..; make
>
> --> FAILS with the error below.
>
>
> (of course, I edited the files to replace the <+...+> to make it compile).
>
> It really seems it's the name of the block (tx_msg2tag) that makes things
> fail.
> How can that be?
>
> Lukas
>
> Lukas wrote:
> > Hi Cinaed,
> >
> > *I* am the author of gr-petro ;-)
> > This is indeed a SWIG question. Or a question about OOT modules.
> >
> > I created the module with gr_modtool. I inserted bunch of blocks with
> "add"
> > command. Just this one below does not work. I have no idea why (and it
> drives
> > me crazy).
> >
> > Hence my questions:
> > - What could be the issue?
> > - What exactly generates *swigPYTHON_wrap.cxx files ?
> > - How are the argument lists for the functions determined?
> >
> > Thanks,
> > Lukas
> >
> >
> >> Hi Lukas - gr-petro is a OOT module - an "out of tree "module - it's
> not
> >> part of gnuradio.
> >>
> >> You need to contact the author of the module.
> >>
> >> It's highly unlikely it's a problem with make - it's more likely a
> >> mismatch between gr-petro and your installed version of gnuradio.
> >>
> >> For instance, the OOT was written for a version of gnuradio prior to
> >> 3.8.
> >>
> >> In any case, I couldn't find the gr-petro source code with a Google
> >> search so I can't even guess what the problem might be. It also helps
> to
> >> state which OS you're using.
> >>
> >> -- Cinaed
> >>
> >>> Hi everyone,
> >>>
> >>> It's driving me NUTS! SWIG just won't recognize an argument to my
> make()
> >>> function and hence build fails. I have other nearly identical blocks
> in
> >>> the same module that work without issues.
> >>>
> >>> What exactly generates the *swigPYTHON_wrap.cxx files and how are the
> >>> argument lists for the functions determined?
> >>>
> >>> Here is how my make fails:
> >>>
> >>> [ 77%] Building CXX object
> >>>
> swig/CMakeFiles/petro_swig.dir/CMakeFiles/petro_swig.dir/petro_swigPYTHO
> >>> N_wrap.cxx.o
> >>>
> /home/petro/src/gr38/gr-petro/build/swig/CMakeFiles/petro_swig.dir/petro
> >>> _swigPYTHON_wrap.cxx: In function ‘PyObject*
> >>> _wrap_tx_msg2tag_make(PyObject*, PyObject*)’:
> >>>
> /home/petro/src/gr38/gr-petro/build/swig/CMakeFiles/petro_swig.dir/petro
> >>> _swigPYTHON_wrap.cxx:18687:48: error: no matching function for call to
> >>> ‘gr::petro::tx_msg2tag::make()’ 18687 | result =
> >>> gr::petro::tx_msg2tag::make(); |
> >>> ^ In file included from
> >>>
> /home/petro/src/gr38/gr-petro/build/swig/CMakeFiles/petro_swig.dir/petro
> >>> _swigPYTHON_wrap.cxx:2881:
> >>> /home/petro/src/gr38/gr-petro/lib/../include/petro/tx_msg2tag.h:48:19:
> >>> note: candidate: ‘static gr::petro::tx_msg2tag::sptr
> >>> gr::petro::tx_msg2tag::make(unsigned int)’ 48 | static sptr
> >>> make(unsigned int time_increment_factor); | ^~~~
> >>> /home/petro/src/gr38/gr-petro/lib/../include/petro/tx_msg2tag.h:48:19:
> >>> note: candidate expects 1 argument, 0 provided
> >>>
> /home/petro/src/gr38/gr-petro/build/swig/CMakeFiles/petro_swig.dir/petro
> >>> _swigPYTHON_wrap.cxx: In function ‘PyObject*
> >>> _wrap_tx_msg2tag_sptr_make(PyObject*, PyObject*)’:
> >>>
> /home/petro/src/gr38/gr-petro/build/swig/CMakeFiles/petro_swig.dir/petro
> >>> _swigPYTHON_wrap.cxx:18914:30: error: no matching function for call to
> >>> ‘gr::petro::tx_msg2tag::make()’ 18914 | result = (*arg1)->make();
> >>> | ^ In file included from
> >>>
> /home/petro/src/gr38/gr-petro/build/swig/CMakeFiles/petro_swig.dir/petro
> >>> _swigPYTHON_wrap.cxx:2881:
> >>> /home/petro/src/gr38/gr-petro/lib/../include/petro/tx_msg2tag.h:48:19:
> >>> note: candidate: ‘static gr::petro::tx_msg2tag::sptr
> >>> gr::petro::tx_msg2tag::make(unsigned int)’ 48 | static sptr
> >>> make(unsigned int time_increment_factor); | ^~~~
> >>> /home/petro/src/gr38/gr-petro/lib/../include/petro/tx_msg2tag.h:48:19:
> >>> note: candidate expects 1 argument, 0 provided make[2]: ***
> >>> [swig/CMakeFiles/petro_swig.dir/build.make:63:
> >>>
> swig/CMakeFiles/petro_swig.dir/CMakeFiles/petro_swig.dir/petro_swigPYTHO
> >>> N_wrap.cxx.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:466:
> >>> swig/CMakeFiles/petro_swig.dir/all] Error 2 make: *** [Makefile:141:
> >>> all] Error 2
> >>>
> >>> As can be very, very clearly seen, tx_msg2tag::make(unsigned int) has
> >>> ONE parameter (time_increment_factor). Yet SWIG wants to call
> >>> gr::petro::tx_msg2tag::make().
> >>>
> >>> I have tried regenerating the file, deleting build directory and
> >>> starting from scratch but this error follows me like a nightmare.
> >>>
> >>> Thanks for suggestions!
> >>>
> 

Re: Symbol timing estimator block and CPM modulations

[Nick Foster]

Thanks for the feedback, Andy! I'm back at this now. I've filed a bug on it
with my findings so far. Comments welcome.

https://github.com/gnuradio/gnuradio/issues/3678

Nick

On Mon, Jun 29, 2020 at 1:06 PM Andy Walls 
wrote:

> Hi Nick:
>
> On Wed, 2020-06-24 at 17:39 -0700, Nick Foster wrote:
> > Hi,
> >
> > I'm finally getting around to doing some more CPM work
>
> I forgot to mention, my company found the GMSK demoulation technique
> found in this paper:
>
>
> https://www.researchgate.net/publication/241629765_Coherent_demodulation_of_AIS-GMSK_signals_in_co-channel_interference
>
> coupled with the "method 0" CFO correction in this paper:
>
>
> https://www.researchgate.net/publication/290776860_Preprocessing_AIS_Signals_for_Demodulation_in_Co-Channel_Interference
>
> along with analog RF components in front of an SDR, and precise timing
> with a GPSDO w/PPS to aid in looking for preambles, gave us fantastic
> results for AIS reception in GNURadio.
>
> Although it required quite a few custom blocks.
>
> Anyway, Douglas Nelson seems to have a lot of cool papers available in the
> public:
>
> https://www.researchgate.net/profile/Douglas_Nelson8
>
> Regards,
> Andy
>
> > Best,
> > Nick
>
>
>

Re: Modifying Offset Stream Tag

[Nick Foster]

Yes -- use a faster sample rate. At some point (10-20Msps in my experience)
you will run into diminishing returns due to both the finite bandwidth of
the transmitted signal and its received SNR (due to the CRLB).

Nick

On Tue, Jun 23, 2020 at 7:11 AM Adam Gorski  wrote:

> Nick, Jeff,
>
>
>
> Thank you for the detailed feedback. I am indeed doing multilateration on
> ADS-B signals, will investigate procuring a GPSDO for accurate timing.
>
>
>
> The way I understand it, once I’m using the GPSDO to acquire an accurate
> timestamp the offset added to each message will still be at a minimum 500ns
> (at 2Msps). Is there anything that can be done to decrease this amount?
>
>
>
> Thanks,
>
>
>
> Adam Gorski
>
> Virginia Tech Applied Research Corporation (VT-ARC)
>
> Wireless Communications Systems Engineer
>
> 410-818-3188
>
>
>
> *From:* Nick Foster 
> *Sent:* Sunday, June 21, 2020 7:01 PM
> *To:* Adam Gorski 
> *Cc:* discuss-gnuradio@gnu.org
> *Subject:* Re: Modifying Offset Stream Tag
>
>
>
> I think you are misunderstanding what the tag offset represents. The
> timestamp is coming from datetime.datetime.utcnow() in init(), and the tag
> offset added to that is just the offset (samples since the flowgraph
> started) of the burst divided by the sample rate. Because the burst offset
> is in *samples* and not *seconds*, its resolution is limited to
> 1/samp_rate. Thus, at 2Msps, the resolution is limited to 500ns. In any
> case, Gnuradio knows nothing at all about time -- it only knows about
> samples.
>
>
>
> To play Clippy for a bit, it sounds like you're trying to do
> multilateration on ADS-B signals. The approach being used in gr-adsb will
> not work for this. You cannot use the host clock (i.e., datetime) because
> its accuracy is nowhere near what is required (if you're using
> PTP/IEEE-1588 with a local timeserver you'll be closer, but it will still
> be a mess). You need to synchronize the radio to GPS time either using a
> built-in GPSDO, or an external one.
>
>
>
> If the radio is not synchronized to a GPSDO, then instead of one problem
> you will have two: the initial time (since it's CPU time) will be wrong,
> and the time offset will drift over time (since the sample rate of the
> radio will not be synchronized).
>
>
>
> Nick
>
>
>
> On Sun, Jun 21, 2020 at 2:56 PM Adam Gorski 
> wrote:
>
> Hello community,
>
>
>
> I am currently using an out of tree module (gr-adsb) with GNU Radio 3.7
> that captures received ADSB messages. I would like to change the timestamp
> resolution for each message received from microseconds to nanoseconds. The
> timestamp of each message is declared in the demod.py (attached) by adding
> the start time of the block to the offset stream tag (line 111 in
> demod.py).
>
>
>
> The offset stream tag is not declared within the out of tree module, but
> somewhere in the GNU Radio source code. There are a handful of python files
> within the GNU Radio source code that include the offset tag, however I
> believe the declaration may lie in one of the following files (these have
> essentially the same code):
>
>- ~/gnuradio/gnuradio-runtime/python/gnuradio/gr/packet_utils.py
>- ~/gnuradio/gr-digital/python/digital/utils/tagged_streams.py
>
>
>
> I would like to declare the offset tag with a nanosecond resolution. I
> have been able to accomplish this type of declaration with the demod block
> start time by calling a c function within a shared library, however I’m
> unsure how to do the same within GNU Radio source code as any sort of test
> print statements within the two files listed above never gets displayed in
> the flowgraph output.
>
>
>
> My questions:
>
>- Is one (or both) of the files indicated above the correct file to
>modify?
>- How do I test modifications to GNU Radio source code files?
>- Are there other methods of changing the offset tag resolution I
>should consider?
>
>
>
> The c function and shared library code is as follows. I chose this way due
> to the flowgraph code builder in GNU Radio 3.7 using python2; if I used a
> python3 function I believe I’d have to rewrite the flowgraph code builder
> in python3.
>
>
>
> Time_ns.c:
>
>
>
> #include 
>
> #include 
>
>
>
> long long time_ns() {
>
> struct timespec t0;
>
> clock_gettime(CLOCK_REALTIME, &t0);
>
> long long ns = (t0.tv_sec * 10) + t0.tv_nsec;
>
> return ns;
>
> }
>
>
>
> int main()  {
>
>   return 0;
>
> }
>
>
>
> Next use this command to create a shared library:
>
> cc -fPIC -shared -o time_ns.so time_ns.c
>
>
>
> Ns.py:
>
>
>
> from ctypes import *
>
> so_file = '~/time_ns.so'
>
> c_time_ns = CDLL(so_file)
>
> c_time_ns.time_ns.restype = c_longlong
>
> return c_time_ns.time_ns()
>
>
>
> Thanks,
>
>
>
> Adam Gorski
>
> Virginia Tech Applied Research Corporation (VT-ARC)
>
> Wireless Communications Systems Engineer
>
> 410-818-3188
>
>
>
>

Re: Modifying Offset Stream Tag

[Nick Foster]

I think you are misunderstanding what the tag offset represents. The
timestamp is coming from datetime.datetime.utcnow() in init(), and the tag
offset added to that is just the offset (samples since the flowgraph
started) of the burst divided by the sample rate. Because the burst offset
is in *samples* and not *seconds*, its resolution is limited to
1/samp_rate. Thus, at 2Msps, the resolution is limited to 500ns. In any
case, Gnuradio knows nothing at all about time -- it only knows about
samples.

To play Clippy for a bit, it sounds like you're trying to do
multilateration on ADS-B signals. The approach being used in gr-adsb will
not work for this. You cannot use the host clock (i.e., datetime) because
its accuracy is nowhere near what is required (if you're using
PTP/IEEE-1588 with a local timeserver you'll be closer, but it will still
be a mess). You need to synchronize the radio to GPS time either using a
built-in GPSDO, or an external one.

If the radio is not synchronized to a GPSDO, then instead of one problem
you will have two: the initial time (since it's CPU time) will be wrong,
and the time offset will drift over time (since the sample rate of the
radio will not be synchronized).

Nick

On Sun, Jun 21, 2020 at 2:56 PM Adam Gorski  wrote:

> Hello community,
>
>
>
> I am currently using an out of tree module (gr-adsb) with GNU Radio 3.7
> that captures received ADSB messages. I would like to change the timestamp
> resolution for each message received from microseconds to nanoseconds. The
> timestamp of each message is declared in the demod.py (attached) by adding
> the start time of the block to the offset stream tag (line 111 in
> demod.py).
>
>
>
> The offset stream tag is not declared within the out of tree module, but
> somewhere in the GNU Radio source code. There are a handful of python files
> within the GNU Radio source code that include the offset tag, however I
> believe the declaration may lie in one of the following files (these have
> essentially the same code):
>
>- ~/gnuradio/gnuradio-runtime/python/gnuradio/gr/packet_utils.py
>- ~/gnuradio/gr-digital/python/digital/utils/tagged_streams.py
>
>
>
> I would like to declare the offset tag with a nanosecond resolution. I
> have been able to accomplish this type of declaration with the demod block
> start time by calling a c function within a shared library, however I’m
> unsure how to do the same within GNU Radio source code as any sort of test
> print statements within the two files listed above never gets displayed in
> the flowgraph output.
>
>
>
> My questions:
>
>- Is one (or both) of the files indicated above the correct file to
>modify?
>- How do I test modifications to GNU Radio source code files?
>- Are there other methods of changing the offset tag resolution I
>should consider?
>
>
>
> The c function and shared library code is as follows. I chose this way due
> to the flowgraph code builder in GNU Radio 3.7 using python2; if I used a
> python3 function I believe I’d have to rewrite the flowgraph code builder
> in python3.
>
>
>
> Time_ns.c:
>
>
>
> #include 
>
> #include 
>
>
>
> long long time_ns() {
>
> struct timespec t0;
>
> clock_gettime(CLOCK_REALTIME, &t0);
>
> long long ns = (t0.tv_sec * 10) + t0.tv_nsec;
>
> return ns;
>
> }
>
>
>
> int main()  {
>
>   return 0;
>
> }
>
>
>
> Next use this command to create a shared library:
>
> cc -fPIC -shared -o time_ns.so time_ns.c
>
>
>
> Ns.py:
>
>
>
> from ctypes import *
>
> so_file = '~/time_ns.so'
>
> c_time_ns = CDLL(so_file)
>
> c_time_ns.time_ns.restype = c_longlong
>
> return c_time_ns.time_ns()
>
>
>
> Thanks,
>
>
>
> Adam Gorski
>
> Virginia Tech Applied Research Corporation (VT-ARC)
>
> Wireless Communications Systems Engineer
>
> 410-818-3188
>
>
>

Re: Best way to set USRP Sink value from separate thread

[Nick Foster]

Just call set_gain() from the thread context of the USRP sink, i.e., the
top_block. Use a semaphore: the thread doing the calling sets a semaphore
in the top_block, and then the top_block runs a loop which looks for that
semaphore to be set and then calls set_gain.

Nick

On Wed, Jun 17, 2020 at 1:04 PM Guy Marino 
wrote:

> Hello,
>
> I'm currently working on a multithreaded application which needs to set
> the gain value of a USRP sink at runtime. The only thing I've found that
> works so far is:
>
> stop() -> wait() -> lock() -> set_gain() -> unlock() -> start()
>
> I tried using just lock/unlock, but this causes the SDR to freeze
> completely. As it is, the current setup causes stability issues and crashes
> after only a few minutes at best. I've heard about sending commands to the
> USRP Sink, though I couldn't find any documentation on the subject and the
> one page I found has been removed (and was never archived). Here's the
> message I keep receiving from the flowgraph:
>
> gr::log :FATAL: tagged_stream_mux0 - Missing a required length tag on port
> 1 at item #100
> thread[thread-per-block[10]: ]: Missing
> length tag.
>
> It seems to happen at random with any tagged block in the flowgraph (the
> point of failure typically changes every time we run it). While we could
> theoretically just catch the error and restart the flowgraph, I would
> rather find a more permanent solution. We're using two Ettus B200 SDRs for
> our current tests.
>
> If anyone has any information on proper dataflow control for blocks or the
> USRP sink message passing API, I'd really appreciate it.
>
> Thanks,
> Guy Marino
>

Re: Correlation Estimator block threshold settings in Absolute/Dynamic mode

[Nick Foster]

The magnitude of the correlation depends on the magnitude of your signal.
The AGC normalizes the signal amplitude before the correlator, so you see
expected behavior. The correlation estimator block expects the input to
have a normalized amplitude.

Nick

On Wed, Apr 1, 2020 at 8:58 AM Fabian Missbrenner <
fabian.missbren...@gmail.com> wrote:

> Hi everyone,
>
> I am currently developing a wireless transceiver and try to get the
> transmission detection running at the receiving end. To help with
> detection and synchronization, a known word is prepended to every
> message. I now want to use the Correlation Estimator block to detect
> the presence of the known word on a noisy, bursty channel. The block
> computes the (magnitude squared of the) correlation of the incoming
> stream of complex baseband samples with the known word:
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/corr_est_cc_impl.cc#L219
>
> Attached you can find the Flowgraph I am using for testing purposes.
>
> With Threshold Method set to Absolute, once the correlation exceeds a
> user-defineable share of the auto-correlation peak of the known word
> (Threshold parameter: between 0 and 1),
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/corr_est_cc_impl.cc#L178
> ,
> the known word is considered detected and a tag is added to the stream.
>
> Unfortunately, the block does not quite behave like expected. The
> threshold needs be set to a value that is off by a factor of 1000 in
> my case:
> cf. PDF attachment, slide 1.
> With a Threshold of 0.8/1000=800u, detection works reliably. But I
> don't understand where this factor of 1000 comes from.
>
> When using an AGC3 block before the Correlation Estimator (yes, I made
> sure to correlate against the normalized known word now), there is no
> correction by factor 1000 necessary anymore:
> cf. PDF attachment, slide 2.
> Here, with a threshold of 0.5, detection works reliably.
>
> With the Dynamic mode, the semantic of the Threshold parameter
> changes: Now it means a probability of false alarm:
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/corr_est_cc_impl.cc#L175
> .
> Unfortunately, regardless of configuring a Threshold close to 0 or
> close to 1, there are many false-positive detections:
> cf. PDF attachment, slides 3 and 4.
>
> I'm not quite sure if I am missing some important point about using
> the block or if the described oddities are bugs. Maybe you can help me
> out? I also saw a discussion about this block in a Github issue
> mentioning its lack of documentation:
> https://github.com/gnuradio/gnuradio/issues/1207#issuecomment-279573149
>
> Best regards
> Fabian Missbrenner
>

Re: Change Variable value from an python block or module?

[Nick Foster]

You know, maybe this is opening up a can of worms, but you *can* do this. A
lot of blocks don't accept messages; messages aren't exactly first-class
(in the sense that every block accepts them) in Gnuradio. All blocks have
getters/setters to change parameters, but only a comparative few have
message slots, even though their functionality usually overlaps.

I'm currently doing this (callbacks) to interface Gpredict to a GRC
flowgraph to provide Doppler correction. A Python block takes a callback to
tb.set_() as a parameter, and sets the Doppler correction
frequency as needed using the rotator block, which does not accept
messages. It's easy, convenient, and didn't require modifying anything. The
process has made me think a bit about messages in GR.

I'm sure anyone who's spent time looking at performance in GR is cringing
right now, but a more generic way of doing this would be for GRC blocks to
register slots (for message sinks) and signals (for message sources).
Within GRC, message slots could be automatically generated for every
callback defined in the .yml. It wouldn't require any changes to any
blocks, which seems like a win to me, rather than changing every block in
GR to add message inputs for all setters.

Nick, waiting for the chorus of "BURN THE WITCH"

On Wed, Mar 25, 2020 at 8:14 AM Steffen Kiel  wrote:

> Hello Marcus,
> alright, i will look into this whole "message" thing instead then.
>
>  thanks for your quick reply.
>
> BR,
> Steffen
>
>
> --
> *Fra:* Müller, Marcus (CEL)
> *Sendt:* Onsdag 25 Marts 2020 16:05
> *Til:* steffenk...@outlook.dk; discuss-gnuradio@gnu.org
> *Emne:* Re: Change Variable value from an python block or module?
>
> Yes, but no!
>
> So, GRC Variables are really a GRC concept, and you'd need to break
> multiple layers of encapsulation from within a Python block just to
> alter them. Really, that's possible with a simple callback function,
> but please don't.
>
> Instead, the appropriate way of dealing with this would be giving the
> signal source a message port, on which it accepts new values via
> message.
>
> Then, from your Python or C++ block, just send a message.
>
> Best regards,
> Marcus
>
> On Wed, 2020-03-25 at 14:57 +, Steffen Kiel wrote:
> > Hello!
> >
> > I have a signal source whose frequency input is referenced to a variable.
> > Is it possible to access this variables value and set it from a python
> block or python module?
> >
> > BR,
> > Steffen
>

Re: GNU Radio 3.8 and Centos 7: Is it possible?

[Nick Foster]

Having been down this road a ways, I can recommend using Docker, if you
value your time and sanity.

$ docker run -ti bistromath/gnuradio:v3.8 bash -l

If you want GRC to work you'll have to do a bit of monkeying. It'll be
different for Centos because everything is, but here's

a starting point.

Nick


On Mon, Jan 20, 2020 at 7:16 PM Andrew J Wolfram 
wrote:

> Hi All,
>
> Has anyone out there been able to install GNU Radio 3.8 on Centos 7? I
> have gotten close compiling from source, but ultimately ran into a
> segmentation fault when running gnuradio-companion.  The gdb output was not
> really helpful. Frame 1 said "Cannot access memory at address 0x170e70>) at
> /usr/include/string.h". I'm guessing something is wonky with the library
> linking due to the piecemeal dependency resolution I had to do. When
> running the cmake command I get a few "Cannot generate a safe runtime
> search path for target because files in some directories may conflict with
> libraries in implicit directories" errors. Perhaps that's related. I've had
> a very difficult time installing dependencies since some of the most recent
> versions are not available via yum. I've had luck using Anaconda (conda),
> but that's contributed to the linking issues since the old version is
> installed somewhere in /usr/ and the newest version is under the Anaconda
> prefix.
>
> I got absolutely nowhere with pybombs.
>
> Is this a doomed endeavor?
>
> Thanks,
> Andrew
>

Re: porting OOT blocks (gr-ais) to gnuradio 3.8

[Nick Foster]

I'll get it ported over Christmas break, if you can wait that long

On Tue, Dec 17, 2019 at 4:59 PM Vasil Velichkov 
wrote:

> Hi Robert,
>
> On 18/12/2019 00.41, Robert Meyer wrote:
> > After that I used pybombs to install gr-ais, and then used  > update -complete> in order to try to convert resources to gnuradio 3.8
>
> This would only convert the GRC blocks from XML to YAML format. You also
> need a lot of cmake related changes.
>
>
> https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#CMake_Updates
>
> > I was able to build without errors, but when running the block I got the
> > error:
> >
> > Traceback (most recent call last):
> >
> > File
> > "/home/superuser/prefix/default/src/gr-ais/build/testing_gr_ais.py",
> line 27
> > in 
> >
> > From ais import gmsk_sync
> >
> > ModuleNotFoundError: No module named 'ais'
>
> Make sure there are no undefined symbols in libgnuradio-ais.so and
> _ais_swig.so
>
> $ ldd  -r ./lib/libgnuradio-ais.so  | grep undefined
> undefined symbol: _ZN2gr6blocks13vector_sink_c4makeEii
> (./lib/libgnuradio-ais.so)
> undefined symbol:
> _ZN2gr6blocks15vector_source_b4makeERKSt6vectorIhSaIhEEbiRKS2_INS_5tag_tESaIS7_EE
> (./lib/libgnuradio-ais.so)
> undefined symbol:
> _ZN2gr6filter14fir_filter_ccf4makeEiRKSt6vectorIfSaIfEE
>  (./lib/libgnuradio-ais.so)
>
> $ c++filt  _ZN2gr6blocks13vector_sink_c4makeEii
> gr::blocks::vector_sink_c::make(int, int)
>
> $ c++filt _ZN2gr6filter14fir_filter_ccf4makeEiRKSt6vectorIfSaIfEE
> gr::filter::fir_filter_ccf::make(int, std::vector std::allocator > const&)
>
> In case you get the same symbols then you need to link with
> gnuradio-blocks and gnuradio-filter using the new cmake syntax. In
> lib/CMakeLists.txt add something like
>
> target_link_libraries(gnuradio-ais gnuradio::gnuradio-blocks
> gnuradio::gnuradio-filter)
>
> Also in python/__init__.py you can add a try except block around the
> import statements and log and reraise any exceptions.
>
> P.S.
> If you manage to port it successfully consider opening a pull request.
>
> Regards,
> Vasil
>
>

Re: Going from GUI to non-GUI operation.

[Nick Foster]

It's a bit wasteful from a CPU cycles standpoint, but you can run your
flowgraph unchanged from the command line using xvfb, and no graphical
output will be displayed.

Nick

On Thu, Nov 14, 2019, 8:53 AM Glen I Langston 
wrote:

> Hi Amr,
>
> Thanks for your suggestion.
>
> However when I select no-gui, then all the QT blocks go RED in my designs
> in gnuradio-companion.
>
> I was hoping that they would instead just go quiet and use the default
> values.
>
> I can, of course, just delete all the QT blocks, but then when going back
> to debugging/improving I’d have to put them back in.
>
> My hope is not yet implemented, it appears.
>
> Best regards,
>
> Glen
>
>
>
> > On Nov 14, 2019, at 9:53 AM, Amr Bekhit  wrote:
> >
> > Hi Glen,
> >
> > In the top right corner of the flow you will see the flow properties
> box. In there you can disable the GUI. You can then run your python file
> directly, or even call the created class object from another file (have a
> look inside the main function to see how the flow is instantiated). You can
> also get and set variable values in runtime via Python and have the flow
> update, just like you can with the GUI.
> >
> > On 14 Nov 2019 Thu at 5:28 PM Glen I Langston 
> wrote:
> > This email is a question concerning the Gnuradio transition from
> > a GUI interface to purely python execution.
> >
> > We’ve developed a series of gnuradio-companion compatible designs
> > that are "just about" perfected from our point of view.   Now we’re going
> > from interactive mode to fully automatic startup and execution from
> > computer reboot.
> >
> > Our designs now immediately start capturing radio astronomy spectra
> > and transient events.
> >
> > Is there a simple mechanism to turn off and on the GUI interface?  Maybe
> > just in the control block?
> >
> > Sorry if this is an obvious question.
> >
> > Thanks - Glen
> >
> >
>
>
>

Re: [Discuss-gnuradio] Compiling QT C++ programs with GNU Radio

[Nick Foster]

Maybe I'm just confused, then. You weren't clear about the problem you're
experiencing, or what you've tried to resolve it. It sounded in your
initial email like you just don't know how to build a CMake project (using
"g++", for instance, is not how that works). Further leading me to think
this was that you apparently are doing this compilation in-tree, in
gr-qtgui/examples, which isn't a good place for user projects.

The CMakeLists.txt you attached appears to be designed for in-tree
compilation. This means your project would always have to be compiled along
with your own custom branch of Gnuradio, which I'm almost positive is not
what you actually want to do. The out-of-tree module template includes all
of the CMake commands necessary to compile and link your own project
outside the Gnuradio source tree. It should serve as a much better starting
point for your project than the CMakeLists.txt that you attached, which
lacks the necessary find_package calls to properly find and link to
Gnuradio (and any other libraries you might use). You'll want to take a
look at the toplevel CMakeLists.txt in the out-of-tree template as well as
the one in lib/, which you'll want to modify to produce an executable
instead of a library for your project.

You could also look at the CMake files from other standalone Gnuradio
applications for inspiration, such as gqrx.

Nick

On Tue, Oct 8, 2019 at 12:55 PM Moses Browne Mwakyanjala 
wrote:

> Hello Nick,
> As I have mentioned in my previous email, I know how to use CMake as I
> have already made a lot of OOTs before. Please understand that I'm not
> trying to build an OOT. In the program, a top_block_sptr object (think of
> it as a C++ based flowgraph) object is initialized with signal generators
> and qt graphics. The Qt event loop initializes the flowgraph (an object
> called 'mywindow'), makes signal/slot connections and runs it. You can also
> have a look at the CMakeList.txt file I attached. It doesn't look like the
> traditional OOT makefiles.
>
> Regards,
>
> Moses.
>
>
> On Tue, Oct 8, 2019 at 9:21 PM Nick Foster  wrote:
>
>> Within the "out of tree module" link I sent is basic information on how
>> to compile an application using CMake.
>>
>> https://wiki.gnuradio.org/index.php/OutOfTreeModules#Using_CMake
>>
>>
>> On Tue, Oct 8, 2019 at 12:05 PM Moses Browne Mwakyanjala <
>> mbkit...@gmail.com> wrote:
>>
>>> Hello Nick,
>>> Thanks for your email.
>>> I have created the OOTs already. What I'm trying to do it to integrate
>>> my OOTs in a QT C++ application (something akin to Gqrx).
>>> You could see what I'm trying to do from the example source code I
>>> attached.
>>>
>>> Regards,
>>> Moses.
>>>
>>> On Tue, Oct 8, 2019 at 8:56 PM Nick Foster  wrote:
>>>
>>>> I think you should read up on creating out-of-tree GNURadio modules:
>>>>
>>>> https://wiki.gnuradio.org/index.php/OutOfTreeModules
>>>>
>>>> Nick
>>>>
>>>> On Tue, Oct 8, 2019 at 11:44 AM Moses Browne Mwakyanjala <
>>>> mbkit...@gmail.com> wrote:
>>>>
>>>>> Hello all,
>>>>> I'm trying to implement an easy-to-use QT-based receiver in GNU Radio.
>>>>> As a starting point, I would like to compile a C++ example (attached) 
>>>>> under
>>>>> /gnuradio/gr-qtgui/examples/c++ . This example program generates a noisy
>>>>> sine wave and displays on some qt gui qwidgets. I was able to compile and
>>>>> run the program a couple of years ago. Unfortunately, I can't remember 
>>>>> what
>>>>> I did as the whole process was trial and error. I have tried both "make"
>>>>> and "g++" without any luck. Please don't hesitate to ask for
>>>>> more information.
>>>>> All help is highly appreciated.
>>>>> Best regards,
>>>>> Moses.
>>>>> ___
>>>>> 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] Compiling QT C++ programs with GNU Radio

[Nick Foster]

Within the "out of tree module" link I sent is basic information on how to
compile an application using CMake.

https://wiki.gnuradio.org/index.php/OutOfTreeModules#Using_CMake


On Tue, Oct 8, 2019 at 12:05 PM Moses Browne Mwakyanjala 
wrote:

> Hello Nick,
> Thanks for your email.
> I have created the OOTs already. What I'm trying to do it to integrate my
> OOTs in a QT C++ application (something akin to Gqrx).
> You could see what I'm trying to do from the example source code I
> attached.
>
> Regards,
> Moses.
>
> On Tue, Oct 8, 2019 at 8:56 PM Nick Foster  wrote:
>
>> I think you should read up on creating out-of-tree GNURadio modules:
>>
>> https://wiki.gnuradio.org/index.php/OutOfTreeModules
>>
>> Nick
>>
>> On Tue, Oct 8, 2019 at 11:44 AM Moses Browne Mwakyanjala <
>> mbkit...@gmail.com> wrote:
>>
>>> Hello all,
>>> I'm trying to implement an easy-to-use QT-based receiver in GNU Radio.
>>> As a starting point, I would like to compile a C++ example (attached) under
>>> /gnuradio/gr-qtgui/examples/c++ . This example program generates a noisy
>>> sine wave and displays on some qt gui qwidgets. I was able to compile and
>>> run the program a couple of years ago. Unfortunately, I can't remember what
>>> I did as the whole process was trial and error. I have tried both "make"
>>> and "g++" without any luck. Please don't hesitate to ask for
>>> more information.
>>> All help is highly appreciated.
>>> Best regards,
>>> Moses.
>>> ___
>>> 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] Compiling QT C++ programs with GNU Radio

[Nick Foster]

I think you should read up on creating out-of-tree GNURadio modules:

https://wiki.gnuradio.org/index.php/OutOfTreeModules

Nick

On Tue, Oct 8, 2019 at 11:44 AM Moses Browne Mwakyanjala 
wrote:

> Hello all,
> I'm trying to implement an easy-to-use QT-based receiver in GNU Radio. As
> a starting point, I would like to compile a C++ example (attached) under
> /gnuradio/gr-qtgui/examples/c++ . This example program generates a noisy
> sine wave and displays on some qt gui qwidgets. I was able to compile and
> run the program a couple of years ago. Unfortunately, I can't remember what
> I did as the whole process was trial and error. I have tried both "make"
> and "g++" without any luck. Please don't hesitate to ask for
> more information.
> All help is highly appreciated.
> Best regards,
> Moses.
> ___
> 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] [RFC] PMT succession: experts' opinions on serialization libs

[Nick Foster]

I think it's wise to avoid hitching our metaphorical horse to any software
project we can't absolutely depend on; questionable dependency choices have
bit us, as you mention, many times.

With that (somewhat) in mind, what about Flatbuffers
 as an alternative to Cap'n Proto?
Seems much more actively maintained, more widely used, and designed with
the same goals in mind. No parsing step required, so performance is good.
Memory use seems to be similarly efficient.

Now, I haven't actually used Flatbuffers before, so anyone who has
experience with them (or your other favorite serialization library!),
please chime in here.

Nick

On Sat, Sep 28, 2019 at 2:02 PM Marcus Müller  wrote:

> To avoid the setting in of post-Conference downs:
>
> Dearest SDR Community with the Highest count of "Awesome" in the
> Universe,
>
> discussions at GRCon have made it abundantly clear that PMT needs to be
> replaced¹.
> Main issues with PMT are:
>
> * broken type system,
> * low suitability as tool for internal packeted data,
> * lack of interoperability with anything but the languages we support
> natively,
> * platform-dependency of the serialization format,
> * bugs.
>
> (to a far lesser degree: performance.)
>
> Having talked to multiple domain experts in networked systems and
> heterogenous cooperative platforms, I've come to the conclusion,
> furthermore, that in the interest of RPC'ing everything², the structure
> of messages exchanged between blocks should be predefined.
>
> In this sense, PMT's (limited) ability do describe itself is of no help
> – instead, it introduces ambiguity.
>
> The dominant choice for binary serialization with known schemata is
> Proto Buffers; however, they require deserialization of a whole message
> if there's substructures before the field you want to access³.
>
> Cap'n Proto[1] (by one of the original authors of protobufs) seems to
> be a suitable alternative, and comparing it to its competitors, it
> seems to have achieved a significant level of maturity and has at least
> one large-scale adopter⁴.
>
> Among its advantages seems to be that operations on the message happen
> in-place (i.e. there's actually a compatible C++ struct representation
> of the memory layout), which rendered it my favourite library for this
> job.
>
> Now, problem: I've never personally worked with Cap'n Proto, or
> protobuf, or any modern, non-self-describing serialization library;
> I've got minimal experience with MessagePack, but as said, that's not
> probably going to make it due to lack of schema.
>
> So, here I am, calling for your experience! Hurl ins(igh|ul)ts at me,
> preferable here on this list.
>
> Best regards,
> Marcus
>
>
> [1] https://capnproto.org/index.html
>
> ¹This doesn't come as a surprise – it's just a good point in time to
> point this out.
> ²You've probably noticed that we're working towards a less machine-
> dependent, more portable, distributable computational model
> ³This can become problematic for messages with large data blobs in
> between, or very complex protocol headers
> ⁴CloudFlare seems to be using Cap'n Proto for Web workers, for example.
> However, it's but at revision 0.7, which indeed implies a bit of
> headache – other tools that never reached 1.0 that we rely on include
> Thrift, and that's really not a club that you'd want to be in.
>
>
> ___
> 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] Eventstream source latency

[Nick Foster]

I think you'll find that the merging is the problem. Gnuradio hangs onto
rather large buffers, as does UHD, and in your case the buffer for the
continuous stream will set the latency of the system rather than the
eventstream PDU.

Try removing the constant stream and see if that changes the behavior
you're seeing.

Nick

On Sat, Aug 17, 2019 at 3:27 PM Jacob Gilbert 
wrote:

> Hi Daniel
>
> You might be interested in the gr-pdu_utils and gr-timing_utils modules.
> They are about to get a significant update but there is a decent writeup on
> the concept of operations in github.
>
> Sub-ms latency is possible depending on host hardware and system
> configuration.
>
> Jacob
>
>
>
> On Fri, Aug 16, 2019, 10:08 Lundberg, Daniel via Discuss-gnuradio <
> discuss-gnuradio@gnu.org> wrote:
>
>> I have a flowgraph with a simple FDMA implementation with two channels.
>> One channel has a constant stream.  The other channel has complex sample
>> bursts generated in a custom python function, which I package as a PDU.  I
>> apply the frequency modulation within the python file to place it in the
>> correct frequency channel.  I send the PDU to an eventstream source and
>> then add the two channels in an add block before sending the merged signal
>> to a USRP sink.  I am seeing latencies of over a second from the PDU
>> generation to when the eventstream source sends them on.  My sample rate is
>> ~5 Ms/s and my PDU is about 1.25 MS, so about a quarter of a second.  My
>> eventstream source block is using ASAP event placement and MEMCPY settings.
>>
>> Is this level of latency expected?  I do not fully understand the merge
>> behavior of the eventstream source, but I would expect perhaps 2X the PDU
>> size of latency if it has a PDU length number of zeros in it's buffer
>> before inserting the PDU.
>>
>> Thank you,
>> DL
>> ___
>> 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] USRP GNU radio receiver

[Nick Foster]

The USRP has a DC offset removal filter in the FPGA. A carrier sent at 0Hz
is exactly the same as DC offset, and will be removed. Zero-IF receiver
architectures (like the USRP) intrinsically have DC offset imperfections.
The filter can be disabled in the USRP Source "FE Options" tab. It is not
good practice to design a system which depends on DC in a zero-IF receiver,
because the DC offset error will change over frequency, temperature, time,
etc.

On Thu, Jul 18, 2019 at 4:29 AM Simona Sibio  wrote:

> Hi all,
>
> Thank you very much for your emails.
> But no tip works fine.
> I wanted only to learn how is USRP working with GNU radio, I thought that
> the RX chain in the USRP was different.
> But I am not the beginner in electronic and RF circuits.
> Anyway, no problem, I don't ask more information about this.
> Best Regards,
>
> Simona
>
> Il giorno gio 18 lug 2019 alle ore 12:11 Jonas Manthey <
> jonas.mant...@u-blox.com> ha scritto:
>
>> Hi,
>>
>>
>>
>> You don’t send a sine with  frequency 0, you send a carrier that is
>> modulated by a sine with a frequency of 0. A sine with a frequency of 0 is
>> 0: sin(2 pi f) = sin(2 pi 0) = sin(0) = 0.
>>
>>
>>
>> So your carrier is modulated with a zero, which I **think** ends up in
>> no carrier at all, not sure right now how zero-IF architectures behave in
>> that case. I highly recommend reading some communications or RF
>> book/website/guide or talk with your advisor.
>>
>>
>>
>> UHD-USRP clips anything above 1 if left in the default setting (float I
>> guess) and there will be a lot of garbage in the sent spectrum.
>>
>>
>>
>> Cheers,
>>
>> Jonas
>>
>>
>>
>> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+jonas.manthey=
>> u-blox@gnu.org] *On Behalf Of *Simona Sibio
>> *Sent:* Donnerstag, 18. Juli 2019 13:01
>> *To:* Kyeong Su Shin 
>> *Cc:* discuss-gnuradio@gnu.org
>> *Subject:* Re: [Discuss-gnuradio] USRP GNU radio receiver
>>
>>
>>
>> Hi Kyeong,
>>
>>
>>
>> I attached the screenshots about time-domain and frequency domain.
>>
>> I sent a sine with frequency=0 and amplitude=0,25.
>>
>> The output is always zero in the receiver.
>>
>> The situation changes only if I send a sine with a frequency non-zero.
>>
>> Thank you for your time.
>>
>> Best Regards,
>>
>>
>>
>> Simona
>>
>>
>>
>> Il giorno mer 17 lug 2019 alle ore 17:41 Kyeong Su Shin <
>> kss...@postech.ac.kr> ha scritto:
>>
>> To whom it may concern:
>>
>>
>>
>> I think there has been some miscommunications or misunderstandings here:
>> the 'Offset' argument for the 'Signal Source' block is for the 'amplitude
>> offset' of the signal, while what Marcus probably meant in his previous
>> e-mail is the 'frequency offset' (you can use USRP's low-freq digital IF
>> capabilities for that). Also, I do not know how UHD sink behaves when you
>> do not input normalized values, but I am pretty sure that you should not
>> input such large values to UHD sink.
>>
>>
>>
>> If readings in the frequency-domain are non-zero (or, in real-world
>> devices, extremely low values), readings in the time-domains are also
>> non-zero. So, "the output became unstable in frequency and in time is
>> always zero" doesn't make sense. Your time-domain plot is probably zoomed
>> out too much.
>>
>>
>>
>> Finally, as Marcus mentioned, throttle blocks _must_ be removed.
>>
>>
>>
>> Regards,
>>
>> Kyeong Su Shin
>>
>>
>> --
>>
>> *보낸* *사람**:* Simona Sibio  대신 Discuss-gnuradio
>> 
>> *보낸* *날짜**:* 2019년 7월 17일 수요일 오후 11:35:00
>> *받는* *사람**:* Müller, Marcus (CEL)
>> *참조**:* discuss-gnuradio@gnu.org
>> *제목**:* Re: [Discuss-gnuradio] USRP GNU radio receiver
>>
>>
>>
>> Thank you very much!
>>
>> I sent the screenshot because in the oscilloscope there is not the
>> offset.
>>
>> Instead, I would like to detect that.
>>
>> Thank you in advance.
>>
>>
>>
>> Simona
>>
>>
>>
>> Il giorno mer 17 lug 2019 alle ore 15:22 Müller, Marcus (CEL) <
>> muel...@kit.edu> ha scritto:
>>
>> 1. Never use a throttle with a hardware block. GRC's log will actually
>> shout at you that you shouldn't be doing that!
>> 2. I must admit this is about as good as I'd expect. I of course can't
>> infer temporal behaviour from screenshots.
>>
>> Best regards,
>> Marcus
>>
>> On Wed, 2019-07-17 at 14:18 +0100, Simona Sibio wrote:
>> > Hi Marcus,
>> >
>> > I tried to change the offset in the transmitter but the output in the
>> receiver is the same, also if I send a sine signal with 10 Hz and 0,1
>> amplitude: the output became unstable in frequency and in time is always
>> zero (see attached, 130K).
>> > The flow graph is attached.
>> > Do you have any suggestions?
>> > Thank you in advance.
>> >
>> > Simona
>> >
>> > Il giorno mar 16 lug 2019 alle ore 18:59 Müller, Marcus (CEL) <
>> muel...@kit.edu> ha scritto:
>> > > That phase is not any more or less random than that of your local
>> > > oscillator, so there might be some misunderstanding here.
>> > > On Tue, 2019-07-16 at 18:52 +0100, Simona Sibio wrote:
>> > > > Thank you ver

Re: [Discuss-gnuradio] Two instances of the same custom block walk into a bar

[Nick Foster]

It looks like you've declared a bunch of static variables within your
block's namespace. Those variables (including pointers!) will be shared
with every instance of your block. This is Bad News. Those variables should
probably all be declared in the header as class member variables.

On Thu, May 9, 2019 at 11:43 AM Brad Hein  wrote:

> I'm running into a strange issue with a new flow graph [1] I'm working on
> that uses a custom C++ block [2] that I built. The block takes input
> samples, performs some DSP, and outputs modified samples at the same sample
> rate.
>
> When the flowgraph has a single instance of my custom block enabled, it
> works fine. But when I enable a second instance of the block in a separate
> second usage, (think stereo sound, one per sink channel) it acts very
> unexpectedly - output samples are wildly inaccurate and distorted.
>
> My perception is that the two instances of the same block seem to be
> sharing some part of their memory namespace and as they modify/store
> variables they are doing so in some sort of shared namespace or memory
> segment.
>
> Is it possible for two blocks to corrupt each other's memory? I can't
> think of any other explanation for the two streams working fine
> individually, but when both are enabled at the same time the output is
> garbled. I've tried all sorts of things like tying them to the same source
> block, removing the upsampling/downsampling, adding a delay to one, etc.
> with no luck.
>
>
> [1] "Flowgraph with two parallel streams both using the custom block
> pq_rails":
> https://github.com/regulatre/gr-powerquality/blob/master/examples/streamer.grc
>
> [2] "pq_rails (Custom block) source code":
> https://github.com/regulatre/gr-powerquality/blob/master/lib/pq_rails_impl.cc
>
> ___
> 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 Block to Output Items that Meet Criteria

[Nick Foster]

Sure, no problem, use a gr::block. Just call consume() to tell the
scheduler how many items you consumed, and return the number of samples you
produced -- subject to the size of the output buffer. general_work() gets
the size of your input and output buffers from ninput_items and
noutput_items. Perfectly fine to return a smaller value than requested.

Nick

On Wed, Mar 6, 2019 at 5:43 PM Mark Gannet  wrote:

> Is it possible to write a custom block that only copies items to the
> output buffer if they meet a certain criterion?  I'm thinking of something
> like a "keep m of n" block but where there is no knowledge of the number of
> items that will be written to the output buffer when entering the work
> function.
>
> Thanks,
> Mark
> ___
> 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] [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

[Nick Foster]

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 <
>> usrp-us...@lists.ettus.com> 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 SR_READBACK_REG_FIFOSIZE to bytes
>>> * Utils: Add Zip test to downloader
>>> * Utils: Factor wait_for_lo_lock() out of cal utils
>>> * DPDK: Add DPDK-based sockets-like library
>>> * MPMD: add option to enum rfnoc blocks from args
>>> * E320: Get RFNoC crossbar baseport from FPGA
>>> * N3xx: Get RFNoC crossbar baseport from FPGA
>>> * UHD: add default xport params to udp_zer

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

[Nick Foster]

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 <
usrp-us...@lists.ettus.com> 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 SR_READBACK_REG_FIFOSIZE to bytes
> * Utils: Add Zip test to downloader
> * Utils: Factor wait_for_lo_lock() out of cal utils
> * DPDK: Add DPDK-based sockets-like library
> * MPMD: add option to enum rfnoc blocks from args
> * E320: Get RFNoC crossbar baseport from FPGA
> * N3xx: Get RFNoC crossbar baseport from FPGA
> * UHD: add default xport params to udp_zero_copy
> * MPM: add link_speed xport_info
> * MPMD: add link speed to xport udp
> * Device3: remove tx_hint[send_buff_size]
> * X300: remove default_buff_args properties
> * RFNoC: Add ability to enable/disable RX timestamp
> * RFNoC: add async message handler
> * Examples: add rfnoc_radio_loopback example
> * UHD: Update rx_frontend_gen3.v controls for 1/4-rate mixer
> * UHD API: Move definition of ALL_MBOARDS and ALL_CHANS constants to
>CPP file.
> * MPM: Add __mpm_device__ as usrp_hwd module variable
> * MPM: Add usrp_update_fs
> * UHD: Add traffic counter to null source sink
> * Examples: Add benchmark_streamer example
> * Tools: Add tool to analyze settling time of gain and freq changes
> * UHD API: Add multi_usrp::set_sync_source() API
> * UHD: Improve documentation for the UHD exception types
> * Examples: Add dual measurements to benchmark_streamer
> * MPM: Add i2c APIs for simple transfers
> * MPM: Add vector-based transfer function for i2c
> * UHD: Improve documentation for set_{time,clock,sync}_source
> * CMake: Bump CMake minimum version to 2.8.12
> * MPM: Add variable configuration support to nijesdcore
> * MPM: Add eyescan utility to nijesdcore
> * MPM: Add PRBS-31 testing to nijesdcore
> * CMake: Change SOVERSION and VERSION for the library files
> * Test: Add graph impl test to device3_test
> * RFNoC: Changes 

Re: [Discuss-gnuradio] Using DDC/DUC in N210 with LFTX/LFRX

[Nick Foster]

Just set the center frequency in the UHD sink/source. UHD will handle the
tuning.

On Thu, Oct 18, 2018 at 5:52 PM Wheberth Damascena Dias 
wrote:

> Hi all,
> I have to generate a narowband signal around 13.57MHz using LFTX/LFRX
> frontend (no LO), but don't want to use a high samplerate due to CPU
> constraints.
> I suppose the Interpolator + DUC/DDC on the FPGA can translate the narrow
> baseband to this center frequency, but I don't know to set the parameters
> to use it in the sink block in gnuradio.
> I don't have the hardware yet so I cant use the "cut and try" method.  Can
> someone just point me the right direction?
>
> Best Regards
>
> --
>
> *Wheberth Damascena Dias*
> linkedin.com/in/wheberth
> whebe...@gmail.com
> ___
> 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] Hello GNURadio from the Amateur Radio World

[Nick Foster]

Will,

Do you have a specific problem we can try to help you with? "Not pleasant"
gives us very little to chew on.

Nick

On Sat, May 26, 2018, 9:20 PM Will Gilliam  wrote:

> Hello Peoples, I just signed up for the discuss list, so I thought I would
> introduce myself
>
> My name is Will Gilliam and I am a FCC licensed General amateur radio
> operator. (Ki7OXA)
>
> My first draw into GNURadio was the possibility of operating a high
> frequency 5W radio
> built from a Raspberry Pi 3, an Soundcard SDR radio. I love the idea of
> embedded computing, SDR radios and GNURadio. Its small, its portable, and
> because it involves a computer, the radio can be anything, even a modem.
> Add amateur radio license, even the Element 2 technicians, your still
> having fun VHF and up...
>
> Doing anything on a large computer is easy. Got more work? throw more cpu
> time on the task, but anyone that tinkers within the Embedded world, you
> know you really can't do that to a large degree.
>
> My experience with GNURadio is so far self taught and not pleasant. I am
> uncertain if my poor experiences are from lack of experience, not enough
> computer power, or a mix of both.
>
> Is there anyone that is using raspberry pi's and GNURadio on any sort of
> realtime projects? Is there a better board to use or one that GNURadio is
> going to try to support?
>
>
> Look forward to learning and chatting with you all
>
>
> Will Gilliam
> ___
> 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] Underflow and Overflow

[Nick Foster]

For starters, you almost certainly cannot write to your hard drive at
15Msps. You might not even be able to reliably read that fast without
underruns.

Reduce the sample rate until things start working. Disable or simplify
parts of your flowgraph to see what's causing your problems. Isolate each
problem and understand it before moving on. Start simple and validate each
part instead of building something complex to start with.

Nick

On Wed, May 23, 2018, 8:02 AM Yeo Jin Kuang Alvin (IA) 
wrote:

> Hi all,
>
>
>
> Btw in this flowgraph, I’ve noticed there is nothing transmitting out when
> I change the file source from repeat to no repeat. Originally, I thought
> the waveform stored in file sink is immediately transmitted out from file
> source and continue the process till I stop the flowgraph.
>
>
>
> When I on the repeat, signal starts transmitting out. Why is this so?
>
>
>
> Thank you in advanced!
>
>
>
> *From:* Kevin McQuiggin [mailto:mcqui...@me.com]
> *Sent:* Wednesday, 23 May 2018 11:35 AM
>
>
> *To:* Yeo Jin Kuang Alvin (IA)
> *Cc:* discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Underflow and Overflow
>
>
>
> Hi Alvin:
>
>
>
>
>
>
>
> On May 22, 2018, at 6:38 PM, Yeo Jin Kuang Alvin (IA) 
> wrote:
>
> I want to do a transceiver, so instead of receiving a signal elsewhere out
> of the board. I self-generate out a chirp signal internally in USRP B210
> and do a loopback to the receive port and then re-transmit out using
> another transmit port.
>
>
>
> You will have to be very careful with this.  Looping back the USRP output
> port back to the input port can blow the front end of the USRP receiver.
> Make sure that you use an external attenuator, not just a loopback cable.
> I would start with 30 dB.
>
>
>
> Please tell the group more about your “transceiver": this is a broad
> statement, what are you trying to achieve?   There are several different
> types of transceivers and the implementation will depend upon the
> application you have in mind.
>
>
>
> Kevin
>
>
>
>
>
>
>
> Thank you in advanced!
>
>
>
> *From:* Kevin McQuiggin [mailto:mcqui...@me.com ]
> *Sent:* Wednesday, 23 May 2018 9:03 AM
> *To:* Yeo Jin Kuang Alvin (IA)
> *Cc:* discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Underflow and Overflow
>
>
>
> Hi Alvin:
>
>
>
> Well, for one thing, you are trying to write USRP output samples to a file
> at 30 MB per second.  That is likely to generate overflows.
>
>
>
> Your flowgraph indicates to me that you haven’t fully internalized how
> gnuradio works and how it interacts with whatever front-end hardware you
> are using.
>
>
>
> Don’t take this comment as overly critical, we all (myself included)
> started with only basic understanding, and had to build our skills from
> there.
>
>
>
> I suggest going to the gnuradio web site and following, as a start, the
> set of tutorials that have already been recommended by others on the list.
> They will help you as you start to climb the learning curve!
>
>
>
> Kevin
>
> Sent from my iPhone
>
>
> On May 22, 2018, at 17:48, Yeo Jin Kuang Alvin (IA) 
> wrote:
>
> Does anyone know this?
>
>
>
> *From:* Discuss-gnuradio [
> mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org
> ] *On Behalf Of *Yeo
> Jin Kuang Alvin (IA)
> *Sent:* Tuesday, 22 May 2018 5:42 PM
> *To:* discuss-gnuradio@gnu.org
> *Subject:* [Discuss-gnuradio] Underflow and Overflow
>
>
>
> Hi all,
>
>
>
> May I know what causes my flowgraph to have so many U’s and O’s, is there
> any block that causes this? I am trying to hit a higher sampling rate
> possibly 20 MHz or higher. I have searched online and some suggest switching
>  to a different OS and I did switch from windows to Ubuntu, only a slight
> difference. Some say is the computer’s processing speed not fast enough,
> thus, changing a better one will help. Others did mentioned that the
> flowgraph connection might cause this problem.
>
>
>
> I am getting “OOOUOO” when transmit a sine wave sampling at 20 MHz and
> receive to a file sink.
>
>
>
> I am using USRP B210, running on a Intel Core i7-4700MQ CPU @ 2.40 GHz x
> 8, 64 bit computer.
>
>
>
> Any help would be appreciated!
>
>
>
> 
>
> ___
> 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] Ettus E310 sample rate

[Nick Foster]

Oh, in addition -- there's a single "radio clock" which is picked based on
the transmit and receive sample rates. This means that, while you have
nearly infinite flexibility as to the sample rate used for just RX or just
TX, when you are using both simultaneously their rates will be tied to each
other as divisors of the common radio clock rate. You can see this clock
rate printed as "master clock rate" when UHD initializes your flowgraph.

Nick

On Fri, May 11, 2018 at 11:46 AM Nick Foster  wrote:

> 8MS/s is about what you can stream *through the host processor* on E310.
> Full-rate streaming is supported just fine through the FPGA fabric. If you
> need to do faster rate streaming on the E310, you need to do the processing
> in the FPGA.
>
> Nick
>
>
> On Fri, May 11, 2018 at 11:39 AM Laura Huddleston <
> laura.huddles...@ierustech.com> wrote:
>
>> Happy Friday,
>>
>>
>>
>> What is the max sample rate for the Ettus e310?
>>
>>
>>
>> When I ssh in and perform the benchmark_test, I get the following:
>>
>>
>>
>> $/usr/lib/uhd/examples/benchmark_rate --rx_rate 12e6 --tx_rate 12e6
>>
>> .
>>
>>  . [other stuff here]
>>
>>.
>>
>> UHD Warning:
>>
>> The hardware does not support the requested TX sample rate:
>>
>> Target sample rate: 12.00 MSps
>>
>> Actual sample rate: 8.00 MSps
>>
>> Testing transmit rate 8.00 Msps on 1 channels
>>
>>
>>
>> When I set the target sample rate to 16MS/s, I get OO.
>>
>>
>>
>> Does this mean that 8MS/s is the highest sample rate which the e310 will
>> work?
>>
>>
>>
>> The data sheet says the max ADC/DAC sample rate is 61.44MS/s, so
>> shouldn’t I be able to stream data at a divisible of this?
>>
>>
>>
>> ~
>>
>> Laura Huddleston
>>
>>
>>
>>
>> ___
>> 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] Ettus E310 sample rate

[Nick Foster]

8MS/s is about what you can stream *through the host processor* on E310.
Full-rate streaming is supported just fine through the FPGA fabric. If you
need to do faster rate streaming on the E310, you need to do the processing
in the FPGA.

Nick


On Fri, May 11, 2018 at 11:39 AM Laura Huddleston <
laura.huddles...@ierustech.com> wrote:

> Happy Friday,
>
>
>
> What is the max sample rate for the Ettus e310?
>
>
>
> When I ssh in and perform the benchmark_test, I get the following:
>
>
>
> $/usr/lib/uhd/examples/benchmark_rate --rx_rate 12e6 --tx_rate 12e6
>
> .
>
>  . [other stuff here]
>
>.
>
> UHD Warning:
>
> The hardware does not support the requested TX sample rate:
>
> Target sample rate: 12.00 MSps
>
> Actual sample rate: 8.00 MSps
>
> Testing transmit rate 8.00 Msps on 1 channels
>
>
>
> When I set the target sample rate to 16MS/s, I get OO.
>
>
>
> Does this mean that 8MS/s is the highest sample rate which the e310 will
> work?
>
>
>
> The data sheet says the max ADC/DAC sample rate is 61.44MS/s, so shouldn’t
> I be able to stream data at a divisible of this?
>
>
>
> ~
>
> Laura Huddleston
>
>
>
>
> ___
> 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] How do I interface my X310 with an NVIDIA K80 GPU in GNURadio

[Nick Foster]

Just to provide further clarification:

If you are recording to disk, your bottleneck is *not* the CPU, nor the
GPU, nor the RAM bandwidth. Your bottleneck is the disk. The K80 is a very
nice GPU, but CUDA will not help in your application.

Your flowgraph (pasted above) is doing effectively no processing at all.
It's simply receiving samples from the X310, converting them from fixed to
floating point, and writing them to disk.

20Msps of bandwidth with 8-bit complex samples works out to 40MB/s write
speed. With 16-bit complex samples, 80MB/s. Start spec'ing SSDs that will
handle the required write rate continuously, or content yourself with
writing shorter bursts to a tmpfs partition.

You'll find GPU processing will start to help when you have a block that
has a very high ratio of required cycles to sample rate. Otherwise, as
mentioned above, you'll spend more time copying data into and out of the
GPU than the GPU will spend processing it. Good candidates for GPU blocks
are low-rate block codes, extremely long filters, or channelizers.

Nick

On Wed, May 2, 2018 at 8:56 AM Michael Piscopo 
wrote:

> Hi LJ,
>
> Adding to John's recommendations if you have your heart set on the GPU,
> check out https://github.com/ghostop14/gr-clenabled.  It's an OOT module
> focused on GPU acceleration of many of the core GNURadio blocks.  But as
> John mentioned every memcpy to/from the GPU pays a performance hit which in
> some cases makes the CPU versions run faster.  Anything with trig or log
> functions tend to run faster on the GPU, basic math tends to be faster on
> the CPU (it finishes calculations before the first memcpy to the GPU even
> finishes).  There's a full performance study doc in the docs directory for
> gr-clenabled that'll help you see which ones may be beneficial and I highly
> recommend reviewing before dropping on GPU blocks on a flowgraph.  At
> really high speeds the CPU does get to be a bottleneck so if there's any
> way to reduce the data rates in the FPGA (RFNoC or custom) prior to hitting
> the CPU like initial decimating filters that might help your performance
> too.
>
> Mike
>
>
> On Wed, May 2, 2018 at 10:56 AM, John Ferguson 
> wrote:
>
>> Hi LJ,
>>
>> If you are trying to record data at very high rates, you GNURadio
>> Companion may not be able to go as high as you want. Maybe your laptop has
>> a fast SSD and your server has spinning disks? If you are wanting to test
>> the limits of recording data with GNURadio to see if it works for your
>> proprietary data rate, I would advise as follows:
>>
>> 1. Enable real-time scheduling and select "No GUI" in the Options block.
>> See the transport notes on the E310 for how to get this to work by editing
>> /etc/security/security.conf
>> 2. Assign each block to a specific processor (Core Affinity) in the
>> Advanced Tab and also increase the buffer size
>> 3. Make sure you have a disk/array that can handle the rate you are
>> trying to achieve.
>> 4. You may need to adjust the dirty background radio in the kernel. you
>> do that by editing /etc/sysctl.conf. This is tricky, so you should read up
>> on how this works.
>>
>> I've attached a shell script that you can use to modify add real time
>> scheduling and adjust the kernel parameters. USE AT YOUR OWN RISK AS
>> MODIFYING KERNEL PARAMETERS CAN BE TRICKY AND HURT YOUR SYSTEM.
>>
>> As mentioned above, to test the bottleneck, try sending the data to a
>> null sink. If it works there, then the issue is that your drive isn't fast
>> enough can keep up.
>>
>> You are correct that you are not using the GPU. GNU radio does not
>> natively support GPU processing. We have had success wrapping pycuda into
>> an OOT modules, and getting good performance. There are better ways, but
>> that would be easiest to get started. Your GPU will require extra memory
>> copies:
>>
>> GNU Radio CPU > CUDA CPU > CUDA GPU > CUDA CPU > GNU Radio CPU
>>
>> So depending on what kind of latency you can handle, this may or may not
>> work for you. I'm assuming that the GPU question is not directly related to
>> the recording question.
>>
>> I hope that helped.
>>
>> John
>>
>>
>>
>> On Wed, May 2, 2018 at 10:32 AM, Eads, LJ D.  wrote:
>>
>>> Derek,
>>>
>>>
>>>
>>> Oops! The error was actually from just a simple WBFM Receiver block
>>> which has the audio sink. No soundcard involved in my setup.
>>>
>>> I still don’t think I will be utilizing the GPU though because GNURadio
>>> isn’t showing up in the GPU processes.. Will I be at least utilizing the
>>> CPU? I will test the block diagrams I sent you on the server (I just have
>>> tested them on my laptop initially) and I will get back to you.
>>>
>>>
>>>
>>> Thank you,
>>>
>>>
>>>
>>> LJ Eads
>>>
>>>
>>>
>>> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
>>> *Sent:* Wednesday, May 2, 2018 10:20 AM
>>> *To:* Eads, LJ D. 
>>> *Cc:* Müller, Marcus (CEL) ; discuss-gnuradio@gnu.org
>>>
>>> *Subject:* Re: [Discuss-gnuradio] How do I interface my X310 with an
>>> NVIDIA K80 GPU

Re: [Discuss-gnuradio] Radiosonde

[Nick Foster]

Andrew,

The first sentence of Bastian's excellent readme answers your second
question. Please do the bare minimum research before sending an email to
several thousand people.

We get that you're excited about GNU Radio. We all are. But if you are
expecting a detailed answer to a question, you need to ask a detailed
question in the first place. Here's a template you can use to help you with
that:

What are you trying to do? Be specific. What software are you trying to do
it with?

What command did you run? If you have a flowgraph, please attach it for
reference.

What did you expect to happen?

What actually happened? Cut and paste is extraordinarily helpful here.

What help do you need in order to move forward?

Hopefully this template can make the mailing list a more useful place for
us all.

Best,
Nick

On Sun, Aug 27, 2017, 10:38 PM Andrew Rich  wrote:

> Yes I have the flow graph setup
>
> I would like to know a bit more about it
>
> Is it possible to get GPS data from it
>
> What modes are supported
>
> Andrew
>
>
> On 28 Aug 2017, at 3:35 pm, andrea montefusco 
> wrote:
>
> Google is your friend, searching for
>
> gnuradio radiosonde flowgraph
>
> returns
>
> https://github.com/bastibl/gr-rstt
> http://brmlab.cz/project/weathersonde/start
>
> Andrea Montefusco IW0HDV
>
> On Aug 28, 2017 07:28, "Andrew Rich"  wrote:
>
>> Hello
>>
>> Anyone have experience decoding radio sonde devices ?
>>
>> Have the flow graph
>>
>> Andrew
>>
>> Sent from my iPhone
>>
>> ___
>> 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] Observing Random Jitter in HackRF One in High Bandwidth with High Carrier Modulation

[Nick Foster]

Do you actually have any evidence or plots showing excess jitter in the
HackRF One and its effect on gr-dvbt demodulation, or are you just making
it up?

It sounds like you have come to a conclusion without understanding the
problem.

--n

On Thu, Jul 6, 2017, 7:15 AM Stack Programer 
wrote:

> Yet i work on DVB-T in HackRF one, in TX we can send DVB-T and we receive
> it with a hardware dongle DVB-T. but for receiving with SDR Based we had
> error: see this link for our older
> 
> work or this
>  link.
>
> DVBT project receiver probelm OOrestart aquisition d_freq_offset: -5
> Od_freq_offset: -5
>
> So for examine my problem i created a new issue on hackrfone github
> project see this  link,
> every thing i found i will update there. In older our post we define jitter
> error , for more info you can see this
> 
> link.
>
> Fig1:Jitter error diagram description
>
>- *So we start examine that how we observed HackRF One has Random
>jitter errors??*
>
> my reason why HackRF One has random jitter error, In protocol like gr-dvbt
> ,gr-ofdm,gr-atsc that they are ofdm
> based modulation, we had not any response in receiver mode in dvb-t we had
> famous error: but frequency offset instantly from -5,3,2,7,….
>
> restart aquisition d_freq_offset: -5 Od_freq_offset: -5
>
> So we  had a error in uncertianly frequency and other hand it is random,
> so we had radom jitter errror.for more info see this
>  link.
>
>- *reason of causing HackRF  One has Jitter error?*
>- Low Resolution ADC:
>
> after some search i concluded that one of reason for random jitter error
> in HackRFOne is low resolution ADC, it has 8 bit ADC,please see this
>  link
> that describe how low resolution ADC can create jitter errors .
>
>- Low SNR in  HackRF One:
>
> For problem long switch diode stage in RF HackRF One it is more noisy vs
> USRP. So it use long way RF, it should edited in newer version.
>
> you can see in below image and link that how bad SNR and low ADC
> resolution can caused jitter errros.
>
> for more info please see this
>  link.
>
>
>
> [image: jitterADC]
>
> Fig2:low resolution ADC can cause jitter errors
>
>
>
> So we saw that HackRF One in OFDM based modulation and high carrier or in
> high bandwidth it sucks and it has random jitter errors, so we should ask
> myself that we need new design opensource hardware SDR hardware?
>
> But some question is need to answered??
>
> *why is mention HackRFOne has bandwidth 20 MSPS…..*??
> we should define bandwidth and sps in high carrier modulation
> it has problem in high carrier modulation?.So really HackRF One have
> Bandwidth more than 2 MSPS?
>
> *but what's solution?*
>
>-
>using a external clock for hackrf one???
>-
>design a new hardware………?
>
> i liked hackrfone for reason that is opensource and hardware, but with
> this condition i concluded that
> we should think a new way for future sdr hardware opensource?
>
> best regards stackprogramer
>
> Fig3:HackRFOne a opensource hardware SDR hardware
>
>
> ___
> 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] Proper synchronization of f0T correction to use gr-trellis for a receiver (Re: gr-trellis test_cpm.py question)

[Nick Foster]

Unrelated to the question at hand, but since you're on the subject: how are
you resetting the Viterbi decoder state between packets? I tried the same
thing some years ago and it worked well except for that problem.

--n

On Thu, Apr 6, 2017 at 12:38 PM Andy Walls 
wrote:

> On Mon, 2017-04-03 at 09:06 -0400, Achilleas Anastasopoulos wrote:
> > sure, feel free to look into the gr-trellis documentation and provide
> > some feedback.
> > If you have further questions please let us know.
> >
> > best,
> > Achilleas
>
> Hi Achilleas:
>
> My objective is to implement an AIS (GMSK, BT=0.4, L=3) receiver, using
> the Viterbi algorithm for optimal demodulation of the CPM symbols.
>
> In examining gr-trellis/examples/python/test_cpm.py, I see that
> everything is perfectly synchronized, for the purposes of
> demonstration. (The addition of a 0.0 to the end of the 99% energy
> orthonormal basis vectors for the matched filter correlators, to have
> the taps completely fall into the initial all-0 history of the fir
> filter blocks, was a nice trick BTW).
>
> In my design concept for a receiver, I believe I have worked out
> carrier frequency offset correction, phase offset correction, symbol
> timing recovery at either 4 or 5 samples per symbol, and injecting
> samples to properly realign the symbols entering the decimating matched
> filter correlators when a new burst is received.
>
> What I can't quite figure out is how to properly synchronize the
> correction of f0T carrier frequency shift introduced by the CPM
> decomposition, without unintentionally adding an arbitrary phase shift
> to the symbol's signal in the CPM decomposition.
>
> Do I restart the complex exponential frequency shift sequence with a
> phase of 0 at the start of each symbol?  I think that works for Q=4.
> But what about for Q=5?
>
> The reason I ask is that it appears the phase of the complex
> correlation output by the matched filters will affect the metric for
> which CPM decomposition signal gets selected as the best match.
>
> Looking at the 16, 99% energy CPM decomposition signals generated by
> the test_cpm.py script:
>
> >>> print abs(Sf.transpose())
> [[ 1.81592306  0.83465307]
>  [ 1.81592306  0.83465307]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.96823385  0.34970555]
>  [ 1.96823385  0.34970555]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.96823385  0.34970555]
>  [ 1.96823385  0.34970555]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.81592306  0.83465307]
>  [ 1.81592306  0.83465307]]
>
> Many of the signals can only be distinguished from each other properly
> when the correlator outputs have proper phase.
>
> Thank you for any advice you can provide.
>
> Regards,
> Andy
>
> ___
> 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] Constant carrier digital transmission

[Nick Foster]

This is a pretty familiar problem. A lot of satcom systems require
continuous transmission when in an idle state so the receiver can use slow
(i.e., sensitive) frequency and timing estimator loops. I'm sorry to say
there's no great answer.

But you have some options:
a) modify the HDLC block so that when work() is called, if nothing is in
the msg queue just output some fixed number of 0x7Es and sit on its thumbs
until the next call.
b) modify whatever block is generating messages so that it outputs 0x7E
frames periodically
c) modify the FPGA (or whatever DUC backend you're using) to both do the
modulating and send 0x7Es (modulated) when there's nothing coming in

Each approach has its disadvantages:
a) because Gnuradio buffers can be quite large, you will incur a latency
penalty as GR (i.e., all of the buffers of all of the blocks downstream of
the HDLC framer) propagates your frame downstream
b) message sources don't have backpressure, so this won't really work --
either you'll underflow and interrupt your sample stream or build up a huge
stack of unsent data just as in a)
c) this is a lot of work, and requires that the whole modulator,
soup-to-nuts, is implemented in the FPGA.

I'd start with approach a) and work your way towards c) if your application
can't handle the latency.

--n



On Mon, Aug 15, 2016 at 8:57 AM Marcus Müller 
wrote:

> Yep, next (==what becomes 3.8) fixes that spinning.
>
>
>
> On 15.08.2016 17:35, Marcus Müller wrote:
>
> Hi Frank,
> > Are you suggesting that I send a SOB tag along with the Flag 0x7E (1
> byte) and the radio will continuously output 0x7E's until I send an EOB ?
>
> Whatever "flag 0x7e" is, no, that's not how it works. You specify a
> transmit time at the start of your burst, and that's the time that the USRP
> will start transmitting the burst. You need to supply the samples that it
> will transmit. Setting another tx_time later on will define a "stop and
> wait for that time to come before continuing to transmit".
> Note that I have no actual clue of HDLC; I was presuming it was a very
> packet-oriented thing?
>
>
> The project I am on is a cubesat project and the team working on the
> cubesat have stipulated that to maintain lock on the signal, when not
> transmitting data the ground station transmitter (my work) is to send
> continuous HDLC Flags. So regardless of my view I need to somehow meet this
> requirement.
>
> That conflicts with my impression that HDLC is a packet format with
> sufficient framing? Because then I don't really see a possibility of
> "continuous HDLC flags"; just closely enough timed HDLC frames that help to
> maintain channel state information on the ground, right?
>
> In that case, I'd expect that these "keepalive" frames are just a special
> kind of data frame, and you'd basically have a timer somewhere that runs
> out occasionally, initiating a frame transmission if it does, and that gets
> reset to 0 every time a frame was sent; or something similar.
>
> Sorry for taking up so much of your time. Your assistance is appreciated.
>
> Hey, sorry if I sometimes come across a little harsh :) I was just really
> confused by the whole aspect of that obsolete thread.
>
> So, let's give a quick overview of what I understand, so that we have a
> good base for discussion:
>
>- You're implementing the satellite-side end of a HDLC comms line
>- You'll have two types of packets
>   - actual payload packets
>   - packets only meant to keep sync with the ground station
>
> So, the current situation is this:
>
> Assuming you want some kind of GMSK modulation, this would "work" for you:
>
>
> [image: flowgraph excerpt]
>
> so what happens here is
>
>
>- The message strobe generates a message every 500 ms containing a
>pair with an arbitrary value in the first element (the HDLC framer demands
>this, but doesn't use it), and a byte vector (ascending values) in the
>second element.
>- The HDLC framer has a message port, which means it can
>asynchronously get messages (asynchronous to the work() ) function; every
>time the work() is called, the HDLC framer checks the new-style message
>queue (that's a bit different from the old-style messgae queues you'll find
>in old GNU Radio). Sadly, in GNU Radio's current version (3.7) this means
>that it "spins"; but that should, as far as I can tell, change with 3.8.
>(I'm testing this right now)
>   - if there's a message in the queue, get it, turns it to a HDLC
>   frame, and adds an output stream tag to the first produced sample 
> telling
>   the downstream blocks "hey, here starts a frame of N items"
>- the GMSK modulator takes one item and turns that into 8 complex
>samples (hence the "tagged stream multiply length tag" block – the length
>tag doesn't reflect the correct length anymore)
>- The USRP sink has been set to "wait for a frame (tagged stream
>block) tag" mode, and will send a burst of specified sample number up

Re: [Discuss-gnuradio] IMSI Catcher Catcher?

[Nick Foster]

The GNU Radio community is always excited to see new applications for the
platform. We have an excellent history of supporting new developers with
interesting ideas who wish to work to turn those ideas into working
software.

--n

On Mon, Jun 20, 2016 at 2:19 PM Ronald F. Guilmette 
wrote:

>
> I just wanted to check again, one last time, before I exit this
> mailing list.  I got no truly useful replies to my earlier post,
> so I just wanted to ask again...
>
> Nobody here either knows of, or has any particular interest in creating
> an off-the-shelf stingray detector (aka "IMSI Catcher Catcher")?
>
> Is that correct?
>
> If so, that's a pity.  I would have thought that GNURadio would have
> been a perfect basis for this kind of thing, certainly code-wise, but
> also because of the typical and widespread political leanings of most
> GNU communities, which tend to favor individual freedom in preference
> to state-sanctioned orthodoxy.
>
>
> Regards,
> rfg
>
> ___
> 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] File source problem

[Nick Foster]

One clue for you is already being printed out for you in the TX flowgraph
image. Get rid of the throttle block.

The RX time domain plot looks actually pretty healthy. It's showing a
frequency offset, which is normal for unsynchronized devices.

The constellation plot needs to happen after timing and phase recovery, or
it will show useless garbage. Because your PSK demod is happening all in a
single, monolithic block, you don't get access to the constellation. If you
put a timing recovery block and a Costas loop block in front of the QT GUI
sink, and set their parameters appropriately, you should be able to get a
decent constellation plot.

--n

On Wed, Jun 15, 2016 at 1:26 PM Olivier Goyette 
wrote:

> I'm giving a copy of the email I just sent to Ettus Research. I think that
> it's been a hardware problem since the beginning but i'm waiting for their
> response.
>
> Check it out, maybe some of view have already seen this kind of bug
>
>
> *E-mail*
>
> Hi !
>
>
>
> My name is Olivier and I’m actually working with your USRP N210 and
> GNURadio Companion. It’s been a couple of week since I started using your
> equipment and yet, I already had issues with it. Doing a simple
> modulation/demodulation seems impossible and everything I came up with
> until now, suggest me that it’s a hardware problem. So, I took quite a lot
> of pictures for you to see what’s wrong and I’ll share the links to my
> dropbox so it will be easier like that.
>
>
>
> What I’m trying to do is a PSK mod and demod. I know it works because one
> of my colleague is using a Nutaq Zepto SDR and he’s been using the same
> flowgraph as mine in an other project and it works perfectly. So, what we
> did is the following setup :
> https://www.dropbox.com/s/ottq341sob5z90r/Actual_setup.jpg?dl=0
>
>
>
> The upper radio represents the TX link (WBX card) and the one at the
> bottom represent the RX link (SBX card).
>
>
>
> This is the flowgraph on the TX radio :
> https://www.dropbox.com/s/ir5ehp6caiy525a/TX_side.jpg?dl=0
>
>
>
> This is the flowgraph on the RX radio :
> https://www.dropbox.com/s/tl95cwbstwzl4r8/RX_side.jpg?dl=0
>
>
>
> What we’re trying to do is to transmit a video stream from one computer to
> another. Unfortunately, on the RX computer, the file supposedly containing
> the video is empty (0 bytes when you right click on it and go to the
> properties panel).
>
>
>
> This is the TX spectrum :
> https://www.dropbox.com/s/pzsn8oo74sgrehp/TX_spectrum.jpg?dl=0 and this
> is the spectrum when you look at it with a spectrum analyser :
> https://www.dropbox.com/s/5bks7aksih8ctzh/TX_MDO_spectrum.jpg?dl=0
>
>
>
> This is the RX spectrum :
> https://www.dropbox.com/s/dlsovfxovv4n9tm/RX_spectrum.jpg?dl=0
>
>
>
> This is the TX time domain graph :
> https://www.dropbox.com/s/q25sbjukyzsyymz/TX_time_domain.jpg?dl=0
>
>
>
> This is the RX time domain graph :
> https://www.dropbox.com/s/qetgf0cr4s7d5hb/RX_time_domain_1.jpg?dl=0
>
>
>
> This is the TX constellation :
> https://www.dropbox.com/s/gflb0f65oa0m1rl/TX_constellation.jpg?dl=0
>
>
>
> This is the RX constellation :
> https://www.dropbox.com/s/4j0hnhl97v2uj7g/RX_constellation.jpg?dl=0
>
>
>
> What seems strange to me is the time domain graph at RX. It’s like if the
> imaginary part and the real part of the signal were modulated onto whatever
> signal that appears to be there. I tried my RX link on one of the other
> radio I have and look at the result :
> https://www.dropbox.com/s/f1al75vgo5z2wcf/RX_time_domain_2.jpg?dl=0 . The
> time domain is completely different but still it is a SBX card and I
> haven’t touch any settings in my flowgraph to keep consistency.
>
>
>
> So, now I’m asking for your help because my knowledge is pretty basic with
> this equipment and I’d like to have your input about that.
>
>
>
> For your information, I did reload the firmware and the bitfile into the
> FPGA before sending this email so it’s not necessary to ask me to do it.
>
>
>
> I sincerely hope this will lead somewhere as I’m out of options right now.
>
>
> Thank you for your time and have a nice day !
>
> 2016-06-15 13:58 GMT-04:00 Marcus Müller :
>
>> Hi Olivier,
>>
>> what does this mean:
>>
>> The 1st file contains only '1' and the other only '0'.
>>
>> How did you generate these files. Without knowing better, I'd say this is
>> a case for our File Format FAQ:
>>
>>
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-file_sink-How-can-I-read-files-produced-by-a-file-sink
>>
>> Best regards,
>> Marcus
>>
>> On 06/15/2016 12:25 AM, Olivier Goyette wrote:
>>
>> This is non sense seriously. This is my flowgraph :
>> 
>> https://www.dropbox.com/s/4cfptq5419kvyhz/file_source.png?dl=0
>>
>> When I send only zeros '0', this is what I get :
>> 
>> https://www.dropbox.com/s/aipf6ws

Re: [Discuss-gnuradio] Displaying angle measurements with a nice GUI

[Nick Foster]

You ought to be able to use PyQwt's compass widget:

http://qwt.sourceforge.net/class_qwt_compass.html

I used it for gr-air-modes and, while ugly, it does work. There's no
integration into GRC so the Python to integrate the widget will, of course,
be your responsibility.

--n

On Wed, Jun 15, 2016 at 9:45 AM Martin Braun  wrote:

> Meny,
>
> no, we don't. A compass was one of the suggestions for this year's GSoC,
> but no one signed up for that.
>
> M
>
> On 06/15/2016 04:34 AM, Meny Sidar wrote:
> > Hi guys
> >
> > I'm looking for a nice GUI that can plot my AoA calculations in a some
> > kind of a compass looking GUI.
> > Does anything like that exists? or do i have to build one of my own?
> > Don't really know how, and would prefer not to start learning Python
> > right now (on a deadline).
> >
> > Any help would be much appreciated!
> > Thanks,
> > Meny
> >
> >
> >
> > ___
> > 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] 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] Syncronization issues, using a GPSDO

[Nick Foster]

You're probably seeing the "site survey" phase of the GPSDO's acquisition.
This only happens immediately after applying power, right? The GPSDO needs
time to settle in.

--n

On Tue, May 24, 2016, 8:10 AM Meelis Nõmm  wrote:

> 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.
>
>
> 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?
> Meelis
>
>
>
> ##Setup UHD Source##
> self.uhd_src = uhd.usrp_source(
> device_addr=self.uhd_addr,
> stream_args=uhd.stream_args('fc32')
> )
>
>
> #Should be redundant for N2xx with internal module, but just to be
> safe
> self.uhd_src.set_clock_source("gpsdo")
> self.uhd_src.set_time_source("gpsdo")
>
> print "Checking if GPSDO locked"
> while(not self.uhd_src.get_mboard_sensor("gps_locked").to_bool()):
> time.sleep(0.1)
> time.sleep(0.2)
> print "GPS Locked  , bool = ",
> self.uhd_src.get_mboard_sensor("gps_locked").to_bool()
>
> print "Checking if ref locked"
> while(not self.uhd_src.get_mboard_sensor("ref_locked").to_bool()):
> time.sleep(0.1)
> time.sleep(0.2)
> print "10 MHz Locked  , bool = ",
> self.uhd_src.get_mboard_sensor("ref_locked").to_bool()
>
> t = self.uhd_src.get_time_last_pps()
> while (t == self.uhd_src.get_time_last_pps()):
> pass
> #Set the time from the GPS time
> gps_time = self.uhd_src.get_mboard_sensor("gps_time").to_int()
> self.uhd_src.set_time_next_pps(uhd.time_spec(gps_time+1))
> #This sleep is recomended to stabilize the clocks
> time.sleep(1)
>
>
> ##Initialization and connecting
>
>
> #Set the start time
> self.uhd_src.set_start_time(uhd.time_spec(gps_time + 3))
>
>
>
> ___
> 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] gr-air-modes/issues/81

[Nick Foster]

Thanks for the detective work, Maitland. I'll cave to convention and move
the filename.

Fix pushed to master.

--n

On Sun, May 1, 2016 at 6:21 AM A. Maitland Bottoms 
wrote:

> (
>  discuss-gnuradio readers: this is about this issue
>  https://github.com/bistromath/gr-air-modes/issues/81
> )
>
> Nick Foster writes:
>  > Thanks Maitland. Do you happen to know offhand if other OOT modules are
>  > affected?
>
> I have not seen any like this. Lucky me, I saw Sesame Street in my youth,
> so I can play "One of these things is not like the other". I came up with
> noticing all the working OOT modules have a swig/_swig.i file.
>
> For example in gr-osmosdr has a swig/osmosdr_swig.i
> while gr-air-modes has a swig/air_modes.i
>
> So currently gr-air-modes breaks because of some implicit deriving
> of the SWIG_MODULE_NAME from the .i file name. I have not tracked
> down exactly when behaviour changed. Clearly Debian stable with
> cmake 3.0.2 builds fine without changes, and Debian unstable last
> year with cmake 3.4.1 was also fine. I think the failures coincide
> with cmake 3.5.0, continuing in the current cmake 3.5.2.
>
> Attached are two solutions.
> Both yield builds on both Debian stable and Debian unstable.
> You can take your pick.
>
> fix-issue81-by-file-rename.patch:
> My first attempt, just making gr-air-modes look more like other
> OOT projects by renaming the .i file.
>
> fix-issue81-by-PROPERTY-SWIG_MODULE_NAME.patch:
> A one-liner, after noticing cmake 3.5.2's UseSWIG.cmake has some
> documentation of SWIG_MODULE_NAME.
>
> Seems that gr_modtool has been creating the swig/modulename_swig.i
> file name since before it got merged into gnuradio. So gr_modtool
> users are less likely to stumble accross this issue.
>
> -Maitland
>
> enc:
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Docker

[Nick Foster]

On Thu, Apr 14, 2016 at 5:40 PM Nicholas McCarthy 
wrote:

> Yeah, this is one of the things I like most about Dockerfiles... the self
> documenting aspect.  However... have you noticed how many times you end up
> dealing with Docker images apart from their Dockerfiles?  For a lot of
> useful images, it's difficult (maybe impossible?) to track the Dockerfile
> down... I've heard it's pretty easy to reverse engineer from the
> intermediate layers, but still.  With pybombs, the catalog is part of the
> image at the command line.  Also, for any OOT, there might just be one guy
> who's an expert at building the project (the guy who wrote the recipe,
> presumably).  Anyone can use the resulting recipe to install, so if you
> want to support a Docker image with dependencies in the pybombs recipe
> world, you don't have to learn how to install them... just use the work
> already in pybombs.
>

Distribute a Dockerfile in the root folder of each OOT. Then you don't have
to have any expert build, you just do "docker build ." and pow, it's
recreated anytime, anywhere. Whether you use pybombs or you just put the
dependencies and build process in the Dockerfile shouldn't matter, the
entire recipe should be in there for anyone to recreate.


>
> Yeah, I should run a real test pitting compression versus
> non-compression I may have gotten confused with pre-existing image
> layers and the source-stripping feature (which definitely helps a lot).  If
> I can avoid the whole tar and untar, that'd make everything much easier.
> The manual decompression takes a lot longer than the Docker decompression,
> though, so maybe bzip2 is just doing a better job?  This will have to wait
> until I have a really good connection, tho.
>
> Okay, that's true... it does very much depend on what you're
> rebuilding So it makes sense to isolate code that changes a lot from
> stable code in layers.  To me, this means installing all the dependencies
> for uhd and gnuradio in a layer, then uhd, then gnuradio... Does it make
> sense to layer any more? (I mean, obviously, it could matter theoretically,
> but in practice?  Am I missing a volatile dependency?)
>

It means that if you're doing daily Gnuradio builds you'll have to pull the
whole layer down each day. If you only want daily builds of your OOT
module, then no, there's no reason you'd want to layer any more finely
grained than that. The incremental cost of updating an OOT should be just a
few MB.

--n


>
> Cheers,
> Nick M.
>
> On Thu, Apr 14, 2016 at 7:48 PM Nick Foster  wrote:
>
>> On Thu, Apr 14, 2016 at 3:54 PM Nicholas McCarthy 
>> wrote:
>>
>>> Three points to make about this OOT Docker example.
>>> 1) Everything you're doing manually here can be accomplished using
>>> pybombs2... and pybombs2 makes itself quite amenable to existing within the
>>> Docker image both as an interface to what's already installed on the image
>>> and a handy way to install new OOTs and dependencies on top of the image.
>>> I would favor using pybombs2 as a basis for gnuradio Docker images... at
>>> least that's what I'm doing for myself.
>>>
>>
>> The only argument I have against this is that not doing so (i.e.,
>> cataloging the dependencies manually in the Dockerfile) sort of obviates
>> the need for pybombs, in this particular case. The dependencies and build
>> procedures are either encoded in the individual Dockerfiles, which are
>> simply part of the OOT project itself, or they're centralized into pybombs
>> recipes. Their usefulness overlaps somewhat.
>>
>> Where I see a clear win for pybombs in a Docker recipe is when you want
>> to compile and install multiple OOTs in a single Docker image -- it's
>> painful to "stack" targets to create a catchall image (i.e., uhd ->
>> gnuradio -> gr-air-modes -> gr-ais...), and annoying to cut and paste
>> Dockerfile recipes to concatenate them. It's not an issue from a production
>> standpoint since half the reason to use Docker in production is to isolate
>> services from each other, one image per service (if all your services
>> depend on the same base layer, there's little/no image size overhead). But
>> if you're putting together a single catchall image for folks to muck around
>> with, a pybombs base layer seems like a great way to do that and still keep
>> a sane-ish Dockerfile.
>>
>>
>>> 2) Supporting a pybombs2 Docker image is a great way to ensure that
>>> pybombs2 builds from a very, very minimal initial Linux installation.
>>> Since pybombs2 is newis

Re: [Discuss-gnuradio] Docker

[Nick Foster]

as a basis for images building OOTs, but what the hell
> are you going to do with an image that's run pybombs install boost except
> run pybombs install gnuradio?
>

Only the incremental layers which have changed need to be sent over the
wire. This can be pretty painful if you're building Gnuradio monolithically
(i.e., in a single RUN command), and means building a distribution in
explicit layers has possibly the largest effect on over-the-wire
requirements for users who need daily Docker builds.

--n


>
> Cheers,
> Nick M.
>
>
> On Thu, Apr 14, 2016 at 2:16 PM Nick Foster  wrote:
>
>> I think it would be really helpful for the GNU Radio project to support a
>>>> standard, basic gnuradio docker install with uhd and grc enabled as well as
>>>> an example or two to demonstrate sane ways to run OOT modules on top of
>>>> that image.  As Ben mentioned, Docker seems like a pretty energy-efficient
>>>> way to approach support for systems like Windows and OSX going forward.
>>>> Not having used boot2docker personally, I won't say that it's necessarily
>>>> time to retire the live usb image, but I think Docker may evolve quickly
>>>> into a pretty obvious replacement, if it hasn't already.  I also appreciate
>>>> GNU Radio looking for ways to support users and potential users attempting
>>>> to build and deploy applications that reach beyond the immediate
>>>> environment of GNU Radio and its core devs.
>>>>
>>>
>> As far as OOT modules, that's easy. For instance, a Dockerfile for
>> gr-air-modes could look like this (this is untested, don't get any ideas):
>>
>> FROM bistromath/gnuradio:3.7.8
>> MAINTAINER bistrom...@gmail.com version: 0.1
>> RUN apt-get install -y python-zmq
>> WORKDIR /opt/gr-air-modes
>> COPY . /opt/gr-air-modes
>> RUNmkdir build \
>> && cd build \
>> && cmake ../ \
>> && make -j4 \
>> && make install
>>
>> ...that's more or less the whole thing, although this particular example
>> is broken for a couple of reasons (no Qt in my base layer, other missing
>> prerequisites). It might be nice to include a Dockerfile template in the
>> OOT example. The nice part about doing OOT modules in this manner is that
>> Gnuradio users could potentially never have to compile Gnuradio -- just
>> write their OOT and base its Dockerfile upon a precompiled Gnuradio base
>> layer. Another benefit is bitrot is all but eliminated, as you're basing
>> your module on top of a versioned base layer rather than master.
>>
>>
>>>
>>>> One problem we have to face, though, is image size.  I'm trying to
>>>> tackle that problem by compressing the install for transactions over the
>>>> wire and then uncompressing locally for applications (using pybombs2, of
>>>> course).  This is all a little awkward for docker distribution, but lots of
>>>> things in docker are a little awkward.  Developers could build on top by
>>>> untarring the prefix, pybombs installing extra recipes (possibly custom
>>>> recipes) and then using the deploy command again, all within the same
>>>> Docker "RUN" section.  Locally, if you docker build applications beginning
>>>> with the same commands to untar the image, then all applications can take
>>>> advantage of that layer (you'll have to untar the base image only one time
>>>> regardless of how many applications use the base image).  Alternatively,
>>>> you can docker run with cmd or entry set to untar the image (and then,
>>>> presumably, you'll want to commit the running container locally so you
>>>> don't have to untar again).
>>>>
>>>
>>>>
>>> Does anyone have a better idea for bringing image size down without
>>>> making it impossible to build and deploy OOTs?  Those Bistromath images are
>>>> pretty tiny... I haven't really looked into the Alpine base image, either.
>>>>
>>>>
>>>
>> The Docker image I put up on Docker Hub is small-ish because it only
>> includes these components (and their prerequisites):
>>
>> --   * python-support
>> --   * testing-support
>> --   * volk
>> --   * gnuradio-runtime
>> --   * gr-blocks
>> --   * gnuradio-companion
>> --   * gr-fft
>> --   * gr-filter
>> --   * gr-analog
>> --   * gr-digital
>> --   * gr-channels
>> --   * gr-uhd
>> --   * gr-utils
>>

Re: [Discuss-gnuradio] Docker

[Nick Foster]

>
> I think it would be really helpful for the GNU Radio project to support a
>> standard, basic gnuradio docker install with uhd and grc enabled as well as
>> an example or two to demonstrate sane ways to run OOT modules on top of
>> that image.  As Ben mentioned, Docker seems like a pretty energy-efficient
>> way to approach support for systems like Windows and OSX going forward.
>> Not having used boot2docker personally, I won't say that it's necessarily
>> time to retire the live usb image, but I think Docker may evolve quickly
>> into a pretty obvious replacement, if it hasn't already.  I also appreciate
>> GNU Radio looking for ways to support users and potential users attempting
>> to build and deploy applications that reach beyond the immediate
>> environment of GNU Radio and its core devs.
>>
>
As far as OOT modules, that's easy. For instance, a Dockerfile for
gr-air-modes could look like this (this is untested, don't get any ideas):

FROM bistromath/gnuradio:3.7.8
MAINTAINER bistrom...@gmail.com version: 0.1
RUN apt-get install -y python-zmq
WORKDIR /opt/gr-air-modes
COPY . /opt/gr-air-modes
RUNmkdir build \
&& cd build \
&& cmake ../ \
&& make -j4 \
&& make install

...that's more or less the whole thing, although this particular example is
broken for a couple of reasons (no Qt in my base layer, other missing
prerequisites). It might be nice to include a Dockerfile template in the
OOT example. The nice part about doing OOT modules in this manner is that
Gnuradio users could potentially never have to compile Gnuradio -- just
write their OOT and base its Dockerfile upon a precompiled Gnuradio base
layer. Another benefit is bitrot is all but eliminated, as you're basing
your module on top of a versioned base layer rather than master.


>
>> One problem we have to face, though, is image size.  I'm trying to tackle
>> that problem by compressing the install for transactions over the wire and
>> then uncompressing locally for applications (using pybombs2, of course).
>> This is all a little awkward for docker distribution, but lots of things in
>> docker are a little awkward.  Developers could build on top by untarring
>> the prefix, pybombs installing extra recipes (possibly custom recipes) and
>> then using the deploy command again, all within the same Docker "RUN"
>> section.  Locally, if you docker build applications beginning with the same
>> commands to untar the image, then all applications can take advantage of
>> that layer (you'll have to untar the base image only one time regardless of
>> how many applications use the base image).  Alternatively, you can docker
>> run with cmd or entry set to untar the image (and then, presumably, you'll
>> want to commit the running container locally so you don't have to untar
>> again).
>>
>
>>
> Does anyone have a better idea for bringing image size down without making
>> it impossible to build and deploy OOTs?  Those Bistromath images are pretty
>> tiny... I haven't really looked into the Alpine base image, either.
>>
>
The Docker image I put up on Docker Hub is small-ish because it only
includes these components (and their prerequisites):

--   * python-support
--   * testing-support
--   * volk
--   * gnuradio-runtime
--   * gr-blocks
--   * gnuradio-companion
--   * gr-fft
--   * gr-filter
--   * gr-analog
--   * gr-digital
--   * gr-channels
--   * gr-uhd
--   * gr-utils
--   * gr-wxgui

It could be a lot smaller if I removed the GR build files (292MB), GR
source files (88MB), and UHD source/build (200MB). That would cut it down
to somewhat more than half its current size. I like having them there
because if I'm working inside the environment I can compile changes
incrementally. For a pure deployment system, though, they're unnecessary.

It's possible, albeit messy, to build a Gnuradio distribution in layers and
tag the individual layers separately. Because each command in a Dockerfile
produces an incremental UFS layer, if you can break the compilation of
Gnuradio into separate commands for each component in the Dockerfile, then
you can tag the various incremental layers to build different composite
Gnuradio distributions. It's probably simpler just to provide a
"bells-'n-whistles" version and a "bare bones" version.

If you like, I can see just how small I can reasonably get things. I'd
argue, though, that a one-time, couple-of-GB download is a reasonable
compromise for the convenience of versioned distribution in all but niche
applications (embedded or offline come to mind). In other words, the
benefit of getting the wire size down probably doesn't outweigh the effort
for most people.

--n


>
>>
>>
>> ___
>> 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

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Nick Foster]

On Thu, Apr 7, 2016, 3:48 PM Ben Hilburn  wrote:

>
> What was your experience like when it came to using the RTL dongle? Was
> there any complexity there? If you have hardware that can stream at higher
> rates, I'd be interested in how those perform in the container, as well.
>

Performance is, for all intents and purposes, unaffected. Network
performance may be very slightly affected by the virtual network device. If
your application is very sensitive, just use the "--net host" option when
invoking the container.

I have benchmarked X310 performance using the "--net host" option and
gotten effectively identical results inside a container vs. running
natively. I do not consider Docker containers to affect performance in any
way.

--n


>
> On Wed, Apr 6, 2016 at 4:23 AM, Stefan Wunsch <
> stefan.wun...@student.kit.edu> wrote:
>
>> Hi all!
>>
>> I have build a docker tool-chain for an image with GNU Radio and UHD
>> installed via PyBOMBS on top of Ubuntu. It's even possible to run it
>> dockerized with a GUI using VNC and it should work as well on windows
>> and mac (so far, not tested). The build files are available on github
>> and the precompiled images on hub.docker.com. If you are interested,
>> have a look! In the following, I will give a short description.
>>
>> How to run the image with VNC server and how to access the container:
>>
>> # Run the image with GNU Radio and VNC server:
>> # The run command will download (pull) the image automatically.
>> # Use the additional option '-device=/dev/bus/usb' for USB access,
>> # e.g., to use rtl dongles. You have to plugin the devices before you
>> # start the container!
>>
>> $ docker run -it --rm -p 5901:5901 -e USER=root \
>> stwunsch/docker-pybombs-gnuradio-vnc bash -c \
>> "vncserver :1 -geometry 1280x800 -depth 24 && tail -F /root/.vnc/*.log"
>>
>> # Get graphical access using a VNC client. I suppose you are running
>> # the container on the same machine. Here an example command using
>> # vncviewer. As well, it's possible to use X forwarding.
>>
>> $ vncviewer localhost:5901
>>
>> So far, it's only tested on a Linux machine, but it should work on every
>> system with an installed docker daemon. I was able to run a rtl dongle
>> with gr-osmosdr. To install new OOTs, just open a terminal and type, for
>> example, 'pybombs install gr-osmosdr'.
>>
>> Here, the image chain. You can pull these images from hub.docker.com.
>> All images are build automatically on change of the appropriate GitHub
>> repository (except the GNU Radio base image, see below for more info on
>> that).
>>
>> Base-image: ubuntu 14.04
>> -> ubuntu + pybombs (stwunsch/docker-pybombs)
>> -> ubuntu + pybombs + uhd (stwunsch/docker-pybombs-uhd)
>> -> ubuntu + pybombs + uhd + gnuradio dependencies
>> (stwunsch/docker-pybombs-gnuradio-depsonly)
>> -> ubuntu + pybombs + uhd + gnuradio (stwunsch/docker-pybombs-gnuradio)
>> -> ubuntu + pybombs + uhd + gnuradio + vnc server
>> (stwunsch/docker-pybombs-gnuradio-vnc)
>>
>> A single problem so far: It is not possible to build the GNU Radio image
>> (docker-pybombs-gnuradio) on the docker servers, because they have a 2h
>> build limitation. I have preinstalled everything (pybombs and all
>> dependencies), but it is not possible to run the compilation below 2h on
>> a single core.
>>
>> Does anyone know whether it's possible to split the compilation or speed
>> it up (without using the -jX flag)? Now the image has to be build
>> locally and then pushed to hub.docker.com manually. Not the best
>> solution!
>>
>> I would be highly interested whether it really works on other systems,
>> especially on windows! That could be a nice alternative to MSVC
>> compilations.
>>
>> Greetings
>> Stefan
>>
>> ___
>> 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] Gnuradio ASK/OOK Binary sequence

[Nick Foster]

Well, if you want a basically working "cheat sheet", I already wrote a
Gnuradio receiver for those keyfob transmitters:

https://github.com/bistromath/keyfob

It hasn't been updated in years, so it's still on the old Automake system.
It won't compile, but the source should get you started.

--n

On Mon, Sep 21, 2015 at 12:17 PM 0x00-0xff <0x00-0...@stienstra.me> wrote:

>
> Thanks, I've already red those pdf's.
> The adsb grc doesn't help me enough :)
>
> I'm getting large binary files with 0's and 1's which doesn't resemble
> the binary sequence I'm looking for...
>
>
> On 2015-09-20 22:33, Chris Kuethe wrote:
> > Check out gr-adsb
> > (https://github.com/wnagele/gr-adsb/tree/master/examples) - the
> > example flowgraph uses a threshold block to produce 0's and 1's. From
> > there you can unpack bits to bytes, add a constant of 48 (numerical
> > value of ascii '0') and come out with a character stream of '0' and
> > '1', which you can then feed into a file sink (opening /dev/stdout)
> >
> > Also check out these tutorials:
> > http://www.inguardians.com/pubs/GRC_signal_analysis_InGuardians_v1.pdf
> > https://nccgroup.github.io/RFTM/
> >
> https://cansecwest.com/slides/2015/From_Baseband_to_bitstream_Andy_Davis.pdf
> >
> >
> > On Sun, Sep 20, 2015 at 1:13 PM, 0x00-0xff <0x00-0...@stienstra.me>
> > wrote:
> >> Hi guys,
> >>
> >> After trying several tutorials en demo's... I need your help.
> >>
> >> I'm trying to get the binary stream from a ASK/OOK modulated signal
> >> (keyfobs
> >> on 433mhz).
> >> I've been able to manually write down the sequence and retransmit it:
> >> https://github.com/0x00-0xFF/gr-x10
> >>
> >> How do I get the 0's and 1's on /dev/stdout (or file).
> >> The tutorials I've seen, give me a load of 0's  and 1's that do not
> >> match
> >> the sequence I see in baudline or wx_scope
> >>
> >> What I realy (realy) want is, to save multiple received ASK/OOK
> >> signals into
> >> a file with corresponding frequency.
> >> But any help is appreciated ;)
> >>
> >> Kind regards,
> >>
> >> 0x00_0xFF
> >>
> >> ___
> >> 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] QT Blocks causing BER errors?

[Nick Foster]

My guess, educated only in that I've seen it happen before, is that one of
the blocks in your flowgraph exhibits behavior which is dependent on the
number of samples per work call. Loading the machine down with GUI blocks
will change the number of samples GR doles out during each work call.

Timing synchronizers would be the first place I'd look.

--n

On Thu, Jul 23, 2015 at 7:26 AM Marcus Müller 
wrote:

>  Hi Rich,
>
> being really surprised:
> I think it would be nice if we knew a bit more about the signal processing
> part of your flow graph.
> What does it rely on? Pure Sample Streams? Stream Tags? Message Passing?
> Old-Style Message queues?
>
> Best regards,
> Marcus
>
>
> On 22.07.2015 20:11, Richard Bell wrote:
>
>I've come across a really unexpected correlation this morning that I'm
> hoping someone has an explanation for. I have a large flow graph with many
> QT GUI blocks because I'm debugging a design. Mostly Time Sinks and
> Constellations plots with a couple of Frequency Sinks thrown in. The number
> of points in some of the time sinks is rather large, on the order of 30k,
> which allows me to see several packets of data at once.
>
>  What I noticed this morning, while debugging a BPSK loopback BER tester,
> is by disabling a number of Constellation plots which were fed by RRC
> filters to make the plot pretty, errors went away. The system works as you
> would expect a simulation with no noise or channel effects to work,
> perfectly. When I enable those GUI blocks, the system looses packet
> synchronization within the first minute consistently. Nothing is changed in
> the data stream between these tests.
>
>  So the question is, is there a known cap on GUI plots? Like I said, I
> have a lot of them and some of them are plotting a large number of points.
> Could this be causing buffers overruns into data spaces or something scary
> like that?
>
>  Another thought I had, could there be an identity problem in which GNU
> Radio at some point can't uniquely identify blocks with the same name apart
> from each other and thus chooses one in some default manner? I'm imagining
> a plotting stream getting crossed with a data stream in some way.
>
>  The bottom line is all I need to do to make this system work is disable
> some plotting only related blocks. Is there a known plotting cap issue that
> I should be aware of?
>
>  Thanks,
>  Rich
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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] Buffers and Sample Rates

[Nick Foster]

We call this the "two clock problem". This is something people (including
myself) have been talking about implementing for ages. There's nothing
available in GNURadio right now to do this.

--n

On Thu, Jun 18, 2015 at 12:51 PM Richard Bell 
wrote:

> Hi all,
>
> I'm working on a system that has hardware defining an input rate and
> hardware defining an output rate. This is a data based system, so I can't
> afford to lose any bits, which implies sample rate changes have to be
> exact.
>
> For example, if data is being input at 2.4 ksps and the USRP outputs data
> at 468.168 ksps, unless my intermediate sample rate changes produce a
> perfect mapping between the two rates, I can expect a buffer under or
> overflow eventually, which would produce problems.
>
> One solution to this problem, would be to use an arbitrary resampler
> before the USRP, that consists of a PLL dynamically changing the sample
> rate of the arbitrary resampler based on how full it's output buffer is. If
> the buffer is above half full, decrease your sample rate, if the buffer is
> below half full, increase your sample rate.
>
> Now the question. I assume I'm not the first person that has needed to do
> something like this, is there a built in mechanism to handle this problem
> already or do I have to create the feedback loop structure myself? I'd
> rather not re-invent the wheel.
>
> v/r,
> Rich
> ___
> 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] CPU usage when hdlc framer is used

[Nick Foster]

Issue #1 is likely the problem. Thanks for pointing that out, Andy! The
other two issues should be pretty miniscule in overhead, but are probably
good ideas nonetheless. The block was written for clarity rather than for
speed, but even so it shouldn't be particularly heavy-duty.

--n

On Tue, Jun 16, 2015 at 9:53 AM Andy Walls 
wrote:

> On Tue, 2015-06-16 at 12:01 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:
>
> > From: Thanasis Balafoutis 
> > To: "discuss-gnuradio@gnu.org" 
> > Subject: [Discuss-gnuradio] CPU usage when hdlc framer is used
>
> > Hi,
> >
> > CPU usage goes to 100% when the hdlc_framer block is used!
> > To verify this I did the following tests:
> >
> > 1. message_strobe_random >  message_debug  (CPU usage 2%)
> > 2. message_strobe_random > hdlc_framer> null_sink (CPU usage
> 100%)
> >
> > Any idea how can I avoid this overload?
>
> Off the cuff, it appears the hdlc_framer needs at least one fix:
>
> 1. If oidx == 0, it should use a blocking fetch of a message here:
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/hdlc_framer_pb_impl.cc#L132
> If oidx != 0 then using the current delete_head_nowait() call is
> correct.
> This is probably the major contribution to the CPU spinning.
>
> Maybe some other changes to the hdlc_framer block might help for high
> sample rates:
>
> 2. The block does a number of dynamic std:vector<> and pmt
> instantiations and destructions in a call to work().  If you use the
> oprofile tools, those likely generate some measureable overhead
> attributable to malloc() and atomic increments and decrements related to
> boost shared pointer for the PMTs.  You might gain a few % CPU back by
> avoiding the constant allocation & deallocation by converting the block
> to use class variables where it makes sense.
>
> 3. The block also has 2 memcpy()'s in a call to work().  If you can
> figure out an way to optimize one away, you'll get some savings.  I
> don't see an obvious way to do that right now.
>
>
> Also, your flowgraph does not have a throttle block to enforce a
> realistic timing for the sample rate you have chosen, so the hdlc_framer
> is going to run as fast as it can.  The null sink essentially ensures
> there is always output buffer space for the hdlc_framer.
>
> > Thank you
> > Thanasis
>
> Regards,
> Andy
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Correlation Estimation Block Oddity

[Nick Foster]

Short answer: use corr_est as your tag. The corr_start tag is undelayed by
the matched filter length, and intended for other purposes (data-aided
equalizers, etc.). Andy Walls can say more, but it's enough to say the
later three tags are the ones that match the peak of the correlation in the
output symbol stream. See corr_est_cc_impl.cc lines 206-214.

--n

On Wed, Apr 22, 2015 at 4:29 PM, Richard Bell 
wrote:

> Hello all,
>
> I'm using GR 3.7.8. I'm trying to work the new Correlation Estimation
> block into my design. I'm seeing what looks like unintended behavior for
> the tag placements. Sometimes the corr_start tag is placed on the same
> sample as the corr_est, time_est and phase_est tags, but sometimes the
> corr_start tag is placed a sample earlier then those three tags.
>
> I've attached a screenshot showing this behavior. In the same running flow
> graph the tag placement will go back and forth between being on the same
> sample or being off by one sample. As long as the corr_start tag is always
> on the correct sample I guess this won't break anything, but I figured I'd
> let you all know what I'm seeing.
>
> I don't have the full design working yet so I can't say myself that the
> block works.
>
> v/r,
> Rich
>
> ___
> 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] Input items vs Output items

[Nick Foster]

Also, to point out existing work, there is an HDLC framer and deframer in
Gnuradio now. The deframer takes in a byte stream, 1 bit per byte, and
outputs PDUs with your HDLC frames.

--n

On Sat, Apr 18, 2015 at 6:46 AM, Marcus Müller 
wrote:

> Hi Mike,
>
> you might actually be doing something redundant here:
> GNU Radio actually keeps tabs on how many items you produced; just call
> nitems_written(0) to get that number.
>
> I don't really understand where your string comes from or where it ends
> up, but do make sure your string isn't going to be longer than your
> noutput_items.
>
> Generally, this is something that can most probably best be analyzed
> using appropriate debugging methods -- I'd like to point you to [1].
> As soon as you find out where your segfault happens, it will be easier
> to understand under which conditions it happens. Also, GDB allows you to
> `print` the value of local variables, so that might actually shine quite
> a light on what goes wrong :)
>
> On a more general note: what your block seems to do looks very much like
> what tagged stream blocks (probably after gr-ax25) were designed to do.
> Have a look at [2]; maybe I'm misjudging the situation, maybe you're
> already using the TSB facilities.
>
> Greetings,
> Marcus
>
> [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
> [2] http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html
> On 04/18/2015 03:36 PM, Mike Willis wrote:
> > I should have added, the packet decoding is based on Volkers rather
> nifty gr-ax25, which I think is based on earlier implementations so I don't
> think that is where the bug is. I have heavily modified that code as I am
> using BPSK demodulator but the hdlc parts are the same.
> >
> > Mike
> >
> > -Original Message-
> > From: Mike Willis [mailto:willis...@gmail.com]
> > Sent: 18 April 2015 13:58
> > To: GNURadio Discussion List
> > Subject: Input items vs Output items
> >
> > I am slightly confused with the way you implement a general work
> function - here is my AX25 decoder which takes in bits and outputs decoded
> packets in text format as a stream of 8 bit integers. This was based on the
> general work example in the GR tutorial.
> >
> > int ax25_impl::general_work (int noutput_items,
> >   gr_vector_int &ninput_items,
> >   gr_vector_const_void_star &input_items,
> >   gr_vector_void_star &output_items) { int i; const char
> *bit = (const char *) input_items[0]; out = (char *) output_items[0];
> >
> > d_numchars=0;
> > for (i=0;i  > {
> > hdlc_rxbit( bit[i] );
> > }
> >
> > // Tell runtime system how many output items we produced.
> > consume_each (noutput_items);
> > return d_numchars;
> > }
> >
> > I keep a tally of how many characters I output in the class member
> variable d_numchars. I do this by initially printing to the "out"
> > buffer (see above code) with the vsprintf() function and then using the
> strlen() function to find out how long the out string is.
> >
> > It works for a while, perhaps 200-300 packets and then crashes with a
> segfault and error 7. I know the crash is related to the number of output
> items because if I reduce the number of characters I output it will run for
> longer. If I don't output anything its fine, but not very useful.
> >
> > It gets complicated because the block outputs nothing at all until it
> decodes a packet, then it outputs that entire packet, which might be up to
> 1000 characters or so.
> >
> > I think I have made a fundamental error somewhere. Finding it is proving
> problematic. I am also confused by ninput_items and noutput_items variables
> as to me they appear reversed but that is how they are in the tutorial.
> >
> >
> > Mike
> >
> >
> > ___
> > 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] gr-ais fails?

[Nick Foster]

Just FYI, I've added the things I needed to add to get gr-ais working
against mainline Gnuradio again. I've tested with USRP1 and N210 and it
works OK here. More testing is of course welcome.

--n

On Tue, Mar 31, 2015 at 6:59 AM, Ralph A. Schmid, dk5ras 
wrote:

> Hey, thanks a lot! I will give it a shot when finished, maybe I will be in
> reach of some ships them again.
>
>
>
> Ralph.
>
>
>
> *From:* discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:
> discuss-gnuradio-bounces+ralph=schmid@gnu.org] *On Behalf Of *Nick
> Foster
> *Sent:* Tuesday, March 31, 2015 3:32 AM
> *To:* Kevin Reid
> *Cc:* GNU Radio Discussion List
> *Subject:* Re: [Discuss-gnuradio] gr-ais fails?
>
>
>
> Yes, this is my fault. I've been catastrophically lazy about removing the
> commits to gr-ais's trunk in order to make it work with mainline GR,
> because I've been hoping things would have been integrated sooner. Tell you
> what, I'll create a branch of gr-ais which just includes the required
> blocks, in-tree, and push that to the trunk until we get all the GR work
> sorted out. It's going to take me some time though.
>
>
>
> --n
>
>
>
> On Mon, Mar 30, 2015 at 6:29 PM, Kevin Reid  wrote:
>
> On Mar 30, 2015, at 9:19, Martin Braun  wrote:
>
> > Did you also clean and rebuild gr-ais?
> >
> > On 29.03.2015 08:53, Ralph A. Schmid, dk5ras wrote:
> [...]
> >> self.preamble_detect = digital.msk_correlate_cc(self.preamble, 0.4,
> >> self._samples_per_symbol)
> >>
> >> AttributeError: 'module' object has no attribute 'msk_correlate_cc'
>
> I hit this myself just recently.
>
> Apparently, trunk gr-ais is “too new”: it requires a block
> gnuradio.digital.msk_correlate_cc, which was proposed but not yet merged:
> https://github.com/gnuradio/gnuradio/pull/376
>
> I, too, would like to use gr-ais and hope this problem gets resolved soon
> (either by gnuradio accepting the patch or gr-ais offering a “stable
> branch”).
>
> --
> Kevin Reid  <http://switchb.org/kpreid/>
>
>
>
> ___
> 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] gr-ais fails?

[Nick Foster]

Yes, this is my fault. I've been catastrophically lazy about removing the
commits to gr-ais's trunk in order to make it work with mainline GR,
because I've been hoping things would have been integrated sooner. Tell you
what, I'll create a branch of gr-ais which just includes the required
blocks, in-tree, and push that to the trunk until we get all the GR work
sorted out. It's going to take me some time though.

--n

On Mon, Mar 30, 2015 at 6:29 PM, Kevin Reid  wrote:

> On Mar 30, 2015, at 9:19, Martin Braun  wrote:
>
> > Did you also clean and rebuild gr-ais?
> >
> > On 29.03.2015 08:53, Ralph A. Schmid, dk5ras wrote:
> [...]
> >> self.preamble_detect = digital.msk_correlate_cc(self.preamble, 0.4,
> >> self._samples_per_symbol)
> >>
> >> AttributeError: 'module' object has no attribute 'msk_correlate_cc'
>
> I hit this myself just recently.
>
> Apparently, trunk gr-ais is “too new”: it requires a block
> gnuradio.digital.msk_correlate_cc, which was proposed but not yet merged:
> https://github.com/gnuradio/gnuradio/pull/376
>
> I, too, would like to use gr-ais and hope this problem gets resolved soon
> (either by gnuradio accepting the patch or gr-ais offering a “stable
> branch”).
>
> --
> Kevin Reid  
>
>
> ___
> 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] Frame Synchronization

[Nick Foster]

This is strange, I agree, but the frame detect sequence is passed into the
Correlate Access Code block as a string, like: "1010101010". It is this way
for historical reasons.

--n

On Wed, Mar 11, 2015 at 12:26 PM, Richard Bell 
wrote:

> Hello,
>
> I'm trying to detect the start of a frame after demodulation. To do this,
> I'm using the 'correlate access code - tag' block. I want a tag to be
> placed at the end of the prbs used to frame sync so subsequent blocks can
> process the packet.
>
> I'm attaching a screenshot of a test I'm doing with the block. I can't get
> it to work. In the screenshot, I am appending a 32 bit long sync frame to
> 320 bits of data for the correlate block to detect. When I make the data
> all 0's, the correlate block detects nothing adding no tags to the stream.
> If I make the data random, tags are added at points in the stream which are
> not equal to the access code.
>
> What am I doing wrong or how do I use this block correctly?
>
> Thanks,
> Rich
>
> ___
> 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] Ais_rx

[Nick Foster]

Possible reasons:

1. Inadequate antenna
2. No line of sight to transmitting ships
3. Incorrect subdevice or antenna specification

--n

On Wed, Mar 4, 2015 at 3:15 AM, Vladimir Musarski 
wrote:

> hello
>
> i'm trying to work with gr-ais gui and after ais_rx runing i have message
> above:
>
> mint@mint ~/src/gr-ais/apps $ ais_rx
>
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-105-g91ae742f
>
>
>
> -- Operating over USB 3.
>
> -- Initialize CODEC control...
>
> -- Initialize Radio control...
>
> -- Performing register loopback test... pass
>
> -- Performing CODEC loopback test... pass
>
> -- Asking for clock rate 32.00 MHz...
>
> -- Actually got clock rate 32.00 MHz.
>
> -- Performing timer loopback test... pass
>
> -- Setting master clock rate selection to 'automatic'.
>
> -- Tune Request: 162.00 MHz
>
> --   The RF LO does not support the requested frequency:
>
> -- Requested LO Frequency: 162.00 MHz
>
> -- RF LO Result: 162.00 MHz
>
> --   Attempted to use the DSP to reach the requested frequency:
>
> -- Desired DSP Frequency: -0.00 MHz
>
> -- DSP Result: -0.00 MHz
>
> --   Successfully tuned to 162.00 MHz
>
> --
>
> Tuned to 162.000MHz
>
> Setting gain to 36
>
> Gain is 36
>
> Rate is 25
>
> Using Volk machine: avx_64_mmx_orc
>
> 
>
> and nothing happened
>
>
>
> do you have some help/sollution for this?
>
> ___
> 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] HDLC Deframer example

[Nick Foster]

Two reasons. First, that random generator is only ever going to generate
one PDU, and it's not going all the way through the deframer for some
reason. I think the deframer is asking for more samples than the framer
ever ends up generating. Try a Message Strobe - Random Delay block, with
the message set to:

pmt.cons(pmt.PMT_NIL, pmt.init_u8vector(4, [0xAA]*4))

Second, the deframer length fields include the HDLC CRC. They probably
shouldn't, in hindsight, but increase the max length to 6 and it'll work.

--n

On Fri, Jan 30, 2015 at 1:21 PM, Thanasis Balafoutis 
wrote:

> Hi,
> I want to run a simple frame-deframe hdlc example.
> In the attached flow-graph the framed packet is printed through the
> "message debug" block. Why I do not receive any message in the output of
> the deframer?
>
> Thank you
> Thanasis
>
>
> ___
> 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] voltage pulse from UHD driver

[Nick Foster]

Nothing. The timing might be a little different -- if it's tuning effects
you're seeing, there's effectively a race condition between tuning and
sample collection. Gnuradio will never discard samples off the front unless
you use a Skip Head block, which you should probably be doing as evidently
you aren't expecting your samples to be tightly synchronized to any
particular point in time.

--n

On Thu, Jan 15, 2015 at 9:46 AM, Anderson, Douglas J. <
dander...@its.bldrdoc.gov> wrote:

>   Okay, this makes sense.
>
>  What about the version I posted on StackExchange where I *am* using GNU
> Radio's scheduler to request the samples?
>
>  What does GNU Radio do when running a constant flowgraph (like uhd_fft)
> that it doesn't to when running topblock.run() for each collection, as far
> as discarding samples off the front?
>
>  -Doug
>   --
> *From:* Nick Foster [bistrom...@gmail.com]
> *Sent:* Thursday, January 15, 2015 10:40 AM
> *To:* Anderson, Douglas J.
> *Cc:* GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] voltage pulse from UHD driver
>
>   In general you cannot use the first few samples of output from an
> acquisition. There are a couple of reasons:
>
>  First, if you begin collecting data immediately (rather than using UHD
> to schedule a collection at a given time) and you are using a daughterboard
> with a downconverter (anything but BasicRX or LFRX), tuning takes some time
> and things will be ugly while PLLs settle, etc.
>
>  Second, there are digital halfband and CIC filters in the USRP, and they
> are not reset between acquisitions. This means that the first samples will
> have some junk left over from the last acquisition.
>
>  Unfortunately, the general answer to what you're trying to do is, don't
> do that.
>
>  Best,
> Nick
>
> On Thu, Jan 15, 2015 at 9:26 AM, Anderson, Douglas J. <
> dander...@its.bldrdoc.gov> wrote:
>
>>  Hi all,
>>
>>  I've been slowly working to understand/isolate an issue with a strange
>> voltage pulse at all freqs and on USRP N210 with 50 Ohm load.
>>
>>  I posted about it on StackExchange here, and there are more details at
>> this link:
>> http://stackoverflow.com/questions/27968237/semi-consistent-voltage-pulse-from-usrp-when-using-simple-gnu-radio-flowgraph
>>
>>  Since then, I've further isolated it as a UHD issue by completely
>> removing the GNU Radio scheduler from the equation and simply using the
>> finite_acquisition function on UHD to pull samples directly into Python.
>>
>>  Here is the code I'm using to produce this output
>> http://i.imgur.com/c3YWA22.png:
>>
>>  An interesting thing is that when using the UHD driver is used outside
>> a flowgraph (uhd.finite_acquisition), I get the strange pulse consistently,
>> whereas when used in a flowgraph it was inconsistent (see the StackExchange
>> question).
>>
>>   import numpy as np
>>  import matplotlib.pyplot as plt
>>
>>   FREQ = 800e6
>>  RATE = 1e6
>>  NSAMPS = 100
>>  usrp = uhd.usrp_source(device_addr="",
>> stream_args=uhd.stream_args('fc32'))
>>  usrp.set_center_freq(FREQ)
>>  usrp.set_samp_rate(RATE)
>>
>>   fig, (freqplot, timeplot) = plt.subplots(2, sharex=True)
>>  freqplot.set_title("Frequency domain")
>>  timeplot.set_title("Time domain")
>>
>>   def plot():
>>  data = np.array(usrp.finite_acquisition(NSAMPS))
>>  shifted_fft = np.fft.fftshift(np.fft.fft(data))
>>  dBm = 20*np.log10(np.abs(shifted_fft)) - 30
>>  freqplot.plot(dBm)
>>  timeplot.plot(np.abs(data))
>>
>>   def run_tb(times=25):
>>  for _ in range(times):
>>  plot()
>>  plt.show(block=False)
>>
>>
>>   *Douglas Anderson** | Intern*
>> DOC/NTIA/ITS-T | 325 Broadway St., Boulder, CO 80305 | P: 303 497 3582
>>
>> ___
>> 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] voltage pulse from UHD driver

[Nick Foster]

In general you cannot use the first few samples of output from an
acquisition. There are a couple of reasons:

First, if you begin collecting data immediately (rather than using UHD to
schedule a collection at a given time) and you are using a daughterboard
with a downconverter (anything but BasicRX or LFRX), tuning takes some time
and things will be ugly while PLLs settle, etc.

Second, there are digital halfband and CIC filters in the USRP, and they
are not reset between acquisitions. This means that the first samples will
have some junk left over from the last acquisition.

Unfortunately, the general answer to what you're trying to do is, don't do
that.

Best,
Nick

On Thu, Jan 15, 2015 at 9:26 AM, Anderson, Douglas J. <
dander...@its.bldrdoc.gov> wrote:

>  Hi all,
>
>  I've been slowly working to understand/isolate an issue with a strange
> voltage pulse at all freqs and on USRP N210 with 50 Ohm load.
>
>  I posted about it on StackExchange here, and there are more details at
> this link:
> http://stackoverflow.com/questions/27968237/semi-consistent-voltage-pulse-from-usrp-when-using-simple-gnu-radio-flowgraph
>
>  Since then, I've further isolated it as a UHD issue by completely
> removing the GNU Radio scheduler from the equation and simply using the
> finite_acquisition function on UHD to pull samples directly into Python.
>
>  Here is the code I'm using to produce this output
> http://i.imgur.com/c3YWA22.png:
>
>  An interesting thing is that when using the UHD driver is used outside a
> flowgraph (uhd.finite_acquisition), I get the strange pulse consistently,
> whereas when used in a flowgraph it was inconsistent (see the StackExchange
> question).
>
>   import numpy as np
>  import matplotlib.pyplot as plt
>
>   FREQ = 800e6
>  RATE = 1e6
>  NSAMPS = 100
>  usrp = uhd.usrp_source(device_addr="",
> stream_args=uhd.stream_args('fc32'))
>  usrp.set_center_freq(FREQ)
>  usrp.set_samp_rate(RATE)
>
>   fig, (freqplot, timeplot) = plt.subplots(2, sharex=True)
>  freqplot.set_title("Frequency domain")
>  timeplot.set_title("Time domain")
>
>   def plot():
>  data = np.array(usrp.finite_acquisition(NSAMPS))
>  shifted_fft = np.fft.fftshift(np.fft.fft(data))
>  dBm = 20*np.log10(np.abs(shifted_fft)) - 30
>  freqplot.plot(dBm)
>  timeplot.plot(np.abs(data))
>
>   def run_tb(times=25):
>  for _ in range(times):
>  plot()
>  plt.show(block=False)
>
>
>   *Douglas Anderson** | Intern*
> DOC/NTIA/ITS-T | 325 Broadway St., Boulder, CO 80305 | P: 303 497 3582
>
> ___
> 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] Max Output Power from the LFTX

[Nick Foster]

On Tue, Jan 6, 2015 at 11:17 AM, Marcus Müller 
wrote:

>  >Is the input impedance of your scope 1Mohm or 50 ohms?
>
> Yes, it is 1 Mohm,
>
>
> Well, in that case, your power consideration is not really correct; the
> LFTX is designed for 50 Ohm load impedance; so, for meaningful
> measurements, you'd have to measure the voltage over 50 Ohm.
> I'm not really sure how much current the opamp on the LFTX is designed to
> source, but I think adding a 50 Ohm load would reduce the current through
> the negative feedback resistors R4/R7 (and in turn reduce the bias over
> R33-R3/R35-R6) , which might change your measurements significantly.
>
>
With a 50ohm term hanging off the other end of a tee, the effective
impedance is 50ohm, so I'd expect to see the rated 7dBm or so coming out of
his setup.

Just for reference, I'm currently getting 5mW (7dBm, 700mV P-P) out of an
LFTX into a 50 ohm load for another project.

--n


> Greetings,
> Marcus
>
>
> On 01/06/2015 08:09 PM, khalid.el-darymli wrote:
>
> Yes, it is 1 Mohm, and my probe is set to 1X.
>
>  Khalid
>
>
> On Tue, Jan 6, 2015 at 3:33 PM, Nick Foster  wrote:
>
>> Is the input impedance of your scope 1Mohm or 50 ohms? You sure you have
>> the voltage multiplier (1x/10x) set correctly?
>>
>>  On Tue, Jan 6, 2015 at 11:01 AM, khalid.el-darymli <
>> khalid.el-dary...@mun.ca> wrote:
>>
>>>   >> Trying setting a gain in your sink block of, let's say, 20dB, with
>>> a magnitude of 0.9.  What power output do you get?   How are you measuring
>>> power?
>>>
>>>  This gives me 23.2 mV (peak to peak). This is the reading I get from a
>>> scope connected to a T. For the input ends of the T, one end is connected
>>> to a 50-ohm terminator and the other end is connected to the output from
>>> LFTX. This gives a power of: 30+10 log_10[{23.2e-03/[2*sqrt(2)]}^2/50]=
>>> *-28.711* dBm.
>>>
>>> >> What is your flow-graph actually doing?  Have you tried both
>>> connectors on the LFTX?
>>>
>>>  Simple, a signal source (Sine) block directly connected to a USRP Sink
>>> block.
>>>  Yes, both connectors on the LFTX daughterboard give the same voltage
>>> reading.
>>>
>>>  Thanks,
>>>  Khalid
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jan 6, 2015 at 2:34 PM, Marcus D. Leech 
>>> wrote:
>>>
>>>>
>>>> >> Output power is determined largely by baseband signal magnitude in
>>>> that case.
>>>>  Yes, I understand. And I noticed that for baseband signal with an
>>>> amplitude *> 1, * the pass-band signal gets clipped off. So I assume
>>>> that an amplitude of 1 for the baseband signal should deliver the maximum
>>>> output power (for the pass-band signal).
>>>>
>>>>  My question was, what is the maximum power one can get for the
>>>> pass-band signal output from LFTX? In your earlier reply, you said it is
>>>> around +7dBm, am I getting this right? In my case, for a baseband amplitude
>>>> of around 1, I am only getting *-28.13dBm*, much less than what you
>>>> said, I am not sure,* why?*
>>>>
>>>>  Thanks,
>>>>  Khalid
>>>>
>>>>   For a magnitude of ~1, you should see maximum amplitude signals
>>>> coming out of it.
>>>>
>>>> You could try setting gain, but on any platforms with VGAs in the DAC,
>>>> there's only about 6dB of gain range settable.  Trying setting a gain in
>>>> your
>>>>   sink block of, let's say, 20dB, with a magnitude of 0.9.  What power
>>>> output do you get?   How are you measuring power?  What is your flow-graph
>>>>   actually doing?  Have you tried both connectors on the LFTX?
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech 
>>>> wrote:
>>>>
>>>>>   Thanks Marcus for your reply.
>>>>>
>>>>> >> Probably somewhere in the neighborhood of +7dBm, maybe a little
>>>>> more.
>>>>>
>>>>>  >> The LF/BASIC series have *no* gain in either path, so you're just
>>>>> looked
>>>>> at buffered ADC ouput.
>>>>>
>>>>> So, ~ *+7dBm* is the max output power I supposed to get from the LFTX
>>>>> daughterboard? 

Re: [Discuss-gnuradio] Max Output Power from the LFTX

[Nick Foster]

Is the input impedance of your scope 1Mohm or 50 ohms? You sure you have
the voltage multiplier (1x/10x) set correctly?

On Tue, Jan 6, 2015 at 11:01 AM, khalid.el-darymli  wrote:

> >> Trying setting a gain in your sink block of, let's say, 20dB, with a
> magnitude of 0.9.  What power output do you get?   How are you measuring
> power?
>
> This gives me 23.2 mV (peak to peak). This is the reading I get from a
> scope connected to a T. For the input ends of the T, one end is connected
> to a 50-ohm terminator and the other end is connected to the output from
> LFTX. This gives a power of: 30+10 log_10[{23.2e-03/[2*sqrt(2)]}^2/50]=
> *-28.711* dBm.
>
> >> What is your flow-graph actually doing?  Have you tried both connectors
> on the LFTX?
>
> Simple, a signal source (Sine) block directly connected to a USRP Sink
> block.
> Yes, both connectors on the LFTX daughterboard give the same voltage
> reading.
>
> Thanks,
> Khalid
>
>
>
>
>
>
>
>
>
>
> On Tue, Jan 6, 2015 at 2:34 PM, Marcus D. Leech  wrote:
>
>>
>> >> Output power is determined largely by baseband signal magnitude in
>> that case.
>>  Yes, I understand. And I noticed that for baseband signal with an
>> amplitude *> 1, * the pass-band signal gets clipped off. So I assume
>> that an amplitude of 1 for the baseband signal should deliver the maximum
>> output power (for the pass-band signal).
>>
>>  My question was, what is the maximum power one can get for the pass-band
>> signal output from LFTX? In your earlier reply, you said it is around
>> +7dBm, am I getting this right? In my case, for a baseband amplitude of
>> around 1, I am only getting *-28.13dBm*, much less than what you said, I
>> am not sure,* why?*
>>
>>  Thanks,
>>  Khalid
>>
>>   For a magnitude of ~1, you should see maximum amplitude signals coming
>> out of it.
>>
>> You could try setting gain, but on any platforms with VGAs in the DAC,
>> there's only about 6dB of gain range settable.  Trying setting a gain in
>> your
>>   sink block of, let's say, 20dB, with a magnitude of 0.9.  What power
>> output do you get?   How are you measuring power?  What is your flow-graph
>>   actually doing?  Have you tried both connectors on the LFTX?
>>
>>
>>
>>
>> On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech 
>> wrote:
>>
>>>Thanks Marcus for your reply.
>>>
>>> >> Probably somewhere in the neighborhood of +7dBm, maybe a little more.
>>>
>>>  >> The LF/BASIC series have *no* gain in either path, so you're just
>>> looked
>>> at buffered ADC ouput.
>>>
>>> So, ~ *+7dBm* is the max output power I supposed to get from the LFTX
>>> daughterboard? How do I get that?
>>>
>>>  Since I am only getting -28.13 dBm, does that mean I have some issue
>>> with my LFTX daughterboard?
>>>
>>>
>>>  Khalid
>>>
>>>
>>>Output power is determined largely by baseband signal magnitude in
>>> that case.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Message: 2
>>> Date: Tue, 6 Jan 2015 10:13:45 -0330
>>> From: "khalid.el-darymli" 
>>> To: "Discuss-gnuradio@gnu.org" 
>>> Subject: [Discuss-gnuradio] Max Output Power from the LFTX
>>> daughterboard
>>> Message-ID:
>>> >> 5GQr0y=wksequrcajrtuv5...@mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hi,
>>>
>>> What is the maximum output power from the LFTX daughterboard when used
>>> with
>>> the USRP N200?
>>>
>>> According to this datasheet [1], the N200 with the WBX daughterbaord
>>> provide an output power of 15 dBm. However, when using the LFTX
>>> daughterboard, I am getting a much less output power.
>>> [1]
>>> http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf
>>>
>>> In GNU Radio with the USRP N200, we use a sinusoid with a frequency of
>>> 150
>>> kHz and an amplitude of 0.98, fed into the LFTX daughterboard for a
>>> center
>>> frequency of 5 MHz. When the output of LFTX is plugged into a scope
>>> terminated with a 50-ohm terminator, the scope reads 24.8 mV
>>> (peak-to-peak). This is around -28.13 dBm.
>>>
>>> Is this the max power one can get out of the LFTX daughterboard?
>>>
>>>
>>> Thanks.
>>>
>>> Best regards,
>>> Khalid
>>> -- next part --
>>> An HTML attachment was scrubbed...
>>> URL: <
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150106/37846ff4/attachment.html
>>> >
>>>
>>> --
>>>
>>> Message: 3
>>> Date: Tue, 06 Jan 2015 08:48:08 -0500
>>> From: "Marcus D. Leech" 
>>> To: discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnuradio] Max Output Power from the LFTX
>>> daughterboard
>>> Message-ID: <54abe798.5060...@ripnet.com>
>>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>>
>>> On 01/06/2015 08:43 AM, khalid.el-darymli wrote:
>>> > Hi,
>>> >
>>> > What is the maximum output power from the LFTX daughterboard when used
>>> > with the USRP N200?
>>> >
>>> > According to this datasheet [1], the N200 with the WBX daughterbaord
>>> > provide an output power of 15 dBm. However, when using the LFTX
>>> > dau

Re: [Discuss-gnuradio] Correlate and sync matched filter: pitfall and another bug (Re: Question on threshold mathematics in correlate_and_sync block)

[Nick Foster]

On Mon, Jan 5, 2015 at 5:00 AM, Andy Walls 
wrote:

> On Fri, 2015-01-02 at 09:56 -0800, Nick Foster wrote:
>
>
> > I'm in the middle of generalizing correlate_and_sync_cc to allow use
> > with any candidate vector you want (although I hadn't considered the
> > real-only case).
>
> > --n
>
> Hi Nick,
>
> Since you're reworking the correlate and sync block, I thought you might
> want to address some additional things I've found regarding the matched
> filter generation. I've noticed 1 end-user pitfall that you may want to
> document and 1 bug in how the matched filter is generated.
>

Great! Thanks!


>
> 1. Pitfall: The pulse filter tap specification requirments are not
> obvious.  In my experimentation over the weekend, the pulse filter taps
> have to be generated assuming a rate of:
>
> nfilts samples/symbol, or equivalently
> (nfilts * symbol_rate) samples/second
>
> where
>
> nfilts is the number of filters in the polyphase resampler
> symbol_rate is the symbol rate in symbols/second
>
> regardless of the user's "sps" (samples/symbol) value.
>
> This is certainly the case for the real rectangular pulse with no ISI
> and real half-sinusoid pulse with no ISI, with which I was playing.
>
> So, if nfilts = 32, these are my proper pulse filter taps specifications
> in python:
>
> rectangular:   [1.0]*nfilts
> half-sinusoid: [math.sin(math.pi*float(i)/float(nfilts)) for i in
> range(nfilts)]
>
> even though my sps = 13..
>
> This was very non-intuitive and should be documented for the end-user.
>

Yeah, this annoyed me, too. The new system actually takes in unmodulated
symbols, modulates them with the modulator of your choice, and then applies
the (non-polyphase) filter taps of your choice to the modulated symbols.
This way, you can pass the same symbols into (for instance) a GMSK
modulator with the shaping filter taps set to [1] since GMSK typically
needs no additional post-modulation filter, a PSK modulator with RRC taps
for the channel, etc. The correlate_and_sync block in my branch doesn't
take in symbols, but bits, and lets a modulator block (passed into it as an
argument) handle the modulating. I'm avoiding the polyphase filter because
I don't have to do resampling in the correlate_and_sync block. The caveats
are:

1) Every digital modulator in GNURadio seems to use its own input data
format -- packed or unpacked bits, signed vs. unsigned, NRZ or straight
binary, etc. Your input vector has to be constructed to match the format
the modulator expects.
2) Many of the modulators don't support fractional samples per symbol.
There are of course workarounds, but I consider this a bug.


>
>
>
> 2. Bug:  The generated matched filter appears to be short a symbol.
> Using my real variant of correlate_and_sync, I specified the following:
>
> symbols:   [1,0]*10 + [1,0,1,1,1,1]   (block converts
> these to NRZ)
> pulse filter taps: [math.sin(math.pi*float(i)/float(32)) for i in
> range(32)]
> samples/symbol:13.33
> nfilts:32
>
> and the block generates the matched filter in the attached PNG.  The
> missing final symbol from the start of the filter is obvious.  Since my
> block is a very closely cut-and-paste clone of
> correlate_and_sync_impl.cc and msk_correlate_impl.cc, the bug probably
> exists in them as well.
>

Pretty sure my changes have obviated this bug but I'll check it out.

My branch has bugs right now (mostly in tag alignment) but you can see it
at https://github.com/bistromath/gnuradio/tree/msk_from_master. Suggestions
and improvements of course welcome. Seems to me that we should collaborate
on this, using my branch as a starting point. Still need to redo the test
case and example, too. Attached is a working example showing the
misalignment. Probably something simple but I was pulled away from working
on it this weekend.

--n


>
>
> Regards,
> Andy
>


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

Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block

[Nick Foster]

>
>
>
> Hi Tom,
>
>
> > Andy,
> >
> >
> > Thanks for the reports and details. I can definitely see the problem
> > with the situation you're describing. We obviously weren't considering
> > that case when we designed the block. We were really expecting any
> > preamble/access code that we were using would have good
> > autocorrelation statistics. From that perspective, the 10101...
> > pattern is pretty silly, but hey, it is used.
>
> Yeah.
>
> > Right now, you're probably best off redoing your own block as you say
> > to deal with the specifics of your case. However, I'd like us to think
> > about how we can abstract this concept within the current block so
> > that we can more easily provide the behavior we'd like to see, such as
> > the correlation and detection logic, and the filter design. I know
> > Nick Foster has thoughts on this, too, with his work on GMSK signals.
>
> Yes, I leveraged Nick's msk_correlate_and_sync as well. :)
>
> For visualizing the scenario I mentioned, see the attached "Clock
> pattern correlation.png".  I took the "corr" output of my custom block
> and plotted its abs() along with the baseband input. My custom block
> picked the two large positive correlation peaks and ignores the nearby
> negative ones.  With my particular real, baseband input, I'm guaranteed
> not to have any sign ambiguity in the baseband input; so I could ignore
> that wrinkle.
>
> There is another problem which prevents proper correlation: the end of
> work coming mid-burst.  See the attached "End of work mid-corr.png"
> which shows an end of work tag with the value of noutput_items.  I'm not
> sure how to handle this is the general case, except for burst energy
> detection.  But burst energy detection won't work for CDMA-like things,
> where the signal might be buried in the noise.
>

I'm in the middle of generalizing correlate_and_sync_cc to allow use with
any candidate vector you want (although I hadn't considered the real-only
case). It's working now, and just this morning I encountered the same thing
you're seeing. Of interest to me is the loop:

<...>
d_filter->filter(noutput_items, in, corr);
<...>
int i = d_sps;
while(i

...with set_history(d_filter->ntaps()) in the constructor, we should
probably be running the filter against the entire input vector
*including* history,
and copying to the output the part relevant to the current work call. Or,
only running the work function up to (noutput_items - d_filter->ntaps())
items. Right?

--n


>
> Regards,
> Andy
>
>
>
> ___
> 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] Building BOOT.BIN for Zedboard to use with gnuradio-dev-image

[Nick Foster]

On Tue, Dec 9, 2014 at 11:21 AM, Nowlan, Sean 
wrote:

> >On 12/09/2014 12:16 PM, Nick Foster wrote:
> >> A number of different distributions include a u-boot.elf suitable for
> >> the Zedboard. I'm not a linux boot expert, but u-boot seems pretty
> >> platform-agnostic when paired with a suitable FSBL.
>
> A lot of u-boots I've found point to a ramdisk filesystem instead of a
> partition.
>

That option should be pulled in from the devicetree, at least for sane
u-boots! The one I linked appears to be a sane u-boot.


> >>
> >> The images here include a u-boot.elf that works with Zedboard, ZC702,
> >> ZC706, etc.
> >> http://wiki.analog.com/resources/tools-software/linux-software/zynq_im
> >> ages
> >>
> >> Email me directly and I'll just send you the .elf if you're interested.
>
> >A pox on people using ancient stuff.
> >I think Sean wants to load an fpga image early in the boot process.
>

Hey, if it loads the kernel and FPGA it does everything I need it to do.
The linked one is used in ADI's FMCOMMS distro and loads an FPGA image
before the kernel boots, if you put the bitfile into the compiled boot.bin
created by the Xilinx SDK.

Is there anything a newer u-boot buys me? If so I'll go through the legwork
of rebuilding from recent sources. If not I'll keep on keepin' on. ;)

--n


>
> Not trying to do anything fancy; just trying to reproduce Jonathan
> Pendlum's FFT filter example, which was written back when that ancient
> stuff was current. I think it'd be good for that to be updated for people
> who want to run GNU Radio on Zynq. I know RFNoC will change how that's done
> with E310, but we don't need RFNoC for MicroZed/ZedBoard/ZC70x. I'm happy
> to help with the writeup if/when I figure all this out.
>
> >Try the image I posted a few days ago and drop a file called fpga.bin in
> the FAT partition. U-boot SPL will load that fpga.bin file then load u-boot.
> >You can now build the fsbl directly from u-boot but dropping the ps7*
> files in the right place. (See the OE recipe for how that is done there,
> and copy if you are building u-boot from Xilinx git)
>
> I'll try your newer image.
>
> >My understanding is the current release of Xilinx tools will give you
> >ps7 files with a license that is compatible with the GPL.
>
> >Philip
>
> >>
> >> --n
> >>
> >> On Tue, Dec 9, 2014 at 7:27 AM, Nowlan, Sean
> >> 
> >> wrote:
> >>
> >>>  I'd like to use the gnuradio openembedded SDK and image that are
> >>> available here [1] to reproduce the work here [2] without building my
> >>> own openembedded image. I'm having trouble getting a working boot.bin
> >>> for Zedboard without doing a full openembedded build. I know that
> >>> there are licensing issues that may prohibit distributing an FSBL
> >>> file, but I've gone ahead and done that using the directions in [2].
> >>> I'd like to compile boot.bin with the zynq_fsbl.bit I created with
> >>> Xilinx 14.6, uImage, and the device tree binary distributed in [1].
> >>> However, in order to use the build script in zynq-acp, I need
> >>> u-boot.elf, and [1] only provides u-boot.bin. Is there another way to
> compile these without doing a full openembedded build?
> .>>
> >>>
> >>>
> >>> [1]  http://gnuradio.org/data/sdk/zedboard_armv7a-sf-vfp-neon/
> >>>
> >>> [2]  http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq
> >>>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Sean
> >>>
> >>> ___
> >>> 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] Building BOOT.BIN for Zedboard to use with gnuradio-dev-image

[Nick Foster]

A number of different distributions include a u-boot.elf suitable for the
Zedboard. I'm not a linux boot expert, but u-boot seems pretty
platform-agnostic when paired with a suitable FSBL.

The images here include a u-boot.elf that works with Zedboard, ZC702,
ZC706, etc.
http://wiki.analog.com/resources/tools-software/linux-software/zynq_images

Email me directly and I'll just send you the .elf if you're interested.

--n

On Tue, Dec 9, 2014 at 7:27 AM, Nowlan, Sean 
wrote:

>  I’d like to use the gnuradio openembedded SDK and image that are
> available here [1] to reproduce the work here [2] without building my own
> openembedded image. I’m having trouble getting a working boot.bin for
> Zedboard without doing a full openembedded build. I know that there are
> licensing issues that may prohibit distributing an FSBL file, but I’ve gone
> ahead and done that using the directions in [2]. I’d like to compile
> boot.bin with the zynq_fsbl.bit I created with Xilinx 14.6, uImage, and the
> device tree binary distributed in [1]. However, in order to use the build
> script in zynq-acp, I need u-boot.elf, and [1] only provides u-boot.bin. Is
> there another way to compile these without doing a full openembedded build?
>
>
>
> [1]  http://gnuradio.org/data/sdk/zedboard_armv7a-sf-vfp-neon/
>
> [2]  http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq
>
>
>
> Thanks,
>
> Sean
>
> ___
> 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] HDLC framer

[Nick Foster]

I wrote the HDLC framer to use PMT blobs (specifically, PMT pairs with a
length field and a blob) because it seemed that was the convention we were
settling upon in GR to handle binary messages. I'm unaware if there was any
formal specification or agreement to this format.

To clarify, the missing feature is just dealing with blobs that aren't a
multiple of 8 bits in length. To do so would probably require changing the
length field to represent nbits instead of nbytes, and using a padding
convention (msbit or lsbit) to determine which bits in the last byte of the
blob should be included.

I haven't seen too many (len%8) HDLC frames out there so I never got down
to putting that in there. The deframer would also have to be modified,
specifically crc_ccitt().

--n

On Thu, Dec 4, 2014 at 8:25 AM, Marcus Müller 
wrote:

> Hi Daniel,
> the HDLC framer can only deal with messages containing PMTs that are
> "blobs", ie. u8vectors.
> In fact, that's a missing feature:
> pmt::pmt_t len(pmt::car(msg)); //TODO for non-mult-8 nbits
> pmt::pmt_t blob(pmt::cdr(msg));
> if(!pmt::is_blob(blob))
> throw std::runtime_error("HDLC framer: PMT must be blob");
>
> Instead of making a pmt.intern("String"), you will need to have a
> u8vector. It's a bit ugly to generate that in single line:
>
> pmt.pmt_to_python.numpy_to_uvector(numpy.array([ord(c) for c in "Hello
> World"], numpy.uint8))
>
> you might need to add an "import block" that does an "import numpy".
>
> Greetings,
> Marcus
>
> On 12/04/2014 11:52 AM, Daniel Batista wrote:
> > Thank you Marcus,
> > I try the following:
> > MessageStrobe("Hello World") > HDCL framer >HDLC deframer >
> Message Debug
> > and I get the following error message:thread[thread-per-block[2]:  hdlc_framer_pb (1)>]: pmt_car: wrong_type : Hello World!
> > What did I do wrong?
> > Daniel
> >
> >
> >
> >  On Wednesday, December 3, 2014 10:55 AM, Marcus Müller <
> marcus.muel...@ettus.com> wrote:
> >
> >
> >  Hi Daniel,
> >
> > PMT is short for "polymorphic type" [1].
> > GNU Radio uses PMTs for stream tags and, more importantly here, for
> > asynchronous message ports.
> > So the idea is that you have a source of messages[2], sending your
> > data to the HDLC framer, which frames it and generates output items.
> > If you want some illustrated guide through these concept, I'd
> > recommend the new guided tutorials on gnuradio.org[3] numbers 1 through
> 5.
> >
> > Greetings, and happy hacking,
> > Marcus
> >
> > [1] http://gnuradio.org/doc/doxygen/page_pmt.html
> > [2] http://gnuradio.org/doc/doxygen/page_msg_passing.html
> > [3] http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
> >
> > On 12/02/2014 10:47 AM, Daniel Batista wrote:
> >> Hi, I read in the documentation that HDLC framer takes in PMT
> >> binary blobs and outputs HDLC frames as unpacked bits.I don't
> >> undestand what are the PMT binary blobs.How can I put in an HDLC
> >> frame a "Hello World" message? ThanksDaniel
> >>
> >>
> >>
> >>
> >> ___ 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] Works with GR 3.6, breaks with 3.7

[Nick Foster]

Red face over here.

There was a bug in correlate_access_code_tag -- which only gr-smartnet and
gr-ais use, so far as I know. The fix was pulled into master a couple of
days ago. This could explain the discrepancy you're seeing in the preamble
mark.

Pull latest GR master, build, and see if it fixes what you're seeing.

--n

On Tue, Nov 4, 2014 at 5:19 PM, Andy Walls 
wrote:

> On Mon, 2014-11-03 at 22:13 -0500, Luke Berndt wrote:
> > Thanks Andy! Good catch - I made the changes you suggested. I was just
> > doing a simple back of the envelope calculation to come up with
> > channel size. It does look like cleans things up and adding the
> > waterfall graphs does make it easier to see. Unfortunately, it does
> > seem to change the decoding. I am still getting the same amount of CRC
> > errors.
> >
> > Did the overall signal look right, like something that should be
> decodable?
>
> So I put the output of the FLL into a quad demod block and compared its
> output to the PLL Freq det output.  They are pretty much in line, except
> the quadrature demod block output shows occasional burst of noise for a
> few symbol times where the transmission must have stopped and restarted.
> The PLL freq detect block just makes something up during these times.
> So that seems generally OK.
>
>
>
> > Anything else I should try?
>
> Your PLL freq detector block output is swinging between -2 and 2.  You
> might want to reduce the max and min freq by a factor of 2, so that the
> clock recovery block sees inputs limited to +/- 1.0.  See Nick's
> recommendation here:
> http://lists.gnu.org/archive/html/discuss-gnuradio/2014-10/msg00473.html
>
> So after i did that, what I really noticed is that the correlator is
> just not marking preambles properly.  See the top plot of the attached
> to window shots:  Preamble_marked_late_twice.png and
> Preamble_marked_early.png
>
> If the deinterleaver and/or crc block isn't searching around for where
> the preamble really is, well that would explain it.
>
> Regards,
> Andy
>
> >  - Luke
> >
> > >
> > > Hi Luke,
> > >
> > > I have not built the SmartNet blocks yet, but:
> > >
> > > Your low pass filter looks way too wide and you'll get aliases when you
> > > decimate by 185.  2 Msps / 185 = 10.81 ksps, so the Nyquist frequency
> is
> > > 5.405 kHz.  I winged this is as a low pass filter and things looked
> > > better:
> > >
> > > firdes.low_pass_2(1, samp_rate, 4500, 1000, 60, firdes.WIN_HANN, 6.76)
> > >
> > > The 60 dB down may be overkill, you can make it smaller for a filter
> > > with less delay.
> > >
> > > I found an offset slider value of -15k made things look about centered
> > > manually.
> > >
> > > You might want to put a waterfall sink before and after the FLL
> > > Band-Edge filter to observe how it is making the spectrum wobble around
> > > a little. If you change your offset slider, you can see the FLL
> > > band-edge filter centering things back up; so that looks like it is
> > > working.
> > >
> > > Regards,
> > > Andy
> > >
> >
>
>
> ___
> 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] Works with GR 3.6, breaks with 3.7

[Nick Foster]

Tom changed it to use the fir_filter_with_buffer vs. the standard
fir_filter internally, but as the taps remain the same I'd imagine it to be
more or less numerically identical.

First step I think is to verify that the FLL is actually the problem -- get
a scope on the output of the FLL and see that your FSK signal is more or
less at baseband.

--n

On Sat, Oct 18, 2014 at 8:57 AM, Luke Berndt  wrote:

> Thanks! I clearly have a lot of RF theory to read up on.
>
> The Band Edge FLL works great for me too, on 3.6. Does anyone know if
> there were changes to it or surrounding blocks in 3.7 that would make it
> stop working?
>
> I have a pretty strong, clean signal.
>
> Sent from my iPhone
>
> On Oct 18, 2014, at 11:00 AM, Nick Foster  wrote:
>
> Figured I'd chime in since I wrote the code in question. The band edge FLL
> is probably the wrong thing to use, but it did work surprisingly well for
> my local setup (at very high SNR), so I left it in. The square-and-FFT
> block works great for MSK, but Smartnet isn't MSK, it's FSK, and its lack
> of phase coherence (and variable deviation) mean you won't see those nice
> 1/2-bitrate FFT spikes.
>
> As Andy points out, the "right" answer is to correlate against the
> modulated preamble and develop phase, frequency, and timing estimates from
> the known preamble.
>
> --n
>
>
> On Oct 18, 2014 6:41 AM, "Andy Walls"  wrote:
>
>> On Fri, 2014-10-17 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
>> wrote:
>>
>> > Message: 33
>> > Date: Fri, 17 Oct 2014 07:37:25 -0700
>> > From: John Malsbury 
>> > To: Luke Berndt 
>> > Cc: "Discuss-gnuradio@gnu.org List" 
>> > Subject: Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
>> > Message-ID:
>> >   > agfz1rxekc7nav+xzimzqv...@mail.gmail.com>
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > Also, my understanding for the PLL blocks were that they were ideal for
>> > "strong carrier" signals like AM.  When I say strong carrier i mean a
>> > signal that has an obvious carrier which isn't "hidden" under
>> modulation..
>>
>> John and Luke,
>>
>> Yup.  GMSK doesn't have any narrow and strong spectral feature on which
>> one can lock a PLL.  (And the band-edge FLL is the wrong thing to use
>> too.)
>>
>> You can however get a spectral feature from the square of the GMSK
>> signal.  *Assuming* you have an approximately random bit stream,
>> squaring the GMSK signal gives you spectral peaks at f_c +/- f_b/2,
>> where f_c is the center frequency and f_b is your bit rate.  See the
>> attached "GMSK_squared_spectrum.png" which shows the spectra from a
>> random bit stream.
>>
>> So you can get a non-data-aided coarse frequency correction doing
>> essentially what older versions of gr-ais did.  See the attached
>> "square_and_fft_freq_sync.grc.png".  The gr-ais "freqest" block is the
>> only non-stock gnuradio block and it just walks the FFT looking for the
>> spectral peaks at +/- f_b/2 and outputs a frequency correction values
>> based on how many FFT bins the peaks are offset from the expected center
>> frequency.
>>
>> The major tradeoff is the length of the FFT:
>> 1. More FFT points gives you finer resolution bins and a finer
>> correction.
>> 2. More FFT points protects against pathological data sequences (e.g. a
>> long run of 0's) that give different spectral peaks which screw up the
>> correction.
>> 3. Fewer FFT points ensures the start and end of bursts get the proper
>> correction as the correction reacts faster to the transition from
>> dead-air to modulated signal.
>> 4. Fewer FFT points ensures faster reaction to changes in frequency
>> offset.
>>
>>
>> Although, if you have a known preamble to inspect, data-aided carrier
>> frequency offset correction is way better than the above non-data-aided
>> stuff.
>>
>> Regards,
>> Andy
>>
>> > Anyway, the GMSK block might be a good place to start.
>> >
>> > -John
>> >
>> > On Fri, Oct 17, 2014 at 7:35 AM, John Malsbury <
>> jmalsbury.perso...@gmail.com
>> > > wrote:
>> >
>> > > It doesn't have frequency correction - I can probably follow up with
>> some
>> > > ideas on how to implement that part.  But the GMSK demod might do OK
>> for
>> > > you initially.  It doesn't do anything intelligent to deal with the
>> da

Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7

[Nick Foster]

Figured I'd chime in since I wrote the code in question. The band edge FLL
is probably the wrong thing to use, but it did work surprisingly well for
my local setup (at very high SNR), so I left it in. The square-and-FFT
block works great for MSK, but Smartnet isn't MSK, it's FSK, and its lack
of phase coherence (and variable deviation) mean you won't see those nice
1/2-bitrate FFT spikes.

As Andy points out, the "right" answer is to correlate against the
modulated preamble and develop phase, frequency, and timing estimates from
the known preamble.

--n


On Oct 18, 2014 6:41 AM, "Andy Walls"  wrote:

> On Fri, 2014-10-17 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:
>
> > Message: 33
> > Date: Fri, 17 Oct 2014 07:37:25 -0700
> > From: John Malsbury 
> > To: Luke Berndt 
> > Cc: "Discuss-gnuradio@gnu.org List" 
> > Subject: Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
> > Message-ID:
> >agfz1rxekc7nav+xzimzqv...@mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Also, my understanding for the PLL blocks were that they were ideal for
> > "strong carrier" signals like AM.  When I say strong carrier i mean a
> > signal that has an obvious carrier which isn't "hidden" under
> modulation..
>
> John and Luke,
>
> Yup.  GMSK doesn't have any narrow and strong spectral feature on which
> one can lock a PLL.  (And the band-edge FLL is the wrong thing to use
> too.)
>
> You can however get a spectral feature from the square of the GMSK
> signal.  *Assuming* you have an approximately random bit stream,
> squaring the GMSK signal gives you spectral peaks at f_c +/- f_b/2,
> where f_c is the center frequency and f_b is your bit rate.  See the
> attached "GMSK_squared_spectrum.png" which shows the spectra from a
> random bit stream.
>
> So you can get a non-data-aided coarse frequency correction doing
> essentially what older versions of gr-ais did.  See the attached
> "square_and_fft_freq_sync.grc.png".  The gr-ais "freqest" block is the
> only non-stock gnuradio block and it just walks the FFT looking for the
> spectral peaks at +/- f_b/2 and outputs a frequency correction values
> based on how many FFT bins the peaks are offset from the expected center
> frequency.
>
> The major tradeoff is the length of the FFT:
> 1. More FFT points gives you finer resolution bins and a finer
> correction.
> 2. More FFT points protects against pathological data sequences (e.g. a
> long run of 0's) that give different spectral peaks which screw up the
> correction.
> 3. Fewer FFT points ensures the start and end of bursts get the proper
> correction as the correction reacts faster to the transition from
> dead-air to modulated signal.
> 4. Fewer FFT points ensures faster reaction to changes in frequency
> offset.
>
>
> Although, if you have a known preamble to inspect, data-aided carrier
> frequency offset correction is way better than the above non-data-aided
> stuff.
>
> Regards,
> Andy
>
> > Anyway, the GMSK block might be a good place to start.
> >
> > -John
> >
> > On Fri, Oct 17, 2014 at 7:35 AM, John Malsbury <
> jmalsbury.perso...@gmail.com
> > > wrote:
> >
> > > It doesn't have frequency correction - I can probably follow up with
> some
> > > ideas on how to implement that part.  But the GMSK demod might do OK
> for
> > > you initially.  It doesn't do anything intelligent to deal with the
> data
> > > shaping - its just a non-coherent slicer.
> > >
> > > If you want to design in GRC but keep your top-level application as is,
> > > you can use a hier block.  You can also use a command line parameter or
> > > other mechanism to select your demodulator at start-time for easy
> > > comparisons.
> > >
> > > [typed one handed.. my daughter has my other and]
> > >
> > > -John
> > >
> > > On Fri, Oct 17, 2014 at 7:08 AM, Luke Berndt 
> wrote:
> > >
> > >> Thanks for looking into it! To be honest, I am not really good at RF.
> I
> > >> based my code off the python code in gr-smartnet. The fsk-demod
> python file
> > >> is here:
> > >>
> https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py
> > >>
> > >> It is quite possible that it just happened to work because of an error
> > >> that got patched in Gr 3.7.
> > >>
> > >> Are there some good examples for GMSK/FSK demodulation that I could
> > >> borrow from instead?
> > >>
> > >> Recreating this in GRC sounds like a great idea so I can scope along
> the
> > >> way. I will give that a try next.
> > >>
> > >> Thanks again for the pointers, fresh eyes are really helpful when you
> > >> have been staring at it for so long.
> > >>
> > >>  - Luke
> > >>
> > >> On Fri, Oct 17, 2014 at 8:18 AM, Martin Braun  >
> > >> wrote:
> > >>
> > >>> On 10/17/2014 08:28 AM, John Malsbury wrote:
> > >>> > Also also, is the Band-Edge FLL ideal for GMSK?  My possibly,
> incorrect
> > >>> > understanding of that block is that it was more ideal for PAM with
> > >>> > common RRC.
> > >>>
> > >>> For the record: It might work coincident

Re: [Discuss-gnuradio] ADS-B on Mac 10.9 - possible linking error

[Nick Foster]

Awesome, thanks for the report Alan, and thanks Michael for the package.
Happy to incorporate any required changes.

--n
On Sep 23, 2014 3:21 PM, "Alan Woodward" 
wrote:

> Michael, Bastian
>
> Many thanks for your help, the macports method has worked perfectly and I
> now have a working gr-air-modes with the rtl-sdr dongle.
>
> Alan
>
> On 23 Sep 2014, at 10:56, Michael Dickens 
> wrote:
>
> > A few points regarding gr-air-modes on OSX:
> >
> > 0) "ldconfig" does not exist on OSX.  Apple's DYLD manager "does the
> right thing" most of the time without having to be told that new libraries
> are available.  One can tweak the DYLD manager behavior during runtime via
> various DYLD_* variables <
> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html
> > ... I encourage folks to set these variables just for a specific
> execution, e.g,:
> > {{{
> > DYLD_PRINT_LIBRARIES=1 /opt/local/bin/python2.7
> > }}}
> > and so forth.  Setting (e.g.) DYLD_LIBRARY_PATH to always include
> /opt/local/lib is dangerous since generally a library knows which other
> libraries it is linked to and it is those libraries that should be used,
> not some identically named on that might not be ABI compatible.
> >
> > 1) I just added gr-air-modes to MacPorts <
> https://trac.macports.org/changeset/125643 >, with a few patches to get
> things going.  I'll send a pull request to bistromath with the changes.
> This port should be live by around 11 AM US/Eastern this morning. You'll
> want to "sudo port sync" at a minimum; "sudo port selfupdate" is almost
> always better.
> >
> > 2) Because GNU Radio now links on OSX with some @rpath libraries, it's
> wise to set the RPATH too, not just the INSTALL_NAME.
> >
> > ["rpath" == "runtime path"; instead of specifying the exact library
> location, e.g. /opt/local/lib/libfoo.dylib, one uses the runtime path
> instead, e.g., @rpath/libfoo.dylib .  This, in theory, allows the libraries
> using @rpath to be embedded within an application by setting the @rpath to
> be the absolute path to where those libraries are actually located.]
> >
> > The addition is:
> > {{{
> > if(APPLE)
> >if(NOT CMAKE_INSTALL_NAME_DIR)
> >set(CMAKE_INSTALL_NAME_DIR
> >${CMAKE_INSTALL_PREFIX}/${GR_LIBRARY_DIR} CACHE
> >PATH "Library Install Name Destination Directory" FORCE)
> >endif(NOT CMAKE_INSTALL_NAME_DIR)
> >if(NOT CMAKE_INSTALL_RPATH)
> >set(CMAKE_INSTALL_RPATH
> >${CMAKE_INSTALL_PREFIX}/${GR_LIBRARY_DIR} CACHE
> >PATH "Library Install RPath" FORCE)
> >endif(NOT CMAKE_INSTALL_RPATH)
> >if(NOT CMAKE_BUILD_WITH_INSTALL_RPATH)
> >set(CMAKE_BUILD_WITH_INSTALL_RPATH ON CACHE
> >BOOL "Do Build Using Library Install RPath" FORCE)
> >endif(NOT CMAKE_BUILD_WITH_INSTALL_RPATH)
> > endif(APPLE)
> > }}}
> >
> > Hope this helps! - MLD
> >
> > On Sep 23, 2014, at 7:51 AM, Bastian Bloessl 
> wrote:
> >> On 23 Sep 2014, at 13:19, Alan Woodward 
> wrote:
> >>> I am trying to build and use gr_air_modes built from
> https://github.com/bistromath/gr-air-modes.  But the command
> >>>
> >>> sudo ldconfig
> >>>
> >>> is not available on Mac 10.9.5.  When I execute the modes_rx command I
> get the following:
> >>>
> >>> sudo /usr/local/bin/modes_gui
> >>> Traceback (most recent call last):
> >>> File "/usr/local/bin/modes_gui", line 30, in 
> >>>  import air_modes
> >>> ImportError: No module named air_modes
> >>
> >> Python cannot find find the module, so you might have to adapt you
> PYTHONPATH to include the folder where air_modes is installed (something
> like /usr/local/lib/python2.7/site-packages). Then you will most likely run
> into problems with shared libraries that can be fixed like this
> >>
> >>
> https://github.com/bastibl/gr-air-modes/commit/c1379fa5979fadd296e8be03634c1a561384b424
> >>
> >> If you run it and it segfaults assert (with cmake) that you use the
> python libraries from port which are typically installed under /opt/local.
> By default it selects the libs from OS X.
>
>
> ___
> 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] gr-uhd multi_usrp bug in 3.7.4+

[Nick Foster]

Hi,

Looks like either the syntax for instantiating multi_usrp has changed
(seems unlikely), or a bug was introduced, likely in 7/2-7/4's recent
gr-uhd refactoring (1eaa96b, 350d285, fe58537, 3c42e79, 691bdaa). Sorry I
haven't gotten more specific than that. The attached flowgraph, when used
with a USRP1 (yes, I know, I'm probably the only guy using one) returns:

RuntimeError: LookupError: IndexError: multi_usrp: TX channel 1 out of
range for configured TX frontends

Prior to the above commits the error does not occur.

Best,
Nick


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

Re: [Discuss-gnuradio] gr-ais not decoding AIS data

[Nick Foster]

Strange. You have the correct settings. I'll look into that now.

I've been operating gr-ais from a separate branch lately (the "msk"
branch), but it depends on some blocks which I haven't gotten permission to
contribute back upstream yet. Hopefully by GRCon I'll have permission and
can move them into master; the MSK sync blocks help a lot with AIS
performance.

--n


On Tue, Aug 26, 2014 at 3:35 PM, Josh Hattery  wrote:

> Hi,
>
> I've just started poking around with gr-ais on a new Ubuntu 14.04 install.
> I grabbed it from https://github.com/bistromath/gr-ais.git and it
> compiled fine, but when I feed it "ais.dat" from
> http://www.nerdnetworks.org/~bistromath/ais.dat.tar.gz it doesn't output
> any AIS data:
>
> :~$ ais_rx -s Downloads/ais.dat -r 256e3 -g 60
> Using file source Downloads/ais.dat
> Rate is 256000
> Using Volk machine: sse4_2_64_orc
> :~$
>
> The data file looks good as the FFT and Waterfall plots in GRC clearly
> show the recorded AIS data. Is this an issue with the transition to
> gnuradio 3.7?
>
> Cheers,
> Josh
>
> ___
> 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] Unable to log in usrpe 110 to get access to gnuradio on screen?

[Nick Foster]

Wafa,

Try using a USB hub for the mouse instead of plugging it directly into the
E100. E100 is picky about USB and doesn't support USB1.1 devices directly
connected to the ports. This is a Linux HCI driver issue related to OTG
support in the Overo.

It's mentioned in the E100 FAQ:
http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ#What-kind-of-USB-devices-can-I-connect-to-the-my-E1x0-series

--n


On Wed, May 28, 2014 at 6:43 AM, West, Nathan
wrote:

> On Wed, May 28, 2014 at 8:03 AM, Wafa Elhajhmida
>  wrote:
> > Please any suggestion is appreciated.
> >
> > Thanks in advance.
> >
> > Best regards,
> >
> > Wafa HAJ HMIDA
> >
> >
> >
> >
> > 2014-05-28 11:16 GMT+02:00 Wafa Elhajhmida :
> >
> >> Hi,
> >>
> >> I made a reboot of the usrp e110. I got on the screen a button login.
> >>
> >> But I'm unable to login with a mouse. In fact, the mouse doesn't work on
> >> usrp. But the mouse works well on my laptop.
> >>
> >> In fact, I even connected the mouse directly to a usrp e100 with a cable
> >> which is provided by Ettus(on host port).
> >>
> >> According to you what can be the problem ?
> >>
> >> Best regards,
> >>
> >> Wafa HAJ HMIDA
> >>
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
> First of all, your method of asking questions is ineffective. For a
> guide on how to get better help read this:
> http://www.catb.org/esr/faqs/smart-questions.html . I would especially
> like to point you to "Choose your forum carefully" where this
> particular email violates at least 3 (and possibly 4 based on
> perspective) of the first 4 bullet points. There's no need for this to
> be cross-listed to 3 mailing lists, a corporate support account, and 2
> individuals. Also, this e-mail has nothing to do with GNU Radio.
>
> Second, I have no idea why your mouse doesn't work. If it used to
> work, you did something, and now it doesn't work then whatever you did
> probably had a side affect of breaking your mouse.
>
> Finally, based on your previous mailing list posts and irc chats you
> seem overwhelmed. My only real comment here is that you probably need
> more help/support than anyone can give over a mailing list. Perhaps
> you would be better off backing up from your final goal and learning
> more about GNU Radio on a standard PC and then try porting your work
> to an embedded device. Alternatively maybe you could also take some
> time to learn more about embedded systems (there's lots of classes
> on-line and every university should have a couple). It might also help
> if you hired someone to come in and do some work for you and you could
> learn from them on the job.
>
> Nathan
>
> ___
> 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] B200 clock calibration

[Nick Foster]

The ADF4001's output charge pump is tristated when not locking to an
external reference, and a resistor divider holds the VCTCXO's tuning input
at 1/2 Vcc. The B200 hardware can use the AD9361's low-speed DAC to drive
the VCTCXO's tuning input via AUXDAC1 if R118 is populated; however, this
functionality is not supported by the B200 UHD driver.

--n


On Thu, May 15, 2014 at 2:48 AM, Robert Light  wrote:

> Hi, In case we use on-board oscillator , how is ADF4001 configured? Does
> CP (pin20) output affect the VCXO_Tune ? Is it possible to control this
> chip directly from the command line?
>
> ___
> 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] One problem with gr-ais for 3.7 (Re: Recommended gr-ais repo/branch/commit for GnuRadio 3.7.x (latest git) and UHD 3.7.1?)

[Nick Foster]

Thanks for the report. Going to move this one offlist -- have some stuff
for you to try.

--n


On Tue, May 13, 2014 at 8:34 AM, Andy Walls wrote:

>
>
> On Fri, 2014-04-25 at 17:22 -0400, Andy Walls wrote:
> [snip]
> > > On Fri, Apr 25, 2014 at 2:14 PM, Andy Walls
> > >  wrote:
> > > Hi.
> > >
> > > What is the recommended gr-ais repo/branch/commit that yields
> > > a working
> > > gr-ais with GnuRadio 3.7.x (git commit
> > > 3831dd37c8df19e25fa258db4d393ee068889dae)
> > > and the Ettus UHD 3.7.1
> > >
> > > GitHub shows this fork network:
> > > https://github.com/bistromath/gr-ais/network
> > >
> > > Right now I'm using bistromath/gr-ais commit
> > > 754c13ca4f1c3fb0d079d3a42002b0dade2268ff
> > > (master HEAD, IIRC), but I'm not getting *any* !AIVDM output
> > > to the terminal window.
>
> Well, I've identified one problem.
>
> The "unstuff" operation is being applied before the correlator for the
> start flag of 0110 (0x7e).  The start flag, end flag, and preamble
> are not subject to bit stuffing per ITU-R M.1371-4 Annex 2 Sections
> 3.2.2.1 through 3.2.2.4.
>
> I suspect this causes a problem with proper detection of the start of
> the message, as the unstuff, as I understand it, will change the start
> flag from 0110 to 010m, where m is the first bit of the message
> payload.
>
> Putting the unstuff operation after the correlators doesn't fix
> everything though.  All potential message decodes still fail the CRC
> check.
>
> Bypassing the CRC check and inspecting the output !AIVDMs with gpsdecode
> verifies they are junk. :(
>
> Regards,
> Andy
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-air-modes compilation

[Nick Foster]

That's very strange. Cython isn't required for either PyZMQ or
gr-air-modes. My guess is you have multiple Python versions installed, and
PyZMQ got installed to a version that isn't the one gr-air-modes found.

Whatever works! =)

--n


On Mon, Apr 28, 2014 at 9:10 AM, Silverfox  wrote:

> I got it complied and working.  The key was to install Cython.  It is
> probably worthwhile to add it to the dependency list.
>
> Alan
>
>
>
>
>
> *From:* Nick Foster [mailto:bistrom...@gmail.com]
> *Sent:* Sunday, April 27, 2014 4:30 PM
> *To:* Silverfox
> *Subject:* Re: [Discuss-gnuradio] gr-air-modes compilation
>
>
>
> Open python, type "import zmq". What's the result?
>
>
>
> On Sun, Apr 27, 2014 at 4:24 PM, Silverfox  wrote:
>
> I am trying to compile the lasted code from github and am getting an error
> from CMake.  It is looking for pyZMQ and not finding it.  I tried to
> install the module but not having much luck - that is it is not simple.  Is
> there a scenario that I can follow?  The dependency list does not cite
> PyMZQ so I am curious if it really needs it.  This is on Ubutunu 14.04.
>
>
>
> Alan - W6ARH
>
>
>
>
> ___
> 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] Recommended gr-ais repo/branch/commit for GnuRadio 3.7.x (latest git) and UHD 3.7.1?

[Nick Foster]

754C is correct. What hardware are you using? Are you sure you have a
line-of-sight view to ships?


On Fri, Apr 25, 2014 at 2:14 PM, Andy Walls wrote:

> Hi.
>
> What is the recommended gr-ais repo/branch/commit that yields a working
> gr-ais with GnuRadio 3.7.x (git commit
> 3831dd37c8df19e25fa258db4d393ee068889dae)
> and the Ettus UHD 3.7.1
>
> GitHub shows this fork network:
> https://github.com/bistromath/gr-ais/network
>
> Right now I'm using bistromath/gr-ais commit
> 754c13ca4f1c3fb0d079d3a42002b0dade2268ff
> (master HEAD, IIRC), but I'm not getting *any* !AIVDM output to the
> terminal window.
>
> Regards,
> Andy
>
>
> ___
> 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] ASK demodulation help

[Nick Foster]

That's very likely it. It's effectively starting with a random guess as to
the bit timing, and it locks exponentially faster the closer it is to
correct. So for a worst-case guess, it'll take significantly longer to lock.

--n


On Fri, Apr 11, 2014 at 10:33 AM, Francois Gervais <
francoisgerv...@gmail.com> wrote:

> That could explain it. However most of the time it locks just fine even
> for the preamble with the same block parameters. I'm not sure what causes
> this variability and if I have control over it of not.
>
> Might be related to when the MM clock recovery starts sampling the signal.
> Sometimes it's lucky and start sampling the bit close to a bit frontier and
> sometimes not so it needs to adjust on the next bit. Could that make sense?
>
>
> On Fri, Apr 11, 2014 at 1:19 PM, Nick Foster  wrote:
>
>> To me it looks like it's taking some time to acquire, which is normal for
>> a closed-loop timing recovery algorithm. This is one reason packets have
>> preambles. If you need it to lock faster and don't mind some self-noise,
>> and if the SNR is high enough, you can turn up the gain of the M&M block
>> (change 0.175 in both gain mu and gain omega to a larger number) to allow
>> it to lock faster.
>>
>> --n
>>
>>
>> On Fri, Apr 11, 2014 at 9:59 AM, Francois Gervais <
>> francoisgerv...@gmail.com> wrote:
>>
>>> Any idea on this? Should I post the images somewhere else?
>>>
>>>
>>> On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais <
>>> francoisgerv...@gmail.com> wrote:
>>>
>>>> I tried using the M&M clock recovery block as suggested and I have a
>>>> little fidelity problem. I added two screenshot links below which show the
>>>> problem. I would say 70% of the time the recovered data is fine but for
>>>> some reason it's sometimes badly distorted. By looking at it, the input
>>>> signal looks always about the same. Is there something obviously wrong in
>>>> what I'm doing?
>>>>
>>>> ASK demodulation GRC
>>>>
>>>> https://drive.google.com/file/d/0B_ApAHfP4naZaE5WRUJHWUtHUEU/edit?usp=sharing
>>>>
>>>> Signal in and out of Clock recovery block
>>>>
>>>> https://drive.google.com/file/d/0B_ApAHfP4naZY3Ryblp3cFlrdGs/edit?usp=sharing
>>>>
>>>>
>>>> On Wed, Apr 9, 2014 at 5:27 PM, John Malsbury 
>>>> wrote:
>>>>
>>>>> I don't know if I would call it overkill.  It is just one of several
>>>>> methods you can use to achieve synchronization.  Other options for
>>>>> synchronization include correlate and sync (probably needs modification),
>>>>> or possible the polyphase resync.  Others on the list would have more
>>>>> expertise on these blocks.
>>>>>
>>>>> In my experience 10 samples per symbol seems to work well with M&M.
>>>>> I've heard very high samp/sym (ie. >20) can cause problems, but I haven't
>>>>> seen this myself.
>>>>>
>>>>> The amplitude going into M&M should be as close as possible to +/-
>>>>> 1.0, which is why you want the scaling functions before this block.  The
>>>>> AGC block assures you're working with something constant amplitude for
>>>>> demodulation.
>>>>>
>>>>> -John
>>>>>
>>>>>
>>>>> On Wed, Apr 9, 2014 at 2:04 PM, Francois Gervais <
>>>>> francoisgerv...@gmail.com> wrote:
>>>>>
>>>>>> Thanks guys for the information,
>>>>>>
>>>>>> I looked a little about the M&M recovery block but it seemed to me
>>>>>> like and advance algorithm, overkill for what I'm trying to achieve. I'm 
>>>>>> I
>>>>>> mistaken?
>>>>>>
>>>>>> If I'm using the M&M clock recovery block what is the quality of
>>>>>> input signal I should aim to avoid translation errors? Should my signal 
>>>>>> be
>>>>>> filtered with a really narrow band and should I allow more harmonics in 
>>>>>> to
>>>>>> the signal is more square? Can the input signal have too much sample per
>>>>>> bit? Right now I'm at 16. Is more better? Is it better to have more
>>>>>> amplitude?
>>>>>>
>>>>>> Thanks
>>

Re: [Discuss-gnuradio] ASK demodulation help

[Nick Foster]

To me it looks like it's taking some time to acquire, which is normal for a
closed-loop timing recovery algorithm. This is one reason packets have
preambles. If you need it to lock faster and don't mind some self-noise,
and if the SNR is high enough, you can turn up the gain of the M&M block
(change 0.175 in both gain mu and gain omega to a larger number) to allow
it to lock faster.

--n


On Fri, Apr 11, 2014 at 9:59 AM, Francois Gervais  wrote:

> Any idea on this? Should I post the images somewhere else?
>
>
> On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais <
> francoisgerv...@gmail.com> wrote:
>
>> I tried using the M&M clock recovery block as suggested and I have a
>> little fidelity problem. I added two screenshot links below which show the
>> problem. I would say 70% of the time the recovered data is fine but for
>> some reason it's sometimes badly distorted. By looking at it, the input
>> signal looks always about the same. Is there something obviously wrong in
>> what I'm doing?
>>
>> ASK demodulation GRC
>>
>> https://drive.google.com/file/d/0B_ApAHfP4naZaE5WRUJHWUtHUEU/edit?usp=sharing
>>
>> Signal in and out of Clock recovery block
>>
>> https://drive.google.com/file/d/0B_ApAHfP4naZY3Ryblp3cFlrdGs/edit?usp=sharing
>>
>>
>> On Wed, Apr 9, 2014 at 5:27 PM, John Malsbury wrote:
>>
>>> I don't know if I would call it overkill.  It is just one of several
>>> methods you can use to achieve synchronization.  Other options for
>>> synchronization include correlate and sync (probably needs modification),
>>> or possible the polyphase resync.  Others on the list would have more
>>> expertise on these blocks.
>>>
>>> In my experience 10 samples per symbol seems to work well with M&M.
>>> I've heard very high samp/sym (ie. >20) can cause problems, but I haven't
>>> seen this myself.
>>>
>>> The amplitude going into M&M should be as close as possible to +/- 1.0,
>>> which is why you want the scaling functions before this block.  The AGC
>>> block assures you're working with something constant amplitude for
>>> demodulation.
>>>
>>> -John
>>>
>>>
>>> On Wed, Apr 9, 2014 at 2:04 PM, Francois Gervais <
>>> francoisgerv...@gmail.com> wrote:
>>>
 Thanks guys for the information,

 I looked a little about the M&M recovery block but it seemed to me like
 and advance algorithm, overkill for what I'm trying to achieve. I'm I
 mistaken?

 If I'm using the M&M clock recovery block what is the quality of input
 signal I should aim to avoid translation errors? Should my signal be
 filtered with a really narrow band and should I allow more harmonics in to
 the signal is more square? Can the input signal have too much sample per
 bit? Right now I'm at 16. Is more better? Is it better to have more
 amplitude?

 Thanks


 On Wed, Apr 9, 2014 at 4:31 PM, John Malsbury 
 wrote:

> Depending on various factors the implementation may vary, but you
> could probably start with a chain that looks something like this:
>
> I/q source -> filter -> AGC -> AM demod (complex to mag) -> scaling
> for am depth -> m&m clock recovery -> slicer -> do something with the data
>
> Other, more advanced implementations might use correlation for
> synchronization.
>
> -John
>
>
> On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais <
> francoisgerv...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK
>> signal from a device I have, as a first project. I'm using RTL-SDR as the
>> input device.
>>
>> I'm slowly getting there. I receive the signal, at 2Msample/s, I
>> low-pass filter it to 300khz, I send it through the AM demodulation block
>> and then through the DC blocker.
>>
>> From there I have my signal and it looks fine i.e I could retrieve
>> the information manually by looking at it.
>>
>> Now I think the goal is to somehow synchronize with the bits and
>> re-sample to get 1 sample per bit. This could then be sent to a file. Is
>> that it?
>>
>> At first glance I'm thinking I should have a PLL which ouputs a clock
>> at about 250khz (twice the bit rate) and synchronize the rising edge with
>> every bit transitioning from 0 to 1 so unless I receive only ones ou 
>> zeros
>> I should be quite in sync. Then I could toggle a sample every falling 
>> edge
>> of the clock which should be at about the middle of the bit.
>>
>> Is this a viable solution? Can it be done with gnuradio? Other
>> alternatives?
>>
>> 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
 htt

Re: [Discuss-gnuradio] ASK demodulation help

[Nick Foster]

Look at the clock_recovery_mm_ff block. It does exactly what you want.

--n


On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais
wrote:

> Hi,
>
> I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK signal
> from a device I have, as a first project. I'm using RTL-SDR as the input
> device.
>
> I'm slowly getting there. I receive the signal, at 2Msample/s, I low-pass
> filter it to 300khz, I send it through the AM demodulation block and then
> through the DC blocker.
>
> From there I have my signal and it looks fine i.e I could retrieve the
> information manually by looking at it.
>
> Now I think the goal is to somehow synchronize with the bits and re-sample
> to get 1 sample per bit. This could then be sent to a file. Is that it?
>
> At first glance I'm thinking I should have a PLL which ouputs a clock at
> about 250khz (twice the bit rate) and synchronize the rising edge with
> every bit transitioning from 0 to 1 so unless I receive only ones ou zeros
> I should be quite in sync. Then I could toggle a sample every falling edge
> of the clock which should be at about the middle of the bit.
>
> Is this a viable solution? Can it be done with gnuradio? Other
> alternatives?
>
> 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] Noisy APT images

[Nick Foster]

The WFM receive block includes deemphasis processing for improving the
sound of broadcast FM reception. This is going to screw up your APT
reception. You'll be better off making your own WFM demod block -- it's
just a quadrature demod followed by a low-pass filter.

--n


On Thu, Mar 6, 2014 at 7:42 AM, Pablo Fernández Alonso <
pfernandezalons...@gmail.com> wrote:

> Hi,
>
> I'm trying to receive APT images from NOAA with a QHA antenna and I
> received noisy images. I use a usrp source block, then a low pass filter
> with 50 kHz of cutoff and 20 kHz of transition width, then a WBFM receiver
> and a resampler connected to the audio sink. I think that I should change
> the parameters of the filter.
>
> Regards,
>
> Pablo.
>
> ___
> 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] The GMSK demodulation

[Nick Foster]

On Fri, Feb 28, 2014 at 10:21 AM, Tom Tsou  wrote:

> On Fri, Feb 28, 2014 at 11:51 AM, Nick Foster 
> wrote:
> > I'm working on a generalized CPM demod based on Achilleas's previous
> work in
> > gr-trellis/src/examples/test_cpm.py, and I have it more or less working
> > although there are plenty of little bugs to work out. Since the Viterbi
> part
> > was more or less worked out for me, synchronization is the hard part; my
> > application isn't GSM, and I'd like the solution in Gnuradio to be
> > applicable to a wide range of systems -- this means closed-loop timing
> and
> > freq synchronization instead of just doing data-aided estimates from the
> > preamble.
>
> I don't have much to add, but Nick and Sylvain touched on the largest
> difference between the Gnuradio GMSK demod and GSM/TDMA type burst
> processing - and it's not the Viterbi. The use of synchronization
> loops (or lack thereof) in the demod is really the separating factor.
>

Sample tagging in GR makes it easier to have it both ways in this case. If
you have a correlator block that outputs timing phase estimates based on
the preamble (or whatever), this should be used to initialize a closed-loop
timing recovery block's phase. For bursty transmissions this lets you keep
the loop gain pretty low and still acquire quickly. This is what Tom (R) is
doing with the correlate_and_sync and polyphase_clock_sync blocks, and it's
what I'm doing in my MSK timing recovery block, although I'm still dealing
with a bug in that estimate. If you want to rely strictly on the timing
phase estimate of the preamble as in GMSK's case you could just turn the
loop gain of your favorite timing sync block to zero and let it act as a
naive (and inefficient) decimator.

--n


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

Re: [Discuss-gnuradio] The GMSK demodulation

[Nick Foster]

It's already a separate block, so yes.


On Fri, Feb 28, 2014 at 9:15 AM, Dan CaJacob  wrote:

> Nick,
>
> Are you going to release the non-coherent timing recovery improvement as a
> separate block too (not baked into a GMSK hier block)?  Thanks!
>
> Very Respectfully,
>
> Dan CaJacob
>
>
> On Fri, Feb 28, 2014 at 11:51 AM, Nick Foster wrote:
>
>> I'm working on a generalized CPM demod based on Achilleas's previous work
>> in gr-trellis/src/examples/test_cpm.py, and I have it more or less working
>> although there are plenty of little bugs to work out. Since the Viterbi
>> part was more or less worked out for me, synchronization is the hard part;
>> my application isn't GSM, and I'd like the solution in Gnuradio to be
>> applicable to a wide range of systems -- this means closed-loop timing and
>> freq synchronization instead of just doing data-aided estimates from the
>> preamble. I've implemented a timing synchronizer based on the D'andrea,
>> Mengali, Reggiannini paper following MATLAB's example, and I'm using an
>> adaptation of the correlate_and_sync block to synchronize to (G)MSK
>> preambles.
>>
>> Don't know when I'll have it ready to release (i.e. when the code isn't
>> an embarrassment to look at) but it's Working In The Lab (TM). It also
>> takes quite a bit of setup to apply to each use case.
>>
>> If you don't need those extra few dB, it's a whole heck of a lot simpler
>> both in implementation complexity and CPU cycles to just stick with the
>> existing noncoherent GMSK block. When I release code I'll also release an
>> updated noncoherent GMSK receiver block which uses the new timing
>> estimator, as the primary weakness of the existing GMSK block is timing
>> recovery.
>>
>> --n
>>
>>
>> On Fri, Feb 28, 2014 at 7:31 AM, Sylvain Munaut <246...@gmail.com> wrote:
>>
>>> Also as a side note, you can't demod GSM and then slice it. You have
>>> to demod it burst by burst so that you can lock to the training
>>> sequence of each. So the demod block of GR is pretty much useless
>>> here.
>>>
>>> airprobe has a viterbi demod (which is probably one of the few good
>>> part of airprobe to re-use).
>>>
>>> Cheers,
>>>
>>> Sylvain
>>>
>>>
>>> On Fri, Feb 28, 2014 at 4:27 PM, Tom Rondeau  wrote:
>>> > On Fri, Feb 28, 2014 at 10:12 AM, Marcus Müller 
>>> wrote:
>>> >> Hi Zhenhua,
>>> >> as Aditya pointed out: Viterby is /not/ a demodulator.
>>> >> You should read something on digital communication that explains the
>>> >> difference between channel coding and modulation, then everything
>>> will be
>>> >> clearer to you.
>>> >>
>>> >> Greetings,
>>> >> Marcus
>>> >>
>>> >> On 02/28/2014 04:04 PM, zhenhua han wrote:
>>> >>
>>> >> What confused me is the Viterbi algorithm. I saw it can be used to
>>> >> demodulate GMSK in more than one place (such as here:
>>> >>
>>> http://www.mathworks.cn/cn/help/comm/ref/comm.gmskdemodulatorclass.html)
>>> >>
>>> >> I think it's better for me to read some materials of Viterbi and find
>>> out
>>> >> what really it is.
>>> >>
>>> >> Cheers
>>> >> Zhenhua
>>> >>
>>> >> 2014-2-28 下午10:40于 "Aditya Dhananjay"  写道：
>>> >>>>
>>> >>>>
>>> >>>> As I have known, GSM uses GMSK modulation which BT = 0.3 and it uses
>>> >>>> Viterbi algorithm for demodulation. And I took a look at the code
>>> of GMSK
>>> >>>> demod code in GNU Radio, it use quadrature_demod but not Viterbi as
>>> >>>> demodulation method. So which one is better in doing demodulating
>>> GMSK?
>>> >>>>
>>> >>>> Moreover, GSM uses Viterbi algorithm to decode the convolution
>>> encoding.
>>> >>>> Would it be possible to use quadrature_demod to demodulate GSM
>>> signal
>>> >>>> instead of Viterbi? What about the convolution decoding part (maybe
>>> by some
>>> >>>> other method)?
>>> >>>>
>>> >>>
>>> >>> I think you are mixing up the modulation and coding components.
>>> >>

Re: [Discuss-gnuradio] The GMSK demodulation

[Nick Foster]

I'm working on a generalized CPM demod based on Achilleas's previous work
in gr-trellis/src/examples/test_cpm.py, and I have it more or less working
although there are plenty of little bugs to work out. Since the Viterbi
part was more or less worked out for me, synchronization is the hard part;
my application isn't GSM, and I'd like the solution in Gnuradio to be
applicable to a wide range of systems -- this means closed-loop timing and
freq synchronization instead of just doing data-aided estimates from the
preamble. I've implemented a timing synchronizer based on the D'andrea,
Mengali, Reggiannini paper following MATLAB's example, and I'm using an
adaptation of the correlate_and_sync block to synchronize to (G)MSK
preambles.

Don't know when I'll have it ready to release (i.e. when the code isn't an
embarrassment to look at) but it's Working In The Lab (TM). It also takes
quite a bit of setup to apply to each use case.

If you don't need those extra few dB, it's a whole heck of a lot simpler
both in implementation complexity and CPU cycles to just stick with the
existing noncoherent GMSK block. When I release code I'll also release an
updated noncoherent GMSK receiver block which uses the new timing
estimator, as the primary weakness of the existing GMSK block is timing
recovery.

--n


On Fri, Feb 28, 2014 at 7:31 AM, Sylvain Munaut <246...@gmail.com> wrote:

> Also as a side note, you can't demod GSM and then slice it. You have
> to demod it burst by burst so that you can lock to the training
> sequence of each. So the demod block of GR is pretty much useless
> here.
>
> airprobe has a viterbi demod (which is probably one of the few good
> part of airprobe to re-use).
>
> Cheers,
>
> Sylvain
>
>
> On Fri, Feb 28, 2014 at 4:27 PM, Tom Rondeau  wrote:
> > On Fri, Feb 28, 2014 at 10:12 AM, Marcus Müller 
> wrote:
> >> Hi Zhenhua,
> >> as Aditya pointed out: Viterby is /not/ a demodulator.
> >> You should read something on digital communication that explains the
> >> difference between channel coding and modulation, then everything will
> be
> >> clearer to you.
> >>
> >> Greetings,
> >> Marcus
> >>
> >> On 02/28/2014 04:04 PM, zhenhua han wrote:
> >>
> >> What confused me is the Viterbi algorithm. I saw it can be used to
> >> demodulate GMSK in more than one place (such as here:
> >> http://www.mathworks.cn/cn/help/comm/ref/comm.gmskdemodulatorclass.html)
> >>
> >> I think it's better for me to read some materials of Viterbi and find
> out
> >> what really it is.
> >>
> >> Cheers
> >> Zhenhua
> >>
> >> 2014-2-28 下午10:40于 "Aditya Dhananjay"  写道：
> 
> 
>  As I have known, GSM uses GMSK modulation which BT = 0.3 and it uses
>  Viterbi algorithm for demodulation. And I took a look at the code of
> GMSK
>  demod code in GNU Radio, it use quadrature_demod but not Viterbi as
>  demodulation method. So which one is better in doing demodulating
> GMSK?
> 
>  Moreover, GSM uses Viterbi algorithm to decode the convolution
> encoding.
>  Would it be possible to use quadrature_demod to demodulate GSM signal
>  instead of Viterbi? What about the convolution decoding part (maybe
> by some
>  other method)?
> 
> >>>
> >>> I think you are mixing up the modulation and coding components.
> >>>
> >>> At the transmitter, you first code (convolutional code), and then you
> >>> modulate (GMSK).
> >>>
> >>> At the receiver, you first demodulate (quadrature demodulate) and then
> you
> >>> decode (Viterbi).
> >>>
> >>> Coding takes a stream of bits and converts it to another stream of
> bits.
> >>> Modulation refers to the process of converting the post-coded bits into
> >>> "symbols" that you will then send over-the-air.
> >>>
> >>> best,
> >>> aditya
> >
> >
> > Actually, guys
> >
> > http://www.ittc.ku.edu/~prescott/kcp/HPRC-GMSK-Demod.pdf
> >
> > You can demodulate GMSK using the Viterbi algorithm.
> >
> > Zhenhua,
> >
> > We don't implement this method in our GMSK demodulator, though I have
> > wanted to see someone do it. The Viterbi is the maximum likelihood
> > detector for GMSK, but it's more complicated to implement. The
> > quadrature method we use is simple and intuitive but suboptimal.
> >
> > Tom
> >
> > ___
> > 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] .so: undefined symbol: _ZN2gr6blocks12count_bits16E

[Nick Foster]

Usually a "make clean" will solve this.

--n


On Mon, Feb 10, 2014 at 9:57 AM, raf raf  wrote:

> Hi all gnuradio users,
>
> I have an error when I try to execute a python script after adding a new
> block.
>
> My block is add to a gnuradio 3.7 with gr_modtool with a command :
>
>
> gr_modtool add -t sync packet_sink
>
> The module containing a blocks is ieee_868_915. The error is  :
>
> Traceback (most recent call last):
>   File "./qa_symbols_to_chips_bs.py", line 25, in 
> import ieee_868_915
>   File "/usr/local/lib/python2.7/dist-packages/ieee_868_915/__init__.py",
> line 45, in 
> from ieee_868_915_swig import *
>   File
> "/usr/local/lib/python2.7/dist-packages/ieee_868_915/ieee_868_915_swig.py",
> line 26, in 
> _ieee_868_915_swig = swig_import_helper()
>   File
> "/usr/local/lib/python2.7/dist-packages/ieee_868_915/ieee_868_915_swig.py",
> line 22, in swig_import_helper
> _mod = imp.load_module('_ieee_868_915_swig', fp, pathname, description)
> ImportError: /usr/local/lib/libgnuradio-ieee_868_915.so: undefined symbol:
> _ZN2gr6blocks12count_bits16Ej
>
>
> I tried to delete a lib file libgnuradio-ieee_868_915.so and reinstall all
> a block, but it didn't give a result.
>
>
> Please help me to fix this error.
>
> Thank you.
>
> ___
> 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] QT GUI Time Sink Attribute Error

[Nick Foster]

Upper left corner of your GRC flowgraph. Where it says Generate Options.
Change that to "QT GUI".

--n


On Thu, Jan 30, 2014 at 7:07 PM, Activecat  wrote:

> Dear Sir,
>
> How to use the block of QT GUI Time Sink?
> It always produces following error message:
>
> Generating: "/home/sgku/grc/top_block.py"
> Executing: "/home/sgku/grc/top_block.py"
> Traceback (most recent call last):
>   File "/home/sgku/grc/top_block.py", line 158, in 
> tb = top_block()
>   File "/home/sgku/grc/top_block.py", line 93, in __init__
> self.top_layout.addWidget(self._qtgui_time_sink_x_0_win)
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
> line 94, in __getattr__
> return getattr(self._tb, name)
> AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout'
> >>> Done
>
> Please advise, thanks.
> Regards,
> activecat
>
>
> ___
> 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] Help about using gr-air-modes

[Nick Foster]

Oh! Of course. Yes, that's why I wanted to see the complete output --
timestamps are not kept in the saved samples. You'll only get timestamps if
you are viewing live data.

--n


On Wed, Jan 29, 2014 at 2:24 AM, Cheng Chi  wrote:

> Hi Nick,
>
> Thanks for your explanation :)
>
> Today I have collected some data using the same setup, USRP N210 with
> GPSDO + WBX. The collection is done at the rooftop with open sky.
> Gain: 20
> Sampling Rate: 10M
> Center Frequency: 1090M
> Data format: complex float (Use GNUradio Companion for collecting data. I
> think this should be the same as using uhd_rx_cfile?)
>
> As shown below, the decoded data seems correct, but the timestamp
> information is still quite strange. Is it because the modes_rx program
> can't timestamp packets for saved data? Do you have any suggestion about
> how to identify the Mode S packet from the raw data? (I've tried using the
> preamble to cross correlate with the received data, but no success so far.)
>
>
> command line:
> {{{
> modes_rx -s ADSB_10M_JAN29_float_4.dat -r 1000
> }}}
>
> output:
> {{{
> (-55 0.) Type 0 (short A-A surveillance) from 8a0301 at 2450ft
> (Vertical TCAS resolution only)
> (-52 0.) Type 20 TCAS report from 76ce4e:  (no handler for TTI=0)
> at 14200ft
> (-55 0.) Type 0 (short A-A surveillance) from 8a0301 at 2450ft
> (Vertical TCAS resolution only)
> (-56 0.) Type 0 (short A-A surveillance) from 76cf27 at 8600ft
> (Vertical TCAS resolution only)
> (-50 0.) Type 17 BDS0,9-1 (track report) from 461eac with velocity
> 191kt heading 23 VS 64
> (-57 0.) Type 17 BDS0,5 (position report) from 8a01ba at
> (0.985511, 103.824021) at 5375ft
> (-56 0.) Type 20 TCAS report from 75029c:  (no handler for TTI=0)
> at 38025ft
> (-54 0.) Type 0 (short A-A surveillance) from 75029c at 38025ft
> (speed 300-600kt)
> (-60 0.) Type 0 (short A-A surveillance) from abee7c at 7100ft
> (Vertical TCAS resolution only)
> (-46 0.) Type 0 (short A-A surveillance) from 750279 at 9100ft
> (Vertical TCAS resolution only)
> (-58 0.) Type 0 (short A-A surveillance) from 8a1f1a at 2400ft
> (Vertical TCAS resolution only)
> (-55 0.) Type 0 (short A-A surveillance) from 8a03c2 at 8075ft
> (Vertical TCAS resolution only)
> (-45 0.) Type 0 (short A-A surveillance) from ae075d at 1100ft
> (Vertical TCAS resolution only)
> (-50 0.) Type 0 (short A-A surveillance) from 4b1906 at 10100ft
> (Vertical TCAS resolution only)
> (-54 0.) Type 20 TCAS report from 76cd88:  (no handler for TTI=0)
> at 4100ft
> (-51 0.) Type 0 (short A-A surveillance) from 4b1906 at 10100ft
> (Vertical TCAS resolution only)
> (-44 0.) Type 11 (all call reply) from 8a01ba in reply to
> interrogator 0 with capability level 6
> (-52 0.) Type 17 BDS0,5 (position report) from 76ce4e at
> (1.148118, 104.249078) at 14225ft
> (-55 0.) Type 20 TCAS report from 76cd88:  (no handler for TTI=0)
> at 4100ft
> (-58 0.) Type 0 (short A-A surveillance) from 8a0301 at 2450ft
> (Vertical TCAS resolution only)
> (-56 0.) Type 0 (short A-A surveillance) from 732f06 at 3700ft
> (Vertical TCAS resolution only)
> (-51 0.) Type 0 (short A-A surveillance) from 7501fd at 33000ft
> (Vertical TCAS resolution only)
> (-53 0.) Type 0 (short A-A surveillance) from 76cd88 at 4100ft
> (Vertical TCAS resolution only)
> (-55 0.) Type 21 link capability report from 76cd88: ACS: 0x10080,
> BCS: 0xf600, ECS: 0x0, continues 0 ident 9c
> (-51 0.) Type 0 (short A-A surveillance) from 76ce4e at 14225ft
> (speed 300-600kt)
> (-45 0.) Type 0 (short A-A surveillance) from ae075d at 1100ft
> (Vertical TCAS resolution only)
> (-56 0.) Type 0 (short A-A surveillance) from 8a0301 at 2450ft
> (Vertical TCAS resolution only)
> (-57 0.) Type 0 (short A-A surveillance) from 76cf27 at 8600ft
> (Vertical TCAS resolution only)
> (-54 0.) Type 17 BDS0,5 (position report) from 76cd88 at
> (0.876299, 103.944397) at 4100ft
> (-52 0.) Type 0 (short A-A surveillance) from 76ce4e at 14225ft
> (Vertical TCAS resolution only)
> (-50 0.) Type 11 (all call reply) from 461eac in reply to
> interrogator 0 with capability level 6
> }}}
>
> Best regards,
> Cheng Chi
>
>
>
> On Tue, Jan 28, 2014 at 1:58 AM, Nick Foster  wrote:
>
>> Haven't used bladeRF, but I have used other LMS6002D-based radios with
>> gr-air-modes, with some success. The problem is Mode S has a weak CRC and
>> is thus vulnerable to spurious packets. That said, in practice spurious
>> replies should be unde

Re: [Discuss-gnuradio] Help about using gr-air-modes

[Nick Foster]

Haven't used bladeRF, but I have used other LMS6002D-based radios with
gr-air-modes, with some success. The problem is Mode S has a weak CRC and
is thus vulnerable to spurious packets. That said, in practice spurious
replies should be under 1% of your total. Experiment with gain and
threshold settings -- your feedback should be nonunique ICAO numbers; in
other words you're looking for multiple replies from the same aircraft. The
"get_dupes.py" script in apps/ will take the output generated by
gr-air-modes and parse it to tell you how many actual aircraft you've heard.

--n


On Mon, Jan 27, 2014 at 2:35 AM, Ralph A. Schmid, dk5ras
wrote:

> When having no clue about the data I should expect – how can I find out
> about the real data, and how can I see what is decoded noise? I am using
> the bladeRF, and to me most data looks wrong, too :)
>
>
>
> Ralph-
>
>
>
> *From:* discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:
> discuss-gnuradio-bounces+ralph=schmid@gnu.org] *On Behalf Of *Nick
> Foster
> *Sent:* Monday, January 27, 2014 9:43 AM
> *To:* Cheng Chi
> *Cc:* GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] Help about using gr-air-modes
>
>
>
> The reason you're seeing lots of false packets is the use of a zero
> threshold. Leave the -T 0 part out of the command line. Your other settings
> are fine, although if you're indoors you probably aren't going to see much
> data at all.
>
>
>
> I'll look into the timestamp issue and see if I can replicate it here.
>
>
>
> --n
>
>
>
> On Mon, Jan 27, 2014 at 12:40 AM, Cheng Chi  wrote:
>
> Hi Nick,
>
>
>
> The command line:
>
> {{{
>
> modes_rx -T 0 -r 1000 -s packet_float.dat
>
> }}}
>
>
>
> The setup:
>
> USRP + WBX + VERT900 Antenna, gain is set at 19 when recording the data.
>
>
>
>
>
> The output:
>
> {{{
>
> usrp@ubuntu:~/gr-air-modes/apps$ modes_rx -T 0 -r 1000 -s
> packet_float.dat
>
> Using file source packet_float.dat
>
> Rate is 1000
>
> Using Volk machine: avx_32_mmx_orc
>
> (41 0.) Type 0 (short A-A surveillance) from 8b11e3 at 43825ft
> (speed <75kt)
>
> (31 0.) Type 0 (short A-A surveillance) from 76ce83 at 19000ft
> (Vertical TCAS resolution only)
>
> (38 0.) Type 0 (short A-A surveillance) from 7805dd at 3025ft
> (Vertical TCAS resolution only)
>
> (26 0.) Type 4 (short surveillance altitude reply) from 53dd8d at
> -1000ft (SPI)
>
> (25 0.) No handler for message type 24 from d9a7dd
>
> (27 0.) Type 0 (short A-A surveillance) from ee5e77 at 44475ft
> (Vertical TCAS resolution only)
>
> (26 0.) Type 0 (short A-A surveillance) from e2683e at 33850ft
> (speed 1200-2400kt)
>
> (38 0.) Type 0 (short A-A surveillance) from 7805dd at 3025ft
> (Vertical TCAS resolution only)
>
> (26 0.) No handler for message type 24 from df163e
>
> (26 0.) No handler for message type 24 from 4dd8f4
>
> (22 0.) Type 0 (short A-A surveillance) from 3b8ec9 at 59100ft
> (speed 75-150kt)
>
> (26 0.) Type 0 (short A-A surveillance) from 9f6f91 at 18450ft
> (speed 1200-2400kt)
>
> (28 0.) No handler for message type 24 from c4b50b
>
> (31 0.) Type 11 (all call reply) from 76ce83 in reply to
> interrogator 0 with capability level 6
>
> (31 0.) Type 21 link capability report from 75008f: ACS: 0x10680,
> BCS: 0xf600, ECS: 0x0, continues 0 ident 564
>
> (23 0.) No handler for message type 24 from 38f620
>
> (26 0.) No handler for message type 24 from d7a547
>
> (29 0.) Type 11 (all call reply) from 76aa6b in reply to
> interrogator 0 with capability level 6
>
> (26 0.) Type 5 (short surveillance ident reply) from b49331 with
> ident 7150 (aircraft is on the ground)
>
> (29 0.) Type 5 (short surveillance ident reply) from 8f6b6a with
> ident 7610 (SPI ALERT)
>
> (39 0.) Type 4 (short surveillance altitude reply) from a69223 at
> 32975ft (AIRBORNE ALERT)
>
> (25 0.) Type 4 (short surveillance altitude reply) from acc9e9 at
> 53700ft (aircraft is on the ground)
>
> (33 0.) Type 0 (short A-A surveillance) from 8a01d4 at 18750ft
> (speed 300-600kt)
>
> (32 0.) Type 0 (short A-A surveillance) from 8a01d4 at 18750ft
> (speed 300-600kt)
>
> (28 0.) Type 0 (short A-A surveillance) from 601589 at 46725ft
> (TCAS resolution inhibited)
>
> (27 0.) Type 5 (short surveillance ident reply) from 4ba262 with
> ident 2520 (SPI)
>
> (24 0.) Type 21 link capability report fro

Re: [Discuss-gnuradio] Help about using gr-air-modes

[Nick Foster]

0 TCAS report from 7805dd:  (no handler for TTI=0)
> at 3000ft
> (27 0.) Type 0 (short A-A surveillance) from dc2ed9 at 45900ft
> (speed 600-1200kt)
> (23 0.) Type 4 (short surveillance altitude reply) from 2443b0 at
> 59800ft (GROUND ALERT)
> (24 0.) Type 4 (short surveillance altitude reply) from 3b1fc3 at
> 3200ft (SPI)
> (21 0.) Type 21 link capability report from d5ca0e: ACS: 0xda21,
> BCS: 0xc923, ECS: 0xee, continues 8 ident 123e
> (22 0.) Type 5 (short surveillance ident reply) from 5ad8b4 with
> ident 728 (GROUND ALERT)
> (37 0.) Type 17 BDS0,9-1 (track report) from 7805dd with velocity
> 218kt heading 238 VS -1664
>  }}}
>
> Best regards,
> Cheng Chi
>
>
> On Mon, Jan 27, 2014 at 4:28 PM, Nick Foster  wrote:
>
>> On Mon, Jan 27, 2014 at 12:23 AM, Cheng Chi wrote:
>>
>>> Hi Nick,
>>>
>>> Thanks for your quick reply!
>>>
>>> I have to use a 10M sampling rate in my case, but due to computer
>>> constrain, modes_rx will cause overflow when used directly with -r
>>> 1000. I gauss it's because it's sampling data in float? I am using a
>>> GPSDO with USRP.
>>>
>>> So I record data in short at 10M sampling rate, convert from short to
>>> float and then input to modes_rx. The output looks like this:
>>> {{{
>>> (27 0.) Type 0 (short A-A surveillance) from dc2ed9 at 45900ft
>>> (speed 600-1200kt)
>>> (23 0.) Type 4 (short surveillance altitude reply) from 2443b0
>>> at 59800ft (GROUND ALERT)
>>> (24 0.) Type 4 (short surveillance altitude reply) from 3b1fc3
>>> at 3200ft (SPI)
>>> (21 0.) Type 21 link capability report from d5ca0e: ACS: 0xda21,
>>> BCS: 0xc923, ECS: 0xee, continues 8 ident 123e
>>> (22 0.) Type 5 (short surveillance ident reply) from 5ad8b4 with
>>> ident 728 (GROUND ALERT)
>>> (37 0.) Type 17 BDS0,9-1 (track report) from 7805dd with
>>> velocity 218kt heading 238 VS -1664
>>> }}}
>>>
>>> The timestamp are all zeros.
>>>
>>
>> This appears to be a bug. Can you paste the entire output of gr-air-modes?
>>
>> I'm also concerned by the data you've shown. There is only one real reply
>> in the above data -- the last one. The others are all spurious replies. Can
>> you tell me the command line you're using as well as the equipment setup --
>> daughterboard, antenna, etc.?
>>
>>
>>
>>>
>>> Another question is that if I use modes_rx, how to save the sampled
>>> complex baseband signal? Is the data saved somewhere that I've missed?
>>>
>>
>> This is not something modes_rx is designed to do. I suggest instead that
>> you record samples to disk using uhd_rx_cfile, and then run modes_rx on the
>> saved file using --source=.
>>
>> --n
>>
>>
>>>
>>> Best regards,
>>> Cheng Chi
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jan 27, 2014 at 3:57 PM, Nick Foster wrote:
>>>
>>>> On Sun, Jan 26, 2014 at 11:48 PM, Cheng Chi wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am using gr-air-modes for decoding the air plane signal with USRP.
>>>>> I've successfully used the "modes_rx" and "modes_gui" for decoding the
>>>>> mode-S packets.
>>>>>
>>>>> However, it seems that the modes_rx or modes_gui can't provide the
>>>>> timestamp of the mode-S packets being decoded. Is there any option that I
>>>>> can set to timestamp the mode-S packet? The reason I want this timestamp
>>>>> function is that I want to know the decoded packet data correspond to 
>>>>> which
>>>>> part of the raw data (complex baseband data samples).
>>>>>
>>>>
>>>> If you're using a USRP, you should be getting a timestamp. It's the
>>>> second number printed, as in the following:
>>>> (-14 *1.29258827811*) Type 0 (short A-A surveillance) from ab2984 at
>>>> 3000ft
>>>>
>>>> If you are using a GPSDO with your USRP, the printed time will be in
>>>> UTC seconds. Otherwise, it will be in seconds since the application started
>>>> running.
>>>>
>>>> --n
>>>>
>>>>
>>>>
>>>>>
>>>>> Thank you for any help you can provide in this situation.
>>>>>
>>>>> I found that there's a file called "air_modes_preamble.cc" seems to
>>>>> provide the timestamp function. Does anyone know how to use this file
>>>>> separately?
>>>>>
>>>>> Best regards,
>>>>> Cheng Chi
>>>>>
>>>>> ___
>>>>> 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] Help about using gr-air-modes

[Nick Foster]

On Mon, Jan 27, 2014 at 12:23 AM, Cheng Chi  wrote:

> Hi Nick,
>
> Thanks for your quick reply!
>
> I have to use a 10M sampling rate in my case, but due to computer
> constrain, modes_rx will cause overflow when used directly with -r
> 1000. I gauss it's because it's sampling data in float? I am using a
> GPSDO with USRP.
>
> So I record data in short at 10M sampling rate, convert from short to
> float and then input to modes_rx. The output looks like this:
> {{{
> (27 0.) Type 0 (short A-A surveillance) from dc2ed9 at 45900ft
> (speed 600-1200kt)
> (23 0.) Type 4 (short surveillance altitude reply) from 2443b0 at
> 59800ft (GROUND ALERT)
> (24 0.) Type 4 (short surveillance altitude reply) from 3b1fc3 at
> 3200ft (SPI)
> (21 0.) Type 21 link capability report from d5ca0e: ACS: 0xda21,
> BCS: 0xc923, ECS: 0xee, continues 8 ident 123e
> (22 0.) Type 5 (short surveillance ident reply) from 5ad8b4 with
> ident 728 (GROUND ALERT)
> (37 0.) Type 17 BDS0,9-1 (track report) from 7805dd with velocity
> 218kt heading 238 VS -1664
> }}}
>
> The timestamp are all zeros.
>

This appears to be a bug. Can you paste the entire output of gr-air-modes?

I'm also concerned by the data you've shown. There is only one real reply
in the above data -- the last one. The others are all spurious replies. Can
you tell me the command line you're using as well as the equipment setup --
daughterboard, antenna, etc.?



>
> Another question is that if I use modes_rx, how to save the sampled
> complex baseband signal? Is the data saved somewhere that I've missed?
>

This is not something modes_rx is designed to do. I suggest instead that
you record samples to disk using uhd_rx_cfile, and then run modes_rx on the
saved file using --source=.

--n


>
> Best regards,
> Cheng Chi
>
>
>
>
>
> On Mon, Jan 27, 2014 at 3:57 PM, Nick Foster  wrote:
>
>> On Sun, Jan 26, 2014 at 11:48 PM, Cheng Chi wrote:
>>
>>> Hi,
>>>
>>> I am using gr-air-modes for decoding the air plane signal with USRP.
>>> I've successfully used the "modes_rx" and "modes_gui" for decoding the
>>> mode-S packets.
>>>
>>> However, it seems that the modes_rx or modes_gui can't provide the
>>> timestamp of the mode-S packets being decoded. Is there any option that I
>>> can set to timestamp the mode-S packet? The reason I want this timestamp
>>> function is that I want to know the decoded packet data correspond to which
>>> part of the raw data (complex baseband data samples).
>>>
>>
>> If you're using a USRP, you should be getting a timestamp. It's the
>> second number printed, as in the following:
>> (-14 *1.29258827811*) Type 0 (short A-A surveillance) from ab2984 at
>> 3000ft
>>
>> If you are using a GPSDO with your USRP, the printed time will be in UTC
>> seconds. Otherwise, it will be in seconds since the application started
>> running.
>>
>> --n
>>
>>
>>
>>>
>>> Thank you for any help you can provide in this situation.
>>>
>>> I found that there's a file called "air_modes_preamble.cc" seems to
>>> provide the timestamp function. Does anyone know how to use this file
>>> separately?
>>>
>>> Best regards,
>>> Cheng Chi
>>>
>>> ___
>>> 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] Help about using gr-air-modes

[Nick Foster]

On Sun, Jan 26, 2014 at 11:48 PM, Cheng Chi  wrote:

> Hi,
>
> I am using gr-air-modes for decoding the air plane signal with USRP. I've
> successfully used the "modes_rx" and "modes_gui" for decoding the mode-S
> packets.
>
> However, it seems that the modes_rx or modes_gui can't provide the
> timestamp of the mode-S packets being decoded. Is there any option that I
> can set to timestamp the mode-S packet? The reason I want this timestamp
> function is that I want to know the decoded packet data correspond to which
> part of the raw data (complex baseband data samples).
>

If you're using a USRP, you should be getting a timestamp. It's the second
number printed, as in the following:
(-14 *1.29258827811*) Type 0 (short A-A surveillance) from ab2984 at 3000ft

If you are using a GPSDO with your USRP, the printed time will be in UTC
seconds. Otherwise, it will be in seconds since the application started
running.

--n



>
> Thank you for any help you can provide in this situation.
>
> I found that there's a file called "air_modes_preamble.cc" seems to
> provide the timestamp function. Does anyone know how to use this file
> separately?
>
> Best regards,
> Cheng Chi
>
> ___
> 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