Hi all!
Here last version PCB of UmTRXv2.
In the next e-mail I'll include project files and cheapest BOM for debug
variant.
I think it is final, because of nobody desire to say me any suggestions
(except Robin).
Best regards,
Andrey Sviyazov.
Hi Thomas,
If we get a UmTRX to you, could you make OpenBTS to run with it
quickly, like before the end of the month? No matter how hackish the
solution would be. We just need a way to start testing the hardware
performance in a more real situation. Then we could target a cleaner
solution.
To recap - right now we could transmit on a single channel, and
receive on both channels, but the control of LMS chips is done by an
external python script. I.e. to tune and set bandwidth, gain, etc you
have to run this script before claiming a device with UHD.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
On Mon, Jun 18, 2012 at 5:32 AM, Thomas Tsou <thomastsou(a)gmail.com> wrote:
> On Mon, Jun 11, 2012 at 7:12 AM, Alexander Chemeris
> <alexander.chemeris(a)gmail.com> wrote:
>> On Mon, Jun 11, 2012 at 4:08 AM, Thomas Tsou <thomastsou(a)gmail.com> wrote:
>>> If the load drops down and the signal transmits, I wouldn't worry
>>> about it for now. The likely condition is that there is a offset
>>> between the initial arriving timestamp and the expected timestamp.
>>> Because the receive timestamps drive the transceiver, the receiver may
>>> run at 100% until the timestamp and expected value align. If OpenBTS
>>> transmits consistently, then the system is in sync.
>>
>> Aah! Yes, we have some issue with setting the timestamp with UmTRX.
>> E.g. I had to modify UHD examples which set timestamp to 0 on startup
>> and rely on this later on. With my change they read the actual value
>> of the timestamp and start from that. Could we do the same for
>> OpenBTS?
>
> I'm running into this issue now, which was the reason I wasn't always
> seeing transmit output. Workaround patch is attached along with the
> corrected 'normal' rate GSM signal.
Thanks for the patch! I think we could push it to the OpenBTS repom as
it doesn't harm anyone?
Sylvain - with your great debugging abilities, could you find the
cause for this bug without too much trouble? To me it looks like the
bug is in FPGA firmware, i.e. something went wrong with the VITA timer
control when we changed frequencies of the DSP part of the FPGA. The
bug is not critical, but is really annoying, because you have to
change all UHD utils to avoid setting a timestamp before use.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi all,
I've cleaned up our git branches to make sure everyone are on the same
page. Now a stable code (if could say so) is in 'fairwaves/umtrx'
branch. I.e. you should build FPGA image, ZPU firmware and UHD host
code from this branch. Other branches are topic branches, owned and
maintained by respective developers for their very own purposes and
you're not warranted from any consequences of using them, including,
but not limited to disappearance of your cat.
(I apologize for the language - just finished reading a 15 page long contract)
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
