1. Forum
  3. Development
  5. Protocol Development
  7. New FrSkyX protocol

New FrSkyX protocol

More
25 Sep 2016 20:39 #54262 by FDR
Replied by FDR on topic New FrSkyX protocol
Gentlemen, please, no need to be harsh!
Everybody's intention is to implement a reverse engineered protocol to work as good as possible for everybody's sake. ;)
It only needs some patience and respect to work out the bugs...

Please Log in or Create an account to join the conversation.

More
25 Sep 2016 20:45 - 25 Sep 2016 20:46 #54263 by petsmith
Replied by petsmith on topic New FrSkyX protocol

midelic wrote: Guys do whatever you feel is good.I tried to help ..but I'm out now ,do whatever you want.


I don't know what to say. I know you're the developer of this FrskyX for DIYModule. I'm only telling you what I had observed and you're implying me that I'm making things up. From all my testing & logs, the checksum DID BLOCK all the corrupting packets that I've encountered so far. Again, I didn't make up anything. If you can't accept a developer can be wrong sometimes. I don't know what else I can say. Anyway, I don't want me to be the reason for your leaving. You don't need to go as the whole Deviation community treasure you. I should be the one to leave as I didn't contribute much at all. Bye everyone!
Last edit: 25 Sep 2016 20:46 by petsmith.

Please Log in or Create an account to join the conversation.

More
25 Sep 2016 20:52 - 25 Sep 2016 20:57 #54264 by midelic
Replied by midelic on topic New FrSkyX protocol
This is unbelievable,I'm not going anywhere as I write here occasionally .I don;t belong to deviation community no more than normal user .I belong to RCGroups community where I'm involved ,I write here from time to time when I want to help.
If checksum works very good Imo should not be necessary.My thinking was to find the real problem.
Last edit: 25 Sep 2016 20:57 by midelic.

Please Log in or Create an account to join the conversation.

More
25 Sep 2016 20:57 #54266 by lamnesique
Replied by lamnesique on topic New FrSkyX protocol
hi men (petsmith and midelic),
IMO the commity need you both, don't be hungry, we are all here for the same things, and to exchange on our compétences and experience, i dont anderstand the dev part but i can test for you.
be cool and happy

Please Log in or Create an account to join the conversation.

More
26 Sep 2016 05:22 #54276 by dc59
Replied by dc59 on topic New FrSkyX protocol

lamnesique wrote: hi men (petsmith and midelic),
IMO the commity need you both, don't be hungry, we are all here for the same things, and to exchange on our compétences and experience, i dont anderstand the dev part but i can test for you.
be cool and happy


+1

Please Log in or Create an account to join the conversation.

More
26 Sep 2016 12:06 #54285 by Cereal_Killer
Replied by Cereal_Killer on topic New FrSkyX protocol
^ +2

Forums are designed for people with conflicting opinions on different things to come together for a greater good. Both you guys do amazing work and though you may go about it different and have opposing views on what works neither of you are wrong... Please neither of you go anywhere, we need you, the internet needs you!
Taranis X9E | DEVO 10 | Devo U7E | Taranis Q7

What I do in real life: rivergoequestrian.com/

Please Log in or Create an account to join the conversation.

More
26 Sep 2016 12:23 #54286 by hexfet
Replied by hexfet on topic New FrSkyX protocol

petsmith wrote: @hexfet, the reason we couldn't get any telemetry in the last build is 'cos you're including the 2 crc bytes in calculating the checksum. ...should be like to this, "len-5" needs to be changed to "len-7"

        && crc(&pkt[3], len-7) == (pkt[len-4] << 8 | pkt[len-3])


Thanks for catching that. The test build is updated.

Please Log in or Create an account to join the conversation.

More
26 Sep 2016 20:42 #54306 by lamnesique
Replied by lamnesique on topic New FrSkyX protocol

hexfet wrote:

petsmith wrote: @hexfet, the reason we couldn't get any telemetry in the last build is 'cos you're including the 2 crc bytes in calculating the checksum. ...should be like to this, "len-5" needs to be changed to "len-7"

        && crc(&pkt[3], len-7) == (pkt[len-4] << 8 | pkt[len-3])


Thanks for catching that. The test build is updated.


hi, just flash the new build and it look ok, the telemetry is back...i will test outdoor tomorow

Please Log in or Create an account to join the conversation.

More
27 Sep 2016 15:10 - 27 Sep 2016 15:46 #54336 by petsmith
Replied by petsmith on topic New FrSkyX protocol

midelic wrote: My thinking was to find the real problem.

midelic, that's what I want too, to find the real problem. Can we start over and be civilized? No attacks, just discussion over the facts, okay?

Here, I will like to post the logs. These logs were generated by a Devo u7e with a XSR receiver 10 feet away and a concrete wall in between. The firmware that produced these logs are based on the current nightly. That is, it still has the dropout issue and no fix applied. I only added a few logging statements at the end of the function frsky_check_telemetry(), after the statement frsky_parse_sport_stream, as listed below, nothing else is changed in the code.

The 1st column in the log is the packet sequence number that I added. As you can see from the 1st log, there were about 50 out of 4500 packets with CRC mismatched (1%). Some of these are obviously corrupted by looking at the packet length and pkt[6]. Without the CRC checking, some of these packets will corrupt the Telemetry display, and some will result in dropouts. In the 2nd log, I only dumped packets with packet length not equals to 17. About 14 out of 10000 packets are received with incorrect length (0.1%). One of them is with packet length 7. The strange thing is some packets are even longer than 17.

I can think of several reasons for the mismatched CRCs and incorrect length packets.

1) You mentioned that the CRC bytes are from Taranis openTX, not from FrskyX protocol. If this is true, it would mean that the CRC are generated by Transmitter CC2500 module or Deviation firmware, and there are some bugs in the CC2500 or Deviation firmware.

2) These are actually corrupted packets during radio transmission, and the CRC bytes are generated on the receiver side.

3) There are some problem in my logging code.

These are the possible causes that I can think of. Maybe you can help to share some light on the subject.

Logging code for 1st log:
#if HAS_EXTENDED_TELEMETRY
        for (u8 i=0; i < pkt[6]; i++)
            frsky_parse_sport_stream(pkt[7+i]);

        // Log mismatched CRC packets
        static int packet_count = 1;
        u16 crc_calculated = crc(&pkt[3], len-7);
        u16 crc_packet = pkt[len-4] << 8 | pkt[len-3];
        if (crc_calculated != crc_packet) {
            printf("#%d\tpkt[6]: %d,  len: %d", packet_count, pkt[6], len);
            printf("\tCRC Calcuated: %04X, CRC in Packet: %04X\t", crc_calculated, crc_packet);
            for (u8 i=0; i < len; i++)
                printf("%02X ", pkt[i]);
            printf("\n");
        }
        packet_count++;
#endif // HAS_EXTENDED_TELEMETRY

1st Log:
#63	pkt[6]: 6,  len: 17	CRC Calcuated: 5E30, CRC in Packet: 3172	0E FF 59 02 C4 00 06 7E 18 37 00 9A E8 31 72 0B B1 
#92	pkt[6]: 220,  len: 17	CRC Calcuated: FEF9, CRC in Packet: 40AF	0E FF 59 02 BE 00 DC 98 02 88 04 00 00 40 AF FF DF 
#101	pkt[6]: 6,  len: 17	CRC Calcuated: 4CE5, CRC in Packet: 4FD7	0E FF 59 02 BC 03 06 10 12 88 04 00 00 4F D7 07 AE 
#199	pkt[6]: 6,  len: 17	CRC Calcuated: B078, CRC in Packet: AA38	0E FF 59 02 C4 22 06 00 00 06 7E 1B 10 AA 38 0E F4 
#302	pkt[6]: 14,  len: 17	CRC Calcuated: 8AB7, CRC in Packet: E67C	0E FF 59 02 30 31 0E 40 08 48 88 00 00 E6 7C FA B5 
#374	pkt[6]: 6,  len: 17	CRC Calcuated: 45E3, CRC in Packet: 2168	0E FF 59 02 C2 22 06 7E 1B 10 00 04 1E 21 68 FE B0 
#395	pkt[6]: 6,  len: 15	CRC Calcuated: 34A1, CRC in Packet: 1B10	0C FF 59 02 C1 12 06 27 00 00 7E 1B 10 00 B1 
#440	pkt[6]: 6,  len: 17	CRC Calcuated: 9299, CRC in Packet: F720	0E FF 59 02 30 33 06 7E 1B 10 10 07 DC F7 20 0A B2 
#508	pkt[6]: 6,  len: 17	CRC Calcuated: 7D97, CRC in Packet: 9299	0E FF 59 02 30 33 06 7E 18 37 98 2E 9C 92 99 09 B0 
#543	pkt[6]: 6,  len: 17	CRC Calcuated: DB40, CRC in Packet: C08C	0E FF 59 02 C3 31 06 7E 1B 10 20 07 5A C0 8C 09 B1 
#576	pkt[6]: 6,  len: 17	CRC Calcuated: D062, CRC in Packet: D1FB	0E FF 59 02 BF 00 06 00 07 00 00 02 00 D1 FB 00 B1 
#672	pkt[6]: 6,  len: 17	CRC Calcuated: 0BB7, CRC in Packet: 0BBA	0E FF 59 02 C3 32 06 00 00 00 7E 1B 10 0B BA 08 B2 
#713	pkt[6]: 193,  len: 17	CRC Calcuated: A028, CRC in Packet: 0E6A	0E FF 59 00 1A 18 C1 BE 1B 10 00 04 1B 0E 6A 10 DC 
#845	pkt[6]: 0,  len: 17	CRC Calcuated: CB00, CRC in Packet: 7C44	0E FF 59 02 30 82 00 F0 DC 4A 7E 1A 10 7C 44 09 BC 
#857	pkt[6]: 6,  len: 17	CRC Calcuated: 86F7, CRC in Packet: 0F95	0E FF 59 02 C1 13 06 00 00 00 7E 0C DC 0F 95 12 B1 
#923	pkt[6]: 6,  len: 17	CRC Calcuated: FCF9, CRC in Packet: 7766	0E FF 59 02 30 12 06 10 07 DD 01 A6 7B 77 66 07 B2 
#1088	pkt[6]: 103,  len: 17	CRC Calcuated: DEB7, CRC in Packet: FB74	0E FF 59 12 A3 63 67 00 00 00 00 07 00 FB 74 07 F0 
#1098	pkt[6]: 6,  len: 17	CRC Calcuated: 2A81, CRC in Packet: E493	0E FF 59 02 C1 10 06 00 07 00 02 51 40 E4 93 0A B1 
#1163	pkt[6]: 54,  len: 17	CRC Calcuated: 60EB, CRC in Packet: 0D02	0E FF 59 03 E4 F2 36 7E 1B 10 10 02 88 0D 02 FD E0 
#1188	pkt[6]: 6,  len: 17	CRC Calcuated: DC16, CRC in Packet: 3A10	0E FF 59 02 30 12 06 7E 02 BC 26 FB DC 3A 10 10 B3 
#1207	pkt[6]: 7,  len: 17	CRC Calcuated: E0F9, CRC in Packet: 0968	0E FF 59 02 C0 01 07 15 25 A9 FE 1B 10 09 68 00 B3 
#1244	pkt[6]: 6,  len: 17	CRC Calcuated: DC06, CRC in Packet: CF83	0E FF 59 02 70 00 06 FE 1B 30 40 18 C1 CF 83 FD FF 
#1311	pkt[6]: 6,  len: 17	CRC Calcuated: 17C9, CRC in Packet: 8DE3	0E FF 59 02 30 30 06 6F 0B 10 80 04 1A 8D E3 FF B2 
#1344	pkt[6]: 6,  len: 17	CRC Calcuated: F37E, CRC in Packet: 5AB5	0E FF 59 02 BF 00 06 7E 1A 10 00 F1 C1 5A B5 FE B0 
#1347	pkt[6]: 48,  len: 17	CRC Calcuated: C8BD, CRC in Packet: 34C1	0E FF 59 02 30 28 30 6E 12 88 04 00 00 34 C1 0B DB 
#1484	pkt[6]: 3,  len: 17	CRC Calcuated: 6D28, CRC in Packet: 45BB	0E FF 59 02 30 33 03 04 00 00 14 E8 40 45 BB 04 B1 
#1637	pkt[6]: 6,  len: 17	CRC Calcuated: 11D9, CRC in Packet: 7766	0E FF 59 02 CD 22 06 7E 1B 00 00 05 20 77 66 1E B2 
#1790	pkt[6]: 6,  len: 17	CRC Calcuated: C46C, CRC in Packet: C46F	0E FF 59 02 30 23 06 7E 1B 10 20 07 5A C4 6F 1B B0 
#1792	pkt[6]: 6,  len: 17	CRC Calcuated: D5EF, CRC in Packet: CF9D	0E FF 59 02 A7 10 06 7E 1B 10 2F 01 5C CF 9D 1D B0 
#1815	pkt[6]: 6,  len: 17	CRC Calcuated: F970, CRC in Packet: CDBE	0E FF 59 02 C7 00 06 04 00 00 7E 1B 28 CD BE 1B AF 
#1995	pkt[6]: 6,  len: 17	CRC Calcuated: F7A5, CRC in Packet: F344	0E FF 59 02 30 21 06 03 FC 54 96 A8 00 F3 44 01 B1 
#2015	pkt[6]: 6,  len: 17	CRC Calcuated: 202A, CRC in Packet: A300	0E FF 59 02 C6 23 06 00 00 00 7E 1B 11 A3 00 0C B3 
#2121	pkt[6]: 6,  len: 17	CRC Calcuated: 4E81, CRC in Packet: 6001	0E FF 59 02 30 20 06 20 07 5A 00 0C 00 60 01 09 B1 
#2124	pkt[6]: 6,  len: 13	CRC Calcuated: 095C, CRC in Packet: 007E	0A FF 59 02 9D 15 06 A7 00 00 7E D8 C8 
#2208	pkt[6]: 6,  len: 17	CRC Calcuated: 898B, CRC in Packet: CA02	0E FF 59 02 30 12 06 04 00 00 3E 12 78 CA 02 11 B1 
#2274	pkt[6]: 6,  len: 17	CRC Calcuated: 5EE1, CRC in Packet: 6B2C	0E FF 59 02 CA 82 06 20 21 4E 82 80 00 6B 2C 19 B1 
#2380	pkt[6]: 6,  len: 17	CRC Calcuated: 1502, CRC in Packet: 1562	0E FF 59 02 30 00 06 00 00 00 7E 1B 10 15 62 09 B2 
#2620	pkt[6]: 6,  len: 17	CRC Calcuated: 4D46, CRC in Packet: C37E	0E FF 59 02 30 33 06 88 00 04 EA 5A 6C C3 7E 1A B0 
#2904	pkt[6]: 14,  len: 17	CRC Calcuated: 5460, CRC in Packet: B0AD	0E FF 59 02 C9 22 0E 8C CA 70 40 08 0E B0 AD 1A C2 
#2912	pkt[6]: 6,  len: 17	CRC Calcuated: 2F66, CRC in Packet: CF85	0E FF 59 02 BF 22 06 7E 12 00 9A 52 88 CF 85 1B B2 
#2973	pkt[6]: 23,  len: 17	CRC Calcuated: F0C7, CRC in Packet: 0A3E	0E FF 59 02 01 F0 17 CE 1B 10 20 07 5B 0A 3E 1C E3 
#3015	pkt[6]: 6,  len: 17	CRC Calcuated: 8038, CRC in Packet: 83EA	0E FF 59 02 C9 30 06 7E 1B 10 40 0F FB 83 EA 17 B1 
#3092	pkt[6]: 6,  len: 17	CRC Calcuated: F5F5, CRC in Packet: 8FD5	0E FF 59 02 C9 10 06 30 85 0A 20 00 00 8F D5 1D B9 
#3146	pkt[6]: 234,  len: 17	CRC Calcuated: 7766, CRC in Packet: A4B9	0E FF 59 C2 AF AD EA 7E 1B 10 10 07 DD A4 B9 15 E0 
#3344	pkt[6]: 3,  len: 17	CRC Calcuated: 9012, CRC in Packet: 4593	0E FF 59 02 C7 03 03 27 02 00 00 04 1B 45 93 1C BD 
#3862	pkt[6]: 6,  len: 17	CRC Calcuated: 3B72, CRC in Packet: 3B73	0E FF 59 02 CF 30 06 7E 1B 10 20 07 5B 3B 73 21 B2 
#3899	pkt[6]: 6,  len: 17	CRC Calcuated: 2A4A, CRC in Packet: C037	0E FF 59 02 CD 11 06 7E 1B 10 03 11 C2 C0 37 1C B1 
#3966	pkt[6]: 6,  len: 17	CRC Calcuated: F6E7, CRC in Packet: 2F78	0E FF 59 02 CE 30 06 88 80 00 7E 1B 10 2F 78 27 B1 
#4334	pkt[6]: 7,  len: 18	CRC Calcuated: 6D8D, CRC in Packet: 7255	0F FF 59 02 C2 11 07 30 A7 DD FF FF FF 6B 72 55 CC D0 
#4345	pkt[6]: 6,  len: 17	CRC Calcuated: BC12, CRC in Packet: BC13	0E FF 59 02 30 01 06 00 00 00 7E 1B 10 BC 13 0B B2 
#4543	pkt[6]: 6,  len: 17	CRC Calcuated: 18EF, CRC in Packet: 19EF	0E FF 59 02 C3 13 06 7E 1B 10 10 02 88 19 EF 04 AF 
#4544	pkt[6]: 0,  len: 17	CRC Calcuated: 09B9, CRC in Packet: 2F08	0E FF 59 02 30 88 00 71 00 01 50 02 88 2F 08 04 B7 
#4748	pkt[6]: 0,  len: 17	CRC Calcuated: 49E9, CRC in Packet: D1DB	0E FF 59 02 C1 02 00 C8 52 00 40 08 40 D1 DB 01 C0 
#4749	pkt[6]: 0,  len: 18	CRC Calcuated: C900, CRC in Packet: C9D5	0F FF 59 02 30 88 00 7E 1B 10 00 07 00 F2 C9 D5 F2 B0

Logging code for 2nd log. It's basically the same as the first. Just that it only logs packets with length not equals to 17.
#if HAS_EXTENDED_TELEMETRY
        for (u8 i=0; i < pkt[6]; i++)
            frsky_parse_sport_stream(pkt[7+i]);

        // Log packet len != 17
        static int packet_count = 1;
        u16 crc_calculated = crc(&pkt[3], len-7);
        u16 crc_packet = pkt[len-4] << 8 | pkt[len-3];
        if (len != 17) {
            printf("#%d\tpkt[6]: %d,  len: %d", packet_count, pkt[6], len);
            printf("\tCRC Calcuated: %04X, CRC in Packet: %04X\t", crc_calculated, crc_packet);
            for (u8 i=0; i < len; i++)
                printf("%02X ", pkt[i]);
            printf("\n");
        }
        packet_count++;
#endif // HAS_EXTENDED_TELEMETRY

2nd Log:
#3887	pkt[6]: 6,  len: 13	CRC Calcuated: 4281, CRC in Packet: 1040	0A FF 59 00 B4 11 06 7E 1B 10 40 DC B8 
#3977	pkt[6]: 0,  len: 9	CRC Calcuated: 1118, CRC in Packet: 8800	06 FF 59 02 10 88 00 D9 B6 
#4001	pkt[6]: 6,  len: 9	CRC Calcuated: 301A, CRC in Packet: 2206	06 FF 59 02 30 22 06 DB B0 
#5726	pkt[6]: 6,  len: 15	CRC Calcuated: 0A1A, CRC in Packet: 1B10	0C FF 59 02 30 33 06 00 00 00 7E 1B 10 DA B0 
#6732	pkt[6]: 3,  len: 18	CRC Calcuated: 5742, CRC in Packet: 0855	0F FF 59 02 30 11 03 47 90 08 40 08 72 23 08 55 F8 B7 
#7299	pkt[6]: 6,  len: 13	CRC Calcuated: AE48, CRC in Packet: 1000	0A FF 59 02 30 22 06 7E 1B 10 00 F9 B4 
#7513	pkt[6]: 6,  len: 18	CRC Calcuated: B504, CRC in Packet: F7D5	0F FF 59 02 30 23 06 7E 1B 10 20 07 59 B6 F7 D5 ED EA 
#7540	pkt[6]: 2,  len: 13	CRC Calcuated: F0ED, CRC in Packet: D000	0A FF 59 02 30 11 02 03 B1 D0 00 EB C7 
#7787	pkt[6]: 6,  len: 9	CRC Calcuated: 301A, CRC in Packet: 3306	06 FF 59 02 30 33 06 F9 AE 
#8414	pkt[6]: 0,  len: 9	CRC Calcuated: B412, CRC in Packet: 0000	06 FF 59 02 B0 00 00 D8 AD 
#8664	pkt[6]: 6,  len: 9	CRC Calcuated: F33E, CRC in Packet: 3306	06 FF 59 02 A5 33 06 ED B6 
#9784	pkt[6]: 158,  len: 7	CRC Calcuated: 0000, CRC in Packet: 02B5	04 FF 59 02 B5 F2 9E 
#10671	pkt[6]: 3,  len: 18	CRC Calcuated: D700, CRC in Packet: D7D5	0F FF 59 02 30 11 03 00 00 00 20 07 59 98 D7 D5 D0 B1
Last edit: 27 Sep 2016 15:46 by petsmith.

Please Log in or Create an account to join the conversation.

More
27 Sep 2016 15:55 - 27 Sep 2016 15:57 #54337 by midelic
Replied by midelic on topic New FrSkyX protocol
Not have too much time.I'm busy.
but the crc calculation is from pkt[3] to pkt[12];;that means len-5 not len-7.
I think dropout is from pkt[6],,the for loop works "forever" on high value and disrupt the reception timing
You can introduce a check on pkt[0]==0x0E(the pkt[0]must be 0x0e) and(crc is you want) later on pkt[6]<7.I know is not elegant but as I said have no much time.

regards,
Last edit: 27 Sep 2016 15:57 by midelic.

Please Log in or Create an account to join the conversation.

More
27 Sep 2016 16:11 #54339 by petsmith
Replied by petsmith on topic New FrSkyX protocol

midelic wrote: Not have too much time.I'm busy.
but the crc calculation is from pkt[3] to pkt[12];;that means len-5 not len-7.

The CRC calculation is from pkt[3] to pkt[12], that is 10 bytes. len is 17, len-5 will be 12. That is incorrect. On the other hand, len-7 is 10. Can you check your calculation again?

I think dropout is from pkt[6],,the for loop works "forever" on high value and disrupt the reception timing

That is correct. That had been solved with the checking that I added in a few days back.

You can introduce a check on pkt[0]==0x0E(the pkt[0]must be 0x0e) and(crc is you want) later on pkt[6]<7.I know is not elegant but as I said have no much time.

Maybe you can help to take a look again when you've more time. Thanks!

Please Log in or Create an account to join the conversation.

More
28 Sep 2016 03:58 #54350 by hexfet
Replied by hexfet on topic New FrSkyX protocol
Trying to make a long explanation seemed confusing but these items may answer some questions.
  • The X-series receivers seem to always send a telemetry packet 15 bytes long, which is why pkt[0] is expected to be 0x0e.
  • With PKTCTRL1 APPEND_STATUS bit set the CC2500 in the tx appends the RSSI and LQI bytes to the packet, which is why len is expected to be 17.
  • In the D16 protocol the CC2500 integrated CRC support is disabled. The CRC in pkt[len-4] and pkt[len-3] is calculated in software as part of the D16 protocol. The current frskyx test build includes a check for this CRC being correct, while the nightly does not have this check. This CRC does not appear in the OpenTX code (it must be handled by the XJT module).
  • The SPORT payloads (aka extended telemetry) also have a checksum (different algorithm) which is not yet implemented in Deviation. It is implemented in OpenTX in checkSportPacket().

I'm curious why you would have errors at all at close range. Not sure what would cause short or long packets at the rates you found. What is the WiFi environment like in your test setup?

I also wonder about telemetry pkt[3] - is it a version number that may change for different packet types? Should we check it before assuming the format of the rest of the packet? Always unanswered questions remaining when reverse engineering.

petsmith, if you wouldn't mind there is one change I'd like to see tested. Does the telemetry packet error rate change if you modify AGCCTRL2 to be 0x03 instead of 0x43? And can you still bind with this value?

Please Log in or Create an account to join the conversation.

More
28 Sep 2016 06:52 #54354 by Fernandez
Replied by Fernandez on topic New FrSkyX protocol
Thanks guys for great work here!

Packet loss on close range could it be due to swamping of the Rx stages? The LNA stage get too much power and over steering the input?
It won't work when too close, I believe is also common for Frsky.

Please Log in or Create an account to join the conversation.

More
28 Sep 2016 12:51 #54368 by Cereal_Killer
Replied by Cereal_Killer on topic New FrSkyX protocol

Fernandez wrote: Packet loss on close range could it be due to swamping of the Rx stages? The LNA stage get too much power and over steering the input?
It won't work when too close, I believe is also common for Frsky.


Ding ding, exactly... though very rare I do experience this with my X9E / X4R's. Especially when SWR is higher (verified in logs). Though again it's very rare, maybe once a week if that, control is still good I just get a "telemetry lost" warning for one second when close by. Again it's highly dependent on SWR and also (though not something that can be logged) only seems to happen when it's in a position to receive the best signal (rx antennas parallel to tx), note rssi has always been quite high when these blips happen.
Taranis X9E | DEVO 10 | Devo U7E | Taranis Q7

What I do in real life: rivergoequestrian.com/

Please Log in or Create an account to join the conversation.

More
28 Sep 2016 15:57 #54374 by Alexandro
Replied by Alexandro on topic New FrSkyX protocol
Same on Taranis. Allways near the Tx. Go arround 5 to 10 Meters away from the Plane and all is good. On Bench with Deviation i allways have to switch to the lower Power setting at the tx.But on flight no Problems with Frsky. May be the Range of the X Version is a little bit better. But it is the same at Taranis, here is the same with the X Version Range.It is a little better as the D Version (all Tests with the Latest Int. Taranis Tx Modul and RX Firmware)
Greetings Alex

Please Log in or Create an account to join the conversation.

More
28 Sep 2016 17:15 #54375 by petsmith
Replied by petsmith on topic New FrSkyX protocol
That many errors from previous tests only occurred when the Transmitter & Receiver were separated by a 12" concrete wall. I guess it weakened the signal and resulted in lot of errors. If there was no wall in between and the distance was 10 feet away, errors would be much less (close to 0). The place where I did the testing has many WiFi routers around, they would have some effect too. However, I don't think I've encountered the swamping issue when they're 10 feet apart.

@hexfet, thanks a lot for the detailed post. That explained a lot. As for setting AGCCTRL2 to 0x03, it would still bind and worked fine. I've done some tests with AGCCTRL2 set to 0x43 & 0x03 with a 12" concrete wall in between and also without. The transmit power was set to 100mW. For each test case, I ran it 3 times. Each test run was done by receiving 30000 packets and measuring number of packets with CRC errors. Previously, the log statements were inside the "if (pkt[1] == (fixed_id & off)…" block, which means packets that didn't match the criteria wouldn't be counted. Now, the log statements are moved outside the if block, so that every single packets are counted.

Test Case #1
AGCCTRL2 = 0x43, Transmitter & Receiver 10 feet apart, no obstacles in between
#1: 1/30000 (0.003%)
#2: 2/30000 (0.007%)
#3: 0/30000 (0%)

Test Case #2:
AGCCTRL2 = 0x03, Transmitter & Receiver 10 feet apart, no obstacles in between
#1: 0/30000 (0%)
#2: 2/30000 (0.007%)
#3: 0/30000 (0%)

Test Case #3:
AGCCTRL2 = 0x43, Transmitter & Receiver 10 feet apart, a concrete wall in between
#1: 301/30000 (1.03%)
#2: 276/30000 (0.92%)
#3: 368/30000 (1.23%)

Test Case #4:
AGCCTRL2 = 0x03, Transmitter & Receiver 10 feet apart, a concrete wall in between
#1: 342/30000 (1.14%)
#2: 331/30000 (1.1%)
#3: 237/30000 (0.79%)

During the test, I received a packet with len=5, even smaller than previous time. Base on our current implementation, these short packets will have unpredictable result, like doing crc(&pkt[3], len-7) and len-7 would become 5-7. Since the packet length are always 17, I strongly suggest that we add a length check like this in the beginning.
        if (len == 17
	    && pkt[1] == (fixed_id & 0xff)
            && pkt[2] == (fixed_id >> 8)
            && pkt[0] == len-3
            && crc(&pkt[3], len-7) == (pkt[len-4] << 8 | pkt[len-3])

Please Log in or Create an account to join the conversation.

More
29 Sep 2016 15:41 #54397 by hexfet
Replied by hexfet on topic New FrSkyX protocol
I've updated the test build to only accept telemetry packets of length 17. If we find cases with valid packets of other lengths we can make a change then.

Tried adding a crc check for the sport packets but the telemetry test data I have wasn't passing the test. Need to go back to the spi captures and make sure I'm using the right data.

The AGCCTRL value of 3 should improve telemetry range but doesn't seem to make much difference in this test. Want to try in an open field before making a conclusion. Does your concrete wall contain rebar? Maybe the errors are more due to interference than attenuation. But 3 is the default value so maybe Frsky had a reason for setting it to 0x43...

Please Log in or Create an account to join the conversation.

More
29 Sep 2016 20:23 - 29 Sep 2016 20:33 #54407 by Cereal_Killer
Replied by Cereal_Killer on topic New FrSkyX protocol
Hi, here's a log from today, it's only about 5min of logging but I flew 7 packs (so about 50 minutes) in all today and the only one drop-out I had was when I flew below the horizon and lost video then 1sec later RC (but duh...) In other words it did the best I've ever seen out of the devo / X4R combo!

Dont know if it's anything you're even working on still or if you've got it buttoned up but here it is anyway. Hopefully it helps, if you'd like more of a specific build let me know which one...


Devo10 [hexfet]frskyx_drop -572bda9
X4R
Cleanflight

Logged:
TAE
RSSI
Batt
Altitude

1drv.ms/u/s!ApynWlfDdSgy-giH0kMIvHc5ScER



Edit:
The only issues were telemetry data freakouts, I did get a few RSSI warnings at times I didnt crash but not sure it any of them are in the log and my X9E did the same thing 30 minutes before in the same spots at the far corners of my field (foliage is extremely wet after 36 hours of heavy rains, both RC and 5G8 video was heavily effected when flying behind trees that dont usually present an issue). Also note my baro is having some airflow issues but is never more than a few hundred meters off when using Taranis, here it's crazy (like -5000m to +6500m), battery and RSSI both have random blips of corrupt data too.
Should I try your other build to take care of telemetry? Should [hexfet]frsky_telem and/or [hexfet]yd717_noack take care of the telemetry issues and include the dropout fixes?
Taranis X9E | DEVO 10 | Devo U7E | Taranis Q7

What I do in real life: rivergoequestrian.com/
Last edit: 29 Sep 2016 20:33 by Cereal_Killer.

Please Log in or Create an account to join the conversation.

More
30 Sep 2016 05:20 #54419 by petsmith
Replied by petsmith on topic New FrSkyX protocol
@hexfet, I live in a high rise and it's a thick concrete wall that contains rebar. The AGCCTRL with 0x03 didn't make much difference in my case, could be due to my short distance of testing. I'm unable to test for long distance due to the field that I used to fly is quite small, only about 100m. Maybe others can help to test it for longer range.

I've tested the latest build 543f89d and it works fine, no dropouts for my usual wall testing. The telemetry corruption is also gone.

@Cereal_Killer, to my understanding, frsky_telem & yd717_noack are old builds and don't have the dropout or other recent fixes. The latest fix is in frskyx_drop and the one that you used is 1 version behind. However, I don't see the new one has any effect on Telemetry compared to the one that you tested.

Please Log in or Create an account to join the conversation.

More
30 Sep 2016 12:23 #54435 by Cereal_Killer
Replied by Cereal_Killer on topic New FrSkyX protocol
Where can I get the newest? I had just downloaded and flashed the one I did (572bda9) two nights ago.
Taranis X9E | DEVO 10 | Devo U7E | Taranis Q7

What I do in real life: rivergoequestrian.com/

Please Log in or Create an account to join the conversation.

  1. Forum
  3. Development
  5. Protocol Development
  7. New FrSkyX protocol
Time to create page: 0.477 seconds
Powered by Kunena Forum
Force desktop display