Calibration table generation hangs, performance issues #362
Comments
|
When you're using the table, it's with the same gain values used when generating the table, correct? _Update:_ It was later confirmed on IRC that the values were not correct due to a missed Could you quantify the difference between the I/Q DC offset values for no correction, the I know that the table isn't always as effective across power cycles as a cal done at every power cycle, but I'd just like to get a sense of what types of values you're seeing. For the error/freeze, could you share a verbose log? |
|
Just another item I wanted to verify with regard to the poor perfomance -- you're running The We've seen that the I/Q DC correction values yield significantly different results when those LMS registers are either uninitialized or initialized to different values. |
|
Yes, I can confirm that the DC spike is substantial, and can lead to spurious out of channel emmission when using a PA, even after generating a table using cal dc table rx in 100kHz steps, at actual gain settings. The DC spike seems to be as large as the synthesized baseband emission, which wastes output power during narrowband TX. Also, the table generation will only work with USB2, and ALWAYS crashes using USB3. |
|
I haven't been able to reproduce the table crash with my USB 3 cards. Why don't we open a new issue to track that, as efforts on resolving that are likely orthogonal to improving. Please include a verbose log and some information about your system & USB 3 controller. Regarding the DC spike - do you have some before/after screen captures from a signal analyzer? Could you quantify the DC offset you're seeing? (Note that <= -60dB is within ~1 DAC bit...) I'll look to post back with some captures of what I'm seeing. |
|
Linux version 3.17.6-1-ARCH (builduser@foutrelis) (gcc version 4.9.2 (GCC) ) #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC 2014 CPU0: Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz (fam: 06, model: 3c, stepping: 03) USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04) Intel® Desktop Board DQ87PG - BIOS updated 10-1-14 BladeRF is latest gitCommand tunes wrong frequency and crashes... Failed calibrate command : bladeRF-cli -v verbose -i
|
jynik
changed the title
|
Marking this as a duplicate, as I believe this and #373 are the same or tightly coupled. |
|
I agree. Hoping rfdog agrees too and are able to confirm result whence issue is solved. |
|
Note to self - need to revisit this now that we found that there were some PLLs losing lock at certain temperatures and frequencies... may be related. |
|
Finally getting around to digging into this...sorry for the embarrassingly long delay folks. Been running master in Windows (libusb 1.0.19 backend) and have not seen the lockups that I see in Linux or OSX)... just thought this was an observation worth recording. |
|
Further research into this indicates that the problem is in firmware. It seems that the RX side is actually what locks up (this is used in the TX cal). This can be reproduced using the Once locked up, we can continue to use TX, but not RX. Reloading the FPGA has no effect, suggesting FX3 firmware may be the source of the problem. FW v1.6.1 does not appear to exhibit this, but v1.7.1 does. The latter introduced changes intended to flush the DMA channels upon restarting a stream -- I will be focusing on this change. |
|
As of 1154ef7, the calibration routines should no longer induce lockups. I've re-implemented them in a manner that does not repeated start/stop streams, so this can be avoided. The new implementation of the DC cal routines tends to yield better results, as they try a bit harder to yield results in the edge cases, and some other measure are taken to yield better results:
In general, the TX cal's been much better for me. However, I see that calibrating in loopback does not adequately account for the DC offset contribution from the PAs. Therefore, a future work will be to allow calibration via external loopback (as an opt-in option). I've tested this in MATLAB and found it to yield good results. |
It appears the values created by the calibrate table command are incorrect ; typically the DC spike is not removed, whereas it is removed when calling "cal dc rx" manually. Also the calibrate table command will sometimes fail with Error: Operation timed out, or remain frozen.
The text was updated successfully, but these errors were encountered: