Hi Will,
Thank you for the good news. Answering to your question, first please
update your UmTRX firmware and host side UHD:
1. Update your UHD and umtrx_scripts from the git. Build UHD.
2. Flash attached ZPU firmware to a UmTRX with the following command:
./usrp_n2xx_net_burner.py --addr=192.168.10.2 --fw=usrp2p_txrx_uhd.bin
3. Power cycle UmTRX
Calibrate with GPS:
1. Take your UmTRX outside to get GPS lock.
2. When GPS acquires a lock, use 'umtrx_vcxo.py' utility without
parameters to read current VCTCXO DAC value in a loop.
3. When the value stabilise (couple minutes after GPS acquires the
lock), write this value to EEPROM:
./usrp_burn_mb_eeprom --key tcxo-dac --val <YOUR_VAL>
4. Now i should pickup the value from EEPROM on boot, so GPS is no
required unless you change ambient temperature considerably.
Note, that you should warm up your UmTRX for a while before
calibration, because it depends on the TCXO temperature.
Let me know if something goes wrong - I wasn't able to test
everything, as I don't have my UmTRX with me at the moment.
On Tue, May 21, 2013 at 9:50 PM, Will Hawkins
<hawkinsw(a)opentechinstitute.org> wrote:
> Hey Alexander!
>
> Yesterday we took our umtrx outside to get the GPS lock for calibrating the
> tcxo voltage. There were some good outcomes and bad outcomes:
>
> The good:
> If you remember correctly, Dan could not associate to the umtrx with his
> Galaxy Nexus. After getting a GPS signal, Dan's phone could associate! So,
> great news.
>
> The bad:
> We attempted to record the calibrated tcxo dac values and had no luck. We
> booted the umtrx board connected via serial console to my laptop. I was able
> to see the boot messages and other output so I know the console was working.
> Once the board got a GPS lock, I assumed that I would see some tcxo DAC
> values printed to the console. Based on what you said last week, I was going
> to wait until those values stabilized and then use that output to flash into
> the eeprom. Unfortunately I did not see any output on the serial console.
> Then I thought that we could poll the umtrx (using UHD probe) for its tcxo
> dac values. Unfortunately it showed the default (2048) every time.
>
> Can you tell me what I'm doing wrong?
>
> Thanks!
> Will
>
> PS: CC'ing Dan since he's working this with me.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi All,
I wish to work with the Synchronize Sram and to connect it to the FPGA
Microblaze.
Does anyone was able to use and communicate with the SRAM?
If so, can U help with the configuration of the EMC?
I read the EMC datasheet and they describe different way for connecting the
EMC with the SRAM. Maybe U know on a problem when working with SRAM?
thanks in advance,
Yaniv
Hi to All
I am trying to implement Xilinx microblaze on the umtrx2 with EMC core that
connect to the external SRAM. I configured the EMC to Synchronous mode and
I used the UCF that is published at the GITHUB. If I am trying to deluge
the MCU without the EMC the MCU seem running, but when I connect the EMC,
the MCU stuck and I cannot download the code through the JTAG.
Please advise how to connect the EMC core to the external SRAM ?
thanks in advance,
Yaniv
Hello team,
I met in Paris with Jean-Samuel last Friday. We talked among other
things about handover in OpenBTS and I wanted to share some of our ideas
with you.
Note: this is my recollection of things, if I misreported something it's
my fault. :}
# Handling SIP intricacies outside of OpenBTS
We both agreed that it is better/simpler to keep the complexity of SIP
protocol out of OpenBTS. There are already very good platforms that can
hide the intricacies of SIP from OpenBTS (FreeSwitch, Asterisk, OpenSIPS
B2BUA, etc.). The alternative (implementing a complete, compliant B2BUA
SIP stack inside OpenBTS) seems difficult (complete rewrite using e.g.
sofia-sip) and doesn't help with time-to-market.
We also both enjoy the "GSM handset looks like a SIP endpoint" analogy
that is the basis of OpenBTS and would like to keep the OpenBTS
GSM-to-SIP interface as transparent as possible.
(Apologies for cross-posting. We wanted to reach everyone who might be
interested in attending. Please respond responsibly.)
Anders Brownworth (Switchcoder), Alexander Chemeris (Fairwaves), and Robin
Coxe (Close-Haul Communications & Analog Devices) invite those interested
in open GSM hardware and software development to an informal gathering in
Cambridge, MA on Friday 10 May 2013 from 6-8 pm. Alexander will be
visiting the Boston area from Moscow.
If you are interested in participating in any capacity in the Boston-area
open source GSM development community, we look forward to meeting you. Our
goal is to identify like-minded people involved in or interested in
learning more about projects such as OpenBTS, OsmocomBTS, OsmocomBB, and
OpenBSC. If you have a portable, self-contained demo, feel free to bring
it with you.
When: Friday 10 May 2013, 6-8 pm EDT
Where: Cambridge Innovation Center, 1 Broadway, 4th Floor, Cambridge, MA
02142 USA
Photo ID required for building entry.
Please RSVP on Eventbrite: http://opengsmboston.eventbrite.com/
