Many Spektrum telemetry sensors not defined. #3368
Comments
|
Have been working on the spectrum telemetry lately. Specifically the GSP, ID=0x16 and 0x17 (non binary), and AS3X/SAFE Flight Mode. The challenge is getting a sensor to test. Do you own this sensors??? I have a way that we can capture the data and save it into a file in your radio, and then in development (without the sensor), i can use some of the capture data to develop/test locally. If you can capture some sample data, that will help a lot. Check this other similar issue that we are trying to fix it using this remote data capture method: |
|
In fact I am working an a project named openXsensor on RP2040. For SRXL2, I did not planned to develop 16 and 17 frames for GPS because it seems me much better to use the binary format (= 0X26 frame). |
|
@mstrens hi! Nice to see you here! I’ve been using openXsensor in quite some planes ;-) feel free to just file a PR if you need anything, that is much easier as you can get it tested as well ;-) |
|
I never installed Edge on my Tx. I could propose some changes to Edge for spektrum telemetry but I can't test it. |
|
Nice to meet you @mstrens! whats your name? Would be great to coordinate and collaborate, and let me know more about your sensors.. would like to use them. I think my little tools here can help more development.
Bye, |
|
@mstrens let me know in case you need a second radio to be able to test with EdgeTx. Just contact me on Discord: drop by at the dev channel and ask for Raphael. |
|
I prepare some changes to the file spektrum.cpp.
|
|
On rcgroups forum, there is a message saying that all Spektrum sensors are nor using big-endian in the telemetry frame. |
|
It can handle both big-endian and little-endian.. you just have to change the type in the table. By default, big-endian. We need to know what sensors uses big or little. We could capture the frames from someone who has the sensor, so we can be sure, as well as use those frames for testing. ------- Data types ---------------------- |
|
@mstrens, will do your changes and compile it for your to test. Will have some time over the weekend. What radio are you using?? TX16S? |
|
Thanks. |
|
Hi frankiearzu, |
|
Firmware with your changes.. based on 2.8.1 I don't see different compilations options between TX16S and TX16S MkII. How spektrum.cpp looks: Let me know if your binary GPS works now, as well as the fixes for ESC values. |
|
@pierrotm777 wrote:
@pierrotm777 So i guess the Lat/Long needs to be devided by 10. use the NMEA format, will be easier (decimal minutes) instead of DMS. |
|
About GPS alt, I found the bug in my oXs program (value was not filled correctly). About GPS long and lat, I think the error (adding a division by 10) is the spektrum.cpp program because the spektrum doc says that it is in degree with 7 decimals ("// degree / 10,000,000") and this is the way oXs fill the fields. About sensor 0X18, here are the lines to be added Still this creates new codes for names. So those codes should be added to another table in another file (code => string name) |
|
I forgot to say that all other changes seems OK. |
|
New firmare with your changes. Attached here the firware and the specktrum.cpp. Don't know what name to give the new sensorts. Do you know what is the name on a spektrum radio?? // 0x18 RX CAPACITY METER |
|
Thank you Frank, |
|
Was able to validate the RPM canculation (Erpm), as well as the current ECUR.. have to change it from mAh to A.. on a bigger plane using almost 80A, 80A is easier to read than 80000.0mAh. After doing your build, i continued testing, and fixed a few other minor things... The EThr (Throttle percent) i also fix it to be 0-100% instrad of 0.0-10.0%. (no decimals). Also found another funny bug... telemetry connection starts sending data, but in the initial part, it uses i2CAddress=0 (no-op/dummy)... so if you are discovering sensors in EdgeTX, will create all the fake sensorts 0000,0002,0004, etc.. |
|
Also found another funny bug... telemetry connection starts sending data, but in the initial part, it uses i2CAddress=0 (no-op/dummy)... so if you are discovering sensors in EdgeTX, will create all the fake sensorts 0000,0002,0004, etc.. In fact, i have found sensors from 0000 to 000D :-) |
|
@mstrens @pierrotm777: Any news with the latest changes? |
|
Hi Franki, all is OK now accept GSpd value that seems not correct. |
|
For the ID 0000 to 0000D... have a fix for that. On the GSpd is it a scaling problem (multiply or divide by 10)??? of the value does not make sense?? There is not much that we are doing in the code.. is just a plain uint8 (0..256 kmh) Have to make nicer names for the sensors... (RXB_Curr, etc) Will work this weekend to cleanup the code, and compile a new testing firmware. |
|
For GSpd it's a value that is not much sense. |
|
For GPS speed, oXs transmits the value in km/h as defined in the doc from Spektrum.. |
|
Hello, I test the firmware 2.8.3 with the Spektrum protocol. ID 0000 to 000D now don't exits. |
|
2.8.3 don’t have your changes for binary GPS.We need to do a few more testing and get proper names for the battery sensors.I can create a 2.8.3 with that changes to continue that work.Frankie On Apr 22, 2023, at 10:58 AM, pierrotm777 ***@***.***> wrote:
Hello,
I test the firmware 2.8.3 with the Spektrum protocol.
ID 0000 to 000D now don't exits.
But i discover now some ID from 2600 to 260C .
I don't see GPS values :-( !
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
|
Ok, I wait you new 2.8.3 new version for test 👌 |
1. Expand constants for telemetry frame SIDs and optimize flow of processing of sensors (less CPU work) 2. Add Binary GPS 3. Add Dual Battery Sensor monitor 4. Fix bad math on some ESC sensors 5. Fix problem where ESC RPM sensor was changed from "Erpm" to "EscR".. fix it back to "Erpm" for compatibility with 2.8.x
1. Split long if-then-else code into more granular function. 2. fix ESC VBEC (BEC voltage) 3. Improve testing function
|
Hi Franki, |
…attery Sensor Capacity meter (#3615) * #3368 DSM Telemetry Fixes 1. Expand constants for telemetry frame SIDs and optimize flow of processing of sensors (less CPU work) 2. Add Binary GPS 3. Add Dual Battery Sensor monitor 4. Fix bad math on some ESC sensors 5. Fix problem where ESC RPM sensor was changed from "Erpm" to "EscR".. fix it back to "Erpm" for compatibility with 2.8.x * #3368 DSM Telemetry Fixes 1. Split long if-then-else code into more granular function. 2. fix ESC VBEC (BEC voltage) 3. Improve testing function
|
@pierrotm777 2.9 will be released soon... this fix/improvement will be released. I can make a 2.8.4+this changes if you need them sooner. |
|
Thanks Franki, as you want, if you have some time for build a 2.8.4 version, that will be cool. |
|
@mstrens @pierrotm777 you posted earlier: I think this might be right, since the Flight Pack Energy sensor was sending data in little-endian, is manufactured by "Eagle Tree". I think all Eagle Tree might be little endians. For the Binary GPS and RX capacity metter, i think they probably use little-endian too if they are manufactured by Eagle Tree. Frankie |
|
@frankiearzu I can create a seperate issue to take this forward, but my query relates to a similar issue. I have a kingtech turbine telemetry unit which kiddybacks on spektrum's jetcat telemetry interface when transmitting telemetry to a spektrum receiver. However, as can be seen in edgetx/radio/src/telemetry/spektrum.cpp Line 193 in 149e1a2 When trying to utilise it tonight, on my TX16S MAX I, was able to detect the non-commented lines in the I2C_JETCAT address but not the status messages, they wouldn't even read as an int for example. The status message enums can be found in 2 sections of this file https://github.com/SpektrumRC/SpektrumDocumentation/blob/2a8a5f9d6f85eff0d2458b9ac2b05e9dcf7ddcab/Telemetry/spektrumTelemetrySensors.h#L739. BUT kingtech use different phrases in their status enums from the jetcat enums which means there needs to be a way to specify the turbine being used, too. The differences can be found on page 41 in section 2.9.4 of https://drive.google.com/file/d/1TfaMCA3zpDcdGQMnRq5MnjJexTBp-VZD/view |
|
Really not much focus on turbine, since is not that common, but can be added.. thats what open source is for :-) We should start a new improvement request. If i understand correctly, you are getting some data into sensors, but not all of them (Status for example). We could aproach it in three ways:
Options 1/2 will allow you to log the value into telemetry logs... Please create the new request, and we can work on what could be a good solution. |
|
Thanks for the prompt response Frankie - that's great to hear! My initial thought is that option 2 is the better as it keeps all the sensor data importing as close to the sensors page as possible, otherwise a new user would have to know separately about the widgets to translate it. I'll make the request now! |
Is there an existing issue for this feature request?
Is your feature request related to a problem?
On edgeTx handset , there are many telemetry sensors that are not displayed in the expected fields.
Spektrum uses an ID for each type of sensor.
Many of them are not yet defined in the table used by EdgeTx to recognise the different fields in the telemetry frame.
I have e.g. following sensors that I can' use because they are not defined in the table
Describe the solution you'd like
Please fill the edge table to support:
//////////////////////////////////////////////////////////////////////////////
//
// GPS
// Binary Type
//
// NOTE: Data resolution for all fields matches Crossfire EXCEPT speed.
//
//////////////////////////////////////////////////////////////////////////////
//
typedef struct
{
uint8_t identifier; // Source device = 0x26
uint8_t sID; // Secondary ID
uint16_t altitude; // m, 1000m offset
int32_t latitude; // degree / 10,000,000
int32_t longitude; // degree / 10,000,000
uint16_t heading; // degree / 10
uint8_t groundSpeed; // km/h
uint8_t numSats; // count
} attribute((packed)) STRU_TELE_GPS_BINARY;
and also
//////////////////////////////////////////////////////////////////////////////
//
// RX CAPACITY METER
//
//////////////////////////////////////////////////////////////////////////////
//
typedef struct
{
uint8_t identifier; // Source device = 0x18
uint8_t sID; // Secondary ID
int16_t current_A; // Instantaneous current, 0.01A (0-328.7A) 7FFF-> no data
uint16_t chargeUsed_A; // Integrated mAh used, 0.1mAh (0-3276.6mAh)
uint16_t volts_A; // Volts, 0.01V increments (0-16.00V)
int16_t current_B; // Instantaneous current, 0.01A (0-328.7A) 7FFF-> no data/sensor B
uint16_t chargeUsed_B; // Integrated mAh used, 0.1mAh (0-3276.6mAh)
uint16_t volts_B; // Volts, 0.01V increments (0-16.00V)
uint8_t alerts, // Bit mapped alert conditions (see below)
highCharge; // High nybble is extra bits for chargeUsed_B, Low is for chargeUsed_A
} attribute((packed)) STRU_TELE_RX_MAH;
#define RXMAH_PS_ALERT_NONE (0) // No alarms
#define RXMAH_PS_ALERT_RF_INT (1 << 0) // A or internal Remote failure
#define RXMAH_PS_ALERT_RF_ANT1 (1 << 1) // B remote power fault
#define RXMAH_PS_ALERT_RF_ANT2 (1 << 2) // L remote power fault
#define RXMAH_PS_ALERT_RF_ANT3 (1 << 3) // R remote power fault
#define RXMAH_PS_ALERT_OVERVOLT_A (1 << 4) // Battery A is over voltage
#define RXMAH_PS_ALERT_OVERVOLT_B (1 << 5) // Battery A is over voltage
#define RXMAH_PS_ALERT_RFU1 (1 << 6)
#define RXMAH_PS_ALERT_RFU2 (1 << 7)
Describe alternatives you've considered
No response
Additional context
The table to complete in EdgeTx is:
spektrumSensors[] (in file spektrum.cpp).
The list of all sensors defined by spektrum is in this document:
https://github.com/SpektrumRC/SpektrumDocumentation/blob/master/Telemetry/spektrumTelemetrySensors.h
The text was updated successfully, but these errors were encountered: