Several problems about Openwifi porting to AD936X on PYNQ-Z1 (2rx-2tx mode, 2.4G scan, TX channel, failed timing)

[regymm]

0. Could you send email to xianjun.jiao@ugent.be to introduce your self? I'm the author of #99 and my extension board is finally working. Now I'm trying to port Openwifi firmware. You already know my Telegram @regymm0 :-)

1. Our image is used directly or you build your own image? My own.

2. What is your own modification? Linux kernel/rootfs: no except minor(like debug serial to UART0 instead of UART1) openwifi-hw: modified according to my own based on antsdr, TX interface is singled ended on FPGA side and converted to LVDS using driver chip, so adi-hdi axi_ad9361 OBUF is slightly modified. timing failed. openwifi: device tree modified, ad9361 part same as antsdr except 2rx-2tx is disabled -- if this is enabled, RX/TX tuning will fail on high sample rate.

3. Versions: OS, Vivado, openwifi/openwifi-hw repo branch and commit revision ArchLinux, Vivado 2019.1, openwifi/openwifi-hw master, adi-hdl is using plutosdr-fw master branch because openwifi-hw compilation crash on Vivado 2019.1. Other using default.

4. Board/hardware type Self-designed AD9363 on xc7z020 @ PYNQ-Z1, LVDS interface. PlutoSDR firmware already ported without any problem. RX and TX auto-tuning OK at 61440000 sample clock.

Now what works: ~/openwifi/fosdem.sh successfully end, showing that AP enabled. Then I run wdg.sh and iw dev sdr0 scan, the 5G wifi spot in my home is shown(this is the only 5G spot nearby). Though my balun is only 0-3G(hard to get a better now).

Problems:

2rx-2tx mode: since if I enable this tuning will fail, I have to disable this. And there're some no-such-file error because of this, but I guess Openwifi don't need 2 RX and 2 TX anyway? Is there any other options to modify in this case?

2.4G scan: I don't know how to scan 2.4G wifi signals. No matter what I do (like following #114), only the 5G one is shown in iw scan though there're more stronger 2.4G signals nearby. I see in rf_init.sh there are 5G frequencies being set as LO frequency, is this related?

TX channel: though fosdem.sh run successfully(default 5G or #107), I cannot see the hotspot on my phone. In rf_init.sh I can see TX gain is set from -89dB to -dB on the TX2 port(in_voltage1_xxx). However, I only have TX1(in_voltage0_xxx). I modified this manually but still no luck. Seems output defaults to TX1 which is not my case. Can I modify this? I don't have a spectrum meter, how can I know if there's actually something sending out of TX port?

failed timing: I'm using antsdr's Vivado project with no modification other than the ZYNQ PS itself and output OBUFs. Yet timing failed, WNS -0.692ns TNS -97.949ns. Update: timing passed after tweaking compile strategies, other problems remain.

And I'm getting handle_probe_req: send failed when trying to connect to my 5G spot using wpa_supplicant -i sdr0 -c wpa-connect.conf, which, of course failed because my TX certainly have some problem now.

Here's my log when running fosdem.sh: https://gist.github.com/regymm/7fcdfade09dcef3710881462bd9b5e1f

Any help is appreciated!

[JiaoXianjun]

Great news!

Here are some replies/comments:

openwifi: device tree modified, ad9361 part same as antsdr except 2rx-2tx is disabled -- if this is enabled, RX/TX tuning will fail on high sample rate.

-- According to https://github.com/analogdevicesinc/linux/blob/b6e379910a11af77e6500ed8b0895006e471a279/drivers/iio/adc/ad9361_conv.c#L466 , the auto tuning covers 25/40/61.44M. Do you know it fails at which rate? You can remove 61.44M on purpose, if it fails.

-- About vivado 2019.1, indeed it needs some work to upgrade openwifi-hw for it. So far we only tried it internally based on the ADI's kuiper release for zcu102. Not sure how much work will be needed for normal zynq7000 FPGA.

Self-designed AD9363 on xc7z020 @ PYNQ-Z1, LVDS interface. PlutoSDR firmware already ported without any problem. RX and TX auto-tuning OK at 61440000 sample clock.

-- But you said "RX/TX tuning will fail on high sample rate."?

Now what works: ~/openwifi/fosdem.sh successfully end, showing that AP enabled.

-- Can you connect to this openwifi AP from your phone/pad/computer?

2rx-2tx mode:

-- I remember that it is defined in the devicetree. We use this mode on purpose no matter it is ad9361/3/4, because we don't want to change the I/Q data interleaved mode on the link which needs different FPGA side interface/ad9361-ip setting (I might be wrong). So always using 2rx-2tx mode brings us the maximum compatibility on different RF chips (9361/3/4).

2.4G scan:

-- Normally when you scan Linux will tune the RF to all channels/bands supported sequentially by calling ieee80211_ops/config --> openwifi_config --> ad9361_rf_set_channel. You can see this tuning procedure/log by running dmesg after you run "iwlist sdr0 scan".

TX channel: though fosdem.sh run successfully(default 5G or #107), I cannot see the hotspot on my phone. In rf_init.sh I can see TX gain is set from -89dB to -dB on the TX2 port(in_voltage1_xxx). However, I only have TX1(in_voltage0_xxx). I modified this manually but still no luck. Seems output defaults to TX1 which is not my case. Can I modify this? I don't have a spectrum meter, how can I know if there's actually something sending out of TX port?

-- You don't need to modify rf_init.sh, because the sdr.c will set the TX channel attenuation under the Linux instruction (such as rfkill, ifconfig sdr0 up/down, etc.). To debug, after you run fosdem-11ag.sh (use fosdem-11ag.sh instead of fosdem.sh to have the most robust/reliable config), then check "cat /proc/interrutps" (this app note: https://github.com/open-sdr/openwifi/blob/master/doc/app_notes/ap-client-two-sdr.md). You can also check driver tx and rx messages by https://github.com/open-sdr/openwifi/blob/master/doc/README.md#debug-methods (you can set register value to 7 instead of 3 in the example to see the beacon tx in the dmesg. You can also see the rx message when you scan by iwlist or monitor a busy wifi channel. Check this monitor and packet injection app note: https://github.com/open-sdr/openwifi/blob/master/doc/app_notes/inject_80211.md )

-- Please share your discoveries (like the interrupt number screenshot) and dmesg outputs, if you want us to analyze the issue.

[regymm]

Thanks for your reply. I tried these debugging methods a little bit but still no luck.

About 2rx-2tx mode and tuning: If I disable this mode(remove this line from device tree), RX and TX tuning are both OK. If I enable this, RX will fail when sample rate gets higher than ~40M, and TX will always fail even at 3M sample rate. This may be related to my PCB signal integrity. I'm curious if Openwifi can still run with this line of device tree disabled.

Hotspot: Though shown AP enabled, I cannot find the Openwifi hotspot on any of my devices.

2.4G scan: Here is a dmesg log when scanning. For me it looks like many weak signals are scanned but not reported.

TX channel: When I run fosdem-11ag.sh, I can see interrupt number growing in /proc/interrupt. And the dmesg after running the script is here. After this dmesg, I waited for a while and no more related dmesg were printed. Scripts are all unmodified.

Others: I can change LO frequency in /sys/bus/iio/devices/iio:device1/, and right after the board got powered on, I change LO to 80MHz, and can get a modulated 80MHz sine wave with >50mV peak-peak voltage on TX port via SMA cable to my 100MHz oscilloscope(in normal measure mode because my scope doesn't support 50R impedance). After Openwifi hotspot enabled, I, again, manually change LO to 80MHz, but now there's absolutely no signal on TX port anymore. So, I guess, there's no signal transmitted on TX now. Though I don't know why.

[regymm]

Considering this, I'll first try installing Vivado 2018.3 and try in fresh environment if there's any tuning fail any more.

[JiaoXianjun]

Vivado version is important for HDL design. Even you target plutoSDR's HDL design, you need to stick to the Vivado version they suggested. We have observed that the same HDL performs different (timing) in different Vivado versions.

[regymm]

The 2018.3 Vivado results the same. I found in AD936X datasheet that in LVDS mode, "The maximum DATA_CLK rate is increased to 245.76 MHz"(UG570, page 108). And I do noticed a clock speed of 4x sample rate when performing tuning. This is certainly more than my board's TX path could handle. So this is why TX tuning failed, and there's not much hope on this version of my board(though making a next one will cost little because I have abundant components now).

So can Openwifi work with, like, under 61.44 MHz data rate? Seems it can be inferred in UG570 that if we stick to 1R1T config and don't use 2x oversampling, clock rate will be under control(and my board can do this, since tuning OK in 1R1T at 61.44MHz). Especially, will everything work with adi,2rx-2tx-mode-enable; commented out in device tree? I don't have other capable hardware so can't try this myself now. I think this is the major challenge in my case now.

[JiaoXianjun]

I can try.

But can you check firstly that we simply remove "adi,2rx-2tx-mode-enable;"? What does this mean, and shall we add a different config instead? Like 1rx-1tx sth?

Can you run plutoSDR test successfully when commenting out the "adi,2rx-2tx-mode-enable;"? What is the result? For instance, you can try to loop back the signal over the air (or coaxial cable) and see some sine wave or spectrum sent by yourself at specific carrier frequency with specific bandwidth/sampling rate setting.

[regymm]

I think just simply remove "adi,2rx-2tx-mode-enable;" is enough.

On pluto, when no "adi,2rx-2tx-mode-enable;" is present(the default case), RX and TX tuning will all pass, and I can see signal spectrum received over antenna is similar to BIST digital "internal loopback". And I can see modulated sine wave on scope. When "adi,2rx-2tx-mode-enable;" is added and RX & TX tuning skipped, I cannot get any feedback even in BIST digital loopback.

[JiaoXianjun]

In the pluto mode (with 2tx 2rx removed), what is the highest baseband sampling rate you can achieve in the successful BIST test?

[regymm]

Pluto 1RX 1TX (and also Openwifi 1RX 1TX) the self-tuning covers roughly 25M to 61.44M, and my board can pass at 61.44M. I don't think there's higher sampling rate tests.

[JiaoXianjun]

Your 61.44M is the baseband sampling rate? or the rate of DATA_CLK?

According to the figure in page 110, in 1t1r mode if the DATA_CLK is 61.44M, then the sampling rate (one sample needs 12bit I and 12bit Q) will be 61.44/2M, which is lower than the openwifi baseband sampling rate 40M.

Can you achieve DATA_CLK 80M, which means 40M baseband sampling mode in 1t1r mode.

If yes, then we don't need to change the openwifi baseband sampling rate 40M, and only go for 1t1r mode. If not, then we need to change the openwifi baseband sampling rate to 20M, which implies 40M DATA_CLK in 1t1r mode.

[regymm]

Though I'm not very sure about the detail of tuning process, I performed a tuning at 61440000 sample frequency(maximum possible), everything passed, and I captured this on my scope: DATA_CLK is showing 120MHz(low amplitude because it's near my scope's limit). Seems in the tuning they have already taken the 2x clock frequency into account. In this case, 80M can be achieved without problem.

And do you mean openwifi code need extra modification? I'll try reading/modifying related parted if needed.

[regymm]

After further debugging, I'm sorry to tell that the previous assumptions are a little bit wrong.

In pluto BIST loopback tests, error will occur when TX amplitude reaches the MSB part. In the picture, the red line is -37 dB scale, and the green is -35 dB scale, the difference is easy to see. I counted that there are only 64 values aka 6 bits, so my assumption is the I/Q sequence got interpreted wrong and somehow MSB is always zero.

I'm still looking into these. It's quite strange given that RX and TX tuning all passed.

[JiaoXianjun]

I tested the 1rx-1tx mode on antsdr (by commenting out the 2rx-2tx in the devicetree). It works fine. I can connect my phone to the openwifi AP on antsdr.

I confirm the new devicetree is loaded on board Linux by:

cat /proc/device-tree/amba/spi******/ad9361-phy******

You can see all the devicetree items there. During my test there isn't adi,2rx-2tx-mode-enable. Normally there is such a item, if the 2rx-2tx is not commented out.

[JiaoXianjun]

From your openwifi board, you can discover other wifi AP's name/ssid, right? Can you confirm further for the rx channel by using the monitor mode? https://github.com/open-sdr/openwifi/blob/master/doc/app_notes/inject_80211.md

Simply run onboard:

./wgd.sh
./monitor_ch.sh sdr0 6 (you can change this channel 6 to other indented channel, where you know there are WiFi AP and traffic)
tcpdump -i sdr0

If you see lots of meaningful packet (some with bad fcs others not), that means your rx channel (from antenna to openwifi baseband demodulator till driver and linux) works fine. Then the problem could be with your tx channel, since you never discover the openwifi AP on other devices.

I think the lvds data and clk rate are the same for rx and tx channel, so it is strange. Because if the rx channel works fine, that means your board/hardware has the capability to handle the lvds clk and data signal. Maybe you need to check the design and hardware about what is the difference between the rx and tx on your board. You can try to insert some FPGA ila to check how does the tx and rx channel I/Q sample and FPGA internal clk (the name is the adc clk inside FPGA) look like.

We add ila like in this issue: https://github.com/open-sdr/openwifi-hw/issues/39

[JiaoXianjun]

After further debugging, I'm sorry to tell that the previous assumptions are a little bit wrong.

In pluto BIST loopback tests, error will occur when TX amplitude reaches the MSB part. In the picture, the red line is -37 dB scale, and the green is -35 dB scale, the difference is easy to see. I counted that there are only 64 values aka 6 bits, so my assumption is the I/Q sequence got interpreted wrong and somehow MSB is always zero.

I'm still looking into these. It's quite strange given that RX and TX tuning all passed.

Seems like a amplitude overflow, but overall seems OK. You are using 31M sampling rate in the figure, what about 40M?

[regymm]

Glad to know 1R1T also works on stock boards. I think monitor mode seems good, here's a piece of log:

00:10:20.102280 33025502us tsft 12.0 Mb/s 2452 MHz 11g -14dB signal antenna 0 Clear-To-Send RA:74:29:af:28:77:7b (oui Unknown) 
00:10:20.102411 33025637us tsft 24.0 Mb/s 2452 MHz 11g -15dB signal antenna 0 Acknowledgment RA:74:29:af:28:77:7b (oui Unknown) 
00:10:20.105058 33028283us tsft 24.0 Mb/s 2452 MHz 11g -16dB signal antenna 0 Request-To-Send TA:c8:3a:35:b0:e8:61 (oui Unknown) 
00:10:20.129989 33053213us tsft 24.0 Mb/s 2452 MHz 11g -14dB signal antenna 0 Request-To-Send TA:c8:3a:35:b0:e8:61 (oui Unknown) 
00:10:20.130551 33053775us tsft 24.0 Mb/s 2452 MHz 11g -14dB signal antenna 0 Request-To-Send TA:c8:3a:35:b0:e8:61 (oui Unknown) 
00:10:20.146132 33069357us tsft 24.0 Mb/s 2452 MHz 11g -14dB signal antenna 0 Acknowledgment RA:74:29:af:28:77:7b (oui Unknown) 
00:10:20.164056 33087276us tsft 12.0 Mb/s 2452 MHz 11g -13dB signal antenna 0 Clear-To-Send RA:74:29:af:28:77:7b (oui Unknown) 
00:10:20.164185 33087411us tsft 24.0 Mb/s 2452 MHz 11g -14dB signal antenna 0 Acknowledgment RA:74:29:af:28:77:7b (oui U

It's true my board's TX and RX wiring are quite different. RX is short and direct while TX is driven single-ended in FPGA and converted to LVDS using external chip. In tuning I can see "open area" for RX is bigger than TX, but TX tuning also pass.

About the BIST waveform, it's the same at 40M sample rate.

Though I still don't think it's amplitude overflow, as if I further increase scale(dBFS) it'll be like this:

And I can count there's only 64 values in the pictures -- just like 6-bits. It just feels like higher 6 bits are just missing.

[JiaoXianjun]

According to Each clock only transfers 6bits. Two clocks transfer the complete 12bits. It might be related to this, since you only have 6bits. Maybe due to the wrong TX_FRAME signal? It is always high or low?

[regymm]

You are right, my TX_FRAME was inversed. I don't know why TX tuning doesn't spot this. Now the pluto loopback test looks good(sine wave I/Q in both BIST self-loopback or antenna over the air). However I still can't see the Openwifi hotspot.

I did this debugging:

To see signals on my scope, after running fosdem-11ag.sh I manually changed LO frequency to 80 MHz (from 5 GHz), and get this signal. If I zoom in enough I can see the 80 MHz carrier frequency. I've never seen this before the TX_FRAME fix, so at least there's some improvement. The problem is the amplitude is so small(5mV per grid).

There's an parameter called "out_voltage0_hardwaregain" in /sys/bus/iio/devices and "Attenuation(dB)" on iio oscilloscope, default value is -10dB, and when Openwifi is enabled, this is set to 0dB. On my board, -10dB results in good transmit power while 0dB transmits nearly nothing. I want to set this to -10dB, but if I echo "-10" > out_voltage0_hardwaregain, I get the message rfkill: WLAN hard blocked and this parameter will drop to -89dB, and the signal on scope will disappear.

As a comparison, I also set LO frequency to 80 MHz right after board power on(when the out_voltage0_hardwaregain is still -10dB), and I can get this. It's 200mV per grid!

So can I keep the out_voltage0_hardwaregain negative without getting WLAN hard blocked?

[JiaoXianjun]

The first figure waveform looks like WiFi packet very much!

To control the ad9361 tx attenuation, you can change

#define AD9361_RADIO_ON_TX_ATT 000

in sdr.h. Then recompile the driver and copy the driver onboard (https://github.com/open-sdr/openwifi#update-driver). We will have a release soon to let user change it via sdrctl command on board without recompiling the driver.

For 3dB attenuation, you need value 3000 For 10dB attenuation, you need value 10000

Since the chip has better performance in 2.4GHz, I suggest you test in 2.4GHz by changing on board hostapd-openwifi-11ag.conf

hw_mode=g
channel=6

Then run fosdem-11ag.sh again. Hope this will help other device discover openwifi SSID.

[regymm]

After the changes the signal strength increase ~10 times. But still, SSID can't be found.

Now, there's still one thing uncommon: though I can monitor all channels covering 2.4G and 5G, when doing iwlist scan, only 5G spot is shown. I don't know why. Maybe debugging this is a starting point?

Other debugging methods plausible that I'll try if have time: 1. solder another extension board and compare if there's any chip or hardware difference. 2. try porting iio-oscilloscope(server on board?) to Openwifi Linux firmware, so I can possibly monitor transmission quality at 2.4G directly.

[JiaoXianjun]

Hi,

1. Your tcpdump shows quite big RSSI (-14dB). It seems strange. Normally it hardly can achieve such high. So, I suspect the RSSI measurement, which needs FPGA baseband work with AD9361 CONTROL OUTPUT pins (UG-570 rev A p73), has issue. Could you check the CONTROL OUTPUT wire/pin between AD9361 and FPGA?

2. If the RSSI measurement has issue, it could mess up the CSMA/CA engine (RSSI based CCA). So to debug the TX, we'd better turn off the CSMA/CA and rx totally, and transmit some packet via packet injection (https://github.com/open-sdr/openwifi/blob/master/doc/app_notes/inject_80211.md). In that app note, you can replace "-n 10" by "-n 99999" to give you continuous packet sending in channel 11 to the air. Before running the injection program, you also need to do extra setting as we suggested here: https://github.com/open-sdr/openwifi/issues/117#issuecomment-965072537 . While the injection is running, you can use another device (Raspberry PI, laptop, computer) which can run wireshark or tcpdump over monitor mode in channel 11. If you see lots of packet sent by openwifi (with MAC address 66:55:44:33**), that means the TX path is OK

3. Would you please also run the IQ capture app note? That allows you see the I/Q sample (could be from RX or FPGA internal TX), AD9361 CONTROL OUTPUT (AGC gain) and RSSI in real-time. Since your FPGA is 7020, so pay attention to those notes for small FPGA in that app note. The IQ source selection logic is here: https://github.com/open-sdr/openwifi-hw/blob/70d7b29e87866b7e51324ed547fb6d75725cf38d/ip/side_ch/src/side_ch_control.v#L268 . It goes to the side_ch module register 5 -- slv_reg5[2:1]: https://github.com/open-sdr/openwifi-hw/blob/70d7b29e87866b7e51324ed547fb6d75725cf38d/ip/side_ch/src/side_ch.v#L258 . To change the value of slv_reg5[2:0], you can use "./side_ch_ctl wh5dX" as in that app node. Attention, the I/Q source is controled by [2:1], the [0] is for free running option (check the app note).

You can check the captured I/Q by Matlab WLAN toolbox, or share the file here for us to check.

[regymm]

I tried these but still no luck.

1. I didn't capture waveform on the 8 control output pins one by one, but there's no apparent wiring problem. The -14dB RSSI is when my board is close to my router. It'll be -1dB when their antennas are next to each other. When I monitor on other channels, usually RSSI is ranging from -80dB to -30dB.

2. I followed this but cannot see any related packages in Wireshark. My dmesg after sending some packages seems different from #117 case: I only got messages similar to last three lines, previous openwifi_tx: xxx can't be found in my case even drv_tx 7 7 set.

I got this on scope (setting LO to 80M).

3. I followed notes for small FPGA, but ./side_ch_ctl g gave me a segfault. This works. Here's some screenshots of python graphs and MATLAB analysis.

[JiaoXianjun]

In the scope picture, how long is each grid? 20us? If so, seems like your tx sampling rate is half of requirement. We need 40M, but yours seems like 20M. Because according to https://github.com/FCAE/WLAN/blob/master/doc/802.11-2012.pdf (18.3.3) , at the beginning STF is 8us then followed by 8us LTF. Yours seems like 16us (if 20us/square on the screen)

Can you share me the raw iq file captured by you? Please capture the tx_intf iq by “./side_ch_ctl wh5d4” before your capture.

[regymm]

Yes, the problem was with sample rate: after tweaking some HDL parameters now things worked -- the STF becomes 8us and I can connect to Openwifi AP, as well as use the board to connect to my home's wifi, ping each other, and see the welcome webserver in both case.

Thanks a million for your kind and timely guide and this Openwifi project!

Here's my board setup if you're curious :-)

There still remain some problem, but I guess it's probably my RF frontend design. It's actually just the thing from very beginning -- I cannot scan 2.4G wifi spots. Only 5G spot is shown. If I set hw_mode=g channel=6 or other 2.4G band channel, I can find the openwifi hotspot but when I try to connect, I'll get this on my laptop:

[85830.755104] wlp3s0: authenticate with 66:55:44:33:22:79
[85830.759572] wlp3s0: send auth to 66:55:44:33:22:79 (try 1/3)
[85830.875167] wlp3s0: send auth to 66:55:44:33:22:79 (try 2/3)
[85830.877587] wlp3s0: authenticated
[85830.878209] iwlwifi 0000:03:00.0 wlp3s0: disabling HT/VHT/HE as WMM/QoS is not supported by the AP
[85830.878338] wlp3s0: associate with 66:55:44:33:22:79 (try 1/3)
[85830.965137] wlp3s0: RX AssocResp from 66:55:44:33:22:79 (capab=0x401 status=0 aid=2)
[85830.967597] wlp3s0: associated
[85830.969693] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
[85831.097908] wlp3s0: disassociated from 66:55:44:33:22:79 (Reason: 7=CLASS3_FRAME_FROM_NONASSOC_STA)
[85831.149434] wlp3s0: authenticate with 66:55:44:33:22:79
[85831.154139] wlp3s0: send auth to 66:55:44:33:22:79 (try 1/3)
[85831.261728] wlp3s0: send auth to 66:55:44:33:22:79 (try 2/3)
[85831.262747] wlp3s0: authenticated
[85831.263256] iwlwifi 0000:03:00.0 wlp3s0: disabling HT/VHT/HE as WMM/QoS is not supported by the AP
[85831.265039] wlp3s0: associate with 66:55:44:33:22:79 (try 1/3)
[85831.266454] wlp3s0: RX AssocResp from 66:55:44:33:22:79 (capab=0x401 status=0 aid=2)
[85831.268354] wlp3s0: associated
[85831.983460] wlp3s0: disassociated from 66:55:44:33:22:79 (Reason: 7=CLASS3_FRAME_FROM_NONASSOC_STA)

And this on board:

sdr0: STA 74:e5:f9:e5:6b:1d IEEE 802.11: did not acknowledge authentication response
sdr0: STA 74:e5:f9:e5:6b:1d IEEE 802.11: did not acknowledge authentication response
sdr0: STA 74:e5:f9:e5:6b:1d IEEE 802.11: did not acknowledge authentication response

And I can't let the board connect to other 2.4G spots as well. All my successful testing are in 5G band -- in the picture shown, the laptop get 2 slots of signal(4 slots if openwifi in 2.4G, but I can't connect). Weak but I'm still able to watch the test video with no lag.

This is interesting because my balun on board officially supports only up to 3G. Maybe in 2.4G transfer/receive RF signal quality get degraded? Can't conclude now.

Later, I'll convert my Altium Designer files based on this to KiCad and open-source them. About my ported code, it's a little bit messy and may not help much, so I haven't thought about how to share them yet. And if have further time I'll blog about my whole porting and debugging process, guess blogs will help more. Anyway, thanks again!

[regymm]

And of course, I'm glad to do more testings/give more captured data if needed!

[JiaoXianjun]

Hi,

This is really a great news! I foresee many many SDR hobbyists/enthusiasts can enjoy your super low cost SDR solution for PYNQ board!

The 2.4GHz issue is known issue. It could be related to our CSMA/CA engine design, since the 2.4GHz uses a slightly different low MAC parameters. So far, in deed we mainly work in 5GHz. So,

• For connected/signaling test with COTS device, for now please use 5GHz
• For non-connected/non-signaling test (such as packet injection or monitor only for some special purpose), both bands are OK.

For your 3GHz balun, I think it can't stop signal at 5GHz entirely. Maybe it only has several dB insertion loss at 5GHz (check your datasheet), so working in 5GHz is allowed (with slightly degraded performance).