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 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 (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 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.

[OneOfEleven]

So what you could do is to buffer the 70MHz I.F signals and feed them straight into ADC's sampling at say 8MHz or some such rate (under sampling). So long as the bandwidth of the 70MHz I.F is suitably limited (1MHz max BW maybe ?) before going into the ADC's everything would be good.

Some info here ..

https://www.ti.com/lit/an/slaa594a/slaa594a.pdf http://sss-mag.com/pdf/ad5.pdf

[sp9bsl]

Hi, I've made some measurements of the sample I received from Hugen, I want to thank Him very much for being so kind! I'm very satisfied how it works after few simple hardware changes I made (the additional screws as Jan recommended and few small pieces of EMI gasket around SMA connectors). After applied the gasket I notice less temperature drift seen on isolation measurement (much less than OneOfEleven shown on his video).

VNA2 measurements.pdf

[OneOfEleven]

We have some gasket tape to use too, just haven't got around to using yet.

What additional screws have you added I wonder ? .. are they to add extra clamping for the top/bottom case halves to the board ?

Have you got a photo of where the extra screws go ?

[sp9bsl]

Hi OneOfEleven, I've added 4 screws as recommended by Jan. It is quite hard to do it - especially the two between the ports at edge of case/pcb. I would recommend to use 2.5mm screws or less instead of 3mm I've used as Jan recommends. I have quite good bench drill but almost destroyed the case during drilling. In newer version of pcb, Jan moved RF traces and switches 2.1mm inside the board (more distance to the pcb ege). I wanted not to destroy the vias around the GCPW so I had to drill quite close to the edge of pcb. Fortunatelly the screws keeps the case very strong (3mm uper case bore, 3mm threaded holes in the bottom case, 3mm pcb holes).

And the coordinates on the pcb (reverse engineering from gerbers...):

I did some pcb cleaning with IPA, because there were some flux residue on ENIG exposed areas around RF source attenuator which caused aluminum case not to contact very well to ENIG.

I also added the 2mm thermal pads (high thermal conductive material) under the mixers/PLLs, so the bottom part of the aluminium case is much warmer now, the top of QFNs are equipped with thin (0.1mm) silicone pad, "just in case". QFNs are designed to be cooled by exposed pad and thus aluminium case should be thermally coupled with bottom of pcb more than the top of plastic chip case. I plan to make heatsink at the bottom of case, probably with fan because I see no influence on measurement noise when fan is running close to analyzer (laying on the top or bottom of the case).

I was planning to test one more improvement, some time ago when I worked with MAX2871 I've used a microwave absorber to help isolate the receiver from PLL, it was a piece of ESD foam (ordinary black foam used for IC transportation). It was quite good absorbing the rf field above 3GHz. I think I will test it here too inserting some of it into port cavities under and above of pcb with 1mm clearance to pcb.

Some remarks about the software: I reported some time ago to Jan that there is problem with locales, but I see the last version works perfect in this area - thank you! I met other thing, not very important but want to let you know: when I have sweep set for example 2 to 3 GHz, and then load saved setup with wider sweep range, the application expands the widows (axes) but not the sweep range. Sweep remains as it was during last setup before loaded the new (wider) one.

Off topic question :) @OneOfEleven: do you plan to add S12 and S22 to your exelent software? So far I see it only works for Port1.

[OneOfEleven]

Thank you SP9BSL !

Adding those extra holes/screws won't be a problem here, we have the pillar drill etc so will do that this week some time.

My software does already sample and store S12 and S22, I just haven't added the extra options to show them on the graphs - yet.

Loosing frequency points when sampling is a bit concerning really as no measurement instrument show ever loose data like that, but the CPU in the VNA just doesn't have enough RAM to store a full scan unfortunately. If it were me I'd change that to ensure their was enough ram to store a full scan and add a new scan-on-demand command so that the VNA performs each individual full scan at a rate that the connected PC can cope with, that way no data would ever be lost.

Anyway, I don't want to replace Jan's PC software, he's doing a wonderful job, just thought I'd add basic/simple ability to use Jan's VNA is all, at least for now.

Is there an updated PC software (windows) and newest firmware pre-built files at all ? .. I still can't install QT on my laptop due to lack of SSD space.

[jankae]

@OneOfEleven

If the I.F signal into the ADC's is fairly clean you can use under sampling for the ADC sampling

I have used that before but didn't really consider it for this project. Not exactly sure why, I am collecting ideas for a new hardware version in the future and will think about it again.

Have you got a photo of where the extra screws go ?

Although SP9BSL already answered that, here is a list with modifications and hardware fixes I have done (including the screws): https://github.com/jankae/VNA2/blob/master/Documentation/DeveloperInfo/VersionsAndModifications.md

If it were me I'd change that to ensure their was enough ram to store a full scan and add a new scan-on-demand command so that the VNA performs each individual full scan at a rate that the connected PC can cope with, that way no data would ever be lost.

I am thinking about another solution: Temporarily pause the scan if the internal RAM buffer is full. That way no points should get lost and it can work without changing the hardware. I would need quite a lot more RAM to store a full scan. There certainly are uCs with enough RAM (or just use an external RAM) but if possible I'd like to keep the current controller (easier firmware development if all existing samples have the same controller and it also fixed the missing points problem for the already distributed samples). At the moment the FPGA is responsible for the timing of the scan (once the uC has configured all the points), so I'll have to change the FPGA configuration a bit. It shouldn't be too hard to implement :)

@sp9bsl

I met other thing, not very important but want to let you know: when I have sweep set for example 2 to 3 GHz, and then load saved setup with wider sweep range, the application expands the widows (axes) but not the sweep range.

The span/frequency settings are not included in the saved setup files (because I already had the option to save them whenever the application is closed). So far, the setup files contain only the configuration of traces, graphs and markers. Over time I will add more configuration to the setup, probably starting with the span/frequency setting.

By the way: If you do find strange behavior like this, feel free to open a new issue for it, that way I am constantly reminded of it (this issue is full of improvement ideas but if I don't implement them right away, I might forget about it)

[EnthuMan]

@jankae Thanks a lot for the detailed answer. Is the IF bandwidth calculated as Sampling_Rate/N (number of points used for FFT)? So for highest IF bandwidth i.e., lowest number of points: 1e6/131072 and for smallest IF bandwidth: 1e6/16

I was tryiing to understand your calculation of the achievable sweep rate for a particular IF bandwidth: 1) Programming time: ~20us (guess) 2) Settling time: 20us 3) Data acquisition and single DFT calculation: N * 1e-6 (I suppose you don't wait to acquire the N samples to start processing, you might be starting right from the time the first sample arrives) 4) Some more processing: 20us 5) Time to send this to microcontroller and final calculation at a particular frequency: 20us

another question: what is the impact of IF BW in this case where the sought signal is a single tone of a known frequency?

Apologies for asking questions which are probably too basic but thanks in advance for answering them :)

A small suggestion: Since your IF and sampling frequency are related as F_IF = F_sampling/4 you could consider using a very simple downconversion mechanism instead of an NCO and a mixer (probably could save some FPGA resources)

https://dspguru.com/dsp/tricks/complex-downconverters-at-fs-over-4/

@oneofeleven I am also planning to make a small setup to try out undersampling. Will report in some days. \

On Tue, 29 Dec 2020 at 22:04, jankae notifications@github.com wrote:

@OneOfEleven https://github.com/OneOfEleven

If the I.F signal into the ADC's is fairly clean you can use under sampling for the ADC sampling

I have used that before but didn't really consider it for this project. Not exactly sure why, I am collecting ideas for a new hardware version in the future and will think about it again.

Have you got a photo of where the extra screws go ?

Although SP9BSL already answered that, here is a list with modifications and hardware fixes I have done (including the screws): https://github.com/jankae/VNA2/blob/master/Documentation/DeveloperInfo/VersionsAndModifications.md

If it were me I'd change that to ensure their was enough ram to store a full scan and add a new scan-on-demand command so that the VNA performs each individual full scan at a rate that the connected PC can cope with, that way no data would ever be lost.

I am thinking about another solution: Temporarily pause the scan if the internal RAM buffer is full. That way no points should get lost and it can work without changing the hardware. I would need quite a lot more RAM to store a full scan. There certainly are uCs with enough RAM (or just use an external RAM) but if possible I'd like to keep the current controller (easier firmware development if all existing samples have the same controller and it also fixed the missing points problem for the already distributed samples). At the moment the FPGA is responsible for the timing of the scan (once the uC has configured all the points), so I'll have to change the FPGA configuration a bit. It shouldn't be too hard to implement :)

@sp9bsl https://github.com/sp9bsl

I met other thing, not very important but want to let you know: when I have sweep set for example 2 to 3 GHz, and then load saved setup with wider sweep range, the application expands the widows (axes) but not the sweep range.

The span/frequency settings are not included in the saved setup files (because I already had the option to save them whenever the application is closed). So far, the setup files contain only the configuration of traces, graphs and markers. Over time I will add more configuration to the setup, probably starting with the span/frequency setting.

By the way: If you do find strange behavior like this, feel free to open a new issue for it, that way I am constantly reminded of it (this issue is full of improvement ideas but if I don't implement them right away, I might forget about it)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jankae/VNA2/issues/2#issuecomment-752149056, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASJFO5SBQBWZEGJWNSCAUTDSXIAJZANCNFSM4R3TMTEA .

[OneOfEleven]

Although SP9BSL already answered that, here is a list with modifications and hardware fixes I have done (including the screws): https://github.com/jankae/VNA2/blob/master/Documentation/DeveloperInfo/VersionsAndModifications.md

Thank you Jan.

I am thinking about another solution: Temporarily pause the scan if the internal RAM buffer is full. That way no points should get lost and it can work without changing the hardware. I would need quite a lot more RAM to store a full scan. There certainly are uCs with enough RAM (or just use an external RAM) but if possible I'd like to keep the current controller (easier firmware development if all existing samples have the same controller and it also fixed the missing points problem for the already distributed samples). At the moment the FPGA is responsible for the timing of the scan (once the uC has configured all the points), so I'll have to change the FPGA configuration a bit. It shouldn't be too hard to implement :)

That sounds good! .. would also mean no changes to the PC software would be needed as the VNA does the pausing itself.

I'm going to try adding 10 more screws to my VNA as per this (the extra 10 are the semi transparent holes). I've overlayed the gerbers as a transparency so that I could see where exactly to position the extra holes without cutting through inner layer tracks ..

[slightly updated hole positions]

Paint Shop Pro image file ..

IMG_5449 B.zip

[jankae]

Is the IF bandwidth calculated as Sampling_Rate/N (number of points used for FFT)?

That is what I use in VNA mode, yes.

I was tryiing to understand your calculation of the achievable sweep rate for a particular IF bandwidth

I never calculated that, I only ever measured the number of points received on the PC per unit of time.

1) Programming time: ~20us (guess)

This is closer to 7us.

2) Settling time: 20us

Actual settling time of the PLLs is about 10-15us so I always wait 20us before sampling to be save (lock detect of the MAX2871 is constantly asserted when only doing very small frequency adjustments so I can't use that for settling)

3) Data acquisition and single DFT calculation: N * 1e-6 (I suppose you don't wait to acquire the N samples to start processing, you might be starting right from the time the first sample arrives)

Exactly, processing is done as the samples come in. The main FPGA clock is 102.4MHz. Compared to that the sampling rate is really slow which leaves a lot of time to handle the samples.

4) Some more processing: 20us

No extra processing, right after the last sample, the FPGA transfers the DFT bin into a buffer register and the CPU can read it anytime (only has to do so before the next sampling step is complete and the result is updated with the new value).

5) Time to send this to microcontroller and final calculation at a particular frequency: 20us

This happens concurrently to the setting up and sampling of the next measurement point. I have forgotten how long it takes but I think it was a bit longer when I benchmarked it a while ago (maybe 40-50us).

another question: what is the impact of IF BW in this case where the sought signal is a single tone of a known frequency?

More samples of the ADC are used, so the result is less noisy with low IF BW/high number of samples

A small suggestion: Since your IF and sampling frequency are related as F_IF = F_sampling/4 you could consider using a very simple downconversion mechanism instead of an NCO and a mixer (probably could save some FPGA resources)

That is what I used for the very first experiments. At the moment I am actually sampling the ADC only at 800kHz. This works out to cover 5 periods of the IF with exactly 16 samples (which is the reason for the minimum amount of 16 samples). F_IF=F_s/4 has the problem that the 3rd harmonic of the IF aliases to the IF in the ADC which gave slightly worse measurement results.

FPGA resources are not a problem at all in VNA mode. But the FPGA is really helpful in spectrum analyzer mode, where I calculate up to 96 DFT bins while sampling the ADC, this results in much faster sweeps at low RBWs

[jankae]

@OneOfEleven

I'm going to try adding 10 more screws to my VNA as per this

Please check the additional holes you added extra carefully. At the bottom part (close to the ports) both inner layers are ground but in the upper part, one is ground and one is used for various supply voltages. If you drill the holes there, the screws might short something. Also make sure you don't accidentally cut a supply polygon completely.

By the way: I managed to mill small (1mm) grooves into one of my shielding and will try with the RF gaskets you suggested earlier soon.

[OneOfEleven]

Please check the additional holes you added extra carefully. At the bottom part (close to the ports) both inner layers are ground but in the upper part, one is ground and one is used for various supply voltages. If you drill the holes there, the screws might short something. Also make sure you don't accidentally cut a supply polygon completely.

That explains the inner layer space around some ground via's! OK, I've moved a hole and removed another.

By the way: I managed to mill small (1mm) grooves into one of my shielding and will try with the RF gaskets you suggested earlier soon.

ooo ! .. you wouldn't need the extra holes you added if you're going to do that as you'd have full contact everywhere.

The Signal Path guy has just done a nice teardown video of the R&S 6GHz VNA. At 13:16 he turns the board over at which point you get a glimps of the milled casing with the gasketing in place ..

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

What CNC machine do you use I wonder to do your nice casings ?

[jankae]

you wouldn't need the extra holes you added if you're going to do that as you'd have full contact everywhere

This is more an experiment how much of a difference the gaskets make. The small grooves are probably too expensive to manufacture but if there is a lot of improvement I could use thicker walls in the shielding and also thicker gaskets.

The Signal Path guy has just done a nice teardown video of the R&S 6GHz VNA

That was really interesting to watch, because it is (almost) the same frequency range and also a reasonable compact design. Of course I can't compare my VNA to an R&S design but I would have loved to get some information about the used chips in there.

What CNC machine do you use I wonder to do your nice casings ?

It is a converted Optimum BF20. I wasn't sure I could do the small grooves because the main spindle does not have enough RPM for such a small end mill. I had to add a secondary high-speed spindle and even then I still broke three tools. 1mm is just too small

[sp9bsl]

@OneOfEleven interesting video, I wonder where to get those flexible gaskets that RS used... The ones widely available (for example the Wurth electronic) are too rigid to make such radius as we have here. The exposed traces are not ENIG, it looks like silver plating or something else...

[OneOfEleven]

interesting video, I wonder where to get those flexible gaskets that RS used... The ones widely available (for example the Wurth electronic) are too rigid to make such radius as we have here. The exposed traces are not ENIG, it looks like silver plating or something else...

@sp9bsl It might be that they are using silicone gaskets rather than mesh/fabric type gaskets. Silicone gaskets are conductive silicone squirted into the groves in the case halves, they are soft (as per silicone is), or could be just cut pieces of conductive silicone 'cord' placed into the case groves, I'm not sure as he didn't show the gasket seals in detail.

Conductive 1.35mm silicone gasket, 3 UKP per meter here .. https://www.rf-microwave.com/en/rfi-shielding-ltd/1-0014/silicone-elastomer-conductive-elastic-gasket-1/gue-1.35

[sp9bsl]

Thank you, I've never used such silicone. I think It also worth to try print gasket with conductive ABS or PLA.

[OneOfEleven]

Thank you, I've never used such silicone. I think It also worth to try print gasket with conductive ABS or PLA.

Well the problem is that gaskets need to have some softness to them in order to work as intended, otherwise the gasket would not fill in any gaps and make full electrical contact where the case meets the PCB.

If you could 3D print a conductive gasket using flexible filament then that would be really nice, I could do that myself as I have a 3D printer, but I don't know of any available conductive 3D printer filament.

[OneOfEleven]

There is also ..

https://www.spira-emi.com/product/spira-shield

That can be bent in fairly sharp corners ..

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

[blackberryer]

If the edge of soldermask can be made into this kind of hole, I think it will be much better

[sp9bsl]

If you could 3D print a conductive gasket using flexible filament then that would be really nice, I could do that myself as I have a 3D printer, but I don't know of any available conductive 3D printer filament.

I found TPU Ampere here, manufacturer claims it conducts the current... Although expensive compared to ordinary PET or PLA which I use daily...

[jankae]

My shielding now looks like this: In detail: I have used Laird 8863-0100-50, the grooves are 1mm wide and 0.8mm deep. Did this change anything? Well, not really: I was hoping for some improvement of the isolation at higher frequencies but nothing significant happened (by the way, the traces were taken without any calibration but that doesn't really matter for relative comparison of isolation performance).