开云体育

XENOMORPH, who I believe first introduced the 1500 MHz, tdr, and battery icon firmware mod, has just released a firmware mod that adds additional 256 point FFT capabilities versus the current 128 point FFT. He posted a photo showing the new firmware being used to perform a tdr measurement on a 65 meter length of RG-6U (0.89) see attachment. The measurement was accurate to 0.07 meters. I have also attached his DFU file in-case someone wants to play with it. I am going to order another nanoVNA to experiment with all the new firmware mods that have started to appear. My current firmware works so well that I hesitate to muck with it.

No, It is just ttrftech/NanoVNA head build. XENOMORPH is not an author.

Any source, if any, of github repository ??

Both edy555 and hugen

Hi erik,

edy555 and hugen have sources for 256 point FFT Firmware ?

Where is it ? I can not find...

In the github master of both




I helped to get the TDR improved and that required the 256 point FFT

On Thu, Sep 26, 2019 at 11:14 AM, <erik@...> wrote:

I helped to get the TDR improved and that required the 256 point FFT

it's better to perform 32768 points IFT for TDR. But I suspect it will not fit into the chip memory :)

More time domain samples will not provide better resolution because of the upper frequency limit. However, if the UI allowed picking a peak on the time domain display, one could window that in time, Fourier transform and do a linear fit to the phase to get the delay time and display that.

For peaks which are close together, the Rayleigh criterion set by the maximum frequency is the best you can do. However, the phase fit is most easily done with just a single peak. For an isolated peak the phase resolution and wavelength of the highest frequency measured determines the spatial resolution. I doubt that the velocity factor sufficiently consistent to do better than a few cm.

A basis pursuit will resolve closely spaced reflections, but that's not something that an STM32F series MCU can do.

Off the top of my head, I don't see a way to solve d = a0*exp(j*2*pi*f*t0) + a1*exp(j*2*pi*f*t1) by least squares. Though you might get close enough by estimating a0 & a1 in the time domain and only solving for for t0 and t1.

I wish I had time to work on this more, but other tasks must be attended to.

Have Fun!
Reg

One thing I noticed about the screenshot attached to the first post, is the TDR function seems to involve some human interaction. The first peak is a false positive and the cursor at the second peak was the true cable length reflection. There is probably not enough memory to make it a hands off calculation like Rune's NanoVNA Saver performs.

Current NanoVNA TDR implementation is almost useless, because it shows time with 1 nanosecond resolution.

I experimented with different FFT sizes and it looks that 65536 has the best resolution for NanoVNA. It allows to see picoseconds. But it produce a lot of data, it's better to use 32768 points. 16384 also usable, but insufficient resolution becomes noticeable.

This TDR feature just eats precious memory. F072 has too small memory. So, I think it's better to remove TDR function from firmware and replace it with more useful features

The 900 MHz upper limit implies a sinc(t) width of 2.2 ns. A 256 point complex to 512 point real FFT will provide a long enough trace to reach the end of a ~50 m cable. The screen pixel count is not large enough to display all of that in time in a single screen.

The 1500 MHz upper frequency implies a 1.33 ns sinc(t). In that case the distance will be limited to ~30 m by only having 256 complex points. While more points would interpolate the sinc(t) and make it easier to pick the correct time looking at the TDR response, calculating the shift in the frequency domain will be *much* more accurate.

The screen resolution makes more than 256 samples not especially useful. Better to display the time to the cursor with picosecond resolution calculated in the frequency domain by a linear fit to the phase.

To reiterate. The sampling in time determines the maximum frequency. The sampling in frequency determines the maximum time. The maximum frequency and the numerical precision govern the achievable resolution picking a TDR trace.

The initial spike is a bug. It is a real constant added at all frequencies to the correct magnitude, but with no change in the phase angle. One can determine what that is by zeroing out everything after that initial spike and transforming back to frequency. I suspect that it is the result of a naive attempt to set the DC value in the frequency domain. If the frequency sampling were were infinitesimally fine (and the series length infinitely long), then setting that would be easy, but because it is discrete, that DC value is smeared out across the low frequency components. I did the smearing in frequency as a result of limited series length in grad school. I'll leave the problem one faces going the other way to the reader, at least for now. If you've taken a course in integral transforms or at least the Fourier transform, it's a very valuable exercise. The transform is symmetric, so once you've done one you know the other.

I haven't looked at the code, but I do know the mathematics well enough to be very sure of the preceding statement. "The Fourier Transform and Its Applications" by Ronald Bracewell will fill in all the details anyone might desire. At least until you want all the important theorems about the Fourier transform. For that, "A Handbook of Fourier Theorems" by D.C. Champeney is what you want. However, the latter is only really of use if you're concerned about whether doing the transform is valid.

Have Fun!
Reg

I don't understand all the theoretical limitations associated with different FFT sizes; but from a practical use point of view if my $50 device, as a additional throw-in, can measure a 65 meter length cable accurate to 0.1 meter then I'm impressed.

I am in complete agreement. That was the point of my post. Unless the velocity factor is a lot more consistent than I would expect, that's all you'll be able to do with *any* TDR. And for practical RF tasks, all you need.

For measuring cable length to 100 m , 256 measurements from 1-256 MHz should suffice for 2 cm resolution if the phase angle is accurate to 10 degrees at 256 MHz.

As I have the great pleasure of a Tek 11801 and SD-24 along with a new coil of high quality coax, I'll do some tests once I get connectors. That setup has better than 5 ps TDR resolution. I'm going to make up a set of jumper cables. When I do, I'll be testing them and posting them to a thread on the testing RF connectors and cables I started on the EEVblog forum. I'll make a point of cutting each length under uniform tension so they are the same physical length. I've also got an HP 8753B. So I'll be solving the problem in both domains with 1st rate gear. Albeit rather old.

The nanoVNA has derailed a bunch of my projects because it's a $50 device and can do so much that was out of reach of post hams because of cost in the past.

Have Fun!
Reg

On Fri, Sep 27, 2019 at 03:44 AM, hwalker wrote:

I don't understand all the theoretical limitations associated with different
FFT sizes; but from a practical use point of view if my $50 device, as a
additional throw-in, can measure a 65 meter length cable accurate to 0.1 meter
then I'm impressed.

more FFT size leads to better time resolution. I don't need to measure cable length with TDR, this is not reliable way, because it depends on cable velocity factor which may vary even through cable length and is not stable, it very depends on temperature, frequency and other factors. More easy and reliable way to measure cable length is to use meter or with measurement tape.

TDR allows to analyze cable and connector issues, such as bad contact, impedance change, delay to incident plane, etc. But it needs at least picosecond resolution to be usable. This is why firmware TDR implementation is useless. With nanosecond resolution it's just a toy for those who want to see what TDR is. NanoVNA memory is too small for better resolution, because it needs at least 16384 points FFT. But you can do it on the PC.

I think that waste valuable controller memory for useless feature such as TDR just for one-time use DEMO purposes is a bad way. It is better to use this memory for more useful features, such as better calibration, more measurement points, more graphs etc. If you're needs TDR, you can do it on PC with much better resolution

qrp.ddc,

You are absolutely wrong in saying TDR on the NanoVNA is a 'waste of time'.

This is essentially an Amateur Radio hobby forum.

Amateurs have been at the forefront of many new innovations in radio communication - because they EXPERIMENT with practically anything and everything technical.

For you to say this and that is a waste of time belittles the accomplishments of many Amateurs.

TDR on the NanoVNA is an EXPERIMENT!
It is to be played-with!
It is to be commented on in ways to MAKE IT BETTER.

All you are doing is pushing negativity about. Please don't.
Most of the forum members here will absolutely agree that playing with that particular version of firmware is interesting.

If you cannot understand that - don't use that version of firmware.
Simple, eh?

So - instead of bashing the TDR function, how about you coming up with some alternate functionality that you would like to replace the TDR with.
That way everyone here can experiment with different 'flavours' of firmware.

You said you would like to see: better calibration, more measurement points, more graphs etc.
It's all opensource and you are already writing software - so why no try adding what you want to the firmware yourself?
Several others are already doing that......

Regards,
Larry

On Fri, Sep 27, 2019 at 07:36 PM, Larry Rothman wrote:

For you to say this and that is a waste of time belittles the accomplishments
of many Amateurs.

You're don't understand what I say. I don't say that TDR is waste of time. I say that attempt to integrate it into firmware is waste of controller memory in the detriment of more useful functions.

TDR is very interesting feature. But NanoVNA is unable to handle it self (with no PC) with a good resolution due to low memory resources in the cheap controller. It doesn't means that you cannot use TDR with NanoVNA. You can do it on PC.

It just means that it's better to not make NanoVNA measurement more worse and to cut-off very useful functions just to get TDR inside firmware with a low and not usable resolution.

I think the better way is to use controller memory for more measurement points, to use more precise calibration and to add more useful measurements instead of DEMO version of TDR inside firmware with low resolution. The better way is to implement TDR feature on PC side and use controller resources for more useful features.

There is no question if TDR needed or not. It is definitely must have. The question if it worth to make measurement more worse, cut-off useful measurements just to add low-res TDR on firmware side? Or if it's better to make NanoVNA more precise, more stable and more useful with more measurements, but with TDR implementation on PC software side (with much better resolution and more usable)?

I would be happy to see TDR inside firmware, but not in the detriment of precision and more needed features. Unfortunately NanoVNA controller cannot handle all things simultaneously, there is needs to make decision if we needs more precise measurement, or DEMO TDR inside firmware. Any case doesn't prevent to use NanoVNA for TDR. The question is where to implement it - on firmware side or on PC software side. That's what I'm talking about.

On Fri, Sep 27, 2019 at 07:36 PM, Larry Rothman wrote:

It's all opensource and you are already writing software - so why no try
adding what you want to the firmware yourself?

I'm already doing that. Unfortunately I'm not familiar with calibration math, so I have no idea how to improve it.
If you can help with the math details for better calibration, it will be nice.

OK, no problem then.

However, please remember - considering the cost of the NanoVNA - it puts more capability in your shirt pocket than most of its predecessors used by Amateurs.
As I mentioned, it takes no effort to flash different versions of firmware onto the device. We aren't doing microwave design were pico-seconds matter.
And you can take it up an antenna tower - without a PC.

If I need to check out a length of cable from my Tx to the antenna, it is more than adequate to show the approximate location of any issues - and that includes connectors.
If the Nano TDR shows shows me a reflection a foot or two away from a connector, don't you think I will look at the connector before anything else?
It is good enough to play with and get a feel for how it works and that in my opinion is not a waste of time.

Others are using the Nano to learn from - from both a programming and an RF point of view.
There has been some great dialogue in the forum regarding TDR and RF theory in general.
You are sharing your TDR knowledge as well - that's great!
I've worked in the RF field (no pun intended) for 40 years and I'm still learning.

All I am saying here is that the various diagnostic functions that are being graciously developed for the Nano by very talented individuals, may not be for everyone but, they are NOT a waste of time for everyone.

Cheers,
Larry

On Fri, Sep 27, 2019 at 10:23 PM, Larry Rothman wrote:

If the Nano TDR shows shows me a reflection a foot or two away from a
connector, don't you think I will look at the connector before anything else?

If I'm looking for discontinuities in the circuit, which total length is 1 foot total and TDR can show it one or two foot away from real point, I think it will be useless.

To be more clear what I'm talking about, here is pictures of TDR measurement for the same S1P file captured with NanoVNA, with different FFT size. This TDR implemented on PC side, so it doesn't limited with memory and don't requires TDR support in the firmware and allows to use any size FFT for tests. Actually I capture this S1P with old firmware which doesn't have TDR in the firmware at all.

In my previous post, I was referring to coax from my hamshack to the antenna - not a piece of transmission line a foot or 2 long.
Please remember that from a practical viewpoint, LOW resolution in a handheld device is much better that NO resolution (ie: no TDR function).

...Larry