* some Debian-flavored Linux testing

* scanraw serial FROM DEVICE issues with the buffer. This is being explored see Example #3 in [Plotting Data with Matplotlib](#plotting-data-with-matplotlib) for details.

pyQt5

pip install pyserial numpy pandas matplotlib pillow pyQt5

`pyQt5` is used with `matplotlib` to draw the figures. It needs to be installed in Linux systems to follow the examples included in tinySA_python, but is not needed on all Windows machines.

This library was developed on Windows and has been lightly tested on Linux. The main difference (so far) has been in the permissions for first access of the serial port, but there may be smaller bugs in format that have not been detected yet.

tsa.set_verbose(True) #detailed messages

tsa.set_error_byte_return(True) #get explicit b'ERROR' if error thrown

if connected_bool == True:

import serial.tools.list_ports

ports = serial.tools.list_ports.comports()

for port, desc, hwid in ports:

print(f"Port: {port}, Description: {desc}, Hardware ID: {hwid}")

Port: /dev/ttyS0, Description: n/a, Hardware ID: n/a

Port: /dev/ttyS3, Description: n/a, Hardware ID: n/a

Port: /dev/ttyS2, Description: n/a, Hardware ID: n/a

Port: /dev/ttyS1, Description: n/a, Hardware ID: n/a

Port: /dev/ttyACM0, Description: tinySA4, Hardware ID: USB VID:PID=0483:5740 SER=400 LOCATION=3-3:1.0

This method identified the `/dev/ttyACM0`. Now, when attempting to use the autoconnect feature, the following error was initially returned:

[Errno 13] could not open port /dev/ttyACM0: [Errno 13] Permission denied: '/dev/ttyACM0'

This was due to not having permission to access the port. In this case, this error was solved by opening a terminal and executing `sudo chmod a+rw /dev/ttyACM0`. Should this issue be persistent, other solutions related to user groups and access will need to be investigated.

tsa.set_verbose(True) #detailed messages

tsa.set_error_byte_return(True) #get explicit b'ERROR' if error thrown

tsa.set_verbose(True) #detailed messages

tsa.set_error_byte_return(True) #get explicit b'ERROR' if error thrown

tsa.set_verbose(True) #detailed messages

tsa.set_error_byte_return(True) #get explicit b'ERROR' if error thrown

tsa.set_verbose(True) #detailed messages

tsa.set_error_byte_return(True) #get explicit b'ERROR' if error thrown

tsa.set_verbose(True) #detailed messages

tsa.set_error_byte_return(True) #get explicit b'ERROR' if error thrown

NOTE FOR LINUX USERS: the serial read with SCANRAW is finicky. It's also ONLY with this function on Linux. Reading the serial buffer after SCANRAW failed in several situations:

1. Requesting data too quickly after the last read

* Expected, as the tinySA needs to resume and re-measure.

2. Requesting data when the screen is frozen

* Mildly expected, user error can trigger this too. Turns out in some situations, the frozen screen is not the same as a `pause`, and there is no data to flush from the buffer because no more data has been taken. This is either a safe error state, a feature of how SCANRAW works, or potentially a bug with the device/firmware/this library. Using the `resume()` function after this will restart measurements.

3. {UNKNOWN}. There are several conditions that can cause issues, but it's unclear what 'symptoms' go to which problems

* On the first few reads after the tinySA has been turned on and operational for at least 1 minute.

* After sitting unused for more than a few minutes the returned buffer is < 50% the expected size or more than 5x the expected size. This is AFTER the flush command.

# NOTE: if repeated read errors with utf-8 occur, uncomment the below as an alternative to the

# line above. This will show you what value is being returned that caused the problem. It may

# indicate a different problem with the serial connection permissions

# data_arr = []

# for i, line in enumerate(data1.decode('utf-8').split('\n')):

# print(f"Line {i}: '{line}'") # Show the raw line

# line = line.strip()

# if line:

# try:

# value = float(line.split()[0])

# data_arr.append(value)

# # print(f" Parsed float: {value}")

# except ValueError as e:

# print(f" Could not convert line to float: {line} — Error: {e}")

tsa.set_verbose(True) #detailed messages

tsa.set_error_byte_return(True) #get explicit b'ERROR' if error thrown

# for subsequent reads, the tinySA does freeze while preforming SCANRAW

# if there's an error, the screen will stay frozen (for reading).

# So start it again so new data can be taken

tsa.resume()

expected_len = 3 * pts

actual_len = len(bin_scanraw)

print(f"Expected length: {expected_len}, Actual length: {actual_len}")

if actual_len == expected_len:

# SCANRAW has returned the expected amount of data for the read.

# sometimes this function (and not SCAN) does not read the buffer properly

# a fix is in progress for LINUX systems. it works fine for Windows

processed_scanraw = struct.unpack( '<' + 'xH'*pts, bin_scanraw ) # ignore trailing '}ch> '

processed_scanraw = np.array(processed_scanraw, dtype=np.uint16 ).reshape(-1, 1) #unit8 has overflow error

# CONVERT to dBm Power

# take the processed binary data and convert it to dBm.

# The equation is from tinySA.org & official documentation

SCALE_FACTOR = 174 # tinySA Basic: 128, tinySA Ultra and newer is 174

dBm_data = processed_scanraw / 32 - SCALE_FACTOR

print(dBm_data)

# plot

plt.plot(freq_arr, data_arr, label= 'SCAN data')

plt.plot(freq_arr, dBm_data, label= 'SCANRAW data')

plt.xlabel("frequency (hz)")

plt.ylabel("measured data (dBm)")

plt.title("tinySA SCAN and SCANRAW data")

plt.legend()

plt.show()

else:

print("SCANRAW did not return the expected amount of data for the read")

tsa.set_verbose(True) #detailed messages

tsa.set_error_byte_return(True) #get explicit b'ERROR' if error thrown

* **Direct Library Function Call:** `scan_raw(start=Int|Float, stop=Int|Float, pts=Int|Float, unbuf=1)`