Closed cpbridges closed 5 years ago
mhennerich
commented
6 years ago I guess you're observing emissions by the TX Quadrature Calibration. Please see here: https://wiki.analog.com/resources/tools-software/linux-drivers/iio-transceiver/ad9361#calibration_mode_controls
This calibration automatically runs if you tune the TX LO > 100 MHz from previous calibration point. This happens inside the driver, gr-iio only triggers it by flushing the TX lo setup to the device.
cpbridges
commented
6 years ago Many thanks for the reply @mhennerich!
So if I tune on Rx or Tx only by a few kHz (e.g. for satellite Doppler correction) or, say, up to 20 MHz to another channel, I can confirm this behaviour still occurs - even if I don't start or stop the flowgraph. Does this sounds right still?
Can you suggest the best way to move the centre frequency without the TXQC kicking in? Like a behaviour in a spec analyser that recals itself every 5 mins.
Happy to edit/review parts of code and report back if you suggest where to look!
73s Chris
Edit: I guess only: echo manual > calib_mode after logging in over serial?
tfcollins
commented
6 years ago When you change parameters on the block masks it will actually update a large number of parameters, which is probably why the calibrations get updated. You can try changing the LO alone through the IIO attribute directly like:
iio_attr -q -c ad9361-phy altvoltage0 frequency <some lo freq>
from your host. You can modify the calib_mode in the same way from your host.
With regards to the calibrations, only the RF DC, RX quad, and TX quad get updated when the LO changes more than 100MHz. When the sample rate is touched all of the calibrations are called again.
cpbridges
commented
6 years ago Hmm - that sounds good and I can create a script to work for me like this. Thanks @tfcollins!
If only there was a gr-iio block for only this though. 73s Chris
tfcollins
commented
6 years ago You could probably just create a simple python block without ports and a single callback function. Then put a system call to use iio_attr tool.
Or just modify the Pluto block's callback to use a different function that didn't update all the parameters.
cpbridges
commented
6 years ago Thank Travis, this is spot on - I used the following for my Tx line too:
iio_attr -q -c ad9361-phy altvoltage1 frequency <some lo freq>
So three last things: 1) iio_attr is very useful - but I cannot find where to set the Rx/Tx gains / levels.
I can see the output voltage channels (voltage0, voltage2, voltage3):
# iio_attr -c ad9361-phy | grep -i output
dev 'ad9361-phy', channel 'altvoltage1', id 'TX_LO' (output), found 8 channel-specific attributes
dev 'ad9361-phy', channel 'voltage3' (output), found 8 channel-specific attributes
dev 'ad9361-phy', channel 'altvoltage0', id 'RX_LO' (output), found 8 channel-specific attributes
dev 'ad9361-phy', channel 'voltage2' (output), found 8 channel-specific attributes
dev 'ad9361-phy', channel 'voltage0' (output), found 10 channel-specific attributesI'm guessing there are two for I and Q (voltage2 and voltage3) but it could be that 'raw' variable. But the following didn't work. What should I use to set the gain?
iio_attr -q -c ad9361-phy voltage2 raw <raw I ADC level>; iio_attr -q -c ad9361-phy voltage2 raw <raw Q ADC level>
2) I can create a bash script in vi to start with on this before I'll need to check out the Pluto's block callback. But I can't run it (in any location) as I have 'Permission denied'. Is there a location a bash script would work?
3) Could you point me to the callback file I should be looking at (in /gr-iio/lib?)?
Happy to share when complete :) 73s Chris
mhennerich
commented
6 years ago Use iio_info to list all channel-specific attributes...
voltage0: (output)
10 channel-specific attributes found:
attr 0: rf_port_select value: A
attr 1: hardwaregain value: -10.000000 dB
attr 2: rssi value: 0.00 dB
attr 3: hardwaregain_available value: [0 250 89750]
attr 4: sampling_frequency_available value: [2083333 1 61440000]
attr 5: rf_port_select_available value: A B
attr 6: filter_fir_en value: 0
attr 7: sampling_frequency value: 30720000
attr 8: rf_bandwidth_available value: [200000 1 40000000]
attr 9: rf_bandwidth value: 18000000
voltage0: (input)
15 channel-specific attributes found:
attr 0: hardwaregain_available value: [-3 1 71]
attr 1: hardwaregain value: 71.000000 dB
attr 2: rssi value: 115.00 dB
attr 3: rf_port_select value: A_BALANCED
attr 4: gain_control_mode value: slow_attack
attr 5: rf_port_select_available value: A_BALANCED B_BALANCED C_BALANCED A_N A_P B_N B_P C_N C_P TX_MONITOR1 TX_MONITOR2 TX_MONITOR1_2
attr 6: rf_bandwidth value: 18000000
attr 7: rf_dc_offset_tracking_en value: 1
attr 8: sampling_frequency_available value: [2083333 1 61440000]
attr 9: quadrature_tracking_en value: 1
attr 10: sampling_frequency value: 30720000
attr 11: gain_control_mode_available value: manual fast_attack slow_attack hybrid
attr 12: filter_fir_en value: 0
attr 13: rf_bandwidth_available value: [200000 1 56000000]
attr 14: bb_dc_offset_tracking_en value: 1Please see also here: https://wiki.analog.com/resources/tools-software/linux-drivers/iio-transceiver/ad9361
General attribute naming convention: involtage0[…]: targets RX1 involtage1[…]: targets RX2 (AD9361 in 2RX2TX mode only)
outvoltage0[…]: targets TX1 outvoltage1[…]: targets TX2 (AD9361 in 2RX2TX mode only)
outaltvoltage0[…]: targets RX LO outaltvoltage1[…]: targets TX LO
The phy device doesn't handle I&Q channels ...
It's the:
iio:device4: cf-ad9361-lpc (buffer capable)
2 channels found:
voltage0: (input, index: 0, format: le:S12/16>>0)
6 channel-specific attributes found:
attr 0: calibphase value: 0.000000
attr 1: calibbias value: 0
attr 2: calibscale value: 1.000000
attr 3: samples_pps ERROR: No such device (-19)
attr 4: sampling_frequency_available value: 30720000 3840000
attr 5: sampling_frequency value: 30720000
voltage1: (input, index: 1, format: le:S12/16>>0)
6 channel-specific attributes found:
attr 0: calibbias value: 0
attr 1: calibphase value: 0.000000
attr 2: calibscale value: 1.000000
attr 3: samples_pps ERROR: No such device (-19)
attr 4: sampling_frequency_available value: 30720000 3840000
attr 5: sampling_frequency value: 30720000
2 buffer-specific attributes found:
attr 0: watermark value: 2048
attr 1: data_available value: 0
2 debug attributes found:
debug attr 0: pseudorandom_err_check value: CH0 : PN9 : Out of Sync : PN ErrorCH1 : PN9 : Out of Sync : PN Error debug attr 1: direct_reg_access value: 0x0
Where voltage0 is I and voltage1 is Q ... Same for the TX core:
iio:device3: cf-ad9361-dds-core-lpc (buffer capable)
6 channels found:
voltage0: (output, index: 0, format: le:S16/16>>0)
4 channel-specific attributes found:
attr 0: calibscale value: 1.000000
attr 1: calibphase value: 0.000000
attr 2: sampling_frequency_available value: 30720000 3840000
attr 3: sampling_frequency value: 30720000
voltage1: (output, index: 1, format: le:S16/16>>0)
4 channel-specific attributes found:
attr 0: calibphase value: 0.000000
attr 1: calibscale value: 1.000000
attr 2: sampling_frequency_available value: 30720000 3840000
attr 3: sampling_frequency value: 30720000
altvoltage3: TX1_Q_F2 (output)
5 channel-specific attributes found:
attr 0: raw value: 1
attr 1: phase value: 0
attr 2: frequency value: 9279985
attr 3: scale value: 0.000000
attr 4: sampling_frequency value: 30720000
altvoltage1: TX1_I_F2 (output)
5 channel-specific attributes found:
attr 0: phase value: 90000
attr 1: scale value: 0.000000
attr 2: raw value: 1
attr 3: frequency value: 9279985
attr 4: sampling_frequency value: 30720000
altvoltage0: TX1_I_F1 (output)
5 channel-specific attributes found:
attr 0: phase value: 90000
attr 1: scale value: 0.000000
attr 2: frequency value: 9279985
attr 3: raw value: 1
attr 4: sampling_frequency value: 30720000
altvoltage2: TX1_Q_F1 (output)
5 channel-specific attributes found:
attr 0: raw value: 1
attr 1: phase value: 0
attr 2: frequency value: 9279985
attr 3: scale value: 0.000000
attr 4: sampling_frequency value: 30720000
2 buffer-specific attributes found:
attr 0: watermark value: 2048
attr 1: data_available value: 0
1 debug attributes found:
debug attr 0: direct_reg_access value: 0x90062mni 73 de DL6SEG
cpbridges
commented
6 years ago Good webpage. For the Tx gain, I use:
# iio_attr -c ad9361-phy voltage0 hardwaregain -40
dev 'ad9361-phy', channel 'voltage0' (input), attr 'hardwaregain', value '-1.000000 dB'
wrote 4 bytes to hardwaregain
dev 'ad9361-phy', channel 'voltage0' (input), attr 'hardwaregain', value '-1.000000 dB'
dev 'ad9361-phy', channel 'voltage0' (output), attr 'hardwaregain', value '-30.000000 dB'
wrote 4 bytes to hardwaregain
dev 'ad9361-phy', channel 'voltage0' (output), attr 'hardwaregain', value '-40.000000 dB'Just Questions 2 and 3 in the previous post to resolve :)
73s Chris
tfcollins
commented
6 years ago Are you trying to run it on Pluto or your local machine?
The mask callbacks are defined in the GRC xml files: https://github.com/analogdevicesinc/gr-iio/blob/master/grc/iio_pluto_source.xml#L9 Actual callback: https://github.com/analogdevicesinc/gr-iio/blob/master/lib/pluto_source_impl.cc#L95
cpbridges
commented
6 years ago tfcollins
commented
6 years ago cpbridges
commented
6 years ago tfcollins
commented
6 years ago This seems really strange. Are you just opening vi and pasting your script? What firmware version are you running?
tfcollins
commented
5 years ago Issue has gone stale. Closing for now.
Hi gr-iio wizards,
I'm investigating the transmit function of gr-iio for a pluto and I see the following behaviour:
I'm guessing this is some sort of self calibration at the beginning using the older LO value.
Can someone explain where this would appear in the code to correct as I do not want to see this maximum drive level at the same?
I'm running the new 0.27 firmware.
73s Chris