VNA measurement doesn't deliver any plausible values, Official Red Pitaya OS VNA although does

[UpstairsCucumber]

Description of the setup:

Device:

Red Pitaya Stemlab 125-14 V1.0

SD card image:

• red-pitaya-alpine-3.18-armv7-20240204
• red-pitaya-alpine-3.18-armv7-20231004
• RedPitaya_OS_2.04-35_stable.img

Application:

VNA
Latest vna.py client

Other relevant information:

Description of the problem:

I'm not able to reproduce the same VNA Measurements, when using the VNA app on your images, as opposed to the
VNA on the official RedPitaya_OS (2.04)

Steps to reproduce the problem:

1. copy a red-pitaya-apline image (see description) on the SD Card
2. Start the VNA through the browser
3. Connect with the vna.py to the red pitaya
4. Calibrate
5. Connect an Antenna on the DUT Port with Resonance frequency around 35 Mhz
6. See under tab SWR no plausible values

Dear Pavel,

For a university project, where we tune and match Antennas, I'm trying to use your VNA Project on the Red Pitaya, but I'm not able to see any plausible measurements on the VNA of the Alpine Image, I've tried the official VNA Adapter for the Red Pitaya as well as Mini-Circuits Couplers.

How it should look like (using the Offical RedPitaya OS)

How the SWR on the VNA of the Alpine Images looks like:

Calibration steps of the "not working VNA" :
LOAD:

OPEN:

SHORT:

I understand that the issue is probably on my side, since the VNA of the Red Pitaya OS is basically your VNA, but since the Red Pitaya restarts when using your vna.c file on it, the red pitaya crashes, so they must have changed something.

I've discovered the issue by trying to generate the .bit file of the VNA myself and converting and transferring it to the red pitaya.
I've wrapped the block_design.tcl myself in vivado (using your make file, which lead to an error explaining that vna.gen couldn't be found, but it built the whole project, so i was able to wrap it myself) and added the constraints from your other projects (clock.xdc and ports.xdc).
I originally thought i made some mistakes here, but I've found your alpine images, where i could rule out, that i was using wrong files.
I've also tried older Red Pitaya Images and I've also revalidated the SWR (how it should look like) with the minivna-tiny and at the university with an Rohde&Schwarz VNA, so the DUT is not the issue either.
I have looked through all the issues on github on your account and on the redpitaya account and haven't found something regarding this topic either, except that it seems to work for other people.

So I kindly ask for your help on this topic, since I've not been able to fix it myself, and I'm stuck for a while now.
Maybe you can provide other things i can try out, why it seems to not work for me.
I will try out another redpitaya, if there is one available, again as well, but since the VNA on the RedPitayaOS seems to work, it doesn't seem to me like an RP issue.

I also wanna take the opportunity and thank you, for providing all this open source material surrounding FPGAs.

Best regards,
David

[pavel-demin]

Thank you for testing the VNA application and for finding this problem.

I cannot think of any better approach to understanding this problem than to compare the source codes of the two versions of the VNA application.

According to the commit number in vna/info/info.json, the source code for the VNA application version distributed with RedPitaya_OS_2.04-35_stable.img comes from this commit.

This code looks mostly similar to the code from the 20220322 release of this repository. Could you please check if this release works for you?

[UpstairsCucumber]

Thank you, for your fast response.

I've just tried the image version you suggested (red-pitaya-alpine-3.14-armv7-20220322.zip ) and it works! ( yay! =) )

Calibration Pictures

OPEN

SHORT

LOAD

SWR Working AGAIN

Thank you for your help!

Best regards,
David

[pavel-demin]

Thank you for testing the 20220322 release.

It looks like I introduced a bug into the VNA project in some changes that I made in 2023. I see a couple of suspicious changes in this commit.

I think that I now need to build a test setup to reproduce this problem and identify the exact change responsible for this problem.

[pavel-demin]

I found the source of the problem and fixed it with this commit.

[UpstairsCucumber]

Awesome, that is great news!
I also verified it, and it works again! =)

While trying it out, I noticed that I made your 2022 version slower by modifying it (I had removed the ADC2 channel and its related functionality), Your current version is twice as fast, so I’ll definitely revert my changes and stick with your updated version.

Thank you once again for your great work!

Best regards,
David

[pavel-demin]

Thank you for testing this fix. The fixed version is now in the new release.