Groups keyboard shortcuts have been updated

Dismiss

See shortcuts

USRP and resampling

344 views

Skip to first unread message

Ofir

unread,

Sep 15, 2013, 12:39:58 PM9/15/13

to flex...@googlegroups.com

Hi there talented gentlemen,

I built and run OSLD, and I believe everythiong is working just fine when I run with osld_tx_file.app and osld_rx_file.app.

I am having trouble with 2 USRP's (model 2920) on 2 PC's. When I run the osld_tx_usrp.app & osld_rx_usrp.app - both PC's seems to utilize their local cores at 60% max, so I think there is no problem with processing power.

I noticed that the UHD driver says:

"""

Opening a USRP2/N-Series device...

-- Current recv frame size: 1472 bytes

-- Current send frame size: 1460 bytes

-- Detecting internal GPSDO.... not found

UHD Warning:

The hardware does not support the requested TX sample rate:

Target sample rate: 1.920000 MSps

Actual sample rate: 1.923077 MSps

.OK!

"""

And the same goes for RX.

First of all, I think "GPSDO.... not found" is not an issue since I am using kalibrate (http://thre.at/kalibrate/) to calibrate the USRP clock and it is proven to correct some clock issues with USRP.

Secondly, I've seen that someone wrote:

"""

> Yes, I just thought that the reason for that is that the USRP sampling frequency is not exactly 1.92 MHz (is a little bit higher), and since the waveform sends 1920 samples each time slot, the time > slot is slightly shorter than that.

> Try to do the following:

> - When you run the osld_tx_usrp.app, read the sampling rate from the console output and compute the time slot (i.e. 1920/Sr, with Sr the sampling rate).

> - I think it was something like 930 us. Then go to the config file and set the time slot to 930 us.

"""

and indeed setting the timeslot to 870 micro eliminates the "D" being printed to the screen on the tx machine, and the "U" for the rx machine, but still the whole thing doesn't seem to work :(

A disturbing thought came to my head: in OpenBTS the folks tell the average Joe to compile with re-sampling flag, which means that the IQ samples are resampled before they are sent to the USRP. Doen't it mean that in OSLD case we need to re-sample the 1.92 Mega-samples samples to 1.923077 Mega-samples? And do the same for the rx: resample 1.923 Mega samples to 1.920 mega samples?

I'll be glad to hear your thoughts on the matter.

Thanks in advance!

Ofir

Ismael Gomez

unread,

Sep 16, 2013, 11:46:26 AM9/16/13

to flex...@googlegroups.com

2013/9/15 Ofir <ofir...@gmail.com>

Hi there talented gentlemen,

Hi ofir, welcome to the list.

I built and run OSLD, and I believe everythiong is working just fine when I run with osld_tx_file.app and osld_rx_file.app.
I am having trouble with 2 USRP's (model 2920) on 2 PC's. When I run the osld_tx_usrp.app & osld_rx_usrp.app - both PC's seems to utilize their local cores at 60% max, so I think there is no problem with processing power.

I noticed that the UHD driver says:

"""
Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes

-- Current send frame size: 1460 bytes
-- Detecting internal GPSDO.... not found

UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 1.920000 MSps

Actual sample rate: 1.923077 MSps
.OK!
"""
And the same goes for RX.

First of all, I think "GPSDO.... not found" is not an issue since I am using kalibrate (http://thre.at/kalibrate/) to calibrate the USRP clock and it is proven to correct some clock issues with USRP.

Secondly, I've seen that someone wrote:

"""
> Yes, I just thought that the reason for that is that the USRP sampling frequency is not exactly 1.92 MHz (is a little bit higher), and since the waveform sends 1920 samples each time slot, the time > slot is slightly shorter than that.

> Try to do the following:
> - When you run the osld_tx_usrp.app, read the sampling rate from the console output and compute the time slot (i.e. 1920/Sr, with Sr the sampling rate).

> - I think it was something like 930 us. Then go to the config file and set the time slot to 930 us.
"""

and indeed setting the timeslot to 870 micro eliminates the "D" being printed to the screen on the tx machine, and the "U" for the rx machine, but still the whole thing doesn't seem to work :(

Did you have the opportunity to check the transmitted signal with an spectrum analyzer?

Please check the last message of this thread: https://groups.google.com/forum/#!topic/flexnets/3cG66AEB0h8

It's the same you were mentioning. If you are not using Xenomai, setting a timeslot to 870 micro and the blocking=1 option should work. The next step is to calibrate the receiver gain, because the AGC module is not working propertly.

Please check that thread and don't hesitate to ask any question or report your results/experiences.

A disturbing thought came to my head: in OpenBTS the folks tell the average Joe to compile with re-sampling flag, which means that the IQ samples are resampled before they are sent to the USRP. Doen't it mean that in OSLD case we need to re-sample the 1.92 Mega-samples samples to 1.923077 Mega-samples? And do the same for the rx: resample 1.923 Mega samples to 1.920 mega samples?

I'll be glad to hear your thoughts on the matter.

You don't need to do this in ALOE. The transmitted signal is not 100% compliant with the LTE RF specifications, because it occupies 1.923 MHz of spectrum, rather than 1.92 MHz. The bit rate is higher, too. Since the receiver also operates at 1.923 MHz, you shouldn't see any problem.

Thanks in advance!

Ofir

Thank you for trying OSLD. Your feedback is very helpful to us!

Kind regards,

Ismael

--
You received this message because you are subscribed to the Google Groups "ALOE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flexnets+u...@googlegroups.com.
To post to this group, send email to flex...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/c258f13e-d475-47b9-8afa-3eafc0fc6696%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Ofir

unread,

Sep 17, 2013, 6:59:09 AM9/17/13

to flex...@googlegroups.com

Hi,

Thanks for the fast reply!

So one thing that really got me going was moving the antenna on the rx USRP to the second port which is marked "RX 2". Game is on!

Using uhd_fft i see the signal load and clear (-30 dbm). I moved to frequency 895MHz by changing "{name="freq";value=895000000.0}" on *rx*.app and *tx*.app files (the spectrum seemed clearer there).

I played with the scale parameter on the agc on osld_rx_usrp.app, and noticed that I can get the line

"Peak detected 11037.5 at 960, cfo=0.01"

appear every 1-5 time slots, depending on the scale parameter - or not at all. I'll try playing with it some more and let you know.

At first I got a lot of

"""

>> r

Running...OK!

>> Module resdemapp_pdcch returned error from work() function. Trying a clean stop

Total blocks: 1 Total errors: 1 BLER=1

Total blocks: 7 Total errors: 7 BLER=1

Waveform ./osld_rx_usrp.app was cleanly removed from the system.

"""

And I'm still getting it every time on one of my PC's. Sometimes waiting a few seconds between "i" and "r" solves the problem on my other PC.

I guess it's some kind of bug in resdemapp_pdcch when no blocks are received...

When things actually run, on Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz using cores 1,2,3, it seems that processing is too slow. I get:

Name Mean Exec (us) Max Exec (us) Time slot Processor Id:Pos

rx 7.56 51 5713 1:0

ctrl_mux 3.71 21 5713 1:1

ctrl 38.86 182 5713 1:2

agc 23.87 171 5713 1:3

synchro_pss 312.24 1333 5713 1:4

logtime_st 3.11 26 5713 1:5

dup 5.23 43 5713 1:6

synchro_sss 63.38 126 5713 1:7

symb_rx_de_output 8.21 78 5713 0:8

symb_rx_remcyclic_first_0 1.89 15 5713 0:9

symb_rx_remcyclic_first_1 3.09 19 5713 2:10

symb_rx_remcyclic_0 1.70 13 5713 0:11

symb_rx_remcyclic_1 1.94 18 5713 0:12

symb_rx_remcyclic_2 1.74 16 5713 0:13

symb_rx_remcyclic_3 2.66 25 5713 2:14

symb_rx_remcyclic_4 1.69 12 5713 0:15

symb_rx_remcyclic_5 2.37 23 5713 2:16

symb_rx_remcyclic_6 1.61 15 5713 0:17

symb_rx_remcyclic_7 2.21 18 5713 2:18

symb_rx_remcyclic_8 1.60 12 5713 0:19

symb_rx_remcyclic_9 1.65 13 5713 0:20

symb_rx_remcyclic_10 1.61 20 5713 0:21

symb_rx_remcyclic_11 1.69 12 5713 0:22

symb_rx_fft_0 7.25 40 5713 0:23

symb_rx_fft_1 5.90 42 5713 0:24

symb_rx_fft_2 5.00 46 5713 0:25

symb_rx_fft_3 4.92 47 5713 0:26

symb_rx_fft_4 10.13 67 5713 2:27

symb_rx_fft_5 4.61 49 5713 0:28

symb_rx_fft_6 7.33 51 5713 2:29

symb_rx_fft_7 6.85 53 5713 2:30

symb_rx_fft_8 4.98 49 5713 0:31

symb_rx_fft_9 6.69 52 5713 2:32

symb_rx_fft_10 4.83 50 5713 0:33

symb_rx_fft_11 4.59 46 5713 0:34

symb_rx_fft_12 5.06 54 5713 0:35

symb_rx_fft_13 4.56 47 5713 0:36

mux_rx 6.71 62 5713 0:37

equalizer 12.33 109 5713 0:38

resdemapp_pbch 8.75 79 5713 0:39

pbch_rx_demodulator 2.48 36 5713 0:40

pbch_rx_descrambling 2.30 33 5713 0:41

pbch_rx_unratematching 1.12 22 5713 0:42

pbch_rx_decoder 30.03 586 5713 0:43

pbch_rx_crc_descramble 0.82 3 5713 0:44

pbch_rx_crc_check 1.09 4 5713 0:45

pbch_rx_unpack 0.99 6 5713 0:46

resdemapp_pcfich 16.02 79 5713 2:47

pcfich_rx_demodulation 2.27 15 5713 2:48

pcfich_rx_descrambling 3.02 24 5713 2:49

pcfich_rx_decoder 4.51 29 5713 2:50

resdemapp_pdcch 30.38 109 5713 1:51

pdcch_rx_demodulator 11.04 23 5713 1:52

pdcch_rx_descrambling 5.99 20 5713 1:53

pdcch_rx_unratematching 6.45 26 5713 1:54

pdcch_rx_decoder 444.17 580 5712 1:55

pdcch_rx_crc_check 2.69 14 5712 1:56

pdcch_rx_unpack 4.62 20 5712 1:57

resdemapp_pdsch 16.37 103 5713 2:58

pdsch_rx_demodulator 68.78 165 5713 2:59

pdsch_rx_descrambling 27.56 94 5713 2:60

pdsch_rx_unratematching 184.30 447 5713 2:61

pdsch_rx_decoder 347.35 683 5712 2:62

pdsch_rx_uncrc_tb 19.63 30 5712 2:63

logtime_end 1.68 3 5712 2:64

sink 1.69 2 5712 2:65

Total 2393 (275.06%) Max: 6361 (731.15%)

>> Total blocks: 4500 Total errors: 4500 BLER=1

Total blocks: 5400 Total errors: 5400 BLER=1

Total blocks: 6300 Total errors: 6300 BLER=1

Total blocks: 7200 Total errors: 7200 BLER=1

Total blocks: 8100 Total errors: 8100 BLER=1

Total blocks: 9000 Total errors: 9000 BLER=1

Total blocks: 9900 Total errors: 9900 BLER=1

Total blocks: 10800 Total errors: 10800 BLER=1

Total blocks: 11700 Total errors: 11700 BLER=1

Total blocks: 1352 Total errors: 92 BLER=0.0680473

Total blocks: 15099 Total errors: 9436 BLER=0.624942

Total blocks: 11721 Total errors: 11721 BLER=1

Waveform ./osld_rx_usrp.app was cleanly removed from the system.

OK!

"""

Do you think that moving to a kernel with Xenomai will improve performance?

I noticed that right after hitting "s" the some blocks received properly. Do you have any ideas why?

One last thing to note: if I use cores 0,1,2,3 then there is no exiting via Ctrl+C from runcf. I have to kill the process via kill -9 to terminate runcf.

Thanks a lot!

Ofir

--
You received this message because you are subscribed to a topic in the Google Groups "ALOE" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/flexnets/uPU2WFm1DBg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to flexnets+u...@googlegroups.com.

To post to this group, send email to flex...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/CAAC4g6vjtVXOusj4qjmxT7kFLOQSKBX93oXcsSY9D5ETJ70viw%40mail.gmail.com.

Ismael Gomez

unread,

Sep 17, 2013, 11:56:15 AM9/17/13

to flex...@googlegroups.com

2013/9/17 Ofir <ofir...@gmail.com>

Hi,

Thanks for the fast reply!

So one thing that really got me going was moving the antenna on the rx USRP to the second port which is marked "RX 2". Game is on!

Great!

Using uhd_fft i see the signal load and clear (-30 dbm). I moved to frequency 895MHz by changing "{name="freq";value=895000000.0}" on *rx*.app and *tx*.app files (the spectrum seemed clearer there).

I played with the scale parameter on the agc on osld_rx_usrp.app, and noticed that I can get the line
"Peak detected 11037.5 at 960, cfo=0.01"
appear every 1-5 time slots, depending on the scale parameter - or not at all. I'll try playing with it some more and let you know.

Yes, the PSS sequence is transmitted every 5 time slots (in a previous thread, I incorrectly said 10 time slots, sorry). Thus, tune the scale parameter so that you see the peak every 5 slots.

At first I got a lot of
"""

>> r
Running...OK!

>> Module resdemapp_pdcch returned error from work() function. Trying a clean stop

Total blocks: 1 Total errors: 1 BLER=1

Total blocks: 7 Total errors: 7 BLER=1
Total blocks: 7 Total errors: 7 BLER=1

Waveform ./osld_rx_usrp.app was cleanly removed from the system.
"""

This is because the PSS sequence was not detected.

And I'm still getting it every time on one of my PC's. Sometimes waiting a few seconds between "i" and "r" solves the problem on my other PC.

Maybe the USRP needs some time to buffer samples.

The large differences between the maximum and mean execution times indicate that the processing is eventually interrupted. This might be due to one of the following reasons (try to solve them in this order):

1) Running with no root permisions

2) Cores 0,1,2,3 share a physical core. Is your processor a true quad-core or a dual-core with 2 threads each core? Each allocated core should be a single physical core.

3) Print logs to stdout. In the config file, disable log_to_stdout and log_modules_to_stdout options.

4) Background tasks with real-time scheduler

5) Hardware interrupts, e.g. power saving, sound card, network, etc.

Do you think that moving to a kernel with Xenomai will improve performance?

You won't improve the mean execution time, but you will reduce the ratio between the maximum and mean execution time.

I noticed that right after hitting "s" the some blocks received properly. Do you have any ideas why?

When you hit 's', the total received/errors blocks are printed out. You should get the same info from the

One last thing to note: if I use cores 0,1,2,3 then there is no exiting via Ctrl+C from runcf. I have to kill the process via kill -9 to terminate runcf.