This MavLink_FrSkySPort repository is discontinued! The development is moved to athertop/MavLink_FrSkySPort. Please do not use this repo, and follow the link to athertop.
Would be keen to get a chat going here about voice message refactoring. This is the background:
As we can place the Teensy ground side now (for LRS systems providing ground-side Mavlink) this means some users will want to run different models off one ground station (one teensy), and its likely that all these models may have differing AP versions - for example one user has copter and plane running APM (2.21) and also copter running Pixhawk (3.4). In the traditional design, he would need to change the teensy code and the wav files each time he wants to fly a different model. This is because the Teensy code currently requires the inclusion of message code to choose either 3.2 or 3.3 message tables. the two different version tables often use the same number for different messages, so in order to consolidate all possible messages into one big lookup table (covering all versions of copter/plane), I would need to re-assign all numbering from scratch. Figuring the best way to organise these messages so I can assign a logical numbering scheme is the basis for this conversation.
Currently, the Tmp2 SmartPort sensor carries the message number and severity code (and armed state) down to the Taranis. We compile these numbers inside a uint_16t variable, 1 bit for armed status, then 4 bits for severity (16 values possible), followed by the next 10 bits for message code (1024 different possible values),and finally 1 (most significant) bit is not yet used. So using the existing variable I could extend it to use that spare bit, so have 11 bits for the message code (so 2048 distinct values). Alternatively, as the FrSky Tmp2 sensor value is defined as a 32bit integer, we could change the code to use all 32 bits - so would have 27bits for message numbering (134,217,727 distinct possible values), so I don't think we would run out of numbers here :-)
So I would like to compile a list of all possible messages from versions of plane/copter from 3.2 to current, and assign each message a unique number, and then build wav files for each. The discussion I would like to have here is: what is the best way to organise those messages into numeric groups? Is this even important? I.e. is there value to managing a numeric grouping structure?
Would be great if you were willing to share some thoughts on this - give me some suggestions for direction perhaps.
@wolkstein , @Clooney82 , @lvale ,
Would be keen to get a chat going here about voice message refactoring. This is the background:
As we can place the Teensy ground side now (for LRS systems providing ground-side Mavlink) this means some users will want to run different models off one ground station (one teensy), and its likely that all these models may have differing AP versions - for example one user has copter and plane running APM (2.21) and also copter running Pixhawk (3.4). In the traditional design, he would need to change the teensy code and the wav files each time he wants to fly a different model. This is because the Teensy code currently requires the inclusion of message code to choose either 3.2 or 3.3 message tables. the two different version tables often use the same number for different messages, so in order to consolidate all possible messages into one big lookup table (covering all versions of copter/plane), I would need to re-assign all numbering from scratch. Figuring the best way to organise these messages so I can assign a logical numbering scheme is the basis for this conversation.
Currently, the Tmp2 SmartPort sensor carries the message number and severity code (and armed state) down to the Taranis. We compile these numbers inside a uint_16t variable, 1 bit for armed status, then 4 bits for severity (16 values possible), followed by the next 10 bits for message code (1024 different possible values),and finally 1 (most significant) bit is not yet used. So using the existing variable I could extend it to use that spare bit, so have 11 bits for the message code (so 2048 distinct values). Alternatively, as the FrSky Tmp2 sensor value is defined as a 32bit integer, we could change the code to use all 32 bits - so would have 27bits for message numbering (134,217,727 distinct possible values), so I don't think we would run out of numbers here :-)
So I would like to compile a list of all possible messages from versions of plane/copter from 3.2 to current, and assign each message a unique number, and then build wav files for each. The discussion I would like to have here is: what is the best way to organise those messages into numeric groups? Is this even important? I.e. is there value to managing a numeric grouping structure?
Would be great if you were willing to share some thoughts on this - give me some suggestions for direction perhaps.
Cheers, Paul