Hi guys,
Could anyone tell me, the software guy, what may be the purpose of
VCOREG block in LMS6002D (Figure 3.4 at the Programming Guide)? In our
current code it's always powered down and not used, and I just wonder
whether it could be used for frequency hopping and what are other
potential uses. If I understand correctly, it's a kind of fine tuning
for the PLL output frequency.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi,
Very nice to see the progress UmRTX.
I checked out the git found the GPS 1pps signal was terminated to
FPGA, and wonder how the discipline algorithm was implemented. Someone
would give me a hint or introductory?
thanks in advance.
Regards.
Jerry
Hi Thomas,
I recall you had some patch to add a second Tx channel to the host
UHD. Could you push it to git or send as a patch here? We're testing
dual-channel FPGA firmware now and it would be of good help.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi all,
I've started putting together a ToDo list for UmTRX features which are
missing support on the host side or the FPGA side. I invite everyone
to add more tickets, fill details in existing tickets and discuss
implementation strategies in comments.
You could use this filter in our issues tracker to select at the tasks
open at the moment:
http://code.google.com/p/umtrx/issues/list?can=2&q=label%3AComponent-Host
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Andrey Sviyazov,
How much space do we have in the EEPROM right now?
I'm thinking which calibration data we could store there and which we
should store on a host.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi all,
Today we've received first units of UmTRXv2 from a fab. The unit is lovely
to look at - find the picture attached. I hope it will show no less great
performance when we turn it on.
In addition to fixed bugs this version has following major changes. I may
have forgotten something, but these are the most important changes:
* better form factor (10x16cm Eurocard)
* doesn't have RF switches on board (the're moved to a frontend for higher
flexibility)
* newer GPS module (EB-570)
* U.FL connectors by default (to simplify automated mounting)
* optional connector for external front panel (for waterproof casing)
* tantalum capacitors instead everywhere (for longer life)
* wider input power voltage range (8-28VDC)
We consider this version as pre-production. I.e. it will go into production
if there are no serious bugs. Now our task is to bring up the board and
check for all possible bugs before we go forward.
PS White squares on the picture is not because we obscure the photo - it's
white thermal pads which the fab placed atop of chips instead of placing
them at the bottom of PCB.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi Daud,
I've copied the mailing list, as I believe the question belongs there.
On Wed, Sep 19, 2012 at 1:20 AM, Daud Suleiman <msdaudi(a)gmail.com> wrote:
> I am very excited and glad and happy for the UmTRX project. I would like to
> know if you have plans for stacking capability for the RF frontend. I am
> assuming that there is only 2TXs. Int he event that a client needs more TXs,
> say 12TXs, have you any plans to stack as many RF frontends and or UmTRXs?
Yes, we have an option to stack UmTRX'es, but it is only to share
clock source and/or GPS source, i.e. you still have to connect each
UmTRX to the Ethernet. As long as connecting to an Ethernet switch
works fine, so we don't see this as an issue.
Later we may consider implementing true stacking when stacked units
share Ethernet port, like with USRPs. This might be a useful endeavor,
but we don't want to dive into this until we have everything else
settled.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi all,
Some good news for today. We've had a small fairwaves hackathon here
in Moscow and we've done a good progress in UmTRX development. I'm
quite exhausted, thus in short:
1. A software issue has been fixed in PLL tuning code. It works
reliably now. Previously it didn't correctly handle edge cases when
the best VCOCAP value was at the end of a range.
2. A software issue has been fixed in automatic LMS calibration code.
Turns out a process described in the datasheet is not complete - you
have read FAQ, question 4.7 for an amendment.
3. Now we correctly select Rx input. You have to change _two_
registers to do that - 0x75 and 0x25. This wasn't obvious from the
brief reading of the manual.
4. A hardware bug was fixed - RF diversity switch required a bias to
work correctly. Luckily we decided to move the switch from the main
board to a frontend in the rev2 of UmTRX. So we don't have to re-make
the UmTRX schematics.
Huge thanks to Andrey Sviyazov ("RF guy"), Andrew Karpenkov ("FPGA
guy") and Srdjan Milenkovic ("remote LimeMicro guy") for going through
all the issues.
Fixes for the code will be pushed to github in the next few days after
I clean it up.
PS Another good news is that we should have first UmTRXv2 units on
hands in the next few days, when we get them from customs. Can't wait
to put my hands on them.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Thomas,
Do you have an idea why we get this messages when running OpenBTS?
Also we configured OpenBTS to output all received bursts to a screen
and it looks like it starts receiving a lot of noise. Then this noise
almost stops and shows only sometimes.
$ tail -f syslog
Sep 6 19:13:16 kluchnikov transceiver:
ERR 3043572592 UHDDevice.cpp:785:recv_async_msg: An internal send buffer
has emptied at 826.035 sec.
Sep 6 19:13:16 kluchnikov transceiver:
ERR 3043572592 UHDDevice.cpp:785:recv_async_msg: Packet time was too late
or too early at 826.037 sec.
Sep 6 19:13:47 kluchnikov transceiver:
ERR 3043572592 UHDDevice.cpp:785:recv_async_msg: An internal send buffer
has emptied at 856.255 sec.
Sep 6 19:13:47 kluchnikov transceiver:
ERR 3043572592 UHDDevice.cpp:785:recv_async_msg: Packet time was too late
or too early at 856.257 sec.
Sep 6 19:13:47 kluchnikov transceiver:
ERR 3043572592 UHDDevice.cpp:785:recv_async_msg: Packet time was too late
or too early at 856.257 sec.
Sep 6 19:14:04 kluchnikov transceiver:
ERR 3043572592 UHDDevice.cpp:785:recv_async_msg: An internal send buffer
has emptied at 874.005 sec.
Sep 6 19:14:04 kluchnikov transceiver:
ERR 3043572592 UHDDevice.cpp:785:recv_async_msg: Packet time was too late
or too early at 874.009 sec.
Sep 6 19:14:04 kluchnikov transceiver:
ERR 3043572592 UHDDevice.cpp:785:recv_async_msg: Packet time was too late
or too early at 874.009 sec.
Sep 6 19:14:07 kluchnikov transceiver:
ERR 3043572592 UHDDevice.cpp:785:recv_async_msg: An internal send buffer
has emptied at 877.01 sec.
Sep 6 19:14:07 kluchnikov transceiver:
ERR 3043572592 UHDDevice.cpp:785:recv_async_msg: Packet time was too late
or too early at 877.013 sec.
Sep 6 19:14:07 kluchnikov transceiver:
ERR 3043572592 UHDDevice.cpp:785:recv_async_msg: Packet time was too late
or too early at 877.013 sec.
Sep 6 19:14:09 kluchnikov transceiver:
ERR 3043572592 UHDDevice.cpp:785:recv_async_msg: An internal send buffer
has emptied at 878.466 sec.
Sep 6 19:14:09 kluchnikov transceiver: ERR 3043572592
UHDDevice.cpp:785:recv_async_msg: Packet time was too late or too early at
878.468 sec.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi All,
I added control logic of LMS reset pins into ZPU firmware (commit
25a89e337b98f89d542a8bd51a3bfb6dc2a9f441
<https://github.com/chemeris/UHD-Fairwaves/commit/25a89e337b98f89d542a8bd51a…>at
the akarpenkov/dual-channel branch).
I need to take control under Diversity switches and LMS reset pins from
host. As I understand, python script "umtrx_ctrl.py" is not able write FPGA
registers, it's can talk only with SPI devices.
Max, Sylvain or anyone else, can you help me get access to FPGA registers
(they connected to wishbone bus) from host? I'm not very good at
programming on python..
UHD can do this (example here: host\lib\usrp\usrp2\usrp2_impl.cpp:530).
Also I added second RX and TX channels to the FPGA firmware and according
with that changed memory maps in ZPU and HOST firmwares (all changes at
the akarpenkov/dual-channel branch on github).
Work of TX and RX DSP 2 units I can't check due to complete lack of support
in the HOST software. Could anyone make needed changes at HOST firmware?
Regards,
Andrew Karpenkov
