# Transmission issue in USRP N210

**URL:** <https://www.ruby-forum.com/t/transmission-issue-in-usrp-n210/241444>\
**Category:** GNU Radio\
**Created:** [April 7, 2015, 2:16pm UTC](https://www.ruby-forum.com/t/transmission-issue-in-usrp-n210/241444 "2015-04-07T14:16:45Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\
**Post date:** [April 7, 2015, 2:16pm UTC](https://www.ruby-forum.com/t/transmission-issue-in-usrp-n210/241444/1 "2015-04-07T14:16:45Z")

</div>

Hi all,

I have recently installed openbts-2.8 on a banana-pi (Processor: armv7)  
board to work with USRP N210. Had all the pre-requisite installations  
and  
procedures been done, I noticed that, the transmitter is not working.

Though this issue seems to be related with openbts but since they are  
not  
responding, I would like to have some suggestions from you to resolve  
this  
issue.

In a previous thread ‘Marcus’ has stated that LED A is not working  
because  
openbts is not talking to USRP. i.e. USRP is not configured to receive  
samples.

Is he pointing to a receiving issue (probably I was looking for a  
transmission issue) or am I the one who is confused?

Can anyone please shed some light on this.

Thank you.

Best,  
Zamrath N.

---

<div class="post-metadata">

**Author:** ![Zamrath\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/b487fb/32.png) [@Zamrath\_N](https://www.ruby-forum.com/u/Zamrath_N)\
**Post date:** [April 7, 2015, 2:45pm UTC](https://www.ruby-forum.com/t/transmission-issue-in-usrp-n210/241444/2 "2015-04-07T14:45:39Z")

</div>

On 04/07/2015 08:14 AM, Zamrath N. wrote:

> Best,  
> Zamrath N.
> 
> * * *
> 
> Discuss-gnuradio mailing list  
> [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)  
> Can you ping the N210?

If you use:

uhd\_usrp\_probe --args addr=192.168.10.2

What happens?

Is your ethernet interface configured for 192.168.10.1 ?

---

<div class="post-metadata">

**Author:** ![Zamrath\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/b487fb/32.png) [@Zamrath\_N](https://www.ruby-forum.com/u/Zamrath_N)\
**Post date:** [April 7, 2015, 2:57pm UTC](https://www.ruby-forum.com/t/transmission-issue-in-usrp-n210/241444/3 "2015-04-07T14:57:49Z")

</div>

Hi Marcus,

> Can you ping the N210?

Yes. “ping 192.168.10.2” works fine.

> If you use: uhd\_usrp\_probe --args addr=192.168.10.2, What happens?

“uhd\_usrp\_probe” also works fine. Couldn’t check with --args. I am away  
from the board now for few hours. Until then…

> Is your ethernet interface configured for 192.168.10.1 ?

Yes. Configured statically in “/etc/network/interfaces” file.

Thanks,  
Zamrath N.

---

<div class="post-metadata">

**Author:** ![Zamrath\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/b487fb/32.png) [@Zamrath\_N](https://www.ruby-forum.com/u/Zamrath_N)\
**Post date:** [April 7, 2015, 3:12pm UTC](https://www.ruby-forum.com/t/transmission-issue-in-usrp-n210/241444/4 "2015-04-07T15:12:23Z")

</div>

The other Marcus here, I was the one that said something about the LEDs:

If your N210’s transmit LED is not on, then openBTS simply did not  
instruct the USRP to send samples.  
Thus, you will have to fix the problem on openBTS side. I’m pretty sure  
we went through all the diagnostics that made sense, and your USRP and  
UHD are working fine.

Greetings,  
Marcus

---

<div class="post-metadata">

**Author:** ![Zamrath\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/b487fb/32.png) [@Zamrath\_N](https://www.ruby-forum.com/u/Zamrath_N)\
**Post date:** [April 7, 2015, 7:40pm UTC](https://www.ruby-forum.com/t/transmission-issue-in-usrp-n210/241444/5 "2015-04-07T19:40:24Z")

</div>

Hi Marcus and Marcus,

Thank you for the valuable comments given. It made us to shrink all our  
focus on OpenBTS. But I see an inactive list in openbts side made me to  
wait for there response for a while. That’s why I thought to circulate  
this  
in gnuradio list hoping for any assistance to overcome this.

I have freshly installed openbts for three times upto now beside few  
many  
build cleans and installs. But I saw no breakthrough. Truth to be told,  
when I build openbts on banana-pi, I encountered following errors and  
did  
few manipulations given accordingly.

i) SIPEngine.cpp:1620:60: error: too few arguments to function ‘int  
rtp\_session\_set\_local\_addr(RtpSession\*, const char\*, int, int)’  
rtp\_session\_set\_local\_addr(mSession, “0.0.0.0”, mRTPPort );

Changed line 291, “ORTP\_PUBLIC int rtp\_session\_set\_local\_addr(RtpSession  
\*session,const char \*addr, int rtp\_port, int rtcp\_port);” into,  
“ORTP\_PUBLIC int rtp\_session\_set\_local\_addr(RtpSession \*session,const  
char  
\*addr, int rtp\_port);”

ii) SIPMessage.cpp:39:44: error: expected ‘,’ or ‘;’ before ‘VERSION’  
static const char\* userAgent = "OpenBTS " VERSION " Build Date "  
**DATE** ;

Changed line 39 of “trunk/SIP/SIPMessage.cpp” ("static const char\*  
userAgent = “OpenBTS " VERSION " Build Date " **DATE** ;”) into, "static  
const char\* userAgent = “OpenBTS Build Date " **DATE** ;”

iii) OpenBTS.cpp:375:48: error: ‘VERSION’ was not declared in this scope  
LOG(ALERT) \<\< "OpenBTS (re)starting, ver " \<\< VERSION \<\< " build date  
"  
\<\< **DATE** ;

Changed line 375 of “trunk/apps/OpenBTS.cpp” ("LOG(ALERT) \<\< “OpenBTS  
(re)starting, ver " \<\< VERSION \<\< " build date " \<\< **DATE** ;”) into,  
"LOG(ALERT) \<\< “OpenBTS (re)starting, build date " \<\< **DATE** ;”

Had above changes done, build was successfully compiled. Change i) was  
done  
according to "

> **[TOP 10 Game Bài Đổi Thưởng Uy Tín 2026 - Cẩm Nang Chọn Sân Chơi](https://sourcearchive.com/)**
>
> Khám phá danh sách TOP 10 game bài đổi thưởng uy tín 2026 với công nghệ AI và Blockchain, cùng cẩm nang chọn cổng game an toàn.

".

Anyone has a hint?

Thank you.

Best regards,  
Zamrath N.

PS: First Marcus, The output corresponding to “uhd\_usrp\_probe --args  
addr=192.168.10.2” is,

* * *

## – UHD Device 0

Device Address:  
type: usrp2  
addr: 192.168.10.2  
name:  
serial: F3A31F

On Tue, Apr 7, 2015 at 6:40 PM, Marcus Müller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)