feat(cpn): support more than just FrSky S.Port telemetry simulation

[nrw505]

Fixes #4983
Fixes #2156

Summary of changes:

1. Replace the current telemetry sensor UI dropdowns to choose a telemetry source for both the internal and external module.
2. Refactor the current FrSky S.port telemetry implementation to allow it to have separate telemetry for both internal and external modules at the same time
3. Update the simulator interface to accept different telemetry protocols
4. Implement a CRSF telemetry source and associated UI
5. Rejigger the way the log replay controller works so that it can work with multiple kinds of telemetry

Example: Screencast from 10-08-24 01:17:55.webm

[elecpower]

Post merge of #5381 sim telemetry will need to be modified to suit surface radios eg flight vs drive and hide flight sensors eg vario

[elecpower]

UI comments:

• change buttons font size to default (just look out of place in Linux)
• QComboBox protocol selector would look better IMO if moved closer to label

[nrw505]

• change buttons font size to default (just look out of place in Linux)

They already are the default font size, the .ui file does not specify a font size for the buttons e.g.

    <widget class="QPushButton" name="button_saveTelemetryValues">
     <property name="text">
      <string>Save Telemetry Values</string>
     </property>
    </widget>

This is the same font size that the buttons are in the current frsky-only telemetry screen (and the fields and labels are 8pt as they are on the current frsky-only telemetry screen).

I'm happy to change them to 8 point so they match the rest of the fields on that widget it that's what you want. Please confirm.

• QComboBox protocol selector would look better IMO if moved closer to label

Just right-align the labels so they're next to the QComboBox OK?

[elecpower]

This is the same font size that the buttons are in the current frsky-only telemetry screen (and the fields and labels are 8pt as they are on the current frsky-only telemetry screen).
I'm happy to change them to 8 point so they match the rest of the fields on that widget it that's what you want. Please confirm.

Make buttons consistent with rest of dialog.

Just right-align the labels so they're next to the QComboBox OK?

Right align would suffice.

IMO the main dialog could do with some grids to aid in layout but that is for another day.

[LupusTheCanine]

whould it be possible to use serial port as telemetry source and possibly output port for protocols like CRSF?

[nrw505]

whould it be possible to use serial port as telemetry source and possibly output port for protocols like CRSF?

If you wanted to do that I think you'd probably be better off changing radio/src/targets/simu to use a real serial port as an internal (or external) module - then you'd have real telemetry and the simulation telemetry wouldn't be used at all.

[pfeerick]

My only nitpicks so far would be:

• for CRSF/ELRS, FM has quotes which shouldn't be there
• 1RSS isn't being read from the attached log file (TX16S, ELRS, Betaflight). TinyTrainer2-2024-08-03-091029.zip
• Could do with some padding at the top for the checkboxes... (ignore this if already covered earlier)
  

Otherwise, after a quick poke around and replay of the log... this is working fantastic! :)

[pfeerick]

btw, don't think I didn't notice this! 🤣 🤣 🤣

[nrw505]

• for CRSF/ELRS, FM has quotes which shouldn't be there

Fixed

• 1RSS isn't being read from the attached log file (TX16S, ELRS, Betaflight). TinyTrainer2-2024-08-03-091029.zip

It's being read OK, but I had the UI set up wrong given CRSF RSS measurements are an actual measurement not a percentage-like value like S.Port. Fixed.

• Could do with some padding at the top for the checkboxes... (ignore this if already covered earlier)

Oops, didn't mean to change that part of the original UI. Padding added.

[nrw505]

btw, don't think I didn't notice this! 🤣 🤣 🤣

Hey, you said you wanted it merge-ready :P . Keep an eye out for followup PRs. I also want to change what's selectable in the internal/external module dropdowns based on what the simulated radio is capable of and maybe a warning if you choose something that the current model isn't configured for.

[3djc]

Looks quite nice to me.

Unsure if in the scope of this contest, but I think ELRS has this specificity that you can set frame rate and telemetry frame ratio. When set to very low frame rate (like 25hz) and low telemetry ratio, the flow of incoming telemetry is quite slow, and may potentially affect Lua scripts. It would be great if (even at a later time) you could have a way to specify 'I'm running at 25Hz, 1/32 telem' (or whatever those values are)

But already quite nice !

[pfeerick]

That's probably out of scope, but would be interesting to see. Do you see that primarily only affecting the replay of a log? Thus effectively just more granularity over the replay rate? Or are you after it slowing down/controlling the refreshes of the sensors, i.e. for ELRS to be taking into account the LINK and DATA groupings and data rates for sensors.

[3djc]

I was thinking 'live' usage, affecting the refresh of sensors, for LUA devs who might make computation based on sensor that might glitch at low or high refresh speed. But thinking about it, that may not be practical since you need to hand change the values. Unless is introduced (definitely out of scope) an variation feature where you can ask sensors to 'jitter' a certain quantity

[nrw505]

I was thinking 'live' usage, affecting the refresh of sensors, for LUA devs who might make computation based on sensor that might glitch at low or high refresh speed. But thinking about it, that may not be practical since you need to hand change the values. Unless is introduced (definitely out of scope) an variation feature where you can ask sensors to 'jitter' a certain quantity

You could change the log controller to schedule changes in line with the timestamp field of the CSV (rather than assuming the rate based on the first 20 rows), and then generate a CSV with "jittered" timestamps and/or values..

I'm not sure how you'd be able to generate a log from an observed problematic sensor, as the loggin process is a periodic sampler rather than logging the telemetry with a timestamp as it comes in.

[nrw505]

Oops wrong button sorry

[3djc]

I was not thinking log at all, only live data, that could have a "jitter" (by that i don't mean like a problematic sensor, but like any sensor which value changes over time) value of 0 (so like today) or say x% where value would vary by that much, as it is currently difficult when you debug scripts on simu to see how your values follow (or not) sensor value changes (but then again , out of scope of the competition itself)

[nrw505]

@3djc you mean kind of like how the simulated GPS can currently be set to run its own little simulation which updates the position over time?

[3djc]

@3djc you mean kind of like how the simulated GPS can currently be set to run its own little simulation which updates the position over time?

Yes, something very similar, it could look like that (quick concept)

where you could decide an amount of variation. If you wanted to go over the top, you would add another column to decide variation type (rng, sine, triangle, square,..), but a default of triangle or rng would be perfect

[nrw505]

Rebased to squash all the fixups

[pfeerick]

Probably my final comments on this before merge:

• can we make it so don't need to re-enter instance ids for the FrSky SPort fields before they function? As now need to reenter at least "something" before can replay frsky telemetry.
• from a BF ELRS quad, GPS lat long appears to not be comma separated, so doesn't relay through to simulation from the logs (i.e. see Crux3 NLR-2022-10-08-093345.csv.zip)...

[nrw505]

• can we make it so don't need to re-enter instance ids for the FrSky SPort fields before they function? As now need to reenter at least "something" before can replay frsky telemetry.

Whoops, had some initialisation for the FrSky provider called by the wrong spot: now it populates those instance id fields like it did before this PR.

• from a BF ELRS quad, GPS lat long appears to not be comma separated, so doesn't relay through to simulation from the logs

Made the simulated GPS accept space separated lat/long as well as tolerating spaces around a comma.

[pfeerick]

Seems to be working perfectly... thank you! :)