-
-
Notifications
You must be signed in to change notification settings - Fork 340
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(simu): cross-platform connection of host serial ports to simu radio #5584
base: main
Are you sure you want to change the base?
feat(simu): cross-platform connection of host serial ports to simu radio #5584
Conversation
8553373
to
9a00027
Compare
9a00027
to
1b6a405
Compare
Would this allow to connect an external module (e.g. ELRS RX-as-TX bidirectional connected) to the simulator? |
The task was explicitly not to require to communicate within the simulator with physical internal or external RF modules, as the serial communication with them has too tight timing constraints, which typical computer OS, w/o real-time capabilities, would not be able to adhere to: https://edgetx.org/contest_companion_phy_ser/ |
If ELRS RX-as-TX currently works on AUX1 or AUX2, then maybe, with absolutely no guarantees of reliability given the impossibility of guaranteeing timing on a general purpose OS. If you're going to try it for god's sake make sure you've got your props off. |
I tried this PR unter Linux: selecting a serial device like |
I tried both the prebuilt AppImage as well as a self-compiled version: in both variants I can't successfully choose a serial device. |
Did you see if data flowed between the simulator and the serial port, or did you just check to see if the dropdown had the correct value selected when you opened the serial device dialog again? I've just fixed the issue where the dialog wouldn't select the currently-connected port when it opens :) |
Just tried with yout latest update (both pre-built app-image as well as self-build)
|
And I want to say that it would be a real cool feature if |
It's not expected to persist across restarts of the simulator.
Interesting, it's working for me (on linux and windows) with a GPS plugged in to the host. a) How are you configuring the simulated radio? |
It might be cool, but it won't happen in this PR. (I've had a poke through and it looks like you'd need to wait for #4102 to go in) |
Ok, no problem ;-)
Maybe we are talking of different things. |
I've just had a poke around, and it doesn't.
If you set |
Mmh, that's a pity! |
I suspect that the point of |
@wimalopaan See: #2562 |
The baudrate should be user settable I think, and not fixed 9600Bd |
The baudrate on the host will be set to whatever the radio has set it to. opentxsimulator.cpp:167 -> opentxsimulator.cpp:144 -> opentxsimulator.cpp:678 -> simulatormainwindow.cpp:160 -> hostserialconnector.cpp:136 |
Here the files and sections from previous post with links for easier reading: |
Yes, I was aware of that fact but did not find the link to your new code ... |
Many thanks ;-) |
I still wonder about the best way to achieve the goal to attach an ELRS-module to the simu ... |
Something like the approach in this PR but instead of connecting the simulated AUX1/AUX2 to a host serial port, you'd be connecting the simulated internal or external module to the host hardware in some way? OR you could extend the module handling code to support having a third (or fourth) serial-connected (no module heartbeat for sync, for example) module on AUX1/AUX2 and use this PR to connect it to the host. |
Actually I hestitate to use a serial device. I think of a pipe/socket or shared-memory to communicate with a kind of module-simulator ... |
Whoops, this is what happens when I test with re: the LUA loopback test: turns out that QByteArray::fromRawData doesn't copy the data it's given but points directly to it. And with the timing for the the GPS driver it just happened to be that the data got sent before the buffer got overwritten. But when sending data from LUA, the buffer got overwritten for each character while the queue of QT signals grew. Also fixed in latest push, at least that's what it looks like on my machine :) |
Looking good so far... both fixes working fine here on Linux :) edit: and Windows |
Now just need to find someone with a mac 😆 |
Welp... github blocked my email reply... Got someone in mind already, just need to send him a reminder to test this as we were discussing this just before EdgeTX fest so would have been forgotten in the chaos of getting ready for that. |
Summary of changes:
It's a bit convoluted because QSerialPort has to belong to the main event loop's thread, not the simulator's thread. We rely on QT's signal management to let us shunt data between the threads nicely.