Context
I'm porting openwifi to LibreSDR rev.5, building
the FPGA design from this repo's libresdr branch (Vivado 2021.2), and building the
kernel/driver stack from source (both an ADI-Kuiper-based image and a Buildroot image).
The FPGA build, kernel, and driver all load and run correctly; hostapd brings up an AP
and the interface is fully operational at the driver level.
Symptom
A real client (phone/laptop) can authenticate with the AP (802.11 Open System auth
succeeds), but association never completes reliably — the client repeatedly re-auths,
or times out on inactivity, or the AP reports "did not acknowledge authentication
response" for its own TX. This is 100% reproducible across two independently built
OS images (different kernel/rootfs/driver builds), on two different physical LibreSDR
rev.5 units, regardless of which antenna port is used or which channel (2.4GHz or 5GHz).
Diagnostics already done
- FPGA timing: Vivado's routed timing summary shows
WNS=+0.125ns, 0 failing
endpoints out of 134,576 — "All user specified timing constraints are met." Digital
logic timing closure is not the issue.
- RX front-end is alive: reading
/sys/bus/iio/devices/iio:device0/in_voltage0_rssi
repeatedly shows it fluctuating meaningfully (e.g. 87–116 "dB" raw units over a few
seconds), so the AD9363 is clearly sensing real, varying RF power.
- Not a squelch/threshold issue: lowering openwifi's RX power-detect threshold from
the default -95dBm to -100dBm made no difference.
- Scan finds nothing real:
iw dev sdr0 scan sweeps all 2.4GHz+5GHz channels
correctly (confirmed via driver logs tuning through every channel), but detects zero
of 4+ real, independently-confirmed nearby Wi-Fi networks.
Taken together (power is detected, but OFDM demodulation/sync never locks onto a real,
present 802.11 signal), this looks like a carrier frequency offset problem — the LO
frequency being meaningfully off from what the receiver's CFO correction range can
handle — rather than a digital logic or driver bug.
What I found in the rev.5 schematic
On the clock sheet, U12 is a DAC5311 (single-channel, volatile SPI DAC), driven by
CLK_DAC_CS# / CLK_DAC_SCLK / CLK_DAC_SDI, whose output (VOUT) feeds
VCTCXO_VFC — i.e. the reference oscillator's frequency-control voltage. Since the
DAC5311 has no non-volatile memory, its output resets on every power cycle and needs to
be programmed at boot to get the VCTCXO to its calibrated frequency.
I could not find any code in openwifi, nor in plutosdr-fw_0.37_libre, that programs
this DAC.
Question
- Is there a documented/expected trim value (or a fixed default that should be
"close enough") for this DAC on rev.5 boards, or is it factory-calibrated per unit?
- If per-unit, what's the calibration procedure (e.g. is there a value written
somewhere in flash/EEPROM at manufacturing that a driver is expected to read and
replay to the DAC at boot)?
- Is there existing reference code (U-Boot, kernel driver, or userspace) anywhere in
the official LibreSDR firmware that's supposed to handle this, that I might have
missed?
Happy to share full boot logs, the FPGA .xsa, or run any test on real hardware —
I have two rev.5 units available for testing.
Context
I'm porting openwifi to LibreSDR rev.5, building
the FPGA design from this repo's
libresdrbranch (Vivado 2021.2), and building thekernel/driver stack from source (both an ADI-Kuiper-based image and a Buildroot image).
The FPGA build, kernel, and driver all load and run correctly; hostapd brings up an AP
and the interface is fully operational at the driver level.
Symptom
A real client (phone/laptop) can authenticate with the AP (802.11 Open System auth
succeeds), but association never completes reliably — the client repeatedly re-auths,
or times out on inactivity, or the AP reports "did not acknowledge authentication
response" for its own TX. This is 100% reproducible across two independently built
OS images (different kernel/rootfs/driver builds), on two different physical LibreSDR
rev.5 units, regardless of which antenna port is used or which channel (2.4GHz or 5GHz).
Diagnostics already done
WNS=+0.125ns, 0 failingendpoints out of 134,576 — "All user specified timing constraints are met." Digital
logic timing closure is not the issue.
/sys/bus/iio/devices/iio:device0/in_voltage0_rssirepeatedly shows it fluctuating meaningfully (e.g. 87–116 "dB" raw units over a few
seconds), so the AD9363 is clearly sensing real, varying RF power.
the default -95dBm to -100dBm made no difference.
iw dev sdr0 scansweeps all 2.4GHz+5GHz channelscorrectly (confirmed via driver logs tuning through every channel), but detects zero
of 4+ real, independently-confirmed nearby Wi-Fi networks.
Taken together (power is detected, but OFDM demodulation/sync never locks onto a real,
present 802.11 signal), this looks like a carrier frequency offset problem — the LO
frequency being meaningfully off from what the receiver's CFO correction range can
handle — rather than a digital logic or driver bug.
What I found in the rev.5 schematic
On the clock sheet, U12 is a DAC5311 (single-channel, volatile SPI DAC), driven by
CLK_DAC_CS#/CLK_DAC_SCLK/CLK_DAC_SDI, whose output (VOUT) feedsVCTCXO_VFC— i.e. the reference oscillator's frequency-control voltage. Since theDAC5311 has no non-volatile memory, its output resets on every power cycle and needs to
be programmed at boot to get the VCTCXO to its calibrated frequency.
I could not find any code in openwifi, nor in
plutosdr-fw_0.37_libre, that programsthis DAC.
Question
"close enough") for this DAC on rev.5 boards, or is it factory-calibrated per unit?
somewhere in flash/EEPROM at manufacturing that a driver is expected to read and
replay to the DAC at boot)?
the official LibreSDR firmware that's supposed to handle this, that I might have
missed?
Happy to share full boot logs, the FPGA
.xsa, or run any test on real hardware —I have two rev.5 units available for testing.