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.comHi Thomas, On Sun, Jun 17, 2012 at 4:59 AM, Thomas Tsou <thomastsou at gmail.com> 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=<ip address> --fpga=<path to FPGA image> --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