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 [email protected] 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 https://github.com/jankae/VNA2/issues/2#issuecomment-701105210, 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 ([email protected]) 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 https://github.com/jankae/VNA2/issues/2#issuecomment-733606090, 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]

Hi, thanks for taking an interest in the project, I hope this clarifies your questions:

1. Cost, mostly. A 40MSps ADC is significantly more expensive than the 1MSps I ended up using (and I need three of them). With the lower sampling rate, of course I also need a lower IF and 250kHz seemed like a good match for the sampling rate. 1.1. I think in general a higher IF means better performance (in terms of speed, RF performance is not really affected) while also requiring more processing power. The limiting factor in my design is definitely the ADCs, the FPGA could handle much faster data rates.
2. Both stages combined perform the downconversion. The first LO is always 62MHz above the measurement frequency, the second LO is fixed at 61.75MHz, resulting in a final IF frequency of 250kHz. There are also some special frequencies where the second LO is shifted slightly to compensate for non-ideal fractional dividers in the MAX2871 PLLs. I have been getting quite a few questions why dual-stage conversion is implemented instead a simpler one-stage. I found one more reason I haven't shared yet: The 1.LO PLL can't go below 23.5MHz. With only one stage I would either have to use a much higher IF (->more expensive ADCs) or a more complicated 1.LO (similar to the source PLL) to cover the measurement frequencies below about 23MHz.
3. Your description sounds about right to me. N depends on the IF bandwidth which is user selectable. The minimum value for N is 16, the maximum 131072 (could be changed with a different FPGA implementation). This translates to an IF bandwidth of about 6Hz to 50kHz. The single bin DFT is not sent directly to the PC, the uC performs some calculations and only sends the (uncalibrated) S parameters (basically it divides the single bin DFT of each port by the single bin of the reference receiver). At the highest IF bandwidth, the achievable sweep rate is 10kpoints/second (although this requires a fast USB implementation on the PC side to keep up with the data). Pipelining in the way you describe it is not implemented. The FPGA is easily fast enough to calculate the single bin DFT while acquiring the samples. I tried to set up the PLLs while taking the samples from the previous point but as soon as I write the first register, the output changes so that is not possible. Each point follows this sequence:

• Set up source and 1.LO PLL
• Set the port switch to route the source signal to port 1
• Wait some time to let everything settle (about 20us at the moment)
• Sample ADCs, calculate S11 and S21
• Set the port switch to route the source signal to port 2
• Wait for settling again
• Sample ADCs, calculate S22 and S12
• Transfer all S parameters to PC, repeat for next point

[OneOfEleven]

If the I.F signal into the ADC's is fairly clean you can use under sampling for the ADC sampling, I use it all the time without any performance problems, and many other RF commercial instruments use under sampling too, it's a good method to use when sampling fixed frequency RF signals (such as in I.F's). Many ADC chips have been designed with under sampling in mind when it comes to RF sampling.