Hi Arik:
On Sat, Apr 2, 2016 at 7:41 PM, Landsman, Arik <arik.lands...@tufts.edu>
wrote:
> Hi Andy,
>
> Still looking it over, but one thing jumps out right away - for some
> reason I couldn't execute either Rx_syncd_2.grc or the Rx_syncd.py. getting
> the same error in both cases:
>
> ""
> Generating:
> '/home/ubuntu/Desktop/MSProject/alternateVersions/Rx_syncd_2.py'
>
> Executing: '/usr/bin/python2 -u
> /home/ubuntu/Desktop/MSProject/alternateVersions/Rx_syncd_2.py'
>
> Using Volk machine: sse4_1_64
> Thrift: Sat Apr 2 19:05:54 2016 TServerSocket::listen() BIND 9090
> terminate called after throwing an instance of
> 'apache::thrift::transport::TTransportException'
> what(): Could not bind: Transport endpoint is not connected
> ""
>
> does this look familiar by any chance?
>
It looks like a GNURadio ControlPort / Apache Thrift error.
I took your flowgraph and modified it slightly, only adding a few blocks:
-modulate_vector
-skip_head
-keep_1_in_n
-qt_time_sink
-feedforward_agc
-multiply const
-qt gui range
One of those might be doing it. Disable skip_head, keep_1_in_n, and the
constellation sink they connect to. Hopefully it's one of them.
Otherwise, you didn't drop a control port related block on the flowgraph
did you?
FWIW, I also modified the Polyphase clock sync filter taps, the Corr_Est
symbols, and changed a few 3.14's to math.pi.
>
> Also could you elaborate a bit on what you did with
>
> ""
> $ source <path_to_target>/setup_env.sh
> $ ./Rx_syncd.py | grep -v volk | sed -e 's/(//g' -e 's/)//g' >
> foo.txt
> $ octave
> octave:1> x = csvread('foo.txt');
> octave:2> t = [1:length(x)];
> octave:3> plot(t,abs(x))
> octave:4> plot(t,arg(x)/pi)
> ""
>
> at the very least where can I find setup_env.sh?.
If you build GNURadio with the PyBOMBS build system and install in a target
directory somewhere, PyBOMBS generates this environment file which is
essential to run GNURadio Companion and gnuradio scripts properly. If you
are using the GNURadio supplied by your distribution, then sourcing a
setup_env.sh file is not necessary.
> . wondering what <path_to_target> may be.
> I suppose you then pipe a portion of the stream in Rx_syncd.py into
> foo.txt to parse with octave?
>
Yes, I just have it emit the complex samples vector that the
modulate_vector block creates, and then inspect the samples in octave. You
can do it in MatLab or Python or Excel, or whatever.
> going to try it if I find setup_env.sh on my end. and once I can run
> Rx_syncd.py... )
>
> Thanks,
> Arik
>
And another, "Oh by the way" for when things are working. In the flowgraph
I sent, I mark the phase correction on the last symbol of the preamble -
where the phase correction was measured. This means, that the previous
symbols in the preamble, if they suffered a phase rotation, may not get
corrected by the costas loop. You can "fix" that by setting the corr_est
tag marking delay to 0, to mark the first symbol in the preamble with the
phase correction. This is OK as long as you are very close to the correct
center frequency. The measured phase rotation will become less correct the
farther you move from the measurement point at the peak of the correlation,
if you don't have good frequency lock when performing the correlation.
Regards,
Andy
>
>
>
> ________________________________________
> From: Andy Walls [a...@silverblocksystems.net]
> Sent: Friday, April 01, 2016 9:18 AM
> To: Landsman, Arik
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync
> block in qpsk
>
> Hi Arik,
>
> I have attached a slightly improved flowgraph and a hand edited .py
> file.
>
> The only modifications to the flowgraph from before, is that I set the
> reference samples for the corr_est block to start at the _middle_ of the
> first symbol of the preamble and stop at the _middle_ of the last symbol
> in the preamble; I also ensured the phase_est and time_est tags stayed
> marked at the center of the last symbol of the preamble. This has two
> benefits:
>
> 1. The phase_est value will not be thrown off by the end of symbol
> transition to a different unknown symbol after the preamble.
> 2. The correlation won't be sensitive to the unknown symbols before and
> after the preamble.
>
> In other words, it was a mistake to have the correlation reference
> sequence start and end at the symbol transition times. :P
>
> In the generated *.py script I added one line near the end:
>
> print tb.get_modulated_preamble_untrimmed()
>
> So you can so this:
>
> $ source <path_to_target>/setup_env.sh
> $ ./Rx_syncd.py | grep -v volk | sed -e 's/(//g' -e 's/)//g' >
> foo.txt
> $ octave
> octave:1> x = csvread('foo.txt');
> octave:2> t = [1:length(x)];
> octave:3> plot(t,abs(x))
> octave:4> plot(t,arg(x)/pi)
>
> and see why I picked the values I did to trim the modulated preamble to
> the correct set of samples.
>
> The modulator that generates the reference sequence has a pretty long
> delay, and the first copy of the preamble it outputs is a little
> distorted at the first symbol. That's why I snipped out the second copy
> of the preamble.
>
> Regards,
> Andy
>
>
> On Thu, 2016-03-31 at 22:04 -0400, Andy Walls wrote:
> > Hi Arik,
> >
> > Try the attached flowgraph. I didn't get to put everything back in, but
> > it demonstrates the principal.
> >
> > 1. Observe the corr_est block correlates to your preamble bytes.
> > 2. Slide the phase offset around:
> > a. observe the phase changing/wrapping in the time plot of the output of
> > the correlator
> > b. observe the phase_est tag value approximately matches the value of
> > the phase offset slider.
> > c. Observe the constellation rotate as you change the phase offset.
> > d. Observe your decoded bits stay the same.
> >
> > Regards,
> > Andy
> >
> >
> >
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
