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/.
Thomas Tsou thomastsou at gmail.comHi Alexander, I spent some time with UmTRX today and, after a number of tries, got the FPGA and firmware code in the fairwaves/umtrx-dboard branch running. I build the bootloader.rmi into the fpga image and loaded through JTAG. Some observations and questions so far: The UmTRX identifies and comes up fine, but I'm having some tuning difficulties on LMS 1 with the following command sequence. I don't get the same output on LMS 2. Do I need to make any other changes? Register dump attached. === LMS 1 === $ ./umtrx_lms.py --lms 1 --lms-init $ ./umtrx_lms.py --lms 1 --lms-tx-enable 1 $ ./umtrx_lms.py --lms 1 --lms-tx-pll-tune 900e6 FREQSEL=62 VCO_X=8 NINT=276 NFRACK=7743330 VOVCO[0]=1 VOVCO[1]=1 VOVCO[2]=1 ... VOVCO[62]=1 VOVCO[63]=1 CAN'T TUNE === LMS 2 === ./umtrx_lms.py --lms 2 --lms-tx-pll-tune 900e6 FREQSEL=62 VCO_X=8 NINT=276 NFRACK=7743330 VOVCO[0]=2 VOVCO[1]=2 VOVCO[2]=2 ... VOVCO[62]=1 VOVCO[63]=1 START=45 STOP=50 SET=47 Also, what is the status of storing to flash with usrp_n2xx_net_burner.py? The firmware appears to write successfully, but the FPGA image times out after 'Verifying data'. I suppose this part is not essential right now, but it would be convenient because I otherwise need to borrow a JTAG adapter. Working with Xilinx tools in Linux is very frustrating, but I guess that is old news. ISE 13.3 kept crashing until I installed it in a virtual machine. That was the worst part. Thomas On Mon, Jun 11, 2012 at 7:12 AM, Alexander Chemeris <alexander.chemeris at gmail.com> wrote: > On 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: lms_reg_dump.log Type: application/octet-stream Size: 4191 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20120616/cb8299b9/attachment.obj>