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.
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@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
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@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@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
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
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.
Hi Stephane,
On Sat, Feb 23, 2013 at 9:14 PM, stephane@shimaore.net wrote:
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.
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.
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.
Hi Stephane,
I'm back from MWC, catching up with the mailing list.
On Sun, Feb 24, 2013 at 12:22 AM, stephane@shimaore.net wrote:
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.
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.
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
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.
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@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
-
Alexander Chemeris -
Andrew Karpenkov -
stephane＠shimaore.net