开云体育

hooray at last,the answer i needed,thanks eric 73

On Thu, Nov 28, 2019 at 05:40 AM, paul larner wrote:

yes they do,i need to know if i need the resistive touchscreen or the
capacitive one!

Unless I misread the diagram those displays have 40 pins.

Good luck on your search.

Did you check that they use the same controller?

On Thu, Nov 28, 2019 at 1:38 PM <erik@...> wrote:

Do the LCD modules you selected have 18 pin connectors as described in the
wiki?

--
NanoVNA Wiki: /g/nanovna-users/wiki/home
NanoVNA Files: /g/nanovna-users/files
Erik, PD0EK

Thank you,

Hans

-----Ursprüngliche Nachricht-----
Von: [email protected] <[email protected]> Im Auftrag von neb40gsm via Groups.Io
Gesendet: Donnerstag, 28. November 2019 11:55
An: [email protected]
Betreff: Re: [nanovna-users] nanoVNA Partner #nanovna_partner

Hi,

Thanks to all who appreciated the software. Consider it as my contribution to the group.

Kind regards,

neb

You need the resistive touch panel.

yes they do,i need to know if i need the resistive touchscreen or the
capacitive one!

Do the LCD modules you selected have 18 pin connectors as described in the wiki?

--
NanoVNA Wiki: /g/nanovna-users/wiki/home
NanoVNA Files: /g/nanovna-users/files
Erik, PD0EK

On Thu, Nov 28, 2019 at 03:12 AM, paul larner wrote:

Isnt it amazing how i cant get an answer to a simple question!,if i wanted to
use a tab i would have asked that!!,pointless as my tab doesent support the
app,just wanted to know what screen to get out of the 2 i linked too!.

Calm down Paul!

No one can tell you which one is better because it's personal preference.

Besides, there is only one person who attempted to change the display and that info is in the Wiki/Files section of the forum (Herman's work).

Now's the time to experiment - look at the specs and buy the display that matches the interface - simple.

Search the 7500+ messages - hopefully, you'll find more info.

John,

If you're sweeping an antenna that's in close proximity to the VNA,
leakage from the cables is probably not going to be a limiting
factor. Other aspects of cable quality (impedance bumps at
cheap connectors, as just one example) still matter. Another
very important aspect of cable quality is stability of the cable's
delay in the face of flexing the cable. If, for example, the cable
is flexed in between measuring the short and open CAL standards,
it can really throw off even single port calibrations.

You're right: really good test cables for VNA work would set you
back more than 10X the price you probably paid for your nano-VNA.
And a decent set of CAL standards goes for around $4k to $5k
last time I looked, which was close to 10 years ago.

I have access to a lab-grade VNA and have been meaning to
take a look at the cables that accompanied my Aursinc nano,
but haven't gotten around to that yet.

Dana

Hi aa_Talaat
Sort of right.
For the input impedance measurements you may calibrate Ch0 on the output side the inserted attenuator.
40dB is a bit tough as it will introduce larger measurement error/noise than if you used a 20dB attenuator which might not saturate the amplifier. I you have an oscilloscope/small signal power meter you may inspect the output or if you have more attenuator what the S21 output with 40dB versus 20dB in the TX path and if difference is 20dB then no saturation.
Kind regards
Kurt

-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af aa_talaat via Groups.Io
Sendt: 28. november 2019 12:21
Til: [email protected]
Emne: [nanovna-users] Measure S11 and S22 for active devices

I build a common emitter amplifier based on BFP420 BJT, and would like to measure its gain and input and output impedance. As the gain should be within 25dB, so I connected a 40dB 50 ohm input/output attenuator between CH0 and the input of the amplifier to avoid driving the amplifier into saturation, then connected the output of the amplifier to CH1.

The negative dBs readings of S21 were making sense to me after adding up logically 40dB to come up with the actual amplifier gain. However as the inserted attenuator impedance at CH0 is 50 ohm, the readings of S11 was showing as almost flat 50 ohm across the frequency range which is expected.

To measure amplifier input impedance (S11), I removed the attenuator and connected amplifier input directly to CH0 and connected amplifier output to a 50 ohm load. As the amplifier is driven into saturation, I am not sure if the S11 readings are correct, and I can rely on for small signal.

I repeated the same but swapping the amplifier input and output to measure the output impedance (S22).

Is this the right way to measure input and output impedance for such amplifier.in the absence of power control on the nanoVNA? Is there a better way?

There is limited output power control on the nanoVNA you can use (limited, no 30dB control)
Use a terminal emulator to connect to the nanoVNA and you can use the "power" command to 4 levels of output power
power 0
is the lowest level,
power 3
the highest level
The levels result in 2, 4, 6 and 8mA into 50 ohm so the maximum current range you have is 8 / 2 = 4 , 4 times 4 (as you want the power range, not the mA range) gives you a factor 16 in power range

But for you amplifier this range is insufficient so I think you are using the right approach

W.r.t the negative reading, if you do a calibration of the thru with the 40dB attenuator in line (no amplifier) the new 0 level of S21 will help showing positive levels for you amplifier.
By not storing the updated calibration it is a real temporary measurement calibration and when the nanoVNA is reset everything goes back to normal.
Whether the saturated measurement of S11 makes sense depends on the type of input component in your amplifier.

--
NanoVNA Wiki: /g/nanovna-users/wiki/home
NanoVNA Files: /g/nanovna-users/files
Erik, PD0EK

I build a common emitter amplifier based on BFP420 BJT, and would like to measure its gain and input and output impedance. As the gain should be within 25dB, so I connected a 40dB 50 ohm input/output attenuator between CH0 and the input of the amplifier to avoid driving the amplifier into saturation, then connected the output of the amplifier to CH1.

The negative dBs readings of S21 were making sense to me after adding up logically 40dB to come up with the actual amplifier gain. However as the inserted attenuator impedance at CH0 is 50 ohm, the readings of S11 was showing as almost flat 50 ohm across the frequency range which is expected.

To measure amplifier input impedance (S11), I removed the attenuator and connected amplifier input directly to CH0 and connected amplifier output to a 50 ohm load. As the amplifier is driven into saturation, I am not sure if the S11 readings are correct, and I can rely on for small signal.

I repeated the same but swapping the amplifier input and output to measure the output impedance (S22).

Is this the right way to measure input and output impedance for such amplifier.in the absence of power control on the nanoVNA? Is there a better way?

Hi,

Thanks to all who appreciated the software. Consider it as my contribution to the
group.

Kind regards,

neb

bug reports for this gcc bug are already exists.

I just fixed NanoVNA code to avoid it.

On Thu, Nov 28, 2019 at 06:28 AM, Rune Broberg wrote:

Python 2.7 is end-of-life in little over a month. Developing new software
using that cannot reasonably be encouraged.

Hi Rune,

please don't think that I am referring to your own excellent software.
I know it works when all the bits are in the right place ;)

What I refer to is the general disease of of always needing to mess about finding new dependencies, updating to a new version
of something or other or trashing and rebuilding hard disks for another OS and it wastes a lot of peoples time.

And all for what ?

The excuse of security updates is wearing thin, rarely do the end users see any tangible benefits and not everything is plugged into to the internet.

Every Android phone that's a day old seems to require a hundred updates.
Every day old Windows PC seems to need a a day connecting to Microsoft for updates.
You would have thought that with all these years gone by, things would be sorted out by now.
Linux is just as bad, nearly every day my update manager is offering more "security" updates.

Windows...another version of MS Silveright, another version of .NET crap just to continue to run another updated app.
All this update crap is everywhere and we end users want to get on with our lives.

That's why I think that some form of line needs to be drawn *generally* when releasing *anything*.
Maybe Python 3.5, that seems to be default in Linux or Raspberry Pi's only 12 months ago.

And look at Linux Mint.

LM 18.3 is still LTS.
Why would I want to upgrade to 19.x for no benefit.
THere's issues with WINE being installed.
And the last time I looked at a newer WINE it appeared to have dropped support for the od Win 3.1 stuff, which is the only reason why most of us need it anyway.
That is according to the WINECFG that I tried to set up, and it no longer allowed me to set up anything old than about WinXP from memory.

All this pushing the blame back to users to upgrade / update is not good enough.
It's devs being too lazy to think about making their apps works for the majority.

Well I'm not playing the game any more these days, I have a life to get on with.

A PC should be working for *me*, I am not it's damn slave anymore ;-)

73 de Andy

On 11/28/19 12:10 AM, QRP RX wrote:

just installed gcc and tested it. The root of cause is GCC compiler bug.
It produces garbage code. I will implement workaround for this GCC compiler bug.

???? And file a bug report?

Isnt it amazing how i cant get an answer to a simple question!,if i wanted to use a tab i would have asked that!!,pointless as my tab doesent support the app,just wanted to know what screen to get out of the 2 i linked too!.

just installed gcc and tested it. The root of cause is GCC compiler bug.
It produces garbage code. I will implement workaround for this GCC compiler bug.

Hi Andy,
Python 2.7 is end-of-life in little over a month. Developing new software
using that cannot reasonably be encouraged.

If anyone wants to port NanoVNA-Saver to other platforms or languages, it
is fully open source, so they can do so. :-)

--
Rune / 5Q5R

On Thu, 28 Nov 2019, 06:48 Andy via Groups.Io, <punkbiscuit=
[email protected]> wrote:

If something was written in a common base version, such as 2.7 for Python,
which is probably pre-packaged in 90% of Linux OS's then
I bet life would be much easier.

- Andy -

file board.c, line 65

I don't have gcc at the moment, so I cannot implement patch for your compiler.

You can try the following change:

volatile uint32_t dfu_reset_to_bootloader_magic __attribute__ ((section (".noinit")));

let me know if it works, I will add this patch for gcc.