- isn't it starting to look like a series fixture?
- since we know V1, is it necessary to measure Vin?

I think that this kind of bridge was designed for devices with only one input. In case of Red Pitaya, if we can accurately measure both branches of the bridge then the common mode rejection can be done numerically.fisafisa wrote:Instead of using a bridge with a transformer/common mode rejection circuit,
why not simply acquire both branches of the bridge using the 2 RPI inputs?
In my VNA configuration, three series of values are recorded synchronously: DAC samples, ADC1 samples and ADC2 samples. With the open/short/load calibration, there is enough information to calculate Z from the DAC samples and ADC1 samples.fisafisa wrote: One will simply be 0.5 Vin
The other will be Vin /(50 + Z) * Z.
By looking at the phase and amplitude one can measure Z.
In fact, if one could rely on the Zout of RPI, one would not need to measure Vin...
The complicated bridge is not the only possible configuration. There are at least four possible configurations:fisafisa wrote:In that case one could duplicate the circuit and make a 2 port measurement.
Just a silly idea, but I cannot be convinced we need a complicated bridge since we have 2 ports?
As far as I know, the SD card images available from http://redpitaya.readthedocs.io/en/late ... Dcard.html have a compatibility problem.I am running the current stable RedPitaya OS and I also tried the current beta release RedPitaya OS.
This is very interesting result. I didn't see many comparisons of my VNA application for Red Pitaya with other analyzers. The only other comparison that I know about is the comparison of Red Pitaya VNA vs Arduino VNA done by Ghislain F4HGA. It can be found at the following link:==> the results differ from the results of well-known analyzers like RigExpert, SARK or miniVNA. The SWR and return loss data RedPitaya/VNA returns are shifted about 150-350kHz. For example: the transceiver or Rigexpert Analyzer shows resonance frequency at 14.150kHz and Redpitaya/VNA shows 13.870kHz.
Before I tried the latest stable and latest beta I was running 0.95.pavel wrote:[As far as I know, the SD card images available from http://redpitaya.readthedocs.io/en/late ... Dcard.html have a compatibility problem. As a workaround, I’d suggest to use the previous version (0.95) of the SD card images.
I will revert and retry and let you know ...pavel wrote:These images are available from the following links:
http://pavel-demin.github.io/red-pitaya ... -ecosystem
http://downloads.redpitaya.com/downloads/0.95
thanks for clarification. I will use it on my Linux desktop.pavel wrote:If you're using vna.py, then it's better to use this version. The latest version in the master branch isn't compatible with the VNA application from the application marketplace. I updated the code but didn't have time to update the pre-built binaries.
Right, I was using the latest windows client version from market place with the mentioned client application for Windows.pavel wrote:It's still OK to use the VNA application from the application marketplace with the client application for MS Windows.
I've just updated all the VNA related files. Could you give them another try?Ok let me know when you have done your updates and I will recheck.
so I need to download THIS SD CARD IMAGE and write it onto my MMC ?[...]
Getting started with GNU/Linux
Download customized SD card image zip file.
[...]
Users browsing this forum: No registered users and 1 guest