This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/UmTRX@lists.osmocom.org/.
Alexander Chemeris alexander.chemeris at gmail.comOn Mon, Jun 11, 2012 at 4:08 AM, Thomas Tsou <thomastsou at gmail.com> wrote: > On Sun, Jun 10, 2012 at 10:05 AM, Alexander Chemeris > <alexander.chemeris at gmail.com> wrote: >> OpenBTS starts with this change: >> >> diff --git a/Transceiver52M/UHDDevice.cpp b/Transceiver52M/UHDDevice.cpp >> index d4ba580..4baf824 100644 >> --- a/Transceiver52M/UHDDevice.cpp >> +++ b/Transceiver52M/UHDDevice.cpp >> @@ -48,7 +48,8 @@ >> >> tx_ampl - Transmit amplitude must be between 0 and 1.0 >> */ >> -const double master_clk_rt = 52e6; >> +//const double master_clk_rt = 52e6; >> +const double master_clk_rt = 13e6; >> const size_t smpl_buf_sz = (1 << 20); >> const float tx_ampl = .3; >> >> But the behavior is a bit strange - when I start OpenBTS transceiver >> starts to consume 100% of CPU and doesn't transmit. After a while (a >> minute or so) CPU usage drops and I start seeing a signal at the UmTRX >> output. I had no time to look into this deeply. > > 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? We have to track down this bug in FPGA, as it's quite annoying. :( May that's something Robin or Sylvain could take on? >>> Can you transmit a beacon signal? >> >> Yes. I could see the network with a phone. Signal hound pictures: >> 1) umtrx-openbts-spectrum.PNG - spectrum, generated by OpenBTS. >> 2) umtrx-openbts-timeslots.PNG - the same, but with zero span. >> 3) "GMSK VGA1 -5, VGA2 18, channel power 750kHz.PNG" and >> "Tx_GMSK#6(hot)_240412.png" are spectrum of a pure continuous GMSK >> signal, transmitted with UmTRX (captured by me and Andrey Sviyazov). > > Signals look great! Glad you like it :) >> Actually I should just try to run it - may be it will work right away? :) > > Yes, check for RACH bursts. The bursts will probably get rejected if > they arrive at GSM core due to timing offset, but that is an easy fix. Yep, will do at Wed when I get back to Moscow. Do you have a patchset to enable all needed debug settings for this? > Have you verified reception of a receive test signal? Andrew Karpenkov should have done that. I personally haven't tried yet. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru