- Posts: 3333
DSM Telemetry support
- vlad_vy
- Offline
static void parse_telemetry_packet()
{
static s32 altitude;
static const u8 update7f[] = {
TELEM_DSM_FLOG_FADESA, TELEM_DSM_FLOG_FADESB,
TELEM_DSM_FLOG_FADESL, TELEM_DSM_FLOG_FADESR,
TELEM_DSM_FLOG_FRAMELOSS, TELEM_DSM_FLOG_HOLDS,
TELEM_DSM_FLOG_VOLT2, 0};
static const u8 update7e[] = {
TELEM_DSM_FLOG_RPM1, TELEM_DSM_FLOG_VOLT1, TELEM_DSM_FLOG_TEMP1, 0};
static const u8 update16[] = { TELEM_GPS_ALT, TELEM_GPS_LAT, TELEM_GPS_LONG, 0};
static const u8 update17[] = { TELEM_GPS_SPEED, TELEM_GPS_TIME, 0};
const u8 *update = NULL;
switch(packet[0]) {
case 0x7f: //TM1000 Flight log
case 0xff: //TM1100 Flight log
update = update7f;
Telemetry.p.dsm.flog.fades[0] = pkt16_to_u8(packet+2); //FadesA 0xFFFF = (not connected)
Telemetry.p.dsm.flog.fades[1] = pkt16_to_u8(packet+4); //FadesB 0xFFFF = (not connected)
Telemetry.p.dsm.flog.fades[2] = pkt16_to_u8(packet+6); //FadesL 0xFFFF = (not connected)
Telemetry.p.dsm.flog.fades[3] = pkt16_to_u8(packet+8); //FadesR 0xFFFF = (not connected)
Telemetry.p.dsm.flog.frameloss = pkt16_to_u8(packet+10);
Telemetry.p.dsm.flog.holds = pkt16_to_u8(packet+12);
Telemetry.p.dsm.flog.volt[1] = pkt16_to_volt(packet+14);
break;
case 0x7e: //TM1000
case 0xfe: //TM1100
update = update7e;
Telemetry.p.dsm.flog.rpm = pkt16_to_rpm(packet+2);
Telemetry.p.dsm.flog.volt[0] = pkt16_to_volt(packet+4); //In 1/10 of Volts
Telemetry.p.dsm.flog.temp = pkt16_to_temp(packet+6);
case 0x03: //High Current sensor
//Telemetry.current = (s32)((s16)(packet[2] << 8) | packet[3]) * 196791 / 100000; //In 1/10 of Amps (16bit signed integer, 1 unit is 0.196791A)
break;
case 0x0a: //Powerbox sensor
//Telemetry.pwb.volt1 = (((s32)packet[2] << 8) | packet[3] + 5) /10; //In 1/10 of Volts
//Telemetry.pwb.volt1 = (((s32)packet[4] << 8) | packet[5] + 5) /10; //In 1/10 of Volts
//Telemetry.pwb.capacity1 = ((s32)packet[6] << 8) | packet[7]; //In mAh
//Telemetry.pwb.capacity2 = ((s32)packet[8] << 8) | packet[9]; //In mAh
//Telemetry.pwb.alarm_v1 = packet[15] & 0x01; //0 = disable, 1 = enable
//Telemetry.pwb.alarm_v2 = (packet[15] >> 1) & 0x01; //0 = disable, 1 = enable
//Telemetry.pwb.alarm_c1 = (packet[15] >> 2) & 0x01; //0 = disable, 1 = enable
//Telemetry.pwb.alarm_c2 = (packet[15] >> 3) & 0x01; //0 = disable, 1 = enable
break;
case 0x11: //AirSpeed sensor
//Telemetry.airspeed = ((s32)packet[2] << 8) | packet[3]; //In km/h (16Bit value, 1 unit is 1 km/h)
break;
case 0x12: //Altimeter sensor
//Telemetry.altitude = (s16)(packet[2] << 8) | packet[3]; //In 0.1 meters (16Bit signed integer, 1 unit is 0.1m)
//Telemetry.maxaltitude = (s16)(packet[4] << 8) | packet[5]; //In 0.1 meters (16Bit signed integer, 1 unit is 0.1m)
break;
case 0x14: //G-Force sensor
//Telemetry.gforce.x = (s16)(packet[2] << 8) | packet[3]; //In 0.01g (16Bit signed integers, unit is 0.01g)
//Telemetry.gforce.y = (s16)(packet[4] << 8) | packet[5];
//Telemetry.gforce.z = (s16)(packet[6] << 8) | packet[7];
//Telemetry.gforce.xmax = (s16)(packet[8] << 8) | packet[9];
//Telemetry.gforce.ymax = (s16)(packet[10] << 8) | packet[11];
//Telemetry.gforce.zmax = (s16)(packet[12] << 8) | packet[13];
//Telemetry.gforce.zmin = (s16)(packet[14] << 8) | packet[15];
break;
case 0x15: //JetCat sensor
//Telemetry.jc.status = packet[2];
//Possible messages for status:
//0x00:OFF
//0x01:WAIT FOR RPM
//0x02:IGNITE
//0x03;ACCELERATE
//0x04:STABILIZE
//0x05:LEARN HIGH
//0x06:LEARN LOW
//0x07:undef
//0x08:SLOW DOWN
//0x09:MANUAL
//0x0a,0x10:AUTO OFF
//0x0b,0x11:RUN
//0x0c,0x12:ACCELERATION DELAY
//0x0d,0x13:SPEED REG
//0x0e,0x14:TWO SHAFT REGULATE
//0x0f,0x15:PRE HEAT
//0x16:PRE HEAT 2
//0x17:MAIN F START
//0x18:not used
//0x19:KERO FULL ON
//0x1a:MAX STATE
//Telemetry.jc.throttle = (packet[3] >> 4) * 10 + (packet[3] & 0x0f); //up to 159% (the upper nibble is 0-f, the lower nibble 0-9)
//Telemetry.jc.pack_volt = (((packet[5] >> 4) * 10 + (packet[5] & 0x0f)) * 100
// + (packet[4] >> 4) * 10 + (packet[4] & 0x0f) + 5) / 10; //In 1/10 of Volts
//Telemetry.jc.pump_volt = (((packet[7] >> 6) * 10 + (packet[7] & 0x0f)) * 100
// + (packet[6] >> 4) * 10 + (packet[6] & 0x0f) + 5) / 10; //In 1/10 of Volts (low voltage)
//Telemetry.jc.rpm = ((packet[10] >> 4) * 10 + (packet[10] & 0x0f)) * 10000
// + ((packet[9] >> 4) * 10 + (packet[9] & 0x0f)) * 100
// + ((packet[8] >> 4) * 10 + (packet[8] & 0x0f)); //RPM up to 999999
//Telemetry.jc.tempEGT = (packet[13] & 0x0f) * 100 + (packet[12] >> 4) * 10 + (packet[12] & 0x0f); //EGT temp up to 999В°C
//Telemetry.jc.off_condition = packet[14];
//Messages for Off_Condition:
//0x00:NA
//0x01:OFF BY RC
//0x02:OVER TEMPERATURE
//0x03:IGNITION TIMEOUT
//0x04:ACCELERATION TIMEOUT
//0x05:ACCELERATION TOO SLOW
//0x06:OVER RPM
//0x07:LOW RPM OFF
//0x08:LOW BATTERY
//0x09:AUTO OFF
//0x0a,0x10:LOW TEMP OFF
//0x0b,0x11:HIGH TEMP OFF
//0x0c,0x12:GLOW PLUG DEFECTIVE
//0x0d,0x13:WATCH DOG TIMER
//0x0e,0x14:FAIL SAFE OFF
//0x0f,0x15:MANUAL OFF
//0x16:POWER BATT FAIL
//0x17:TEMP SENSOR FAIL
//0x18:FUEL FAIL
//0x19:PROP FAIL
//0x1a:2nd ENGINE FAIL
//0x1b:2nd ENGINE DIFFERENTIAL TOO HIGH
//0x1c:2nd ENGINE NO COMMUNICATION
//0x1d:MAX OFF CONDITION
break;
case 0x16: //GPS sensor (always second GPS packet)
update = update16;
altitude += (((packet[3] >> 4) * 10 + (packet[3] & 0x0f)) * 100
+ ((packet[2] >> 4) * 10 + (packet[2] & 0x0f))) * 100; //In meters * 1000 (16Bit decimal, 1 unit is 0.1m)
Telemetry.gps.altitude = altitude;
Telemetry.gps.latitude = ((packet[7] >> 4) * 10 + (packet[7] & 0x0f)) * 3600000
+ ((packet[6] >> 4) * 10 + (packet[6] & 0x0f)) * 60000
+ ((packet[5] >> 4) * 10 + (packet[5] & 0x0f)) * 600
+ ((packet[4] >> 4) * 10 + (packet[4] & 0x0f)) * 6; // (decimal, format DD MM.SSSS)
if ((packet[15] & 0x01) == 0)
Telemetry.gps.latitude *= -1; //1=N(+), 0=S(-)
Telemetry.gps.longitude = ((packet[11] >> 4) * 10 + (packet[11] & 0x0f)) * 3600000
+ ((packet[10] >> 4) * 10 + (packet[10] & 0x0f)) * 60000
+ ((packet[9] >> 4) * 10 + (packet[9] & 0x0f)) * 600
+ ((packet[8] >> 4) * 10 + (packet[8] & 0x0f)) * 6; // (decimal, format DD MM.SSSS)
if ((packet[15] & 0x04) == 4)
Telemetry.gps.longitude += 360000000; //1=+100 degrees
if ((packet[15] & 0x02) == 0)
Telemetry.gps.longitude *= -1; //1=E(+), 0=W(-)
//Telemetry.gps.heading = ((packet[13] >> 4) * 10 + (packet[13] & 0x0f)) * 10
// + ((packet[12] >> 4) * 10 + (packet[12] & 0x0f)) / 10; //In degrees (16Bit decimal, 1 unit is 0.1 degree)
break;
case 0x17: //GPS sensor (always first GPS packet)
update = update17;
Telemetry.gps.velocity = (((packet[3] >> 4) * 10 + (packet[3] & 0x0f)) * 100
+ ((packet[2] >> 4) * 10 + (packet[2] & 0x0f))) * 5556 / 108; //In m/s * 1000
u8 hour = (packet[7] >> 4) * 10 + (packet[7] & 0x0f);
u8 min = (packet[6] >> 4) * 10 + (packet[6] & 0x0f);
u8 sec = (packet[5] >> 4) * 10 + (packet[5] & 0x0f);
//u8 ssec = (packet[4] >> 4) * 10 + (packet[4] & 0x0f);
u8 day = 0;
u8 month = 0;
u8 year = 0; // + 2000
Telemetry.gps.time = ((year & 0x3F) << 26)
| ((month & 0x0F) << 22)
| ((day & 0x1F) << 17)
| ((hour & 0x1F) << 12)
| ((min & 0x3F) << 6)
| ((sec & 0x3F) << 0);
//Telemetry.gps.sats = ((packet[8] >> 4) * 10 + (packet[8] & 0x0f));
altitude = ((packet[9] >> 4) * 10 + (packet[9] & 0x0f)) * 1000000; //In 1000 meters * 1000 (8Bit decimal, 1 unit is 1000m)
break;
}
if (update) {
while(*update) {
TELEMETRY_SetUpdated(*update++);
}
}
}
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
case 0x7f: //TM1000 Flight log
case 0xff: //TM1100 Flight log
update = update7f;
Telemetry.p.dsm.flog.fades[0] = pkt16_to_u8(packet+2); //FadesA 0xFFFF = (not connected)
Telemetry.p.dsm.flog.fades[1] = pkt16_to_u8(packet+4); //FadesB 0xFFFF = (not connected)
Telemetry.p.dsm.flog.fades[2] = pkt16_to_u8(packet+6); //FadesL 0xFFFF = (not connected)
Telemetry.p.dsm.flog.fades[3] = pkt16_to_u8(packet+8); //FadesR 0xFFFF = (not connected)
Telemetry.p.dsm.flog.frameloss = pkt16_to_u8(packet+10);
Telemetry.p.dsm.flog.holds = pkt16_to_u8(packet+12);
Telemetry.p.dsm.flog.volt[1] = pkt16_to_volt(packet+14);
break;
Telemetry.p.dsm.flog.fades[0] = pkt16_to_u8(x); - is not fully useful (up to 255 only), normally fades can be up to 500. Also, if fades is more than 511, it's probably = 'Telemetry Range Warning' and has to be filtered and trigger telemetry range warning.
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
if 'A' or 'B' or 'L' or 'R' not equal to its previous value and >=512 (usually =65535) -> Telemetry Range Warning
-> A, B, L, R, F, H -> not valid (must be filtered)
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
vlad_vy wrote: I need DX8 log (.tlm) file with negative (under sea level) GPS altitude to find out how encoded the negative altitude. Possible it coded by a bit in the byte 15 of GPS packet 0x16.
Does anyone have such GPS files???
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
Data type = 0x40: Variometer Sensor
0[00] 0x40
1[01] 00
2[02] MSB_ALT, 16Bit signed integer, 1 unit is 0.1m, altitude.
3[03] LSB_ALT, 16Bit signed integer, 1 unit is 0.1m, altitude.
4[04] MSB_CR, 16Bit signed integer, 1 unit is 0.1m/s, climb rate
5[05] LSB_CR, 16Bit signed integer, 1 unit is 0.1m/s, climb rate
6[06] 00
7[07] 00
8[08] 00
9[09] 00
10[0A] 00
11[0B] 00
12[0C] 00
13[0D] 00
14[0E] 00
15[0F] 00
Please Log in or Create an account to join the conversation.
- Thomas.Heiss
- Offline
- Posts: 698
Link: www.deviationtx.com/forum/builds/3712-ni...-dsm-telemetry-fixed
Greetings
Thomas
Please Log in or Create an account to join the conversation.
- Thomas.Heiss
- Offline
- Posts: 698
It is not known to me that displaying 5-digit values (>9999) of max to 65535 makes sense or might be required at a later time.
It shall be compatible with:
- with higher Spektrum receivers showing >=500 fades (e.g AR8000, see manual)
- tweaking gain values with Flightlog for Blade 200SRX and Blade 180CFX models for showing 9999/888 (200SRX) or 4401/4402 (180CFX) values in the display according to advanced manuals.
To my knowledge only the lower channel Spektrum receivers like AR600, AR6210 map fades to a fixed number of 255/0xFF.
There is also a ticket on BitBucket: bitbucket.org/PhracturedBlue/deviation/i...ly-functional-on-200
First of I have to tell you that basic C programming has been 16 years ago and I am more involved into Java programming But I try my best...
My build for Devo 10 went fine, but I need to find ways to actually test the DSM flightlog screen displaying >255 values or see if I can pickup one of the Blade models from a friend or dealer.
I had to change telemetry.h struct telem_dsm_flog and change u8 to u16 datatypes for fades, frameloss and holds too.
For the first test I replaced pkt16_to_u8 function with:
static int pkt16_to_flog(u8 *ptr)
{
u32 value = ((u32)ptr[0] << | ptr[1];
return value > 9999 ? 9999 : value;
}
and let function parse_telemetry_packet() call:
Telemetry.p.dsm.flog.fades[0] = pkt16_to_flog(packet+2); //FadesA 0xFFFF = (not connected)
Telemetry.p.dsm.flog.fades[1] = pkt16_to_flog(packet+4); //FadesB 0xFFFF = (not connected)
Telemetry.p.dsm.flog.fades[2] = pkt16_to_flog(packet+6); //FadesL 0xFFFF = (not connected)
Telemetry.p.dsm.flog.fades[3] = pkt16_to_flog(packet+; //FadesR 0xFFFF = (not connected)
Telemetry.p.dsm.flog.frameloss = pkt16_to_flog(packet+10);
Telemetry.p.dsm.flog.holds = pkt16_to_flog(packet+12);
What is the correct mapping function to read u16 values and set u16 values?
Isn't casting to u16 enough?
pkt16_to_u8() function previously used u32 casting too for giving back a "255" max int value.
I still do not understand why it is even possible to read u16 values from the "u8 packet[16];" variable, while it is only declared as u8.
But as I can see it for other datatype mapping (e.g temp, volt, sensors,...) it seems to be working?
Can you confirm that the code changes are correct to be working with max of "9999" values?
Would I need to change more source code?
What does 0xFFFF not connected mean in the inline comment?
"FadesB 0xFFFF = (not connected)"
If the actual values are not set in the packet its set to 0xFFFF?
How does DeviationTX Nightly-Build behave when telemetry out of range is fired?
Are there any values / if-conditions set hard-coded in the source code like I read above in this thread?
Has this be implemented? Where?
I also changed telemetry/telem_dsm.c/_dsm_get_max_value and changed 255 to 9999 for testing.
That worked fine in the telemetry config page but that was no u8->u16 datatype change either.
Greetings from Germany
Thomas
Please Log in or Create an account to join the conversation.
- Thomas.Heiss
- Offline
- Posts: 698
good news. It looks generally to be working with showing >255 numbers with u16 datatypes.
I tested with AR600, where A is only 255 (max), but higher framelosses.
On a AR8000 I received these numbers:
A: 255 (max)
L: 1570
B/R 9999 (not connected, inactive according to AR8000 manual)
F 1211
H 8
So at least changing to u16 datatypes and modifying a little bit the mapping in the DSM protocol does not stop the firmware to be working.
Questions:
1) What would I do with the 0xFFFF / 65535 not connected in the mapping or displaying structs to UI, which are currently set to 9999 for B/R?
2) Maybe leave it displayed as "9999" or try to set to "--"?
The code before set it to max 255, if a 0xFFFF has been received in a packet.
So the display showed 255?
Telemetry range mode:
3) When my Devo10 was out of range, A/L switched from time to time to "9999", which is clearly a notify for a received 0xFFFF inside a packet.
4) Even the "not connected" B switched from "9999" to 1138, while not connected R switched from "9999" to 0. Must be the TM which transmits these values.
5) My modified DSM protocol mapping code - as the code before - checks for bigger (>9999 vs >255) values and hard-coded sets A/L/B/R to "9999" (255 before) once 0xFFFF is received.
6) So when a DSM telemetry out of range occurs, the display jumps back and forth from a real value like 255 or 1570 to 9999.
Not that nice...
7) I wish a "telemetry out of range" would just grey out the telemetry fields but not change it's previous read values?!?
Currently it's both, sometimes jumping numbers back and forth, grey out (black highlight), setting read real numbers like A/L to "9999", setting holds to "0" (instead "9999") or setting holds to "255" (instead of "9999").
Again repeated: "9999" does ONLY apply to A/L/B/R, not framelosses, not holds.
9) For bug tracker #571 at least A+L+B+R >255 would be fixed.
FrameLosses can now be >255 too (successfully tested).
10) For holds >255 this would have to be tested first. Not easily testable here.
At least displaying "normal flightlog numbers" has nothing to do with a TM1000 or telemetry out of range messages.
What are you opinions?
Regards
Thomas
Please Log in or Create an account to join the conversation.
- mwm
- Offline
Thomas.Heiss wrote: I am working on a DSM telemetry test build version which might allow displaying "9999" values for A/B/L/R/F/H instead of fixed max value of "255".
My build for Devo 10 went fine, but I need to find ways to actually test the DSM flightlog screen displaying >255 values or see if I can pickup one of the Blade models from a friend or dealer.
Thanks for working on these. I'd love to test them out, but want to make sure I have good copies. Could you provide either a patch file or a pull request against my deviation repository ( bitbucket.org/mwm/deviation )?
Thomas.Heiss wrote: What is the correct mapping function to read u16 values and set u16 values?
Isn't casting to u16 enough?
pkt16_to_u8() function previously used u32 casting too for giving back a "255" max int value.
I still do not understand why it is even possible to read u16 values from the "u8 packet[16];" variable, while it is only declared as u8.
But as I can see it for other datatype mapping (e.g temp, volt, sensors,...) it seems to be working?
Can you confirm that the code changes are correct to be working with max of "9999" values?
In order. Yes, casting to u16 should be enough.
You've forgotten that C started life as a high-level assembler. So in this case, casting to u16 just says "Treat this address as a pointer to u16 and read the value from it." While Java gets its syntax from C, its semantics come from more modern languages.
Well, they look right to me, but I'd like patches to test on my 200SRX. If you can provide patches but not a pull request, I'll create that for the main deviation repository for you.
Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.
My remotely piloted vehicle ("drone") is a yacht.
Please Log in or Create an account to join the conversation.
- Thomas.Heiss
- Offline
- Posts: 698
I created local repository: bitbucket.org/ThomasHeiss/deviation
My changes are committed there.
Its a fork of PhracturedBlue/deviation default so the only? pull request which I seem to be able to create on BitBucket.org automatically is for PB/deviation repository...I am new to Mercurial...
Let's first test and improve it a little bit more together before pushing to PB's repository.
EDIT: I fail to attach the .patch file with the browser gui.
Workaround address: modellbau.theiss-nbg.de/DeviationTX-Nigh...nhancement.patch.txt
Thomas
Please Log in or Create an account to join the conversation.
- victzh
- Offline
- Posts: 1386
This forum accepts only files of several types, so renaming your patch to patch.txt would help.
Please Log in or Create an account to join the conversation.
- mwm
- Offline
I can verify that this indeed fixes the issues with the 200 SRX telemetry. It now works as advertised. So I've attached your patch file to my issue on the deviation repository. If you'd like me to create a pull request as well, please let me know.
I've also had problems trying to use the DSM altimeter telemetry. While I think I sold the hardware to test that, I'd be interested in knowing if this patch might have fixed that.
Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.
My remotely piloted vehicle ("drone") is a yacht.
Please Log in or Create an account to join the conversation.
- Thomas.Heiss
- Offline
- Posts: 698
great news!
Same will apply for Blade 180CFX and showing screen numbers.
I guess I will then simply remove function "pkt16_to_u8" in my repository code as it is not being used at another place (compiler warning).
To create the pull request for PB/deviation I have to say I am still a bit unsure about the 0xFFFF vs fixed "9999" mapping handling.
Same applies to TM / packet changing random fixed numbers.
I believe we need to sort that out / little improve it before...
I am not that happy that two flightlog fades fields showing all the time fixed "9999" even the RX might NOT support it ("not connected"). Users may get irritated in-flight. There is no real value for displaying non-real / un-mapped field numbers.
I guess it may be the better way to send 0xFFFF from dsm2_cyrf6936.c to the UI code or set a constant like "NOT_CONNECTED" and map 0xFFFF/65535 to "--" there and let the UI code do a mapping / filtering before display?
IMHO 5 digit fields are too much for the telemetry screen.
Of course it makes NO SENSE to display "65535" (from the 0xFFFF TM packet) there, as it is no real value, same applies to showing "9999" in my test.
According to 200SRX manual the value range up to "9999" is real.
Blade 180CFX does not use numbers up to "9999" according to manual.
So at least 4-digit numbers up to "9999" would have to be supported (for 200SRX) to be shown in the DSM telemetry flightlog screen fields - at least for now.
I hardly can guess of a real usage for a real value >9999 either for fades/H/F?!
The old mapping for packet 0xFFFF (not connected) to fixed 255/9999 values (which show up 1:1 in UI screen fields) makes no longer sense for the new mapping / display logic.
What about the 255->9999 change in src/telemetry/telem_dsm.c for the DSM telemtry config screen drop down chooser?
My code / patch already implies the change for "9999" (was my 1st testing).
So you can actually select "9999" or you would have to disable frameloss/hold warnings before completely if setting up a heli/plane (which would make sense too).
But generally speaking for DSM flightlog telemetry in-flight range warnings, the select number 9999 in src/telemetry/telem_dsm.c makes no sense for a real warning value.
But does it really make sense to have a warning >255 fades/F/H? I doubt that.
For sure >fades could be 4-digit (>255) as I had tested with AR8000.
The "255" number for select box was surely the simple way to configure the max value of the u8 0xFF datastruct?!?
>40 framelosses and >0 holds should be IMHO the warning for a practible in-flight warning.
Personally I used >80 fades config warning once the RX did good on 1-3 flights.
I believe there was no real spec for setting concrete fades for DSMx/TM manuals by HH/SpektrumRC? Will have to overread again...
Of course one antenna might display >255 fades on DSMx if it was placed/oriented wrong over another antenna with lower fades (e.g satellite), depending on total DSMx channel hopping (compared to DSM2).
But that was more described interdependent by HH/SpektrumRC and not for fades fixed value warnings?!
Nevertheless >80 fades worked for me on DX8 for in-flight warnings as I had low fade values (with 2nd HF-module).
My 1st DX8 HF-module, bad SBEC controllers or combination of both gave >40 framelosses (about 50-90) while 2x fades where quite fast at max. 255 (6CH RX) always. This seem not to be the usual case as I learned if all is good.
But see my previous posting above, AR8000 supports >255 fades and framelosses on some antennas, so will 7-12CH RX do.
Greetings
Thomas
Please Log in or Create an account to join the conversation.
- Indigo
- Offline
- Posts: 230
Over the last 2 weeks , I've been expanding upon the code of vlad_vy and Thomas Heiss. You can find all my dsm telemetry coding here:
bitbucket.org/Indigo1/deviation/commits/all
If you review my code and spot errors please leave comments for me. On the downloads page are prebuilt firmwares (with all commits combined).
You can find a summary of changes here . Add to that one commit added today (see commits link above).
I'm unable to test telemetry myself, all I have is a NanoQX. I only see values for F and H, nothing for A, B, L, R. Please test it and check that it is working correctly.
Cheers,
Indigo
Please Log in or Create an account to join the conversation.
- Indigo
- Offline
- Posts: 230
- When in Telemetry config, disable automatic jumping to telemetry screen.
- Add buttons in Telemetry config to enable a sound test of each alarm
- Add a data filter -- to cache values, sort them and extract the middle value
- Display extended telemetry data
Is there supposed to be a different alarm sound for each telemetry alarm? They all sound the same to me.
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
Data type = 0x40: Variometer Sensor (SPMA9589)
0[00] 0x40
1[01] 00
2[02] MSB_ALT (Hex, signed integer), in 0.1m, altitude.
3[03] LSB_ALT (Hex, signed integer), in 0.1m, altitude.
4[04] MSB_CR250 (Hex, signed integer), in 0.1m, change during the last 250ms
5[05] LSB_CR250 (Hex, signed integer), in 0.1m, change during the last 250ms
6[06] MSB_CR500 (Hex, signed integer), in 0.1m, change during the last 500ms
7[07] LSB_CR500 (Hex, signed integer), in 0.1m, change during the last 500ms
8[08] MSB_CR1000 (Hex, signed integer), in 0.1m, change during the last 1000ms
9[09] LSB_CR1000 (Hex, signed integer), in 0.1m, change during the last 1000ms
10[0A] MSB_CR1500 (Hex, signed integer), in 0.1m, change during the last 1500ms
11[0B] LSB_CR1500 (Hex, signed integer), in 0.1m, change during the last 1500ms
12[0C] MSB_CR2000 (Hex, signed integer), in 0.1m, change during the last 2000ms
13[0D] LSB_CR2000 (Hex, signed integer), in 0.1m, change during the last 2000ms
14[0E] MSB_CR3000 (Hex, signed integer), in 0.1m, change during the last 3000ms
15[0F] LSB_CR3000 (Hex, signed integer), in 0.1m, change during the last 3000ms
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
Data type = 0x18: RX Pack Cap Sensor (SPMA9604)
0[00] 0x18
1[01] 00
2[02] Current LSB (Hex) in 0.01 A
3[03] Current MSB (Hex) in 0.01 A
4[04] Capacity LSB (Hex) in 0.1 mAh
5[05] Caoacity MSB (Hex) in 0.1 mAh
6[06] Voltage LSB (Hex) in 0.01 V
7[07] Voltage MSB (Hex) in 0.01 V
8[08] 00
9[09] 00
10[0A] 00
11[0B] 00
12[0C] 00
13[0D] 00
14[0E] 00
15[0F] 00
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
Data type = 0x34: Flight Pack Cap Sensor (SPMA9605)
0[00] 0x34
1[01] 00
2[02] Current LSB in 0.1 A
3[03] Current MSB in 0.1 A
4[04] Capacity LSB in 1.0 mAh
5[05] Capacity MSB in 1.0 mAh
6[06] Temp LSB in 0.1 degree (Fahrenheit or Celsius ???)
7[07] Temp MSB in 0.1 degree (Fahrenheit or Celsius ???)
8[08] 00
9[09] 00
10[0A] 00
11[0B] 00
12[0C] 00
13[0D] 00
14[0E] 00
15[0F] 00
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
Data type = 0x20: 'hypothetic' ESC Sensor, not released yet.
0[00] 0x20
1[01] 00
2[02] RPM MSB in 10 rpm
3[03] RPM LSB in 10 rpm
4[04] Voltage MSB in 0.01V
5[05] Voltage LSB in 0.01V
6[06] FET Temp MSB in 0.1 degree
7[07] FET Temp LSB in 0.1 degree
8[08] Current MSB in 0.01A
9[09] Current LSB in 0.01A
10[0A] BEC Temp MSB in 0.1 degree
11[0B] BEC Temp LSB in 0.1 degree
12[0C] BEC Current in 0.1A
13[0D] BEC Voltage in 0.05V
14[0E] Throttle % in 0.5%
15[0F] Output % in 0.5%
Please Log in or Create an account to join the conversation.
- Indigo
- Offline
- Posts: 230
@Thomas.Heiss - If you have the time (this weekend maybe?), can you please test the latest - see other thread. Thank you.
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Protocol Development
- DSM Telemetry support