#3: better code and/or algorithm
If it won't keep up at 1Hz something is seriously wrong, or else you're doing a *lot* more than just plotting.
Matlabplot and equivalent are geared to operate on datasets and make pretty plots.
What is debugging mode? What is "it"?
import matplotlib.pyplot as plt
from matplotlib.animation import FuncAnimation
from random import randrange
from math import sin, pi
fig = plt.figure(figsize=(6, 3))
x = [0]
y = [0]
ln, = plt.plot(x, y, '-')
def update(frame):
x.append(x[-1] + (pi / 50))
y.append(sin(x[-1]))
ln.set_data(x, y)
fig.gca().relim()
fig.gca().autoscale_view()
return ln,
animation = FuncAnimation(fig, update, interval=50)
plt.show()
Python should be more than sufficient. My GUI uses python and can get 35datapoints/second (1500Bps) with usb serial or about 15dp/second (600Bps) with LoRa. I can probably squeeze more, but the least of my problems is the python GUI. The only thing that doesn't seem to keep up is pyqt refreshing widgets, and that's an intermitten issue that I think is because I'm not using pyqt correctly.
Python modules are often written in C/C++, so you don't necessarily gain advantage by using C languages over python nowadays because python is already leveraging those advantages. Any gains will really come at the expense of debugging an executable which can be complicated if you're not good at managing memory. For casual things or hobbies, python is probably the way to go, but certainly not the only way to do it.
The Python global interpreter lock (GIL) makes this (mostly) unnecessary but also means that Python threads aren't unique processes and your performance improvements are heavily dependent upon the application. For something like this project, a thread will often help because the GIL will be released during waits, like when waiting for serial data.
No, unfortunately I don't like sharing my code publicly. Only my friends have access to it... sorry.
tHoagland beat yah to it lol, but thank you. I definitely need to look into this, because I didn't know about the GIL. It seems like multithreading meets my usecase, but I'd be interested to see the performance difference if I implement multiprocessing. My GUI is not cpu bound, so its probably not going to improve anything, but it will be handy as I continue developing it. (EDIT) thinking about it, it might be useful for my voiceover thread. My software can do the altitude and stat announcements (apogee, max speed, etc), but it tends to be slow because of network issues (absolutely no guarantee of a good connection at a launch site, and you can only cache some of the voice over because the stats tend to vary from my simulations by at least a few meters). I couldn't get my GUI working with an offline text-to-speech library because it seemed to close the application after playing one voice message, even with multithreading. I bet you I can implement multiprocessing with that and the GUI will continue running with the offline tts voice overs.
LORA seems plenty fast and I've been designing for small packet sizes. I have had no problem when using the <2KM setup (which empirically still works at 2 miles with a line of site to the rocket).
Do you have a pointer to a basic template/tutorial for the basic windowed setup you are using? I'd like to give something like that a try.
You can look up tutorials for pyqt5. Most of of my widgets are from common libraries like pglive and the built in “qwidgets”. However, there are two custom widgets: the magnometer and altimeter tape. The magnometer needs calibration for that (normalizing the max/min guass to 1 and -1 for each axis), otherwise it’s difficult to understand the meaning of the data. The widget just always views it from the “north” vector, so your perspective would resemble what you would see if you were right next to it. The altimeter tape isn’t really following how they normally do it, but the premise is to show vertical movement. How I did it shows motion from a static position like the magnometer widget I made. For those, I used opengl to render the displays. The “lights” are just text labels and I change the BG color to show a change in status, and you can easily reproduce those.
The trick is that pyqt doesn't really handle any of the plotting, it's just displaying a qt canvas which matplotlib is driving. Things get sketchier when you add significant qt-driven plot interactions. It's a shame PythonQwt isn't (wasn't) well maintained, it was a very nice, well performing plotting package.
