[Discuss-gnuradio] Fwd:MIMO cable synchronization accuracy
Hi everyone,
To synchronize two USRPs, I connect them and add the following code in
the slave USRP. ---
set_clock_source( 'MIMO',0);
set_time_source('MIMO',0);
---
I have got that the length of MIMO cable is fixed because the cable
delay is compensated in the slave USRP's motherboard. So here is a
question that what is the time synchronization accuracy within USRPs
using MIMO cable?
Thank you in advance.
Best,
Harry
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Time Granularity of USRP N2XX
Dear Marcus, Thank you for your reply. I'm confused about two concepts. Referring to the file time_spec.hpp in UHD, fractional sec is calculated according to the parameter ticks and tick_rate. So I think the time granularity is '1/tick_rate' which is 0.1us using 10Mhz clock. But for the timestamp of sample stream, the granularity is the sample duration. Is it correct? Best, Harry 2013/11/26 20:12, Marcus Müller wrote: Hi Harry, as far as I know, the granularity of a time stamp is the sample duration at the downsampled side. As for the 10MHz: The 10MHz clock is used to derive different other clocks, especially the rx ADC and tx DAC clocks, which are an order of magnitude higher; bear in mind that when you request e.g. "5MHz samle rate" you still get the 100MHz* samples of the ADC, but downsampled by a factor of 20. Please also bear in mind that due to physics, processing etc the timestamp of the rx side is delayed to the actual reception of "that sample", and that this delay is largely constant when receiving using the same settings, but my change based on sampling rate and other factors. Greetings Marcus *for USRP2 arch, if I remember correctly. On 26.11.2013 13:04, Harry Zhang wrote: Hi, Since we can get receive time of rx_stream's first sample via rx tags, I have two questions about the time granularity. Given the internal clock is 10Mhz, is the time granularity 0.1us? The fractional second is stored double type. Does it mean the last digits of the fractional sec are invalid? ___ 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] Time Granularity of USRP N2XX
Hi, Since we can get receive time of rx_stream's first sample via rx tags, I have two questions about the time granularity. Given the internal clock is 10Mhz, is the time granularity 0.1us? The fractional second is stored double type. Does it mean the last digits of the fractional sec are invalid? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to get multipe rx_time tags while receiving continuously
Dear Miklos, Yes, I do never stop receive program. I'm using USRP N210, WBX, Ubuntu12.04 and UHD3.5.3. I'm writing a document in detail, which will be sent to you later today. Best, Harry 2013/11/3 22:47, Miklos Maroti wrote: Hi Harry, You never stop the receiver on node B and C, right? You should not observe anything like that if you do not have dropped packets. Are you using USRP2's? Miklos On Sat, Nov 2, 2013 at 3:05 AM, Harry Zhang wrote: Tom, Thanks for your reply. I got a weird problem when using rx_time tags. I have three nodes, node A sends 10 packets within 0.2 sec ,stops for 1sec sends 10 packets , stops..., sends,stops . Node B and C receive it and record the receive time using (rx_time+ sample_count*sample_rate). Considerating the clock offset between B and C, the difference of B and C's receive time must remain stable. But every time after A stops for 1sec, the receive time's difference varies several hundreds of microsecond. I'm stumped by this problem. Could you give me some advice. Thank you in advance. Harry 2013/11/1 22:26, Tom Rondeau wrote: On Thu, Oct 31, 2013 at 3:46 AM, Harry Zhang wrote: Hi, As far as I know rx_time tag is associated with the first sample of a receive stream. If I wanna get multiple rx_time tags while receiving continuous data, should I stop and issue a new stream again and again for getting more rx_time tags. Thank you. Harry, We want to minimize tags through the flowgraph since it adds overhead. The UHD driver only sends an rx_time tag whenever one is necessary. That means that if there is a chance that the host has become unsynchronized, it sends an updated tag. So there's one at the beginning of the stream to set the initial time. Then, if a dropped packet or overflow are detected, it sends a new rx_time tag. Between time tags, you can count samples and you know the sample rate, so you know the time of every sample based on that initial rx_time tag (to within the tolerance of the sample clock on the USRP). 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] How to get multipe rx_time tags while receiving continuously
Tom, Thanks for your reply. I got a weird problem when using rx_time tags. I have three nodes, node A sends 10 packets within 0.2 sec ,stops for 1sec sends 10 packets , stops..., sends,stops . Node B and C receive it and record the receive time using (rx_time+ sample_count*sample_rate). Considerating the clock offset between B and C, the difference of B and C's receive time must remain stable. But every time after A stops for 1sec, the receive time's difference varies several hundreds of microsecond. I'm stumped by this problem. Could you give me some advice. Thank you in advance. Harry 2013/11/1 22:26, Tom Rondeau wrote: On Thu, Oct 31, 2013 at 3:46 AM, Harry Zhang wrote: Hi, As far as I know rx_time tag is associated with the first sample of a receive stream. If I wanna get multiple rx_time tags while receiving continuous data, should I stop and issue a new stream again and again for getting more rx_time tags. Thank you. Harry, We want to minimize tags through the flowgraph since it adds overhead. The UHD driver only sends an rx_time tag whenever one is necessary. That means that if there is a chance that the host has become unsynchronized, it sends an updated tag. So there's one at the beginning of the stream to set the initial time. Then, if a dropped packet or overflow are detected, it sends a new rx_time tag. Between time tags, you can count samples and you know the sample rate, so you know the time of every sample based on that initial rx_time tag (to within the tolerance of the sample clock on the USRP). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to get multipe rx_time tags while receiving continuously
Hi, As far as I know rx_time tag is associated with the first sample of a receive stream. If I wanna get multiple rx_time tags while receiving continuous data, should I stop and issue a new stream again and again for getting more rx_time tags. Thank you. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Time synchronization between two USRPs without external signal
Dear Miklos, I got a weird problem while running the sync method(Node A transmit the sync messages,node A and B receive them). I control A transmit continuously for 0.2sec and stop for 2sec,repeat this.In the 0.2 sec period, node A could transmit 20 sync message and the difference of A and B's receive timestamp remain stable(such as 3.205122sec), the standard deviation of it is about 5us,which is good. But when transmitting again after 3sec stop, the difference of A and B's receive timestamp is completely different with the previous one(changed to 3.245897sec but also stable). The difference is about .Considering the clock drift is small(about 2.5ppm),the the difference of receive timestamp between node A and B should remain unchanged in several minutes.So I think it's not caused by the clock drift in such a short time. What maybe cause this problem? Thanks in advance. Best Regard, Harry 2013/10/16 20:20, Miklos Maroti wrote: Hi Harry, On Sat, Oct 12, 2013 at 3:12 PM, Harry Zhang wrote: Dear Miklos, Thank you for your inspiring reply. 1.I do think this method sounds like a receiver-receiver sync while sync message's transmitter A also doing beacon node C's function ( (1)sending sync message and (2)recording receive time which would be sended to B for sync).Is it correct? Well, it is a transmitter-receiver synchronization, since only two nodes are involved A and B, and only A sends, B only receives. The real problem is to correlate samples with time, and I have used the RX chain sample counter as "time" both on node A and B. You cannot use PC time because of large errors over ethernet/USB so you have to use the clock of the FPGA. 2.For 1us accuracy, does it mean the sample rate must be more than 1e6? Yes, of course. But you can even synchronize at 10 times the sampling rate (hard, but not impossible), i.e. you would use 1e6 sampling rate and get 1e7 precision. 3.Does "close to zero samples" means the sample_rate*sample_offset produces larger error when I use it for getting sync message's receive time? close to zero samples is complex numbers 1e^-4 + 1e^-4*j. The reason I do not use zero complex numbers is because I am afraid that the FPGA switches off the TX chain if you continuously try to transmit zeros. I am not sure that it does, you can experiment with that. 4.The 1us is the jitter caused by sample duration.What about the jitter produced by tx/rx tags? I do think 160us is mainly caused by the difference between actual time when message leaving/arriving antenna and tx/rx tags's time.What's your opinion? I do not know about the tx/rx tags. Of course the FPGA needs time to do the DSP, so it is possible that what you are seeing is the DSP time. However, the DSP time should be almost completely deterministic, so it cannot be a jitter just some time offset. If you see a jitter, then I think it must be caused by either ethernet or some DSP startup artifacts. Miklos Best, Harry 2013/10/12 19:17, Miklos Maroti wrote: Hi Harry, First, you should always transmit from node A, but when you want to be silent, then transmit something very close to zero complex numbers. This will ensure, that you have a nice continuous stream of data going out, and you can plan to do anything you want with sampling rate precision (better than 1us). Once you can do this, then transmit some pseudo random sequence from node A, e.g. BPSK with 2 samples per bit, and it is possible to synchronize to that with sampling rate precision again. Now comes the trick: node A not only transmits continuously, but it also receives continuously just like node B (with an antenna or just overhearing in the board). Both A and B synchronizes to the signal transmitted by A. In case of node A you do not have to worry of slightly different clocks, so once you are synchronized you will never get out of sync if you count the number of samples. In the case of node B it is harder, since node A might run a little faster or slower, so you will get out of sync, so you have to maintain synchronization. At this point, you have achieved synchronization of the two USRP nodes: you can stop sending periodically (continue spending close to zero samples) and then you can sample some data from node C, doing beam forming (depends on modulation), or whatever. You can correlate the received samples at node B with the received samples at node A with close to one sample precision (better than 1us). If you do not want to transmit all the time, then you can use TX tags, but it gets a little trickier, and I think there is some bug in the FPGA hardware to cause very rarely one sample shift between the TX and RX chain. I am not absolutely sure about this, but I could not explain something in any other way. Best, Miklos On Sat, Oct 12, 2013 at 10:10 AM, Harry Zhang wrote: Dear Miklos, I'm glad to hear from you. The idea of t
Re: [Discuss-gnuradio] Time synchronization between two USRPs without external signal
Dear Miklos, Thank you for your inspiring reply. 1.I do think this method sounds like a receiver-receiver sync while sync message's transmitter A also doing beacon node C's function ( (1)sending sync message and (2)recording receive time which would be sended to B for sync).Is it correct? 2.For 1us accuracy, does it mean the sample rate must be more than 1e6? 3.Does "close to zero samples" means the sample_rate*sample_offset produces larger error when I use it for getting sync message's receive time? 4.The 1us is the jitter caused by sample duration.What about the jitter produced by tx/rx tags? I do think 160us is mainly caused by the difference between actual time when message leaving/arriving antenna and tx/rx tags's time.What's your opinion? Best, Harry 2013/10/12 19:17, Miklos Maroti wrote: Hi Harry, First, you should always transmit from node A, but when you want to be silent, then transmit something very close to zero complex numbers. This will ensure, that you have a nice continuous stream of data going out, and you can plan to do anything you want with sampling rate precision (better than 1us). Once you can do this, then transmit some pseudo random sequence from node A, e.g. BPSK with 2 samples per bit, and it is possible to synchronize to that with sampling rate precision again. Now comes the trick: node A not only transmits continuously, but it also receives continuously just like node B (with an antenna or just overhearing in the board). Both A and B synchronizes to the signal transmitted by A. In case of node A you do not have to worry of slightly different clocks, so once you are synchronized you will never get out of sync if you count the number of samples. In the case of node B it is harder, since node A might run a little faster or slower, so you will get out of sync, so you have to maintain synchronization. At this point, you have achieved synchronization of the two USRP nodes: you can stop sending periodically (continue spending close to zero samples) and then you can sample some data from node C, doing beam forming (depends on modulation), or whatever. You can correlate the received samples at node B with the received samples at node A with close to one sample precision (better than 1us). If you do not want to transmit all the time, then you can use TX tags, but it gets a little trickier, and I think there is some bug in the FPGA hardware to cause very rarely one sample shift between the TX and RX chain. I am not absolutely sure about this, but I could not explain something in any other way. Best, Miklos On Sat, Oct 12, 2013 at 10:10 AM, Harry Zhang wrote: Dear Miklos, I'm glad to hear from you. The idea of this experiment is quite similar to the core of your honored paper "The flooding time synchronization protocol". It's a transmitter-receiver sync method using precious tx/rx timestamp to synchronize transmitter's and receiver's local timer. On the transmitter side, sync message is transmitted every 1 sec. Using rx tags, it's easy to get the average receive interval is 1.0003sec and the jitter is around 320us. Considering the interval jitter is 2*(rx jitter+rx jitter), the sync accuracy is 160us. I wanna break into USRP FPGA to achieve 1us or less accuracy. And I don't understand your "continuously transmission". Could give me some details. 2013/10/12 9:03, Miklos Maroti wrote: Hi Harrz, What do you mean by 160us precision? How did you measure it or compute it exactly? I do not understand your goal, but it is quite simple to synchronize two usrps with continuous transmission to within one sample and if you continuously receive the transmitted signal on the transmitter side, then you can avoid all time stamping problems and effectively synchronize the tx and rx chains of a single usrp. Miklos On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang wrote: Hi, I have implemented time synchronization between two USRPs without GPSDO, MIMO cable or referring to computer's time.It's a sender-receiver method based on message exchange. It will be included in my next paper soon. I use the tx_time and tx_sob tag to transmit the message at the planned time. When this message researches the receiver, I can get the receive time via rx_time tags. The transmit and receive time of tx tags and rx tags are recorded in USRP motherboard without the jitter of Ethernet cable or operating system. So I think it could achieve the best accuracy without modifying FPGA. The experiment shows the accuracy is around 160us. I think it's mostly caused by the jitter of the tx tag's time. I wanna achieve better accuracy than this and the best way is adding a hardware timestamp module in FPGA. Is this way feasible? As for now, I wanna get a depth understanding of the implementing of tx tag,so I will know the accuracy limit of this method. But I'm not fam
Re: [Discuss-gnuradio] Time synchronization between two USRPs without external signal
Dear Miklos, I'm glad to hear from you. The idea of this experiment is quite similar to the core of your honored paper "The flooding time synchronization protocol". It's a transmitter-receiver sync method using precious tx/rx timestamp to synchronize transmitter's and receiver's local timer. On the transmitter side, sync message is transmitted every 1 sec. Using rx tags, it's easy to get the average receive interval is 1.0003sec and the jitter is around 320us. Considering the interval jitter is 2*(rx jitter+rx jitter), the sync accuracy is 160us. I wanna break into USRP FPGA to achieve 1us or less accuracy. And I don't understand your "continuously transmission". Could give me some details. 2013/10/12 9:03, Miklos Maroti wrote: Hi Harrz, What do you mean by 160us precision? How did you measure it or compute it exactly? I do not understand your goal, but it is quite simple to synchronize two usrps with continuous transmission to within one sample and if you continuously receive the transmitted signal on the transmitter side, then you can avoid all time stamping problems and effectively synchronize the tx and rx chains of a single usrp. Miklos On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang wrote: Hi, I have implemented time synchronization between two USRPs without GPSDO, MIMO cable or referring to computer's time.It's a sender-receiver method based on message exchange. It will be included in my next paper soon. I use the tx_time and tx_sob tag to transmit the message at the planned time. When this message researches the receiver, I can get the receive time via rx_time tags. The transmit and receive time of tx tags and rx tags are recorded in USRP motherboard without the jitter of Ethernet cable or operating system. So I think it could achieve the best accuracy without modifying FPGA. The experiment shows the accuracy is around 160us. I think it's mostly caused by the jitter of the tx tag's time. I wanna achieve better accuracy than this and the best way is adding a hardware timestamp module in FPGA. Is this way feasible? As for now, I wanna get a depth understanding of the implementing of tx tag,so I will know the accuracy limit of this method. But I'm not familiar with the FPGA, so could anyone describe how tx_time tag implemented or give me some documents about this? Thanks in advance. ___ 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] Time synchronization between two USRPs without external signal
Hi, I have implemented time synchronization between two USRPs without GPSDO, MIMO cable or referring to computer's time.It's a sender-receiver method based on message exchange. It will be included in my next paper soon. I use the tx_time and tx_sob tag to transmit the message at the planned time. When this message researches the receiver, I can get the receive time via rx_time tags. The transmit and receive time of tx tags and rx tags are recorded in USRP motherboard without the jitter of Ethernet cable or operating system. So I think it could achieve the best accuracy without modifying FPGA. The experiment shows the accuracy is around 160us. I think it's mostly caused by the jitter of the tx tag's time. I wanna achieve better accuracy than this and the best way is adding a hardware timestamp module in FPGA. Is this way feasible? As for now, I wanna get a depth understanding of the implementing of tx tag,so I will know the accuracy limit of this method. But I'm not familiar with the FPGA, so could anyone describe how tx_time tag implemented or give me some documents about this? Thanks in advance. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sample receive time in benchmark
于 2013/9/19 21:56, Tom Rondeau 写道: On Wed, Sep 18, 2013 at 11:32 PM, Harry Zhang wrote: Hi, My last question (http://lists.gnu.org/archive/html/discuss-gnuradio/2013-09/msg00196.html) seems no answer.But I get another question. I wanna know the actual receive time of a sample. If I get the rx tag(sample count 100), I can calculate the any sample's receive time. For example,sample 1600's receive time: (1600-100)*sample_rate. Is it correct? Yes, as long as you are using the right sample rate. In my last question, the sender transmit data every 3 second and the uhd_fft shows it's true.But the above formula give the result about 1 second. I think the sample_rate is wrong. I'm using benchmark_rx(gmsk) in narrowband and the UHD shows the sample_rate is 200ksample/s. Sample_rate wrong or my formula,which is wrong? Any suggestion is appreciated. Make sure you are using the sample rate and not the symbol rate. Each symbol is transmitted using some number of samples per symbol. I'm sure you already know that, but just to make sure as that's a likely cause of confusion when setting things up. If I'm using the symbol_rate, the actual sample_rate must be more that that I'm using now. Thus the formula gives result even less than 1 second, which is still not coming to 3 second. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sample receive time in benchmark
Hi, My last question (http://lists.gnu.org/archive/html/discuss-gnuradio/2013-09/msg00196.html) seems no answer.But I get another question. I wanna know the actual receive time of a sample. If I get the rx tag(sample count 100), I can calculate the any sample's receive time. For example,sample 1600's receive time: (1600-100)*sample_rate. Is it correct? In my last question, the sender transmit data every 3 second and the uhd_fft shows it's true.But the above formula give the result about 1 second. I think the sample_rate is wrong. I'm using benchmark_rx(gmsk) in narrowband and the UHD shows the sample_rate is 200ksample/s. Sample_rate wrong or my formula,which is wrong? Any suggestion is appreciated. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tx_tag's time VS. USRP time
Hi everyone,
I wanna send data at desired time with USRP N210. The codes look like these
-
int num=1;
pmt::pmt_t key = pmt::pmt_string_to_symbol("sob");
uint64_t offset = this->nitems_written(0);
pmt::pmt_t value = pmt::pmt_make_tuple(
pmt::pmt_from_uint64(5+3*num),
pmt::pmt_from_double(0.000)
);
this->add_item_tag(0, offset, key, value);
num+=1;
offset = this->nitems_written(0)+n;
key = pmt::pmt_string_to_symbol("tx_tag");
value = pmt::pmt_make_tuple(
pmt::pmt_from_uint64(5+3*num),
pmt::pmt_from_double(0.000)
);
this->add_item_tag(0, offset, key, value);
num+=1;
offset = this->nitems_written(0);
key = pmt::pmt_string_to_symbol("eob");
value = pmt::pmt_make_tuple(
pmt::pmt_from_uint64(5+3*num),
pmt::pmt_from_double(0.000)
);
this->add_item_tag(0, offset, key, value);
It is obvious the code make the data sent at 8.00s,11.00s abd
14.00s.On the receive side,I can see the data is sent every 3
seconds.This is correct.But I didn't set USRP time to 0.00 before
executing the code. This means the data were sent at (assuming it's
300.10s now) 303.10s, 306.100s and 309.100. why this?
I'm using Ubuntu12.04 and gnuradio 3.6.5.1.
Any suggestion is appreciated.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Can not get rx time tags
Hi,
I'm trying to get rx time tags in narrowband Benchmark_tx/rx with a
modified digital_correlate_access_code.cc. But the
"get_tags_in_range(rx_time_tags,0,this->nitems_read(0)+i,this->nitems_read(0)+i+1,pmt::pmt_string_to_symbol("rx_time"))"
method gets no tag in rx_time_tags while the communication between two
USRP N210s running benchmark_rx/tx is OK.
I'm using GNU Radio 3.6.5.1, Ubuntu12.04, boost 1.48 and UHD 3.5.3.
Thanks in advance.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using UHD control block
Dear Josh, I have checked the cmake output and gr_uhd is within the enabled components. I'm using Ubuntu12.04 and boost 1.48. 2013/8/3 11:39, Josh Blum wrote: On 08/02/2013 06:32 AM, Marcus Müller wrote: Hi Harry Zhang, UHD in general not related to GRAS. I don't know either a UHD control nor a status block. Are you referring to the UHD USRP source/sink blocks? However, if you're trying to use any UHD related functionality, you will need to compile GNURadio with UHD support, therefore have the UHD headers somewhere Cmake will find them (thus enabling gr-uhd). There is a control and status block in grextras. They should show up in the UHD category tree when installed. https://github.com/guruofquality/grextras/wiki/Blocks#wiki-misc-uhd-blocks So I guess you need to check if the the cmake configuration for GRAS found uhd support. The configuration verbose should tell us this. Just post the verbose if you have any questions. THanks! -josh -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using UHD control block
Hi, I install the GRAS. But I can't find the UHD status block or UHD control block in GRC. How can I use them? Is there any example about using UHD control block? Thanks in advance. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio3.7 make error
Dear Nathan, Thank you for your reply. I have changed the boost to 1.48 but the error remains. According to the error information, it seems to require libboost1.40,which puzzles me. 2013/7/30 12:12, Nathan West wrote: On Mon, Jul 29, 2013 at 11:55 PM, Gong Zhang wrote: Dear Nathan, I have tried the method in the URL but it does not work. The error remains. 2013/7/30 10:58, Nathan West wrote: On Mon, Jul 29, 2013 at 10:44 PM, Harry Zhang wrote: Hi, I'm using Ubuntu 12.04 and libboost1.46. I got the following errors when I make the project. libboost1.46 is known to cause problems with GNU Radio. Ubuntu 12.04 should have libboost1.48 available in the repos. Here's some more info: http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00267.html What do you mean you tried the method in the URL? The cmake flag? The point of sending that link is the version of boost you have is known to cause problems with GNU Radio and unless you have a very good reason for using it you should use another version. If you're having trouble installing GNU Radio for the first time you might give pybombs a shot. It's pretty easy to get an installation going for the first time, especially if you're having a problem with dependencies like boost. Here's info on pybombs: http://gnuradio.org/redmine/projects/pybombs/wiki Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gnuradio3.7 make error
Hi, I'm using Ubuntu 12.04 and libboost1.46. I got the following errors when I make the project. [ 85%] Building CXX object gr-uhd/examples/c++/CMakeFiles/tags_demo.dir/tags_demo.cc.o Linking CXX executable tags_demo /usr/bin/ld: warning: libboost_date_time.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_filesystem.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_program_options.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_regex.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_system.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_thread.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_unit_test_framework.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/local/lib/libuhd.so: undefined reference to `boost::filesystem::detail::dir_itr_increment(void*&, void*&, std::basic_string, std::allocator >&, boost::filesystem::file_status&, boost::filesystem::file_status&)' /usr/local/lib/libuhd.so: undefined reference to `boost::thread_resource_error::thread_resource_error()' /usr/local/lib/libuhd.so: undefined reference to `boost::filesystem::detail::dir_itr_close(void*&, void*&)' /usr/local/lib/libuhd.so: undefined reference to `boost::lock_error::lock_error()' /usr/local/lib/libuhd.so: undefined reference to `boost::filesystem::detail::dir_itr_first(void*&, void*&, std::basic_string, std::allocator > const&, std::basic_string, std::allocator >&, boost::filesystem::file_status&, boost::filesystem::file_status&)' /usr/local/lib/libuhd.so: undefined reference to `boost::filesystem::detail::get_current_path_api(std::basic_stringstd::char_traits, std::allocator >&)' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::get_mem_block()' /usr/local/lib/libuhd.so: undefined reference to `boost::filesystem::detail::not_found_error()' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::get_default_error_string(boost::regex_constants::error_type)' /usr/local/lib/libuhd.so: undefined reference to `boost::system::get_generic_category()' /usr/local/lib/libuhd.so: undefined reference to `boost::system::get_system_category()' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::put_mem_block(void*)' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::raise_runtime_error(std::runtime_error const&)' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::cpp_regex_traits_implementation::transform_primary(char const*, char const*) const' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::perl_matcherstd::allocator >, boost::regex_traits > >::construct_init(boost::basic_regexboost::cpp_regex_traits > > const&, boost::regex_constants::_match_flags)' /usr/local/lib/libuhd.so: undefined reference to `boost::filesystem::detail::status_api(std::basic_stringstd::char_traits, std::allocator > const&, boost::system::error_code&)' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::cpp_regex_traits_implementation::transform(char const*, char const*) const' /usr/local/lib/libuhd.so: undefined reference to `boost::match_resultsconst*> > >::maybe_assign(boost::match_resultsstd::allocator > > const&)' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::verify_options(unsigned int, boost::regex_constants::_match_flags)' /usr/local/lib/libuhd.so: undefined reference to `boost::basic_regexboost::cpp_regex_traits > >::do_assign(char const*, char const*, unsigned int)' collect2: ld returned 1 exit status make[2]: *** [gr-uhd/examples/c++/tags_demo] Error 1 make[1]: *** [gr-uhd/examples/c++/CMakeFiles/tags_demo.dir/all] Error 2 make: *** [all] Error 2 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
