开云体育

Yes, flush this firmware cleaning, then your own.

Successfully installed your white.dfu. Still blue.

Hardware issue ? Some kind of flash memory that needs to be cleared ?

73,
Steve, N2IC

22 : AnyVNA From The Common User's Point Of View :

A Practical Application of the Core Uncertainty Strips

Hello,

Allow us, please, to point out that, first of all, the Practical
Uses of the Core Uncertainty Strip(s) CUS(s) resulting from
AnyVNA system are limited only by the imagination of it's
Common User in Design, Prediction, Explanation,
Justification, Evaluation, or whatever else are his needs...

Anyway, since our Sole Objective here is the Evaluation
of NanoVNA, we begun yesterday our final trials
by using that one-port 50-OHM DC ref2007box,
for which we got its Core Uncertainty Strip(s) CUS(s)
using our VNA system:

[20] : Measurements with Core Uncertainty:
/g/nanovna-users/message/3273

So, our aim was to put the Initial (R,X) calibrated
results of NanoVNA onto (R,X) CUS diagrams.
For that purpose, we built [ods] files by using the
Calc application of foss LibreOffice 4.1.0.4 and
we extracted the following resulting images:

A : Initial NanoVNA results vs ref2007box CUSs :

1 : R ~ f :
2 : X ~ f :

From these figures we concluded at once that
since the most of NanoVNA results were definitely
lie outside the CASs, this is due - perhaps -
to the unavoidably inserted N-to-SMA converter.

After that, and in order to somehow substantially support
this - guessed - conclusion, we "manipulated" the
NanoVNA results by mathematically transforming them
in such a way to put them inside the CUSs, as follows:

B : Initial (pink) and Transformed (red) NanoVNA results vs ref2007box CUSs :

3 : R ~ f :
4 : X ~ f :

Finally, in order to complete the "dirty manipulation of
data" we just "eliminated" the initial NanoVNA results
from the diagrams:

C : (red) (Transformed) NanoVNA results vs ref2007box CASs:

5: R ~ f :
6: X ~ f :

In this way, we could - prematurely - concluded that the
NanoVNA is as much reliable as our VNA.

But, obviously, more work has to be done in the direction of
finding at last the NanoVNA CUSs.

Sincerely,

gin&pez@arg

22

3d printing is a slippery slope. I started out with a printer 2 years ago
and now I have 3.

Dave-KB1PVH


Sent from my Galaxy S9

I got one today as well, will be putting it on this afternoon.

- I really don't need another hobby, but 3D printing is something I really
want to do!

Try this one, instead of blue, white.
DFU Firmware.

Well, it doesn't work for me....

Tried:

1) Intentionally putting a syntax error into main.c to see that I was building the correct main.c.
2) Shorted the pins to put into DFU mode.
3) Changed all of the trace colors to (255,255,255).
4) Made a change in plot.c, to confirm that the correct firmware was being flashed.

The result is the original, default colors.

73,
Steve, N2IC

This little ''case'' being made of plastic won't give you any shielding or isolation.

But it sure will help cut down on the buildup of pocket lint getting inside!
I just received mine and got it installed without any instructions.
It is held on by the screws holding the outer panels in place.
Bill

I just tried it myself. Everything is working. Did you remember to click save before compiling?

Sorry, DMR...it doesn't work. Still blue.

I do a make - main.c recompiles, builds,etc.

do sudo make flash and the flash appears to install just fine.I'm using the config->dfu->reset and enter dfu, not shorting the pins.

73,
Steve, N2IC

Change colors in this line. main.c

Standard
/* trace_colors[4] */ { RGB565(0,255,255), RGB565(255,0,0), RGB565(0,0,255), RGB565(50,255,0) },
Blue -> White
/* trace_colors[4] */ { RGB565(0,255,255), RGB565(255,255,255), RGB565(0,0,255), RGB565(50,255,0) },

I have been successfully making some small tweaks to the 0.1.1 firmware. I would like to change the colors of the traces to make them more readable in sunlight. However, that tweak has not been successful. In main.c, I tried changing the trace_color array in config_t config. However, it does not seem to have any effect. What am I missing ?

Thanks,
Steve, N2IC

On Sat, Sep 28, 2019 at 02:39 PM, Warren Allgyer wrote:

As accurate as the Nanovna appears to be, you will see an even tighter
correlation if you calibrate both instruments from the same set of calibration
loads.

I'll try that tomorrow with the 1 GHz filter. Here are the cal loads for the Agilent - can't lose just one of them - it's all or nothing!

My implementation did not have a limit on the points scanned but of course edy555 is free to do different
Maybe hugen has a better solutiom

Warren wrote:

"The Nanovna has become my go-to bench instrument and the spectrum analyzer/tracking generator/rf bridge rarely even gets powered on these days. Simply an amazing device!"
--------------------------------------------------------------------------------------

I agree Warren. I can't wait until the Belton TX hamfest next month so I can get rid of my HP8568B spectrum analyzer, HP8444A tracking generator, and various RF bridges that I was only using sporadically. My workbench will feel like its got a new lease on life.

Herb

Benny,
Some of the lower cost nanoVNA's are delivered without a battery. Check and see if you have one. You may be charging a capacitor when you plug it in, but after disconnecting from USB power the capacitor discharges to the point it can no longer power the nanoVNA.

Heerb

John,

As accurate as the Nanovna appears to be, you will see an even tighter correlation if you calibrate both instruments from the same set of calibration loads.

The Nanovna has become my go-to bench instrument and the spectrum analyzer/tracking generator/rf bridge rarely even gets powered on these days. Simply an amazing device!

WA8TOD

I have a nanoVNA with USB-C after charging, I turn it on without the USB-C power on, it turns on fine, but turns off again after approx. 30 sec. - but run with USB power plugged in, does anyone have a good idea, preferably a solution? ;-)

Best regards Benny OZ5RZ