Nice work. BTW, What's the application for this method?
On Tue, Jul 19, 2016 at 6:11 AM, Christopher Richardson
wrote:
> Hi Everyone
>
> I've just been working on an alternative approach
> for classification based on the following paper -
>
> Convolutional Radio Modulation Recognition Networks –
Hi,
I'm currently working on creating a TensorFlow graph model, which can be
loaded by my TFModel block, which will then connect to Sebastian's blocks
which are able to pick out signals along with having a neat GUI.
So soon, we should be able to determine the modulation schemes of arbitrary
signa
We have just published our first OOT module to Github (
https://github.com/drs-ss/gr-polaris )and would like to get the module
published on CGRAN. The instructions I found point me to the gnuradio-legacy
recipes repo. I am guessing we shouldn't be submitting pulls requests to the
legacy repo. S
I have the recipe file ready and it's published at:
https://github.com/drs-ss/drs-gr-recipes
-Brandon Smith
-Original Message-
From: Chris Kuethe [mailto:chris.kue...@gmail.com]
Sent: Tuesday, July 19, 2016 1:59 PM
To: Smith, Brandon
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss
Thanks - I already added a recipe.
I'm don't think the satisfy section is correct, as there are no
resullts returned by "apt search polaris" or "port search polaris" on
my machines.
On Tue, Jul 19, 2016 at 11:01 AM, Smith, Brandon wrote:
> I have the recipe file ready and it's published at:
> h
Thanks for the heads up. I'll add this to PyBOMBS.
On Tue, Jul 19, 2016 at 10:23 AM, Smith, Brandon wrote:
> We have just published our first OOT module to Github (
> https://github.com/drs-ss/gr-polaris )and would like to get the module
> published on CGRAN. The instructions I found point me to
I didn’t check that part, I was copying from another recipe. I can remove it
-Brandon Smith
-Original Message-
From: Chris Kuethe [mailto:chris.kue...@gmail.com]
Sent: Tuesday, July 19, 2016 2:18 PM
To: Smith, Brandon
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Adding
Actually "incorrect" is too strong. It's valid syntax, but it's a
no-op since there are no binary packages which would satisfy the
install.
On Tue, Jul 19, 2016 at 11:13 AM, Chris Kuethe wrote:
> Thanks - I already added a recipe.
>
> I'm don't think the satisfy section is correct, as there are n
Considering the simple flow graph attached, a random number is generated at
a sample rate of 32kHz. I’m seeking a method to ‘expose’ the floating
point number to external python code. This code would need to be updated at
every 'tic' of the sample rate. Initially I had considered using the probe
No worries, I didn't include it in my version of the recipe commit.
And when I copied the airspy recipe, I accidentally left in a libusb
dependency that I had to fix before merging. :-P
On Tue, Jul 19, 2016 at 11:29 AM, Smith, Brandon wrote:
> I didn’t check that part, I was copying from another
Hello Marcus:
Thank you for the quick reply. My initial thought was that the external
code would query the grc block at a rate of 32kHz. I WAS assuming that
there would be a unique value available every 1/32000s. Since this is not
the case, I'm left wondering how best to get all 32000samples p
I've been playing some lately with devices that don't provide an
inherent hardware timestamp, yet which can be run from a common clock,
and made coherent using cross-correlation estimation of timing offset.
Something that would make this easier--in that it would establish a
starting-point for
Well, there's multiple things you can do; a very easy thing would be to
put your external Python code into a GNU Radio block and let the GNU
Radio scheduler call it as soon as there's a "chunk" of fresh samples.
You could also go for message passing, or zmq inter-process messages. Or
simply take t
> Something that would make this easier--in that it would establish a
> starting-point for cross correlation, and thus reduce the window size
> over which one needs to estimate, would be if the scheduler could insert a
> time tag of some sort the FIRST time it calls a work function
> either ini
On 07/19/2016 04:53 PM, Sylvain Munaut wrote:
I don't see why this has to be done by the scheduler, I'd do that in
the source, or even as a separate OOT that just inserts that tag.
Doing it in the source means modifying each source to insert, but, maybe
that's the right thing to do.
Cheers,
Hi Ed,
to what do you need that number "delivered"? That's the interesting
point here; whether your external code "polls" a function, or expects to
get a message of some sorts, or listens on a socket, or...
Also note that it's not really like there's a constant "trickle" of
random numbers, one ev
Doing it in gr-osmosdr means that just about everything will gain
timestamping support at the same time.
On Tue, Jul 19, 2016 at 2:00 PM, Marcus D. Leech wrote:
> On 07/19/2016 04:53 PM, Sylvain Munaut wrote:
>>
>> I don't see why this has to be done by the scheduler, I'd do that in
>> the source
Question arising: would you want the tag to contain the time when
general_work() was called, or rather the time of the first sample? Note
that sources should usually be designed to be blocking until there's
data available! That way, between entering general_work() and actually
having the first samp
On 07/19/2016 05:10 PM, Chris Kuethe wrote:
Doing it in gr-osmosdr means that just about everything will gain
timestamping support at the same time.
Yes, although, gr-osmosdr defers the job of setting up work() functions
to the actual hardware drivers, so it still means the hardware
drivers m
Hi Marcus the elder,
wouldn't a block that adds that tag work, too?
I see that you, especially in a high-rate streaming scenario, wouldn't
want to have a "memcpy" block; and I see actual need for a GR
scheduler/buffer_reader enhancement that allows for blocks that are
"transparent" by means that
On 07/19/2016 05:13 PM, Marcus Müller wrote:
Question arising: would you want the tag to contain the time when
general_work() was called, or rather the time of the first sample? Note
that sources should usually be designed to be blocking until there's
data available! That way, between entering ge
Hi Craig,
cross-posting this on the GNU Radio discussion mailing list, since it's
pretty GR-specific; please follow up where you feel is more adequate.
"pmt.intern(repr(time.time()))" will be evaluated once, and the result
will be used to construct the message strobe block. So yes, the message
22 matches
Mail list logo
