From andreysviyaz at gmail.com Tue Jun 5 21:35:17 2012 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Tue, 5 Jun 2012 23:35:17 +0200 Subject: UmTRXv2 final project Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UmTRXv2pcb (05.06.2012 23-19-20).zip Type: application/zip Size: 5044887 bytes Desc: not available URL: From andreysviyaz at gmail.com Tue Jun 5 21:37:47 2012 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Tue, 5 Jun 2012 23:37:47 +0200 Subject: UmTRXv2 final project In-Reply-To: References: Message-ID: Here included project files and cheapest BOM for debug variant. Best regards, Andrey Sviyazov. 2012/6/5 Andrey Sviyazov > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UmTRXv1b_prj (29.05.2012 2-59-49).zip Type: application/zip Size: 1478450 bytes Desc: not available URL: From andreysviyaz at gmail.com Tue Jun 5 21:44:01 2012 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Tue, 5 Jun 2012 23:44:01 +0200 Subject: UmTRXv2 final project In-Reply-To: References:

Message-ID: Sorry for my crooked hands :) Final project files and cheapest BOM for debug variant included here. Best regards, Andrey Sviyazov. 2012/6/5 Andrey Sviyazov > Here included project files and cheapest BOM for debug variant. > > Best regards, > Andrey Sviyazov. > > > > 2012/6/5 Andrey Sviyazov > >> 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. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UmTRXv2prj (05.06.2012 23-17-45).zip Type: application/zip Size: 2268660 bytes Desc: not available URL: From jsn at bjtpartners.com Tue Jun 5 22:54:17 2012 From: jsn at bjtpartners.com (Jean-Samuel Najnudel - BJT PARTNERS SARL) Date: Wed, 6 Jun 2012 00:54:17 +0200 Subject: UmTRXv2 final project In-Reply-To: References:

Message-ID: Hi Andrey, Thank you very much for these files. Thanks a lot for this great work. Just a question, what do you mean by "cheapest BOM for debug variant" ? Best regards. Jean-Samuel. :-) On Tue, Jun 5, 2012 at 11:44 PM, Andrey Sviyazov wrote: > Sorry for my crooked hands :) > Final project files and cheapest BOM for debug variant included here. > > Best regards, > Andrey Sviyazov. > > > > 2012/6/5 Andrey Sviyazov > >> Here included project files and cheapest BOM for debug variant. >> >> Best regards, >> Andrey Sviyazov. >> >> >> >> 2012/6/5 Andrey Sviyazov >> >>> 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. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreysviyaz at gmail.com Tue Jun 5 23:02:16 2012 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Wed, 6 Jun 2012 01:02:16 +0200 Subject: UmTRXv2 final project In-Reply-To: References:

Message-ID: Hi Jean-Samuel. I decide to add SMD LED's to the project just to have cheap variant but for debug only. I am glade that this variant will be useful for you. Best regards, Andrey Sviyazov. (Sent from my mobile client) 06.06.2012 0:54 ???????????? "Jean-Samuel Najnudel - BJT PARTNERS SARL" < jsn at bjtpartners.com> ???????: > Hi Andrey, > > Thank you very much for these files. Thanks a lot for this great work. > Just a question, what do you mean by "cheapest BOM for debug variant" ? > > Best regards. > > Jean-Samuel. > :-) > > > On Tue, Jun 5, 2012 at 11:44 PM, Andrey Sviyazov wrote: > >> Sorry for my crooked hands :) >> Final project files and cheapest BOM for debug variant included here. >> >> Best regards, >> Andrey Sviyazov. >> >> >> >> 2012/6/5 Andrey Sviyazov >> >>> Here included project files and cheapest BOM for debug variant. >>> >>> Best regards, >>> Andrey Sviyazov. >>> >>> >>> >>> 2012/6/5 Andrey Sviyazov >>> >>>> 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. >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Sat Jun 9 13:30:10 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 9 Jun 2012 17:30:10 +0400 Subject: UmTRX integration with OpenBTS Message-ID: 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 From andreysviyaz at gmail.com Sun Jun 10 00:43:29 2012 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Sun, 10 Jun 2012 04:43:29 +0400 Subject: UmTRXv2 final project In-Reply-To: References: Message-ID: Hi all! Here final project UmTRXv2 @ 10/06/2012 (PcbDoc file will be attached to the next e-mail). Jean-Samuel, please check SMD LED's placed at the front edge of the PCB. If you agree with this variant then I'll generate Gerber files vs required layers and description to produce PCB. If anybody find any mistake, please inform me immediatelly. Best regards, Andrey Sviyazov. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UmTRXv2_Proj (10.06.2012 4-16-25).zip Type: application/zip Size: 2275157 bytes Desc: not available URL: From andreysviyaz at gmail.com Sun Jun 10 00:46:35 2012 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Sun, 10 Jun 2012 04:46:35 +0400 Subject: UmTRXv2 final project In-Reply-To: References:

Message-ID: Here PcbDoc @ 10/06/2012. Best regards, Andrey Sviyazov. 2012/6/10 Andrey Sviyazov > Hi all! > > Here final project UmTRXv2 @ 10/06/2012 (PcbDoc file will be attached to > the next e-mail). > Jean-Samuel, please check SMD LED's placed at the front edge of the PCB. > If you agree with this variant then I'll generate Gerber files vs required > layers and description to produce PCB. > If anybody find any mistake, please inform me immediatelly. > > Best regards, > Andrey Sviyazov. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UmTRXv2_PcbDoc (10.06.2012 4-15-02).zip Type: application/zip Size: 5001581 bytes Desc: not available URL: From thomastsou at gmail.com Sun Jun 10 00:58:41 2012 From: thomastsou at gmail.com (Thomas Tsou) Date: Sat, 9 Jun 2012 20:58:41 -0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References: Message-ID: On Sat, Jun 9, 2012 at 9:30 AM, Alexander Chemeris wrote: > 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. FYI, I was finishing plans to attend the openhere festival in Dublin at the end of the month. That is in two weeks. What is the state of OpenBTS integration right now? Can you transmit a beacon signal? If UmTRX can support tuning, gain, and full duplex streaming with the existing UHD timestamp interface, then it shouldn't take long for OpenBTS. I can use any reasonable sample rate for testing. Is the external python script in a repository? Thomas From alexander.chemeris at gmail.com Sun Jun 10 14:05:07 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 10 Jun 2012 18:05:07 +0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: Hi Thomas, On Sun, Jun 10, 2012 at 4:58 AM, Thomas Tsou wrote: > On Sat, Jun 9, 2012 at 9:30 AM, Alexander Chemeris > wrote: >> 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. > > FYI, I was finishing plans to attend the openhere festival in Dublin > at the end of the month. That is in two weeks. Oh, that's great! So hopefully see you there! Andrey Sviyazov is going to be there as well. > What is the state of OpenBTS integration right now? 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. > 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). > If UmTRX can support tuning, gain, and full duplex > streaming with the existing UHD timestamp interface, then it shouldn't > take long for OpenBTS. Great! Actually I should just try to run it - may be it will work right away? :) > I can use any reasonable sample rate for testing. FYI: We use 13MHz > Is the external python script in a repository? Yes. https://github.com/chemeris/UHD-Fairwaves/blob/fairwaves/umtrx-dboard/host/utils/umtrx_lms.py Not everything is implemented, but it's easy to amend it. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: GMSK VGA1 -5, VGA2 18, channel power 750kHz.PNG Type: image/png Size: 100230 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Tx_GMSK#6(hot)_240412.png Type: image/png Size: 48404 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: umtrx-openbts-spectrum.PNG Type: image/png Size: 92670 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: umtrx-openbts-timeslots.PNG Type: image/png Size: 89702 bytes Desc: not available URL: From jsn at bjtpartners.com Sun Jun 10 22:15:20 2012 From: jsn at bjtpartners.com (Jean-Samuel Najnudel - BJT PARTNERS SARL) Date: Mon, 11 Jun 2012 00:15:20 +0200 Subject: UmTRXv2 final project In-Reply-To: References:

Message-ID: Hi Andrey, Thank you very much for the project documents. Thanks a lot for the changes. I really think SMD LEDs at PCB front edge can be an effective, convenient and cheap solution. Anyway, these project files looks fine for me. If everybody can double check and confirm everything is ok, please generate all the files we need. I will send these to the fab and start to move forward to the prototype production process with them. Really, thanks a lot for this work. I am really glad we can move forward to production. This is really great. Best regards. Jean-Samuel. :-) On Sun, Jun 10, 2012 at 2:46 AM, Andrey Sviyazov wrote: > Here PcbDoc @ 10/06/2012. > > Best regards, > Andrey Sviyazov. > > > > 2012/6/10 Andrey Sviyazov > >> Hi all! >> >> Here final project UmTRXv2 @ 10/06/2012 (PcbDoc file will be attached to >> the next e-mail). >> Jean-Samuel, please check SMD LED's placed at the front edge of the PCB. >> If you agree with this variant then I'll generate Gerber files vs >> required layers and description to produce PCB. >> If anybody find any mistake, please inform me immediatelly. >> >> Best regards, >> Andrey Sviyazov. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomastsou at gmail.com Mon Jun 11 00:08:47 2012 From: thomastsou at gmail.com (Thomas Tsou) Date: Sun, 10 Jun 2012 20:08:47 -0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: On Sun, Jun 10, 2012 at 10:05 AM, Alexander Chemeris 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. >> 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! > 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. Have you verified reception of a receive test signal? Thomas From alexander.chemeris at gmail.com Mon Jun 11 11:12:41 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 11 Jun 2012 15:12:41 +0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: On Mon, Jun 11, 2012 at 4:08 AM, Thomas Tsou wrote: > On Sun, Jun 10, 2012 at 10:05 AM, Alexander Chemeris > 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 From andreysviyaz at gmail.com Mon Jun 11 16:01:42 2012 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Mon, 11 Jun 2012 20:01:42 +0400 Subject: UmTRXv2 final project In-Reply-To: References:

Message-ID: Hi Jean-Samuel. I'll try to generate Gerber files this night and then send them to you after double check. Best regards, Andrey Sviyazov. (Sent from my mobile client) 11.06.2012 2:15 ???????????? "Jean-Samuel Najnudel - BJT PARTNERS SARL" < jsn at bjtpartners.com> ???????: > Hi Andrey, > > Thank you very much for the project documents. > > Thanks a lot for the changes. I really think SMD LEDs at PCB front edge > can be an effective, convenient and cheap solution. > > Anyway, these project files looks fine for me. If everybody can double > check and confirm everything is ok, please generate all the files we need. > I will send these to the fab and start to move forward to the prototype > production process with them. > > Really, thanks a lot for this work. I am really glad we can move forward > to production. This is really great. > > Best regards. > > Jean-Samuel. > :-) > > > On Sun, Jun 10, 2012 at 2:46 AM, Andrey Sviyazov wrote: > >> Here PcbDoc @ 10/06/2012. >> >> Best regards, >> Andrey Sviyazov. >> >> >> >> 2012/6/10 Andrey Sviyazov >> >>> Hi all! >>> >>> Here final project UmTRXv2 @ 10/06/2012 (PcbDoc file will be attached to >>> the next e-mail). >>> Jean-Samuel, please check SMD LED's placed at the front edge of the PCB. >>> If you agree with this variant then I'll generate Gerber files vs >>> required layers and description to produce PCB. >>> If anybody find any mistake, please inform me immediatelly. >>> >>> Best regards, >>> Andrey Sviyazov. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreysviyaz at gmail.com Tue Jun 12 00:46:15 2012 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Tue, 12 Jun 2012 04:46:15 +0400 Subject: UmTRXv2 final project In-Reply-To: References:

Message-ID: Hi all! Here final project UmTRXv2 @ 12/06/2012 (PcbDoc file will be attached to the next e-mail). I found an mistake with non-SMD LED's positions in compare to Ettus where A-B in left-to-right orientation (see picture). Andrew Karpenkov suggested me to change it because of it is not yet standard but people accustomed to this. It is done. Also he suggest me to make four test points for RXOUT legs of LMS because he work with this now and found it helpfull. It is done. Also test points which without connector now referenced as TST and therefore RefDes of some connectors changed. Jean-Samuel, please find Gerber files, NC drill and layer stack desription files which usually required to produce PCB. Best regards, Andrey Sviyazov. 2012/6/10 Andrey Sviyazov > Hi all! > > Here final project UmTRXv2 @ 10/06/2012 (PcbDoc file will be attached to > the next e-mail). > Jean-Samuel, please check SMD LED's placed at the front edge of the PCB. > If you agree with this variant then I'll generate Gerber files vs required > layers and description to produce PCB. > If anybody find any mistake, please inform me immediatelly. > > Best regards, > Andrey Sviyazov. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UmTRXv2_Proj_Gbr (12.06.2012 4-21-40).zip Type: application/zip Size: 3696866 bytes Desc: not available URL: From andreysviyaz at gmail.com Tue Jun 12 00:48:10 2012 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Tue, 12 Jun 2012 04:48:10 +0400 Subject: UmTRXv2 final project In-Reply-To: References:

Message-ID: Here PcbDoc file @ 12/06/2012 . So, it all done :) Best regards, Andrey Sviyazov. 2012/6/12 Andrey Sviyazov > Hi all! > > Here final project UmTRXv2 @ 12/06/2012 (PcbDoc file will be attached to > the next e-mail). > I found an mistake with non-SMD LED's positions in compare to Ettus where > A-B in left-to-right orientation (see picture). > Andrew Karpenkov suggested me to change it because of it is not yet > standard but people accustomed to this. > It is done. > > Also he suggest me to make four test points for RXOUT legs of LMS because > he work with this now and found it helpfull. > It is done. > > Also test points which without connector now referenced as TST and > therefore RefDes of some connectors changed. > > Jean-Samuel, please find Gerber files, NC drill and layer stack desription > files which usually required to produce PCB. > > Best regards, > Andrey Sviyazov. > > > > 2012/6/10 Andrey Sviyazov > >> Hi all! >> >> Here final project UmTRXv2 @ 10/06/2012 (PcbDoc file will be attached to >> the next e-mail). >> Jean-Samuel, please check SMD LED's placed at the front edge of the PCB. >> If you agree with this variant then I'll generate Gerber files vs >> required layers and description to produce PCB. >> If anybody find any mistake, please inform me immediatelly. >> >> Best regards, >> Andrey Sviyazov. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UmTRXv2_PcbDoc (12.06.2012 4-19-29).zip Type: application/zip Size: 5006394 bytes Desc: not available URL: From andreysviyaz at gmail.com Wed Jun 13 05:13:20 2012 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Wed, 13 Jun 2012 09:13:20 +0400 Subject: UmTRXv2 final project In-Reply-To: References:

Message-ID: Hi Jean-Samuel. Please inform us about fabrication progress even there are no issues. Best regards, Andrey Sviyazov. (Sent from my mobile client) 12.06.2012 4:48 ???????????? "Andrey Sviyazov" ???????: > Here PcbDoc file @ 12/06/2012 . > So, it all done :) > > Best regards, > Andrey Sviyazov. > > > > 2012/6/12 Andrey Sviyazov > >> Hi all! >> >> Here final project UmTRXv2 @ 12/06/2012 (PcbDoc file will be attached to >> the next e-mail). >> I found an mistake with non-SMD LED's positions in compare to Ettus where >> A-B in left-to-right orientation (see picture). >> Andrew Karpenkov suggested me to change it because of it is not yet >> standard but people accustomed to this. >> It is done. >> >> Also he suggest me to make four test points for RXOUT legs of LMS because >> he work with this now and found it helpfull. >> It is done. >> >> Also test points which without connector now referenced as TST and >> therefore RefDes of some connectors changed. >> >> Jean-Samuel, please find Gerber files, NC drill and layer stack >> desription files which usually required to produce PCB. >> >> Best regards, >> Andrey Sviyazov. >> >> >> >> 2012/6/10 Andrey Sviyazov >> >>> Hi all! >>> >>> Here final project UmTRXv2 @ 10/06/2012 (PcbDoc file will be attached to >>> the next e-mail). >>> Jean-Samuel, please check SMD LED's placed at the front edge of the PCB. >>> If you agree with this variant then I'll generate Gerber files vs >>> required layers and description to produce PCB. >>> If anybody find any mistake, please inform me immediatelly. >>> >>> Best regards, >>> Andrey Sviyazov. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomastsou at gmail.com Sun Jun 17 00:59:08 2012 From: thomastsou at gmail.com (Thomas Tsou) Date: Sat, 16 Jun 2012 20:59:08 -0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: Hi 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 wrote: > On Mon, Jun 11, 2012 at 4:08 AM, Thomas Tsou wrote: >> On Sun, Jun 10, 2012 at 10:05 AM, Alexander Chemeris >> 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: From 246tnt at gmail.com Sun Jun 17 06:49:58 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 17 Jun 2012 08:49:58 +0200 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: Hi, > 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. Something about a missing symbol ? I had the same thing in 13.3 and none of the workaround on the net worked (they just resulted in different errors). I tried 14.1 and had the same issue but this time one of the workaround worked : LD_PRELOAD of libboost_serialization-gcc41-mt-p-1_38.so.1.38.0 made it work. Cheers, Sylvain From alexander.chemeris at gmail.com Sun Jun 17 08:21:54 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 17 Jun 2012 12:21:54 +0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: Hi Thomas, On Sun, Jun 17, 2012 at 4:59 AM, Thomas Tsou wrote: > 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. I apologize for not explaining the status of our code. For FPGA build you should use akarpenkov/lms_freq branch: https://github.com/chemeris/UHD-Fairwaves/tree/akarpenkov/lms_freq Alternatively I recommend you to use this image which is tested and known to work fine (either bin for usrp_n2xx_net_burner.py or bit for JTAG): http://code.google.com/p/umtrx/downloads/detail?name=u2plus_umtrx-20120424.bin http://code.google.com/p/umtrx/downloads/detail?name=u2plus_umtrx-20120424.bit Host utils should be taken from 'fairwaves/umtrx-dboard' branch, as I wrote earlier. Branch 'achemeris/lms_work' contains an unfinished code for baseband loopback inside of the LMS. I just had no time to finish and test it. If you need this, I could drop you an additional documentation on baseband loopback usage. Or you could use RF loopback which is better documented in the original documentation. Branch 'achemeris/zpu_work' contains our changes to ZPU to get ICAP working. I think I fixed all bugs on the ZPU side in that branch, but it still doesn't work. Build ZPU from that branch if you want to play with ICAP. I know, this is a bit of mess and we should clean this up. > 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. Looks like it is not correctly initialized. Try using the same initialization sequence as I do: ./umtrx_lms.py --lms 1 --lms-init ./umtrx_lms.py --lms 1 --lms-tx-enable 1 #./umtrx_lms.py --lms 1 --lms-rx-enable 1 # Select 0.75MHz LPF ./umtrx_lms.py --lms 1 --reg 0x34 --data 0x3e ./umtrx_lms.py --lms 1 --pll-ref-clock 26e6 --lpf-bandwidth-code 0x0f --lms-auto-calibration # Manual DC calibration ./umtrx_lms.py --lms 1 --reg 0x42 --data 0x71 ./umtrx_lms.py --lms 1 --reg 0x43 --data 0x89 ../build/utils/uhd_cal_tx_dc_offset --compl_i 0.001 --compl_q 0 # Tuning ./umtrx_lms.py --lms 1 --lms-tx-pll-tune 925e6 ./umtrx_lms.py --lms 1 --lms-pa-on 2 > 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. Yes, it works fine with the FPGA image above. I use the following command to burn it: ./usrp_n2xx_net_burner.py --addr= --fpga= --overwrite-safe Note, that we have to use safe firmware, because ICAP is not working in our firmware yet and thus we can't load a non-safe firmware. IIRC the image above always tries to load a second ZPU firmware from flash. So if you're not sure in your ZPU image - erase it from flash. You could see whether it boots it or not in the serial console (mini-USB connector at the back). > 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. Yes, they have issues under 64-bit Linux. So you have to either use 32-bit Linux or upgrade to ISE 14.1 and use the workaround as Sylvain mentioned. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From alexander.chemeris at gmail.com Sun Jun 17 18:18:21 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 17 Jun 2012 22:18:21 +0400 Subject: UmTRX UHD branches clean up Message-ID: 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 From thomastsou at gmail.com Sun Jun 17 18:36:24 2012 From: thomastsou at gmail.com (Thomas Tsou) Date: Sun, 17 Jun 2012 14:36:24 -0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: On Sun, Jun 17, 2012 at 2:49 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > >> 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. > > Something about a missing symbol ? > > I had the same thing in 13.3 and none of the workaround on the net > worked (they just resulted in different errors). > I tried 14.1 and had the same issue but this time one of the > workaround worked : LD_PRELOAD of > libboost_serialization-gcc41-mt-p-1_38.so.1.38.0 made it work. Similar, but different symbol error. I had this exact issue with MAP. http://www.xilinx.com/support/answers/43865.htm But the 'solution' caused XST to crash even worse with a double free. I eventually gave ISE it's own CentOS install inside VIrtualBox, which has worked well so far. Thomas From thomastsou at gmail.com Mon Jun 18 00:17:52 2012 From: thomastsou at gmail.com (Thomas Tsou) Date: Sun, 17 Jun 2012 20:17:52 -0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: On Sun, Jun 17, 2012 at 4:21 AM, Alexander Chemeris wrote: > Alternatively I recommend you to use this image which is tested and > known to work fine (either bin for usrp_n2xx_net_burner.py or bit for > JTAG): > http://code.google.com/p/umtrx/downloads/detail?name=u2plus_umtrx-20120424.bin > http://code.google.com/p/umtrx/downloads/detail?name=u2plus_umtrx-20120424.bit Ok. With this FPGA image and the following initialization sequence, I get signal. OpenBTS output is pretty clean as shown in the attachment. Note that I halved the GSM symbol rate because for some strange reason, I was not able to run OpenBTS with two samples-per-symbol, though I was able to send a tone with tx_waveforms at the same sample rate. So this is 'slow' GSM at 135 kHz, but the point was to get sampling above Nyquist to capture any distortion from the device and not OpenBTS itself. There is noticeable IQ imbalance, but I guess that is just uncorrected. Also, please ignore the failure messages on our test equipment (we have a converter spec issue). Is there a similar sequence to enable Rx? Thomas > Looks like it is not correctly initialized. Try using the same > initialization sequence as I do: > > ./umtrx_lms.py --lms 1 --lms-init > ./umtrx_lms.py --lms 1 --lms-tx-enable 1 > #./umtrx_lms.py --lms 1 --lms-rx-enable 1 > # Select 0.75MHz LPF > ./umtrx_lms.py --lms 1 --reg 0x34 --data 0x3e > ./umtrx_lms.py --lms 1 --pll-ref-clock 26e6 --lpf-bandwidth-code 0x0f > --lms-auto-calibration > # Manual DC calibration > ./umtrx_lms.py --lms 1 --reg 0x42 --data 0x71 > ./umtrx_lms.py --lms 1 --reg 0x43 --data 0x89 > ../build/utils/uhd_cal_tx_dc_offset --compl_i 0.001 --compl_q 0 > # Tuning > ./umtrx_lms.py --lms 1 --lms-tx-pll-tune 925e6 > ./umtrx_lms.py --lms 1 --lms-pa-on 2 -------------- next part -------------- A non-text attachment was scrubbed... Name: umtrx_rsa.jpg Type: image/jpeg Size: 111044 bytes Desc: not available URL: From thomastsou at gmail.com Mon Jun 18 01:32:06 2012 From: thomastsou at gmail.com (Thomas Tsou) Date: Sun, 17 Jun 2012 21:32:06 -0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: On Mon, Jun 11, 2012 at 7:12 AM, Alexander Chemeris wrote: > On Mon, Jun 11, 2012 at 4:08 AM, Thomas Tsou 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. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: umtrx_rsa1.JPG Type: image/jpeg Size: 111174 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-transceiver-workaround-for-transmit-testing-with-no-.patch Type: application/octet-stream Size: 3048 bytes Desc: not available URL: From alexander.chemeris at gmail.com Mon Jun 18 05:31:01 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 18 Jun 2012 09:31:01 +0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: On Mon, Jun 18, 2012 at 4:17 AM, Thomas Tsou wrote: > There is noticeable IQ imbalance, but I guess that is > just uncorrected. Yes, after the automatic DC offset calibration with --lms-auto-calibration, you should manually calibrate Tx DC offset and Tx IQ imbalance as described at the guide I attached (sections 4.8 and 4.9)/ Also look at the Starter manual section 6 for a more step by step, but high-level guide. I and Q channel DC calibration could be done with this commands (this is internal to LMS): ./umtrx_lms.py --lms 1 --reg 0x42 --data 0x ./umtrx_lms.py --lms 1 --reg 0x43 --data 0x And you could control I/Q balance with this command (done in FPGA at 13MSPS): ../build/utils/uhd_cal_tx_dc_offset --compl_i --compl_q > Is there a similar sequence to enable Rx? Nothing really tested yet. At least you should do this steps: ./umtrx_lms.py --lms 1 --lms-rx-enable 1 ./umtrx_lms.py --lms 1 --lms-rx-pll-tune 925e6 ./umtrx_lms.py --lms 1 --pll-ref-clock 26e6 --lpf-bandwidth-code 0x0f --lms-auto-calibration Then you need to select Rx input with register 0x75. Should be something like this: ./umtrx_lms.py --lms 1 --reg 0x75 --data 0xF0 There are a lot of other settings for Rx fontend in LMS which I don't understand, but I guess defaults should be fine for the start. Then we could tune them with Andrey's help. If signal is too low you may need to tune Rx VGA2 gain with the register 0x65 (refer to the programming guide for the register values encoding). To simplify further use we should add these controls to the LMS control script. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: LMS6002Dr2-Programming and Calibration Guide-1.1r1.pdf Type: application/pdf Size: 1613740 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LMS6002Dr2-Quick Starter Manual-EVB_5_r2.3.pdf Type: application/pdf Size: 4877633 bytes Desc: not available URL: From alexander.chemeris at gmail.com Mon Jun 18 05:37:44 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 18 Jun 2012 09:37:44 +0400 Subject: UmTRX timestamp bug Was: UmTRX integration with OpenBTS Message-ID: On Mon, Jun 18, 2012 at 5:32 AM, Thomas Tsou wrote: > On Mon, Jun 11, 2012 at 7:12 AM, Alexander Chemeris > wrote: >> On Mon, Jun 11, 2012 at 4:08 AM, Thomas Tsou 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 From andreysviyaz at gmail.com Mon Jun 18 07:49:37 2012 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Mon, 18 Jun 2012 11:49:37 +0400 Subject: UmTRXv2 final project In-Reply-To: References:

Message-ID: Hi Jean-Samuel. Took another week, but still no news from you. Could you please inform us about the progress in the production of prototypes. Best regards, Andrey Sviyazov. 2012/6/13 Andrey Sviyazov > Hi Jean-Samuel. > > Please inform us about fabrication progress even there are no issues. > > Best regards, > Andrey Sviyazov. > (Sent from my mobile client) > 12.06.2012 4:48 ???????????? "Andrey Sviyazov" > ???????: > > Here PcbDoc file @ 12/06/2012 . >> So, it all done :) >> >> Best regards, >> Andrey Sviyazov. >> >> >> >> 2012/6/12 Andrey Sviyazov >> >>> Hi all! >>> >>> Here final project UmTRXv2 @ 12/06/2012 (PcbDoc file will be attached to >>> the next e-mail). >>> I found an mistake with non-SMD LED's positions in compare to Ettus >>> where A-B in left-to-right orientation (see picture). >>> Andrew Karpenkov suggested me to change it because of it is not yet >>> standard but people accustomed to this. >>> It is done. >>> >>> Also he suggest me to make four test points for RXOUT legs of LMS >>> because he work with this now and found it helpfull. >>> It is done. >>> >>> Also test points which without connector now referenced as TST and >>> therefore RefDes of some connectors changed. >>> >>> Jean-Samuel, please find Gerber files, NC drill and layer stack >>> desription files which usually required to produce PCB. >>> >>> Best regards, >>> Andrey Sviyazov. >>> >>> >>> >>> 2012/6/10 Andrey Sviyazov >>> >>>> Hi all! >>>> >>>> Here final project UmTRXv2 @ 10/06/2012 (PcbDoc file will be attached >>>> to the next e-mail). >>>> Jean-Samuel, please check SMD LED's placed at the front edge of the PCB. >>>> If you agree with this variant then I'll generate Gerber files vs >>>> required layers and description to produce PCB. >>>> If anybody find any mistake, please inform me immediatelly. >>>> >>>> Best regards, >>>> Andrey Sviyazov. >>>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsn at bjtpartners.com Mon Jun 18 09:19:35 2012 From: jsn at bjtpartners.com (Jean-Samuel Najnudel - BJT PARTNERS SARL) Date: Mon, 18 Jun 2012 11:19:35 +0200 Subject: UmTRXv2 final project In-Reply-To: References:

Message-ID: Hi Andrey, I sent the files last week. The fab needs a few days to update its pricing and launch the production process. Anyway, I just called them today. Work is in progress. They will provide me with some updates later this week. They confirm this should not take too much time for production and they will anyway contact me if they need anything. I will let you know asap. Best regards. Jean-Samuel. :-) On Mon, Jun 18, 2012 at 9:49 AM, Andrey Sviyazov wrote: > Hi Jean-Samuel. > > Took another week, but still no news from you. > Could you please inform us about the progress in the production of > prototypes. > > Best regards, > Andrey Sviyazov. > > > > 2012/6/13 Andrey Sviyazov > >> Hi Jean-Samuel. >> >> Please inform us about fabrication progress even there are no issues. >> >> Best regards, >> Andrey Sviyazov. >> (Sent from my mobile client) >> 12.06.2012 4:48 ???????????? "Andrey Sviyazov" >> ???????: >> >> Here PcbDoc file @ 12/06/2012 . >>> So, it all done :) >>> >>> Best regards, >>> Andrey Sviyazov. >>> >>> >>> >>> 2012/6/12 Andrey Sviyazov >>> >>>> Hi all! >>>> >>>> Here final project UmTRXv2 @ 12/06/2012 (PcbDoc file will be attached >>>> to the next e-mail). >>>> I found an mistake with non-SMD LED's positions in compare to Ettus >>>> where A-B in left-to-right orientation (see picture). >>>> Andrew Karpenkov suggested me to change it because of it is not yet >>>> standard but people accustomed to this. >>>> It is done. >>>> >>>> Also he suggest me to make four test points for RXOUT legs of LMS >>>> because he work with this now and found it helpfull. >>>> It is done. >>>> >>>> Also test points which without connector now referenced as TST and >>>> therefore RefDes of some connectors changed. >>>> >>>> Jean-Samuel, please find Gerber files, NC drill and layer stack >>>> desription files which usually required to produce PCB. >>>> >>>> Best regards, >>>> Andrey Sviyazov. >>>> >>>> >>>> >>>> 2012/6/10 Andrey Sviyazov >>>> >>>>> Hi all! >>>>> >>>>> Here final project UmTRXv2 @ 10/06/2012 (PcbDoc file will be attached >>>>> to the next e-mail). >>>>> Jean-Samuel, please check SMD LED's placed at the front edge of the >>>>> PCB. >>>>> If you agree with this variant then I'll generate Gerber files vs >>>>> required layers and description to produce PCB. >>>>> If anybody find any mistake, please inform me immediatelly. >>>>> >>>>> Best regards, >>>>> Andrey Sviyazov. >>>>> >>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomastsou at gmail.com Wed Jun 20 01:33:35 2012 From: thomastsou at gmail.com (Thomas Tsou) Date: Tue, 19 Jun 2012 21:33:35 -0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: On Mon, Jun 18, 2012 at 1:31 AM, Alexander Chemeris wrote: > Nothing really tested yet. At least you should do this steps: > ./umtrx_lms.py --lms 1 --lms-rx-enable 1 > ./umtrx_lms.py --lms 1 --lms-rx-pll-tune 925e6 > ./umtrx_lms.py --lms 1 --pll-ref-clock 26e6 --lpf-bandwidth-code 0x0f > --lms-auto-calibration > > Then you need to select Rx input with register 0x75. Should be > something like this: > ./umtrx_lms.py --lms 1 --reg 0x75 --data 0xF0 > > There are a lot of other settings for Rx fontend in LMS which I don't > understand, but I guess defaults should be fine for the start. Then we > could tune them with Andrey's help. > > If signal is too low you may need to tune Rx VGA2 gain with the > register 0x65 (refer to the programming guide for the register values > encoding). Connected a call - all seven actually. It's quite stable once setup. 'fairwaves/umtrx' branch with u2plus_umtrx-20120424.bit and following patch. I and Q were swapped. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-transceiver-umtrx-set-timing-offset-and-swap-receive.patch Type: application/octet-stream Size: 1616 bytes Desc: not available URL: From alexander.chemeris at gmail.com Wed Jun 20 04:11:05 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 20 Jun 2012 08:11:05 +0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: On Wed, Jun 20, 2012 at 5:33 AM, Thomas Tsou wrote: > On Mon, Jun 18, 2012 at 1:31 AM, Alexander Chemeris > wrote: >> Nothing really tested yet. At least you should do this steps: >> ./umtrx_lms.py --lms 1 --lms-rx-enable 1 >> ./umtrx_lms.py --lms 1 --lms-rx-pll-tune 925e6 >> ./umtrx_lms.py --lms 1 --pll-ref-clock 26e6 --lpf-bandwidth-code 0x0f >> --lms-auto-calibration >> >> Then you need to select Rx input with register 0x75. Should be >> something like this: >> ./umtrx_lms.py --lms 1 --reg 0x75 --data 0xF0 >> >> There are a lot of other settings for Rx fontend in LMS which I don't >> understand, but I guess defaults should be fine for the start. Then we >> could tune them with Andrey's help. >> >> If signal is too low you may need to tune Rx VGA2 gain with the >> register 0x65 (refer to the programming guide for the register values >> encoding). > > Connected a call - all seven actually. It's quite stable once setup. Good job! How did you setup Rx on LMS? And anything else to know before testing? > 'fairwaves/umtrx' branch with u2plus_umtrx-20120424.bit and following > patch. Now it's time to make this a configure option. :) > I and Q were swapped. So I/Q order is different at Rx and Tx?We could fix this in FPGA. With the multi-ARFCN support, do you think it will be hard to add support for the second channel in UmTRX to OpenBTS to get 15 calls? Second channel is not fully supported by UmTRX FPGA firmware yet, but we should do this soon. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From alexander.chemeris at gmail.com Wed Jun 20 04:33:52 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 20 Jun 2012 08:33:52 +0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: On Wed, Jun 20, 2012 at 8:11 AM, Alexander Chemeris wrote: > On Wed, Jun 20, 2012 at 5:33 AM, Thomas Tsou wrote: >> On Mon, Jun 18, 2012 at 1:31 AM, Alexander Chemeris >> wrote: >>> Nothing really tested yet. At least you should do this steps: >>> ./umtrx_lms.py --lms 1 --lms-rx-enable 1 >>> ./umtrx_lms.py --lms 1 --lms-rx-pll-tune 925e6 >>> ./umtrx_lms.py --lms 1 --pll-ref-clock 26e6 --lpf-bandwidth-code 0x0f >>> --lms-auto-calibration >>> >>> Then you need to select Rx input with register 0x75. Should be >>> something like this: >>> ./umtrx_lms.py --lms 1 --reg 0x75 --data 0xF0 >>> >>> There are a lot of other settings for Rx fontend in LMS which I don't >>> understand, but I guess defaults should be fine for the start. Then we >>> could tune them with Andrey's help. >>> >>> If signal is too low you may need to tune Rx VGA2 gain with the >>> register 0x65 (refer to the programming guide for the register values >>> encoding). >> >> Connected a call - all seven actually. It's quite stable once setup. > > Good job! > > How did you setup Rx on LMS? > And anything else to know before testing? > >> 'fairwaves/umtrx' branch with u2plus_umtrx-20120424.bit and following >> patch. > > Now it's time to make this a configure option. :) > >> I and Q were swapped. > > So I/Q order is different at Rx and Tx?We could fix this in FPGA. > > With the multi-ARFCN support, do you think it will be hard to add > support for the second channel in UmTRX to OpenBTS to get 15 calls? > Second channel is not fully supported by UmTRX FPGA firmware yet, but > we should do this soon. Actually interesting would be to test UmTRX with your multi-ARFCN code to see how many channels we could fit into. I wonder how do you select/measure rx_smpl_offset. My guess is that you write both Tx and Rx I/Q streams to files, plot them and try to align frame starts. Is that how do you do this? PS Could you record a short video of making 7 calls through UmTRX? We should make some noise or people forget what we're doing. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From plddesigner at gmail.com Wed Jun 20 14:18:32 2012 From: plddesigner at gmail.com (Andrew Karpenkov) Date: Wed, 20 Jun 2012 18:18:32 +0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: Hi, I've fixed reading data order from the receive ADCs. You can found it in fairwaves/umtrx branch (commit e2e5dc62317a714944e9d54b56240fca5336e2ca). 2012/6/20 Thomas Tsou > 'fairwaves/umtrx' branch with u2plus_umtrx-20120424.bit and following > patch. I and Q were swapped. > Regards, Andrew Karpenkov -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Wed Jun 20 14:47:42 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 20 Jun 2012 18:47:42 +0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: Andrew, Thanks for the fix. Now we should merge Sylvain's GPSDO changes into the master branch and make a build with both changes to upload to the web-site. Could you do this and send me both .bit and .bin files? PS Do not forget to build fresh bootloader, it's also changed by GPSDO update. On Wed, Jun 20, 2012 at 6:18 PM, Andrew Karpenkov wrote: > Hi, > > I've fixed reading data order from the receive ADCs.?You can found it in > fairwaves/umtrx branch (commit?e2e5dc62317a714944e9d54b56240fca5336e2ca). > > 2012/6/20 Thomas Tsou? >> >> 'fairwaves/umtrx' branch with u2plus_umtrx-20120424.bit and following >> patch. I and Q were swapped. > > > Regards, > Andrew Karpenkov > > > > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From plddesigner at gmail.com Wed Jun 20 17:22:58 2012 From: plddesigner at gmail.com (Andrew Karpenkov) Date: Wed, 20 Jun 2012 21:22:58 +0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: I've done it. tx_waveforms work fine. Both .bit and .bin files attached. Please, check other function of UmTRX board with this flash image. Repository at github was also updated. Regards, Andrew Karpenkov 2012/6/20 Alexander Chemeris > Andrew, > > Thanks for the fix. Now we should merge Sylvain's GPSDO changes into > the master branch and make a build with both changes to upload to the > web-site. Could you do this and send me both .bit and .bin files? > > PS Do not forget to build fresh bootloader, it's also changed by GPSDO > update. > > On Wed, Jun 20, 2012 at 6:18 PM, Andrew Karpenkov > wrote: > > Hi, > > > > I've fixed reading data order from the receive ADCs. You can found it in > > fairwaves/umtrx branch (commit e2e5dc62317a714944e9d54b56240fca5336e2ca). > > > > 2012/6/20 Thomas Tsou > >> > >> 'fairwaves/umtrx' branch with u2plus_umtrx-20120424.bit and following > >> patch. I and Q were swapped. > > > > > > Regards, > > Andrew Karpenkov > > > > > > > > > > > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / ??? ??????? > http://fairwaves.ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: u2plus_umtrx.bin Type: application/octet-stream Size: 2453092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: u2plus_umtrx.bit Type: application/octet-stream Size: 2453207 bytes Desc: not available URL: From thomastsou at gmail.com Thu Jun 21 03:23:33 2012 From: thomastsou at gmail.com (Thomas Tsou) Date: Wed, 20 Jun 2012 23:23:33 -0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: On Wed, Jun 20, 2012 at 12:11 AM, Alexander Chemeris wrote: > On Wed, Jun 20, 2012 at 5:33 AM, Thomas Tsou wrote: >> On Mon, Jun 18, 2012 at 1:31 AM, Alexander Chemeris >> wrote: >>> Nothing really tested yet. At least you should do this steps: >>> ./umtrx_lms.py --lms 1 --lms-rx-enable 1 >>> ./umtrx_lms.py --lms 1 --lms-rx-pll-tune 925e6 >>> ./umtrx_lms.py --lms 1 --pll-ref-clock 26e6 --lpf-bandwidth-code 0x0f >>> --lms-auto-calibration >>> >>> Then you need to select Rx input with register 0x75. Should be >>> something like this: >>> ./umtrx_lms.py --lms 1 --reg 0x75 --data 0xF0 >>> >>> There are a lot of other settings for Rx fontend in LMS which I don't >>> understand, but I guess defaults should be fine for the start. Then we >>> could tune them with Andrey's help. >>> >>> If signal is too low you may need to tune Rx VGA2 gain with the >>> register 0x65 (refer to the programming guide for the register values >>> encoding). >> >> Connected a call - all seven actually. It's quite stable once setup. > > Good job! > > How did you setup Rx on LMS? > And anything else to know before testing? I used some combination of the above Rx settings and the previous Tx sequence. I don't recall the exact order, but I didn't use any commands or arguments that haven't been mentioned. I didn't change the VGA2 setting and for much of the testing had a 3dB attenuator on the LNA input (probably didn't matter). Remember to set the ARFCN to match the tuning frequencies. I did not and spent some time trying to figure out why only RACH bursts were decoded. >> 'fairwaves/umtrx' branch with u2plus_umtrx-20120424.bit and following >> patch. > > Now it's time to make this a configure option. :) UmTRX could be detected at runtime. There are already device checks for USRP1 and B100. >> I and Q were swapped. > > So I/Q order is different at Rx and Tx?We could fix this in FPGA. > > With the multi-ARFCN support, do you think it will be hard to add > support for the second channel in UmTRX to OpenBTS to get 15 calls? > Second channel is not fully supported by UmTRX FPGA firmware yet, but > we should do this soon. The OpenBTS side should be straightforward. The multicarrier implementation accepts independent transceiver inputs with the channelization acting as multiplexer. With separate physical channels, we just remove the channelization and pass transceiver connections straight through to the device interface. I added the second Tx channel in UHD some time ago, but never created a test case. Thomas From thomastsou at gmail.com Thu Jun 21 04:07:07 2012 From: thomastsou at gmail.com (Thomas Tsou) Date: Thu, 21 Jun 2012 00:07:07 -0400 Subject: UmTRX integration with OpenBTS In-Reply-To: References:

Message-ID: On Wed, Jun 20, 2012 at 12:33 AM, Alexander Chemeris wrote: > Actually interesting would be to test UmTRX with your multi-ARFCN code > to see how many channels we could fit into. I tried this briefly but the transmit output was cutoff by LPF. I'll try it again with different LMS settings at the end of the week. > I wonder how do you select/measure rx_smpl_offset. My guess is that > you write both Tx and Rx I/Q streams to files, plot them and try to > align frame starts. Is that how do you do this? I mainly use two approaches. In the first method, feed the baseband output to a scope (optionally set the transceiver filler table with easy to recognizable values). Set one output of a dual function generator to trigger the scope at the frame rate. Use the second function generator output (with low duty cycle) to select individual timeslots and also trigger an RF signal generator that feeds back to the device. The offset can then be detected using the receiver energy detector. The second much quicker (and generally more effective) approach is to simply measure with a handset. Disable upper layer RACH handling and average the RACH burst TOA values over a few attempts and different handsets. This delay value is the effective combined group delay (relative to the sample counter) of host and device filters, RF components, feed line, etc. I rarely use first approach, but sometimes absolutely nothing works and the test equipment needs to be used to get a better picture. > PS Could you record a short video of making 7 calls through UmTRX? We > should make some noise or people forget what we're doing. I could record a (low quality) video with my phone. That is the only video recorder I have available right now. I can take pretty good pictures though. Thomas