Re: [Discuss-gnuradio] Correlation Estimator Over the Air
the
start byte bits.
-Andy
> These pictures are of the same communication session, screen-printed
> roughly 5 secs apart.
>
> (If the attachments don't make it through the mailing list, please let
> me
> know and I can host them elsewhere)
>
> I really appreciate your guys' help.
>
> Logan Washbourne
> Electrical Engineering Graduate Student
> (Electromagnetics)
>
>
> On Wed, Oct 14, 2015 at 1:31 PM, Washbourne, Logan <
> lwas...@ostatemail.okstate.edu> wrote:
>
> > Sean,
> >
> > Thanks for the tip! Is the k value the reference value in the AGC2
> block
> > or the max gain? Would you mind explaining the equation you used a
> little
> > more? From what I understand of it, the seq is the 1's and 0's that
> make up
> > the pseudorandom preamble, N is the sequence length and i is the
> specific
> > value of the sequence when summing. Is that right or am I way off
> base?
> >
> >
> >
> > Logan Washbourne
> > Electrical Engineering Graduate Student
> > (Electromagnetics)
> >
> >
> > On Wed, Oct 14, 2015 at 9:43 AM, Nowlan, Sean
> <sean.now...@gtri.gatech.edu
> > > wrote:
> >
> >> ?We saw a lot of improvement in the performance of the Correlation
> >> Estimator block once we calculated a level for the AGC. In our
> case, we're
> >> looking for a BPSK preamble that is a pseudorandom sequence. The
> corr_est
> >> block is provided with the match-filtered version of the preamble
> sequence.
> >> So we calculated the average energy per sample of that sequence as
> K =
> >> \frac{ \sum_{i}^{N}(\abs{seq}^2) }{ N }. (Sorry if the LaTeX
> notation is a
> >> bit off). So K is the target level we use in the AGC2 block. This
> seems to
> >> work pretty well for us.
> >>
> >>
> >> Sean
> >>
> >>
> >> --
> >> *From:* discuss-gnuradio-bounces
> +sean.nowlan=gtri.gatech@gnu.org
> >> <discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org> on
> behalf
> >> of Washbourne, Logan <lwas...@ostatemail.okstate.edu>
> >> *Sent:* Tuesday, October 13, 2015 12:03 PM
> >> *To:* GNURadio Discussion List
> >> *Subject:* Re: [Discuss-gnuradio] Correlation Estimator Over the
> Air
> >>
> >> Rich,
> >>
> >> Ah, that makes so much sense now. I was modulating all that came
> out of
> >> the costas loop and packing the bits into bytes which essentially
> means I
> >> was undoing the syncing the blocks before it were doing. This
> morning I
> >> tried searching for the preamble in the binary stream that was
> output from
> >> the constellation decoder and I found it. It was 98 samples in,
> which
> >> confused me, but now that I know I am looking for a tag then that
> makes
> >> perfect sense.
> >>
> >> I just tried that same process, looking for the preamble in the
> binary
> >> stream(using matlab) for the over the air program and I still can't
> find
> >> it, but I am going to play around with the AGC block and see if I
> can't
> >> tweak it enough to work.
> >>
> >> I really appreciate your help, I finally feel like I'm getting
> close to
> >> my goal.
> >>
> >> Logan Washbourne
> >> Electrical Engineering Graduate Student
> >> (Electromagnetics)
> >>
> >>
> >> On Tue, Oct 13, 2015 at 10:55 AM, Richard Bell
> <richard.be...@gmail.com>
> >> wrote:
> >>
> >>> Logan,
> >>>
> >>> How are you doing this test to see if the bit stream comes out?
> >>>
> >>> The corr_est block correlates against a known sequence and when
> the
> >>> correlation output is above a threshold, tags the local maximum
> item around
> >>> that beak. Now it's up to you to do something with that tag. It
> places the
> >>> tag at the very front of the correlation sequence, so one of the
> first
> >>> things you need to do is handle the tag placement. You have some
> control
> >>> over that with the builtin delay paramter, but sometimes that's
> not enough.
> >>>
> >>> I would recommend taking a step back and proving you know how to
> do the
> >>> transformations that don't involve synchronization and channel
> correction.
> >>> Take your input data, map it to symbols, modulate it and then
> immediately
> >>> reverse the process. No channel, no noise, no synch
Re: [Discuss-gnuradio] Correlation Estimator Over the Air
For our use case, since our preamble and payload use the same constellation, the double tag issue probably doesn't hurt us too much, so we haven't guarded against it. Qualitatively, as long as timing and phase offsets haven't diverged "too much" over the course of a few samples, the coarse estimates provided by sampling off-peak while still above threshold update the PFB Clock Sync and Costas loop states to get "close", and they seem to converge during the remainder of the preamble symbols before data payload symbols begin. If anybody has any comments on this, I'd love to hear them. Sean From: Richard Bell <richard.be...@gmail.com> Sent: Tuesday, October 20, 2015 3:48 PM To: Nowlan, Sean Cc: Andy Walls; discuss-gnuradio@gnu.org; lwas...@ostatemail.okstate.edu Subject: Re: [Discuss-gnuradio] Correlation Estimator Over the Air Andy, Sean, Even if you use a sequence that has good correlation properties, you will sometimes get a double tag. This happens when the correlation threshold is passed just at the end of a call to work. Upon the next call to work, the very first few samples may still be above the threshold, but the correlator has no way of knowing this was actually due to the peak it already tagged in the previous call to work, so it tags it again. Andy, how do you work around double or triple tags usually? The tag location in all my applications is vitally important to the rest of the system. I couldn't handle ambiguity in that location. Is your system just not as dependant on knowing exact frame start positions, or are there other helpers to find this exactly down the line in your systems? Very curious. Rich On Tue, Oct 20, 2015 at 12:32 PM, Nowlan, Sean <sean.now...@gtri.gatech.edu<mailto:sean.now...@gtri.gatech.edu>> wrote: Logan, I've been away from email for the last week so sorry for the delay. > Is the k value the reference value in the AGC2 block or the max gain? Would > you mind explaining the equation you used a little more? Yes, it's the reference value. I think the max gain is used to keep the AGC from blowing up. The equation I mentioned is essentially the Euclidean norm, which we applied to our 4x oversampled, root-raised cosine filtered, BPSK sequence of 0s and 1s mapped to constellation points -1+0j and +1+0j, respectively. The corr_est block is running at 4x oversampling of the baud rate. So for BPSK, you can use either GNU Radio or Matlab/Octave to create a root-raised cosine matched filter, map your preamble sequence to constellation points, and filter them. Then calculate the Euclidean norm of the upsampled, matched filtered sequence. That's what I called "K" in my previous message. Dividing by the length of this sequence gives you the average "energy" (unitless) of the sequence. Think of it this way: the corr_est block is a matched filter that will give maximum likelihood detection when 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 From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org<mailto:gtri.gatech@gnu.org> <discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org<mailto:gtri.gatech@gnu.org>> on behalf of Andy Walls <a...@silverblocksystems.net<mailto:a...@silverblocksystems.net>> Sent: Tuesday, October 20, 2015 12:38 PM To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Correlation Estimator Over the Air On Tue, 2015-10-20 at 11:46 -0400, discuss-gnuradio-requ...@gnu.org<mailto:discuss-gnuradio-requ...@gnu.org> wrote: > Message: 10 > Date: Tue, 20 Oct 2015 10:46:11 -0500 > From: "Washbourne, Logan" > To: GNURadio Discussion List > <discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>> > Subject: Re: [Discuss-gnuradio] Correlation Estimator Over the Air > Hello, > > I have still been working on getting the over the air communication to > work > and I think I have definitely narrowed it down to the AGC being the > problem. I took Sean's advice and calculated the average energy per > sample > for the preamble, which yielded me a value of .0078 Joules and I used > that > for the reference value in the AGC2 block. When I used that value as > the > reference, the correlation estimator wouldn't catch anything as > correlated. > It is a real possibility that I calculated the energy per sample > incorrectly. I calculated it by only sending the preamble over the > air, > then took the first 64 complex values( I used some code from the > octave > files in gr-utils, to convert file sink data to complex values) from > t
Re: [Discuss-gnuradio] Correlation Estimator Over the Air
We saw a lot of improvement in the performance of the Correlation Estimator
block once we calculated a level for the AGC. In our case, we're looking for a
BPSK preamble that is a pseudorandom sequence. The corr_est block is provided
with the match-filtered version of the preamble sequence. So we calculated the
average energy per sample of that sequence as K = \frac{
\sum_{i}^{N}(\abs{seq}^2) }{ N }. (Sorry if the LaTeX notation is a bit off).
So K is the target level we use in the AGC2 block. This seems to work pretty
well for us.
Sean
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
on behalf of
Washbourne, Logan
Sent: Tuesday, October 13, 2015 12:03 PM
To: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Correlation Estimator Over the Air
Rich,
Ah, that makes so much sense now. I was modulating all that came out of the
costas loop and packing the bits into bytes which essentially means I was
undoing the syncing the blocks before it were doing. This morning I tried
searching for the preamble in the binary stream that was output from the
constellation decoder and I found it. It was 98 samples in, which confused me,
but now that I know I am looking for a tag then that makes perfect sense.
I just tried that same process, looking for the preamble in the binary
stream(using matlab) for the over the air program and I still can't find it,
but I am going to play around with the AGC block and see if I can't tweak it
enough to work.
I really appreciate your help, I finally feel like I'm getting close to my goal.
Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
On Tue, Oct 13, 2015 at 10:55 AM, Richard Bell
> wrote:
Logan,
How are you doing this test to see if the bit stream comes out?
The corr_est block correlates against a known sequence and when the correlation
output is above a threshold, tags the local maximum item around that beak. Now
it's up to you to do something with that tag. It places the tag at the very
front of the correlation sequence, so one of the first things you need to do is
handle the tag placement. You have some control over that with the builtin
delay paramter, but sometimes that's not enough.
I would recommend taking a step back and proving you know how to do the
transformations that don't involve synchronization and channel correction. Take
your input data, map it to symbols, modulate it and then immediately reverse
the process. No channel, no noise, no synchronization. If you can't make this
simulation work, you are misunderstanding something.
Rich
On Mon, Oct 12, 2015 at 1:28 PM, Washbourne, Logan
> wrote:
Rich and others,
I added the AGC block to RX side and after playing with the parameters for
awhile I got a correlation spike! My next step was to confirm that my output
equalled my input (byte-wise). In order to accomplish this, I added a
Constellation Decoder block after the costas loop and used the constellation
object as the input parameter. Then I repacked the bits into 8 bit bytes and
saved it to a file. I also saved the input byte stream to a file. I looked at
those files in Matlab and so far I have not been able to find the preamble in
the output byte stream.
After not being able to determine if this communication system was working( the
TX and RX programs utilizing the USRPs), I took a step back and tried to figure
out how to confirm if the test_corr_est.grc had the same output as its input
and I'm running into the same problem, I haven't been able to find the preamble
in the output.
Both programs show a clear correlation spike, I just want to put my mind at
ease and verify if it's working through the actual bytes. One last note, the
packed output byte stream is roughly 5.5 times smaller than the input byte
stream, which I was expecting a really close 1:1 size, this makes me think I am
overlooking a consequence of one of the blocks, namely the Correlation
Estimator, Polyphase Clock Sync, or the Costas Loop.
Does anyone have any suggestions?
I know this thread is getting a little long, but I appreciate everyone's
patience with my questions.
Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
On Wed, Oct 7, 2015 at 11:26 AM, Richard Bell
> wrote:
Ah, yes. I suspect you don't have an AGC in your flowgraph? Whenever you're
thresholding against some static number, you need to be sure your input signal
is set to a known amplitude, which is what the AGC does for you. If you put an
AGC in the chain you should see peak values that get close to your simulation
values. The AGC produces a stable platform for the rest of your blocks to
Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis
Thanks, that did the trick. I got about 4e-5 BER and 1.1 % PER at 6dB Es/N0
with my particular CPFSK parameters.
From: Achilleas Anastasopoulos [mailto:anas...@umich.edu]
Sent: Saturday, September 12, 2015 1:21 PM
To: Nowlan, Sean <sean.now...@gtri.gatech.edu>
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using
gr-trellis
Sean,
I guess there was a missing normalization of the pulse.
Please add the line
p=p/sum(p)*Q/2.0;
just after the definition of the p pulse
p = numpy.ones(L*Q)
In addition, make sure you increase the Q (samples per symbol) considerably, ie
make it 16 or more. The reason is that h=25/3 results in a BIG bandwidth for
this constellation so it has to be appropriately samples in order to be
represented accurately.
let me know how it goes
Achilleas
On Thu, Sep 10, 2015 at 6:09 PM, Nowlan, Sean
<sean.now...@gtri.gatech.edu<mailto:sean.now...@gtri.gatech.edu>> wrote:
Thanks, Achilleas, Jan, Jeff for your responses. I think I understand the
format now, and I managed to build the gr-trellis documentation, which does
spell out answers for a lot of what I asked.
I’ve abandoned making my own FSM since I can just use the CPM utilities in
gr-trellis. However, I’m getting unexpected BER and PER when running
gr-trellis/examples/python/test_cpm.py with my CPFSK parameters, h = 25/3 and
L=1.
Diff of test_cpm.py with my simple modifications:
https://gist.github.com/nowls/5b2bc2aada87dc197e3f
$ python test_cpm.py
Using Volk machine: avx_64_mmx_orc
100 16868 100 0.16868 1.0
200 33852 200 0.16926 1.0
300 50786 300 0.16928667 1.0
400 67667 400 0.1691675 1.0
[…]
As you can see, PER is 100% and BER is pretty bad for 10 dB SNR. The
construction of the phase response, q, looks correct to me. Any idea what might
be going wrong?
Thanks,
Sean
From:
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org<mailto:gtri.gatech@gnu.org>
[mailto:discuss-gnuradio-bounces+sean.nowlan<mailto:discuss-gnuradio-bounces%2Bsean.nowlan>=gtri.gatech@gnu.org<mailto:gtri.gatech@gnu.org>]
On Behalf Of Achilleas Anastasopoulos
Sent: Thursday, September 10, 2015 1:28 PM
To: Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using
gr-trellis
Sean,
I just wanted to add to the previous answer:
Indeed gr-trellis (and the fsm class specifically) has a built in constructor
for generating the FSM corresponding to ANY CPM scheme.
It only requires three parameters as explained in the comments
in the file fsm.cc
The constructed FSM is NOT based on Proakis decomposition, but on the more
elegant decomposition by:
"A decomposition approach to CPM", IEEE Trans. Info Theory, March 1988
See also my own notes at
http://www.eecs.umich.edu/~anastas/docs/cpm.pdf
for all the details.
In this case for h=K/P, it does not matter whether K is even or odd, the number
of states is always = M^{L-1} * P (where M is the cardinality of the input
alphabet),
so in your case you'll have a trellis with 3 states as the previous email
suggested.
You may also find useful the python utility
make_cpm_signals(K,P,M,L,q,frac)
that can be found in gr-trellis/python
that generates the signal space for you.
(please see the above references for more info).
Finally, you can take a look at the example "test_cpm.py"
in the gr-trellis/examples/python
and make appropriate changes for your CPFSK signal.
Now you can always drop all the above and design your FSM and signals from
scratch. You can create the FSM from a file (this is explained in the
gr-trellis documentaion--which is generated from gr-trellis/doc/gr-trellis.xml).
The ouput symbol mapping is defined EXACTLY as you suggested in your email:
every line corresponds to the current state and every column to an input.
The entry is a number from 0 to I-1 (where I is the input cardinality).
How this index is translated to an actual signal IS NOT PART OF THE FSM
DEFINITION but part of the modulation definition as explained very extensively
in the gr-trellis documentation.
let me know if you have any further questions,
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis
Sure. Here was the pulse normalization fix Achilleas suggested:
https://github.com/gnuradio/gnuradio/pull/636
And this is a patch for CPFSK with modulation index h=25/3 (based off the PR
above):
https://gist.github.com/nowls/8566d649e20ac0fa6d4e
Sean
From: Dan CaJacob [mailto:dan.caja...@gmail.com]
Sent: Tuesday, September 15, 2015 2:36 PM
To: Nowlan, Sean <sean.now...@gtri.gatech.edu>; anas...@umich.edu
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using
gr-trellis
Hi Sean,
Any chance you can share your work?
On Tue, Sep 15, 2015 at 2:33 PM Nowlan, Sean
<sean.now...@gtri.gatech.edu<mailto:sean.now...@gtri.gatech.edu>> wrote:
Thanks, that did the trick. I got about 4e-5 BER and 1.1 % PER at 6dB Es/N0
with my particular CPFSK parameters.
From: Achilleas Anastasopoulos
[mailto:anas...@umich.edu<mailto:anas...@umich.edu>]
Sent: Saturday, September 12, 2015 1:21 PM
To: Nowlan, Sean
<sean.now...@gtri.gatech.edu<mailto:sean.now...@gtri.gatech.edu>>
Cc: Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using
gr-trellis
Sean,
I guess there was a missing normalization of the pulse.
Please add the line
p=p/sum(p)*Q/2.0;
just after the definition of the p pulse
p = numpy.ones(L*Q)
In addition, make sure you increase the Q (samples per symbol) considerably, ie
make it 16 or more. The reason is that h=25/3 results in a BIG bandwidth for
this constellation so it has to be appropriately samples in order to be
represented accurately.
let me know how it goes
Achilleas
On Thu, Sep 10, 2015 at 6:09 PM, Nowlan, Sean
<sean.now...@gtri.gatech.edu<mailto:sean.now...@gtri.gatech.edu>> wrote:
Thanks, Achilleas, Jan, Jeff for your responses. I think I understand the
format now, and I managed to build the gr-trellis documentation, which does
spell out answers for a lot of what I asked.
I’ve abandoned making my own FSM since I can just use the CPM utilities in
gr-trellis. However, I’m getting unexpected BER and PER when running
gr-trellis/examples/python/test_cpm.py with my CPFSK parameters, h = 25/3 and
L=1.
Diff of test_cpm.py with my simple modifications:
https://gist.github.com/nowls/5b2bc2aada87dc197e3f
$ python test_cpm.py
Using Volk machine: avx_64_mmx_orc
100 16868 100 0.16868 1.0
200 33852 200 0.16926 1.0
300 50786 300 0.16928667 1.0
400 67667 400 0.1691675 1.0
[…]
As you can see, PER is 100% and BER is pretty bad for 10 dB SNR. The
construction of the phase response, q, looks correct to me. Any idea what might
be going wrong?
Thanks,
Sean
From:
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org<mailto:gtri.gatech@gnu.org>
[mailto:discuss-gnuradio-bounces+sean.nowlan<mailto:discuss-gnuradio-bounces%2Bsean.nowlan>=gtri.gatech@gnu.org<mailto:gtri.gatech@gnu.org>]
On Behalf Of Achilleas Anastasopoulos
Sent: Thursday, September 10, 2015 1:28 PM
To: Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using
gr-trellis
Sean,
I just wanted to add to the previous answer:
Indeed gr-trellis (and the fsm class specifically) has a built in constructor
for generating the FSM corresponding to ANY CPM scheme.
It only requires three parameters as explained in the comments
in the file fsm.cc
The constructed FSM is NOT based on Proakis decomposition, but on the more
elegant decomposition by:
"A decomposition approach to CPM", IEEE Trans. Info Theory, March 1988
See also my own notes at
http://www.eecs.umich.edu/~anastas/docs/cpm.pdf
for all the details.
In this case for h=K/P, it does not matter whether K is even or odd, the number
of states is always = M^{L-1} * P (where M is the cardinality of the input
alphabet),
so in your case you'll have a trellis with 3 states as the previous email
suggested.
You may also find useful the python utility
make_cpm_signals(K,P,M,L,q,frac)
that can be found in gr-trellis/python
that generates the signal space for you.
(please see the above references for more info).
Finally, you can take a look at the example "test_cpm.py"
in the gr-trellis/examples/python
and make appropriate changes for your CPFSK signal.
Now you can always drop all the above and design your FSM and signals from
scratch. You can create the FSM from a file (this is explained in the
gr-trellis documentaion--which is generated from gr-trellis/doc/gr-trellis.xml).
The ouput symbol mapping is defined EXACTLY as you suggested in your email:
every line corresponds to the current state and every column to an input.
The entry is a number from 0 to I-1 (where I is the input cardinality).
How this index is translated to an actual signal IS NOT PART OF THE FSM
DEFINITION but part of the modulation definition as explained
Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis
The BER and PER seem to be very sensitive to the oversampling factor (samples per symbol), Q. For low Q, Achilleas’ point about needing more samples to get a better resolution on the symbol matched filters makes sense. However, I’m not sure why there’s a big jump in performance from Q=8 to Q=12, or why performance gets worse for Q>12. But based on this limited test, Q=12 looks like a good candidate. QBERPER 4 1.040e-030.2344 8 1.095e-030.2455 12 2.637e-050.0068 16 3.340e-050.0084 24 3.867e-050.0098 32 3.359e-050.0086 48 4.238e-050.0108 > I got about 4e-5 BER and 1.1 % PER at 6dB Es/N0 with my particular CPFSK > parameters. By the way, the above claim was with Q=48. Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Nowlan, Sean Sent: Tuesday, September 15, 2015 3:40 PM To: Dan CaJacob <dan.caja...@gmail.com>; anas...@umich.edu Cc: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis Sure. Here was the pulse normalization fix Achilleas suggested: https://github.com/gnuradio/gnuradio/pull/636 And this is a patch for CPFSK with modulation index h=25/3 (based off the PR above): https://gist.github.com/nowls/8566d649e20ac0fa6d4e Sean From: Dan CaJacob [mailto:dan.caja...@gmail.com] Sent: Tuesday, September 15, 2015 2:36 PM To: Nowlan, Sean <sean.now...@gtri.gatech.edu<mailto:sean.now...@gtri.gatech.edu>>; anas...@umich.edu<mailto:anas...@umich.edu> Cc: Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis Hi Sean, Any chance you can share your work? On Tue, Sep 15, 2015 at 2:33 PM Nowlan, Sean <sean.now...@gtri.gatech.edu<mailto:sean.now...@gtri.gatech.edu>> wrote: Thanks, that did the trick. I got about 4e-5 BER and 1.1 % PER at 6dB Es/N0 with my particular CPFSK parameters. From: Achilleas Anastasopoulos [mailto:anas...@umich.edu<mailto:anas...@umich.edu>] Sent: Saturday, September 12, 2015 1:21 PM To: Nowlan, Sean <sean.now...@gtri.gatech.edu<mailto:sean.now...@gtri.gatech.edu>> Cc: Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis Sean, I guess there was a missing normalization of the pulse. Please add the line p=p/sum(p)*Q/2.0; just after the definition of the p pulse p = numpy.ones(L*Q) In addition, make sure you increase the Q (samples per symbol) considerably, ie make it 16 or more. The reason is that h=25/3 results in a BIG bandwidth for this constellation so it has to be appropriately samples in order to be represented accurately. let me know how it goes Achilleas On Thu, Sep 10, 2015 at 6:09 PM, Nowlan, Sean <sean.now...@gtri.gatech.edu<mailto:sean.now...@gtri.gatech.edu>> wrote: Thanks, Achilleas, Jan, Jeff for your responses. I think I understand the format now, and I managed to build the gr-trellis documentation, which does spell out answers for a lot of what I asked. I’ve abandoned making my own FSM since I can just use the CPM utilities in gr-trellis. However, I’m getting unexpected BER and PER when running gr-trellis/examples/python/test_cpm.py with my CPFSK parameters, h = 25/3 and L=1. Diff of test_cpm.py with my simple modifications: https://gist.github.com/nowls/5b2bc2aada87dc197e3f $ python test_cpm.py Using Volk machine: avx_64_mmx_orc 100 16868 100 0.16868 1.0 200 33852 200 0.16926 1.0 300 50786 300 0.16928667 1.0 400 67667 400 0.1691675 1.0 […] As you can see, PER is 100% and BER is pretty bad for 10 dB SNR. The construction of the phase response, q, looks correct to me. Any idea what might be going wrong? Thanks, Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org<mailto:gtri.gatech@gnu.org> [mailto:discuss-gnuradio-bounces+sean.nowlan<mailto:discuss-gnuradio-bounces%2Bsean.nowlan>=gtri.gatech@gnu.org<mailto:gtri.gatech@gnu.org>] On Behalf Of Achilleas Anastasopoulos Sent: Thursday, September 10, 2015 1:28 PM To: Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis Sean, I just wanted to add to the previous answer: Indeed gr-trellis (and the fsm class specifically) has a built in constructor for generating the FSM corresponding to ANY CPM scheme. It only requires three parameters as explained in the comments in the file fsm.cc The constructed FSM is NOT based on Proakis decomposition, but on the more elegant decomposition by: "A decomposition approach to CPM", IEEE Trans. Info Theory, March 1988 See also my own notes at http://www.eecs.umich.edu/~
Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis
Thanks, Achilleas, Jan, Jeff for your responses. I think I understand the
format now, and I managed to build the gr-trellis documentation, which does
spell out answers for a lot of what I asked.
I’ve abandoned making my own FSM since I can just use the CPM utilities in
gr-trellis. However, I’m getting unexpected BER and PER when running
gr-trellis/examples/python/test_cpm.py with my CPFSK parameters, h = 25/3 and
L=1.
Diff of test_cpm.py with my simple modifications:
https://gist.github.com/nowls/5b2bc2aada87dc197e3f
$ python test_cpm.py
Using Volk machine: avx_64_mmx_orc
100 16868 100 0.16868 1.0
200 33852 200 0.16926 1.0
300 50786 300 0.16928667 1.0
400 67667 400 0.1691675 1.0
[…]
As you can see, PER is 100% and BER is pretty bad for 10 dB SNR. The
construction of the phase response, q, looks correct to me. Any idea what might
be going wrong?
Thanks,
Sean
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Achilleas Anastasopoulos
Sent: Thursday, September 10, 2015 1:28 PM
To: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using
gr-trellis
Sean,
I just wanted to add to the previous answer:
Indeed gr-trellis (and the fsm class specifically) has a built in constructor
for generating the FSM corresponding to ANY CPM scheme.
It only requires three parameters as explained in the comments
in the file fsm.cc
The constructed FSM is NOT based on Proakis decomposition, but on the more
elegant decomposition by:
"A decomposition approach to CPM", IEEE Trans. Info Theory, March 1988
See also my own notes at
http://www.eecs.umich.edu/~anastas/docs/cpm.pdf
for all the details.
In this case for h=K/P, it does not matter whether K is even or odd, the number
of states is always = M^{L-1} * P (where M is the cardinality of the input
alphabet),
so in your case you'll have a trellis with 3 states as the previous email
suggested.
You may also find useful the python utility
make_cpm_signals(K,P,M,L,q,frac)
that can be found in gr-trellis/python
that generates the signal space for you.
(please see the above references for more info).
Finally, you can take a look at the example "test_cpm.py"
in the gr-trellis/examples/python
and make appropriate changes for your CPFSK signal.
Now you can always drop all the above and design your FSM and signals from
scratch. You can create the FSM from a file (this is explained in the
gr-trellis documentaion--which is generated from gr-trellis/doc/gr-trellis.xml).
The ouput symbol mapping is defined EXACTLY as you suggested in your email:
every line corresponds to the current state and every column to an input.
The entry is a number from 0 to I-1 (where I is the input cardinality).
How this index is translated to an actual signal IS NOT PART OF THE FSM
DEFINITION but part of the modulation definition as explained very extensively
in the gr-trellis documentation.
let me know if you have any further questions,
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis
I'm trying to demodulate a CPFSK signal using the Viterbi algorithm. The
gr-trellis module seems to have most of the components I'll need, but I'm
having trouble figuring out how to wrangle my problem into the FSM format.
Basically, I have a binary CPFSK signal with a modulation index, h=25/3.
Following the guidance of [1] section 3.3-2, I know that for CPM with rational
h=m/p, (here, m=25 and p=3), with m odd, I have 2p=6 phase states. I worked out
the phase trajectories and took them modulo 2*pi to get this set of terminal
phase states: {0, pi/3, 2*pi/3, pi, 4*pi/3, 5*pi/3}.
I'm trying to understand the FSM format in gr-trellis, and how to build my FSM.
If you consider the set of terminal phase states above as being zero-indexed,
the phase transitions should go according to the "Next state" mapping of the
FSM file format below. I've added my comments as to my understanding of the
format. Please correct me if I'm wrong.
FSM file:
2 6 2 # 2 possible input symbols // 6 possible FSM states // 2 possible
output symbols
# Next state mapping
5 1 # if in state 0 and a 0 is received, go to state 5, else (1 is
received, and) go to state 1
0 2 # if in state 1 and a 0 is received, go to state 0, else go to
state 2
1 3 # ...
2 4
3 5
4 0
# Output symbol mapping
[...]
I'm having trouble understanding how to define the output symbol mapping. Is
there a plain-language interpretation like the one I spelled out for Next state
mapping in my comments above?
Thanks!
Sean
[1] Proakis & Salehi, Digital Communications, 5ed.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency
If we don’t just document with comments in the proper places in the OOT structure, I was thinking we could have the user list GR required components in the gr_modtool interactive configuration. It wouldn’t solve all problems like the file_sink_base issue, but it would be a good start. Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Tom Rondeau Sent: Friday, July 31, 2015 1:57 PM To: Valenta, Chris R. Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Fri, Jul 31, 2015 at 1:52 PM, Valenta, Chris R. chris.vale...@gtri.gatech.edumailto:chris.vale...@gtri.gatech.edu wrote: Ah, so I figured it out. Not only did I need to add #define BLOCKS_API to my swig .i file, but I also had to add %include “gnuradio/blocks/file_sink_base.h” as well. Ah, of course! Good catch. We should have this documented somewhere -- how to use GNU Radio classes and blocks in OOT projects. Tom From: Valenta, Chris R. Sent: Friday, July 31, 2015 11:30 AM To: 'Tom Rondeau' Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency Yes, blocks is included in the cmakelists.txt as set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS) as well as a link directory GNURADIO_BLOCKS_LIBRARY_DIRS. Its also in the /lib cmakelists.txt as a target_link_library GNURADIO_BLOCKS_LIBRARIES. BLOCKS_API was not in the swig .i file. I added this, ran make clean, make, and installed and still get the same error. From: trond...@trondeau.commailto:trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Friday, July 31, 2015 11:02 AM To: Valenta, Chris R. Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Fri, Jul 31, 2015 at 10:50 AM, Valenta, Chris R. chris.vale...@gtri.gatech.edumailto:chris.vale...@gtri.gatech.edu wrote: So the function (set_unbuffered) that’s coming up as not being found is in file_sink_base.h which is included in the file_sink.h so I’m pretty sure I’m ok here. The swig file just includes file_sink.h….I tried adding file_sink_base.h to this as well, but it didn’t change anything. For the time being, I’m replicating the file_sink block exactly (except the name) to try and get it to compile OOT. However, since file_sink depends on file_sink_base, which I’m not copying, I think there are problems linking to it. Would it be better to also copy file_sink_base to my OOT module? You should be able to use file_sink_base from libgnuradio-blocks.so, so no, keep that one in tree so you're not carrying around extra stuff. First, do you have BLOCKS as one of the GNU Radio required components in your CMakeLists.txt file? Also, and I suspect this might be the real problem, do you #define BLOCKS_API in you .i file? There should be a #define for your module's name already; just add this line here along with that one. Tom From: trond...@trondeau.commailto:trond...@trondeau.com [mailto:trond...@trondeau.commailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Friday, July 31, 2015 10:27 AM To: Valenta, Chris R. Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency On Thu, Jul 30, 2015 at 5:26 PM, Valenta, Chris R. chris.vale...@gtri.gatech.edumailto:chris.vale...@gtri.gatech.edu wrote: I’m trying to make an out of tree module based on blocks::file_sink that has some additional functionality I need. Right now, I’ve built it OOT, but an having trouble getting it to work. The code (file_sink_impl.cc, file_sink_impl.h, and file_sink.h -- actual names are different so there are no conflicts) are all identical to the ones in tree. I used gr-modtool to create the OOT modules with this block and it makes and installs fine. However, when I try to use it, I get the following error: AttributeError: ‘file_sink_sptr’ object has no attribute ‘set_unbuffered’ What I think is happening here is that the OOT version of my code isn’t linking to the file_sink_base in gnuradio-blocks to inherit this function. Browsing previous mail lists, Marcus Muller noted in the thread ‘ [Discuss-gnuradio] Out of Tree linker error... libgnuradio-MYMOD.so:‘ that the problem might be in my cmake files. He referenced gr-specest as an example which uses in tree modules. I compared the cmakelists.txt in gr-specest to the OOT module directory and in the OOT/lib directory and added the BLOCKS references in the appropriate places. However, this still hasn’t solved the problems. Are there any other steps necessary to make and install an OOT modules with in tree dependencies? All of this is running on Ubuntu 14.04LTS with gnuradio 3.7.7.1 The first thing that comes to mind
Re: [Discuss-gnuradio] Simple BPSK modulation with alternating 1's and 0's
FYI - copying the GNU Radio mailing list, which would be a more appropriate place to post a question such as this one. Some comments on your GNU Radio setup: * You're using a PSK Mod block, which applies a root-raised cosine pulse-shaping filter to the +1/-1 stream, so you wouldn't exactly see +1/-1 at the output, but instead the sum of symbol-period delayed filter responses. * If you look at the documentation for the PSK Mod block in GRC, it will tell you that the input expects unsigned chars, which equates to values in the range [0,256). Instead of using a vector source, use a Random Source with Minimum=0 and Maximum=256 to feed the PSK Mod block. * Your throttle block is what's setting the sample rate in this example, and the modulator is using 4 sps (samples-per-symbol), so your symbol rate is 32k/4 = 8 ksym/s. Since this is BPSK, the data rate is also 8 kbps. * If you were to use a USRP to transmit, you would set its sample rate and then change the SPS to achieve the desired symbol rate: sym_rate = usrp_samp_rate / SPS. * If you're using the QT GUI Constellation Sink, it will display all the complex points, including those interpolated by the filter in the PSK Mod block. Therefore you won't see symbol-clock sampled constellation points - you will also see intermediate points as the signal transitions between constellation points. From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of Moon, Seung - Exelis via USRP-users Sent: Wednesday, July 22, 2015 2:55 PM To: usrp-us...@lists.ettus.com Subject: [USRP-users] Simple BPSK modulation with alternating 1's and 0's Hello, I'm currently working an intern, and my teammate and I are trying to generate a simple BPSK modulated signal. We both lack knowledge on GNURadio and communications for our project, so we are hoping to get some help online. Currently, I have a repeating vector source of alternating 1 and 0 which feeds into PSK modulator block (constellation point: 2, gray code: Y, differential encoding: Y, sps: 4, excess BW: .35) which feeds into a throttle block (sample rate: 32k) which then feeds into a GUI sink. On the GUI constellation diagram, we see some points that are not situated at +1 and -1. We are not sure on how to interpret what we are seeing on the constellation diagram. From my understanding, BPSK modulation modulates our data to +1 and -1. Ultimately, we will be using USRP B200 to transmit our signal to lock on to a receiver which expects a BPSK modulated signal at certain data rate (let's say 1kbps). We are also unsure on how to transmit our data at the desired data rate. Any guidance will be greatly appreciated. Thank you for your interest. Have a wonderful day. This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Exelis Inc. The recipient should check this e-mail and any attachments for the presence of viruses. Exelis Inc. accepts no liability for any damage caused by any virus transmitted by this e-mail. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Debug Question
Neither of these are C++ commands, but they may do what you want: To limit output to 100 lines, you could do the following: $ ./my_flowgraph.py | head -n 100 Or insert a head block in your flowgraph and choose an appropriate number of samples to process. Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Marcus Müller Sent: Tuesday, July 21, 2015 3:07 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Debug Question Hi Rich Best approach is very probable running your flow graph in gdb and specifying a break point: gdb --args python /path/to/flow_graph.py ... break source_code.cc:121 blablabla not loaded, do you want to add it as soon as blabla? Y run if you really want to enforce this in the source code itself: #include csignal ... std::raise(std::SIGINT); // not quite sure which namespace raise and SIGINT end up in; try without std:: on either Best regards, Marcus On 21.07.2015 20:50, Richard Bell wrote: I'm looking for a way to stop my flowgraph through a C++ command just so I can see a few std::cout debug statements without freezing my console due to massive std::couts. Is there a way of doing this? Rich ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orgmailto: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] Tag Propagation Question
First, there may be multiple tags per sample. Use “get_tags_in_range” or
“get_tags_in_window” to get all the tags you need. Using “get_tags_in_window(0,
noutput_items, …)” will get you all the tags associated with samples passed as
your inputs. (Perhaps you know this already and were just choosing a toy
example, but I wanted to make it clear).
There is a pruning routine in the scheduler that will toss out “old” tags,
i.e., tags that have been accounted for based on “nitems_read”, which is
updated when you call consume_each. So I think you will end up getting the last
5 tags again on the next call to work. But you have already propagated them, so
you will be adding duplicates. The solution is to only propagate tags in the
range that you intend to tell the scheduler you’ve consumed.
(Caveat emptor: I haven’t tested this out, but I believe this is how it would
work).
Sean
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Richard Bell
Sent: Monday, July 20, 2015 3:51 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Tag Propagation Question
If I set_tag_propagation policy(TPP_DONT) and then re-add all tags in range to
the output, but only produce a portion of the input items to output, what
effect does this have?
Here is a good corner case example of what I mean:
Suppose I'm given 10 items, and every item has a tag associated with it. I then
make the following actions
set_tag_propagation policy(TPP_DONT)
for( ii = 0; ii 9; ii++)
{
add_item_tag(0, tags[ii].offset, tags[ii].key, tags[ii].value,
tags[ii].srcid);
}
consume_each(5);
return 5;
I'm concerned this might cause tags to be added or lost.
Thanks,
Rich
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph locking up with Stream Mux
Yes, that’s a workaround. My point is that this issue is not obvious to somebody who isn’t familiar with how the scheduler works. When using null sources, it makes sense to just use two of them. But what if you’re supplying a data stream and need to inject a synchronization sequence in the middle, as GSM does? In this case, my workaround is using a Deinterleave block to split a burst of data into two branches fed to the first and third ports of a Stream Mux, and a Vector Source with the sync sequence fed to the second Mux port. This works fine for me. I still wonder if there’s a way to prevent people from stumbling into the issue that’s causing the lock up. Sean From: Richard Bell [mailto:richard.be...@gmail.com] Sent: Thursday, July 09, 2015 3:40 AM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Flowgraph locking up with Stream Mux I think it's the fact that you are feeding two different ports of the mux by one null source that is the issue. The first ports buffer fills before the third ports buffer does. When the first is full, it prevents null source from creating new outputs, which will cause the graph to stall on the third port waiting for items. Use two distinct null sources and I think it will run fine. Sent from my iPhone On Jul 8, 2015, at 7:26 PM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: I’m somehow getting a simple flowgraph to lock up GNU Radio. It locks up every time I run it, after roughly the same amount of time. As you can see in the attached image and GRC file, I’m feeding two inputs of a Stream Mux block from the same upstream block. Do you imagine why that might cause problems? I know there are other ways to do what I’ve shown here, but locking up seems like a bug. Thanks, Sean simple_failing_flowgraph.png stream_mux_bug_test.grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orgmailto: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] Flowgraph locking up with Stream Mux
Null source just sets all outputs to zero, so it’s equivalent to a constant
source with the scalar=0.
…
for(size_t n = 0; n input_items.size(); n++) {
optr = (void*)output_items[n];
memset(optr, 0, noutput_items *
output_signature()-sizeof_stream_item(n));
}
…
I think this is some subtle issue with Stream Mux’s forecast function and how
it interacts with the scheduler knowing when to advance read pointers from the
upstream block. This is just a wild guess, though. Also, I’ve seen an upstream
block connect to two inputs of a Multiply block to create a squaring device,
and that seems to work just fine. But in Stream Mux’s case, it’s only copying
from one input at a time.
Sean
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Jeon
Sent: Wednesday, July 08, 2015 10:46 PM
To: Discuss GNU Radio mailing list
Subject: Re: [Discuss-gnuradio] Flowgraph locking up with Stream Mux
whileni didnt look into null source block code,
but the basic behavior of null source block is,
it outputs nothing.
So stream mux waits until input blocks pass a given number of samples and it
takes forever
Regards
Jeon
2015. 7. 9. 오전 11:27에 Nowlan, Sean
sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu님이 작성:
I’m somehow getting a simple flowgraph to lock up GNU Radio. It locks up every
time I run it, after roughly the same amount of time. As you can see in the
attached image and GRC file, I’m feeding two inputs of a Stream Mux block from
the same upstream block. Do you imagine why that might cause problems?
I know there are other ways to do what I’ve shown here, but locking up seems
like a bug.
Thanks,
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.orgmailto: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] Flowgraph locking up with Stream Mux
I'm somehow getting a simple flowgraph to lock up GNU Radio. It locks up every time I run it, after roughly the same amount of time. As you can see in the attached image and GRC file, I'm feeding two inputs of a Stream Mux block from the same upstream block. Do you imagine why that might cause problems? I know there are other ways to do what I've shown here, but locking up seems like a bug. Thanks, Sean stream_mux_bug_test.grc Description: stream_mux_bug_test.grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Additional code to GRC flowgraph
One way to do this is to create a flowgraph, such as foo.grc. This will
generate a Python file that you can import into another file, bar.py:
#!/usr/bin/env python2
import foo
if __name__ == '__main__':
tb = foo.foo()
# custom code
print samp_rate:, tb.get_samp_rate()
# standard stuff
tb.start()
try:
raw_input('Press Enter to quit: ')
except EOFError:
pass
tb.stop()
tb.wait()
You can add custom stuff into bar.py while being able to modify foo in GRC. I'm
not sure if this applies directly to what you want to do, but I've found it
useful for testing while avoiding having GRC overwrite your custom code.
Of course, another way to do this is to export your flowgraph as a hierarchical
block, which you then import into a top level flowgraph. Your top level can
stay the same but you can keep iterating on the hierarchical block.
Sean
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Marcus Müller
Sent: Monday, July 06, 2015 9:33 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Additional code to GRC flowgraph
As I said, if that's the case, avoid using function probes but just use the
MPSK estimator (not the estimator probe), and write your own block that just
takes the tags that come from that, and translates them to messages that you
send to another block that does something useful with them (e.g. adjusting a
frequency correction etc.)
Best regards,
Marcus
On 07/06/2015 12:11 PM, Daniel Brogren wrote:
Sorry for for that I thought the imoprt block was a type of block that I
could create from the modtool.
but
In the import-block I can import modules. But I can still not import actuall
code into my top_block and I can not call functions from the import-block. What
I want to avoid is to add code in the top_block manually since I'm normally
using the GRC to generate the top_block.
/Daniel
Date: Mon, 6 Jul 2015 09:43:24 +0200
From: marcus.muel...@ettus.commailto:marcus.muel...@ettus.com
To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Additional code to GRC flowgraph
Try the block search (magnifier button in GRC), type in import :)
On 07/06/2015 09:33 AM, Daniel Brogren wrote:
Hi again
I have a MPSK SNR Estimator Probe and a Function Probe that calculates the SNR.
I can not find any information regarding import block.
BR
Daniel Brogren
Date: Fri, 3 Jul 2015 18:46:12 +0200
From: marcus.muel...@ettus.commailto:marcus.muel...@ettus.com
To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Additional code to GRC flowgraph
Hi Daniel,
if your code really just looks like
from awesometoolkit import skynet
skynet.kill_sarah()
you can put that into an import block.
But: what you describe doesn't sound like you want to modify the top
block -- it sounds more like you'd want a block to calculate SNR, and
every f_sample*3 samples change some other block.
Now, this completely depends on the block where the freq. offset is
used, but you can just write a block (in python or C++, only matters for
performance), and give that block an message output port, and send
messages containing the changed parameter to the block that needs
adjustment.
If you take a look at the frequency xlating fir filter block, it has a
message port named freq, which takes in PMT messages in form of
tuples; these tuples must be of the form
pmt.pair(pmt.intern(freq), pmt.from_double(123.131) )
Best regards,
Marcus
On 07/03/2015 04:27 PM, Daniel Brogren wrote:
Hi
I'm working with a receiver application in GNU Radio Companion. I would
like to add some additional code to the top block but I still want to be
able to work with the GRC. Is there a way to add this extra code without
the code will be removed when I re-generate the flowgraph from GRC
or
Could I create a new block that can access the variables in the top block
or can execute the set/get functions for the variables in the top block.
What I'm trying to accomplish is that every 3rd second I will check the SNR
and then do som trimming of a freq-offset. I'm a newbie with GNU Radio and
Python but have read through the guided tutorials.
BR
Daniel Brogren
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.orgmailto:Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.orgmailto:Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.orgmailto:Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Include an OOT module in another OOT module?
?Strange. It is now working for me, and I don't know what I did to break or fix it. Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org on behalf of Nowlan, Sean sean.now...@gtri.gatech.edu Sent: Saturday, June 27, 2015 6:27 PM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Include an OOT module in another OOT module? Let's say I've made two OOT projects called gr-first and gr-second. I want to link gr-second against gr-first, but CMake isn't finding it. gr-first/CMakeLists.txt seems to install a helper file: $PREFIX/lib/cmake/first/firstConfig.cmake In gr-second/CMakeLists.txt, I add a line: find_package(first) But this does not work. I also tried include(firstConfig) find_package(first) I guess I can hack something together using an example like gr-osmosdr, which depends on gr-iqbalance. Although if possible, I'd like to use the default helper file and get that working, since that's the whole point of having a helper file. Any hints? Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Include an OOT module in another OOT module?
Let's say I've made two OOT projects called gr-first and gr-second. I want to link gr-second against gr-first, but CMake isn't finding it. gr-first/CMakeLists.txt seems to install a helper file: $PREFIX/lib/cmake/first/firstConfig.cmake In gr-second/CMakeLists.txt, I add a line: find_package(first) But this does not work. I also tried include(firstConfig) find_package(first) I guess I can hack something together using an example like gr-osmosdr, which depends on gr-iqbalance. Although if possible, I'd like to use the default helper file and get that working, since that's the whole point of having a helper file. Any hints? Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PSK Mod Block
This depends on your setup. If you’re just simulating with PSK Mod -- PSK Demod and then comparing the input with the output, then you may be seeing some initial output from the filters due to the convolution operations. Try searching through your output after some delay. If you disabled differential encoding, you may be seeing a bitstream that is not correct due to phase locking with a fixed phase offset at the receiver. If you’re going over hardware or through a noise channel, you might not have enough SNR to decode properly. If you’re using USRPs, have you experimented with the benchmark_tx/rx scripts? These implement various types of single carrier modulation, including many variants of PSK. Sean From: Surya Agam [mailto:surya11.01a...@gmail.com] Sent: Tuesday, June 23, 2015 10:53 AM To: Nowlan, Sean Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] PSK Mod Block Thank you for the fast respond, But, when I use PSK Mod then PSK Demod the output different from the input so no output from the Packet Decoder. Any suggestion? On Tue, Jun 23, 2015 at 9:17 PM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: Introducing ISI to a PSK signal with a root-raised cosine (RRC) filter is a standard communications technique. At the receiver, use a matched RRC filter to eliminate the intentional ISI introduced at the transmitter. This works because the combined filter response of the two filters is a raised cosine pulse, which satisfies the Nyquist criterion for zero ISI. In the PSK Mod block, the filter construction is not exposed to the user except through the excess bandwidth or roll-off parameter. You could adjust that bandwidth factor to be close to zero, but this will create a very long filter. If you really want to do what you are saying, it would be worth looking at the source code for the PSK Mod block, and taking the filter out. However, it is likely that you don’t really want to do this. Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlanmailto:discuss-gnuradio-bounces%2Bsean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org] On Behalf Of Surya Agam Sent: Tuesday, June 23, 2015 9:47 AM To: GNURadio Discussion List Subject: [Discuss-gnuradio] PSK Mod Block Hello, I wanna use PSK Mod Block, but the ISI is annoying. Why PSK Mod Block have a it's own ISI? And also is there anyway to disable the ISI from the block? -- Sincerely, Surya Agam University Al Azhar of Indonesia, Jakarta -- Sincerely, Surya Agam University Al Azhar of Indonesia, Jakarta ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PSK Mod Block
Introducing ISI to a PSK signal with a root-raised cosine (RRC) filter is a standard communications technique. At the receiver, use a matched RRC filter to eliminate the intentional ISI introduced at the transmitter. This works because the combined filter response of the two filters is a raised cosine pulse, which satisfies the Nyquist criterion for zero ISI. In the PSK Mod block, the filter construction is not exposed to the user except through the excess bandwidth or roll-off parameter. You could adjust that bandwidth factor to be close to zero, but this will create a very long filter. If you really want to do what you are saying, it would be worth looking at the source code for the PSK Mod block, and taking the filter out. However, it is likely that you don’t really want to do this. Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Surya Agam Sent: Tuesday, June 23, 2015 9:47 AM To: GNURadio Discussion List Subject: [Discuss-gnuradio] PSK Mod Block Hello, I wanna use PSK Mod Block, but the ISI is annoying. Why PSK Mod Block have a it's own ISI? And also is there anyway to disable the ISI from the block? -- Sincerely, Surya Agam University Al Azhar of Indonesia, Jakarta ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PSK Mod Block
Looking quickly at the documentation, for PSK Mod and Demod blocks, it appears that PSK Mod expects packed bytes (8 bits of meaningful data in each byte) and that the Demod block outputs a stream of bits with 1 meaningful bit in the LSB position. Use a Repack Bits block. However, you may need to play with the delay (insert a Delay Block) to make sure that the Repack Bits block is aligning bits into bytes properly. Mod: The input is a byte stream (unsigned char), treated as a series of packed symbols. Symbols are grouped from MSB to LSB. Demod: The output is a stream of bytes, each representing a recovered bit. The most significant bit is reported first. From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Marcus Müller Sent: Tuesday, June 23, 2015 11:59 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] PSK Mod Block Then you really want some pulse shaping filter, like the RRC that is used by default. On 06/23/2015 05:39 PM, Surya Agam wrote: My target is using USRP, but still simulate using a noise channel. The output of PSK Demod is bit 0 a with some 1 and no input data in the output. I attach the input and the output screenshot. On Tue, Jun 23, 2015 at 10:12 PM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: This depends on your setup. If you're just simulating with PSK Mod -- PSK Demod and then comparing the input with the output, then you may be seeing some initial output from the filters due to the convolution operations. Try searching through your output after some delay. If you disabled differential encoding, you may be seeing a bitstream that is not correct due to phase locking with a fixed phase offset at the receiver. If you're going over hardware or through a noise channel, you might not have enough SNR to decode properly. If you're using USRPs, have you experimented with the benchmark_tx/rx scripts? These implement various types of single carrier modulation, including many variants of PSK. Sean From: Surya Agam [mailto:surya11.01a...@gmail.commailto:surya11.01a...@gmail.com] Sent: Tuesday, June 23, 2015 10:53 AM To: Nowlan, Sean Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] PSK Mod Block Thank you for the fast respond, But, when I use PSK Mod then PSK Demod the output different from the input so no output from the Packet Decoder. Any suggestion? On Tue, Jun 23, 2015 at 9:17 PM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: Introducing ISI to a PSK signal with a root-raised cosine (RRC) filter is a standard communications technique. At the receiver, use a matched RRC filter to eliminate the intentional ISI introduced at the transmitter. This works because the combined filter response of the two filters is a raised cosine pulse, which satisfies the Nyquist criterion for zero ISI. In the PSK Mod block, the filter construction is not exposed to the user except through the excess bandwidth or roll-off parameter. You could adjust that bandwidth factor to be close to zero, but this will create a very long filter. If you really want to do what you are saying, it would be worth looking at the source code for the PSK Mod block, and taking the filter out. However, it is likely that you don't really want to do this. Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlanmailto:discuss-gnuradio-bounces%2Bsean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org] On Behalf Of Surya Agam Sent: Tuesday, June 23, 2015 9:47 AM To: GNURadio Discussion List Subject: [Discuss-gnuradio] PSK Mod Block Hello, I wanna use PSK Mod Block, but the ISI is annoying. Why PSK Mod Block have a it's own ISI? And also is there anyway to disable the ISI from the block? -- Sincerely, Surya Agam University Al Azhar of Indonesia, Jakarta -- Sincerely, Surya Agam University Al Azhar of Indonesia, Jakarta -- Sincerely, Surya Agam University Al Azhar of Indonesia, Jakarta ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orgmailto: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] Embedded WG
On Mon, Jun 15, 2015 at 7:38 PM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: J Corgan's bootable USB stick on a Minnowboard I'm pretty curious how well this worked and if you ran into any issues or had to do anything extra for this combination. It was as simple as choosing the USB stick from the boot list in BIOS. MinnowBoard has a USB 3.0 port, so booting was fairly quick. It operated smoothly. I ran volk_profile and gr-benchmark and uploaded results to stats.gnuradio.org. The Intel Atom E3825 is mysteriously missing right now, but I know I’ve seen it up there. ODROIDXU is also gone, and I know that was up there too. Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Embedded WG
For the next year, I'd like to get more people actually using the infrastructure we have. I'd like to get a list of gnuradio apps together and start validating they run on various embedded platforms. I've been doing a little benchmarking of GR on various embedded platforms, but I've been using different O/Ses on each (Ubuntu 14.04.2 LTS on ODROID XU3 and C1, Ubuntu 15.04 on RPi2, J Corgan's bootable USB stick on a Minnowboard, and OE on E310). For uniformity, I agree that it would be nice to have an OE way to do build across all these targets. I've also been working on tuning compile flags for XU3. I'm planning to share some results with the community in the next few weeks. I'd also like some feedback on who would attend a WG call sometime in the next few weeks. I'm interested. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [VOLK] volk_profile failures
That makes sense. I installed ORC 0.4.23 and tried to recompile GR, but the build is failing on Volk. GCC segfaults a couple times before failing with an error on volk_16ic_magnitude_16i_a_orc_impl. Full output here: https://gist.github.com/nowls/2f6ddf5734e152ca21a7 ORC 0.4.23 was built with: CFLAGS=-mcpu=cortex-a15.cortex-a7 -mtune=cortex-a15.cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -funsafe-math-optimizations CPPFLAGS=-mcpu=cortex-a15.cortex-a7 -mtune=cortex-a15.cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -funsafe-math-optimizations UHD built fine w/ ORC 0.4.23. Sean From: West, Nathan n...@ostatemail.okstate.edu Sent: Saturday, June 6, 2015 12:57 PM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] [VOLK] volk_profile failures Most likely. What we've seen before is that ORC didn't preserve registers according to ARM specifications. This basically results in unpredictable data corruption. The commit I pointed to is the fix (vpush certain registers if used, then vpop after the routine). The visible corruption is seen by corrupting the test tolerance. If you look at ctest -V you should see that the errors are actually the same result, but since tolerance gets corrupted the test erroneously is false. The only QA failures should be on kernels that have an ORC protokernel, but this bug can affect non-ORC protokernels for that kernel. Nathan On Sat, Jun 6, 2015 at 12:47 PM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: Ok, I will install ORC 0.4.23 from source. Is ORC involved with all the other architectures that had failures? Sean From: West, Nathan n...@ostatemail.okstate.edumailto:n...@ostatemail.okstate.edu Sent: Friday, June 5, 2015 6:48 PM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] [VOLK] volk_profile failures Hi Sean, I didn't read all of the debug info, but your symptoms are a result of ORC doing bad things. You can either uninstall ORC or upgrade to the latest release (0.4.23). The commit you really need is this one: http://cgit.freedesktop.org/gstreamer/orc/commit/?id=acdaac31c648fd10f1bd0a49c4c33b483bb9c35c If you choose to upgrade ORC let me know how it goes. Cheers, Nathan On Friday, June 5, 2015, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: I compiled GNU Radio 3.7.7.1 natively on an ODROID XU3-Lite with Ubuntu 14.04.2 LTS. I ran volk_profile and got a lot of failures for various embedded architectures. Any ideas what could be happening? Could it be something with the compile flags I chose? volk_16ic_s32f_deinterleave_32f_x2: fail on arch neon volk_16ic_s32f_deinterleave_32f_x2: fail on arch neon volk_16ic_s32f_deinterleave_32f_x2: fail on arch u_orc volk_16ic_s32f_deinterleave_32f_x2: fail on arch u_orc volk_32fc_s32f_magnitude_16i: fail on arch u_orc volk_32fc_x2_multiply_32fc: fail on arch a_generic volk_32fc_x2_multiply_32fc: fail on arch a_generic volk_32fc_x2_multiply_32fc: fail on arch a_generic volk_32fc_x2_multiply_32fc: fail on arch neon volk_32fc_x2_multiply_32fc: fail on arch neon volk_32fc_x2_multiply_32fc: fail on arch neon volk_32fc_x2_multiply_32fc: fail on arch neon_opttests volk_32fc_x2_multiply_32fc: fail on arch neon_opttests volk_32fc_x2_multiply_32fc: fail on arch neon_opttests volk_32fc_x2_multiply_32fc: fail on arch neonasm volk_32fc_x2_multiply_32fc: fail on arch neonasm volk_32fc_x2_multiply_32fc: fail on arch neonasm volk_32fc_x2_multiply_32fc: fail on arch u_orc volk_32fc_x2_multiply_32fc: fail on arch u_orc volk_32fc_x2_multiply_32fc: fail on arch u_orc volk_32f_sqrt_32f: fail on arch neon volk_32f_x3_sum_of_poly_32f: fail on arch a_neon volk_32f_x3_sum_of_poly_32f: fail on arch neonvert volk_32fc_s32fc_multiply_32fc: fail on arch neon The full output of volk_profile is here: https://gist.github.com/nowls/37c78d89342053bae0ea https://gist.github.com/nowls/37c78d89342053bae0ea Resulting volk_config: https://gist.github.com/nowls/5894fbce1b29325b8f58 Some relevant configuration info taken from CMakeCache.txt (gcc/g++ version and C/CXX/ASM flags): CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++-4.9 CMAKE_CXX_COMPILER_WITH_PATH:FILEPATH=/usr/bin/g++-4.9 CMAKE_CXX_FLAGS:STRING=-mcpu=cortex-a15.cortex-a7 -mtune=cortex-a15.cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -funsafe-math-optimizations CMAKE_CXX_FLAGS_DEBUG:STRING=-g CMAKE_CXX_FLAGS_DEBUGPARANOID:STRING=-Wall -Wextra -g -O0 CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_CXX_FLAGS_NOOPTWITHASM:STRING=-Wall -save-temps -g -O0 CMAKE_CXX_FLAGS_O2WITHASM:STRING=-Wall -save-temps -g -O2 CMAKE_CXX_FLAGS_O3WITHASM:STRING=-Wall -save-temps -g -O3 CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-4.9 CMAKE_C_COMPILER_WITH_PATH:FILEPATH=/usr/bin/gcc
[Discuss-gnuradio] [VOLK] volk_profile failures
I compiled GNU Radio 3.7.7.1 natively on an ODROID XU3-Lite with Ubuntu 14.04.2 LTS. I ran volk_profile and got a lot of failures for various embedded architectures. Any ideas what could be happening? Could it be something with the compile flags I chose? volk_16ic_s32f_deinterleave_32f_x2: fail on arch neon volk_16ic_s32f_deinterleave_32f_x2: fail on arch neon volk_16ic_s32f_deinterleave_32f_x2: fail on arch u_orc volk_16ic_s32f_deinterleave_32f_x2: fail on arch u_orc volk_32fc_s32f_magnitude_16i: fail on arch u_orc volk_32fc_x2_multiply_32fc: fail on arch a_generic volk_32fc_x2_multiply_32fc: fail on arch a_generic volk_32fc_x2_multiply_32fc: fail on arch a_generic volk_32fc_x2_multiply_32fc: fail on arch neon volk_32fc_x2_multiply_32fc: fail on arch neon volk_32fc_x2_multiply_32fc: fail on arch neon volk_32fc_x2_multiply_32fc: fail on arch neon_opttests volk_32fc_x2_multiply_32fc: fail on arch neon_opttests volk_32fc_x2_multiply_32fc: fail on arch neon_opttests volk_32fc_x2_multiply_32fc: fail on arch neonasm volk_32fc_x2_multiply_32fc: fail on arch neonasm volk_32fc_x2_multiply_32fc: fail on arch neonasm volk_32fc_x2_multiply_32fc: fail on arch u_orc volk_32fc_x2_multiply_32fc: fail on arch u_orc volk_32fc_x2_multiply_32fc: fail on arch u_orc volk_32f_sqrt_32f: fail on arch neon volk_32f_x3_sum_of_poly_32f: fail on arch a_neon volk_32f_x3_sum_of_poly_32f: fail on arch neonvert volk_32fc_s32fc_multiply_32fc: fail on arch neon The full output of volk_profile is here: https://gist.github.com/nowls/37c78d89342053bae0ea https://gist.github.com/nowls/37c78d89342053bae0ea Resulting volk_config: https://gist.github.com/nowls/5894fbce1b29325b8f58 Some relevant configuration info taken from CMakeCache.txt (gcc/g++ version and C/CXX/ASM flags): CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++-4.9 CMAKE_CXX_COMPILER_WITH_PATH:FILEPATH=/usr/bin/g++-4.9 CMAKE_CXX_FLAGS:STRING=-mcpu=cortex-a15.cortex-a7 -mtune=cortex-a15.cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -funsafe-math-optimizations CMAKE_CXX_FLAGS_DEBUG:STRING=-g CMAKE_CXX_FLAGS_DEBUGPARANOID:STRING=-Wall -Wextra -g -O0 CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_CXX_FLAGS_NOOPTWITHASM:STRING=-Wall -save-temps -g -O0 CMAKE_CXX_FLAGS_O2WITHASM:STRING=-Wall -save-temps -g -O2 CMAKE_CXX_FLAGS_O3WITHASM:STRING=-Wall -save-temps -g -O3 CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-4.9 CMAKE_C_COMPILER_WITH_PATH:FILEPATH=/usr/bin/gcc-4.9 CMAKE_C_FLAGS:STRING=-mcpu=cortex-a15.cortex-a7 -mtune=cortex-a15.cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -funsafe-math-optimizations CMAKE_C_FLAGS_DEBUG:STRING=-g CMAKE_C_FLAGS_DEBUGPARANOID:STRING=-Wall -Wextra -g -O0 CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_C_FLAGS_NOOPTWITHASM:STRING=-Wall -save-temps -g -O0 CMAKE_C_FLAGS_O2WITHASM:STRING=-Wall -save-temps -g -O2 CMAKE_C_FLAGS_O3WITHASM:STRING=-Wall -save-temps -g -O3 CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG CMAKE_ASM_FLAGS:STRING=-mcpu=cortex-a15.cortex-a7 -mtune=cortex-a15.cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -funsafe-math-optimizations CMAKE_ASM_FLAGS_DEBUG:STRING=-g CMAKE_ASM_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_ASM_FLAGS_RELEASE:STRING=-O3 -DNDEBUG CMAKE_ASM_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG Sean Nowlan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble with SWIG for packet_formatter_default child class
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org on behalf of
Nowlan, Sean sean.now...@gtri.gatech.edu
Sent: Tuesday, February 24, 2015 1:27 PM
To: Tom Rondeau; Bastian Bloessl
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Trouble with SWIG for packet_formatter_default
child class
From: trond...@trondeau.com trond...@trondeau.com on behalf of Tom Rondeau
t...@trondeau.com
Sent: Tuesday, February 24, 2015 10:32 AM
To: Bastian Bloessl
Cc: Nowlan, Sean; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Trouble with SWIG for packet_formatter_default
child class
On Tue, Feb 24, 2015 at 3:00 AM, Bastian Bloessl
bloe...@ccs-labs.orgmailto:bloe...@ccs-labs.org wrote:
Hi,
I also created a custom header that derives from packet_formatter_default and
this swig file works for me
https://github.com/bastibl/gr-ieee802-11/blob/master/swig/ieee802_11_swig.i
I forgot why it did it like that, but maybe it helps.
Best,
Bastian
On 23 Feb 2015, at 22:10, Nowlan, Sean
sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote:
From:
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlanmailto:discuss-gnuradio-bounces%2Bsean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org]
On Behalf Of Nowlan, Sean
Sent: Monday, February 23, 2015 3:10 PM
To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Trouble with SWIG for packet_formatter_default
child class
Hi all –
I’m working on Tom’s packet_handling branch
(github.com/trondeau/gnuradio.githttp://github.com/trondeau/gnuradio.git)
and building a custom packet formatter. Everything works in C++ land,
including QA code. However, SWIG is complaining about undeclared things. I
duplicated the CMake and SWIG structures of gnuradio/gr-digital/swig/ for
building derived classes such as gr::digital::packet_formatter_counter. Any
ideas why this would not work? Thanks!
first few lines of make errors
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx: In function
‘PyObject* _wrap_packet_formatter_custom_make(PyObject*, PyObject*,
PyObject*)’:
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5030:3: error:
‘sptr’ was not declared in this scope
sptr result;
^
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5030:8: error:
expected ‘;’ before ‘result’
sptr result;
^
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5062:7: error:
‘result’ was not declared in this scope
result = gr::myoot::packet_formatter_custom::make((std::string const
)*arg1,(std::string const )*arg2,arg3);
^
gr-myoot/swig/myoot_swig.i
/* -*- c++ -*- */
#define MYOOT_API
%include gnuradio.i// the common stuff
//load generated python docstrings
%include myoot_swig_doc.i
%{
#include myoot/packet_formatter_custom.h
%}
%include myoot/packet_formatter_custom.h
GR_SWIG_BLOCK_MAGIC2(myoot, packet_formatter_custom);
// Properly package up non-block objects
%include packet_formatter_custom.i
gr-myoot/swig/packet_formatter_custom.i
%template(packet_formatter_custom_sptr)
boost::shared_ptrgr::myoot::packet_formatter_custom;
%pythoncode %{
packet_formatter_custom_sptr.__repr__ = lambda self:
packet_formatter_custom
packet_formatter_custom = packet_formatter_custom .make;
%}
--
To get it to build, I added the following typedef to
gr-myoot/include/myoot/packet_formatter_custom.h :
…
public:
typedef
boost:shared_ptrpacket_formatter_custom sptr;
…
Now importing SWIG-generated stuff in Python fails:
import myoot
Traceback (most recent call last):
File input, line 1, in module
File /home/me/target/lib/python2.7/dist-packages/myoot/__init__.py, line
29, in module
from myoot_swig import *
File /home/me/target/lib/python2.7/dist-packages/myoot/myoot_swig.py, line
265, in module
packet_formatter_custom = packet_formatter_custom .make;
AttributeError: 'function' object has no attribute 'make'
This is probably due to a conflict between the definition of sptr: one is
being autogenerated by SWIG based on the typedef in
include/myoot/packet_formatter_custom.h; the other is the template in
swig/packet_formatter_custom.i.
Now if I build without the special sauce in swig/packet_formatter_custom.i, I
can get “import myoot” in Python to work. However, there’s still some strange
behavior if I don’t actually assign to a variable.
import myoot
from gnuradio import digital
formatter1 = myoot.packet_formatter_custom(1, 1, 1)
formatter2 = digital.packet_formatter_counter(1, 1
Re: [Discuss-gnuradio] Trouble with SWIG for packet_formatter_default child class
From: trond...@trondeau.com trond...@trondeau.com on behalf of Tom Rondeau
t...@trondeau.com
Sent: Tuesday, February 24, 2015 10:32 AM
To: Bastian Bloessl
Cc: Nowlan, Sean; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Trouble with SWIG for packet_formatter_default
child class
On Tue, Feb 24, 2015 at 3:00 AM, Bastian Bloessl
bloe...@ccs-labs.orgmailto:bloe...@ccs-labs.org wrote:
Hi,
I also created a custom header that derives from packet_formatter_default and
this swig file works for me
https://github.com/bastibl/gr-ieee802-11/blob/master/swig/ieee802_11_swig.i
I forgot why it did it like that, but maybe it helps.
Best,
Bastian
On 23 Feb 2015, at 22:10, Nowlan, Sean
sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote:
From:
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlanmailto:discuss-gnuradio-bounces%2Bsean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org]
On Behalf Of Nowlan, Sean
Sent: Monday, February 23, 2015 3:10 PM
To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Trouble with SWIG for packet_formatter_default
child class
Hi all –
I’m working on Tom’s packet_handling branch
(github.com/trondeau/gnuradio.githttp://github.com/trondeau/gnuradio.git)
and building a custom packet formatter. Everything works in C++ land,
including QA code. However, SWIG is complaining about undeclared things. I
duplicated the CMake and SWIG structures of gnuradio/gr-digital/swig/ for
building derived classes such as gr::digital::packet_formatter_counter. Any
ideas why this would not work? Thanks!
first few lines of make errors
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx: In function
‘PyObject* _wrap_packet_formatter_custom_make(PyObject*, PyObject*,
PyObject*)’:
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5030:3: error:
‘sptr’ was not declared in this scope
sptr result;
^
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5030:8: error:
expected ‘;’ before ‘result’
sptr result;
^
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5062:7: error:
‘result’ was not declared in this scope
result = gr::myoot::packet_formatter_custom::make((std::string const
)*arg1,(std::string const )*arg2,arg3);
^
gr-myoot/swig/myoot_swig.i
/* -*- c++ -*- */
#define MYOOT_API
%include gnuradio.i// the common stuff
//load generated python docstrings
%include myoot_swig_doc.i
%{
#include myoot/packet_formatter_custom.h
%}
%include myoot/packet_formatter_custom.h
GR_SWIG_BLOCK_MAGIC2(myoot, packet_formatter_custom);
// Properly package up non-block objects
%include packet_formatter_custom.i
gr-myoot/swig/packet_formatter_custom.i
%template(packet_formatter_custom_sptr)
boost::shared_ptrgr::myoot::packet_formatter_custom;
%pythoncode %{
packet_formatter_custom_sptr.__repr__ = lambda self:
packet_formatter_custom
packet_formatter_custom = packet_formatter_custom .make;
%}
--
To get it to build, I added the following typedef to
gr-myoot/include/myoot/packet_formatter_custom.h :
…
public:
typedef
boost:shared_ptrpacket_formatter_custom sptr;
…
Now importing SWIG-generated stuff in Python fails:
import myoot
Traceback (most recent call last):
File input, line 1, in module
File /home/me/target/lib/python2.7/dist-packages/myoot/__init__.py, line
29, in module
from myoot_swig import *
File /home/me/target/lib/python2.7/dist-packages/myoot/myoot_swig.py, line
265, in module
packet_formatter_custom = packet_formatter_custom .make;
AttributeError: 'function' object has no attribute 'make'
This is probably due to a conflict between the definition of sptr: one is
being autogenerated by SWIG based on the typedef in
include/myoot/packet_formatter_custom.h; the other is the template in
swig/packet_formatter_custom.i.
Now if I build without the special sauce in swig/packet_formatter_custom.i, I
can get “import myoot” in Python to work. However, there’s still some strange
behavior if I don’t actually assign to a variable.
import myoot
from gnuradio import digital
formatter1 = myoot.packet_formatter_custom(1, 1, 1)
formatter2 = digital.packet_formatter_counter(1, 1)
myoot.packet_formatter_custom(1, 1, 1)
Traceback (most recent call last):
File input, line 1, in module
File /home/me/target/lib/python2.7/dist-packages/myoot/myoot_swig.py, line
261, in lambda
packet_formatter_custom_sptr.__repr__ = lambda self: gr_block %s (%d) %
(self.namehttp://self.name(), self.unique_id())
AttributeError: 'packet_formatter_custom_sptr' object has no attribute 'name
Re: [Discuss-gnuradio] Trouble with SWIG for packet_formatter_default child class
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Nowlan, Sean
Sent: Monday, February 23, 2015 3:10 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Trouble with SWIG for packet_formatter_default
child class
Hi all -
I'm working on Tom's packet_handling branch (github.com/trondeau/gnuradio.git)
and building a custom packet formatter. Everything works in C++ land, including
QA code. However, SWIG is complaining about undeclared things. I duplicated the
CMake and SWIG structures of gnuradio/gr-digital/swig/ for building derived
classes such as gr::digital::packet_formatter_counter. Any ideas why this would
not work? Thanks!
first few lines of make errors
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx: In function
'PyObject* _wrap_packet_formatter_custom_make(PyObject*, PyObject*, PyObject*)':
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5030:3: error:
'sptr' was not declared in this scope
sptr result;
^
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5030:8: error:
expected ';' before 'result'
sptr result;
^
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5062:7: error:
'result' was not declared in this scope
result = gr::myoot::packet_formatter_custom::make((std::string const
)*arg1,(std::string const )*arg2,arg3);
^
gr-myoot/swig/myoot_swig.i
/* -*- c++ -*- */
#define MYOOT_API
%include gnuradio.i// the common stuff
//load generated python docstrings
%include myoot_swig_doc.i
%{
#include myoot/packet_formatter_custom.h
%}
%include myoot/packet_formatter_custom.h
GR_SWIG_BLOCK_MAGIC2(myoot, packet_formatter_custom);
// Properly package up non-block objects
%include packet_formatter_custom.i
gr-myoot/swig/packet_formatter_custom.i
%template(packet_formatter_custom_sptr)
boost::shared_ptrgr::myoot::packet_formatter_custom;
%pythoncode %{
packet_formatter_custom_sptr.__repr__ = lambda self: packet_formatter_custom
packet_formatter_custom = packet_formatter_custom .make;
%}
--
To get it to build, I added the following typedef to
gr-myoot/include/myoot/packet_formatter_custom.h :
...
public:
typedef
boost:shared_ptrpacket_formatter_custom sptr;
...
Now importing SWIG-generated stuff in Python fails:
import myoot
Traceback (most recent call last):
File input, line 1, in module
File /home/me/target/lib/python2.7/dist-packages/myoot/__init__.py, line
29, in module
from myoot_swig import *
File /home/me/target/lib/python2.7/dist-packages/myoot/myoot_swig.py, line
265, in module
packet_formatter_custom = packet_formatter_custom .make;
AttributeError: 'function' object has no attribute 'make'
This is probably due to a conflict between the definition of sptr: one is being
autogenerated by SWIG based on the typedef in
include/myoot/packet_formatter_custom.h; the other is the template in
swig/packet_formatter_custom.i.
Now if I build without the special sauce in swig/packet_formatter_custom.i, I
can get import myoot in Python to work. However, there's still some strange
behavior if I don't actually assign to a variable.
import myoot
from gnuradio import digital
formatter1 = myoot.packet_formatter_custom(1, 1, 1)
formatter2 = digital.packet_formatter_counter(1, 1)
myoot.packet_formatter_custom(1, 1, 1)
Traceback (most recent call last):
File input, line 1, in module
File /home/me/target/lib/python2.7/dist-packages/myoot/myoot_swig.py, line
261, in lambda
packet_formatter_custom_sptr.__repr__ = lambda self: gr_block %s (%d) %
(self.name(), self.unique_id())
AttributeError: 'packet_formatter_custom_sptr' object has no attribute 'name'
digital.packet_formatter_counter(1, 1)
packet_formatter_default
Note that the sptr in gr-digital is of type packet_formatter_default, meaning
it inherited the definition of the typedef from packet_formatter_default. In my
case it didn't work because I used GR_SWIG_BLOCK_MAGIC2 on a non block, so the
__repr__ definition (above) breaks.
What should I do? I can rely on GR_SWIG_BLOCK_MAGIC2, which is not really the
right way to generate SWIG templates for a non block, or I can try to get
things to work without redefining the sptr typedef in the child class. In that
case, I need to include the proper header file (namely,
packet_formatter_default.h) from gr-digital. Should I do that explicitly in
myoot_swig.i, or is there a better way to add gr-digital to include dirs in
swig/CMakeLists.txt?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Trouble with SWIG for packet_formatter_default child class
Hi all -
I'm working on Tom's packet_handling branch (github.com/trondeau/gnuradio.git)
and building a custom packet formatter. Everything works in C++ land, including
QA code. However, SWIG is complaining about undeclared things. I duplicated the
CMake and SWIG structures of gnuradio/gr-digital/swig/ for building derived
classes such as gr::digital::packet_formatter_counter. Any ideas why this would
not work? Thanks!
first few lines of make errors
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx: In function
'PyObject* _wrap_packet_formatter_custom_make(PyObject*, PyObject*, PyObject*)':
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5030:3: error:
'sptr' was not declared in this scope
sptr result;
^
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5030:8: error:
expected ';' before 'result'
sptr result;
^
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5062:7: error:
'result' was not declared in this scope
result = gr::myoot::packet_formatter_custom::make((std::string const
)*arg1,(std::string const )*arg2,arg3);
^
gr-myoot/swig/myoot_swig.i
/* -*- c++ -*- */
#define MYOOT_API
%include gnuradio.i// the common stuff
//load generated python docstrings
%include myoot_swig_doc.i
%{
#include myoot/packet_formatter_custom.h
%}
%include myoot/packet_formatter_custom.h
GR_SWIG_BLOCK_MAGIC2(myoot, packet_formatter_custom);
// Properly package up non-block objects
%include packet_formatter_custom.i
gr-myoot/swig/packet_formatter_custom.i
%template(packet_formatter_custom_sptr)
boost::shared_ptrgr::myoot::packet_formatter_custom;
%pythoncode %{
packet_formatter_custom_sptr.__repr__ = lambda self: packet_formatter_custom
packet_formatter_custom = packet_formatter_custom .make;
%}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC - specifying version for install
Hi, I have only used pybombs to install GRC and it is a fantasic way to get this done. Thanks very much for pybombs! I do notice though that there is no mention of which version will be installed. For example I have two machines GRC installed within about a week of one another a couple of months ago. One machine has 3.7.5 git-0-grbb2b314 while the other has 3.7.6 git-1-g01deede3. This past weekend I installed it on a third machine which reports as 3.7.2.1 All of these machines are to be used within a sensor network and I am weery of having differing versions. Should I be concerned? Is there an easy way to update them to have the same version? Will I need to wipe everything and start fresh on each machine? Thanks as always John John, I don’t know if there is a more straightforward way to do this, but here’s a way you can force a specific branch or tag, like “master” (default) or “v3.7.5.1” (latest release). Edit the file “pybombs/recipes/gnuradio.lwr” and change the value of “gitbranch”. You will need to rebuild by doing the following: ./pybombs clean uhd gnuradio ./pybombs install uhd gnuradio Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Building BOOT.BIN for Zedboard to use with gnuradio-dev-image
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
Re: [Discuss-gnuradio] Building BOOT.BIN for Zedboard to use with gnuradio-dev-image
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. 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. 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 sean.now...@gtri.gatech.edu 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] Can a tagged stream block be a source block?
On 12/04/2014 04:08 PM, Martin Braun wrote:
Actually, it's probably something I should fix before people start
writing tags by hand. David, until I have that ready you should change
that offending line to:
102 if(!d_n_input_items_reqd.empty() d_n_input_items_reqd[0] ==
0) { // Otherwise, it's already set from a previous call
parse_length_tags() will then never be called.
calculate_output_stream_length() however should return a valid length.
This was actually simpler than expected:
https://github.com/mbr0wn/gnuradio/tree/tsb/allow_source
I also put an example in there (see the 2nd commit).
Just to understand the implications of this change to pdu_to_tagged stream, max
input PDU size is now effectively constrained by the max buffer size that can
be handled by the scheduler and passed to work(). Correct? That may not be a
limitation for many people, and I suppose it would have surfaced before if
someone tried to send a larger PDU into a pdu_to_tagged_stream block connected
to a downstream tsb-derived block.
I guess the upside is that now you only need one call to work() per PDU and you
don't need an internal buffer and a stateful work() to push a PDU through.
Sean
Cheers,
M
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] RFNoC -- Making FPGA design easy from GNU Radio
Ettus Research is very excited to announce the release of RFNoC! […] This is very cool. I’ve been looking forward to working with this development. Mixing and matching host-based and FPGA-based processing is transparent to the user, and that processing can scale across multiple FPGAs and devices across a network Does this imply that I could run a GNU Radio application on a Zedboard, for instance, with the following data flows: (1) GR on Zynq ARM -- Zynq FPGA -- GR on Zynq ARM -- B2x0 RF/radio (2) GR on Zynq ARM -- Zynq FPGA -- GR on Zynq ARM -- X3x0 FPGA -- X3x0 RF/radio I think (1) is similar or identical to Jonathon Pendlum’s FPGA filter demo. What I’m more curious about is how easy it is to build a single GR flowgraph that mixes GR processing with FPGAs that live either in Zynq or connected 3x0 series devices. It sounds like this kind of support is an explicit goal of RFNoC. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Dev call tomorrow? + digital mod/demod questions
It looks like there's a dev call tomorrow. Is that 1700 or 1800 UTC? https://gnuradio.org/redmine/projects/gnuradio/wiki/Call20141120 As for input to the digital mod and packet structure discussion, I have a few questions, or at least food-for-thought for tomorrow: - It looks like the correlate_and_sync work is promising for allowing carrier and timing recovery loops to adjust more quickly when dealing with bursty, packetized traffic. However, most of the GR modem applications I've seen use the correlate_access_code block without the time and phase estimates being done on the preamble. I know the paradigm is slightly different, i.e. matched-filter preamble correlator vs. counting access code bit errors after MF and slicing, but is the intent to eventually merge the two approaches together? - What's the best way to handle the sudden ramp in power at the start of a burst? Use squelch to detect power above a threshold? Use AGC? This may be a fundamental radio receiver design question but I think it makes sense to ask it in the context of how these blocks are implemented. In gr-air-modes it looks like the preamble detector scans for a rapid change in sample voltage before initiating a preamble search. This seems more efficient if packet traffic is expected to be low, otherwise all you're doing is correlating against noise (correlate_and_sync) or junk bit decisions (correlate_access_code). If I've misunderstood anything here, please advise. Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
From Marcus:
... and that (wut) might be a bug, because it implies that, if the stream has
both a time tag and a sob tag, the
question whether the tx metadata has a time tag depends on in which order
these tags are sorted on the the
tag storage multimap. Which might be random, because tags are sorted only by
tag offset.
@Martin: is there a reason that this is explicitely set to false here, or can
one just fix this by deleting a line?
This appears to be handled correctly. Given the same tag offset, the order of
tx_time vs. tx_sob tags should not matter. If tx_time is found first, it sets
found_time_tag=true and _metadata.has_time_spec=true (lines 652 653). Then
_metadata.has_time_spec is overwritten in the tx_sob check (line 665) with
'false', but is set back to 'true' in line 743 due to found_time_tag being
true.
if (found_time_tag) {
_metadata.has_time_spec = true;
}
If instead tx_sob is found first and tx_time second, then the time spec will
also be set in line 743. So the question is whether setting
_metadata.has_time_spec=false is really necessary. I'd say it's worth keeping
in case the user doesn't always want to use tx_time stamps. The user may want
to schedule some bursts but force others to transmit as soon as possible while
still using the ATR functionality of the USRP.
I know all this logic can be hard to follow, but it has to handle so many
different cases and possibly span many calls to work and tag_work.
From Frederik:
Unfortunately, even with the newest version the USRP is still transmitting
its carrier over the air. I tried both with
the Message Burst Source as well as with the Stream to Tagged Stream Block
combined with setting a Length Tag
name in the USRP Sink. With the Tag Debug Block I see tx_sob+tx_eob and the
Length Tag, respectively. They all
seem to be at the right place and have the right value.
The Length Tag should arrive properly at the Sink. I checked by changing the
tag's name at the Stream to Tagged
Stream Block to something stupid and finally got an tG printed out.
It should be mentioned that there are two burst tag interfaces that cannot be
mixed. if a Length Tag Name is specified to the constructor, all tx_sob and
tx_eob tags will be ignored in tag_work to ensure the interfaces are mutually
exclusive. If no Length Tag Name is specified, then tag_work will search for
tx_sob/tx_eob tags and won't look for length tags.
Sean
On 21.10.2014 15:53, Frederik Wing wrote:
Hi Marcus,
I cannot believe that there is no solution to it since the
tags_demo application shows that it is indeed possible.
:-/
that makes the two of us! I didn't get that when using tags_demo,
you're not seeing the carrier that you use tags_demo; as far as I
understood, your application does exactly the same, sending bursts
with sob/eob tags?
That's right. tags_demo works perfectly. No carrier in between the
bursts. The flow graph I posted before sends exactly one burst with
SOB and EOB tags. The only difference to tags_demo I could recognize
so far is that I don't assign time stamps to the samples.
But this shouldn't be a problem, should it?
Frederik
___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJURnbzAAoJEAFxB7BbsDrL2nEIAJnutUguHZy3qb0delF4EEoZ
Wh+ikhML4LpzX76omgESTBzCIL+yeSzpwyF4+xFMs/laONrFoSYjKrIPicOUC85K
pKbddIT1eYC4ulDLViEAK7G+f3h8d6fj8NvVlBOYflyz/z8kfT5Ow2P7vT2osPbi
MrY9to3MQVGHriakq6mzf5cUe/F54YmscikEofrZXZj2EqwknULehS0Q0tm/Ms0L
G+OamkGyPdsyxn8vmR2yMOScHSKxWF0yINYzf+jLJ4ypmbYUmn+99lsDZoyF9bJ3
L93I6IaRgUReawdYjvfSmDMOL1n0t1zyp9GBgBTly4JtfD2Rcvfn8al6FSzOZv8=
=V3EN
-END PGP SIGNATURE-
___
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] Transmitting bursts with GRC by inserting SOB and EOB
I'm concerned that the problem Frederik is observing has to do with the very
short burst he is sending, something like 5 samples. I suspect this requires 1
call each to work and tag_work per 5 sample burst, which seems like an awful
lot of context switching and overhead.
-Original Message-
From: Marcus Müller [mailto:mar...@hostalia.de]
Sent: Tuesday, October 21, 2014 1:24 PM
To: Nowlan, Sean; discuss-gnuradio@gnu.org; Martin Braun
Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB
and EOB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Sean,
aaah good catch! Yes, that's right; sob is safe.
Cheers,
Marcus
On 21.10.2014 19:19, Nowlan, Sean wrote:
From Marcus:
... and that (wut) might be a bug, because it implies that, if the
stream has both a time tag and a sob tag, the question whether the tx
metadata has a time tag depends on in which order these tags are
sorted on the the tag storage multimap. Which might be random,
because tags are sorted only by tag offset.
@Martin: is there a reason that this is explicitely set to false
here, or can one just fix this by deleting a line?
This appears to be handled correctly. Given the same tag offset, the
order of tx_time vs. tx_sob tags should not matter. If tx_time is
found first, it sets found_time_tag=true and
_metadata.has_time_spec=true (lines 652 653). Then
_metadata.has_time_spec is overwritten in the tx_sob check (line
665) with 'false', but is set back to 'true' in line 743 due to
found_time_tag being true.
if (found_time_tag) { _metadata.has_time_spec = true; }
If instead tx_sob is found first and tx_time second, then the time
spec will also be set in line 743. So the question is whether setting
_metadata.has_time_spec=false is really necessary. I'd say it's worth
keeping in case the user doesn't always want to use tx_time stamps.
The user may want to schedule some bursts but force others to transmit
as soon as possible while still using the ATR functionality of the
USRP.
I know all this logic can be hard to follow, but it has to handle so
many different cases and possibly span many calls to work and
tag_work.
From Frederik:
Unfortunately, even with the newest version the USRP is still
transmitting its carrier over the air. I tried both with the Message
Burst Source as well as with the Stream to Tagged Stream Block
combined with setting a Length Tag name in the USRP Sink.
With the Tag Debug Block I see tx_sob+tx_eob and the Length Tag,
respectively. They all seem to be at the right place and have the
right value.
The Length Tag should arrive properly at the Sink. I checked by
changing the tag's name at the Stream to Tagged Stream Block to
something stupid and finally got an tG printed out.
It should be mentioned that there are two burst tag interfaces that
cannot be mixed. if a Length Tag Name is specified to the constructor,
all tx_sob and tx_eob tags will be ignored in tag_work to ensure the
interfaces are mutually exclusive. If no Length Tag Name is specified,
then tag_work will search for tx_sob/tx_eob tags and won't look for
length tags.
Sean
On 21.10.2014 15:53, Frederik Wing wrote:
Hi Marcus,
I cannot believe that there is no solution to it since the
tags_demo application shows that it is indeed possible.
:-/
that makes the two of us! I didn't get that when using tags_demo,
you're not seeing the carrier that you use tags_demo; as far as I
understood, your application does exactly the same, sending bursts
with sob/eob tags?
That's right. tags_demo works perfectly. No carrier in between the
bursts. The flow graph I posted before sends exactly one burst with
SOB and EOB tags. The only difference to tags_demo I could recognize
so far is that I don't assign time stamps to the samples. But this
shouldn't be a problem, should it?
Frederik
___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-BEGIN PGP SIGNATURE- Version: GnuPG v1
iQEcBAEBAgAGBQJURnbzAAoJEAFxB7BbsDrL2nEIAJnutUguHZy3qb0delF4EEoZ
Wh+ikhML4LpzX76omgESTBzCIL+yeSzpwyF4+xFMs/laONrFoSYjKrIPicOUC85K
pKbddIT1eYC4ulDLViEAK7G+f3h8d6fj8NvVlBOYflyz/z8kfT5Ow2P7vT2osPbi
MrY9to3MQVGHriakq6mzf5cUe/F54YmscikEofrZXZj2EqwknULehS0Q0tm/Ms0L
G+OamkGyPdsyxn8vmR2yMOScHSKxWF0yINYzf+jLJ4ypmbYUmn+99lsDZoyF9bJ3
L93I6IaRgUReawdYjvfSmDMOL1n0t1zyp9GBgBTly4JtfD2Rcvfn8al6FSzOZv8=
=V3EN -END PGP SIGNATURE-
___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJURparAAoJEAFxB7BbsDrLiT8H/0qUJ6qkMEgWdp7q1eKTr3Bm
hq4P6pIAXxXkmIRWVy+pn2uZ2zunvv0/2e/NcE4RMppuxTlT8HvjeKb0aKDMIxE2
spVqN/nuue5JSRAbQJIvI69jJytGgqzxvjY2EyWHSZPKtXB3Hc5a/PoMGY3EZb45
hZ
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
##
# Variables
##
self.tx_gain = tx_gain = 15
self.samp_rate = samp_rate = 20
self.f_center = f_center = 1.47e9
self.device = device = type=usrp2
##
# Blocks
##
self.usrp_sink = uhd.usrp_sink(
device_addr=device,
stream_args=uhd.stream_args(
cpu_format=fc32,
length_tag_name=packet_len,
channels=range(1),
),
)
self.usrp_sink.set_samp_rate(samp_rate)
self.usrp_sink.set_center_freq(f_center, 0)
self.usrp_sink.set_gain(tx_gain, 0)
self.usrp_sink.set_antenna(TX/RX, 0)
self.blocks_vector_source_x_0 =
blocks.vector_source_c((1,)*5, False, 1, [])
self.blocks_stream_to_tagged_stream_0 =
blocks.stream_to_tagged_stream(gr.sizeof_gr_complex, 1, 5,
packet_len)
##
# Connections
##
self.connect((self.blocks_vector_source_x_0, 0),
(self.blocks_stream_to_tagged_stream_0, 0))
self.connect((self.blocks_stream_to_tagged_stream_0, 0),
(self.usrp_sink, 0))
It's not working either... I can still observe the carrier at the receiver.
- You'll know if your USRP hasn't acknowledged tx_eob if you see 'U's
between bursts.
I am getting exactly one U. Both for the code in my previous post as
well as for the above one. It really seems like the USRP is not
recognizing the stream tags.
There are a few things to consider with this flowgraph (as posted):
1) Your vector source is set to /not/ repeat. After your flowgraph
terminates, is that when you observe the LO still running?
2) You're essentially sending a very short rectangular pulse modulated
onto a carrier, which in the frequency domain would look like a sinc function
centered at the carrier. Is this what you want, or are you just experimenting
with the burst interface?
3) Is there a reason your burst pulses need to contain so few samples?
Could you provide some information about what you're trying to do in your end
application?
Sean
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Marcus Müller
Sent: Tuesday, October 21, 2014 1:41 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB
and EOB
Sean,
interesting point.
Frederik,
How does your carrier look when you send bursts of 500 samples?
Greetings,
Marcus
On 21.10.2014 19:29, Nowlan, Sean wrote:
I'm concerned that the problem
Frederik is observing has to do with the very short burst he is
sending, something like 5 samples. I suspect this requires 1 call
each to work and tag_work per 5 sample burst, which seems like an
awful lot of context switching and overhead.
-Original Message-
From: Marcus Müller [mailto:mar...@hostalia.de]
Sent: Tuesday, October 21, 2014 1:24 PM
To: Nowlan, Sean;
discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org; Martin Braun
Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC
by inserting SOB and EOB
Hi Sean,
aaah good catch! Yes, that's right; sob is safe.
Cheers,
Marcus
On 21.10.2014 19:19, Nowlan, Sean wrote:
From Marcus:
... and that (wut) might be a bug, because it implies that, if the
stream has both a time tag and a sob tag, the question whether the tx
metadata has a time tag depends on in which order these tags are
sorted on the the tag storage multimap. Which might be random,
because tags are sorted only by tag offset.
@Martin: is there a reason that this is explicitely set to false
here, or can one just fix this by deleting a line?
This appears to be handled correctly. Given the same tag offset, the
order of tx_time vs. tx_sob tags should not matter. If tx_time is
found first, it sets found_time_tag=true and
_metadata.has_time_spec=true (lines 652 653). Then
_metadata.has_time_spec is overwritten in the tx_sob check (line
665) with 'false', but is set back to 'true' in line 743 due to
found_time_tag being true.
if (found_time_tag) { _metadata.has_time_spec = true; }
If instead tx_sob is found first and tx_time second, then the time
spec will also be set in line 743. So the question is whether setting
_metadata.has_time_spec=false is really necessary. I'd say it's worth
keeping in case the user doesn't always want to use tx_time stamps.
The user may want to schedule some
Re: [Discuss-gnuradio] Error: undefined symbol: volk_malloc
ImportError: /usr/local/lib/libgnuradio-filter-3.7.3.so.0.0.0: undefined symbol: volk_malloc It's possible that parts of the build are out of sync. I recommend rebuilding / reinstalling GNU Radio. Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems building GNURadio
I'm using the cross compiling environment to take advantage of the latest
updates to ARM VOLK kernels. My build environment is identical to the one
described in the Wiki page for embedded, except that it was necessary to add
-mtune=cortex-a9 to get the Neon assembly files to compile in volk. Before
adding this flag, I got this error:
[ 0%] Building ASM object
volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s.o
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:
Assembler messages:
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:35:
Error: selected processor does not support ARM mode `veor realAccQ,realAccQ'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:36:
Error: selected processor does not support ARM mode `veor compAccQ,compAccQ'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:42:
Error: selected processor does not support ARM mode `vld1.32
{d4-d5},[taps:128]!'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:43:
Error: selected processor does not support ARM mode `vld2.32
{d18-d21},[input:128]!'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:50:
Error: selected processor does not support ARM mode `vmul.f32
realMul,tapsVal,inRealVal'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:51:
Error: selected processor does not support ARM mode `vmul.f32
compMul,tapsVal,inCompVal'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:52:
Error: selected processor does not support ARM mode `vadd.f32
realAccQ,realAccQ,realMul'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:53:
Error: selected processor does not support ARM mode `vadd.f32
compAccQ,compAccQ,compMul'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:54:
Error: selected processor does not support ARM mode `vld1.32
{d4-d5},[taps:128]!'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:55:
Error: selected processor does not support ARM mode `vld2.32
{d18-d21},[input:128]!'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:61:
Error: selected processor does not support ARM mode `vpadd.f32 d0,d0,d1'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:62:
Error: selected processor does not support ARM mode `vpadd.f32 d2,d2,d3'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:63:
Error: selected processor does not support ARM mode `vadd.f32 realAccS,s0,s1'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:64:
Error: selected processor does not support ARM mode `vadd.f32 compAccS,s4,s5'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:71:
Error: selected processor does not support ARM mode `vld1.32 {d4[0]},[taps]!'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:72:
Error: selected processor does not support ARM mode `vld2.32
{d5[0],d6[0]},[input]!'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:73:
Error: selected processor does not support ARM mode `vmul.f32 s5,s8,s12'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:74:
Error: selected processor does not support ARM mode `vmul.f32 s6,s8,s10'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:75:
Error: selected processor does not support ARM mode `vadd.f32
realAccS,realAccS,s5'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:76:
Error: selected processor does not support ARM mode `vadd.f32
compAccS,compAccS,s6'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:82:
Error: selected processor does not support ARM mode `vst1.32 {d0[0]},[result]!'
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:83:
Error: selected processor does not support ARM mode `vst1.32 {d2[0]},[result]'
make[2]: ***
Re: [Discuss-gnuradio] ZedBoard GNU Radio image boot problems
On Wed, Sep 3, 2014 at 4:30 PM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: I’m trying to boot a ZedBoard with the GNU Radio image here: http://gnuradio.org/data/sdk/zedboard_armv7a-hf-vfp-neon/. I picked the hard float image even though the tutorial points to the soft float image (http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq). I don’t know why I’d want the soft float image since using the FPU will be much faster. There's a bug in ORC on hard float. So we were looking into soft float + ORC or hard flow - ORC. Now that we've checked in all of Nathan's NEON VOLK kernels to GNU Radio, we mostly cover all of the cases where we were benefiting from ORC. Bottom line, at this point in the development, use hard float. We will likely stop all support of soft float images in the future. I followed the directions at the aforementioned tutorial except I renamed “u-boot.bin” to “BOOT.BIN” and “uImage-zedboard-zynq7.dtb” to “devicetree.dtb”. I could not get the board to boot. The USB-to-UART triggers cdc_acm to load /dev/ttyACM0 on my Linux host PC, but there is no activity over serial. I’m confident the board is not dead because I am able to boot from the preloaded SD card that came with the ZedBoard development kit. Does anybody have any suggestions? It seems like either some step is missing or I am misunderstanding a step in the tutorial. Thanks, Sean Nowlan u-boot.bin != BOOT.BIN. I know it feels like it should, but it's missing the first stage boot loader (fsbl). There are licensing issues with distributing that ourselves. I might have the details slightly wrong since it's been a while. But basically, follow the instructions on the Zynq wiki you linked to above to build your of fsbl file and properly build your own boot.bin. Then DON'T LOSE THAT FILE. That'll be pretty much permanent for your uses. You did the right thing with the device tree file, as that might be updated and changed and we'll continue providing that. Tom Ok. I was afraid of that, but it’s not clear in the tutorial. Also, I see the process for building BOOT.BIN in Appendix A. I think things would be more clear if the “Pre-built” wiki section had a paragraph explicitly referring to Appendix A as a necessary step before using pre-built images (second stage boot loader, kernel, boot parameters, rootfs, etc.) for everything else. In my mind it seemed like that step only applied if doing a full OpenEmbedded build. Thanks! Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ZedBoard GNU Radio image boot problems
I'm trying to boot a ZedBoard with the GNU Radio image here: http://gnuradio.org/data/sdk/zedboard_armv7a-hf-vfp-neon/. I picked the hard float image even though the tutorial points to the soft float image (http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq). I don't know why I'd want the soft float image since using the FPU will be much faster. I followed the directions at the aforementioned tutorial except I renamed u-boot.bin to BOOT.BIN and uImage-zedboard-zynq7.dtb to devicetree.dtb. I could not get the board to boot. The USB-to-UART triggers cdc_acm to load /dev/ttyACM0 on my Linux host PC, but there is no activity over serial. I'm confident the board is not dead because I am able to boot from the preloaded SD card that came with the ZedBoard development kit. Does anybody have any suggestions? It seems like either some step is missing or I am misunderstanding a step in the tutorial. Thanks, Sean Nowlan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio support on MicroZed
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Tom Rondeau Sent: Tuesday, August 26, 2014 10:10 AM To: Stephen Harrison Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] GNU Radio support on MicroZed On Sat, Aug 23, 2014 at 11:42 PM, Stephen Harrison msteveharri...@gmail.commailto:msteveharri...@gmail.com wrote: Hi Sean, Is the Linaro distribution possible on MicroZed? I spent a long time trying to get OpenEmbedded to happen with no success. The Linaro distribution was a snap and I got GNURadio running no problem on the ZedBoard. Stephen For reference on getting OE working, see our Embedded page: http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded Though I can't speak directly to the MicroZed. Tom Thanks, all, for the pointers. I’ll see if I can get MicroZed boot files to launch into the GNU Radio rootfs image. Thanks, Sean On Sat, Aug 23, 2014 at 6:55 PM, West, Nathan n...@ostatemail.okstate.edumailto:n...@ostatemail.okstate.edu wrote: On Fri, Aug 22, 2014 at 7:10 PM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: I'm not the world's foremost expert in OpenEmbedded (read: person with nearly no knowledge of how to use it). I'd like to get GNU Radio working on a MicroZed. Unfortunately that board is not among the boards supported as mentioned here: http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq Also, I don't necessarily need John Pendlum's changes to add userspace support for interfacing with the FPGA. I just want to get the ARM running GNU Radio. The meta-xilinx-community repo claims to support a BSP and build for MicroZed: http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx-community/about/ How do I go about merging these two things together? I've taken my best guess as to how to setup a configuration with Poky: Build Configuration: BB_VERSION= 1.23.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-13.10 TARGET_SYS= arm-poky-linux-gnueabi MACHINE = microzed-zynq7 DISTRO= poky DISTRO_VERSION= 1.6+snapshot-20140822 TUNE_FEATURES = arm armv7a vfp neon zynq TARGET_FPU= vfp-neon meta meta-yocto meta-yocto-bsp= master:34436672f3ef4915e7526770a0fa8dcff328f93d meta-xilinx = master:83bf54daeaca21879290bf444876f9949b117454 meta-xilinx-community = master:a093287b81d446435d44cf238a9240782a80e1b7 meta-oe meta-networking meta-filesystems = master:8f637f9bbcdda1dc7a1998d243708c727aa6016f meta-sdr = master:21e2722a5e6671fd98268241f216e087f279566d Am I on the right track here? It's still fetching/building/etc. I'm not too confident it will actually work, since I don't really know what I'm doing. Thanks, Sean Hi Sean, The embedded page might be more useful: http://gnuradio.org/redmine/projects/gnuradio/wiki/embedded Especially check out the link to SDKs. There's a rootfs and modules built for a zedboard, all you'll need are device specific boot files. Just create the right partitions on your card and the provided rootfs and modules should be sufficient. (extract the rootfs to the / mounted partition on the SD card). Hopefully that can get you booting Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio support on MicroZed
Be careful what branch of meta-xilinx-community you use. If it is useful, I can look at adding it to the repo manifest to try and keep things in sync. I tried bitbaking again and ran into problems. I used the daisy branch on meta-xilinx-community. I also replaced github.com/Xilinx/meta-xilinx with git.yoctoproject.org/meta-xilinx in repo manifest.xml, also using daisy branch. I initially used the directions at https://github.com/balister/oe-gnuradio-manifest to set everything up and then made the aforementioned changes, and added meta-xilinx-community to bblayers.conf. No dice. Do you know if Yocto's and Xilinx's meta-xilinx layers are too different to be substituted? Is there a way to pull the microzed-zynq7 machine diffs into Xilinx/meta-xilinx? I'm kind of surprised Xilinx hasn't already added MicroZed support there. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio support on MicroZed
I'm not the world's foremost expert in OpenEmbedded (read: person with nearly no knowledge of how to use it). I'd like to get GNU Radio working on a MicroZed. Unfortunately that board is not among the boards supported as mentioned here: http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq Also, I don't necessarily need John Pendlum's changes to add userspace support for interfacing with the FPGA. I just want to get the ARM running GNU Radio. The meta-xilinx-community repo claims to support a BSP and build for MicroZed: http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx-community/about/ http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx-community/about/ How do I go about merging these two things together? I've taken my best guess as to how to setup a configuration with Poky: Build Configuration: BB_VERSION= 1.23.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-13.10 TARGET_SYS= arm-poky-linux-gnueabi MACHINE = microzed-zynq7 DISTRO= poky DISTRO_VERSION= 1.6+snapshot-20140822 TUNE_FEATURES = arm armv7a vfp neon zynq TARGET_FPU= vfp-neon meta meta-yocto meta-yocto-bsp= master:34436672f3ef4915e7526770a0fa8dcff328f93d meta-xilinx = master:83bf54daeaca21879290bf444876f9949b117454 meta-xilinx-community = master:a093287b81d446435d44cf238a9240782a80e1b7 meta-oe meta-networking meta-filesystems = master:8f637f9bbcdda1dc7a1998d243708c727aa6016f meta-sdr = master:21e2722a5e6671fd98268241f216e087f279566d ?Am I on the right track here? It's still fetching/building/etc. I'm not too confident it will actually work, since I don't really know what I'm doing. Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] comments on stream tags and metadata storage
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org on behalf of Peter A. Bigot p...@pabigot.com Sent: Thursday, July 17, 2014 6:11 PM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] comments on stream tags and metadata storage Some comments after playing with stream tags and metadata this afternoon. I can't speak to all of these issues due to not having played around much with the file_meta_sink and tagged_file_sink blocks but I have some responses to some of your comments/questions. (1) Although the discussion of stream tag insertion hints that this should be done within the scheduler's call to work() it could be more clear that doing it in any other context can result in race conditions. (I did think I saw it stated more clearly somewhere, but can't find that now, so maybe this point has been addressed.) (2) In the current implementation it's further necessary that tags be added to an output in monotonic non-decreasing offset order. file_meta_sink does not sort the return value from get_tags_in_range(), and emits all data up to the timestamp of the next tag, so a subsequent tag with an earlier offset is dropped from the archive. (I note that tagged_file_sink() does sort the tags it receives in one case, but not in others.) I don't see this requirement on ordered generation documented. In some cases, it may be inconvenient to do this, e.g. when a block's analysis discovers after-the-fact that something interesting can be associated with a past sample. Similarly, a user might want a block to associate a tag with sample that not yet arrived, to notify a downstream block that will need to process the event. I don't think that ordered generation is required per se, but certain blocks sort and others don't. For instance, the tag_work function in usrp_sink_impl.cc does sort precisely because get_tags_in_range doesn't. A simple solution for the infrastructure is to require that tags only be generated from within work(), with offsets corresponding to samples generated in that call to work(), and in non-decreasing offset order (though this last requirement could be handled by add_item_tag()). The developer must then handle the too-late/too-early tag associations through some other mechanism, such as carrying the effective offset as part of the tag value. As far as I'm aware, adding tags from within work is the only safe way to add tags to a stream. Also, it is required that offsets correspond to the valid range spanning the buffer of input items passed to work. The scheduler prunes others outside this range. It's also worth noting that although the history mechanism allows viewing past samples (filters use this, for example), attempting to add tags to samples in history will not work; those tags will be pruned. If tags need to be stored for future processing in subsequent calls to work, it's up to the programmer to push them onto a stack/queue/whatever inside the block. The scheduler won't handle this. (3) Qt GUI Range with widget Counter + Slider invokes callbacks twice, even if the value itself was set exactly once through the counter text entry. If the callback records the change by queuing a stream tag for addition to the output, multiple tags with the same offset/key/value will be generated. There are ugly solutions to this but it's probably sufficient to note somewhere that it can happen. It's really not specific to tags, but is clearly visible in that case. (4) The in-memory stream of tags can produce multiple settings of the same key at the same offset. However, when stored to a file only the last setting of the key is recorded. I believe this last behavior is incorrect and that it's a mistake to use a map instead of a multimap or simple list for the metadata record of stream tags associated with a sample. One argument is that it's critical that a stream archive of a processing session faithfully record the contents of the stream so that re-running the application using playback reproduces that stream and thus the original behavior (absent non-determinism due to asynchrony). This faithful reproduction is what would allow a maintainer to diagnose an operational failure caused by a block with a runtime failure when the same tag is processed twice at the same offset. This is true even if the same key is set to the same value at the same sample offset multiple times, which some might otherwise want to argue is redundant. A corollary argument is that the sample number at which an event like a tuner configuration change occurs usually can't be exactly associated with a sample; the best estimate is likely to be the index of the first sample generated by the next call to work. But depending on processing speed an application might change an attribute of a data source multiple
[Discuss-gnuradio] PyBOMBS skip volk_profile
Is there a clean way to skip volk_profile when rebuilding gnuradio with PyBOMBS? This setting seems to be automated and I can't find where to switch it off. Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS skip volk_profile
Never mind. It looks like there's a timeout before which the user can select no to running volk_profile. From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Nowlan, Sean Sent: Tuesday, July 15, 2014 4:47 PM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] PyBOMBS skip volk_profile Is there a clean way to skip volk_profile when rebuilding gnuradio with PyBOMBS? This setting seems to be automated and I can't find where to switch it off. Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT Sink center frequency not working
On Fri, Jun 20, 2014 at 5:41 PM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: Setting the center frequency in the QT Sink doesn't seem to work. It stays centered at 0 Hz. Center frequency seems to work fine with regular QT Frequency Sink. GNU Radio version is v3.7.4git-332-g34ee3b7d. I attached a GRC file. Sean Hmm... just tested your example GRC file here and it worked fine for me. Tom Strange. I’m using the latest git revision on master. PyQt4 version is 4.10.4. Any other ideas? Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT Sink center frequency not working
Well, that would help, wouldn’t it! D’oh. Thanks! Sean From: Nowlan, Sean Sent: Monday, June 23, 2014 1:39 PM To: 'Tom Rondeau' Subject: RE: [Discuss-gnuradio] QT Sink center frequency not working Ah. The shame. Thanks! From: trond...@trondeau.commailto:trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Monday, June 23, 2014 11:23 AM To: Nowlan, Sean Subject: Re: [Discuss-gnuradio] QT Sink center frequency not working Stupid question, but you are clicking the Display RF Frequencies check box, right? Tom On Mon, Jun 23, 2014 at 11:21 AM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: On Fri, Jun 20, 2014 at 5:41 PM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: Setting the center frequency in the QT Sink doesn't seem to work. It stays centered at 0 Hz. Center frequency seems to work fine with regular QT Frequency Sink. GNU Radio version is v3.7.4git-332-g34ee3b7d. I attached a GRC file. Sean Hmm... just tested your example GRC file here and it worked fine for me. Tom Strange. I’m using the latest git revision on master. PyQt4 version is 4.10.4. Any other ideas? Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] QT Sink center frequency not working
Setting the center frequency in the QT Sink doesn't seem to work. It stays centered at 0 Hz. Center frequency seems to work fine with regular QT Frequency Sink. GNU Radio version is v3.7.4git-332-g34ee3b7d. I attached a GRC file. Sean ? qt_sink_test.grc Description: qt_sink_test.grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] testing block written in block
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Activecat Sent: Wednesday, June 18, 2014 5:59 AM To: discuss-gnuradio@gnu.org Cc: sreena p h Subject: Re: [Discuss-gnuradio] testing block written in block On Wed, Jun 18, 2014 at 4:57 PM, sreena p h sreena...@yahoo.inmailto:sreena...@yahoo.in wrote: Hi I'm new to GNU radio and is trying to develop my own block. I want to develop a block that intake a vector and out put sum of the vector elements. I used the out of tree module and followed tutorial using python code. How should be the arguments of blocks.vector_source_f to be given if i am inputting vector stream of four integers is used. the python code and test file is given below. Does your intake vectors have fixed-length or variable length? If they are variable length, then your sream_ff block won't be very useful in graphical GRC flowgraph, because there the vector streams are usually fixed-length. If they are fixed-length, then your problem could be easily solved; just create sream_ff as a decimator block. If you’d rather use stock GR blocks or you would like a flowgraph with identical functionality, you can hook up a Vector to Stream block (with num_items=vector_length) to an Integrate block (with decimation=vector_length). … vector_length = 10 self.vec2stream = blocks.vector_to_stream(gr.sizeof_gr_complex, vector_length) self.integrate = blocks.integrate_cc(vector_length) self.connect((self.vec2stream, 0), (self.integrate, 0)) … Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Data Collection Across Multiple Machines and USRPs
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Tom Rondeau Sent: Tuesday, June 03, 2014 2:32 PM To: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Data Collection Across Multiple Machines and USRPs On Tue, Jun 3, 2014 at 2:28 PM, Marcus Müller marcus.muel...@ettus.commailto:marcus.muel...@ettus.com wrote: Hey Jonathan, when you cannot use GPSDOs, you should just sync your Laptops using NTP, and then set the laptop time as device time on the USRPs using set_time_now. You can then agree on a specific point in time, use set_start_time on the USRP sources and try to estimate how well-coordinated you are by cross-correlating your measurements. Greetings, Marcus I'll also recommend the file_meta_sink block: http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1file__meta__sink.html This will store a time stamp based on the time info from the USRPs. It should help you realign the data sets afterwards. Tom If you don’t have GPSDOs but need near-GPS accuracy, one option is to get cheap USB GPS pucks and configure your GPSD instance to run an NTP server, and point your system ntpd client at it. Then use the “set_time_now” UHD/gr-uhd command to set the time register on multiple radios. Finally, use the “set_start_time” command mentioned above to schedule RX captures. www.catb.org/gpsd/gpsd-time-service-howto.htmlhttp://www.catb.org/gpsd/gpsd-time-service-howto.html Sean On 03.06.2014 20:24, Jonathan Fox wrote: Hey list, this is a question for anyone that has used the USRPs and GNU Radio for synchronized data collection. I need to collect data using USRP N210s across a wireless network for a field test. Basically the USRPs would be connected to laptops running GNU radio and the laptops themselves will be networked over WiFi. My conceptualized collection would work as so: master computer that would control the collection python scripts on remote machines and itself locally (a simple USRP source to throttle to file sink). The caveat is these scripts must start within a second of each other, so I am trying to avoid delays and keep latency under a 1000 ms (preferably somewhere close to 500 ms). My initial testing of my idea at my work desk as been less than spectacular. I was using a bash script that had two lines of code: #!/bin/sh ./home/$USER/Documents/GNU_radio/data_collection.py --uhd-addr=addr=10.2.8.104 ssh -t $USER@Dell1 python ~/Documents/GNU_radio/data_collection.py --uhd-addr=addr=10.2.8.105 It is a very simple script executing a script on local and one remotely via SSH, and according to the saved data files the file creation/modification times are off. If the the save files are created from scratch, the timing is extremely close and meets expectations when it is just two scripts. If the files are already pre-existing then the modification times can range from 1 to 5 seconds. When I add more scripts to the shell script. Like so: #!/bin/sh ./home/$USER/Documents/GNU_radio/data_collection.py --uhd-addr=addr=10.2.8.104 ./home/$USER/Documents/GNU_radio/data_collection.py --uhd-addr=addr=10.2.8.102 ssh -t $USER@Dell1 python ~/Documents/GNU_radio/data_collection.py --uhd-addr=addr=10.2.8.105 ssh -t $USER@Dell1 python ~/Documents/GNU_radio/data_collection.py --uhd-addr=addr=10.2.8.103 The times are even more off and can range from 3 to 10 seconds. Alternatively, I can have dual USRP sources to file sink in the same script to get back down to the original script and I have a 3 to 7 seconds gap between the data files collected in the local script compared to the data files collected by the remote script. Is there a better way to go about collecting data quickly in synchronized fashion? I thought about a timing function built in each GNU radio script that should start the flow graph on any even second (based off a modulus function of current system time in seconds) but I want to weigh all options first. Thanks for your time reading, Jon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orgmailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orgmailto: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] Digital voice encryption block
There is no crypto in the main GNU Radio installation. I am not aware of any public out-of-tree modules that implement crypto. Your best bet would probably be handling crypto at the data socket layer and pushing to a GNU Radio PDU-to-tagged-stream or using GR's message passing interface to pass encrypted data packet between the upper layer and GR mod/demod layer. You could use PyCrypto, as you suggested, or libgcrypt in C/C++. http://www.gnu.org/software/libgcrypt/ GNU Radio is best suited for the PHY and basic MAC layers, but of course this doesn't preclude wrapping libgcrypt functions into GNU Radio blocks. I just think it would be more efficient to do crypto at a layer above the GR mod/demod blocks. You would essentially pass data between the layers using message queues and message handlers. Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Ralph A. Schmid, dk5ras Sent: Thursday, April 17, 2014 10:38 AM To: 'Tigor Christian'; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Digital voice encryption block Question 3: AES is indeed a common system for voice encryption, widely used for example in US police / public safety radios (APCO25 standard). Older systems used often DES, but not with a neat linear predictive voice codec, but just a CVSD digitizer, DES box and FSK radio link (Motorola SECURENET). Then there are lots of proprietary / closed source encryption systems, some really weak with 32 bit keys, more aimed against the casual listener / scanner kid, but not providing real security against an advanced eavesdropping attack. Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.orgmailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Tigor Christian Sent: Thursday, April 17, 2014 3:50 PM To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Digital voice encryption block Hi all, I want to simulate a voice transmission system in GNURadio Companion (GRC) before I build a real one. My system configuration is as follows. TX: mic -- encoder -- encryption -- modulator -- RF Rx: speaker -- decoder -- decryption -- demodulator -- RF I have succeed in simulating the above configuration in Ubuntu 12.04 LTS machine but without encryption/decryption blocks. I want to encrypt my digital voice using AES (128/192/256, either one) algorithm, but so far, I couldn't find suitable blocks for my purpose. I know that GNURadio will synthesize a python code when you compile your blocks configuration in GRC. On the other hand, every python dev installation in Ubuntu will also install PyCrypto lib in your machine, this library has a ready-to-use function of AES algorithm. Furthermore, I also know the concept of Out-of-Tree Module (OoTM) of GNURadio. My questions are: 1. My first thought is to get data stream of certain block and do encryption process with PyCrypto (not in the OoTM, but directly in synthesized python code) then put them back to the next block. Would it be possible and how to achieve this? 2. Do GNURadio has a ready-to-use GRC blocks or OoTM of digital encryption algorithm (not scrambler)? and how do I get it (a tutorial would be fine)? So far, I can not found the block either in GRC or https://www.cgran.orghttps://www.cgran.org/ 3. Last question may be off topic a bit. Is it common to use AES algorithm to encrypt voice data, or is there any common encryption method (preferably could be implemented in GRC)? Thank you for your time and willingness to answer these questions Regards tc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Conference 2014 - Registration is Open!
Looking forward to it! What will generally be the agenda for the New Developers' Day? Do you see a role for people who have been hacking at GR for a while, or is it specifically catered to new users? I'm trying to debate whether to go the extra day or not, and I bet I'm not the only one who is curious. :) Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of John Malsbury Sent: Wednesday, March 12, 2014 2:49 AM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] GNU Radio Conference 2014 - Registration is Open! Greetings, We just wanted to let everyone know that registration for GNU Radio Conference 2014 is now open. Here is a quick overview of the event for those of you who have missed previous announcements: Date: September 15-19, 2014 Location: The District Architecture Centerhttp://aiadac.com/ in Washington, DC (USA) - an interesting, modern event facility. Unlike previous conference values, we will be renting out an entire floor and will have access to several divided spaces that will allow us to add new components to the conference. Attendance: We are expecting to have somewhere between 120 and 150 attendees. A great mix of new users, experienced developers, students, professors, engineers and researchers. This is the perfect mix for everyone to share their experiences with GNU Radio, learn more about it, and help build the future of SDR. New Components: Hacker/demo space, poster session, 'New Developers Day' to attract new/beginning users, an open lounge for people to socialize and mingle, and daily working groups. For more information, and links to the registration page, please see the GNU Radio Conference Websitehttp://www.trondeau.com/grcon14. We will be posting a preliminary agenda, and more details about the facility soon. I'd also like to take this opportunity to remind everyone about the Call for Presentationshttp://www.trondeau.com/grc2014-call-for-presentations/, which is open until March 31. We've seen some great submissions up to this point, and look forward to receiving more! Best Regards, John Malsbury ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Conference 2014 - Registration is Open!
I'd be happy to help! I'm sure classroom-style lectures will be covered by a few people who have already presented the material a bunch of times (Tom, Johnathan, etc.). Maybe you could use a bunch of more experienced GR people in small breakout sessions or to oversee hands-on tutorials, etc. I'll be on the lookout for how to get involved. Sean From: John Malsbury [mailto:john.malsb...@ettus.com] Sent: Friday, March 14, 2014 3:09 PM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] GNU Radio Conference 2014 - Registration is Open! Sean, Thanks for bringing this up. Simply stated, the goal of this New Users Day is: * Increase visibility for GNU Radio, possibly touching new professional and social circles where GNU Radio isn't used yet * Help new users understand what GNU Radio is, and how to use it In some ways this is a marketing opportunity for GNU Radio. But the major focus will be on actually teaching people the basics of GNU Radio through lecture and possibly hands-on tutorials. Hopefully this gives you an idea of the type of content we'll have on the first day. It would seem someone with your experience would get more value out of contributing the event, rather than sitting through the presentations/tutorials. It would be great if everyone can help promote this widely. A single-day event will be more oriented toward a regional audience, but in an ideal case people from all over will come for the new user day and stay for the conference. It's going to be a great show this year! Aside from the high quality presentations we have every year, there will be more time for working groups, and a hackerspace filled with enough hardware for everyone to make some trouble. More details will be forthcoming. In the meantime, I suppose the call to action is - help us promote! Registration is open, and seats are filling up. -John On Fri, Mar 14, 2014 at 11:51 AM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: Looking forward to it! What will generally be the agenda for the New Developers' Day? Do you see a role for people who have been hacking at GR for a while, or is it specifically catered to new users? I'm trying to debate whether to go the extra day or not, and I bet I'm not the only one who is curious. :) Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlanmailto:discuss-gnuradio-bounces%2Bsean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org] On Behalf Of John Malsbury Sent: Wednesday, March 12, 2014 2:49 AM To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] GNU Radio Conference 2014 - Registration is Open! Greetings, We just wanted to let everyone know that registration for GNU Radio Conference 2014 is now open. Here is a quick overview of the event for those of you who have missed previous announcements: Date: September 15-19, 2014 Location: The District Architecture Centerhttp://aiadac.com/ in Washington, DC (USA) - an interesting, modern event facility. Unlike previous conference values, we will be renting out an entire floor and will have access to several divided spaces that will allow us to add new components to the conference. Attendance: We are expecting to have somewhere between 120 and 150 attendees. A great mix of new users, experienced developers, students, professors, engineers and researchers. This is the perfect mix for everyone to share their experiences with GNU Radio, learn more about it, and help build the future of SDR. New Components: Hacker/demo space, poster session, 'New Developers Day' to attract new/beginning users, an open lounge for people to socialize and mingle, and daily working groups. For more information, and links to the registration page, please see the GNU Radio Conference Websitehttp://www.trondeau.com/grcon14. We will be posting a preliminary agenda, and more details about the facility soon. I'd also like to take this opportunity to remind everyone about the Call for Presentationshttp://www.trondeau.com/grc2014-call-for-presentations/, which is open until March 31. We've seen some great submissions up to this point, and look forward to receiving more! Best Regards, John Malsbury ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] get_tags_in_range
On Mon, Mar 10, 2014 at 4:16 PM, Nowlan, Sean sean.now...@gtri.gatech.edu
wrote:
On Mon, Mar 10, 2014 at 5:55 AM, Martin Braun martin.br...@ettus.com wrote:
On 03/10/2014 01:08 AM, Nowlan, Sean wrote:
I'm using get_tags_in_range with bounds outside the absolute sample
offsets presented in each work function. I'm using this to add
end-of-burst tags at offset K-1 for every start-of-burst tag that I
find at offset K (except the very first K).
I just want to confirm that this is valid. All my tests have shown
that it is, since I believe the underlying deque is completely
independent of the data stream except that offsets are used for
both absolute sample offsets and tag bookkeeping.
I think you're right, but only if you do this *after* the current
bounds, not before.
M
Yes, the scheduler prunes all tags before the window after work is done.
Basically, since we're tagging a data sample, if that sample is no longer
available to you, neither is it's tag. You'll have to get them and store
them locally for your uses later.
Tom
Ok, that makes sense; I'd be unable to read tags from the past. But what
happens if I *create* a tag on a past data sample? Will it be propagated or
ignored?
( A ) { B }
(0 1) { 2 3 4 } 5 ...
Let's say section ( A ) is from a previous call to work. Let's also say { B
} is the current work window, i.e., nitems_read(0) == 2 and noutput_items ==
3. If I find a start-of-burst tag on absolute offset 2, is it impossible to
create a new tag on absolute offset 1?
The vast majority of the time, this would not be a problem. The boundary
condition is really the only source of trouble. I suppose I could use
set_history(2) so that I can always see the tags at the offset range
endpoints. Do you advise this? Does history ensure the scheduler doesn't
prune tags from the history region?
Sean
Yeah, if you set a tag to a time in the past, the following blocks will
(likely, based on the dynamics of the scheduler) prune it before your
follow-on block can process it.
I'd have to double check and think about the case where you use set_history
for this. It seems like it should work, but just remember that set history
really just initializes your read pointers back by
history()-1 number of items. So the tag wouldn't go on item-2 in the stream
since index 0 of the buffer /is/ item-2 already.
Ok, I guess I should go poke around the prune_tags logic and see how it works.
If it respects history(), it wouldn't prune tags from any item that is
available at the start of the read pointer, including history. If it doesn't,
tags may be abandoned/pruned even though I have access to history()-1 number of
previous items, and I'm still stuck.
Functionally speaking, if I can read a sample, I should be able to read its
associated tags. But history() only involves input buffers, not output buffers,
so perhaps I'm still falling into the trap mentioned above, i.e., the tag may
be pruned before the downstream block can see it.
But something like this, if not exactly, should work, yes.
I'm trying to determine an exact solution. This is another way to work around
PFB arb resampler tag propagation issues (discussed in issue #652). Basically
I'm adding a start-of-burst tag to the first sample of a stream pre-resampler,
and then once things have been resampled, I go back and fill in end-of-burst
tags. This avoids having to know when the PFB arb resampler adds +/- 1 samples.
This block I've written is a sync_block that simply does a memcpy of samples
and the tag processing mentioned above.
Now I'm thinking a workaround could be to return noutput_items-1 items. This
way I get to check the last item of a work input buffer,
nitems_read(0)+noutput_items-1, for a start-of-burst tag and place an
end-of-burst tag at nitems_read(0)+noutput_items-2. At the next call to work,
that last item of the previous input buffer is the first item of the input
buffer, and I can put an end-of-burst tag at nitems_read(0) if I find a tag at
nitems_read(0)+1. Makes sense in my head, at least...
Tom
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] get_tags_in_range
I'm using get_tags_in_range with bounds outside the absolute sample offsets presented in each work function. I'm using this to add end-of-burst tags at offset K-1 for every start-of-burst tag that I find at offset K (except the very first K). I just want to confirm that this is valid. All my tests have shown that it is, since I believe the underlying deque is completely independent of the data stream except that offsets are used for both absolute sample offsets and tag bookkeeping. Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with undefined symbol in new block created by gr_modtool in 3.7.2
The first place I'd look is in your_block.h. Did you remember to declare any public member functions to be pure virtual in that file, and then declare your (non-virtual) functions in your_block_impl.h? If you forgot to declare pure virtual functions, i.e., virtual return_type your_block(args_list) = 0; in your_block.h, it will compile but you will get the undefined symbol at runtime. This probably a common pitfall and it might be worth making a note in the wiki for OutOfTreeModules. I'll add that. Architects of gr_modtool... can you add an autogen comment in *.h files reminding the user to declare pure virtual functions? I think users who don't deeply understand OO and particularly its C++ syntax would benefit from this reminder. I think it's a common paradigm to use other examples to fill in the guts of gr_modtool generated C++ code, but things like this are easy to miss. Sean -Original Message- From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Marcus Müller Sent: Wednesday, March 05, 2014 3:21 PM To: George Sklivanitis; GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Problem with undefined symbol in new block created by gr_modtool in 3.7.2 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi George, This is a little unspecific. Most probably you have a problem similar to the fftw- related problem of activecat, but that's only guessing... Please heed http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors when reporting errors. Greetings, Marcus On March 5, 2014 8:57:46 PM CET, George Sklivanitis george.sklivani...@gmail.com wrote: Hello all, I am dealing with the problem of undefined symbol when trying to execute a python script for testing my new custom block created in GNU Radio 3.7.2. I used gr_modtool for creating the new block and also followed the instructions posted at http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConf ig for correctly configuring it but the problem still holds. Any ideas? Thanks, -George -- Sklivanitis Georgios --- - ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- Version: APG v1.0.9 iQFABAEBCAAqBQJTF4c7IxxNYXJjdXMgTfxsbGVyIDxtYXJjdXNAaG9zdGFsaWEu ZGU+AAoJEBKNLRrpJvfojQoH/2a609iWLTsywtozQ+FcZkuQT6uCy13vX3n4b5k3 rTvy9QP3uHuHQkiRZHDbZoJ+mZ9kFOf6NeG20RGdf8i4yCB1AZ8F7uvvdi7CebXT sRQxoQE+8Vz5VS+faAStAOK3+tArdRGZOU2v3gTYXGCvATaeM3A+rxsNQ7LKPwM8 sI5KZ3xgvgikkObbFuo00MOaLA7tHzMttXxWjU5riXann1l1eOyGIzM1j0XO1gAD imofs0DfXHB4cE0Gi43E1gjjeqEW034dLZAS7w/c/Gq85Z0Ni+z1a35kS5UYvYhQ ndeEMqrLQv4ghCRnHR93ob+8YRlqMedVjDDeKQdjEh0D2jY= =27ny -END PGP SIGNATURE- ___ 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] Problem with undefined symbol in new block created by gr_modtool in 3.7.2
Ah, nevermind about the wiki edit. The use of pure virtual functions is already discussed in http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide . Still, the gr_modtool addition may be useful. -Original Message- From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Nowlan, Sean Sent: Wednesday, March 05, 2014 4:45 PM To: Marcus Müller; George Sklivanitis; GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Problem with undefined symbol in new block created by gr_modtool in 3.7.2 The first place I'd look is in your_block.h. Did you remember to declare any public member functions to be pure virtual in that file, and then declare your (non-virtual) functions in your_block_impl.h? If you forgot to declare pure virtual functions, i.e., virtual return_type your_block(args_list) = 0; in your_block.h, it will compile but you will get the undefined symbol at runtime. This probably a common pitfall and it might be worth making a note in the wiki for OutOfTreeModules. I'll add that. Architects of gr_modtool... can you add an autogen comment in *.h files reminding the user to declare pure virtual functions? I think users who don't deeply understand OO and particularly its C++ syntax would benefit from this reminder. I think it's a common paradigm to use other examples to fill in the guts of gr_modtool generated C++ code, but things like this are easy to miss. Sean -Original Message- From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Marcus Müller Sent: Wednesday, March 05, 2014 3:21 PM To: George Sklivanitis; GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Problem with undefined symbol in new block created by gr_modtool in 3.7.2 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi George, This is a little unspecific. Most probably you have a problem similar to the fftw- related problem of activecat, but that's only guessing... Please heed http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors when reporting errors. Greetings, Marcus On March 5, 2014 8:57:46 PM CET, George Sklivanitis george.sklivani...@gmail.com wrote: Hello all, I am dealing with the problem of undefined symbol when trying to execute a python script for testing my new custom block created in GNU Radio 3.7.2. I used gr_modtool for creating the new block and also followed the instructions posted at http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConf ig for correctly configuring it but the problem still holds. Any ideas? Thanks, -George -- Sklivanitis Georgios --- - ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- Version: APG v1.0.9 iQFABAEBCAAqBQJTF4c7IxxNYXJjdXMgTfxsbGVyIDxtYXJjdXNAaG9zdGFsaWEu ZGU+AAoJEBKNLRrpJvfojQoH/2a609iWLTsywtozQ+FcZkuQT6uCy13vX3n4b5k3 rTvy9QP3uHuHQkiRZHDbZoJ+mZ9kFOf6NeG20RGdf8i4yCB1AZ8F7uvvdi7CebXT sRQxoQE+8Vz5VS+faAStAOK3+tArdRGZOU2v3gTYXGCvATaeM3A+rxsNQ7LKPwM8 sI5KZ3xgvgikkObbFuo00MOaLA7tHzMttXxWjU5riXann1l1eOyGIzM1j0XO1gAD imofs0DfXHB4cE0Gi43E1gjjeqEW034dLZAS7w/c/Gq85Z0Ni+z1a35kS5UYvYhQ ndeEMqrLQv4ghCRnHR93ob+8YRlqMedVjDDeKQdjEh0D2jY= =27ny -END PGP SIGNATURE- ___ 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] message port names
Hi Sean, Tom and Martin, basic_block enforces using a symbol in its message_port_register_in method, so that's where you'd have to start changing things. But to add my 0b0010* ct to this: - using strings as port names keeps consistency - using strings is the proper way to ensure all tools (esp. the companion) display port names alike and are able to save/generate a flowgraph into/from a text file format - stepping away from pmt_symbol as port name type opens up the gate for people doing stuff like assigning numeric values of different types (that could lead to a nice monte carlo QA for pmt::eqv; corner cases like pmt::eqv(pmt_uint64(x),pmt_int(x))==false will lead to problems) - I guess the whole point of pmt_symbol is it being unique and provide guaranteed identification** - comparatively very little overhead with the outK method, your workaround seems feasible (also: you could consider keeping your own port name std::vectorpmt_t and use that for later reference; if you just need a (strangely sorted) list of your ports, it's basic_block::msg_queue) - hashing overhead negligible for short strings and it speeds up the std::map operations when adding/using message ports (hashing will probably even pay during runtime) +Ok, I admit it's strange to use PMTs if you'd actually wanted to use strings (and have the type safety) Greetings, Marcus I don't see a need to change how it's currently being done, i.e., using string_to_symbol. I had just asked the question because I was curious, and I think the outK workaround is useful because it corresponds with how GRC automates naming with nports. * valid for gcc 4.3+, clang and C++14 ;) ** Tom: why is there a d_next member in pmt_symbol? On 02/28/2014 09:19 AM, Martin Braun wrote: On 02/28/2014 01:39 AM, Nowlan, Sean wrote: Hey Sean, I /think/ so. I'd have to double check, but at some point it's likely to go through a symbol_to_string conversion. Can you think of a need for a port name to be something other than a symbol/string? Maybe an enumeration or something? Tom In a certain block I'm registering N ports, where N is a constructor argument to the block. I was hoping I could call them pmt::from_long(0) through pmt::from_long(N-1), but that didn't work. I ended up creating string names out0 through outK (where K = N-1) and then used pmt::string_to_symbol. I doubt anyone implemented that to limit names, it was more likely that we didn't think of this use case. If you see this is a small, non-invasive change that would allow other PMTs to be port names, that would be interesting to see. M ___ 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] message port names
From: trond...@trondeau.com [trond...@trondeau.com] on behalf of Tom Rondeau [t...@trondeau.com] Sent: Thursday, February 27, 2014 2:45 PM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] message port names On Mon, Feb 24, 2014 at 2:46 PM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: Quick question: can a message port name be any valid PMT type? Or does it have to be a string converted to a symbol? Thanks, Sean Hey Sean, I /think/ so. I'd have to double check, but at some point it's likely to go through a symbol_to_string conversion. Can you think of a need for a port name to be something other than a symbol/string? Maybe an enumeration or something? Tom In a certain block I'm registering N ports, where N is a constructor argument to the block. I was hoping I could call them pmt::from_long(0) through pmt::from_long(N-1), but that didn't work. I ended up creating string names out0 through outK (where K = N-1) and then used pmt::string_to_symbol. Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Message API questions
I have a few questions regarding messages in GR. 1) Is it possible to mix-and-match the old style message sink/source blocks with the new style message passing API? Any guidance on how to make the connections? I didn't have much luck with msg_connect. I don't think the message sink/source blocks have an associated port name to make this possible. Perhaps that's something worth adding internally? 2) I see 2 implementations of msg_queue, one in gr namespace and one in gr::messages namespace. What are the differences between these? 3) How does one achieve flow control with the new style message passing API? I have a use case in which I'm generating packets in one flowgraph and pushing them through a pdu_to_tagged_stream (P2TS) block to be modulated in another flowgraph. I believe I'm overwhelming the P2TS block's queue because I get warnings about dropped messages. One hack I made was to insert a throttle block into the packet generating flowgraph. This helped a bit, but I have to guess the magic throttle rate at which I don't fill up the queue. Is there a way to have P2TS block when its queue is full and therefore generate backpressure on the upstream flowgraph? Thanks! Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Message API questions
From: Aditya Dhananjay [mailto:adi...@cs.nyu.edu] Sent: Wednesday, February 26, 2014 8:53 AM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Message API questions On Wed, Feb 26, 2014 at 8:45 AM, Nowlan, Sean sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote: I have a few questions regarding messages in GR. 1) Is it possible to mix-and-match the old style message sink/source blocks with the new style message passing API? Any guidance on how to make the connections? I didn't have much luck with msg_connect. I don't think the message sink/source blocks have an associated port name to make this possible. Perhaps that's something worth adding internally? I'm not sure I completely understand your question. Have you looked at the OFDM Tx/Rx examples in PATH/gr-digital/examples/ofdm? The flowgraph is a combination of standard connections within blocks, along with a message passing connection (look at the header/payload demux block). Thanks! What I was referring to are the gr::blocks::message_source and gr::blocks::message_sink blocks. They don't use the new style message passing API in which you register ports and message handlers. Instead, gr::blocks::message_source has an internal message queue. It blocks in within its work function waiting for a message to enter the queue. What I'm wondering is how to connect a new style block's message output with the input to this block, and the inverse case for connecting a gr::blocks::message_sink to a new style block's message input. 2) I see 2 implementations of msg_queue, one in gr namespace and one in gr::messages namespace. What are the differences between these? 3) How does one achieve flow control with the new style message passing API? I have a use case in which I'm generating packets in one flowgraph and pushing them through a pdu_to_tagged_stream (P2TS) block to be modulated in another flowgraph. I believe I'm overwhelming the P2TS block's queue because I get warnings about dropped messages. One hack I made was to insert a throttle block into the packet generating flowgraph. This helped a bit, but I have to guess the magic throttle rate at which I don't fill up the queue. Is there a way to have P2TS block when its queue is full and therefore generate backpressure on the upstream flowgraph? Are you using actual hardware or is this a software only simulation? I basically have flowgraph (FG1) -- message domain -- flowgraph (FG2) -- USRP. FG1's flow rate is not constrained by streaming backpressure. FG2's flow rate is constrained by the USRP. To constrain FG1's flow rate I either have to use a throttle block or find a way to enforce flow control in the message domain. Thanks! Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orgmailto: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] Async message flow control
How does one achieve flow control with the new style message passing API? I have a use case in which I'm generating packets in one flowgraph and pushing them through a pdu_to_tagged_stream (P2TS) block to be modulated in another flowgraph. I believe I'm overwhelming the P2TS block's queue because I get warnings about dropped messages. One hack I made was to insert a throttle block into the packet generating flowgraph. This helped a bit, but I have to guess the magic throttle rate at which I don't fill up the queue. Is there a way to have P2TS block when its queue is full and therefore generate backpressure on the upstream flowgraph? I basically have flowgraph (FG1) -- message domain -- flowgraph (FG2) -- USRP. FG1's flow rate is not constrained by streaming backpressure. FG2's flow rate is constrained by a USRP. To constrain FG1's flow rate I either have to use a throttle block or find a way to enforce flow control in the message domain. Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] message port names
Quick question: can a message port name be any valid PMT type? Or does it have to be a string converted to a symbol? Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Catch-22 with forecast general_work
I have a situation in which I need to read tags associated with multiple block inputs in order to decide which input to process during general_work. In my situation it's possible for there to be zero input available to some inputs, and a nonzero amount of input available to others. The Catch-22 is that if I demand ninput_items_required[k] = 1 on all k inputs, but any individual input doesn't have any data available yet, the scheduler will never call general_work. If I demand ninput_items_required[k] = 0 for all inputs, my general_work method will be called, but there will be no data to process, even if there actually is data available on some inputs. The problem is partially solved by the tagged_stream_block implementation. However, the huge limitation with that approach is that tagged streams are limited to a maximum on the order of 8k items (this number is probably system dependent). If I want to operate on a tagged stream that is several orders of magnitude greater than this limit, I'm out of luck. Does anybody have any suggestions? I may end up having to reimplement tagged_stream_block to hold some internal state so it can handle tagged streams much larger than any one call to work. This state would be some variable, maybe nitems_left_in_tagged_stream that would get reset every time a length_tag was found and would be decremented by the number of items consumed. The forecast implementation would demand ninput_items_reqd[k] = min(items_left_in_tagged_stream, noutput_items), or something like that. Thoughts? Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
Clayton and I worked on the FM RDS project over the last weeks. I think that the receiving side is in a pretty good state now. It works well with the RTL SDR. This is really cool! Worked right out of the box. It's decoding and displaying the local NPR station without any problems. Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Message port connections in gr-blocks/examples/msg_passing
-Original Message- From: Bastian Bloessl [mailto:bastian.bloe...@uibk.ac.at] Sent: Friday, December 20, 2013 9:06 AM To: Koslowski, Sebastian (CEL) Cc: Tom Rondeau; Nowlan, Sean; GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Message port connections in gr-blocks/examples/msg_passing Hi, On 19 Dec 2013, at 17:45, Koslowski, Sebastian (CEL) sebastian.koslow...@kit.edu wrote: I am a little surprised to hear that gr-ieee802-11 files are not working either because it was Bastian who came up with the need to change this... I'm currently travelling and can't test it, but I updated my stuff and tested it on several different PCs. So it should work. The conversation with Sean about the broken connections was before the changes to mainline. At that time I had a non-standard installation and therefore my flow graphs did not work for out of the box. But that should be fixed now. Bastian - Sorry I didn't provide that context, i.e., that my experience with gr-ieee802-11 was several weeks ago before those changes. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio-companion segfaults with latest gnuradio master and gr-osmosdr
When I run gnuradio-companion with the latest gnuradio master and gr-osmosdr master, it segfaults. A backtrace reveals that there's a problem when Python tries to load _osmosdr_swig. If I uninstall gr-osmosdr, gnuradio-companion opens normally. GDB backtrace: http://pastebin.com/PYmyAbqE Let me know if I should open a bug report. I'm not sure if others are experiencing this, or there is just something weird or misconfigured on my system. Ubuntu 13.04 x86_64 Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Message port connections in gr-blocks/examples/msg_passing
I'm trying to learn the message passing API by reviewing the examples in gr-blocks/examples/msg_passing. Message ports are not connected upon opening GRC (this seems to be a gnuradio-wide problem - same thing happens with gr-ieee802-11). I know the workaround is to open each hier block and build so that code gets put in ~/.grc_gnuradio. However, I'm not sure how to hook up the ports as they were intended. Does anybody have screen captures of strobe.grc, test_msg_hier.grc, and test_msg_hier_topblock.grc with the ports connected correctly? Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception
Sorry it took me a bit of time to respond. Yes, I'm sure my flowgraph is still
running and producing data as expected. Can anybody think of why the ice
endpoint would die unexpectedly?
Sean
From: Tim Newman [mailto:tim.new...@gmail.com]
Sent: Wednesday, November 13, 2013 11:42 AM
To: Nowlan, Sean
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception
I've seen ICE do this before, but usually its because my flowgraph dies, via
segfault or something. When the flowgraph dies, the ice endpoints aren't
available anymore so the controlport monitor timesout when attempting to query
them. Are you sure your flowgraph isn't crapping out for some reason or
another?
Tim
On Wed, Nov 13, 2013 at 11:10 AM, Nowlan, Sean
sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote:
From:
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlanmailto:discuss-gnuradio-bounces%2Bsean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org]
On Behalf Of Nowlan, Sean
Sent: Monday, November 11, 2013 4:10 PM
To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception
I'm using ControlPort to monitor transmissions through a USRP. I have a
flowgraph responsible for generating burst traffic and streaming to a
uhd_sink. Then I have a uhd_source tuned to the same frequency as the
uhd_sink, and I connect it to a ctrlport_probe2_c block with length=128. I
have ControlPort support compiled-in and enabled from a config file. I'm able
to connect to a remotely running flowgraph using gr-ctrlport-monitor and plot
the PSD of the samples vector pulled from the probe2 block every 100
milliseconds. The problem is that after (what seems to be) a nondeterministic
time, the ICE port stops responding and gr-ctrlport-monitor reports an error:
ctrlport-monitor: radio.get threw exception (exception
::Ice::ConnectTimeoutException
{
}).
When I close and restart, gr-ctrlport-monitor times out and segfaults:
2013-11-11 16:02:47.329422 /usr/local/bin/gr-ctrlport-monitor: error:
Traceback (most recent call last):
File /usr/lib/pymodules/python2.7/Ice.py, line 984, in main
status = self.doMain(args, initData)
File /usr/lib/pymodules/python2.7/Ice.py, line 1031, in doMain
return self.run(args)
File
/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
line 97, in run
radio = self.getRadio(host, port)
File
/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
line 36, in getRadio
radio = GNURadio.ControlPortPrx.checkedCast(base)
File /usr/local/lib/python2.7/dist-packages/gnuradio_ice.py, line 1257, in
checkedCast
return _M_gnuradio.ctrlport.GNURadio.ControlPortPrx.ice_checkedCast(proxy,
'::GNURadio::ControlPort', facetOrCtx, _ctx)
ConnectTimeoutException: exception ::Ice::ConnectTimeoutException
{
}
Segmentation fault (core dumped)
So there are two issues to note here:
-Something in the ICE instance is breaking on the GNU Radio flowgraph
side. The port is still open; it just times out. Trying to instantiate
gr-ctrlport-monitor to an incorrect port just says connection refused, as
expected.
-gr-ctrlport-monitor is not robust to connection-related errors like
timeouts or refused connections.
Is there any advice of what I can turn on or enable in GNU Radio or my
flowgraph to debug the first problem? I can live with the second problem as
long as I can make sure ICE doesn't break on me.
Thanks,
Sean
Sorry for getting antsy about this, but I'm really not sure how to go about
debugging ICE server stuff. It seems like it's buried pretty deeply in
gnuradio-runtime. Where's the best place to start looking to find out why the
ICE server stops responding?
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.orgmailto: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-ctrlport-monitor timeout exception
Perhaps this is happening due to the ICE endpoint's TCP timeout setting. I have
it configured to 300 ms based on the example ctrlport.conf file distributed
with GNU Radio. I'll try increasing this. A few questions:
1) What disadvantages would there be to setting this to something really
high?
2) I need to monitor things over a potentially unreliable connection. It
looks straightforward to configure the ICE endpoint to use UDP. What would it
take to make gr-ctrlport-monitor work with a UDP endpoint?
Thanks,
Sean
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Nowlan, Sean
Sent: Tuesday, December 03, 2013 3:13 PM
To: Tim Newman
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception
Sorry it took me a bit of time to respond. Yes, I'm sure my flowgraph is still
running and producing data as expected. Can anybody think of why the ice
endpoint would die unexpectedly?
Sean
From: Tim Newman [mailto:tim.new...@gmail.com]
Sent: Wednesday, November 13, 2013 11:42 AM
To: Nowlan, Sean
Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception
I've seen ICE do this before, but usually its because my flowgraph dies, via
segfault or something. When the flowgraph dies, the ice endpoints aren't
available anymore so the controlport monitor timesout when attempting to query
them. Are you sure your flowgraph isn't crapping out for some reason or
another?
Tim
On Wed, Nov 13, 2013 at 11:10 AM, Nowlan, Sean
sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote:
From:
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlanmailto:discuss-gnuradio-bounces%2Bsean.nowlan=gtri.gatech@gnu.orgmailto:gtri.gatech@gnu.org]
On Behalf Of Nowlan, Sean
Sent: Monday, November 11, 2013 4:10 PM
To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception
I'm using ControlPort to monitor transmissions through a USRP. I have a
flowgraph responsible for generating burst traffic and streaming to a
uhd_sink. Then I have a uhd_source tuned to the same frequency as the
uhd_sink, and I connect it to a ctrlport_probe2_c block with length=128. I
have ControlPort support compiled-in and enabled from a config file. I'm able
to connect to a remotely running flowgraph using gr-ctrlport-monitor and plot
the PSD of the samples vector pulled from the probe2 block every 100
milliseconds. The problem is that after (what seems to be) a nondeterministic
time, the ICE port stops responding and gr-ctrlport-monitor reports an error:
ctrlport-monitor: radio.get threw exception (exception
::Ice::ConnectTimeoutException
{
}).
When I close and restart, gr-ctrlport-monitor times out and segfaults:
2013-11-11 16:02:47.329422 /usr/local/bin/gr-ctrlport-monitor: error:
Traceback (most recent call last):
File /usr/lib/pymodules/python2.7/Ice.py, line 984, in main
status = self.doMain(args, initData)
File /usr/lib/pymodules/python2.7/Ice.py, line 1031, in doMain
return self.run(args)
File
/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
line 97, in run
radio = self.getRadio(host, port)
File
/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
line 36, in getRadio
radio = GNURadio.ControlPortPrx.checkedCast(base)
File /usr/local/lib/python2.7/dist-packages/gnuradio_ice.py, line 1257, in
checkedCast
return _M_gnuradio.ctrlport.GNURadio.ControlPortPrx.ice_checkedCast(proxy,
'::GNURadio::ControlPort', facetOrCtx, _ctx)
ConnectTimeoutException: exception ::Ice::ConnectTimeoutException
{
}
Segmentation fault (core dumped)
So there are two issues to note here:
-Something in the ICE instance is breaking on the GNU Radio flowgraph
side. The port is still open; it just times out. Trying to instantiate
gr-ctrlport-monitor to an incorrect port just says connection refused, as
expected.
-gr-ctrlport-monitor is not robust to connection-related errors like
timeouts or refused connections.
Is there any advice of what I can turn on or enable in GNU Radio or my
flowgraph to debug the first problem? I can live with the second problem as
long as I can make sure ICE doesn't break on me.
Thanks,
Sean
Sorry for getting antsy about this, but I'm really not sure how to go about
debugging ICE server stuff. It seems like it's buried pretty deeply in
gnuradio-runtime. Where's the best place to start looking to find out why the
ICE server stops responding?
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.orgmailto:Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] A good alternative for Ezcap DVB-T Dongle??
My experience has been that the EZcaps with E4000 aren't easy to get anymore since the E4000 has been discontinued. I'll second Rui's notion that you should look for something with the R820T. I just picked one up last week - it seems to have much better sensitivity and much less LO leakage (DC spike) than my EZcap. Look for the NooElec TV28T: http://www.amazon.com/Receiver-RTL2832U-Compatible-Packages-Guaranteed/dp/B009U7WZCA/ Sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Manu T S Sent: Tuesday, November 19, 2013 7:58 AM To: Rui Pinheiro; GNURadio Discussion List Subject: Re: [Discuss-gnuradio] [USRP-users] A good alternative for Ezcap DVB-T Dongle?? Hi Rui, I was looking for alternatives because ezcap dongles are not readily available in India. When I bought one (I bought from dealextream) it had to be shipped from Hong Kong and took many days to reach me. I had to pay extra customs duty.(That any way will be unavoidable) . I'm not averse to ezcap in any way. But I'm looking for better reliability about shipping. If you are aware of any dealers selling ezcap, I would be glad to know the details. Thanks. Manu On Tue, Nov 19, 2013 at 5:59 PM, Rui Pinheiro ruipinhei...@gmail.commailto:ruipinhei...@gmail.com wrote: Hi Manu, why an alternative? I uses dongles with the E4000 tuner some cynergys. In my opinion the ezcap with the R820T tuner works better and more stable (rtl-sdr project). Cheers.. Rui Am 19.11.2013 12:36 schrieb Manu T S manu.t.s...@gmail.commailto:manu.t.s...@gmail.com: Hi, What are the options for a good alternative for Ezcap DVB-T dongle? We need some RTL SDR dongles, for setting up experiments for undergraduate communication lab course. We were planning to buy some RTL SDR compatible dongles for the same. If anyone knows a good alternative for Ezcap DVB-T dongle, please let me know. Any amount of details ( specifications, available vendors) are welcome. Thank you. -- Manu T S ___ USRP-users mailing list usrp-us...@lists.ettus.commailto:usrp-us...@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC: File/Path browser in QT or WX gui ?
You could have a text box with a file open dialog, and the callback would lock/stop the flowgraph, give the returned file path string to a file_source block, and then unlock/start the flowgraph. -Original Message- From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of M Dammer Sent: Wednesday, November 20, 2013 10:12 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] GRC: File/Path browser in QT or WX gui ? I was thinking about people who just load a flowgraph and start it. In this case it would be very convenient to have all parameters that need adjusting (including filepath) in the GUI. greetings, Mark On 20/11/13 15:07, Marcus Müller wrote: I think that would be possible; however, before you start coding it yourself, please consider the use case: In most cases, things like I want to read that file are considered before starting a flow graph. Greetings, Marcus On 20.11.2013 15:08, M Dammer wrote: I am looking for a standard file browser widget for a QT or Wx based GUI. You browse the filesystem and the moment you click o.k. the choosen path is put into a variable that can be used within your flowgraph. Is this possible ? Currently the only option I see is to set the filename/path within the flowgraph (e.g. WAV sinks/sources). 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 ___ 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-ieee802-11 grc files missing
I'm taking a look at the gr-ieee802-11 project. I'm unable to use ofdm_loopback.grc because ofdm_phy_hier appears to be missing. I've installed gr-ieee802-11 and gr-foo from Bastian's github page. What step am I missing? Thanks, Sean Welcome to GNU Radio Companion v3.7.2-13-gf1904733 Loading: ofdm_loopback.grc Error: Block key ofdm_phy_hier not found in Platform - grc(GNU Radio Companion) Error: Connection between ofdm_phy_hier_1(0) and foo_packet_pad_0(0) could not be made. source block id ofdm_phy_hier_1 not in block ids Error: Connection between blocks_add_xx_0(0) and ofdm_phy_hier_1(0) could not be made. sink block id ofdm_phy_hier_1 not in block ids Error: Connection between blocks_message_strobe_0(0) and ieee802_11_ofdm_mac_0(0) could not be made. source key 0 not in source block keys Error: Connection between ofdm_phy_hier_1(1) and ieee802_11_ofdm_mac_0(1) could not be made. source block id ofdm_phy_hier_1 not in block ids Error: Connection between ieee802_11_ofdm_mac_0(1) and ofdm_phy_hier_1(1) could not be made. sink block id ofdm_phy_hier_1 not in block ids Error: Connection between ofdm_phy_hier_1(1) and ieee802_11_ofdm_parse_mac_0(0) could not be made. source block id ofdm_phy_hier_1 not in block ids ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-ieee802-11 grc files missing
I don't know if there is a way to include hierarchical blocks in the installation process. So for now you have to manually open ofdm_phy_hier.grc and click build. This installs the block in your ~/.grc_gnuradio folder. Then reopen grc. Thanks, Bastian. I tried this and got another error: Welcome to GNU Radio Companion v3.7.2-13-gf1904733 Loading: ofdm_phy_hier.grc Error: Connection between pad_source_1(0) and ieee802_11_ofdm_mapper_0(0) could not be made. sink key 0 not in sink block keys Error: Connection between ieee802_11_ofdm_decode_mac_0(0) and pad_sink_1(0) could not be made. source key 0 not in source block keys Done ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-ieee802-11 grc files missing
I have a patch applied that rename message ports. Maybe the connections are therefore broken. Can you have a quick look if the gray ports are connected. It should be easy to spot where the connections should be (mac_out - phy_in and so on). They were not connected; I connected them and it compiled. There are message block connections missing in ofdm_loopback.grc as well, but it's not as clear how they should be connected. Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-ieee802-11 grc files missing
like this: http://www.ccs-labs.org/~bloessl/grc.png strobe - app_in phy_out - mac_in mac_out - phy_in mac_out - in (of parser) Thanks! It works. Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On
Behalf Of Nowlan, Sean
Sent: Monday, November 11, 2013 4:10 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception
I'm using ControlPort to monitor transmissions through a USRP. I have a
flowgraph responsible for generating burst traffic and streaming to a
uhd_sink. Then I have a uhd_source tuned to the same frequency as the
uhd_sink, and I connect it to a ctrlport_probe2_c block with length=128. I
have ControlPort support compiled-in and enabled from a config file. I'm able
to connect to a remotely running flowgraph using gr-ctrlport-monitor and plot
the PSD of the samples vector pulled from the probe2 block every 100
milliseconds. The problem is that after (what seems to be) a nondeterministic
time, the ICE port stops responding and gr-ctrlport-monitor reports an error:
ctrlport-monitor: radio.get threw exception (exception
::Ice::ConnectTimeoutException
{
}).
When I close and restart, gr-ctrlport-monitor times out and segfaults:
2013-11-11 16:02:47.329422 /usr/local/bin/gr-ctrlport-monitor: error:
Traceback (most recent call last):
File /usr/lib/pymodules/python2.7/Ice.py, line 984, in main
status = self.doMain(args, initData)
File /usr/lib/pymodules/python2.7/Ice.py, line 1031, in doMain
return self.run(args)
File
/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
line 97, in run
radio = self.getRadio(host, port)
File
/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
line 36, in getRadio
radio = GNURadio.ControlPortPrx.checkedCast(base)
File /usr/local/lib/python2.7/dist-packages/gnuradio_ice.py, line 1257, in
checkedCast
return _M_gnuradio.ctrlport.GNURadio.ControlPortPrx.ice_checkedCast(proxy,
'::GNURadio::ControlPort', facetOrCtx, _ctx)
ConnectTimeoutException: exception ::Ice::ConnectTimeoutException
{
}
Segmentation fault (core dumped)
So there are two issues to note here:
-Something in the ICE instance is breaking on the GNU Radio flowgraph
side. The port is still open; it just times out. Trying to instantiate
gr-ctrlport-monitor to an incorrect port just says connection refused, as
expected.
-gr-ctrlport-monitor is not robust to connection-related errors like
timeouts or refused connections.
Is there any advice of what I can turn on or enable in GNU Radio or my
flowgraph to debug the first problem? I can live with the second problem as
long as I can make sure ICE doesn't break on me.
Thanks,
Sean
Sorry for getting antsy about this, but I'm really not sure how to go about
debugging ICE server stuff. It seems like it's buried pretty deeply in
gnuradio-runtime. Where's the best place to start looking to find out why the
ICE server stops responding?
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-ctrlport-monitor timeout exception
I'm using ControlPort to monitor transmissions through a USRP. I have a
flowgraph responsible for generating burst traffic and streaming to a uhd_sink.
Then I have a uhd_source tuned to the same frequency as the uhd_sink, and I
connect it to a ctrlport_probe2_c block with length=128. I have ControlPort
support compiled-in and enabled from a config file. I'm able to connect to a
remotely running flowgraph using gr-ctrlport-monitor and plot the PSD of the
samples vector pulled from the probe2 block every 100 milliseconds. The
problem is that after (what seems to be) a nondeterministic time, the ICE port
stops responding and gr-ctrlport-monitor reports an error:
ctrlport-monitor: radio.get threw exception (exception
::Ice::ConnectTimeoutException
{
}).
When I close and restart, gr-ctrlport-monitor times out and segfaults:
2013-11-11 16:02:47.329422 /usr/local/bin/gr-ctrlport-monitor: error: Traceback
(most recent call last):
File /usr/lib/pymodules/python2.7/Ice.py, line 984, in main
status = self.doMain(args, initData)
File /usr/lib/pymodules/python2.7/Ice.py, line 1031, in doMain
return self.run(args)
File
/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
line 97, in run
radio = self.getRadio(host, port)
File
/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
line 36, in getRadio
radio = GNURadio.ControlPortPrx.checkedCast(base)
File /usr/local/lib/python2.7/dist-packages/gnuradio_ice.py, line 1257, in
checkedCast
return _M_gnuradio.ctrlport.GNURadio.ControlPortPrx.ice_checkedCast(proxy,
'::GNURadio::ControlPort', facetOrCtx, _ctx)
ConnectTimeoutException: exception ::Ice::ConnectTimeoutException
{
}
Segmentation fault (core dumped)
So there are two issues to note here:
- Something in the ICE instance is breaking on the GNU Radio flowgraph
side. The port is still open; it just times out. Trying to instantiate
gr-ctrlport-monitor to an incorrect port just says connection refused, as
expected.
- gr-ctrlport-monitor is not robust to connection-related errors like
timeouts or refused connections.
Is there any advice of what I can turn on or enable in GNU Radio or my
flowgraph to debug the first problem? I can live with the second problem as
long as I can make sure ICE doesn't break on me.
Thanks,
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] stream tag samples
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Jenny Galasso Sent: Friday, October 25, 2013 3:06 PM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] stream tag samples Today at 1:02 PM Hi, I'm using stream tags to time tag my data. In particular, I'm reading in one-second files and tagging the first sample read in with the time. I'm concerned with how the tag will be handled during decimation, filtering etc. I have read the documentation and understand that the tag is reassigned based on the relative_rate. For this particular data set though, it is important that the tags stay with the specific samples to which they were assigned, even if some of the tags are lost during decimation, filtering, etc. Is this even possible? Are there any recommendations or tricks to get it to behave this way? Thanks! Jenny Hi Jenny, If you decimate by N, you're getting rid of N-1 out of every N samples. So naturally you would want the tag to stick with the sample that doesn't get thrown out. Similarly, if you interpolate by M, you introduce M-1 samples into the stream for every input sample; you'd naturally want the tag associated with input sample /i/ to be placed on the first sample of the corresponding batch of M output samples. The propagate_tags method in gnuradio/gnuradio-runtime/lib/block_executor.cc handles this by default. You can override this behavior in your own blocks by calling set_tag_propagation_policy(TPP_DONT) in your block's constructor and then handling tags yourself in your work method. Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] stream tag samples
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Nowlan, Sean Sent: Friday, October 25, 2013 3:23 PM To: Jenny Galasso; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] stream tag samples From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.orgmailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Jenny Galasso Sent: Friday, October 25, 2013 3:06 PM To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] stream tag samples Today at 1:02 PM Hi, I'm using stream tags to time tag my data. In particular, I'm reading in one-second files and tagging the first sample read in with the time. I'm concerned with how the tag will be handled during decimation, filtering etc. I have read the documentation and understand that the tag is reassigned based on the relative_rate. For this particular data set though, it is important that the tags stay with the specific samples to which they were assigned, even if some of the tags are lost during decimation, filtering, etc. Is this even possible? Are there any recommendations or tricks to get it to behave this way? Thanks! Jenny Hi Jenny, If you decimate by N, you're getting rid of N-1 out of every N samples. So naturally you would want the tag to stick with the sample that doesn't get thrown out. Similarly, if you interpolate by M, you introduce M-1 samples into the stream for every input sample; you'd naturally want the tag associated with input sample /i/ to be placed on the first sample of the corresponding batch of M output samples. The propagate_tags method in gnuradio/gnuradio-runtime/lib/block_executor.cc handles this by default. You can override this behavior in your own blocks by calling set_tag_propagation_policy(TPP_DONT) in your block's constructor and then handling tags yourself in your work method. Sean I don't think there's a way to tell GNU Radio blocks derived from sync_decimator and sync_interpolator to quit propagating tags as described above (unless you write blocks that inherit from these classes yourself). It's the only way that really makes sense when changing rate domains by a rational factor. Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Specify which methods show up in SWIG version of C++ block
Declare a pure virtual function in (for example) gr-OOT/include/OOT/myblock.h :
virtual int how_many_things(const int n) const = 0;
Then declare a concrete function in gr-OOT/lib/myblock_impl.h :
int how_many_things(const int n) const;
Then define your concrete function in gr-OOT/lib/myblock_impl.cc :
int how_many_things(const int n)
{
return n;
}
If you added your block with gr_modtool, you'll find this in
gr-OOT/swig/OOT_swig.i :
%{
...
#include OOT/myblock.h
...
%}
...
%include OOT/myblock.h
...
GR_SWIG_BLOCK_MAGIC2(OOT, myblock);
The above statements will automagically SWIG anything defined in myblock.h.
-Original Message-
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Ethan Trewhitt
Sent: Wednesday, October 09, 2013 4:36 PM
To: GnuRadio Discussion List
Subject: [Discuss-gnuradio] Specify which methods show up in SWIG version of
C++ block
I'm working on some custom C++ blocks. I would like to have a few methods in
the C++ world visible to Python so that they can be called directly. My
understanding is that GRC can then make such things visible through the
callback tag in the block's XML specification.
Looking at the GR3.7 version of fir_filter, for instance, shows that it has a
set_taps method and an update_tap method, both of which are public.
However, only set_taps gets translated into the SWIG Python version of the
fir_filter block, while update_tap does not.
What part of the gr-filter source tree instructs SWIG to include one but not
the other? Does it have something to do with the way the
GR_SWIG_BLOCK_MAGIC2() macro works within filter_swig.i?
Short version: how do I instruct the SWIG build process to translate a
particular method of a C++ GR block into its Python version?
Thanks in advance.
Ethan
___
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] PFB Arbitrary Resampler
In the benchmark_tx.py code for MPSK modulation, the pfb_arbitrary_resampler block is instantiated with 32 * 11 * floor(samples_per_symbol) taps. I understand that 32 is the number of filters in the filterbank, but I'm not sure what motivates the factor of 11. Has anybody been able to fine tune these numbers to improve performance of the resampling filter, e.g., reducing the number of taps? Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flowgraph with async messaging hangs on calling wait()
Any block can return DONE to indicate the scheduler that it finished its processing. Then the scheduler tells downstream blocks that they are DONE too. However, it's possible that you want downstream blocks to finish operating on samples that are in flight after the upstream block is marked DONE, rather than terminating everything before those buffers have been flushed/processed. Wouldn't it make sense to have the scheduler let these buffers flush before notifying those blocks that they are DONE? (Or does the scheduler already do something like this, and I've just not noticed?) From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] on behalf of Tom Rondeau [t...@trondeau.com] Sent: Thursday, September 12, 2013 9:45 AM To: Mark Cottrell Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] flowgraph with async messaging hangs on calling wait() On Wed, Sep 11, 2013 at 5:08 PM, Mark Cottrell mark.cottr...@taitradio.com wrote: Hi Tom, I spent a while playing around with this, including adding a bunch of debug output to tpb_thread_body::tpb_thread_body, and found that when a block is done, the DONE state should propagate through the flow graph as tpb_detail::notify_neighbours is called (as I'm sure you're aware). The problem is, tpb_detail::notify_neighbours only notifies blocks that that have input or output buffers (which as far as I can tell, blocks with only message inputs or outputs don't), so blocks like message_debug will block on tpb_detail::input_cond forever (on line 110 of tpb_thread_body.cc) and can never be notified (as it has no input buffers, so notify downstream does nothing). Johnathan contacted me r.e. this and I sent him a patch which fixed the problem for me (attached to this message), but I don't think he has had time to look at it yet. The gist of it is that it uses pmt::PMT_EOF to indicate that message blocks should transition to done and notify neighbours. Please feel free to correct me on any of what I said above, this was my first foray into the scheduler so I could have it completely wrong. Thanks, Mark Yeah, ok, I see the problem. I think I remember now someone else talking about this potential issue. I'll discuss your patch with Johnathan sometime soon. I see where you're going with it, but I'm hoping that there's a solution that's a bit simpler (or just fewer changes). Thanks, -- Tom Visit us at GRCon13 Oct. 1 - 4 http://www.trondeau.com/grcon13 On Thu, Sep 12, 2013 at 3:56 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Aug 22, 2013 at 10:44 PM, Mark Cottrell mark.cottr...@taitradio.com wrote: Hello all, I have written a sync block that takes in samples and outputs messages (similar to tagged_stream_to_pdu), but when writing a test for the block I found that when I called top_block.run(), the test never finished, as it appears to be hanging on the call to top_block.wait(). The flow graph for the test is as follows: non-repeating file source - my block - message_debug is hanging the expected behaviour? I can work around it by counting the number of items written by the file source, but it would be nice to have it terminate of its own accord. Thanks, Mark Mark, No, that's not expected behavior. When the file sink finishes, it should set the DONE stage in the scheduler that should indicated to every down stream block that they are also done. Make sure that there isn't something happening where your block isn't getting stuck in 'work' at this point. -- Tom Visit us at GRCon13 Oct. 1 - 4 http://www.trondeau.com/grcon13 ___ 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] Empty work functions
The implementation of the uhd_control_port block in gnuradio-extras has an empty work function because it doesn't actually process any samples. I believe gnuradio-extras uses the gnuradio advanced scheduler (GRAS), so apparently GRAS doesn't mind blocks that don't have any connections in a flowgraph or do any work. Does the standard gnuradio scheduler also support this? I just want to know for reference if the gnuradio scheduler will keep or ignore a block with no connections, or empty io_signatures, or no code body in the work function. What I want to do is change power using timed commands independent of the data path in the flowgraphs. I can do this one of two ways: 1) Make a block with a message queue and some logic to handle timing (to play nice with the timed commands implementation, which has a limited FIFO size and only a 10 second timeout window). 2) Launch a separate thread in Python that does the same thing as 1) but isn't a block. I assume this will be a lot easier. --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Public transport in Boston
Sorry for the bad info; I wasn't aware of the Blue Line T going to the airport. In the past I've taken the Silver Line (bus rapid transit) to South Station and transferred to the Red Line. --sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] on behalf of Michael Dickens [m...@alum.mit.edu] Sent: Saturday, August 10, 2013 12:07 PM To: Bruce Penswick Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Public transport in Boston Cool; I've been out of Boston for ~8 years now, so the Silver Line is new to me. Thanks! It looks from the map http://www.mbta.com/uploadedFiles/Documents/Schedules_and_Maps/Bus/silverwatermap.pdf that the Silver Line's SL1 and SL2 go by the World Trade Center, with a stop at the Courthouse which is on Seaport Boulevard; so not on Summer St where the GRCon building is, but close by. One could get off at Courthouse and walk South on (looks like) Thompson Place to get to the GRCon building. It would probably be faster to just get off at South Station and walk across the Summer St Bridge though. It also looks like MBTA Buses 4 and 7 go right by the GRCon meeting place; Bus 11 goes very close. So, lots of public transport options. Getting out of the Airport is also easier because the Silver Line goes directly to terminals (or, that's the way it looks from the maps @ http://www.mbta.com/schedules_and_maps/subway/ ; can anyone confirm?). - MLD On Aug 10, 2013, at 10:32 AM, Bruce Penswick brucepensw...@yahoo.com wrote: actually now there is a new Silver Line, which takes you from South Station, past where GRcon is being held, to Logan Airport. https://en.wikipedia.org/wiki/Silver_Line_%28MBTA%29 http://www.mbta.com/schedules_and_maps/subway/lines/?route=SILVER http://www.mbta.com/schedules_and_maps/subway/lines/?route=BLUE ___ 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] Spectrogram plot on ControlPort
That should definitely be a good start. You're going to probably want to have a rolling buffer that you fill up with the latest samples and age off the oldest ones once its full. Otherwise, you'll just get one or two lines of the spectrogram plotted. I used the waterfall_sink_c class. Doesn't that already buffer everything it needs to display the plot? Are you talking about additional buffering before the waterfall sink? It looks to be working already. --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Spectrogram plot on ControlPort
On Thu, Aug 1, 2013 at 4:02 PM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: Does anybody know how to get gr-ctrlport-monitor to do spectrogram plots? I set up a ctrlport_probe2_c block with the DISPSPEC DisplayType but all I see are Time, PSD, and Constellation plot options in gr-ctrlport-monitor. I hadn't actually enabled the spectrogram plots through our ControlPort monitor app. It's due to the way the data is handled that makes it a slight pain to set up. It's not impossible, but I just hadn't spent the time to do it. You can look in gnuradio-runtime/python/gnuradio/ctrlport/GrDataPlotter.py and see what you can do about adding it in. I just copied the PSD functions and changed Psd to Spectrogram and added waterfall sinks to get it working. However I had to remove a call to enable_autoscale(bool) since that function isn't a member of the waterfall_sink_* classes. Does this sound like the right approach or do I have to do something special to the data first? --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Public transport in Boston
I found a Holiday Inn Express along the Red line of the T, maybe 20 mins south, for ~215 a night. Haven't placed the order though. Just took a look at avg rates on their website. -Original Message- From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Philip Balister Sent: Monday, August 05, 2013 11:12 AM To: GNURadio Discussion List Subject: [Discuss-gnuradio] Public transport in Boston I am looking at hotels in Boston GR Con. Needless to say, I will never complain about Si valley rates again. Does anyone have any comments about public transport in Boston? Especially about getting from cheaper hotels to the conference location. Thanks, Philip ___ 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] Public transport in Boston
Also, the train doesn’t go to the airport, but there are frequent bus transfers to nearby train stations. I suggest Google Maps or the MBTA website itself. The latter provides a Route Planning tool an lets you choose between Google Maps or their own interface. http://www.mbta.com/ --sean From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Nick Foster Sent: Monday, August 05, 2013 11:40 AM To: Philip Balister Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Public transport in Boston Boston's T is a pretty good, reasonably reliable public transit system, and the city is compact enough that it's generally pretty easy to get around. The conference is very close to South Station, which is the largest transport hub in Boston. South Station is on the Red Line of the MBTA subway and is easy to get to from any other T stop with a maximum of 1 transfer. If you were incredibly, world-class cheap, you could even stay way out in the suburbs and take the commuter rail into South Station for the conference. Personally, if I wanted to save money, I'd look out toward Quincy Adams on the south end of the Red Line for a cheaper place to stay, and take the Red Line into South Station. Here's a map showing the subway and commuter rail lines: http://www.mbta.com/schedules_and_maps/rail/ --n On Mon, Aug 5, 2013 at 8:12 AM, Philip Balister phi...@balister.orgmailto:phi...@balister.org wrote: I am looking at hotels in Boston GR Con. Needless to say, I will never complain about Si valley rates again. Does anyone have any comments about public transport in Boston? Especially about getting from cheaper hotels to the conference location. Thanks, Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orgmailto: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] Spectrogram plot on ControlPort
Does anybody know how to get gr-ctrlport-monitor to do spectrogram plots? I set up a ctrlport_probe2_c block with the DISPSPEC DisplayType but all I see are Time, PSD, and Constellation plot options in gr-ctrlport-monitor. Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT GUI FFT and Waterfall plots not working for me on 3.7
The plots are working now. I was on Qt 4.8.1 and Qwt 5.2.2, the defaults installed by the build-gnuradio script. I removed Qwt 5.2.2 (packages: libqwt5-qt4 libqwt5-qt4-dev) and installed Qwt 6.0.0 (packages: libqwt libqwt-dev). Perhaps it's worth changing these in the Ubuntu 13.* section of build-gnuradio. --sean From: trond...@trondeau.com [trond...@trondeau.com] on behalf of Tom Rondeau [t...@trondeau.com] Sent: Tuesday, July 30, 2013 9:36 AM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] QT GUI FFT and Waterfall plots not working for me on 3.7 On Mon, Jul 29, 2013 at 4:39 PM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: Hi all, For whatever reason QT FFT and Waterfall plots are not displaying for me. All the controls are present and I can change scale, FFT size, color intensity (for waterfall), etc. but the display area is just a white brick. Time domain display seems to work just fine. I see this behavior both with gr-qtgui/apps/uhd_display.py and with a simple GRC flowgraph with UHD - QT sink. System info: Ubuntu 13.04 x86_64 GNU Radio v3.7.0-82-g179a2d78 UHD v3.5.3-20-gbcdf7c3 Compiler: g++-4.6 --sean What version of Qt and QWT do you have? I've noticed display problems on the time raster plots for Qwt less than version 6. So if you can install and use Qwt 6 (which should be pretty easy on Ubuntu 13.04), give that a shot. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT GUI FFT and Waterfall plots not working for me on 3.7
The plots are working now. I was on Qt 4.8.1 and Qwt 5.2.2, the defaults installed by the build-gnuradio script. I removed Qwt 5.2.2 (packages: libqwt5-qt4 libqwt5-qt4-dev) and installed Qwt 6.0.0 (packages: libqwt libqwt-dev). Perhaps it's worth changing these in the Ubuntu 13.* section of build-gnuradio. Sorry, I meant to say Ubuntu 13.04 uses Qt 4.8.4. --sean From: trond...@trondeau.com [trond...@trondeau.com] on behalf of Tom Rondeau [t...@trondeau.com] Sent: Tuesday, July 30, 2013 9:36 AM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] QT GUI FFT and Waterfall plots not working for me on 3.7 On Mon, Jul 29, 2013 at 4:39 PM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: Hi all, For whatever reason QT FFT and Waterfall plots are not displaying for me. All the controls are present and I can change scale, FFT size, color intensity (for waterfall), etc. but the display area is just a white brick. Time domain display seems to work just fine. I see this behavior both with gr-qtgui/apps/uhd_display.py and with a simple GRC flowgraph with UHD - QT sink. System info: Ubuntu 13.04 x86_64 GNU Radio v3.7.0-82-g179a2d78 UHD v3.5.3-20-gbcdf7c3 Compiler: g++-4.6 --sean What version of Qt and QWT do you have? I've noticed display problems on the time raster plots for Qwt less than version 6. So if you can install and use Qwt 6 (which should be pretty easy on Ubuntu 13.04), give that a shot. 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
Re: [Discuss-gnuradio] Suggestion: Avoid using https in Pybombs recipes
If you sudo make install a compiled binary from spoofed git repository, your botnet masters will thank you! From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] on behalf of Michael Ossmann [m...@ossmann.com] Sent: Tuesday, July 30, 2013 11:52 AM To: M Dammer Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Suggestion: Avoid using https in Pybombs recipes On Tue, Jul 30, 2013 at 11:57:09AM +0100, M Dammer wrote: This may lower security, but as the software we are working with is opensource anyway I do not see the need for encryption. There have been attacks against users of open source software via automated software update and installation methods. My two cents: fix certificate validation instead of dropping https. ___ 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 FFT and Waterfall plots not working for me on 3.7
libqwt5-qt4 libqwt5-qt4-dev If someone can suggest (and test) what the new PACKAGES line should look like to make this happen, I can integrate it. The following built correctly for me using ./build-gnuradio -j2 -v all. The GUI components worked. They also worked for ./build-gnuradio -j2 -v -m all (gnuradio 3.7 master). $ diff -u build-gnuradio-old build-gnuradio --- build-gnuradio-old 2013-07-30 15:52:11.579918663 -0400 +++ build-gnuradio 2013-07-30 15:52:24.919918353 -0400 @@ -491,7 +491,7 @@ libsdl1.2-dev python-wxgtk2.8 git-core libqt4-dev python-numpy ccache python-opengl libgsl0-dev python-cheetah python-lxml doxygen qt4-default qt4-dev-tools libusb-1.0-0-dev - libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-qt4 + libqwt-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-qt4 cmake git-core wget libxi-dev python-docutils gtk2-engines-pixbuf r-base-dev python-tk liborc-0.4-0 liborc-0.4-dev libasound2-dev python-gtk2 CMAKE_FLAG1=-DPythonLibs_FIND_VERSION:STRING=2.7 What does the pyBombs recipe do? I haven't tried this out yet; hopefully somebody who has can chime in. --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] QT GUI FFT and Waterfall plots not working for me on 3.7
Hi all, For whatever reason QT FFT and Waterfall plots are not displaying for me. All the controls are present and I can change scale, FFT size, color intensity (for waterfall), etc. but the display area is just a white brick. Time domain display seems to work just fine. I see this behavior both with gr-qtgui/apps/uhd_display.py and with a simple GRC flowgraph with UHD - QT sink. System info: Ubuntu 13.04 x86_64 GNU Radio v3.7.0-82-g179a2d78 UHD v3.5.3-20-gbcdf7c3 Compiler: g++-4.6 --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble posting messages to block's message port
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] on behalf of Martin Lülf [m...@mluelf.de] Sent: Friday, May 03, 2013 7:59 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Trouble posting messages to block's message port I had this issue once and if I remember correctly, connecting the block to the flowgraph (i.e. connect any block to your message port, even if that port will never send messages) will make your message handler react to messages from your python code. Hope this helps Martin --- Thanks! I'll give that a shot. --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: USRP1 control GPIOs on SBX boards
Unfortunately I wasn't able to determine the problem after a quick glance. I
recommend that you use gr_modtool to create an out-of-tree module and then add
a block to it. This will set up most of what you need. Then you can splice in
your code/algorithms and not have to worry as much about the boilerplate stuff.
However, you will have to add some stuff to the CMakeList.txt files to pull in
UHD support. I don't know off the top of my head how to pull in UHD directly,
but if you pull in the gr-uhd package, that should do it for you. See
gnuradio/cmake/Modules/FindGnuradio.cmake on the next branch for some guidance
on how to do that.
--sean
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] on behalf of
Nelson Pina [n.p...@tomorrow-options.com]
Sent: Thursday, April 25, 2013 5:36 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Fwd: USRP1 control GPIOs on SBX boards
Hi Sean,
thanks for your feedback.. I'm still trying to get this working but the problem
persists. Every time I use the uhd::device_addr_t addr class necessary to
initialize an uhd::usrp::multi_usrp::make object, the GRC program fails.
Do I need to do something in the swig.i or the Python files to use
uhd::device_addr_t addr class? I will send you my .cc and .h files, y«if you
can take a look on those I will be very thankful.
Thanks again.
Best regards,
Nelson Pina
Product Developer
Hardware
[X]
n.p...@tomorrow-options.commailto:n.p...@tomorrow-options.com
T +351 220 301 596 (PT)
T +44 114 213 2712 (UK)
www.tomorrow-options.comhttp://www.tomorrow-options.com/
Porto // Portugal
Sheffield // United Kingdom
[X]http://www.tomorrow-options.com/ [X]
http://www.linkedin.com/company/tomorrow-options[X]
http://www.facebook.com/pages/Porto-Portugal/Tomorrow-Options/214846405104
[X] http://twitter.com/TomorrowOptions[X]
http://www.youtube.com/user/TomorrowOptionsTube
[X]
On Tue, Apr 23, 2013 at 8:31 PM, Sean Nowlan
sean.now...@gtri.gatech.edumailto:sean.now...@gtri.gatech.edu wrote:
On 04/23/2013 02:06 PM, Nelson Pina wrote:
Hi everyone,
I have been trying to make a gnuradio out-of-the-tree block that is able to
control the four GPIOs, currently attached to LED's, of the SBX daughter-boards
working with an USRP motherboard.
I wonder if anyone can help me on this, making a functional draft code of such
a block:
1 integer input - that will define the state of the GPIOs
1 parameter - to define the motherboard serial number
I believe that for people with knowledge of C++, and Python this is a very
simple module, unfortunately that is not my area since I'm a hardware engineer
and I only work with C.
I tried some approaches, using the gr_modtool to create the module, but it
always fails with GRC running errors like:
**
Traceback (most recent call last):
File /home/to-nelsonpina/Desktop/locus_gnuradio/GRC_files/top_block.py,
line 16, in module
import gpio
File /usr/local/lib/python2.7/dist-packages/gpio/__init__.py, line 45, in
module
from gpio_swig import *
File /usr/local/lib/python2.7/dist-packages/gpio/gpio_swig.py, line 26, in
module
_gpio_swig = swig_import_helper()
File /usr/local/lib/python2.7/dist-packages/gpio/gpio_swig.py, line 22, in
swig_import_helper
_mod = imp.load_module('_gpio_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-gpio.so: undefined symbol:
_ZN3uhd4usrp10multi_usrp4makeERKNS_13device_addr_tE
*
This is most likely a failure to define the SWIG header file appropriately, or
possibly you've _declared_ a class that SWIG found but you haven't _defined_
it. Finally because I just found this out the hard way, if you're using the new
code structure with block.h, block_impl.h, and block_impl.cc, be aware that
block.h needs to declare an abstract class and its method declarations need to
be pure virtual. block_impl.h declares the concrete class and block_impl.cc
provides concrete method definitions.
If you want to unmangle that symbol, type this:
c++filt _ZN3uhd4usrp10multi_usrp4makeERKNS_13device_addr_tE
I will appreciate all the help I can get from you guys.
Best regards,
__
Nelson Pina
Product Developer
Hardware
[X]
n.p...@tomorrow-options.commailto:n.p...@tomorrow-options.com
T +351 220 301 596 (PT)
T +44 114 213 2712 (UK)
www.tomorrow-options.comhttp://www.tomorrow-options.com/
Porto // Portugal
Sheffield // United Kingdom
[X]http://www.tomorrow-options.com/ [X]
http://www.linkedin.com/company/tomorrow-options[X]
http://www.facebook.com/pages/Porto-Portugal/Tomorrow-Options/214846405104
[X] http://twitter.com/TomorrowOptions[X]
http://www.youtube.com/user/TomorrowOptionsTube
[X]
___
Discuss-gnuradio mailing list
