RE: UHD Announcement - July 6th 2010

Dear Josh,

I have modified my setting as you explained in your previous reply but
unfortunately I still have an error.

I am using these settings (copied from top_block.py):
self.uhd_mimo_source_0 = uhd.mimo_source(4, “addr=192.168.10.11
192.168.20.11 192.168.30.11 192.168.40.11, recv_buff_size=50000000,
send_buff_size=50000000”, uhd.io_type_t.COMPLEX_FLOAT32)
self.uhd_mimo_source_0.set_samp_rate_all(samp_rate)
map(lambda x: self.uhd_mimo_source_0.set_center_freq(*x),
enumerate((fc,fc,fc,fc)))
map(lambda x: self.uhd_mimo_source_0.set_gain(*x),
enumerate((35,35,35,35)))
map(lambda x: self.uhd_mimo_source_0.set_antenna(*x),
enumerate([‘TX/RX’,‘TX/RX’,‘TX/RX’,‘TX/RX’]))

When I run the flowgraph I receive this error message and the program
stops:
Current recv sock buff size: 50000000 bytes
Current send sock buff size: 50000000 bytes
Current recv sock buff size: 50000000 bytes
Current send sock buff size: 50000000 bytes
Current recv sock buff size: 50000000 bytes
Current send sock buff size: 50000000 bytes
Current recv sock buff size: 50000000 bytes
Current send sock buff size: 50000000 bytes
Using: Flex 2400 MIMO B RX (0x0027)
Using: Flex 2400 MIMO B TX (0x002b)
Using: Flex 2400 MIMO B RX (0x0027)
Using: Flex 2400 MIMO B TX (0x002b)
Using: Flex 2400 MIMO B RX (0x0027)
Using: Flex 2400 MIMO B TX (0x002b)
Using: Flex 2400 MIMO B RX (0x0027)
Using: Flex 2400 MIMO B TX (0x002b)
RX samples per packet: 358
TX samples per packet: 355
Recv pirate num frames: 33333
Set time with unknown pps edge:

  1. set times next pps (race condition)
  2. catch seconds rollover at pps edge
  3. set times next pps (synchronously)
    gr_block_executor: source <gr_block uhd mimo source (1)> produced no
    output.
    We’re marking it DONE.

Sometimes I also receive these errors that disappear when I power cycle
the
USRP2’s:

Error (usrp2 recv pirate loop): bad vrt header or unsupported packet
type
Error (usrp2 recv pirate loop): assertion failed: if_packet_info.has_tsi
and
if_packet_info.has_tsf
in void
usrp2_impl::io_impl::recv_pirate_loop(boost::shared_ptruhd::transport::zero_copy_if,
boost::shared_ptr<usrp2_mboard_impl>, size_t)
at /home/dave/uhd/host/lib/usrp/usrp2/io_impl.cpp:97

Error (usrp2 recv pirate loop): assertion failed: if_packet_info.has_tsi
and
if_packet_info.has_tsf
in void
usrp2_impl::io_impl::recv_pirate_loop(boost::shared_ptruhd::transport::zero_copy_if,
boost::shared_ptr<usrp2_mboard_impl>, size_t)
at /home/dave/uhd/host/lib/usrp/usrp2/io_impl.cpp:97

Waiting for reply. By the way, thank you for modifying the online manual
:slight_smile:

Best regards,

Zohair

  1. set times next pps (synchronously)
    gr_block_executor: source <gr_block uhd mimo source (1)> produced no
    output. We’re marking it DONE.

This tells me that the alignment buffer is not finding a common
timestamp among the 4 channels or one or more channels is not streaming
(perhaps a timestamp/setup issue). What does your setup look like, is
there a common pps and common reference split 4X to each usrp2? I forgot
to add it to the notes but each device should have a common ref and pps
attached to its front panel. Also, can you try to run with just two
usrp2 to simplify the problem, does it work with 2 but not 3, 3 but not
4…?

at /home/dave/uhd/host/lib/usrp/usrp2/io_impl.cpp:97

Because the previous run did not exit cleanly and stop streaming, the
recv loop is catching the middle of a packet from the previous run. This
is safe to ignore.

-Josh

I pushed some changes to the uhd master that will check the deviation on
the times between boards. This should help you to debug your setup. If
you see an error message like the following, then you may have an issue
with the configuration. In the following example, I disconnected the PPS
on one of the boards. This is the result:

Set time with unknown pps edge:
1) set times next pps (race condition)
2) catch seconds rollover at pps edge
3) set times next pps (synchronously)
Error: time deviation between board 1 and board 0.
Board 0 time is 0.008782 seconds.
Board 1 time is 65.009945 seconds.

gr_block_executor: source <gr_block uhd mimo source (3)> produced no
output. We’re marking it DONE.

-Josh

Dear Josh,

Thanks for the info provided and the help.

I
have 4 USRP2 boards, 2 separate function generators and 2 splitters to
supply PPS and REF clock with specs as in the FAQ page. For testing
only, I used a VRT version of the firmware that my colleague modified
to send the REF clock to the debug pins, and I was able to see that the
ref clocks are synchronized.

I tried to work with 2 channels, 3 channels and 4 channels and wasn’t
lucky enough to get something working.

I am also interested to know if anybody has tried the MIMO block and got
it working/not working.

Best regards,
zohair

Dear Josh,
I have used another set of 4 USRP2’s to test my program. Unlike the
error I
see when using my old set I receive this output.

Current recv sock buff size: 50000000 bytes
Current send sock buff size: 50000000 bytes
Current recv sock buff size: 50000000 bytes
Current send sock buff size: 50000000 bytes
Current recv sock buff size: 50000000 bytes
Current send sock buff size: 50000000 bytes
Current recv sock buff size: 50000000 bytes
Current send sock buff size: 50000000 bytes
Using: Flex 2400 MIMO B RX (0x0027)
Using: Flex 2400 MIMO B TX (0x002b)
Using: Flex 2400 MIMO B RX (0x0027)
Using: Flex 2400 MIMO B TX (0x002b)
Using: Flex 2400 MIMO B RX (0x0027)
Using: Flex 2400 MIMO B TX (0x002b)
Using: Flex 2400 MIMO B RX (0x0027)
Using: Flex 2400 MIMO B TX (0x002b)
RX samples per packet: 362
TX samples per packet: 363
Recv pirate num frames: 33967
Set time with unknown pps edge:
1) set times next pps (race condition)
2) catch seconds rollover at pps edge
3) set times next pps (synchronously)
Error: time deviation between board 1 and board 0.
Board 0 time is 102.881714 seconds.
Board 1 time is 102.838705 seconds.

Error: time deviation between board 2 and board 0.
Board 0 time is 102.883991 seconds.
Board 2 time is 102.798313 seconds.

Error: time deviation between board 3 and board 0.
Board 0 time is 102.889212 seconds.
Board 3 time is 102.832728 seconds.

Done

The differnce here is that the program keeps running and I dont receive
the
“gr_block_executor: source <gr_block uhd mimo source (6)> produced no
output. We’re marking it DONE.”

Also, attached are the photos of the clock and the pps signal at the
output
of the splitters at the input of the USRPs.

Any help with this please? I also want to know if my old set of USRPs
has a
problem.

Best regards,

Zohair

Josh B.-2 wrote:

 3) set times next pps (synchronously)

ref clocks are synchronized.

gr_block_executor: source<gr_block uhd mimo source (1)> produced no
4…?
in void

http://old.nabble.com/file/p29224741/20100720119.JPG 20100720119.JPG
http://old.nabble.com/file/p29224741/20100720120.jpg 20100720120.jpg

View this message in context:
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29224741.html
Sent from the GnuRadio mailing list archive at Nabble.com.

The errors below confirm my suspicion that the sync at next pps is not
activated. The “Set time with unknown pps edge” routine will write time
zero into your devices. However, the times all read 102.xxx seconds
after the sync. I assume your powered them up at nearly the same time
(on a power switch) approximately 102 seconds prior to running the code
below. :slight_smile:

1.5 volts is too low for the pps. You need 5v cmos ideally. It may be
possible that the load on the pps is too high. What is the pps level
before the splitter? I recommend an active splitter that gives you 5v
cmos out.

Since we have narrowed the problem down you can test this with a single
usrp2.To debug this, take one usrp2, attach pps and ref with no
splitter, modify the examples/rx_timed_example to set the clock config,
and set the time at next pps, sleep(1). Readback the time and see if it
is expected.

Thank you,
-Josh

Dear Josh,

I have sorted out the PPS signal problem. It was the splitter that has
the
problem and now I am able to output 5v signal from it.

I tried to use an array of 2 and 3 usrp2 and it worked fine. However,
the
block still doesn’t work for my 4 USRP2. I see this error when I use
them
all:


Set time with unknown pps edge:
1) set times next pps (race condition)
2) catch seconds rollover at pps edge
3) set times next pps (synchronously)
Times set to 0 successfully! <<== note: these are printed if
there’s
no time deviation
Times set to 0 successfully!
Times set to 0 successfully!
gr_block_executor: source <gr_block uhd mimo source (1)> produced no
output.
We’re marking it DONE.


Any help, please?

Thanks again,

Zohair

Josh B.-2 wrote:

before the splitter? I recommend an active splitter that gives you 5v

Current send sock buff size: 50000000 bytes
Using: Flex 2400 MIMO B RX (0x0027)
Board 1 time is 102.838705 seconds.

Done
Any help with this please? I also want to know if my old set of USRPs has
the times between boards. This should help you to debug your setup. If
Board 1 time is 65.009945 seconds.

lucky enough to get something working.

usrp2 to simplify the problem, does it work with 2 but not 3, 3 but

Error (usrp2 recv pirate loop): assertion failed:
This


[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29265609.html
Sent from the GnuRadio mailing list archive at Nabble.com.

An extra peice of information is that the block is instable even with 2
and
three USRP2. This means sometimes it works and sometimes it producs no
output.

Zohair wrote:

Set time with unknown pps edge:

The errors below confirm my suspicion that the sync at next pps is not

Current send sock buff size: 50000000 bytes
RX samples per packet: 362
Error: time deviation between board 2 and board 0.
The differnce here is that the program keeps running and I dont receive
problem.

you see an error message like the following, then you may have an issue
Board 1 time is 65.009945 seconds.

I tried to work with 2 channels, 3 channels and 4 channels and wasn’t

no
pps
Error (usrp2 recv pirate loop): bad vrt header or unsupported packet
Because the previous run did not exit cleanly and stop streaming, the
us now


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29268907.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Dear Josh,

It’s working now! I changed it to 50ms instead of 10 and added the lines
in
the synchronisation for loop in mimo_usrp.cpp to see the amount of
deviation
between usrps if they are synchronised:

float diff=(time_i.get_real_secs() - time_0.get_real_secs())*1000;
std::cerr << boost::format(“Time was reset successfully for board %d
with
deviation: %f ms relative to board 0”)
% i %diff<< std::endl;
The output is:
Set time with unknown pps edge:
1) set times next pps (race condition)
2) catch seconds rollover at pps edge
3) set times next pps (synchronously)
Time was reset successfully for board 1 with deviation: 1.095390 ms
relative
to board 0
Time was reset successfully for board 2 with deviation: 1.093340 ms
relative
to board 0
Time was reset successfully for board 3 with deviation: 1.096530 ms
relative
to board 0

However, I still have a few questions:
1-Can’t we make the deviation exactly zero? What factors affect this?

2- In my tries to run the flowgraphs, sometimes I receive these errors:
OError (usrp2 recv pirate loop): assertion failed:
if_packet_info.has_tsi
and if_packet_info.has_tsf
in void
usrp2_impl::io_impl::recv_pirate_loop(boost::shared_ptruhd::transport::zero_copy_if,
boost::shared_ptr<usrp2_mboard_impl>, size_t)
at /home/dave/uhd/host/lib/usrp/usrp2/io_impl.cpp:106

you told me before it’s save to neglect these errors but when i neglect
them
I receive rubbish data not what I am expecting, despite the fact that
boards
indeed synchronised. These errors disappear when I power cycle the
USRPs. Is
there anything I can do about this?

3- Also, sometimes a number of “O” characters get printed on the screen,
what does this mean?

4- What is the least sampling freq that I can use?

I am so glad that we have got something working now and Thank you very
much
indeed.

Zohair

Josh B.-2 wrote:

line to something larger, say 50 ms:
run wireshark on all 4 ethernet interfaces to see how many are actually

 2) catch seconds rollover at pps edge

Any help, please?

activated. The “Set time with unknown pps edge” routine will write time
Since we have narrowed the problem down you can test this with a single

Dear Josh,
Current send sock buff size: 50000000 bytes
RX samples per packet: 362
Error: time deviation between board 2 and board 0.
The differnce here is that the program keeps running and I dont receive
a

the times between boards. This should help you to debug your setup. If
Error: time deviation between board 1 and board 0.

the
zohair

is

Sometimes I also receive these errors that disappear when I power
usrp2_impl::io_impl::recv_pirate_loop(boost::shared_ptruhd::transport::zero_copy_if,
-Josh
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29276686.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Zohair,

Glad to hear that things are working! (though not perfectly)

I intend to duplicate a 4X setup to verify what you are seeing. In the
meantime I have a few things you can try:

edit gr-uhd/lib/uhd_mimo_source.h and change the time in the following
line to something larger, say 50 ms:

stream_cmd.time_spec = get_time_now() + uhd::time_spec_t(0, 0.01);
//10ms offset in future

it is possible that the time in the stream request has become late when
board number 4 gets the command issued. 10 ms is an arbitrary time but i
believe that it is well over 4*RTT so i am not sure why that may be a
problem, but it is worth trying a greater time value.

run wireshark on all 4 ethernet interfaces to see how many are actually
streaming when this error occurs. This would tell me if a particular
board is not streaming or if all are streaming and the timespecs are
incorrect. You should see traffic from each board with udp source port
49153 (the data port).

-Josh

 1) set times next pps (race condition)
 2) catch seconds rollover at pps edge
 3) set times next pps (synchronously)

Time was reset successfully for board 1 with deviation: 1.095390 ms relative
to board 0
Time was reset successfully for board 2 with deviation: 1.093340 ms relative
to board 0
Time was reset successfully for board 3 with deviation: 1.096530 ms relative
to board 0

Your seeing the RTT between requests for the timestamp, since it is
working, the actual deviation is 0 and your boards are synced.

Thats why the test above is really just a sanity check to ensure that
the boards are not too far off (which otherwise implies that the
synchronization failed).

you told me before it’s save to neglect these errors but when i neglect them
I receive rubbish data not what I am expecting, despite the fact that boards
indeed synchronised. These errors disappear when I power cycle the USRPs. Is
there anything I can do about this?

If the setup does not shut down properly, some boards may be left
streaming. When a board begins to receive again, it may get partial
packets and recognize them as junk. You can ignore the warnings.

When you close the flowgraph does the application exit nicely or do you
have to control+C?

personal todo list: clean out the udp recv buffer chain on
initialization

3- Also, sometimes a number of “O” characters get printed on the screen,
what does this mean?

overflow, in the case of the usrp2, there is overflow in the socket
buffer, packets are dropped, and the uhd driver noticed a discrepancy in
the progression of sequence numbers and prints “O”

4- What is the least sampling freq that I can use?

actual sample rates achievable by the hardware are 100e6 divided by
//_USRP2_RATES = range(4, 128+1, 1) + range(130, 256+1, 2) + range(260,
512+1, 4)

so the smallest rate is 100e6/512 = 195312.5 Hz

I am so glad that we have got something working now and Thank you very much
indeed.

glad to hear it too, i will fix the mimo source with a timeout
proportional to the number of channels

-Josh

Hi Josh,

Just a quick note. I don’t use ctrl+c to kill the graph. Instead I use
the
kill button ( or F7)… Thanks again for the info provided.

Regards,

Zohair

Josh B.-2 wrote:

deviation: %f ms relative to board 0")
relative
the boards are not too far off (which otherwise implies that the
boost::shared_ptr<usrp2_mboard_impl>, size_t)

what does this mean?
//_USRP2_RATES = range(4, 128+1, 1) + range(130, 256+1, 2) + range(260,
proportional to the number of channels

-Josh


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29278750.html
Sent from the GnuRadio mailing list archive at Nabble.com.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs