> Date: Wed, 26 Aug 2015 19:09:55 +0200
> From: Marcus M?ller
> Hi Jeon,
> > But I don't think that GNU Radio uses 100 percent (= one) of CPU
> > capability.
> Well, that obviously depends on what you /do /with GNU Radio.
> Generally, GNU Radio scales pretty well, so I'm going to reply with:
>
> Message: 2
> Date: Sat, 29 Aug 2015 17:30:29 -0400
> From: Sylvain Munaut
> To: GNURadio Discussion List
> Subject: [Discuss-gnuradio] GRCon15 Talk recordings
> Hi,
>
>
> For anyone interested into digging into this, here are some recordings
> of the mic RF signal during talks at GRCon 15
>
On Sun, 2015-08-30 at 13:18 -0400, Andy Walls wrote:
> > Message: 2
> > Date: Sat, 29 Aug 2015 17:30:29 -0400
> > From: Sylvain Munaut
> >
> > For anyone interested into digging into this, here are some recordings
> > of the mic RF signal du
> Hello GNU Radio dev community! I wanted to pass on some information
> for you that might be a good way for you to help contribute to our
> project. Thanks to Pete Mathys during out GRCon15 Hackfest, we now
> have a list of blocks with minimal or no documentation. I've put
> together a Google spr
> From: David Halls
>Subject: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send
error:send_to: Message too long
>Date: Fri, 25 Sep 2015 09:05:56 +
>Dear All,
>
>
>When I increase my packet length in a transmission flow graph to over
>16,000 bits, I get the following error
>
>
On Fri, 2015-09-25 at 15:17 -0400, Andy Walls wrote:
> > From: David Halls
> >Subject: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send
> error:send_to: Message too long
> >Date:Fri, 25 Sep 2015 09:05:56 +
>
> >Dear All,
> >
> >
The ML archive here looks like it has stopped updating:
http://lists.gnu.org/archive/html/discuss-gnuradio/2015-10/index.html
Regards,
Andy
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnurad
en the input sample stream containing a
> preamble sequence matches up in time and level with the
> correlation sequence. So the AGC should be configured to
> normalize the input stream to allow that to happen.
>
> Sean
> ___
On Sat, 2015-10-24 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Message: 2
> Date: Fri, 23 Oct 2015 19:56:19 -0400
> From: "Marcus D. Leech"
> To: "Discuss-gnuradio@gnu.org"
> Subject: [Discuss-gnuradio] Synchronous AM detector
> Has anyone done a synchronous AM detector, rather th
> Date: Fri, 4 Dec 2015 15:38:21 +
> From: Henry Barton
> To: "discuss-gnuradio@gnu.org"
> Subject: [Discuss-gnuradio] FW: Possible LTE signal
>
> Could it be some sort of studio-to-transmitter link? There is a
> mysterious tower about a mile away that is registered as SC ETV but
> doesn'
Ryan Wilson wrote:
> Hi all,
>
>
> I am currently attempting to get a bit stream from a captured RF
> signal that I know is from a burst FSK transmitter( 433.92 MHz
> carrier, 10kHz deviation, Manchester).
>
> Using GNU Radio 3.7.8.
>
>
> I have isolated the signal and would say I have success
On Wed, 2016-01-06 at 12:00 -0500, discuss-gnuradio-requ...@gnu.org
wrote:
> On Wed, Jan 6, 2016 at 11:09 AM, Richard Bell
>
> wrote:
>
> > Does anyone know of a good tutorial that shows how to receive and
> display
> > TV on Ubuntu using a USRP and GNU Radio? I'm interested.
> >
> > Rich
> >
>
On Thu, 2016-02-04 at 08:32 -0500, discuss-gnuradio-requ...@gnu.org
wrote:
> In case anyone is interested, I got this to work with code similar to
> the following. Note that ?usrp_alias? must be fetched from an already
> constructed usrp_sink object, for instance using ?self.usrp.alias()?
> in a P
On Thu, 2016-02-04 at 17:53 +, Nowlan, Sean wrote:
> Thanks, Andy. I haven't yet encountered any issues from initializing
> USRP settings (freq/gain/antenna/etc.) from "main" thread and polling
> PPS from another thread,
Neither have I. (FWIW, I poll the GPSDO NMEA strings and USRP timestamp
"Assuming the transmitter and receiver were perfectly clocked in unison, what
stops the receiver from tuning in in the middle of a byte, thus getting a
nibble from the current byte and a nibble from the next?"
Nothing. That is a synchronization task your receiver must perform. Assuming
the TX
On Fri, 2016-02-19 at 12:01 -0500, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Fri, 19 Feb 2016 10:05:29 -0500
> From: Raj Bhattacharjea
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] ZeroMQ and Polar test failures on maint
> All,
>
> I've just checked out and built gnuradio 3.7
On Fri, 2016-02-19 at 12:01 -0500, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Fri, 19 Feb 2016 14:14:34 -0200
> From: Maicon Kist
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Problem with RX OFDM through the
> network
> Hello,
>
> I?m having similar problems exe
On Sun, 2016-03-06 at 08:49 -0500, discuss-gnuradio-requ...@gnu.org
wrote:
> Message: 5
> Date: Sun, 06 Mar 2016 06:45:13 + (GMT)
> From: Joshua Lilly
> Hello,
> My name is Josh and I am interested in getting involved in GNU radio.
> Specifically, I would like to work on the above project id
On Sun, 2016-03-06 at 16:33 -0500, West, Nathan wrote:
> On Sun, Mar 6, 2016 at 4:08 PM, Andy Walls
> wrote:
> 4. Create volk kernels to replace the main operations in the
> work()
> functions of these blocks, if you can. Since adding a
>
On Sun, 2016-03-06 at 16:33 -0500, West, Nathan wrote:
> By the way, if you choose to do this please don't be afraid to ask
> questions; this is a pretty well defined problem, but [...]
Hi Nathan,
Since you mentioned it, a question popped to my mind:
The current add_const blocks let integer o
these C/S specification to be written in a very
confusing manner. Just figuring out the allowed bandwidth of a
transmitter was confusing.
Have Fun.
-Andy
>
>
> Thanks again,
> Jesse
>
> On Tue, Mar 8, 2016 at 3:47 PM Andy Walls
> wrote:
>
> O
ocks defined.
> Thanks for your help,
> Josh
Regards,
Andy
>
> On Mar 06, 2016, at 01:08 PM, Andy Walls
> wrote:
>
> > On Sun, 2016-03-06 at 08:49 -0500, discuss-gnuradio-requ...@gnu.org
> > wrote:
> > > Message: 5
> > > Date: Sun, 06 Mar 2016 06:4
I, and
you will immediately see the difference.
Regards,
Andy
>
>
> Thanks for your help,
>
> Josh
>
> On Mar 06, 2016, at 01:08 PM, Andy Walls
> wrote:
>
> > On Sun, 2016-03-06 at 08:49 -0500, discuss-gnuradio-requ...@gnu.org
> > wro
On Sun, 2016-03-13 at 01:35 -0500, discuss-gnuradio-requ...@gnu.org
wrote:
> Message: 1
> Date: Sat, 12 Mar 2016 21:34:03 +
> From: "Landsman, Arik"
>
> Hello folks,
>
> I am trying to resolve the 90* ambiguity of costas for a QPSK
> receiver, and was hoping folks could weigh-in in case an
On Sun, 2016-03-13 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Message: 10
> Date: Sun, 13 Mar 2016 12:29:07 +
> From: Murray Thomson
Hi Murray,
>
> Hi,
>
> This is probably an easy one but I'm stuck and i could do with some help.
> My goal is to get a musical note from the mi
gards,
Andy
>
> Cheers,
>
> Murray
>
>
> On 13 March 2016 at 19:36, Andy Walls
> wrote:
> On Sun, 2016-03-13 at 12:00 -0400,
> discuss-gnuradio-requ...@gnu.org
> wrote:
> > Message: 10
> > Date: Su
Forgot to mention:
7. Restore the correct magnitude of the real audio by multiplying by the
magnitude we picked off of the complex audio signal at the original
frequencies. (multiply block)
-Andy
On Sun, 2016-03-13 at 16:28 -0400, Andy Walls wrote:
> On Sun, 2016-03-13 at 20:10 +, Mur
> From:
> Tom Golden
> Subject:
> Re: [Discuss-gnuradio] Ettus N210
> GMSK 9600
> Date:
> Wed, 23 Mar 2016 13:14:18 -0600
>
> __
> Here's my f
, because ISI drags some bits closer to 0 freq deviation.
But the timing recovery block is outputting 6 levels. It's getting the
timing of some of the bits slightly wrong. That has implications for
achievable BER for the SNR.
Regards,
Andy
>
>
> On Wed, Mar 23, 2016 at
Golden
> wrote:
> Hi Andy,
>
>
>
> Thanks so much for the link! I'm digging into the gr-ais code
> - but there's certainly a learning curve there. :)
>
>
From:
Tom Golden
Date:
Thu, 24 Mar 2016 13:07:57 -0600
>Sorry - I was attempting to be courteous to other users.
No worries. It's just that others can't learn and contribute, if the
conver
On Fri, 2016-03-25 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> I do have that fix in place. I added the tag_debug for time_est. I'm
> not
> sure which value causes the error, but I see:
>
> thread[thread-per-block[17]: ]:
> mmse_fir_interpolator_cc: imu out of bounds.
>
>
> ---
On Fri, 2016-03-25 at 12:22 -0400, Andy Walls wrote:
> On Fri, 2016-03-25 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:
> FWIW, I couldn't get the attached flowgraph (which looks to correlate to
> the HDLC flag) to crash. I was probably just lucky.
I forgot t
ed for AIS, but it will generically
deframe any HDLC (hopefully!).
-Regards,
Andy
>
> On Fri, Mar 25, 2016 at 10:51 AM, Andy Walls
> wrote:
> On Fri, 2016-03-25 at 12:22 -0400, Andy Walls wrote:
> > On Fri, 2016-03-25 at 12:00 -0400,
> discuss-gnuradi
lates the input,
I'd would probably be easier for me to see what's wrong about the
corr_est process.
Regards,
Andy
> Many Thanks,
> Arik
>
>
>
>
>
>
>
>
>
> From: Landsman, Arik
> Sent: Monday, March 14, 2016 11:59 AM
> To: Andy Walls;
On Fri, 2016-03-25 at 11:07 -0600, Tom Golden wrote:
> AX.25 data is NRZI encoded (so inverse bits and then NRZ). I hand
> calculated the HDLC frame start byte and first few address bytes
Hi Tom,
The attached flowgraph might save you the hassle of working out the NRZI
bit encoding by hand, for a
Hi Tom,
The corr_est block needs to match against the NRZI encoded symbols, so yes I
used 7 ones for the hdlc flag.
The HDLC flag has two possible NRZI encodings depending on the initial state:
0110 - HDLC flag byte
1 0001 - NRZI encoded HDLC flag byte, initial state 1
0110
On Sun, 2016-03-27 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
>
> Message: 5
> Date: Sat, 26 Mar 2016 15:05:02 -0400
> From: Andy Walls
> > From:
> > Tom Golden
> > Subject:
> > Re: [Discus
On Sun, 2016-03-27 at 14:03 -0400, Andy Walls wrote:
> On Sun, 2016-03-27 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:
> >
> > Message: 5
> > Date: Sat, 26 Mar 2016 15:05:02 -0400
> > From: Andy Walls
>
> > >
and
> so far, couldn't create one that worked.
>
>
> Thanks!!
You're welcome.
Now I have more uninteresting work to finish up - on a Holiday. :(
-Andy
> -Tom
>
> On Sun, Mar 27, 2016 at 12:20 PM, Andy Walls
> wrote:
> On Sun, 2016-03-27 at 14:
; pops here and there but not often
> enough to start considering BER testing for now.. costas output flips by 90*
> sporadically.
>
> finally, the gui plots are not in the order of the signal chain but are
> labeled properly. Hopefully easy to follow.
>
> And thanks again!
>
>
On Fri, 2016-04-01 at 09:18 -0400, Andy Walls wrote:
> In the generated *.py script I added one line near the end:
>
> print tb.get_modulated_preamble_untrimmed()
>
> So you can so this:
>
> $ source /setup_env.sh
> $ ./Rx_syncd.py | grep -v volk | se
This is OK as long as you are very close to the correct
center frequency. The measured phase rotation will become less correct the
farther you move from the measurement point at the peak of the correlation,
if you don't have good frequency lock when performing the correlation.
Regards,
Andy
&
Oh, I also added complex_to_arg and probably a complex to mag^2.
I don't know if either of these have controlport functionality.
I might have added other blocks I suppose, I'm typing this all from memory.
-Andy
On Sat, Apr 2, 2016 at 8:11 PM, Andy Walls
wrote:
> Hi Arik:
>
lem I'm experiencing. Strange it
>should matter just by being there.
>
>Tom
>
>
>
>> --
>> *From:* trond...@trondeau.com [trond...@trondeau.com] on behalf of
>Tom
>> Rondeau [t...@trondeau.com]
>> *Sent:* Sunday, April 03, 2016 11:22 AM
>> *To:* A
work.. did you modify
>thrift.conf in any way?
>____
>From: Andy Walls [a...@silverblocksystems.net]
>Sent: Sunday, April 03, 2016 11:36 AM
>To: Tom Rondeau; Landsman, Arik
>Cc: discuss-gnuradio@gnu.org
>Subject: Re: Debugging ControlPort/Thr
e-varying, fast
time-varying, etc.
- Carrier phase offset: constant, slow time-varying, fast time-varying,
etc.
- Rayleigh fading channel (no dominant LOS signal)
- Rician fading channel (one strong LOS)
- Narrow frequency selective fades in your signal bandwidth.
I suppose for extracting absolute p
On Sun, 2016-04-03 at 19:33 -0400, Andy Walls wrote:
> On Sun, 2016-04-03 at 20:24 +, Landsman, Arik wrote:
>
> > btw, played with tag delay manually, this has an immense effect on
> > costas rotation once fading model is added to channel.
>
> Well there are a number
On Tue, 2016-04-05 at 00:00 +, Landsman, Arik wrote:
> Hi Andy,
>
> Added a few comments inline (marked with "==" in lieu of a better email
> client)..
>
> But overall corr_est works very consistently. I did have a few observations:
Hi Arik:
For my responses to the next two, I'm assuming
> The audio codec is proprietary and not documented anywhere AFAIK so
> even if you demod the bitstream, you won't be able to do much with it.
> Thank you all for the conversation, it is pretty interesting. That makes
> sense
> that they have a proprietary protocol, it's a sham
On Fri, Apr 8, 2016 at 10:48 AM, Andy Walls
wrote:
>
> > The audio codec is proprietary and not documented anywhere AFAIK
> so
> > even if you demod the bitstream, you won't be able to do much
> with it.
>
> > Thank you all for the conversati
t see anywhere.
>
>This test was done with a hackrf tuned to 2.3265GHz, 20Msps, 8MHz
>analog filter - there is clearly something interesting going on when
>inline power is enabled with the "bias=1" argument.
>
>On Sat, Apr 9, 2016 at 6:32 AM, Andy Walls
> wrote:
>>
Forgot to add the list
-- Forwarded message --
From: Andy Walls
Date: Sat, Apr 16, 2016 at 4:16 PM
Subject: Re: [Discuss-gnuradio] matched filter for BPSK produced by phase
shifting
To: darem...@gmail.com
*From*: Laur Joost *Subject*: [Discuss-gnuradio] matched filter for BPSK
> outputs.
>> Complex filters are usually only needed when you need filter that is not
>> symmetrical about DC (your channel center, aka your baseband). If you
>> really
>> are at baseband (which you should be if performing clock recovery),
>> your pulse filter sh
what you've come up with may only work for QAM and PSK modulations
using generic_mod.
Regards,
Andy
> Just need to python it into the Rx in a neat way.
>
>
>
>
> ____
> From: Landsman, Arik
> Sent: Sunday, April 17, 2016 7:44
On Thu, 2016-05-12 at 16:24 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Wed, 11 May 2016 16:09:56 -0300
> From: Federico Larroca
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] VOLK division between complexes
> Hello everyone,
> We are on the stage of optimizing our project
On Tue, 2016-05-17 at 12:44 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Mon, 16 May 2016 22:51:45 +0200
> From: Marcus M?ller
> To: discuss-gnuradio@gnu.org
>
> Hi Martin,
>
> first of all: thanks for jumping through all these hoops to push
> PyBOMBS!
>
> So, trying to make things (es
On Wed, 2016-05-18 at 03:11 -0400, Anon Lister wrote:
> Andy,
[snip]
> Since I'm replying in the pybombs thread, I did try it and it broke
> pretty badly. Missing deps and such, I'd be willing to try to help get
> with that after I get the build down by hand and know what I can use
> from yum and
>
> OK, I was able to reproduce the issue, and it appears to me to a core
> GNURadio issue not specifically related to the installer
>
>
> udp_source_impl.cc is setting the SO_LINGER option on the UDP socket,
> which at least on Windows, causes a WSAENOPROTOOPT exception, because
> linger doesn'
On Thu, 2016-05-19 at 11:32 -0400, mle...@ripnet.com wrote:
> I'll comment that the Windows socket implementation isn't in
> compliance with the spirit of the robustness principle. But, whatevs.
> Easy enough to just remove that option for the UDP case.
>
I think it's a bit of a security fail
On Tue, 2016-05-24 at 10:37 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Tue, 24 May 2016 17:37:35 +0300
> From: Meelis N?mm
> Hello everyone,
>
>
> I have been working on a positioning implementation and for that I need
> very good time synchronization between the USRPs that are geog
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 t
From: Michael Dickens
Date: Thu, 28 Jul 2016 20:23:36 -0400
> On Thu, Jul 28, 2016, at 06:44 PM, Johnathan Corgan wrote:
>> The ZMQ REQ/REP dataflow has the receiving end REQuest data from the
sending end when needed, which REPlies with a packet. It's a form of
flow control.
>>
>> From the GNU
> From:
> Francisco Albani
> Subject:
> Re: [Discuss-gnuradio] ZMQ REQ /
> REP naming Swap?
> Date:
> Thu, 28 Jul 2016 23:21:25 -0300
>
> __
>
On Fri, 2016-07-29 at 11:49 -0400, Michael Dickens wrote:
> I'm looking for an OOT to do the REP /REQ way that GR does -not-
> provide, or will just create one myself. I don't anticipate adding it to
> the core gr-zeromq component. I agree that it would add unnecessary
> complexity to those alread
On Tue, 2016-08-23 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Message: 7
> Date: Mon, 22 Aug 2016 18:14:29 -0700 (MST)
> From: Paul Creaser
>
> I've just started studying methods used to detect and then filter out/remove
> cyclic noise from known signals.
>
> I have a signal of 2
On Tue, 2016-08-23 at 15:36 -0700, Richard Bell wrote:
> Great answer. I wish I could upvote it!
Thank you! You're too kind, in light of my typos (e.g. your -> you're,
of -> on). :)
> There should be a GNU Radio Stack Exchange type thing.
There is :)
http://stackoverflow.com/questions/tagg
On Wed, 2016-08-24 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Tue, 23 Aug 2016 16:42:33 -0700 (MST)
> From: Paul Creaser
> To: Discuss-gnuradio@gnu.org
> In a real system the signal would be a preamble, which would normally be used
> for synchronization purposes at the receive
On Wed, 2016-08-24 at 13:55 -0400, Andy Walls wrote:
> On Wed, 2016-08-24 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:
> > Date: Tue, 23 Aug 2016 16:42:33 -0700 (MST)
> > From: Paul Creaser
> > To: Discuss-gnuradio@gnu.org
>
> > In a real system the
> From:
> John Malsbury
> Subject:
> [Discuss-gnuradio] Rectangular
> Pulse Shape w/ PFB Clock Sync
> Date:
> Wed, 28 Sep 2016 00:07:46 -0700
>
>
> From:
> John Malsbury
> Subject:
> Re: [Discuss-gnuradio] Rectangular
> Pulse Shape w/ PFB Clock Sync
> Date:
> Thu, 29 Sep 2016 09:19:20 -0700
>
>
> From:
> Ellis, Duane
>
>
> Date:
> Tue, 18 Oct 2016 18:57:33 +
>
> __
> Hi,
>
> I've been working towards an FSK demodulator scheme using GNU radio (more
> spe
On October 18, 2016 3:39:28 PM EDT, Andy Walls
wrote:
>
>It works because the spectrum of a GMSK signal has two spectral peaks
>spaced equidistant from the center frequency.
Oops. "... spectrum of a *squared* GMSK signal has two
On Sun, 2016-04-03 at 13:01 -0400, Andy Walls wrote:
> >On April 3, 2016 11:31:02 AM EDT, Tom Rondeau wrote:
> >>On Sun, Apr 3, 2016 at 11:27 AM, Landsman, Arik wrote:
[snip]
> >>>> Here is some good info on how GRNURadio's control port works at a
> From:
> devin kelly
> Subject:
> Re: [Discuss-gnuradio] Segfault
> with
> volk_32fc_32f_dot_prod_32fc_a_avx
> Date:
> Wed, 7 Dec 2016 10:18:32 -0500
>
> ___
On Wed, 2016-12-07 at 12:10 -0500, Andy Walls wrote:
> > From GDB I can see
> >
> >
> > d_filtnum = 0
> > count = -67108696
> > d_out_idx = 0
> >
>
> This is a garbage-in, garbage-out problem I've seen exactly before with
> other blocks
y the Milky
Way is a large source of UHF noise.
>
> Thanks again for taking the time to put this all together. I will
> report back on how things are going and if mange to get clean
> recordings.
It was fun. Down where I live they've just upgraded to APCO P25, but
its all new and
On Sun, Jan 22, 2017 at 7:53 PM, Andy Walls wrote:
> On Sun, Jan 22, 2017 at 7:19 PM, Luke Berndt wrote:
>
>> Well, there was definitely a lot of noise! and I am pretty sure the source
>> was my computer. I got a couple of USB extension cables so I could get away
>> from
On Sun, 2017-01-22 at 20:22 -0500, Luke Berndt wrote:
> Thanks again for all the help! It is great to be getting clear audio
> and having things look right on the charts.
> - Luke
You're welcome.
One thing I forgot to mention, that might also help reception:
Use antennas that are at least a qu
If there is no information on the signal, why not just do a straight
energy detector:
source -> complex bandpass filter -> complex to mag -> burst/energy detector ->
QT Time sink (triggering on start of burst tag)
The complex bandpass filter just has to catch all the frequencies of
interest. (A
pidly.
Also, if I'm thinking about this properly:
To get faster lock in, you may want your frequency range of interest to
be somewhere in between Fs/4 and Fs/2; and not near DC. If you're
within the lock-in range of the PLL, you'll lock within 1 cycle. If
you're in the
at PLLs & the gnu radio block
> at some point. However I readily admit to being a software person not
> a DSP/Radio person. I have the day job to deal with today but I will
> have a study of the PLL block given Andy's tips and report back.
>
> Cheers
> Dirk
>
>
>
eers
> Dirk
>
> On 16 March 2017 at 07:22, Dirk Gorissen wrote:
>> Mmm, thats odd. Those settings should be correct, maybe something went
>> wrong with the recording :( I'll try to check in between things at
>> work today else will do so tonight.
>> Thanks for
On Thu, 2017-03-16 at 21:02 -0400, Andy Walls wrote:
> Hi Dirk,
>
> Thanks.
>
> Try the attached flowgraph. The pulse indicator output is a little crude
> at the moment (it needs some latching persistence for a human to read),
> but it does the job for a proof of concept.
> Hi Sverre,
>
> hm, I've taken the time to look at pulse_shaper_bs.py[1], but I didn't
> fully understand what it does, mathematically/technically.
>
>
>
> It does in fact look like a very complicated way to do something that
> I'm not 100% sure wouldn't be covered by a simple FIR filter, bu
On Fri, 2017-03-17 at 14:36 -0400, Andy Walls wrote:
> > Hi Sverre,
> >
> > hm, I've taken the time to look at pulse_shaper_bs.py[1], but I didn't
> > fully understand what it does, mathematically/technically.
> >
> >
> >
> > It doe
e PLL, so I didn't leave it in
the flowgraph.
Regards,
Andy
On Fri, Mar 17, 2017 at 11:46 AM, Andy Walls
wrote:
> On Thu, 2017-03-16 at 21:02 -0400, Andy Walls wrote:
>> Hi Dirk,
>>
>> Thanks.
>>
>> Try the attached flowgraph. The pulse indicator output i
t, Mar 18, 2017 at 6:30 PM, Dirk Gorissen wrote:
> Amazing Andy, thank you for putting this time in. Im still digesting
> this but will report back
>
> On 18 March 2017 at 20:45, Andy Walls wrote:
>> Dirk,
>>
>> Here is a revised flowgraph, slightly tweaked to reduc
Hi Dirk:
On Mon, Mar 20, 2017 at 1:04 PM, Dirk Gorissen wrote:
> Hi Andy,
>
> I have been experimenting with the flowgraphs, tried with some live
> data and it all works as expected. Just had to switch the threshold to
> 2 orders of magnitude smaller when using an airspy.
Yeah, that's expected r
Bah, I messed up my filter designs in that last flowgraph.
(Transition BW != Stopband Freq).
Never drink beer while designing filters. :)
See the attached, fixed flowgraph (v4).
-Andy
On Mon, Mar 20, 2017 at 9:30 PM, Andy Walls wrote:
> Hi Dirk:
>
> On Mon, Mar 20, 2017 at 1:04
Hi Dirk:
Since you asked about how to set PLL values, I've worked up a version
5 of the flowgraph (attached) to help with that.
First you'll need to build and install my OOT NOAA Weather Radio module:
https://github.com/awalls-cx18/gr-nwr
to get a modified version of the PLL Ref Out block. The m
Hi Achilleas:
In the test_cpm.py example under gr-trellis, there is a comment:
"# only works for N=2, do it manually for N>2..."
https://github.com/gnuradio/gnuradio/blob/master/gr-trellis/examples/python/test_cpm.py#L108
Could you, or anyone else, elaborate on what need to be done manually for
ter_xxx_0_0_0 = filter.fir_filter_ccc(Q,
> MF[1].conjugate())
>
>
>
> So what needs to be done is (through a for loop) instantiate these N
> filter blocks
> and appropriately modify the code (in the "connections" part) to make
> the right
> connections to and fro
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
s slightly over a great many samples due to
numerical roundoff, plus it can't be synchronously reset).
I was hoping using gr-trellis practically would have been a little bit
easier. :(
-Andy
> On Thu, Apr 6, 2017 at 12:38 PM Andy Walls
> wrote:
> > On Mon, 2017-04-03 at 09:06 -0
te how the t in 2*pi*f0*t could be
incorporated into the FSM state, since this phase term appears to be
part of the phase memory of the system, though not part of the
modulation memory. I couldn't see an obvious way to do that.
Regards,
Andy
On Thu, 2017-04-06 at 15:36 -0400, Andy Walls wr
> From:
> Fernando
> Subject:
> [Discuss-gnuradio] WBFM
> modulation/demodulation high
> frequencies highly attenuated
> Date:
> Wed, 26 Apr 2017 20:02:29 +0200
>
>
>
> ___
From: Dave NotTelling Date: Thu, 4 May 2017 21:52:04 -0400:
>
> __
> I can see that the threads are showing up with meaningful names using
> `top -H`. Names like `zmq_pub_sink_c1`. The `ps` command doesn't
> usually show me anyt
For a block that performs the identical function of the PFB clock synch
block with correct tag propagation, use the Symbol Synchronizer Block
available in this pull request:
https://github.com/gnuradio/gnuradio/pull/1294
https://github.com/awalls-cx18/gnuradio/tree/symbol_sync2
or this OOT module
loop filter)
for the damping factor.
-Andy
On Thu, 2017-06-08 at 14:08 -0400, Andy Walls wrote:
> For a block that performs the identical function of the PFB clock synch
> block with correct tag propagation, use the Symbol Synchronizer Block
> available in this pull request:
>
>
1 - 100 of 197 matches
Mail list logo
