开云体育

Oristo,

I assume you are aware of the python console commands as made by edy555

Oristo wrote:

Update corrects colors (endian was wrong):

---------------------------------------------------------------------

On my computer the updated script seems to save the screenshot faster, and the image file seems to load faster.

Tks for sharing.

- Herb

Oops, another update shifts right 9 bytes into received display buffer,
eliminating artifacts on left from menu boxes on the right

Hi Erik -

I assume you are aware of the python console commands as made by edy555

Yes, I cited that in /g/nanovna-users/message/5757

screenV.py steals extensively from it,
which I did not run, but suspect that, if you do, then
that Python will fail to capture with at least some recent firmwares.

On Sat, Oct 26, 2019 at 10:48 AM, Oristo wrote:

Oops, another update shifts right 9 bytes into received display buffer,
eliminating artifacts on left from menu boxes on the right

---------------------------------------------------------------------------------------

That update caused my capture to revert back to wrong colors. Also, with this update and the last, script hangs when trying to capture a screen with an on screen keyboard. I believe it is a known problem with the capture command, although QRP seems to have figured it out in his latest NanoVNA-Sharp MOD.

-Herb

Hi Herb -

That update caused my capture to revert back to wrong colors.

Sigh. The problems:
* how many first bytes to discard? Presumably, shell returns the usual echo'ed command..

The newest update defines a "prune" variable to tune that.

Also, with this update and the last,
script hangs when trying to capture a screen with an on screen keyboard.

This is being tested with QRP's NanoVNA-Q-usb-test.dfu
/g/nanovna-users/message/5678

Also, with this update and the last,
script hangs when trying to capture a screen with an on screen keyboard.

This is being tested with QRP's NanoVNA-Q-usb-test.dfu
/g/nanovna-users/message/5678

$ python screenV.py keyboard

Hi Herb -

On my computer the updated script seems to save the screenshot faster,
and the image file seems to load faster.

The earlier version copied edy555 Python: x = struct.unpack(">76800H", b)
.. where the ">" means big-endian, which is unnatural for Intel processors
and arguably incorrect, so far as pairing RGB565 bytes from nanoVNA.
Of course, 16-bit endian interacts with byte offset into buffer from serial.read(),
but little-endian should be faster on x86 processors.

On Sat, Oct 26, 2019 at 10:08 PM, Oristo wrote:

Of course, 16-bit endian interacts with byte offset into buffer from serial.read(),
but little-endian should be faster on x86 processors.

There is no offset and no need to skip bytes. It returns 320x240 pixels, 2 bytes per pixel.

For some unknown reason pixel bytes are reversed on firmware side, So, you're needs to reverse hi and lo bytes before processing RGB565 color

Hi QRP -

Of course, 16-bit endian interacts with byte offset into buffer from
serial.read(),
but little-endian should be faster on x86 processors.

There is no offset and no need to skip bytes.
It returns 320x240 pixels, 2 bytes per pixel.

New version adds commented-out debugging to log:
* the number of bytes from first serial.read()
* the first prune bytes
* location of the first newline:
$ python screenV.py keyboard
12330
b'capture\r\n'
8

The bytes being pruned are that echo'ed 'capture' command.
With 8 = 0-based index of "\n" , need to prune the leading 9 bytes...

For some unknown reason pixel bytes are reversed on firmware side,
So, you're needs to reverse hi and lo bytes before processing RGB565 color

Pruning the first 9 bytes and unpacking little-endian works...

This version also adds 'sleep(0.1)' before 'serial.read()'s
to reduce Python looping.

On Sat, Oct 26, 2019 at 09:37 AM, Oristo wrote:

first "working" script gets screen colors wrong:

Update corrects colors (endian was wrong):

---------------------------------------------------------------------------------------------------------------------

Oristo,
Do you still have a copy of the above screen-saver script? It was the only one that worked correctly for me using version 0.2.3 firmware (sans keyboard and version screen display). I'll eventually upgrade to QRP's latest software but I'm waiting for my second NanoVNA to arrive before I do so. All the subsequent screen.py scripts freeze the display on my NanoVNA and the shell command-line prompt never returns until I re-start the shell.

The line, " x = struct.unpack(">76800H", b)", seems to be where things fall apart. I admit I don't have any idea what the format ">76800H" is doing.

Tks,

- Herb

-Herb

Hi Herb -

Do you still have a copy of the above screen-saver script?

'git' does (attached):
ormpoa@newgate MSYS /g/Gateway/GitHub/oristo
$ cd nVhelp/html
$ git log | less
$ git status
On branch endian
$ git checkout 8d512e0f screenV.py

The line, " x = struct.unpack(">76800H", b)", seems to be where things fall apart.

You may fix that line by
x = struct.unpack("<76800H", b[:153600])

As I read:
struct.unpack() method restructures data from byte buffer 'b' into 'x'
according to format e.g. ">76800H"
.. which in this case is a count of 76800 half-words (uint16) in
big-endian ">",
meaning that left-most byte of each pair should be considered more significant.
So far as I know, ARM processors may be configured either little- or big-endian,
while x86 processors run little-endian.

The struct.unpack() method insists that buffer byte count exactly satisfy format

Essential differences between the attached and current versions:
The attached:
* discarded echo'ed "capture\r\n" by 'ser.readline()'
* then looped 'ser.read()' until 'b' accumulated at least (153600 ==
320 * 240 *2) bytes,
* then pruned 'b' to the first 153600 bytes
* then shifted RGB565 incorrectly into ARGB8888

The current (4083c059) version uses only 'ser.read()', not 'ser.readline()'
* but for 9 more bytes, to account for echo'ed "capture\r\n"
* 'sleep(0.1)' before 'ser.read()' reduces looping and frees CPU cycles
* prunes buffer 'b' directly into 'struct.unpack()' rather than back into 'b'

On Sun, Oct 27, 2019 at 02:21 AM, Oristo wrote:

x = struct.unpack("<76800H", b[:153600])

--------------------------------------------------------------------------------------------------------------------------------------

Oristo,
Tks for taking the time to reply. Some observations:

1. With my ver 0.2.3 firmware, x = struct.unpack("<76800H", b[:153600]) does allow your current script to run to completion. The colors are off as in your first version of the script.

2. Your attached script runs fine with my ver 0.2.3 firmware and the coding seems to be "cleaner" as far as readability goes.

3. The master branches for all the nanovna.py scripts use the following function for the capture command:

def capture(self):
from PIL import Image
self.send_command("capture\r")
b = self.serial.read(320 * 240 * 2)
x = struct.unpack(">76800H", b)
# convert pixel format from 565(RGB) to 8888(RGBA)
arr = np.array(x, dtype=np.uint32)
arr = 0xFF000000 + ((arr & 0xF800) >> 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 19)
return Image.frombuffer('RGBA', (320, 240), arr, 'raw', 'RGBA', 0, 1)

The function doesn't seem to work and I'm sure you wouldn't have re-invented the wheel if it did. So what's going on with it not working or am I missing something?

Regards,

-Herb

On Sun, Oct 27, 2019 at 06:16 AM, hwalker wrote:

It was the only one that worked correctly for me using version 0.2.3 firmware
(sans keyboard and version screen display).

you can use NanoVNAsharp MOD V3 in order to get NanoVNA screenshot, it works ok with any firmware which supports capture command:

Hi Herb -

The colors are off as in your first version of the script.

.. so also change:
arr = 0xFF000000 + ((arr & 0xF800) << 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 3)

The [ nanovna.py capture(self) ] function doesn't seem to work
and I'm sure you wouldn't have re-invented the wheel if it did.
So what's going on with it not working or am I missing something?

I have the advantages of 1) being cynical and 2) simpler Python

b = self.serial.read(320 * 240 * 2)

This does not necessarily return (320 * 240 * 2) bytes into b,
hence:

# unlikely to grab entire screen buffer in one read()
while (blen > (len(b))):
sleep(0.1)
b += ser.read(blen)

#.. which I relearned from Rune.

# Perhaps it should be:
missing = blen - len(b)
while (0 < missing):
sleep(0.1)
b += ser.read(missing)
missing = blen - len(b)

--=--
Also, 'self.send_command("capture\r")' includes 'ser.readline()',
which may or may not already receive "capture\r\n", depending on timing...

I do not know why my most recent 'screenV.py' works for me and fails for you;
perhaps because different Python conglomeration...
what firmware does your nanoVNA run?

perhaps because different Python conglomeration

$ python --version
Python 3.6.6
$ pip freeze
certifi==2019.9.11
numpy==1.17.3
Pillow==6.2.1
pipenv==2018.11.26
pyserial==3.4
virtualenv==16.7.5
virtualenv-clone==0.5.3

Oristo wrote,

"I do not know why my most recent 'screenV.py' works for me and fails for you;
perhaps because different Python conglomeration..."
--------------------------------------------------------------------------------------

On my NanoVNA with version 0.2.3 firmware, the following changes made your most recent script run to completion with correct screen colors.

1. #x = struct.unpack("<76800H", b[prune:blen])
x = struct.unpack("<76800H", b[:153600])

Prior to your suggested change, the error I received was that a consistent buffer size of 153600 was required. None of my web searches explained how that buffer should be allocated. Hard coding "magic" numbers is not good coding practice, but in this case it works :)

2. #arr = 0xFF000000 + ((arr & 0xF800) << 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 3)
arr = 0xFF000000 + ((arr & 0xF800) >> 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 19)

Your earlier script worked for me with the correct screen colors. It has the line "arr = 0xFF000000 + ((arr & 0xF800) >> 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 19)" and when I made that change in your current script the screen colors are correct.

So both scripts are running to completion on my set-up with the correct screen colors now. I'm not sure why "arr = 0xFF000000 + ((arr & 0xF800) << 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 3)" works for you and not for me.

3. As previously noted, trying to grab a screen with an on screen keyboard or "Version" screen causes either script to hang somewhere in the ser.read function. Does this happen with when you use QRP's latest firmware?

I know QRP is wondering what the point of all this is when his NanoVNA-Sharp MOD works perfectly well at grabbing a screen capture. For me its just the exercise of learning Python and understanding another tool for using the NanoVNA.

- Herb

Hi Herb -

Hard coding "magic" numbers is not good coding practice

"<76800H" must match 153600 == 320 * 240 * 2 == nanoVNA screen size in bytes

Anything which breaks those "magic" numbers will also almost certainly break more in this script.

So both scripts are running to completion on my set-up with the correct screen
colors now. I'm not sure why "arr = 0xFF000000 + ((arr & 0xF800) << 8) + ((arr
& 0x07E0) << 5) + ((arr & 0x001F) << 3)" works for you and not for me.

Bit shifts must be coordinated with BOTH:
* struct.unpack() big/little-endian setting
* even or odd byte count pruned or discarded from response[s] after sending "capture\r"

If those shifts do NOT work for you, then either:
* some even number of bytes are being discarded
(e.g. by ser.readline()) or by prune value in b[prune:blen]
* different endian setting, either in firmware or struct.unpack() or your PC OS
* different number of bytes returned by your firmware
between 'ser.write(cmd.encode())' and screen capture data

3. As previously noted, trying to grab a screen with an on screen keyboard or
"Version" screen causes either script to hang somewhere in the ser.read
function. Does this happen with when you use QRP's latest firmware?

No, it works fine, which is why I appended that PNG
to /g/nanovna-users/message/5790

If QRP's NanoVNA-Sharp MOD works with your firmware while my script does not
then perhaps MOD sends "pause\r" before and "resume\r" after..

If this works for you:

"arr = 0xFF000000 + ((arr & 0xF800) >> 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 19)"

.. then byte pairs for each pixel are out of order (wrong-endian)
or struct.unpack() pairs bytes from two pixels (because wrong even/odd buffer prune),
which should make color fringe artifacts on vertical edges in the PNG

Oristo wrote,
"If QRP's NanoVNA-Sharp MOD works with your firmware while my script does not..."
----------------------------------------------------------------------------------------------------

I realized I had only previously used QRP's NanoVNA-Sharp MOD to capture measurement screens. I just now tried to capture on screen keyboard and "Version" screens. It hangs up in the serial I/O routine in the same way your script does using my version 0.2.3 firmware, so no difference there. When my second NanoVNA arrives, I plan on updating to QRP's 0.4.1 firmware.

- Herb