null08 / umtrx Goto Github PK

Cause:

When supply voltage in the range from 8.5V upto 24V then U16 become unstable 
and at TxLO there are -50dBc spurs because of it (see pics).
Found out that U16 skipped a lot pulses and therefore I see spurs on the TxLO 
spectrum at the frequency offsets around 120..180kHz.
Spurs frequency dependant of the LAN, connected or not, i.e. load dependent too.
I found that spurs frequency equals to difference between convertion frequency 
~480kHz and frequency with skipped pulses ~360kHz, i.e. ~120kHz.

Output voltage still normal +2.57V and ripples below 50mV.
See pics where ~30mV ripples for for normal work, ~40mV for semi-normal and 
~45mV for abnormal.
Also pics whith normal pulses, semi-normal pulses and abnormal (skiped) pulse 
of the coil of U16.

Workaround OR Fix:

If syncro pin of U16 disconnected then all become Ok, 
but it mean that syncro mode off and doesn't good to keep so forever.

Application note AN1723 for L5973AD didn't help, I just spent half day with 
zero result.

I found that 100pF capacitor from syncro pin to GND solved problem with LO 
spurs for almost all voltages.
Please see pics how to solder it between 2 and 3 pin of the U15 !!!
But U16 still become unstable when it cold.
So, seems this method doesn't yet fixes this problem.

Any thoughts?

Cause: Incorrect values R5 & R8.

To Fix: Use values R5=180 Ohm  and R8=120 Ohm.

 * Add 2nd Tx DSP control block to the host UHD.
 * Add 2nd streamer to the host UHD.

Timing report in attachement.

The ICAP in S6 seems to have very slow AC characteristics:

Both for clock-to-out and for required setup time :

ICAP_X0Y0.O5         Tcapcko_O             8.000   
u2p_c/s3a_icap_wb/ICAP_SPARTAN6_inst
                                                   u2p_c/s3a_icap_wb/ICAP_SPARTAN6_inst

ICAP_X0Y0.CLK        Tcapcck_WRITE         5.000   
u2p_c/s3a_icap_wb/ICAP_SPARTAN6_inst
                                                   u2p_c/s3a_icap_wb/ICAP_SPARTAN6_inst

Need to clock this module slower or pipeline more. (and define proper 
multicylce constraint).

LMS output has clear 26MHz harmonics up to at least 36th harmonic (936MHz). 
Some of those even lie in GSM-900 downlink band, which is too bad. Note, that 
harmonics doesn't decay with number, level of the 36th harmonic is about the 
same as of 3rd or 4th harmonic.

Their source is not clear yet and may be better chip tuning will help reduce 
them.

Another suggestion is to try to better filter input clock signal, though we 
already do this.

I think having a wideband RX port (no filters) on one of the LMS would be 
useful.

- For development: It's much easier to test something with known signal sources 
/ carriers and those are not in the GSM uplink band.

- For production: Ability to perform wide spectrum survey remotely to identify 
interference / band usage / ...

Cause:
Clock distribution system in the UmTRXv2.1 provides the same clock for LMS 
PLL's and for sampling.
Thus upper clock limit is 40 MHz due to restrictions of the PLL's.
This makes impossible future developing of wideband LTE on UmTRX.

Workaround OR Fix:
For UmTRXv2.2 was suggested to add clock divider by 2 for PLL's to get sampling 
clock limit for sampling up-to 80 MHz.

Cause:
There are no port to control external equipment like PA via I2C or some like 
this.

Workaround OR Fix:
Some serial port connector can be easily soldered instead of debug port.
In UmTRXv2.2 will be added serial port connector and couple of ADC and DAC IC's 
to control external equipment digitally and analogue values  (eg: RF power 
monitor and PA's transistor biasing).

Cause:
SYS_CLK pin of ET1011C chip is connected to the user IO pad of Spartan 6 
(CLK_TO_MAC pin). In consequence we can't use this signal to form GTX_CLK 
signal to ET1011C chip.

Workaround OR Fix:
I connected RX_clk pin to GTX_CLK into FPGA to solve this problem. Now, it 
works fine and I do not find any issues with Ethernet on UmTRX board. But I'm 
not sure that I can do so.

Looking forward for your advise on this issue. Should we use SYS_CLK in next 
version of UmTRX?

1. Connect diversity switch control lines to a register in FPGA.
2. Add a control function for the diversity switch into UHD.
3. Implement logic to control the diversity switch in OpenBTS

Cause:
Found out that for inputs of the diversity switch HMC435 required AC coupling 
to work correctly.

Workaround OR Fix:
Four wires should be cutted between splitters and switches and then 4 pcs of 
100pF capacitors should be placed there.
Cut copper only, then clean up mask and tin wires
Please, be carefully and accurately, do not cut deeply, because of prepregs of 
top and bottom layers are very thin.
Better way to soldering capacitors - to the leg of the switch and wires on top 
and to the wires between two vias on bottom.
See photos with my results below.

After fix, losses of paths between LNA's outputs and LMS's RX inputs becomes 
around 4dB, as it was intended.

Cause:
Even single UmTRXv2.1 still dissipate more then 16 Watt.

Workaround OR Fix:
To make more possible fan-less solution in UmTRXv2.2 will be improved by:
- Adding more mounting holes (at least between LMS's) at center line of board 
for better heat dissipation.
- All free space of Bottom Layer will be filled by the GND cooper polygon for 
better heat dissipation.
- Mounting holes will be more accurately aligned to 0.5mm grid and diameters 
will be increased to 3.2 mm.
- Will be designed mechanical plate component which will be there after easy 
CNCed  out of the usual 4..5mm aluminium plate and then mounted (with UmTRX 
board) to the heatsink by few bigger screws.

Cause:
Thanks to  Ricardas Vadoklis (Senior System and Test Engineer of Lime 
microsystems) who found this my mistake about required contections.
But he also informed us that pins PVDDAD33A..E (1,7,12,18,34) are all tied 
inside the chip. (God saved us one more time :)
So, only one pin have to be connected to Vref through resistor 270 Ohm, and 
other pins can be kept opened or (better) connected to the capacitors.

Workaround OR Fix:
Components R102-1, R102-2, L17-1 and L17-2 have to be removed.

Cause:
Diversity switch control outputs of FPGA are not LVDS compatible.

Workaround OR Fix:
Control diversity switches by set appropriate logical levels.
In version UmTRXv2.2 will be used LVDS compatible output pairs.
It mean that also FPGA user constraint file (UCF) will be different.

Dangerous bag!!!
To avoid fatal damage make sure that this bag are fixed before apply power 
first time !!!

Cause: Incorrect CAD component CY7C1354C-166AXI about pin 76, whitch have to be 
connected to GND.

To Fix: Cut strip line from pin 76 to VIA to +2,5VRAM and connect pin 76 to pin 
71 (GND) by short thin wire.

Cause:
Electrolytic capacitors have lifetime of only 5000 Hrs (208 days).

Workaround OR Fix:
Replace with tantalum capacitors.

Just pasting info from email thread:


> The clock signal at the output of the FPGA will have the deterioration of
> jitter.

Ok, fair enough.

The entire clocking seems a bit weird tough.

For me the point of a clock distribution chip is to have only
point-to-point clock traces to avoid integrity issues.

But here you have:
 - The TX clock fed both to the LMS and the FPGA. Even tough the FPGA
already has a copy of that clock, no point in feeding a second copy.
 - One of the 'PLL CLOCK' is branched off and fed to a header.

I would:
 - Feed the external header from the clock buffer currently assigned
to fpga_clock_n  (we don't use it anyway)
 - Remove the 'feedback' of TX clock. (direct clock chip -> LMS)

The clock is "only" 26 MHz, so a period of 38 ns. So there is no
problem to capture / feed data at the right time from a single clock
in the FGPA (and thus avoid messy clock domain changes in the FPGA).


> Yes, this is my mistake, the correct name should be RX_CLK_OUT.
> However, if you look evaluation board schematic, you will find that this
> signal have the bad level, as it requires additional buffer with adjustable
> external offset.

Well, they have buffer on the eval board, but have you checked the levels ?
It's supposed to be a CMOS level output so the driver on the eval
board might just be a precaution ...

Or is there an errata sheet ?

Because it actually make sense to feed that clock back to the fpga
(altough we might end up not using it, it's good to have a clock that
comes "with" the data)


> Moreover, in order to avoid possible distortions of the spectrum because of
> the wrong quantization of the DAC and ADC, in circuits of TX_CLK and RX_CLK
> at the inputs of the LMS provides the installation of the resistors to
> adjust the duty cycle of the clock signal inside the LMS.

That seems a bit overkill.

Cause:
It was discovered that 80 kHz spurs come from the ET1011.
Unstable work occur because of choke between transistor of the regulator and 1V 
analog power of ET1011.

Workaround OR Fix:
L46 should be replaced by jumper.

If FPGA pins are free, the ability to use other transfer modes than just plain 
serial on the FT232 could be useful to get a high speed debug channel.

UART is nice but is not all that fast.

Cause: Unknown

PS And I hope it's not a problem with my UmTRX unit. Something to check 
tomorrow.

Cause:
LMS chips generate too much heat to work reliably in harsh environments.

Fix:
A fan or a good heat-sink is needed. For outdoor installations a good contact 
with a case may be enough.

Cause:

DSP block at FPGA should work at the frequency of ADC/DAC to correctly process 
data. At the same time the clock for the DSP block is derived from the system 
clock.

When we set system clock to 13MHz to make DSP block synchronous with LMS 
ADC/DAC, Ethernet stops transmitting correctly. Receive seems to work fine, as 
ZPU sees packets and seem to respond to them. But packets are not received by 
the other end (host). So we guess that Ethernet MAC is not working properly in 
this case. The reason for this is not clear yet.

Experiments show that Ethernet works correctly is system clock is >30MHz.


Workaround:

We will run DSP block at 52MHz and drop/insert samples while receiving/sending 
them from/to ADC/DAC.

Cause:
There are mistake in CAD component footprint of VCOCXO U2.

Workaround OR Fix:
Mounting possible from bottom side.
Please find where first pin marked, to be sure.

Todo items:
* Improve integration/decimation filters in FPGA to introduce less distortion.
* Implement wideband I/Q imbalance calibration in FPGA.

Cause:
Solder mask becomes broken (appear shorts to GND pad) after few times 
re-soldering.

In version UmTRXv2.2 will be improved the next:
- Added silkscreen above the via's which under the LMS's to make the screen 
stronger.
- corrected few mask-to-silk warnings around T1-1, T1-2.

Cause: In the schema, nets TXD1 and RXD1 to a component FT232RL are swapped.

To Fix:
a) nets TXD1 and RXD1 must be swapped in the u2plus_umtrx.ucf;
b) the net TXD1 should be renamed in RXD1 and net RXD1 to TXD1.

1. Connect UmSEL SPI and I2C lines in FPGA.
2. Control UmSEL tuner from a host.

A detailed list of things to do is at the wiki page:
http://code.google.com/p/umtrx/wiki/UHDIntegrationToDo

Cause: Incorrect polarity of C169.

To Fix: Remove C169 and solder back with correct polarity.

When calibrated and measured at 945 MHz with Tx only, OpenBTS-UmTRX shows RMS 
phase error below 1.6 degrees. Phase error jumps as high as 2.5 degrees when Rx 
is enabled. Installing a CPU fan reduces error to 1.8 degrees.

Cause:

Temperature confirmed as one cause. Other causes are still unknown.

Workaround OR Fix:

Install cooling fan.

It just needs renaming in the schematic. There is no board level hw change 
required, wiring is ok.

Cause:
Incorrect footprint of the TMP102 component (U38-1, U38-2).

Workaround OR Fix:
Manually soldering.
Will be fixed in UmTRXv2.2.

From Sylvain:

Another improvement to consider for future boards/revisions is to try to put 
all sram data line connection in the same bank.

Currently they all are in bank0 _except_ D17. Post-PAR timing simulation show 
that pin skew to be a clear outlier with > 0.5 ns skew (compared to all the 
other which are withing 70 ps of each other).

Data lines are more critical because you need to capture incoming data on them 
and so you have to consider both the output timing variation of the clk + input 
timing variation.

Since we're running the SRAM pretty far from it's limits (104 MHz vs 166 MHz), 
that shouldn't matter at all. But something to keep in mind as minor 
enhancement in case we want more bandwidth in the future.

Production image is loaded only at the second reset. Third reset doesn't loads 
image again and so on.

Log from the debug console:

<pre>

USRP N210 UDP bootloader
FPGA compatibility number: 8
Firmware compatibility number: 11
Checking for valid production FPGA image...
Valid production FPGA image found. Attempting to boot.
No valid production FPGA image found.
Falling through to built-in firmware.

Enabling Tx and Rx on LMS1 and LMS2

LMS1 register readback = 0x
LMS2 register readback = 0x 00:50:C2:85:3F:FF
192.168.10.2

eth link changed: speed = 0
ethernet flow control: WE_TX
Speed set to 1000

eth link changed: speed = 1000
sent 64 bytes
ethernet flow control: WE_TX

eth link changed: speed = 0
Speed set to 1000

eth link changed: speed = 1000
sent 64 bytes

USRP N210 UDP bootloader
FPGA compatibility number: 8
Firmware compatibility number: 11
Valid production firmware found. Loading...
Finished loading. Starting image.

TxRx-UHD-ZPU
FPGA compatibility number: 8
Firmware compatibility number: 11
LMS1 chip version = 0xD
LMS2 chip version = 0x22

Enabling Tx and Rx on LMS1 and LMS2
LMS1 register readback = 0x0
LMS2 register readback = 0x3E
00:50:C2:85:3F:FF
192.168.10.2

eth link changed: speed = 0
ethernet flow control: WE_TX
Speed set to 1000

eth link changed: speed = 1000
sent 64 bytes
ethernet flow control: WE_TX

eth link changed: speed = 0
Speed set to 1000

eth link changed: speed = 1000
sent 64 bytes
===> 0
===> 1

USRP N210 UDP bootloader
FPGA compatibility number: 8
Firmware compatibility number: 11
Checking for valid production FPGA image...
Valid production FPGA image found. Attempting to boot.
No valid production FPGA image found.
Falling through to built-in firmware.

Enabling Tx and Rx on LMS1 and LMS2

LMS1 register readback = 0x
LMS2 register readback = 0x 00:50:C2:85:3F:FF
192.168.10.2

eth link changed: speed = 0
ethernet flow control: WE_TX
Speed set to 1000

eth link changed: speed = 1000
sent 64 bytes
ethernet flow control: WE_TX

eth link changed: speed = 0
Speed set to 1000

eth link changed: speed = 1000
sent 64 bytes

USRP N210 UDP bootloader
FPGA compatibility number: 8
Firmware compatibility number: 11
Valid production firmware found. Loading...
Finished loading. Starting image.

TxRx-UHD-ZPU
FPGA compatibility number: 8
Firmware compatibility number: 11
LMS1 chip version = 0xD
LMS2 chip version = 0x22

Enabling Tx and Rx on LMS1 and LMS2
LMS1 register readback = 0x0
LMS2 register readback = 0x3E
00:50:C2:85:3F:FF
192.168.10.2

eth link changed: speed = 0
ethernet flow control: WE_TX
Speed set to 1000

eth link changed: speed = 1000
sent 64 bytes
ethernet flow control: WE_TX

eth link changed: speed = 0
Speed set to 1000

eth link changed: speed = 1000
sent 64 bytes
===> 0
===> 1
</pre>

I've noticed that the default 'pull up' state of the pins means
that by default the LMS RXEN and TXEN are _active_ (they're active
high input). Maybe adding pulldowns on those would be a good idea ?

Cause: Incorrect CAD footpring for component M25P16-VMW6TG.

To Fix: Either use appropriate M25P16-VMN6 or solder M25P16-VMW6 with legs 
folded inward.

Cause:
At the Tx outputs of UmTRXv2 there are gain block IC's SPF-5043, so I waited 
signal around +20dBm with saturation, but initially for 900 MHz I got +20dBm 
and only +10dBm for 1800 MHz.

Workaround OR Fix:
To equalize this 10dB required matching of the LMS6002D output by using 
capacitor between C104, C105 and T1 (it is not C96 !).
Here attached pictures how to solder this capacitor.
In the next version of UmTRX position of C96 should be corrected.

For UmTRXv2 found out 3.0pF to get +20dBm signals for 900 MHz band and +17dBm 
for 1800 MHz bands. At the LMS outputs (without gain block) around +3dBm for 
900 and +6dBm for 1800 MHz. All tests was with TXVGA2=25.

For UmTRXv1 found out 1.8pF to get equal signals for 900 and 1800 bands. It is 
around 0dBm at TXVGA2=20 and around +5dBm at TXVGA2=25.

Other settings: TXVGA1=-10, ideal continious GMSK and full bands 
920-960/1800-1880 MHz.

Problem:
M25P16 flash is installed which is 16 MBit. We need 64 MBit flash to store two 
images (normal and safe) for Spartan 6 LX75.

Fix:
M25P16 should be replaced with M25P64.

Cause: ZPU accepts the first two bytes of the received packet to be zero.

Workaround:
The first two bytes of the incoming packets are used only when ZPU will checks 
whether the broadcast packet received.
For our testing purposes we should change value of variable BCAST_MAC_ADDR from 
{{0xff, 0xff, 0xff, 0xff, 0xff, 0xff}} into {{0x00, 0x00, 0xff, 0xff, 0xff, 
0xff}}.
Later we should to do it properly.

Just added, let me not forget to do it.

Cause:
Found out in UmTRXv2, but v1 also has the same labels, which are mixed up.

Workaround OR Fix:
1. Just keep in mind, else it is easy to correct by stickers or permanent 
marker.
2. TopSilk layer could be fix prior the next batch.

We should move to the latest stable UHD, because it's more flexible and 
modular. And to maintain compatibility with the latest GnuRadio.

All calibration values should be stored in EEPROM and automatically applied on 
startup. Includes TCXO DAC value, DC tuning, etc.

Cause: Too low Clipped Sinewave signal from TCD4029 (high level lower then 
1.4V). 

To Fix: below 3 Steps to perform
a) solder R12=10kOhm
b) solder one more the same 0603 10kOhm resistor between R12 and C312 (+3,0VCC) 
c) replace R7 (0 Ohm) by 0.1uF capacitor to make AC coupling to +3,0VCC/2 level.

Cause:
The M0 and M1 pins are both high in the status register.  After the flash 
device is programmed, the default action is to configure the FPGA from the 
flash device, but this requires the mode pins to be set properly for SPI flash 
configuration.  We have a resistor tying M1 to ground, it is not small enough 
to overcome the internal pullup of the Spartan 6.  Less than 1K should do it.

Workaround OR Fix:
We should replace 4k7 resistor (R32 on scheme) at resistor less then 1k. I 
replaced it at 330 Om, and now all work fine.

"1pps" and "Slave" switches combination doesn't work, because U26 switch 
doesn't pass 26MHz further down the path.

I think wiring one of the CE_n line from SRAM to FPGA would be useful.
If pins on the FPGA are missing, adv_ld_n or oe_n could be removed.

Cause:
Output DC offset of clock disributor SI5330F (U5) and LMS PLLCLK input are a 
bit different, even they have similar supply voltage, therefore AC coupling 
required.
Also, possible LC filter (L6-C45) make LMS noise worse too.
Also, engineers of Lime Micro recommends us to use PLL loop filter 100kHz 
instead of 50kHz and charge pump current 0.4mA instead of default 1.6mA.
Smaller current required to decrease fractional spurs and improve noise, but 
possible can increase integral phase noise of LO and possible make modulation 
accuracy a bit worse.
Therefore it should be tested.

Workaround OR Fix:
Replace L6-1 and L6-2 by 0.01 - 0.1uF capacitor instead of choke.
Remove capacitors C45-1, C45-2.

Fix Result:
LMS LO noise improvement about 6-12 dB.
Pictures included.

Discuss, Recomends OR Questions:
1) Avoid to use components with different cases if their type the same.
Sylvain asks why used Case-B for C317? Of cause, its should be Case-A and 10V 
enough. It will be done next PCB version.

2) Searching alternative SMD components instead of thru-hole as possible.
Sylvain recomends to use SMD connector WM3594DKR for JTAG. It will be done next 
PCB version (and mezzanine connector will be changed too).

3) Remove (or don't assembly) most of components that are used for the first 
debug only.
Alexander informs us that X12 is a debug connector and is not really needed...

Cause:
Measurement of VSWR shows that U_FL (UMC) connection becomes unstable right 
after few connections (two-three additional pushing's required, to get good 
connection).

Workaround OR Fix:
In UmTRXv2.2 all U_FL could be replaced by the SMD type MMCX connectors.
Also through hole components, like right-angle SMA, are expensive to soldering 
in production, so there also could be used MMCX connectors.