23 Feb
2013
23 Feb
'13
5:02 p.m.
Hi,
I went to pick up my UmTRX this morning. \o/
It appears to start fine, but I'm hitting a couple issues trying to
connect OpenBTS to it:
transceiver won't start
=======================
I get the following errors when starting OpenBTS or the transceiver:
/home/stephane/Public/src/umtrx/openbts-p2.8/apps# ./transceiver
linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.004.000-a52936a
ALERT 139976877029152 UHDDevice.cpp:434:open: No UHD devices found with address
''
ALERT 139976877029152 runTransceiver.cpp:94:main: Transceiver exiting...
/home/stephane/Public/src/umtrx/openbts-p2.8/apps# ./transceiver
linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.004.000-a52936a
ALERT 139853627492128 UHDDevice.cpp:345:set_rates: Failed to set master clock rate
ALERT 139853627492128 UHDDevice.cpp:346:set_rates: Actual clock rate 1.3e+07
ALERT 139853627492128 runTransceiver.cpp:94:main: Transceiver exiting...
(This is with latest UHD from git://github.com/chemeris/UHD-Fairwaves.git
and latest openBTS from git://github.com/ttsou/openbts-p2.8.git )
I assume the first one ('No UHD devices...') is a transcient problem.
For the second issue I don't know whether this might be because the
firmware on the unit I received might not be the latest, or because I
really need to first upload the FPGA image (although I assumed ZPU wouldn't
start in that case); here's the console output in any case:
USRP N210 UDP bootloader
FPGA compatibility number: 8
Firmware compatibility number: 11
Production image = 0
Checking for valid production FPGA image...
No valid production FPGA image found.
Valid production firmware found. Loading...
Finished loading. Starting image.
TxRx-UHD-ZPU
FPGA compatibility number: 8
Firmware compatibility number: 11
LMS1 chip version = 0x22
LMS2 chip version = 0x22
00:1F:11:02:19:01
192.168.10.2
FPGA compilation error
======================
Assuming this is because of a missing/out-of-date FPGA image, I tried to
compile the latest (git) FPGA firmware:
cd UHD-Fairwaves/fpga/usrp2/top/N2x0/ ; make clean ; make UmTRXv2
but got the following error:
ERROR:HDLCompiler:1654 -
"/home/stephane/Public/src/umtrx/UHD-Fairwaves/fpga/usrp2/top/N2x0/u2plus_core.v"
Line 734: Instantiating <rx_frontend_sw> from unknown module <frontend_sw>
A quick `git blame` points to some changes in January but I wouldn't
know where to start fixing this (or maybe this is an issue with my
environemnt and not the code). In case this is the environemnt, I'm using
ISE 14.4 on Linux/amd64.
S.
23 Feb
23 Feb
5:46 p.m.
Hi Stephane,
Glad to see first users starting to play with UmTRX. :)
Please use OpenBTS from our repository and use branch "umtrx" instead
of "master". UmTRX support is not merged into master yet.
git://github.com/fairwaves/openbts-2.8 umtrx
"Failed to set master clock rate" error is thrown because it thinks
you're using USRP N and tries to set frequency accordingly.
FPGA image should be the latest. You could download it here as well:
http://people.osmocom.org/ipse/umtrx-v2/fpga_bitsream/2013-02-03-394f48b7/
We'll look into the FPGA compilation issue - may be Andrew forgot to
check in that file. Thank you for reporting this.
On Sat, Feb 23, 2013 at 8:02 PM, <stephane(a)shimaore.net> wrote:
Hi,
I went to pick up my UmTRX this morning. \o/
It appears to start fine, but I'm hitting a couple issues trying to
connect OpenBTS to it:
transceiver won't start
=======================
I get the following errors when starting OpenBTS or the transceiver:
/home/stephane/Public/src/umtrx/openbts-p2.8/apps# ./transceiver
linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.004.000-a52936a
ALERT 139976877029152 UHDDevice.cpp:434:open: No UHD devices found with address
''
ALERT 139976877029152 runTransceiver.cpp:94:main: Transceiver exiting...
/home/stephane/Public/src/umtrx/openbts-p2.8/apps# ./transceiver
linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.004.000-a52936a
ALERT 139853627492128 UHDDevice.cpp:345:set_rates: Failed to set master clock rate
ALERT 139853627492128 UHDDevice.cpp:346:set_rates: Actual clock rate 1.3e+07
ALERT 139853627492128 runTransceiver.cpp:94:main: Transceiver exiting...
(This is with latest UHD from git://github.com/chemeris/UHD-Fairwaves.git
and latest openBTS from git://github.com/ttsou/openbts-p2.8.git )
I assume the first one ('No UHD devices...') is a transcient problem.
For the second issue I don't know whether this might be because the
firmware on the unit I received might not be the latest, or because I
really need to first upload the FPGA image (although I assumed ZPU wouldn't
start in that case); here's the console output in any case:
USRP N210 UDP bootloader
FPGA compatibility number: 8
Firmware compatibility number: 11
Production image = 0
Checking for valid production FPGA image...
No valid production FPGA image found.
Valid production firmware found. Loading...
Finished loading. Starting image.
TxRx-UHD-ZPU
FPGA compatibility number: 8
Firmware compatibility number: 11
LMS1 chip version = 0x22
LMS2 chip version = 0x22
00:1F:11:02:19:01
192.168.10.2
FPGA compilation error
======================
Assuming this is because of a missing/out-of-date FPGA image, I tried to
compile the latest (git) FPGA firmware:
cd UHD-Fairwaves/fpga/usrp2/top/N2x0/ ; make clean ; make UmTRXv2
but got the following error:
ERROR:HDLCompiler:1654 -
"/home/stephane/Public/src/umtrx/UHD-Fairwaves/fpga/usrp2/top/N2x0/u2plus_core.v"
Line 734: Instantiating <rx_frontend_sw> from unknown module <frontend_sw>
A quick `git blame` points to some changes in January but I wouldn't
know where to start fixing this (or maybe this is an issue with my
environemnt and not the code). In case this is the environemnt, I'm using
ISE 14.4 on Linux/amd64.
S.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
5:48 p.m.
PS We're flying to the Mobile World Congress tonight and may be slow
to respond. I apologize for this - we'll catch up when we get back
after March 4.
On Sat, Feb 23, 2013 at 8:46 PM, Alexander Chemeris
<alexander.chemeris(a)gmail.com> wrote:
Hi Stephane,
Glad to see first users starting to play with UmTRX. :)
Please use OpenBTS from our repository and use branch "umtrx" instead
of "master". UmTRX support is not merged into master yet.
git://github.com/fairwaves/openbts-2.8 umtrx
"Failed to set master clock rate" error is thrown because it thinks
you're using USRP N and tries to set frequency accordingly.
FPGA image should be the latest. You could download it here as well:
http://people.osmocom.org/ipse/umtrx-v2/fpga_bitsream/2013-02-03-394f48b7/
We'll look into the FPGA compilation issue - may be Andrew forgot to
check in that file. Thank you for reporting this.
On Sat, Feb 23, 2013 at 8:02 PM, <stephane(a)shimaore.net> wrote:
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi,
I went to pick up my UmTRX this morning. \o/
It appears to start fine, but I'm hitting a couple issues trying to
connect OpenBTS to it:
transceiver won't start
=======================
I get the following errors when starting OpenBTS or the transceiver:
/home/stephane/Public/src/umtrx/openbts-p2.8/apps# ./transceiver
linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.004.000-a52936a
ALERT 139976877029152 UHDDevice.cpp:434:open: No UHD devices found with address
''
ALERT 139976877029152 runTransceiver.cpp:94:main: Transceiver exiting...
/home/stephane/Public/src/umtrx/openbts-p2.8/apps# ./transceiver
linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.004.000-a52936a
ALERT 139853627492128 UHDDevice.cpp:345:set_rates: Failed to set master clock rate
ALERT 139853627492128 UHDDevice.cpp:346:set_rates: Actual clock rate 1.3e+07
ALERT 139853627492128 runTransceiver.cpp:94:main: Transceiver exiting...
(This is with latest UHD from git://github.com/chemeris/UHD-Fairwaves.git
and latest openBTS from git://github.com/ttsou/openbts-p2.8.git )
I assume the first one ('No UHD devices...') is a transcient problem.
For the second issue I don't know whether this might be because the
firmware on the unit I received might not be the latest, or because I
really need to first upload the FPGA image (although I assumed ZPU wouldn't
start in that case); here's the console output in any case:
USRP N210 UDP bootloader
FPGA compatibility number: 8
Firmware compatibility number: 11
Production image = 0
Checking for valid production FPGA image...
No valid production FPGA image found.
Valid production firmware found. Loading...
Finished loading. Starting image.
TxRx-UHD-ZPU
FPGA compatibility number: 8
Firmware compatibility number: 11
LMS1 chip version = 0x22
LMS2 chip version = 0x22
00:1F:11:02:19:01
192.168.10.2
FPGA compilation error
======================
Assuming this is because of a missing/out-of-date FPGA image, I tried to
compile the latest (git) FPGA firmware:
cd UHD-Fairwaves/fpga/usrp2/top/N2x0/ ; make clean ; make UmTRXv2
but got the following error:
ERROR:HDLCompiler:1654 -
"/home/stephane/Public/src/umtrx/UHD-Fairwaves/fpga/usrp2/top/N2x0/u2plus_core.v"
Line 734: Instantiating <rx_frontend_sw> from unknown module <frontend_sw>
A quick `git blame` points to some changes in January but I wouldn't
know where to start fixing this (or maybe this is an issue with my
environemnt and not the code). In case this is the environemnt, I'm using
ISE 14.4 on Linux/amd64.
S.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
6:14 p.m.
Hi Alexander,
We'll look into the FPGA compilation issue - may
be Andrew forgot to
check in that file. Thank you for reporting this.
FWIW the issue appears with d7628bcd0b562f8a3be02eb52acc2f5e0a541c33 ;
commit 9d67877209fa5f92d0858ad041be198bd0262045 doesn't have the issue.
I'll go ahead and recompile openBTS using your version. Thank you!
S.
6:23 p.m.
Hi Stephane,
On Sat, Feb 23, 2013 at 9:14 PM, <stephane(a)shimaore.net> wrote:
Btw, do you have experience with Xilinx FPGAs programming? We have an
issue with ICAP which prevents us to use a "production" FPGA bitstream
- right now we use only "safe" bistream. It's not a critical issue and
thus we haven't looked into it deeply, but it would be very convenient
to have it working. If you feel like you could do that, I'll explain
it in more details.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
We'll look
into the FPGA compilation issue - may be Andrew forgot to
check in that file. Thank you for reporting this.
FWIW the issue appears with d7628bcd0b562f8a3be02eb52acc2f5e0a541c33 ;
commit 9d67877209fa5f92d0858ad041be198bd0262045 doesn't have the issue.
9:22 p.m.
I'll go ahead and recompile openBTS using your
version. Thank you!
That worked out rather smoothly. I can see the '00101' GSM network on my
phone and OpenBTS attempts to SIP REGISTER when I choose it on the
phone.
Here are my notes, I'll be posting further updates there as well:
http://blog.shimaore.net/2013/02/umtrx.html
Hope this helps.
Next steps for me are to setup FreeSwitch (and maybe OpenSIPS) so that I
can start testing calls.
Question: I used RX1 and TX1 on the board to connect the antennae, but
`transceiver` says "using transmit antenna RX1" and "using receive antenna
TX2", does that mean I should use RX1/TX2 instead, or is this a
configuration parameter I should modify in OpenBTS.db?
S.
PS: Congratulations to everyone involved in making this so painless!
Eight hours (lunch included) from unpacking to being able to see the MNC
show up on a phone is _very_ nice.
5 Mar
5 Mar
2:32 p.m.
Hi Stephane,
I'm back from MWC, catching up with the mailing list.
On Sun, Feb 24, 2013 at 12:22 AM, <stephane(a)shimaore.net> wrote:
Nice stuff!
Though I should note that FPGA and ZPU compilation and flashing is not
needed in most cases. UmTRX comes pre-flashed and should not need all
those cumbersome steps.
I'll go
ahead and recompile openBTS using your version. Thank you!
That worked out rather smoothly. I can see the '00101' GSM network on my
phone and OpenBTS attempts to SIP REGISTER when I choose it on the
phone.
Here are my notes, I'll be posting further updates there as well:
http://blog.shimaore.net/2013/02/umtrx.html
Hope this helps. Next steps for me are to setup FreeSwitch (and maybe
OpenSIPS) so that I
can start testing calls.
Thank you for your patch to make it working with OpenSIPS :) Looking
forward for more contributions to the SIP side of things. They're need
quite some attention, as you already noticed.
One idea is to have a normal state machines for SIP, independent from
GSM state machines. Current tightly coupled integration between SIP
and GSM states makes both sides to break in various cases. I even
thought about completely replacing oSIP with a library which already
implements SIP state machines, like Sofia-SIP. But this requires
research on whether we'll be able to implement things which require
non-standard behavior, like handover. Thoughts on this topic are
welcome.
Question: I used RX1 and TX1 on the board to connect
the antennae, but
`transceiver` says "using transmit antenna RX1" and "using receive
antenna
TX2", does that mean I should use RX1/TX2 instead, or is this a
configuration parameter I should modify in OpenBTS.db?
Sorry for the confusion. TX1/RX1 label on the board refer to RX/TX of
the channel 1. While in the software channel 1 is referred to as
"daughter board A" and RX1 means we use LNA1 input on LMS chip.
In other words, there are two LMS chips on UmTRX:
channel 1 (daughter board A) - RX1, TX1, SCN1 labels on a PCB
channel 2 (daughter board B) - RX2, TX2, SCN2 labels on a PCB
And each LMS chip has RX1, RX2, RX3 inputs and TX1, TX2 outputs
("antennas" in software) with the following mapping:
RX1 (software) = RXn (PCB label)
RX2 (software) = not connected on the PCB
RX3 (software) = SCNn (PCB label)
TX1 (software) = not connected on the PCB
TX2 (software) = TXn (PCB label)
PS: Congratulations to everyone involved in making
this so painless!
Eight hours (lunch included) from unpacking to being able to see the MNC
show up on a phone is _very_ nice.
Thank you!
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
6 Mar
6 Mar
1:20 a.m.
Hi Alexander,
Hope you guys made some interesting contacts while in Spain.
Though I should note that FPGA and ZPU compilation and
flashing is not
needed in most cases. UmTRX comes pre-flashed and should not need all
those cumbersome steps.
Yup, changed my page to indicate that as well. (Although really I should
be updating the wiki.)
Thank you for your patch to make it working with
OpenSIPS :) Looking
forward for more contributions to the SIP side of things.
My line of thought is to use OpenSIPS as registrar, with a Redis
backend. Then use OpenSIPS to route calls, SMS, .. based on the IMSI.
I even thought about completely replacing oSIP with a
library which
already implements SIP state machines, like Sofia-SIP. But this requires
research on whether we'll be able to implement things which require
non-standard behavior, like handover.
If we are to keep the strong coupling (with OpenBTS a thin
layer between GSM and SIP), the SIP stack can remain pretty simple (with
some level of equivalence between GSM and SIP messages); in that case the
SIP call handling intelligence will be deported to other tools (OpenSIPS,
FreeSwitch, Yate, ...): OpenBTS won't be able to do things like handover
or roaming on its own, the call control will belong in those external
servers, but that's what they were designed to do (and OpenBTS remains
a manageable project).
However, in that case, SIP might not be the best protocol, since
the model is more of a call-agent / gateway relationship (so something
better suited to, e.g., MGCP). Or we need to defined a subset of SIP that
matches that call-agent / gateway relationship carefully.
On the other hand if OpenBTS is to be a full-flegde User-Agent (UA) this
will require a strong SIP stack like sofia-sip, and handling a lot of
"exception cases" inside OpenBTS (SIP is a piece of work). This means
an amount of work similar to that required to write Asterisk, FreeSwitch,
or Yate.
Maybe in that case it's simpler to (re)implement OpenBTS as, e.g., a
FreeSwitch "endpoint" than trying to re-invent a new SIP UA.
About handover:
With regards to Dmitri's handover proposal[1], I can imagine that in
some contexts (large cities?) handover might be a common occurrence and
keeping the call pinned in one (or more?) OpenBTS might cause scalability
or audio quality issues. (This would especially be the case if multiple
handovers mean traversing multiple OpenBTS.)
[1] http://wush.net/trac/rangepublic/wiki/Handover
Also I can imagine that we might eventually want to do GSM-to-WiFi
back to-GSM type of handovers (or is that what GSM would consider
roaming?). I don't know whether there are existing procedures to handle
this?
RX1 (software) = RXn (PCB label)
RX3 (software) = SCNn (PCB label)
TX2 (software) = TXn (PCB label)
OK, that was the missing translation table. I guess I could look at the
hardware schematics when I have hardware questions. :)
S.
23 Feb
23 Feb
9:55 p.m.
Hi Stephane,
Thank you very much for your comment. It's my fault. I forgot to add a line
to the fpga/usrp2/sdr_lib/Makefile.srcs. I fixed this error. To
successfully compile the FPGA project, you will need to update your local
repository from github.
2013/2/23 <stephane(a)shimaore.net>
FPGA compilation error
======================
Assuming this is because of a missing/out-of-date FPGA image, I tried to
compile the latest (git) FPGA firmware:
cd UHD-Fairwaves/fpga/usrp2/top/N2x0/ ; make clean ; make UmTRXv2
but got the following error:
ERROR:HDLCompiler:1654 -
"/home/stephane/Public/src/umtrx/UHD-Fairwaves/fpga/usrp2/top/N2x0/u2plus_core.v"
Line 734: Instantiating <rx_frontend_sw> from unknown module <frontend_sw>
A quick `git blame` points to some changes in January but I wouldn't
know where to start fixing this (or maybe this is an issue with my
environemnt and not the code). In case this is the environemnt, I'm using
ISE 14.4 on Linux/amd64
Regards,
Andrew Karpenkov
4078
days inactive
4089
days old
8 comments
3 participants
participants (3)
-
Alexander Chemeris -
Andrew Karpenkov -
stephane＠shimaore.net