Improvements proposal for future version

[bvernoux]

I think very nice improvements for a future version will be:

• To replace the Spartan6 to ECP5/ECP5-5G and use open source tools
• Add Ethernet with SCPI standard commands (compatible with other VNA ...) as it is very convenient to retrieve S2P, configure the VNA through Ethernet and keep USB of course.
• Improve the range 30 KHz to 7.2 GHz (if possible without breaking everything)
• Improve the dynamic range up to 100dB (if possible without breaking everything and keeping it compact like it is today) will be amazing to be on par with some ultra expensive VNA.

[diegoherranz]

+1 to use ECP5 and use the fantastic SymbiFlow project for less dependence on privative tools.

[jankae]

Thanks for the suggestions, I'll definitely keep them in mind. Here are some initial thoughts on the individual points:

• ECP5: I never really bothered to check for other FPGAs because I have used the Spartan6 before in other projects. It seems a bit dated compared to the ECP5 though and having the toolchain open source would be nice too. The only thing that concerns me bit is the package: they seem to be available only in BGA which I (and probably many others) can't solder reliably
• Ethernet: Excellent idea, if I ever make a redesign, I'll be sure to include it
• 30kHz to 7.2GHz: Not really possible without changing almost all RF components. The 1MHz limit is already below the specification of some chips and the main PLLs only go up to 6GHz (you can overclock them to about 6.2GHz but thats it)
• 100dB dynamic range: Sure would be nice ;) But I don't really know how to improve it without significantly increasing the size. But than again I still consider me somewhat of a beginner when it comes to RF, maybe someone with more experience can help out here

Whether I'll actually work on any of these points probably depends on how this project takes off. As long as it is only me using it on my bench ECP5/Ethernet would require some amount of work but wouldn't yield any improvements while using it

[chrisgj198]

Thank you very much for publishing your VNA design, and for making the pdf schematic in response to my request. I think your design is probably the best of all the published designs.

For many years I have wished to build VNA similar to yours, however I have been much too busy so I just hoard components and look at datasheets, meanwhile some of my components are already obsolete.

I have a lot of thoughts and also some questions on VNA design which I would like to share.

I was wondering why you choose a dual conversion rather than single conversion architecture. I know that many old HP ones also use dual or triple conversion but since there is no image rejection I can't really see an advantage, and all of the extra components in the signal path will drift with temperature and cost money. Is there an advantage to dual conversion that I don't know about?

It was my intention to build a VNA with 2 receivers per port, i.e. 4 receivers for 2 ports, because at a previous job I was unable to use certain calibration methods that I wanted to use, on a HP8753ES that had only 3 receivers. Also, if the hardware of each channel could be made cheap enough, then 4 ports (with 8 receivers) becomes quite attractive, as it enables rapid and convenient measurement of differential components, which are common these days (e.g. cabling for high speed serial links).

As I am not that bothered about speed, I was going to use a much lower, single IF ~ 10kHz, and an ADC such as AD6808 / AD6809 which should be very easy to drive and has simultaneous sampling, with built-in antialiasing filters that I hope would track very closely between the different channels being on one chip. Due to the limited channel-to-channel isolation of that ADC, I had intended to put a PGA with accurate gain steps such as the AD8253, between each mixer and its ADC input channel, probably located near each mixer so as to avoid problems with coupling between the channels at the IF.

What is the reason for filtering the outputs of IC7 (3x110MHz lowpass filters)? Most mixers are quite happy with square wave LO and even give better noise performance and gain stability, and linearity with respect to the RF input port, when the LO port is given a nice sharp square wave. Also where possible I would drive the LO inputs with differential signals. I had been thinking of using something like an ADCLK948 for buffering and distributing the LO in my single conversion design. One thing I have worried about though, is RF getting coupled from the RF port to the LO port in one mixer, and then getting through the LO distribution to the LO port of a different mixer that is measuring a much smaller signal, and getting coupled into the RF port of that mixer. I think quantifying the problem would be the first step. Perhaps individual LO buffers for each mixer might be needed, or if there is a big enough LO signal to start with and a slight coupling problem, then just an individual small attenuator in the LO path of each mixer might be enough, or maybe there is no problem.

Even when driven by a sine wave LO, but especially when driven with a nice sharp square wave LO, I would expect that most mixers would have a useful amount of conversion at the 3rd harmonic of the LO frequency +/- 1xIF. Therefore if the source incorporated something like a RMK-3-123+ from mini-circuits (with some switches to bypass it at lower frequencies), or incorporated an ADF5355, it might be possible to use the same receivers and get useful measurements above 6GHz.

I agree strongly with your choice to use a resistive network and a mixer with differential input as a return loss bridge. I was going to try to use LT5560 as the mixers, but the ADL5801 might be better in that application as I was expecting to have to do something complicated to bias the LT5560 input properly.

I would be quite wary of the possibility of RF getting coupled between channels through logic signals. For example RF could couple from the RF input of one receiver via bond-wire coupling in the mixer package, to control signals like REFMIX1_EN/10.4A, then between the logic traces at the FPGA, then via something like PORT1MIX1_EN/10.3B into another mixer. I would stronly suggest putting a series resistor of a few kOhms if permissible and a 100pF capacitor to ground on each side of the resistor, in each logic trace that does not need to be fast and that goes to a mixer or other sensitive block. I would put the body of the resistor on the boundary of the shield can for that block. I see you have already taken good care of the supply isolation.

A possible method to make your design cheaper to replicate might be to use commercially available screening cans for each stage of the circuit, rather than custom CNC-machined aluminium. For example:

https://leadertechinc.com/wp-content/uploads/2019/09/SMS_Bi-fold_Brochure_Single_Pages2019.pdf

https://au.element14.com/wurth-elektronik/36103205/shielding-cabinet-smd/dp/1909657?ost=1909657

If a major cause of drift in the measurement results turns out to be temperature changes, then it might be fairly cheap and easy to put some large SMT resistors on the back of the board and SMT thermistors, and use a microcontroller to quickly heat the groundplane under each mixer etc. to a stable temperature (maybe 50 deg C) and hold it constant within 0.1 degree or less with a PID algorithm for each sensor/heater. This could shorten the warm-up time to a minute or so. (I am not that interested in powering it from USB...)

Anyway if you do organise the manufacture of your VNA, I would be very interested in participating in a group purchase.

Thank you for publishing this project.

[jankae]

Ok, I did not expect such a long and detailed comment, thank you so much for all your thoughts and ideas. I'll try do address most points:

I was wondering why you choose a dual conversion rather than single conversion architecture.

Yeah, I am actually wondering about that sometimes myself. The initial design started with the LTC5510 as the first mixer and that is only specified down to 1MHz. I didn't want such a high IF, so I thought that I absolutely need the second conversion. I now know that the LTC5510/ADL5801 are probably also good for the 250kHz. But the BOM cost for the second conversion is actually not that high (compared to other parts on the PCB, the LT5560 is pretty cheap) and it has some other advantages: The MAX2871 (Highband source and 1.LO) only has a 12bit modulus divider. This is not a problem for normal VNA mode (only limits the minimum frequency spacing of points), but there is also a spectrum analyzer mode in the firmware (a bit of an afterthought, the device is certainly not intended as a SA) which needs exact LO frequencies and I can achieve that by changing the 2.LO when required.

TL;DR: could probably do just as well without the second conversion but I like the flexibility it provides while not increasing cost to much. I'll try it with just the first conversion when I got the time (should be possible by bridging the 2.Mixer and changing some passives)

Also, if the hardware of each channel could be made cheap enough, then 4 ports (with 8 receivers) becomes quite attractive[...]

I quite like the idea of a modular design, where you simply add channels when needed. Not really a hobby project anymore though ;)

What is the reason for filtering the outputs of IC7 (3x110MHz lowpass filters)?

Getting a cleaner 2.LO, I thought this was necessary during the design (less tones in the final IF). But you are completely right, I just tried without these filters and the performance didn't change at all.

One thing I have worried about though, is RF getting coupled from the RF port to the LO port in one mixer, and then getting through the LO distribution to the LO port of a different mixer that is measuring a much smaller signal, and getting coupled into the RF port of that mixer.

I believe that is actually a problem with the current design, the 1.LO for the reference and port 1 are routed quite close. According to your suggestion I added a 10db pad at both mixers, this improved S12 isolation a little bit. Thanks for the idea :)

Therefore if the source incorporated something like a RMK-3-123+ from mini-circuits (with some switches to bypass it at lower frequencies), or incorporated an ADF5355, it might be possible to use the same receivers and get useful measurements above 6GHz.

When looking at the ADF5355 I really wanted to use it in a future revision (higher frequencies, high resolution modulus), but then I looked at the pricetag...
Anyway, I think for going significantly higher than 6GHz a complete redesign is required and maybe even better PCB material. I don't think I will get into that, at least not for a while.

I would be quite wary of the possibility of RF getting coupled between channels through logic signals.

I have tried adding a resistor/capacitor for each digital line and it didn't change anything at all. I'll update the PCB and include them just to be sure, they certainly won't to any harm.

A possible method to make your design cheaper to replicate might be to use commercially available screening cans for each stage of the circuit, rather than custom CNC-machined aluminium.

Yes, I have never seen an affordable design with custom machined parts before. When I started the design I never really anticipated that other people might take such an interest in it. I do own a CNC mill, so it didn't really increase the cost for me and I really like the look of it.

If a major cause of drift in the measurement results turns out to be temperature changes, then it might be fairly cheap and easy to put some large SMT resistors on the back of the board[...]

It certainly drifts somewhat but it is not terrible (compared to my pocketVNA, which I had to calibrate directly before each measurement).

Anyway if you do organise the manufacture of your VNA, I would be very interested in participating in a group purchase.

I'll keep you updated on that.

[nbgsmk]

* Ethernet: Excellent idea, if I

Since you mentioned some 10k points/sec sweep speed, are there any throughput concerns, in case of using ethernet? I am not really aware of how much data is being transferred here, and I am assuming 100Mbit eth, for some reason. On the other hand, I guess if commercial instruments are doing the same, then surely it's not an issue. Just a thought.

USB
Again, I am not aware of how demanding the PC application is, but in case of usb connection, do you think an android app is a viable option? Then you could run the analyzer from a large-screen tablet. (while still needing to power it from a more powerfull dc supply - I'm having second thoughts now...it may get a bit clumsy :) )

Comments?

[bvernoux]

@jankae @chrisgj198 & @diegoherranz
For me it will be very interesting to do a version with the ADF5355 on the other case it shall not break all, so maybe 2 versions could be done:

• 1st version: Actual version with some improvements without breaking everything (maybe keeping actual FPGA too) as @jankae has already done an amazing job on this VNA which is the most advanced open source design today.
• 2nd version a very improved version using ADF5355... to have a VNA which go up to 13.6GHz ... if the cost do not explode too much (let say something with a 500USD BOM maximum to be checked with other interested people to do such VNA),
  What do you think about that ?

On my part I'm very interested by both versions:

• 1st version (short/mid term) to replace my old HP 8753D
• 2nd version (mid/long term) to have a VNA which will be very nice for microwave experimentation (if the performances are good enough).

So maybe we could start to convert the actual schematic/board to KiCad 5.1.6 ? (I do not see any showstopper to use KiCad 5.1.6 especially it has very nice RF plugins and it is already very good to do very advanced RF design even if KiCad 6.x will bring some improvements)

• I have converted the schematics and they are quite good
• The board is also converted but it has more issues to be fixed,
• Eagle is clearly a showstopper for me as it is required to buy a license to use it and it is clearly not what I want to keep that project as open as possible (and to have more and more good contributors ...)
• Lot of things to do, to to validate what to change by what to improve performance (potentially lower the cost and reduce the BOM especially less unique parts.)

[tchristle]

I am placing another vote on a group purchase when the major bugs are rung out. I think it is more important to benchmark the current capability before major design changes are proposed.

[pentti12]

I also vote the group purchase of the 1st version. Pentti ke 30. syysk. 2020 klo 4.27 tchristle <notifications@github.com> kirjoitti:

…

I am placing another vote on a group purchase when the major bugs are rung out. I think it is more important to benchmark the current capability before major design changes are proposed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKBMVCSBYNRVBYP5RLJD7LSIKCRDANCNFSM4R3TMTEA> .

[jankae]

Since you mentioned some 10k points/sec sweep speed, are there any throughput concerns, in case of using ethernet?

100MBit Ethernet should be fine, it has more throughput capacity than the current Fullspeed USB. In fact, at the moment I can not get the full 10k points out via USB, only up to about 5,5k points/sec. Not exactly sure what the issue is yet, on early projects I reached enough USB throughput for about 12k points/sec.

do you think an android app is a viable option?

Absolutely no idea, I never tried (and am not planning to) developing for android.

[...] so maybe 2 versions could be done

I think that is a good plan. This project started solely because I wanted to learn more about RF design, I didn't even consider some features that could be useful to others (Ethernet, stand-alone version with display,...). Instead of trying to add some of these features afterwards, designing a completely new version after gaining some experience with the current design could be a better way to go. The new version could be planned from the start with these features and maybe an extended frequency range.

Regarding the group purchase: I don't think I will be organizing one but would certainly provide support if questions or problems arise. As stated here, Hugen might actually sell this version if initial testing goes well, this might be another alternative for a group purchase.

[nbgsmk]

In fact, at the moment I can not get the full 10k points out via USB, only up to about 5,5k points/sec.

It's fine for me! I'd be more than happy with the analyzer doing that 👍 (having no analyzer at all)
On the serious side, I see you are running FreeRtos on the STM. Except the usb, what other things are dedicated to the STM?

do you think an android app is a viable option?

Absolutely no idea, I never tried (and am not planning to) developing for android.

Well, it was just an idea. But we could discuss the STM and android further, when you have more time to spare. I am a kind-of self-proclaimed android developer :-) and I may be able to help. I hope. Android is no king of speed and responsivenes, and I have no idea what kind of processing is needed. If nothing else, it would be interesting to discuss the requirements. When you have time. Let's finish this one first.

[...] so maybe 2 versions could be done

I think that is a good plan.
Regarding the group purchase: I don't think I will be organizing one but would certainly provide support if questions or problems arise. As stated here, Hugen might actually sell this version if initial testing goes well, this might be another alternative for a group purchase.

I was already studying distributors and the BOM closely, but this is great news! Even at 5 times the price of NanoVna, ~$200 is not too much for an instrument which I believe is 10 times the product.
My only problem with group purchase is, being outside of EU, I have no idea how the customs will treat such a completed product at $200-250. If it turns out the fees are too high, I'd rather build it myself and learn a lot in the process. I was thinking to order boards from eg. JLCPCB, populated with most of the capacitors, resistors and inexpensive parts they have in stock. Even with 5 boards minimum, I hope this wouldn't be too expensive, and I would save a lot of time soldering. Then, later I would order, say, the mixers, amplifiers and other "expensive" stuff for a single analyzer. (and have other 4 boards as spares if I let the white smoke ouf or it :) :) )
Such partial deliveries would certainly not raise any customs issues. Finally, I would do shield milling in a local company.
Thoughts anyone?

[chrisgj198]

Hi Jan, Something else that I think might be worth looking into:

On the photo of the PCB, it seems like the solder pads for e.g. DC-blocking capacitors are much wider than the 50 Ohm traces that connect to these components. This will lead to impedance discontinuities, particularly for the SMA connectors where the pad is quite long. Fortunately the effect of these impedance discontinuities on s-parameter measurements will be pretty much removed by the calibration process, but things like source power flatness might still be better without the discontinuities.

I would suggest checking the available options for PCB dielectric thickness and try to find one that makes the 50 Ohm trace width about the same as the width of an 0402 component, then use custom pads that are about the same width as the component (for series components). (For shunt components it can be useful to have a different footprint, again trying to keep the width of 50 Ohm traces constant.) There might be some limitations to the footprints based on what your assembly house can handle, but at least getting closer to 50 Ohm width may be worth trying. The components would be easier to knock off the board with narrow pads, but the aluminium cover is pretty good protection against that!

[chrisgj198]

In case anyone is interested, just saw this post about an ADF5356:
13.6 GHz output signal of ADF5356 synthesizer chip

[jankae]

Except the usb, what other things are dedicated to the STM?

The tasks of the different systems during a sweep are roughly like this:

• STM:
  • Receives sweep settings from PC, calculates frequencies and PLL registers and transfers them to FPGA
  • Receives sampling result (imag + real of all three receivers) from FPGA and calculates S-parameters
  • Passes on calculated S parameters to PC
• FPGA:
  • Configures PLLs and RF switches during the sweep
  • Samples the ADCs
  • Calculates single bin DFT
• PC Application:
  • Receives uncorrected S parameters
  • Applies calibration correction

I am a kind-of self-proclaimed android developer :-) and I may be able to help

Thanks for the offer, lets talk about android once the current version is done :)

it seems like the solder pads for e.g. DC-blocking capacitors are much wider than the 50 Ohm traces that connect to these components

Yeah, I couldn't find any cheap manufacturer with a layer stack that results in thicker 50 Ohm traces. They all seem to use thin prepregs between the first and second layer. I have ground cutouts under the pads of components in the RF path to reduce the discontinuities a bit (as described in here).

After comparing the default Eagle 0402 footprint to the IPC standard, I noticed that it is rather large. I will reduce the pad size for the next PCB revision.

The source level is essentially flat up to 3GHz, after that some ripple starts to appear. Unfortunately, I can not measure any higher than 3.2GHz (ignore the negative spikes, this is a max-hold over non-synchronized sweeps of the VNA and SA)

[bvernoux]

I cannot do a check/review of actual board as it is done with Eagle 9.3.1 which requires to pay a license to view the board/schematics ... (schematics are in PDF now)
It is why I insist on the fact converting actual design to KiCad is a must have.

I can help to check the VNA if you want:

• I can do accurate Spectrum Analyzer measurements up to 12.4 GHz (even if it is not required to exceed 6GHz).
• I can also check lot of parts of the PCB with my HP VNA (HP 8753D 30KHz - 6 GHz with a good 7GHz calibration kit (bought from Kirkby Microwave) and SA (also with EM probes) to see where there is room for improvements ...
• I have also some nice RF SigGen up to 12.4GHz including Agilent E4432B(up to 3GHz), DEEPACE KC908 ...
• I shall finalize TRL board/TRL Calibration Kit soldering/tests on the latest version v0.3 from OSHPark (see https://github.com/bvernoux/kicad_rf/tree/master/4Layers_trl-board_v0_3)

[OneOfEleven]

I've already suggested it to Jan but thought I'd log it here.

It might be a good idea to add RF gasket strips between the metal shields and the PCB all along the edges. Examples could be like here such as conductive silicon or fine mesh foam strips, although it does require grooves to be milled along all the contact areas ..

www.p-p-t.co.uk/site/assets/files/1324/ppt-catalogue.8in9j.pdf

If I look at the edge by the LED's I can see light all along the edge through the tiny gap between the PCB and top shield, which means the shield is not making any contact with the PCB, contact is only present around each screw fixings.

If apply a small amount of pressure to the port-1 SMA socket (with a 50R SMA load on it) the S11 calibrated trace with the unit I have here changes dramatically (I'll do a short video soon), which means either the SMA is not quite making good contact with the metals shield it's up against or the PCB/shield contact is not good. All screws are torqued down equally so they are tight.

RF gasket would solved that problem and also improve isolation between each and every RF stage - as is done on pro instruments.

[OneOfEleven]

In fact, at the moment I can not get the full 10k points out via USB, only up to about 5,5k points/sec. Not exactly sure what the issue is yet, on early projects I reached enough USB throughput for about 12k points/sec.

I've trying to solve a problem I have here in my software that I'm getting lost points at the high transfer speeds, they are simply missing from the data stream that I get from libusb, there are no packet frame corruptions or packet frame frame alignment problems, start byte exact where it should be with every point, no corrupted data at all, header is always perfect in the raw data, just simply missing data points.

I was wondering if it might be a problem with the USB transfer itself rather than a problem with my software, I can't work it out at the moment. I will have to install Qt and start testing with your Qt GUI to see if that has the same (but hidden lost points) problem.

[OneOfEleven]

I might try some conductive sealant just as a simple test, something similar to this ..

https://shielding-solutions.com/product/electrically-conductive-caulk-and-sealant

[chrisgj198]

I might try some conductive sealant just as a simple test, something similar to this ..

https://shielding-solutions.com/product/electrically-conductive-caulk-and-sealant

Conductive sealant might be a good way to improve units that have already been manufactured. As I mentioned in my first post above, individual screening cans with frames that get soldered to the PCB and clip-on lids are commercially available and although they are less rigid and less thermally conductive than milled blocks of aluminium, they might be easier for others to replicate at low cost, so they would be worth trying, in my opinion.

[jankae]

It might be a good idea to add RF gasket strips between the metal shields and the PCB all along the edges.

I will definitely try to add the required grooves to the shields because I am really curious how much of a difference it makes but this is not happening any time soon (don't have the right tools for that yet). The shield not making contact between the screws is a problem. I am taking extra care to clean all touching surfaces every time I assemble it and use quite a bit of torque on the screws as that seems to help.

[...] they are simply missing from the data stream that I get from libusb

That happens when the databuffer in the VNA is full. There is not a huge amount of RAM and at 10kpoints/s I can only store about 16ms worth of data. If the PC is not reading fast enough, points are getting dropped. I added a check for missing points and it is also happening with my Qt GUI. The problem is a bit worse on Windows where I have about 50-100 missing points/s. On Linux (same machine) I normally don't see any missing points but if I stress the CPU with other programs I occasionally miss a few (only a couple of missing points every few seconds). Maybe my usage of libusb is not perfect but improving that is not my highest priority (the data at 10kpoints/s is quite noisy anyway and maybe not that useful)

clip-on lids [...] might be easier for others to replicate at low cost

Totally agree, definitely lower cost and easier to replicate. For me, this is mostly a problem of motivation as this would require a board respin while not improving performance much. I am focussing on adding features and fixing bugs in the software at the moment but will keep the clip-on lids in mind for a potential next hardware revision.

[OneOfEleven]

[...] they are simply missing from the data stream that I get from libusb

That happens when the databuffer in the VNA is full. There is not a huge amount of RAM and at 10kpoints/s I can only store about 16ms worth of data. If the PC is not reading fast enough, points are getting dropped. I added a check for missing points and it is also happening with my Qt GUI. The problem is a bit worse on Windows where I have about 50-100 missing points/s. On Linux (same machine) I normally don't see any missing points but if I stress the CPU with other programs I occasionally miss a few (only a couple of missing points every few seconds). Maybe my usage of libusb is not perfect but improving that is not my highest priority (the data at 10kpoints/s is quite noisy anyway and maybe not that useful)

That explains it ! I've been scratching my head for days trying to find out how on earth I'm loosing points, it's because I'm not, they're just not being sent is all.

Here's a short sample of a timing list I just made whilst the points are coming in (Windows), 4501 points per scan at 50kHz bandwidth (around 10000 points/sec). The first figure on each line is the number of points per libusb RX data callback (I do the same as yourself with libusb Jan), the 2nd figure on each line is the elapsed time since the previous RX data callback, the third figure is the calculated time per point.
Their are times when something in windows (either in my software or some other that's running) delays the thread (a high priority one) that I have running from processing the libusb callbacks quick enough. It doesn't take much (just over 1ms between thread calls) to start loosing points.
Poor old windows has never been a real time OS, was never meant to be. You can see that their are more than 16 points per callback on occasion - that's when the lost points occur ..

2 0.244ms 0.122ms/packet
3 0.372ms 0.124ms/packet
2 0.249ms 0.125ms/packet
2 0.250ms 0.125ms/packet
2 0.251ms 0.125ms/packet
2 0.251ms 0.126ms/packet
2 0.249ms 0.124ms/packet
2 0.251ms 0.125ms/packet
2 0.248ms 0.124ms/packet
1 0.250ms 0.250ms/packet
2 0.251ms 0.126ms/packet
2 0.251ms 0.126ms/packet
2 0.249ms 0.125ms/packet
2 0.321ms 0.161ms/packet
2 0.364ms 0.182ms/packet
2 7.005ms 3.503ms/packet
3 0.388ms 0.129ms/packet
18 1.362ms 0.076ms/packet
15 1.125ms 0.075ms/packet
18 1.386ms 0.077ms/packet
18 1.369ms 0.076ms/packet
19 1.369ms 0.072ms/packet
13 1.022ms 0.079ms/packet
5 0.470ms 0.094ms/packet
6 0.633ms 0.105ms/packet
4 0.499ms 0.125ms/packet
4 0.474ms 0.119ms/packet
3 0.403ms 0.134ms/packet
3 0.371ms 0.124ms/packet
3 0.428ms 0.143ms/packet
3 0.449ms 0.150ms/packet
3 0.374ms 0.125ms/packet

[OneOfEleven]

Here's a quick video showing the gap we can't close and how it affects the performance around port-1 at least (S11 changes a lot) ..

https://www.youtube.com/watch?v=ECTPgdGvlfo

This is why we want to fit some RF gasket. It would also hopefully improve RF isolation between the various stages as well.

[sp9bsl]

Hello OneOfEleven,
just wonder watching your video if the RaspberryPi 4 can handle this throughput or is it reserved for big machine? Did you or anyone tested for this option?

The gasket between the board and case is good idea. I have very thin one, around 0.4mm. Will test this when package from Hugen arrive.

Slawek

[pentti12]

Hello The EMI gasket is a good trial, but in my opinion the main issue is on the missing surface treatment of the aluminium parts. The aluminium will oxidise soon after macined from raw material, So my suggestion is that these aluminium parts must be coated with an electrically conductive layer before they are assembled together with the PCB. I will try it here in Finland. Pentti ke 25. marrask. 2020 klo 12.06 sp9bsl (notifications@github.com) kirjoitti:

…

Hello OneOfEleven, just wonder watching your video if the RaspberryPi 4 can handle this throughput or is it reserved for big machine? Did you or anyone tested for this option? The gasket between the board and case is good idea. I have very thin one, around 0.4mm. Will test this when package from Hugen arrive. Slawek — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKBMVAHWXABNB4Q2ERFVYDSRTJKZANCNFSM4R3TMTEA> .

[OneOfEleven]

just wonder watching your video if the RaspberryPi 4 can handle this throughput or is it reserved for big machine? Did you or anyone tested for this option?

The gasket between the board and case is good idea. I have very thin one, around 0.4mm. Will test this when package from Hugen arrive.

I have no idea Slawek, I've never had a ras-pi, so no idea about that really.

Any gasket that would be used would have to be slightly flexible/compressable, it needs a certain amount of give otherwise the gaps/non-contact areas would never be closed, you'd still have the same problem.

The problem of the metal casing not making proper and full contact with the PCB all alone the edges is a major one on the unit I have here. The whole unit gets quite hot at times, any calibration I do can at times be void after 10 seconds or so, you can see the traces slowly move as the seconds tick by, the hot temperatures must be contributing to the problem (physical changes in the cases etc).

[blackberryer]

It might be a good idea to add RF gasket strips between the metal shields and the PCB all along the edges.

I will definitely try to add the required grooves to the shields because I am really curious how much of a difference it makes but this is not happening any time soon (don't have the right tools for that yet). The shield not making contact between the screws is a problem. I am taking extra care to clean all touching surfaces every time I assemble it and use quite a bit of torque on the screws as that seems to help.

[...] they are simply missing from the data stream that I get from libusb

That happens when the databuffer in the VNA is full. There is not a huge amount of RAM and at 10kpoints/s I can only store about 16ms worth of data. If the PC is not reading fast enough, points are getting dropped. I added a check for missing points and it is also happening with my Qt GUI. The problem is a bit worse on Windows where I have about 50-100 missing points/s. On Linux (same machine) I normally don't see any missing points but if I stress the CPU with other programs I occasionally miss a few (only a couple of missing points every few seconds). Maybe my usage of libusb is not perfect but improving that is not my highest priority (the data at 10kpoints/s is quite noisy anyway and maybe not that useful)

clip-on lids [...] might be easier for others to replicate at low cost

Totally agree, definitely lower cost and easier to replicate. For me, this is mostly a problem of motivation as this would require a board respin while not improving performance much. I am focussing on adding features and fixing bugs in the software at the moment but will keep the clip-on lids in mind for a potential next hardware revision.

I have seen the 6GHz VNA designed by Hforsten:
https://hforsten.com/improved-homemade-vna.html

he used a resistive bridge is basically a variation of Wheatstone bridge，
image

What is the difference with your resistive bridge？

It does not have PC-side software, and the actual experience cannot be compared with your design,and I noticed that you mentioned that it can not measure any higher than 3.2GHz？The uploaded file is not resolved yet? Will it be optimized in the next version?

[jankae]

If you look closely at the VNA from Henrik Forsten, you'll notice other similiarities (such as identical ICs in some positions). That design actually served as an inspiration for my project. I believe his resistive bridge is just a variation and should work similar to my implementation (which is a bit closer to a standard wheatstone bridge).
The 3.2GHz limit is only my other test equipment. For example, I can't measure the output signal of my VNA over 3.2GHz because that is the limit of my spectrum analyzer (I can of course measure it with another of my VNA prototypes but sometimes it would be good to have a "known good" instrument as a reference). The VNA, as it is, goes all the way to 6GHz.

The uploaded file is not resolved yet?

Which file are you referring to?

[blackberryer]

If you look closely at the VNA from Henrik Forsten, you'll notice other similiarities (such as identical ICs in some positions). That design actually served as an inspiration for my project. I believe his resistive bridge is just a variation and should work similar to my implementation (which is a bit closer to a standard wheatstone bridge).
The 3.2GHz limit is only my other test equipment. For example, I can't measure the output signal of my VNA over 3.2GHz because that is the limit of my spectrum analyzer (I can of course measure it with another of my VNA prototypes but sometimes it would be good to have a "known good" instrument as a reference). The VNA, as it is, goes all the way to 6GHz.

The uploaded file is not resolved yet?

Which file are you referring to?

I see, in the near future, I think I will try to make a board.
Thank you again for your excellent design, it is spectacular, and ask if you have any plans to update your VNA version again？

[EnthuMan]

@jankae
Thanks for sharing a project that has required effort in such diverse areas.
A few questions about the selection of IF and the sampling rate and I hope you could share your thoughts on them.

1. One of the references you cite (Henrik), used an IF of 2MHz (LO set at an offset of 2MHz) while sampling it at 40MSps. Since you referred to his project and chose to use a much lower 250KHz IF while sampling at only 1MSps, what was your thought process for the going that way.
   1.1) How is the performance of your approach compared to his? There could be many contributing factors but is the choice of IF and the sampling frequency one of them?
2. Is your LO shifted by this IF at the first down conversion or the second?
3. To understand the measurement process: at every frequency you set the the source and LO PLLs, give it some settling time and acquire N samples in the FPGA (how much is N here?). The single frequency DFT is calculated and sent to the PC. The cycle is repeated for the set number of sweep points. Is this correct? What is the sweep time you were able to achieve using this technique? I suppose there could be some pipelining already implemented here: set the PLLs for the next frequency while the DFT for the previous is being calculated (and allow the PLL to settle).
   It is an incredibly complex system and congratulations on the success.

[jankae]

I think it could be a good feature, sure it's not a patch and we can wait for that :)

Well, I couldn't wait ;)

Just finished the implementation, there are probably still some bugs around. The waterfall plot is a bit hidden: You need to close one of the default plots, then you can create a new one (with an option for the waterfall).

And about your "list" can we take a look to the developement pipe on your side ?

It is partially a mental list and (for hardware improvements) a few hand scribbles. For more concrete features, you can check the GitHub issues (I'll try to remember to create some myself for planned features)

dBuV and a selectable reference impedance are also implemented:

[HadesDT]

Amazing !

Just a quick review about the waterfall plot. Can you fit the size of the XYplot to get the same scale of the x axe ? I attach a picture to show what I'm talking.

Thx for your work, I try the others features (dBuV and renormalize impedance) tomorrow with the right setup :)

[jankae]

Can you fit the size of the XYplot to get the same scale of the x axe ?

Yes and no. The plots are completely separate from each other and if you add more plots it is also not guaranteed that both plots have the same width (e.g. you could have two XY-plots under one waterfall plot). What I can do, is give you an option in the waterfall plot setup to match the plot area of an XY-plot (assuming they have the same size). But you still have to manually select this alignment depending on the Y axis setup of the XY-plot (plot area changes when Y axes are enabled/disabled).

[HadesDT]

Can you fit the size of the XYplot to get the same scale of the x axe ?

Yes and no. The plots are completely separate from each other and if you add more plots it is also not a guaranteed that both plots have the same with (e.g. you could have two XY-plots under one waterfall plot). What I can do, is give you an option in the waterfall plot setup to match the plot area of an XY-plot (assuming they have the same size). But you still have to manually select this alignment depending on the Y axis setup of the XY-plot (plot area changes when Y axes are enabled/disabled).

Hello,

I tried your new version with the alignment and it's perfect for me !

Thx a lot for your reactivity !

[HadesDT]

I try the renormalization but I notice no change in the s params.

My process is :

• Calibration SOLT in 50 ohm
• DUT 75 ohm connected
• I got the s params in 50 ohm reference, but if I pu 75 ohms the s params are the sames after a new acquisition
  I do something rong ?
  Thx

[jankae]

moved to a new issue as there is a lot going on in this thread, see #94

[HadesDT]

Hello, quick return about the spektrum analyser.

1. when we display marker the unit is not the unit used in the graph. See my print screen attached.
   

2. Add the possibility of entering EMI/EMC standard limit values to set, for example, a CE102 limit and see if the setup passes the EMI/EMC standard. As on the Spektrum R&S, see print screen
   
   

3. Why the measure of the same setup with the LibreVNA give 5dBuV less than the R&S Spektrum analyser as you can see on the both print screen above :) Limit of the chip ? Need calibration ? How ? Thx :)

[jankae]

when we display marker the unit is not the unit used in the graph. See my print screen attached.

Markers settings are separate from axes settings. For example, you can have the marker show the value in dBm, when the graph is showing dBuV. Right-click on a marker (either on a graph or in the marker widget) to change that setting. So far, the marker did not offer dBuV as a unit. I have added that now.

Add the possibility of entering EMI/EMC standard limit values to set, for example, a CE102 limit and see if the setup passes the EMI/EMC standard. As on the Spektrum R&S, see print screen

Could be possible but not sure where to set it up yet. The smith chart already has a similar feature (constant resistance/impedance lines). Please open a new issue for improvements requests like this, otherwise it probably gets lost in this thread.

Why the measure of the same setup with the LibreVNA give 5dBuV less than the R&S Spektrum analyser as you can see on the both print screen above :) Limit of the chip ? Need calibration ? How ? Thx :)

The input range is limited, as the LibreVNA does not have any switchable input attenuators. But as long as you don't have the "ADC overload" indicator in the bottom right corner, you should be fine. This is likely an issue with the calibration. For accurate spectrum analyzer readings, you need to perform the receiver calibration (Menu: Device->Receiver Calibration). You only need to do that once for each LibreVNA (or perform the calibration with one LibreVNA and copy it to another, they are reasonable similar). Please see the user manual for the calibration procedure.

[piotrek-jan]

Hi Jan,
In general new here and I'm not RF Engineer, however working in RF since few years...
I like your project very much and decided to type a bit. I have few questions about the projects and would appreciate, if you could advise:

1. do you have some authorized place where I could buy it ? Or maybe from you directly ?
2. what board you use in this project - how many layers, what is the stack-up, is it regular FR-4 or something more sophisticated
3. There are places like 60MHz low pass filter at ADL5081 ae. L34-37, C124,C128, C130 - such filters are highly tolerance susceptible, had you thought about some ready pass band filters ? See last point for details
4. the 2nd mixer ae. IC22, gets pretty reach harmonics content signal from IC7, you have some filtering options there but not used - have you tried to filter this a bit out and see is the performance better ?
5. The final IF amplifers has pretty wide bandwitdth 145MHz at Gain 1 and slew rate 490 V/μs, what was intention to use such amplifier in already low frequency circuit, maybe slower amplifier with lower noise could be used here ?
6. In general someone before wrote about somehow limited decoupling on the board, including ADCs. The decoupling is really major aspects next to layout of course, if "all" bits are planned to be used... Have you tried to verify the performance of power rails by some AC/ripple measurements during working conditions over the board?
7. I saw in the past in some analyzer path following solution - just with slightly different components - but idea the same - maybe worth to consider

Best Regards and respect for this great work,
Piotr

[jankae]

Hi Piotr,
I am also not really an RF engineer, but will try to answer your questions:

1. I don't sell the LibreVNA myself but Hugen handles Production and Sales. You can find links to the official shops here: https://www.zeenko.tech/librevna (as far as I am aware, there are no clones yet - might be more difficult to do or not as lucrative as with the NanoVNAs)
2. I have used regular FR-4, specifically the 4-layer JLC7628 stackup: https://cart.jlcpcb.com/impedance. Not ideal but a cost-effective solution.
3. Yes, the component tolerance is why I am using a LPF instead of a BPF. The nominal cutoff frequency of the LPF is also somewhat above the actual used IF, so there is some margin for tolerance.
4. I Initially had these filters populated but didn't see any difference in the performance.
5. In hindsight, I should have chosen a different amplifier (or at least use more filters between that amplifier and the ADCs). I believe that the noise floor of the VNA is currently limited by this amplifier (but the ADC limit is not much better, switching to a different amplifier would only make a small difference. And at higher frequencies, the dynamic range is limited by isolation issues anyway). This is only my third project in the RF domain, some stuff is certainly not perfect.
6. I have looked at all rails with an oscilloscope to detect any obvious problems (everything looked good). But of course that is not enough to really check decoupling. I don't think I have the equipment or knowledge to confidently verify the power supply decoupling. I did however do some ADC measurements with the final IF amplifiers disabled (no input signal at the ADC). Everything else was powered on. I got about 7 or 8 LSB peak-to-peak noise under these conditions. For a 16-bit ADC, this seems good enough for me.
7. Thank you for the suggestion. I think it could be an improvement but it also uses a lot more space (these BPF are huge compared to all the other components in the VNA) and probably also some cost.

I don't think I will do major changes to the LibreVNA as it is now. There might be some layout adjustment or other small stuff like that. However, I have a concept for a potential version 2.0: https://groups.io/g/LibreVNA-support/topic/librevna_2_0_hardware_concept/89858084
It is significantly larger and also more expensive but performance should also be a lot better (and more versatile, due to the modular approach). But the component shortage has put a stop to that project for now... Unfortunately, there is no way for me to get all the parts to assemble a prototype at the moment.

[piotrek-jan]

Hi Jan,
Thank you for answers and feedback. I plan to get it soon.
The new version looks really good and I cheer for you to complete it. The semiconductors market is insine now... Unfortunatelly no signs this madness will end soon.
Keeping the existing project alive and improving the things in my opionion has sense too. I would say, still the performance of recent version is not extracted to the edge, but to do this some small re-design may be necessary.
May be it is a good time when modular version is postponed ;)
The modular design will be more tricky in many aspects - starting from mechanics - like protection against breaking the modules, going to interboards connectors, different temperatures of different modules, matching intermodular traces,cables. It is really ambitious project. As you mentioned this will lead to higher costs too. The recent version has really excellent performance/pricing ratio. Of course there is no simple trade here, but I would vote even to pay more for recent version if directivity / dynamics/software would be a bit better. Probably for most users what is now is enough...
The new modular approach probably will have price per module higher than full set now - guessing in most basic option two modules and motherboard ~2-2.5k. So still much less than commercial equipment but this will be other shelf already...
In case of modular approach maybe make sense to assume 6 slots ;) an extra slot for good quality spectrum analyzer(s) and one more for good quality RF generator(s)... Sometimes does not make sense to force one type equipment to do other functions. Sometime it is easier & better & cheaper to do dedicated stuff (I have some schematics of some old fashion SA and generators, so will be happy to share if interested). Just to have universal test set already. I can support you a bit with hardware, unfortunatelly not with software.

Best Regards,
Piotr

[jankae]

Keeping the existing project alive and improving the things in my opionion has sense too.

Absolutely, I don't plan on abandoning the current LibreVNA.

but I would vote even to pay more for recent version if directivity / dynamics/software would be a bit better. Probably for most users what is now is enough...

I am working on improving the dynamic range (especially for the higher frequencies) but this is also delayed due to part shortage. If you have specific ideas for the software, please open new issues for that (otherwise it probably gets lost in this one).

The new modular approach probably will have price per module higher than full set now - guessing in most basic option two modules and motherboard ~2-2.5k.

I am aiming for < 1k. Electronic BOM is about 500-600$ for one unit, should go down in volume. Of course this does not include the milled shielding, assembling, testing...

In case of modular approach maybe make sense to assume 6 slots ;) an extra slot for good quality spectrum analyzer(s) and one more for good quality RF generator(s)...

I'd prefer to keep it at four slots (keep complexity and size reduced for the base model). With four, you could still get a two-port VNA plus a "good" generator and spectrum analyzer. But this is all moot point as long as I can't get the components...

[piotrek-jan]

When I will have the unit already I will sit to it and do some more measurements - not only soft but also some HW check. At daily basis I work with R&S ZNB8.
What chips do you need to proceed ?

[jankae]

What chips do you need to proceed ?

Too many to keep an accurate count (sometimes it changes from day to day). Some particular problematic chips are the STM32 controllers (not just the one used in the LibreVNA, but the whole family of processors)

[YuryW]

Hi jankae!
I propose to significantly increase the functionality of LibreVNA by adding the ability to configure and test mixers and frequency converters in the application and in the firmware. Such capabilities are available in professional VNAs, for example, in PlanarVNA. Here is a description of how this function works.

                                               Measurement of mixers. 

The analyzer allows you to measure mixers and other frequency-converting devices using the scalar measurement method.
The scalar method makes it possible to obtain the gain modulus of devices with frequency conversion. Phase and group delay measurements are not possible in this mode. The advantage of this method is a simple measurement scheme without the use of external additional equipment.
The basis of the scalar method is the frequency shift mode. The frequency offset mode introduces a frequency offset between the analyzer ports and is detailed below.
Frequency shift mode.
The frequency shift mode serves to measure the gain modulus of devices with frequency conversion. In this section, devices with frequency conversion are understood as devices that carry out frequency transfer (mixers, converters), and devices that multiply or divide frequency.
The measurement method consists in introducing a frequency offset of the port - the receiver of the signal relative to the port - the source. The frequency offset is set for each port using three factors: a multiplier, a divider, and an offset.
Data coefficients allow you to calculate the frequency of the port relative to the base frequency range.

		Fport=(M/D) * Fbase + Fofs, 

where:
M – multiplier,
D – divider,
Fofs – frequency offset,
Fbase - base frequency.

In most cases, it is enough to apply an offset to one of the ports, leaving the other at the base band frequency (M=1, D=1, Fofs=0).
Examples of calculating the frequency offset coefficients for various types of frequency conversion. The mixer input is connected to port 1, the mixer output is connected to port 2. RF is the input frequency, IF is the intermediate frequency, LO is the local oscillator frequency. The analyzer's second port operates in frequency offset mode:

Port1 -> RF -> (Mixer (LO)) -> IF -> Port2

1. IF = RF – LO Port2: M=1, D=1, Fofs= -LO.

2. IF = LO – RF Port2: M= -1, D=1, Fofs=LO.

3. IF = RF + LO Port2: M=1, D=1, Fofs=LO.
   In the frequency shift mode, the frequency range values for each port are displayed at the bottom of the channel window.

                                         Automatic offset frequency adjustment (AOFA)
   

When measuring mixers in frequency offset mode, you must specify the offset frequency, which is numerically equal to the local oscillator frequency. The offset frequency must be accurate to at least the bandwidth of the IF filter being used, otherwise the receiver will not accept the mixer output. In practice, when testing mixers with a built-in local oscillator, there is an error in setting the local oscillator frequency, which is not known to the user.
The analyzer has an automatic offset frequency function that fine-tunes the offset frequency to the frequency of the device's internal oscillator.

The AOFA function can only be enabled for one of the ports. When AOFA is enabled, the tuning value is displayed in the line of the port, the frequency of which is additionally tuned.
Auto-tuning can be performed within ±500 kHz of a user-defined offset frequency. The function can be enabled or disabled by the user, while the adjustment can be carried out at the request of the user by pressing a button, or periodically, after a specified time interval.

It is possible that at the first stage it will be possible to implement this method without automatic frequency control, which is probably difficult in terms of implementation. If the intermediate bandwidth is greater than the error between the set offset frequency and the mixer local oscillator frequency, then everything will work without autotuning. What will the author and lovers of LibreVNA say?

[jankae]

This would be useful for measuring the conversion gain of a mixer across frequency, right?
In theory possible (maybe with a couple modifications) but some points are not clear to me yet:

1. How to set different frequency offsets per port? If I shift the LO of the VNA, I will shift it for all ports (and the reference receiver). Maybe you need to take the measurements one after the other with different LO values? E.g. first measure the generated frequency, store the result of the reference receiver and one port, then shift the LO frequency and take the measurement of the other port?
2. How does calibration work? Since it is only a scalar measurement, it is a bit simpler, but I assume you still want to calibrate out your cables and connecters. Essentially, you would need a mixer with known conversion gain as a reference standard (and I have seen a setup like this in some document).

If you are okay with slow sweeps, you could check out the spectrum analyzer mode in the LibreVNA. It supports a tracking generator with configurable frequency offset. And if you have done the source and receiver calibration, you will at least get reasonable accurate results (with the VNA ports as the reference plane). But of course the sweep is much slower, because the device doesn't know which frequency to look for and has to scan the whole span.

[YuryW]

This would be useful for measuring the conversion gain of a mixer across frequency, right?

Well, yes. Frequency mixers, frequency multipliers, frequency dividers, and also, probably, the measurement of harmonics (nonlinearity) in broadband amplifiers.

1. E.g. first measure the generated frequency, store the result of the reference receiver and one port, then shift the LO frequency and take the measurement of the other port?

Yes, most likely so, first measurements are made without LO frequency shift and we get the results of the reference receiver into a file and, if necessary, measure the module of the mixer input reflection coefficient at one of the ports. The second stage changes (shifts) the LibreVNA LO frequency and measures the transfer characteristic module on the second port relative to the reference receiver level recorded in the file, since in this measurement there will be no useful signal at the input of the reference receiver due to the LO frequency shift.

2. Since it is only a scalar measurement, it is a bit simpler, but I assume you still want to calibrate out your cables and connecters.

Since we still use the virtual reference signal of the receiver recorded in the file, which was measured without frequency offset LO, to measure the transfer characteristic, it is then possible to use the calibration measurements of the reference receiver recorded in the memory, made during the calibration, taking into account all connecting cables and blocks (for example, attenuators or some other ones)? That is, then a calibrated mixer is not needed?

But of course the sweep is much slower, because the device doesn't know which frequency to look for and has to scan the whole span.

It is possible and so, only it is important how slower the scan will be. When setting up mixers, it will probably be important for the user to complete the scan at least in 1 second. I don't have LibreVNA yet, and I have no practice with it. But this is not for long, as it is now the best VNA in its class in terms of its potential and how it develops based on user opinion.
In general, of course, it would be more convenient for me to set up mixers as well as amplifiers, filters out of habit using modes close to VNA.

[YuryW]

In general, only using software tools with this design, you can get complex S11 and S22, necessary for subsequent matching of the DUT-frequency mixer with neighboring circuit blocks, its complex inverse transfer characteristic and scalar direct transfer characteristic (when LO shift occurs during measurements in LibreVNA) .

[jankae]

Since we still use the virtual reference signal of the receiver recorded in the file, which was measured without frequency offset LO, to measure the transfer characteristic, it is then possible to use the calibration measurements of the reference receiver recorded in the memory, made during the calibration, taking into account all connecting cables and blocks (for example, attenuators or some other ones)?

I don't think this would work. Just to make sure I understand you correctly, this is your idea, right?

1. Perform a normal calibration (without frequency offset) and store the coefficients
2. Apply the frequency offset (by changing the LO frequencies) and use the previously recorded calibration values.

The thing is, there are no individual calibration value for each of the receivers. Uncalibrated, the VNA reports S parameters as the ratio of incoming signal at a port to the reference signal. The calibration removes all influences (e.g. the imperfect receivers, phase shift and attenuation within the VNA as well as from external cables...) but there is no way to distinguish how much is caused by each component.
And during a frequency shifted measurement, the reference receiver would be blind as the frequency is not yet shifted there. So there is really no way to generate this signal ratio and I only have the measured signal at the frequency shifted port to work with.

[rainermueller77]

Hi Jan,
you did a great job with the LibreVNA! I love to use it even when I have the possibility to use a R&S or Keysight VNA.
Some of my tasks are the measurement of quite long cables (>20m) and antenna patterns (transmit antenna + turntabel with DUT with distance >40m). For this measurements on commercial VNAs the sweep time can be set manually to overcome the problem with the long travel time of the wave. This problem is also known as "Measuring Electrically Long Devices with a Network Analyzer". I attached an article describing the problem.
I would love it, when you could implement the manual sweep time setting in the libre VNA. Best would be also if I could reach the setting via SCPI, since I'm accessing the LibreVNA mainly via script.
NWA_lange_Kabel.pdf

[jankae]

you did a great job with the LibreVNA! I love to use it even when I have the possibility to use a R&S or Keysight VNA.

Thank you :)

transmit antenna + turntabel with DUT with distance >40m

Isn't that still <1us of signal travel time? Or did I mess up my calculations?
The LibreVNA currently waiters 60us after PLL lock and before sampling of the ADCs (was 20us in earlier firmware versions). This should be plenty of time, even with your long cables.

Your linked document also mentions that this is a problem specific to continuously swept VNAs ("So the error does not occur in the stepped-
frequency mode and it can be used to check the data"). The LibreVNA is by design always in stepped-frequency mode and should not be susceptible to this problem.

[YuryW]

Hi.
Perhaps we are talking about such additional VNA features:

• Measurement_Delay_TRVNA_Operating_Manual_p61:
  

• Segment_Table_TRVNA_Operating_Manual_p59:
  

[rainermueller77]

transmit antenna + turntabel with DUT with distance >40m

Isn't that still <1us of signal travel time? Or did I mess up my calculations? The LibreVNA currently waiters 60us after PLL lock and before sampling of the ADCs (was 20us in earlier firmware versions). This should be plenty of time, even with your long cables.

You are right with the signal travel time.

Your linked document also mentions that this is a problem specific to continuously swept VNAs ("So the error does not occur in the stepped- frequency mode and it can be used to check the data"). The LibreVNA is by design always in stepped-frequency mode and should not be susceptible to this problem.

Well that is what the document says, but even in stepped mode I can have this problem (tested with R&S and Keysight). For me it is not really clear why, but with my knowledge and not knowing what "sophisticated" algorithms are used in these VNAs, I have no explanation.
In January I will have access to all the equippment and try to measure an example.

[rainermueller77]

Your linked document also mentions that this is a problem specific to continuously swept VNAs ("So the error does not occur in the stepped- frequency mode and it can be used to check the data"). The LibreVNA is by design always in stepped-frequency mode and should not be susceptible to this problem.

Well that is what the document says, but even in stepped mode I can have this problem (tested with R&S and Keysight). For me it is not really clear why, but with my knowledge and not knowing what "sophisticated" algorithms are used in these VNAs, I have no explanation. In January I will have access to all the equippment and try to measure an example.

Today I had time and access to a R&S ZNB8 and a Keysight E5071. I measured S21 of a 40m long LMR240 cable, hoping to reproduce the mentioned problem. But with both VNAs and the LibreVNA there wasn't any problem!
I also found a short note of mine from approx. 5 years ago about the sweep time problem including an example picture, but even with the settings from than (frequency, bandwidth, points, trigger), no problem!
Sorry, that I bothered you with that topic and it can be closed.
Thank you for the great support!

[bvernoux]

@jankae This "Thread" related to Improvements go in different direction since the start
Could you create https://github.com/jankae/LibreVNA/discussions (it is an options to enable in settings=>General=>Features Discussions ) to "discuss" about those different improvements... as an Issue is not really for that and not easy to follow for different threads ...

[jankae]

Agreed, this issue has become way to convoluted. I have enabled discussions for the repository and will close this issue.
For future improvement ideas please either

• use the "discussions" feature on this repository: https://github.com/jankae/LibreVNA/discussions

or

• use the groups.io: https://groups.io/g/LibreVNA-support/topics