Hello Community,

I got a new nanovna V2 plus 4 and would like to use it as a affordable educational tool for working with vna systems. The big brothers are unfortunately a bit too expensive.
Furthermore I'm also happy about my new nanovna because it is a huge benefit for my radio shack and ham radio activities.

Now I would like to work with LV as command and control sw. I found some Topics about joe smith but I saw that he would prefer to share the runtime of his custom sw only. This is generous but do not help to improve my knowledge.

Are there any other customers of nanorfe who try to do  the same?. Actually I still have some problems to find a stable communication to the nanovna, therefore I still look for an example .vi who show how I can establish as stable communication port to the nanovna. The usual visa calls of open comport -> clearBuffer -> Write -> Read... do not work like
I expected.

Thanks in advance
TomS

On 5/9/21 9:35 AM, TomS wrote:
> Hello Community,
>
> I got a new nanovna V2 plus 4 and would like to use it as a affordable
> educational tool for working with vna systems. The big brothers are
> unfortunately a bit too expensive.
> Furthermore I'm also happy about my new nanovna because it is a huge
> benefit for my radio shack and ham radio activities.
>
> Now I would like to work with LV as command and control sw. I found
> some Topics about joe smith but I saw that he would prefer to share
> the runtime of his custom sw only. This is generous but do not help to
> improve my knowledge.
>
> Are there any other customers of nanorfe who try to do  the same?.
> Actually I still have some problems to find a stable communication to
> the nanovna, therefore I still look for an example .vi who show how I
> can establish as stable communication port to the nanovna. The usual
> visa calls of open comport -> clearBuffer -> Write -> Read... do not
> work like
> I expected.


As far as I can tell, the NanoVNAs all look like an ordinary USB comm
port.  At least I use the pyserial library (as does NanoVNA-saver)
without any problems, and likewise, a terminal emulator.
So that might be somewhere to start - see if there's something about how
the comm port is configured in LabView that is being wonky (parity,
wordlength, line terminator). Try talking to the NanoVNA using a
terminal emulator.

If you really want to improve your knowledge, roll up your sleeves.  That's about the only way to gain any experience.  I've ran into a problems with the serial ports, I believe with LabView 10.  Outside of that, I have not had any problems using them.   You may want to consider joining the NI forums.

Hello,
Yes, the cypress driver sw creates a new com port in win10 and the nanovna qt sw works well too.
But there is an unexpected behaviour.
Connecting a terminal like the old hyperterm, with 9600/8/n/1 i get no answer from the device, like i saw on some yt videos.
I only get a „2“ . According to the nanorfe manual is there a hex command 0x0D (\r  = CR) which give the default answer „2“ from the INDICATE command.
Same happens if i try to communicate with putty.
For the first step I would like to know how I can connect e.g. putty right in order to communicate teminal based like L.Rothman described in his pdf.

Trying to connect the nanovna with lv, it is a bit different.  I can open the com port with the visa serial open vi without errors. But sending the 0x0D command, the write vi show an error  on the output cluster. Ignoring the error i can read the INDICATE answer. Same happens if I try ro read e.g the number of frequency steps with the READ2 command. I get the right value, but the error message from the read command remains.
For the second step I still look for a working lv code snippet.
All helpful contributions are welcome,
Thanks in advance
TomS

Hello,
Yes, the cypress driver sw creates a new com port in win10 and the nanovna qt sw works well too.
But there is an unexpected behaviour.
Connecting a terminal like the old hyperterm, with 9600/8/n/1 i get no answer from the device, like i saw on some yt videos.
I only get a „2“ . According to the nanorfe manual is there a hex command 0x0D (\r  = CR) which give the default answer „2“ from the INDICATE command.
Same happens if i try to communicate with putty.
For the first step I would like to know how I can connect e.g. putty right in order to communicate teminal based like L.Rothman described in his pdf.

Trying to connect the nanovna with lv, it is a bit different.  I can open the com port with the visa serial open vi without errors. But sending the 0x0D command, the write vi show an error  on the output cluster. Ignoring the error i can read the INDICATE answer. Same happens if I try ro read e.g the number of frequency steps with the READ2 command. I get the right value, but the error message from the read command remains.
For the second step I still look for a working lv code snippet.
All helpful contributions are welcome,
Thanks in advance
TomS

Hi Tom,
I am also interested in using LabVIEW to communicate with the NanoVNA, I'll have some time during this weekend to look into it. Btw, what version of LabVIEW are you using?
Regards,
Fedor

On Thu, May 13, 2021 at 09:36 AM, TomS wrote:

>
> Hello,
> Yes, the cypress driver sw creates a new com port in win10 and the nanovna
> qt sw works well too.
> But there is an unexpected behaviour.
> Connecting a terminal like the old hyperterm, with 9600/8/n/1 i get no
> answer from the device, like i saw on some yt videos.
> I only get a „2“ . According to the nanorfe manual is there a hex command
> 0x0D (\r  = CR) which give the default answer „2“ from the INDICATE
> command.
> Same happens if i try to communicate with putty.
> For the first step I would like to know how I can connect e.g. putty right
> in order to communicate teminal based like L.Rothman described in his pdf.
>
>
> Trying to connect the nanovna with lv, it is a bit different.  I can open
> the com port with the visa serial open vi without errors. But sending the
> 0x0D command, the write vi show an error  on the output cluster. Ignoring
> the error i can read the INDICATE answer. Same happens if I try ro read
> e.g the number of frequency steps with the READ2 command. I get the right
> value, but the error message from the read command remains.
> For the second step I still look for a working lv code snippet.
> All helpful contributions are welcome,
> Thanks in advance
> TomS

Hi Tom,
I am also interested in using LabVIEW to communicate with the NanoVNA, I'll have some time during this weekend to look into it. Btw, what version of LabVIEW are you using?

Regards,
Fedor

Hello Fedor,
sounds good. What is your experience, can you communicate with the nanovna v2 p4 without errors?
I do have access to a laptop from my office where we use LV15. This mean I cannot read vi later than LV15.
TomS

Hello Jim Lux,
you are right. That's the way I tried with putty, but I'm quite sure I use the wrong settings, because I do not get a promt, just a cursor. And the only answer I get is the response to the 0x0D character which is the INDICATE command ( = 2) at the same time. Have you used putty for testing the communication?

If the terminal works on the original version, like I use today, there is a big question for me. How are the terminal commands separated form the hex commands described by nanorfe.? Or do the nanovna accept all commands at the same time? I don't think so, but I'm not sure.

I assume there are two different ways of communication, based on the com port. The terminal mode (how I can enter it with putty ???) and the hex command mode which i try to realize with LV?

best regards
TomS
I

On 5/13/21 6:25 AM, TomS wrote:
> Hello Jim Lux,
> you are right. That's the way I tried with putty, but I'm quite sure I
> use the wrong settings, because I do not get a promt, just a cursor.
> And the only answer I get is the response to the 0x0D character which
> is the INDICATE command ( = 2) at the same time. Have you used putty
> for testing the communication?
>
> If the terminal works on the original version, like I use today, there
> is a big question for me. How are the terminal commands separated form
> the hex commands described by nanorfe.? Or do the nanovna accept all
> commands at the same time? I don't think so, but I'm not sure.
>
> I assume there are two different ways of communication, based on the
> com port. The terminal mode (how I can enter it with putty ???) and
> the hex command mode which i try to realize with LV?
>
> best regards
> TomS
> I



I would look in the NanoVNASaver/Hardware subdirectory of the
NanoVNA-Saver install - there's python code there for all the flavors,
and NanoVNA_V2.py might give you some clues about what you need to send.

NanoVNA.py seems to use text commands:
    def resetSweep(self, start: int, stop: int):
        list(self.exec_command(f"sweep {start} {stop} {self.datapoints}"))
        list(self.exec_command("resume"))

NanoVNA_V2.py uses byte commands:

    def setSweep(self, start, stop):
        step = (stop - start) / (self.datapoints - 1)
        if start == self.sweepStartHz and step == self.sweepStepHz:
            return
        self.sweepStartHz = start
        self.sweepStepHz = step
        logger.info('NanoVNAV2: set sweep start %d step %d',
                    self.sweepStartHz, self.sweepStepHz)
        self._updateSweep()
        return

    def _updateSweep(self):
        cmd = pack("<BBQ", _CMD_WRITE8,
                   _ADDR_SWEEP_START, int(self.sweepStartHz))
        cmd += pack("<BBQ", _CMD_WRITE8,
                    _ADDR_SWEEP_STEP, int(self.sweepStepHz))
        cmd += pack("<BBH", _CMD_WRITE2,
                    _ADDR_SWEEP_POINTS, self.datapoints)
        cmd += pack("<BBH", _CMD_WRITE2,
                    _ADDR_SWEEP_VALS_PER_FREQ, 1)
        with self.serial.lock:
            self.serial.write(cmd)
            sleep(WRITE_SLEEP)

On Thu, May 13, 2021 at 03:47 PM, Jim Lux wrote:

>
> def _updateSweep(self):
> cmd = pack("<BBQ", _CMD_WRITE8,
> _ADDR_SWEEP_START, int(self.sweepStartHz))
> cmd += pack("<BBQ", _CMD_WRITE8,
> _ADDR_SWEEP_STEP, int(self.sweepStepHz))
> cmd += pack("<BBH", _CMD_WRITE2,
> _ADDR_SWEEP_POINTS, self.datapoints)
> cmd += pack("<BBH", _CMD_WRITE2,
> _ADDR_SWEEP_VALS_PER_FREQ, 1)
> with self.serial.lock:
> self.serial.write(cmd)
> sleep(WRITE_SLEEP)

Hello Jim,
I'm not a python user therefore I try to understand the code.
It looks like that the code snippet creates a string with several commands in one transmit string.
eg of the first two commands:  "<BBQ 0x23 0x00 0xabcdef <BBQ 0x23 0x10 0xghijkl"

Quite clear that the spaces in my string are not part of the python cmd string. It is just for better reading. The 0xabcdef represent the uint64 value for start frequency in Hz
and the 0xghijkl represent the uint64 value for frequency step in Hz. and so on.
It seems to me that there obviously different BBQ and a BBH  strings for cmd_write8 and cmd_write_2 commands. I assume there must be two other for maybe cmd_write1 and cmd_write4 because this is possible according to the nanorfe manual.

Do I understand it right?

Thanks in advance
TomS

On 5/13/21 10:48 AM, TomS wrote:
> On Thu, May 13, 2021 at 03:47 PM, Jim Lux wrote:
>
> def _updateSweep(self):
>         cmd = pack("<BBQ", _CMD_WRITE8,
>                    _ADDR_SWEEP_START, int(self.sweepStartHz))
>         cmd += pack("<BBQ", _CMD_WRITE8,
>                     _ADDR_SWEEP_STEP, int(self.sweepStepHz))
>         cmd += pack("<BBH", _CMD_WRITE2,
>                     _ADDR_SWEEP_POINTS, self.datapoints)
>         cmd += pack("<BBH", _CMD_WRITE2,
>                     _ADDR_SWEEP_VALS_PER_FREQ, 1)
>         with self.serial.lock:
>             self.serial.write(cmd)
>             sleep(WRITE_SLEEP)
>
> Hello Jim,
> I'm not a python user therefore I try to understand the code.
> It looks like that the code snippet creates a string with several
> commands in one transmit string.
> eg of the first two commands:  "<BBQ 0x23 0x00 0xabcdef <BBQ 0x23 0x10
> 0xghijkl"
>
> Quite clear that the spaces in my string are not part of the python
> cmd string. It is just for better reading. The 0xabcdef represent the
> uint64 value for start frequency in Hz
> and the 0xghijkl represent the uint64 value for frequency step in Hz.
> and so on.
> It seems to me that there obviously different BBQ and a BBH strings
> for cmd_write8 and cmd_write_2 commands. I assume there must be two
> other for maybe cmd_write1 and cmd_write4 because this is possible
> according to the nanorfe manual.
>
> Do I understand it right?


"<BBQ" is how python puts values into a byte array the < indicates it's
little endian, then two bytes and a quad (unsigned long long, 8 bytes
long).  H is a unsigned 16 bit number.
Here's an example
>>> cmd = struct.pack("<BBQ",0x01,0x02,0xabcdef)
>>> cmd
b'\x01\x02\xef\xcd\xab\x00\x00\x00\x00\x00'


So that code is putting out a concatenated string of 10 bytes + 10 bytes
+ 4 bytes + 4 bytes.

_CMD_WRITE8 and _CMD_WRITE2 refer to the number of argument bytes in the
command.  So it looks like the command format is "length","address
byte", "argument".
It might be something where the protocol just pushes values into
specific places in memory.
You'd have to look at the source code to get the actual values for the
constants.

On Thu, May 13, 2021 at 10:42 PM, Jim Lux wrote:

>
> So that code is putting out a concatenated string of 10 bytes + 10 bytes +
> 4 bytes + 4 bytes.
>
> _CMD_WRITE8 and _CMD_WRITE2 refer to the number of argument bytes in the
> command.  So it looks like the command format is "length","address byte",
> "argument".
> It might be something where the protocol just pushes values into specific
> places in memory.
> You'd have to look at the source code to get the actual values for the
> constants.

Hello Jim,
sorry for the delay, I was abroad on a business trip (under corona conditions :-( ...).
Ok, I see I don't have knowledge about python language, therefore thanks for your last answer.
Removing the wrong data segments I can see that the command string follows the online manual of rfe about the usb command structure.

This mean I should have to put my focus on the LV issues with the cypress usb driver, because the lv visa vi's for the serial out function show me always an
error, but it seems that they transmit the data string to the nanovna. Maybe Joe Smith is willing to show how he solved this problem in his program.

I assume I will have access to our laptop within the next two weeks. Than I can work on the communication again.

Thanks to all supporting my efforts.
TomS

Hello again.
Does anybody know what the parameter

.21

sweepPoints

Sets the number of sweep frequency points. *uint16*.

22..23

valuesPerFrequency

Sets the number of data points to output for each frequency.

*uint16*.

26

rawSamplesMode

Writing 1 switches USB data format to raw samples mode and leaves this protocol.

Values per frequency mean?
Is is equivalent to the average function?
I still think about the data transfer rate for the signal data points. According to the rfe manual have the v2 plus 4 a sample speed of 400s/sec.
This mean that each sample need 26 bytes today. With 400s/sec I must transfer 10400 byte/sec. Actually i only can connect the nanovna with 9600 byte. This is too slow for a continious data stream. If valuesPerFrequency mean averaging than a value of 2 shall solve the problem. Do anybody have some experience with the data transfere?

Regards TomS