Re: [Discuss-gnuradio] Strange output of "0" at the terminal

[Wu Ting]

The output is “O” (Oh) not “0” (zero).

 

I made more tests and feel the problem may be from use of write() to write
data into files. Anyone had similar problem?

 

Wu

 

From: discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org
[mailto:discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.or
g] On Behalf Of Wu Ting
Sent: 2012年2月22日 14:48
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Strange output of "0" at the terminal

 

Hi all,

 

I’m now using message_sink and msg_queue to receive data from USRP. I do
some calculation for all the data in the msg_queue one by one and write some
of them into a file. Everything seems to be working smoothly. But once in a
while, a “0” is printed in the terminal. (There is no code to print “0”
in my program.) I checked the data, and found that every time a “0” is
printed, some data are lost, and the length of lost data seems to be of
hundreds of messages.

 

There is no other error information, so I’m really confused by this
problem. Does anyone has a clue of what happened and how should I deal with
it? 

 

Thanks,

 

Wu

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

Re: [Discuss-gnuradio] UHD Source -and- Sink In Same GRC Flowgraph ?

[g7iii]

On Tue, Feb 21, 2012 at 05:46:51PM -0800, Josh Blum wrote:
> 
> On 02/21/2012 03:30 PM, Marcus D. Leech wrote:
> >
> > Yup, the precipitating characteristic appears to be that both TX and RX
> > facilities are in use on the same USRP1.
> > 
> > I was able to reproduce here with a trivial flow-graph.  Sent a report
> > off to Josh.
> > 
> 
> OK guys, thanks. I pushed a minor fix to master. The max samples per
> packet was mis-advertised and too many bytes were committed to the
> interface in some cases when the previous send() was a short one.

Thanks Josh, amazingly quick response! I just had 5 minutes to test this.
I can confirm that NO-GUI with dual chains now works. With WX-GUI, I still
get hit by the famous OpenGL bug, but that was to be expected.


Thanks again both!

Iain

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

[Discuss-gnuradio] UCLA ZigBee and the Capture Effect

[bjoernm]

Hi everyone,

First of all thanks a lot for any support!

I'm use the UCLA zigbee PHY (IEEE 802.15.4) on three nodes, of which  
one is a dedicated receiver and the other two nodes are transmitting  
simultaneously (No CSMA!).


I noticed that something like a capture effect is taking place,  
meaning that even though the signal is synchronized to a weaker signal  
(signal 1), the receiver appears to jump to the stronger signal  
(signal 2) as soon as it arrives at the receiver (if the second signal  
is significantly stronger then the first one).


I would like to influence this behavior, and hence am looking for the  
related parameters. I just can't find them! Does anyone have a clue  
where this is happening?


I am using the XCVR2450 Daughterboard together with the USRP1.

Any hints, suggestions or detailed help will be highly appreciated!

best regards and thanks a lot,

B



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

[Discuss-gnuradio] Happy Birthday Heinrich Rudolf

[Marcus D. Leech]

...and hooray for Hertzian waves!

-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

Re: [Discuss-gnuradio] Segmentation fault

[Jorge Hernandez]

Hi,

Actually what I'm trying to do is a 2x1 MIMO, but I was trying to run the
benchmark with its default set up to see if I had success with the merging.
As you said, this segmentation fault must appear somewhere when trying to
implement 2 receivers, when you adjust the parameters for 2 tx antennas and
1 rx antennas there is no problem to run it.

So, now I think I have this benchmark_ofm_mimo prepared to work I'm finding
another problems...I am using two USRP2 with XCVR2450 daughterboards in the
transmitter side and another one in the receiver side (less than 1 meter of
distance between tx and rx). My first problem comes when setting the sample
rate, I don't know if I should set the sample rate in the rx usrp as the
sum of the two sample rates of the tx usrps, or it has nothing to
do...Also, I've been reading the UHD/USRP2 application notes and I think
I've got how to configure the slave usrp but I am not sure. I enclose my
code so anyone who has any adviece can have a look at it. Appart from this
issues, my heaviest problem is how to introduce an input into the
transmission chain. I see how packets are made and sent in the
benchmark_ofmd_mimo, but how should I proceed if I want to use my own
source block (in my case it would be a wavfile source)? Thank you for your
support, I will appreciate any help!

2012/2/20 Tom Rondeau 

> On Mon, Feb 20, 2012 at 5:48 AM, Jorge Hernandez <
> jorge.gnura...@googlemail.com> wrote:
>
>> Hi all,
>>
>> I've been working lately to get to work the mimo files from trondeau's
>> branch. After some trials, I thought I've successfully merged the master
>> branch into this branch so I could use the mimo files. However,  when
>> trying to run the benchmark_mimo_ofdm.py file a segmentation fault is
>> happening. I've been reading about this error but I don't know yet where it
>> comes from. I've checked the "How do I debug GNU Radio in Python" from the
>> FAQ to see what to do in this case. I've followed the 2 steps suggested in
>> this point but I don't understand the results coming from the (gdb)
>> backtrace. If anyone has experience with this problem or knows how to
>> understand this message I would really appreciate any help. I enclose the
>> messages I'm getting.
>>
>> This is what it shows when trying to run benchmark_ofdm_mimo.py:
>>
>> ./benchmark_ofdm_mimo.py
>> linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839];
>> Boost_103900; UHD_003.004.000-122b947
>>
>> 27435
>> Press Enter to continue
>> Noise voltage:  4.472135955
>> Frequency offset:  0
>> Symbols per Packet:  16.0
>> Samples per Packet:  11520.0
>> >>> gr_fir_ccf: using 3DNow!
>> >>> gr_fir_ccc: using 3DNow!Ext
>> >>> gr_fir_fff: using 3DNow!
>> Transmitter using  1
>> Receiver using 2
>> x
>>
>> After following the steps suggested it shows:
>>
>> (gdb) backtrace
>> #0  gr_ofdm_alamouti_frame_acquisition::calculate_equalizer
>> (this=0x1137c40, channel=, symbol=> out>,
>> zeros_on_left=) at
>> gr_ofdm_alamouti_frame_acquisition.cc:210
>> #1  0x7f4b40673f67 in
>> gr_ofdm_alamouti_frame_acquisition::general_work (this=0x1137c40,
>> noutput_items=,
>> ninput_items=, input_items=std::vector of length
>> 3, capacity 3 = {...}, output_items=)
>> at gr_ofdm_alamouti_frame_acquisition.cc:245
>> #2  0x7f4b40702c65 in gr_block_executor::run_one_iteration
>> (this=0x7f4b187d7f20) at gr_block_executor.cc:378
>> #3  0x7f4b407235c2 in gr_tpb_thread_body::gr_tpb_thread_body
>> (this=, block=...) at gr_tpb_thread_body.cc:49
>> #4  0x7f4b4071c20c in
>> boost::detail::function::void_function_obj_invoker0,
>> void>::invoke(boost::detail::function::function_buffer&) () from
>> /usr/local/lib64/libgnuradio-core-3.4.2git.so.0
>> #5  0x7f4b4010cd64 in boost::function0::operator() (this=> optimized out>) at /usr/include/boost/function/function_template.hpp:989
>> #6  0x7f4b3fce1010 in thread_proxy () from
>> /usr/lib64/libboost_thread.so.1.39.0
>> #7  0x7f4b415d665d in start_thread () from /lib64/libpthread.so.0
>> #8  0x7f4b40ce9ecd in clone () from /lib64/libc.so.6
>> #9  0x in ?? ()
>>
>> Thanks in advance,
>>
>> Jorge
>>
>
> Hi Jorge,
> So what that backtrace is telling you is on the #0 line that the seg fault
> is occurring here:
> gr_ofdm_alamouti_frame_acquisition.cc:210
>
> So it's that file, line 210.
>
> All that does is narrow your search down for where it's going wrong, but
> this one isn't going to tell you what's wrong with it.
>
> So you're doing a 1x2 code. I know when Matt and I left off with this
> branch, there were some definite issues, and this might just be one of
> them. Have you tried to do a 2x1 MIMO? I'm pretty sure we had that working.
> I can't really remember...
>
> I'm afraid I can't help you more right now, yo're going to have to look
> into that file and try to figure out why it's segfaulting one you. But,
> thanks for reading over the FAQ and posting the back trace! And you figured
> out how to merge those two branches, so it

Re: [Discuss-gnuradio] Segmentation fault

[Jorge Hernandez]

I had forgotten to enclose the code, here it goes!

   # USRP2 sinks

#

# slave USRP2
self.usrp2_sink_slave = uhd.single_usrp_sink(
device_addr="addr=192.168.20.3",
io_type=uhd.io_type_t.COMPLEX_FLOAT32,
num_channels=1,
)
_config = uhd.clock_config()
_config.ref_source = uhd.clock_config.REF_MIMO
_config.pps_source = uhd.clock_config.PPS_MIMO
self.usrp2_sink_slave.set_clock_config(_config, 0)
self.usrp2_sink_slave.set_samp_rate(self.output_samp_rate)
self.usrp2_sink_slave.set_center_freq(self.center_frequency, 0)
self.usrp2_sink_slave.set_gain(self.tx_gain, 0)
# master USRP2
self.usrp2_sink_master = uhd.single_usrp_sink(
device_addr="addr=192.168.10.4",
io_type=uhd.io_type_t.COMPLEX_FLOAT32,
num_channels=1,
)
self.usrp2_sink_master.set_samp_rate(self.output_samp_rate)
self.usrp2_sink_master.set_center_freq(self.center_frequency, 0)
self.usrp2_sink_master.set_gain(self.tx_gain, 0)

2012/2/22 Jorge Hernandez 

> Hi,
>
> Actually what I'm trying to do is a 2x1 MIMO, but I was trying to run the
> benchmark with its default set up to see if I had success with the merging.
> As you said, this segmentation fault must appear somewhere when trying to
> implement 2 receivers, when you adjust the parameters for 2 tx antennas and
> 1 rx antennas there is no problem to run it.
>
> So, now I think I have this benchmark_ofm_mimo prepared to work I'm
> finding another problems...I am using two USRP2 with XCVR2450daughterboards 
> in the transmitter side and another one in the receiver side
> (less than 1 meter of distance between tx and rx). My first problem comes
> when setting the sample rate, I don't know if I should set the sample rate
> in the rx usrp as the sum of the two sample rates of the tx usrps, or it
> has nothing to do...Also, I've been reading the UHD/USRP2 application notes
> and I think I've got how to configure the slave usrp but I am not sure. I
> enclose my code so anyone who has any adviece can have a look at it. Appart
> from this issues, my heaviest problem is how to introduce an input into the
> transmission chain. I see how packets are made and sent in the
> benchmark_ofmd_mimo, but how should I proceed if I want to use my own
> source block (in my case it would be a wavfile source)? Thank you for your
> support, I will appreciate any help!
>
>
> 2012/2/20 Tom Rondeau 
>
>> On Mon, Feb 20, 2012 at 5:48 AM, Jorge Hernandez <
>> jorge.gnura...@googlemail.com> wrote:
>>
>>> Hi all,
>>>
>>> I've been working lately to get to work the mimo files from trondeau's
>>> branch. After some trials, I thought I've successfully merged the master
>>> branch into this branch so I could use the mimo files. However,  when
>>> trying to run the benchmark_mimo_ofdm.py file a segmentation fault is
>>> happening. I've been reading about this error but I don't know yet where it
>>> comes from. I've checked the "How do I debug GNU Radio in Python" from the
>>> FAQ to see what to do in this case. I've followed the 2 steps suggested in
>>> this point but I don't understand the results coming from the (gdb)
>>> backtrace. If anyone has experience with this problem or knows how to
>>> understand this message I would really appreciate any help. I enclose the
>>> messages I'm getting.
>>>
>>> This is what it shows when trying to run benchmark_ofdm_mimo.py:
>>>
>>> ./benchmark_ofdm_mimo.py
>>> linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839];
>>> Boost_103900; UHD_003.004.000-122b947
>>>
>>> 27435
>>> Press Enter to continue
>>> Noise voltage:  4.472135955
>>> Frequency offset:  0
>>> Symbols per Packet:  16.0
>>> Samples per Packet:  11520.0
>>> >>> gr_fir_ccf: using 3DNow!
>>> >>> gr_fir_ccc: using 3DNow!Ext
>>> >>> gr_fir_fff: using 3DNow!
>>> Transmitter using  1
>>> Receiver using 2
>>> x
>>>
>>> After following the steps suggested it shows:
>>>
>>> (gdb) backtrace
>>> #0  gr_ofdm_alamouti_frame_acquisition::calculate_equalizer
>>> (this=0x1137c40, channel=, symbol=>> out>,
>>> zeros_on_left=) at
>>> gr_ofdm_alamouti_frame_acquisition.cc:210
>>> #1  0x7f4b40673f67 in
>>> gr_ofdm_alamouti_frame_acquisition::general_work (this=0x1137c40,
>>> noutput_items=,
>>> ninput_items=, input_items=std::vector of
>>> length 3, capacity 3 = {...}, output_items=)
>>> at gr_ofdm_alamouti_frame_acquisition.cc:245
>>> #2  0x7f4b40702c65 in gr_block_executor::run_one_iteration
>>> (this=0x7f4b187d7f20) at gr_block_executor.cc:378
>>> #3  0x7f4b407235c2 in gr_tpb_thread_body::gr_tpb_thread_body
>>> (this=, block=...) at gr_tpb_thread_body.cc:49
>>> #4  0x7f4b4071c20c in
>>> boost::detail::function::void_function_obj_invoker0,
>>> void>::invoke(boost::detail::function::function_buffer&) () fr

Re: [Discuss-gnuradio] Problem cross-compiling version 3.5.1

[Stefan Ott]

On Mon, Feb 20, 2012 at 23:18, Philip Balister  wrote:
> On 02/20/2012 02:54 PM, Philip Balister wrote:
>> On 02/20/2012 01:18 PM, Ben Hilburn wrote:
>>> Stefan -
>>>
>>> The command listed in that FAQ relies on the use of a CMake toolchain file,
>>> which is distributed with GNU Radio.
>>>
>>> A recent update (to CMake, possibly), seems to have broken use of the
>>> toolchain file -- all of the flags inside of it will get ignored.
>>>
>>> Instead of passing the -DCMAKE_TOOLCHAIN_FILE flag, I would recommend
>>> copying the flags out of the toolchain file, and put them on the CMake line
>>> manually.  Depending on what version of CMake you have, this might be
>>> unnecessary - but it is easy to workaround, and this way, you can be sure.
>>
>> OK, it looks like cmake requires clubbing with a blunt instrument when
>> trying to use FLAGS in a toolchain file.
>>
>> Can the people having issues try this fix and let me know if it works:
>>
>> https://github.com/balister/GNU-Radio/commit/895d2373c2adcc4a0ce949f320d9d92ee672178a
>
> Make that:
>
> https://github.com/balister/GNU-Radio/commit/ffb564cf0361ebbb51d3715ab3cd9672d38f655c

Thanks a lot for all the advice so far. I am currently engaged in
combat, trying to get cmake to cooperate with pkg-config and find my
libraries (never used cmake before). I will report back when I get
some results or reach another point where I need help.

cheers
-- 
Stefan Ott
Communication and Distributed Systems
Institute of Computer Science and Applied Mathematics
University of Bern

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

Re: [Discuss-gnuradio] Strange output of "0" at the terminal

[Andrew Davis]

"O" means there has been an overflow, some part of your system is not
fast enough to keep up with the incoming data, probably your hard
drive, or you may not have a fast enough CPU to process as the sample
rate you have chosen.

2012/2/22 Wu Ting :
> The output is “O” (Oh) not “0” (zero).
>
>
>
> I made more tests and feel the problem may be from use of write() to write
> data into files. Anyone had similar problem?
>
>
>
> Wu
>
>
>
> From: discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org
> [mailto:discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org]
> On Behalf Of Wu Ting
> Sent: 2012年2月22日 14:48
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] Strange output of "0" at the terminal
>
>
>
> Hi all,
>
>
>
> I’m now using message_sink and msg_queue to receive data from USRP. I do
> some calculation for all the data in the msg_queue one by one and write some
> of them into a file. Everything seems to be working smoothly. But once in a
> while, a “0” is printed in the terminal. (There is no code to print “0” in
> my program.) I checked the data, and found that every time a “0” is printed,
> some data are lost, and the length of lost data seems to be of hundreds of
> messages.
>
>
>
> There is no other error information, so I’m really confused by this problem.
> Does anyone has a clue of what happened and how should I deal with it?
>
>
>
> Thanks,
>
>
>
> Wu
>
>
> ___
> 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] Happy Birthday Heinrich Rudolf

[Andrew Davis]

Father of the radio, 155 years old, how far we've come and still using
the same antenna dipole design he made +100 years ago!

On Wed, Feb 22, 2012 at 7:33 AM, Marcus D. Leech  wrote:
> ...and hooray for Hertzian waves!
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ___
> 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] Happy Birthday Heinrich Rudolf

[mleech]

  

Him and Maxwell. Two righteous dudes for sure. 

On Wed, 22 Feb
2012 10:22:47 -0500, Andrew Davis wrote: 

> Father of the radio, 155
years old, how far we've come and still using
> the same antenna dipole
design he made +100 years ago!
> 
> On Wed, Feb 22, 2012 at 7:33 AM,
Marcus D. Leech wrote:
>> ...and hooray for Hertzian waves! -- Principal
Investigator Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org [1] ___
Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org [2]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]

 


Links:
--
[1] http://www.sbrac.org
[2]
mailto:Discuss-gnuradio@gnu.org
[3]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[4]
mailto:mle...@ripnet.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Happy Birthday Heinrich Rudolf

[mleech]

  

So, anyone done an FFT on the Google Doodle today to see if there's
an easter-egg inside it? :-) 

On Wed, 22 Feb 2012 10:22:47 -0500,
Andrew Davis wrote: 

> Father of the radio, 155 years old, how far
we've come and still using
> the same antenna dipole design he made +100
years ago!
> 
> On Wed, Feb 22, 2012 at 7:33 AM, Marcus D. Leech
wrote:
>> ...and hooray for Hertzian waves! -- Principal Investigator
Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org [1]
___ Discuss-gnuradio mailing
list Discuss-gnuradio@gnu.org [2]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]

 


Links:
--
[1] http://www.sbrac.org
[2]
mailto:Discuss-gnuradio@gnu.org
[3]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[4]
mailto:mle...@ripnet.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Happy Birthday Heinrich Rudolf

[Andrew Davis]

Even though it is cyclic the edge of the logo where it fades out makes
natural window function :)

On Wed, Feb 22, 2012 at 10:42 AM,   wrote:
> So, anyone done an FFT on the Google Doodle today to see if there's an
> easter-egg inside it?  :-)
>
>
>
> On Wed, 22 Feb 2012 10:22:47 -0500, Andrew Davis wrote:
>
> Father of the radio, 155 years old, how far we've come and still using
> the same antenna dipole design he made +100 years ago!
>
> On Wed, Feb 22, 2012 at 7:33 AM, Marcus D. Leech  wrote:
>
> ...and hooray for Hertzian waves!
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ___
> 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] Happy Birthday Heinrich Rudolf

[Jens Elsner]

On Wed, Feb 22, 2012 at 7:33 AM, Marcus D. Leech wrote:

...and hooray for Hertzian waves! -- Principal Investigator


For all those coming to Karlsruhe for our workshop [2], I'll gladly
throw a belated birthday party (read: offer you a can of cold beer)
at the birthplace of EM waves [1].

Jens

[1] 
http://en.wikipedia.org/wiki/File:B%C3%BCste_von_Heinrich_Hertz_in_Karlsruhe.jpg

[2] http://www-int.etec.uni-karlsruhe.de/seiten/conferences/wsr12/


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

Re: [Discuss-gnuradio] ATSC decoding - Now Working

[James Smith]

I've uploaded a sample of ATSC signal here:
http://dl.dropbox.com/u/63648777/atsc_data_6m4_short.bz2
The format is interleaved shorts at 6.4 MS like the current ATSC code uses. I 
successfully decoded this data with gnuradio, so the receiver code does work. 

Here's how I see the signal flow through the first part of the receiver:
input from usrp or file
(6.4MS complex short)
filter and translate
(19.2MS real float)
fpll
(19.2MS real float)
bit_timing_loop
(~10.76MS real float) [+ other data?]
field sync recovery

James

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

Re: [Discuss-gnuradio] Using PPS as a sampling trigger

[rmsrms1987]

Hi Josh, 

Thank you for the reply. 

I have been trying to implement what you mentioned using the
rx_timed_samples program but am having some trouble making sense of the
results.  Here are the changes I have made to the code in order to acquire
PPS timing information. 

usrp->set_clock_source("external");
usrp->set_time_source("_external_");

usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));

uhd::time_spec_t pps_time = usrp->get_time_last_pps();

These are the initial variables that are created outside of the "while"
loop.  Inside of the "while" loop I added:

if (pps_time != usrp->get_time_last_pps()){
pps_time = usrp->get_time_last_pps();
std::cout << boost::format("PPS Trigger: %u full secs, %f frac 
secs") 
% pps_time.get_full_secs() % pps_time.get_frac_secs() << 
std::endl;
}

Basically what this is supposed to do is print out the time value of the
last PPS trigger, once a new trigger value has been detected. 

The problem I am having right now is that the timing information is not
matching up to the signal I am inputting to the PPS port.  I started off
with inputting a signal that has an IPP of 1ms, but each PPS Trigger output
incremented in values of 5ms.  I made additional changes to the input signal
by making the IPP 5ms, then the increment of the printed PPS trigger was 10
ms.  Inside each IPP there are also some trigger variations, but these were
never detected.  Is there something I am not doing correctly in my code in
order to detect each PPS trigger? It seems like once a PPS is detected, the
program assumes each subsequent PPS will occur in equal time increments.
Please let me know what you think. 

Thank you very much, 
Rob

-- 
View this message in context: 
http://old.nabble.com/Using-PPS-as-a-sampling-trigger-tp33312321p33374458.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] Problem cross-compiling version 3.5.1

[Nowlan, Sean]

This fix appears to work for me compiling on the E100 itself.

-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, February 20, 2012 5:18 PM
To: Philip Balister
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Problem cross-compiling version 3.5.1

On 02/20/2012 02:54 PM, Philip Balister wrote:
> On 02/20/2012 01:18 PM, Ben Hilburn wrote:
>> Stefan -
>>
>> The command listed in that FAQ relies on the use of a CMake toolchain 
>> file, which is distributed with GNU Radio.
>>
>> A recent update (to CMake, possibly), seems to have broken use of the 
>> toolchain file -- all of the flags inside of it will get ignored.
>>
>> Instead of passing the -DCMAKE_TOOLCHAIN_FILE flag, I would recommend 
>> copying the flags out of the toolchain file, and put them on the 
>> CMake line manually.  Depending on what version of CMake you have, 
>> this might be unnecessary - but it is easy to workaround, and this way, you 
>> can be sure.
> 
> OK, it looks like cmake requires clubbing with a blunt instrument when 
> trying to use FLAGS in a toolchain file.
> 
> Can the people having issues try this fix and let me know if it works:
> 
> https://github.com/balister/GNU-Radio/commit/895d2373c2adcc4a0ce949f32
> 0d9d92ee672178a

Make that:

https://github.com/balister/GNU-Radio/commit/ffb564cf0361ebbb51d3715ab3cd9672d38f655c

Philip

> 
> It worked for me, but I did this against a repo on my desktop, so I 
> hope I avoided a typo :)
> 
> Philip
> 
>>
>> Cheers,
>> Ben
>>
>> On Mon, Feb 20, 2012 at 9:04 AM, Stefan Ott  wrote:
>>
>>> On Mon, Feb 20, 2012 at 17:55, Tom Rondeau  wrote:

 Try to use cmake instead of configure to build GNU Radio. Check out 
 the
>>> "How
 do I install GNU Radio from source?" section
 on: http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ.
>>>
>>> Ok, thank you, I'll try that.
>>>
>>> cheers
>>> --
>>> Stefan Ott
>>> Communication and Distributed Systems Institute of Computer Science 
>>> and Applied Mathematics University of Bern
>>>
>>> ___
>>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Using volk in Mac: test report

[Nowlan, Sean]

I confirmed this works on E100 insofar as I no longer get a segfault on 
volk_32fc_s32fc_multiple_32fc_a. But volk_32fc_s32f_magnitude_16i_a and 
volk_32fc_x2_multiply_32fc_a still fail as expected.

Sean

From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom 
Rondeau
Sent: Tuesday, February 21, 2012 6:49 PM
To: Nick Foster
Cc: Nowlan, Sean; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Using volk in Mac: test report

On Tue, Feb 21, 2012 at 6:43 PM, Nick Foster 
mailto:n...@ettus.com>> wrote:
Tom, Sean,

There's a couple of things here. First, the Orc volk_32fc_s32f_magnitude_16i_a 
function is rounding differently than the generic versions on E100 for some 
reason. Not fatal, totally usable, but it makes the QA code fail. Second, the 
volk_32fc_x2_multiply_32fc_a looks like it's working fine but the thresholds 
are too close in the comparison function, which is strange because it uses the 
same threshold I use everywhere else. I'll keep looking into that. In any case, 
they're fine for use in Volk as-is.

I think the segfault in volk_32fc_s32fc_multiply_32fc_a is being caused by a 
bug in the profiler code as well. It's not correctly handling complex scalars. 
The function itself doesn't actually work either, which doesn't help, but it 
wasn't caught because the profiler code was buggy...

Tom, I pushed a fix to my github under "volk_fix". For now I've disabled 
volk_32fc_s32fc_multiple_32fc_a since I can't figure out a clean way to get it 
to work under Orc; I had a misunderstanding of how float parameters are handled 
inside array operations. I also added complex scalar handling. I'll keep 
looking into solving this one for real but this will get things working for now.

--n

Nick,
Thanks a ton for working on this. I'll merge your branch asap.

Tom


On Sat, Feb 18, 2012 at 1:05 PM, Tom Rondeau 
mailto:t...@trondeau.com>> wrote:
On Fri, Feb 17, 2012 at 6:04 PM, Nowlan, Sean 
mailto:sean.now...@gtri.gatech.edu>> wrote:
Don't know how helpful these are, but here you go.

Sean

Sean,
It looks like a couple of functions are failing from the stdout:

volk_32fc_s32f_magnitude_16i_a: fail on arch orc
volk_32fc_x2_multiply_32fc_a: fail on arch orc

These are both the Orc implementations of the functions, which seem to work 
fine on my Intel processors. I don't have access to an OSX box or an E100, so I 
can't really test this out. The files you sent me don't (appear to) tell me 
what the real problem is.

We'll need some other brave soul out there who can dig into these issues on the 
platforms for us.

Thanks,
Tom



From: trond...@trondeau.com 
[mailto:trond...@trondeau.com] On Behalf Of Tom 
Rondeau
Sent: Friday, February 17, 2012 5:25 PM
To: Nowlan, Sean
Cc: Nick Foster; discuss-gnuradio@gnu.org

Subject: Re: [Discuss-gnuradio] Using volk in Mac: test report

On Fri, Feb 17, 2012 at 5:11 PM, Nowlan, Sean 
mailto:sean.now...@gtri.gatech.edu>> wrote:
I built Tom's safe_align branch on E100 and ran volk_profile. It segfaulted on 
"RUN_VOLK_TESTS:volk_32fc_s32fc_multiply_32fc_a. I'll get a stack trace for you.

Sean

Really interesting that it's the same block. Hopefully, it's a single, simple 
fix. I'll look into it when you can get me the stack trace.

Thanks for reporting!
Tom



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, February 17, 2012 2:33 PM
To: Nick Foster
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Using volk in Mac: test report

On Fri, Feb 17, 2012 at 2:30 PM, Nick Foster 
mailto:n...@ettus.com>> wrote:
On Fri, Feb 17, 2012 at 11:20 AM, Carles Fernandez 
mailto:carles.fernan...@gmail.com>> wrote:
Thanks for the inputs!

We are interested in determining the best architecture at instantation
time. What would be the best strategy? We though about running the
same operations several times for each architecture, measure the
results and use the fastest one for the processing blocks. Would this
be the right approach?

Carles,

Run volk_profile. It does exactly what you said, and writes the results to 
~/.volk/volk_config. Volk reads this file when it is involked (sorry) to 
determine which particular function to execute. So all you do is run 
volk_profile once on any given machine, and it's optimized.

--n

Carles,
This is discussed on the webpage:
http://gnuradio.org/redmine/projects/gnuradio/wiki/volk

We'll be updating this as things progress with Volk, but the profiler info is 
there already.

Tom





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