FlySky Ibus telemetry support #2415

unitware · 2016-09-19T16:43:54Z

This is an enhanced version of @CraigJPerry pull request #1723 dealing with issue
#1125

My contributions:

Rebased to current master
Unit tests
Discards characters that were echoed back on tx creating a loop.
Documentation
Possible support for daisy chained i-bus sensors (experimental due to lack of hardware)
Configurable Vbatt/Cell-voltage to make it easier to use the tranciever voltage restriction to 10 Volts.
Build time define TELEMETRY_IBUS to include code or not

I have tested the code in my quad but not flown much with it since I have barely set up my PID:s. I'd really like someone more experienced in flying to take a test run to see if stability or other things have been affected.

Credits to @CraigJPerry et.al.

Update:
@ledvinap has given lots of good review comments which are implemented except for the frame detection.

@cj1324 has done some bench testing with different receivers, added to documentation.

unitware · 2016-09-19T16:45:35Z

Enable with cli
serial 1 1024 115200 57600 115200 115200

cj1324 · 2016-09-19T23:14:03Z

👍

ledvinap

Nice code, I just commented few details.
Only problem I see is frame sync detection, it does work, but better solutions probably exist.

I did not check unittests closely, but they look fine

ledvinap · 2016-09-20T09:14:42Z

src/main/telemetry/ibus.c

+
+static uint8_t ibusReceiveBuffer[IBUS_RX_BUF_LEN] = { 0x0 };
+
+static uint16_t calculateChecksum(uint8_t ibusPacket[static IBUS_CHECKSUM_SIZE], size_t packetLength) {


static does not make any sense here (I am surprised it's even syntactically correct)
And ibus packet length is not IBUS_CHECKSUM_SIZE.
const uint8_t *ibusPacket is normal way to pass array in C

Static global variables are not visible outside of the C file they are defined in

Sorry, did not know this part of C:
http://stackoverflow.com/questions/3430315/what-is-the-purpose-of-static-keyword-in-array-parameter-of-function-like-char

..and my reply was not for the static inside the array index. I'm also sruprised it was there. Anyway it's gone now since I updated the code with the other review comments.

Well ... minimum size check is nice feature, but it is not used in CF yet ...

ledvinap · 2016-09-20T09:17:28Z

src/main/telemetry/ibus.c

+    return checksum;
+}
+
+static bool isChecksumOk(uint8_t ibusPacket[static IBUS_CHECKSUM_SIZE], size_t packetLength, uint16_t calcuatedChecksum) {


Consider calculating checksum inside this function - this should check packet correctness, caller does not need to know details

ledvinap · 2016-09-20T09:20:32Z

src/main/telemetry/ibus.c

+    }
+}
+
+static void sendIbusCommand(ibusAddress_t address) {


This is discover reply, not command

ledvinap · 2016-09-20T09:21:24Z

src/main/telemetry/ibus.c

+
+static void sendIbusCommand(ibusAddress_t address) {
+    uint8_t sendBuffer[] = { 0x04, IBUS_COMMAND_DISCOVER_SENSOR | address, 0x00, 0x00 };
+    transmitIbusPacket(sendBuffer, sizeof sendBuffer);


in CF, sizeof is used with function syntax, not operator: sizeof(type)

ledvinap · 2016-09-20T09:22:56Z

src/main/telemetry/ibus.c

+    IBUS_SENSOR_TYPE_EXTERNAL_VOLTAGE = 0x03
+} ibusSensorType_e;
+
+static const uint8_t SENSOR_ADDRESS_TYPE_LOOKUP[] = {


CAPITALS are used (only) for constants.

ledvinap · 2016-09-20T09:31:35Z

src/main/telemetry/ibus.c

+    case IBUS_SENSOR_TYPE_TEMPERATURE:
+        {
+            #ifdef BARO
+                float temperature = (baroTemperature + 50) / 100.f;


This looks like integer rounding - but it will not work for floats (and will work incorrectly for negative values)

If you want to round the value, do so explicitly (roundf()) after final scaling.

ledvinap · 2016-09-20T09:31:37Z

src/main/telemetry/ibus.c

+            #else
+                float temperature = telemTemperature1 / 10.f;
+            #endif
+            sendIbusMeasurement(address, (uint16_t) ((temperature + 40)*10));


Valu is converted to degrees C above and then back to decidegrees here. With double conversion avoided, all calculations can be integer based.

ledvinap · 2016-09-20T09:34:06Z

src/main/telemetry/ibus.c

+    }
+
+    if ((returnAddress >= ibusBaseAddress) &&
+        (ibusAddress_t)(returnAddress - ibusBaseAddress) < sizeof SENSOR_ADDRESS_TYPE_LOOKUP) {


better use ARRAYLEN(SENSOR_ADDRESS_TYPE_LOOKUP), it will handle larger types corectly

I guess you mean something like:

#define ARRAYLEN(array) (sizeof(array)/sizeof(array[0]))

Is that available in c? or defined somewhere in cleanflight?

https://github.com/cleanflight/cleanflight/blob/master/src/main/common/utils.h#L23

uups, did a file search on the wrong repo, thanks

ledvinap · 2016-09-20T09:38:37Z

src/main/telemetry/ibus.c

+}
+
+static void pushOntoTail(uint8_t buffer[IBUS_MIN_LEN], size_t bufferLength, uint8_t value) {
+    for (size_t i = 0; i < bufferLength - 1; i++) {


memmove should be faster

ledvinap · 2016-09-20T09:43:11Z

src/main/telemetry/ibus.c

+
+    while (serialRxBytesWaiting(ibusSerialPort) > 0) {
+        uint8_t c = serialRead(ibusSerialPort);
+        pushOntoTail(ibusReceiveBuffer, IBUS_RX_BUF_LEN, c);


This code is quite fragile (it will be hard to support longer request packet) and is a bit suboptimal (each packet is tested four times / processed data are scanned again)
Interpacket gap delay be better (SBUS and others use that) ..

I agree that its not perfect, but I'll leave it be for now.
The packets are maximum 4 bytes so the impact is not that big compared to the time I'm willing to put into this at the moment.

In the future it would be more interesting to see if ibus serial rx and telemetry could coexist on the same serial port with some added hardware (a resistor and diode at the least).

ledvinap · 2016-09-20T11:52:48Z

src/main/telemetry/ibus.c

            #ifdef BARO
-                float temperature = (baroTemperature + 50) / 100.f;
+                uint16_t temperature = (baroTemperature + 50) / 10;


(baroTemperature + 5) / 10 or just baroTemperature / 10
And type is int16_t (or even better int, gcc will generate better code)

It was probably used to round correctly (2160 centidegrees to 22 degrees). But it will return invalid results for negative values (division rounds toward zero). 0.1C is much smaller that sensor accuracy, it's OK to ignore rounding ..
This code will round correctly, but is a bit of overkill:

temperature = baroTemperature / 5; // divide in two steps temperature = (temperature + 1) >> 2; // left shift rounds toward negative infinity

This logic is just copied from the file: src/main/telemetry/frsky.c
hope that its ok now in the latest commit. I'd love if anyone could try it for real now after all changes.

Thanks for the review by the way!

Frsky code rounds the value, it works fine for non-negative temperatures. But added value has to be half the divisor.
baroTemperature / 10 should do in iBus case.

ledvinap · 2016-09-21T11:30:00Z

src/main/telemetry/ibus.c

+
+    case IBUS_SENSOR_TYPE_TEMPERATURE:
+        #ifdef BARO
+            value = (baroTemperature + 50) / 10;


value = baroTemperature / 10;

With your version reading will be 0.5C too high

@mojocorp Any input on this? It's your implementation from the beginning? (according to a comment in the old pull request)

@unitware It's a copy/paste from the frsky telemetry. No idea where the +50 is coming from.
As far as I remember the git history doesn't help at all and there is no mention anywhere about the units (I assume degrees centigrades). The temperature should be sent as DECIGRADES to the ibus telemetry, that's why there is a division by 10.
I've fixed the gyro temperature reading for the naze32 (MPU6500) and my pull request was merged last month. Maybe using the gyro temp should be enough.
Anyway, the temperature coming from the gyro (MPU6500) is in degree centigrades. I have no idea for other gyro (no units anywhere).

ok, so now I am confused. I am removing the 0.5 degree offset because its probably a manual fix to deal with die temperature etc.

My best effort is now something like this.

case IBUS_SENSOR_TYPE_TEMPERATURE: #ifdef BARO value = baroTemperature / 10; #else value = telemTemperature1 * 10; #endif sendIbusMeasurement(address, value + IBUS_TEMPERATURE_OFFSET); break;

Is it then correct to assume that:

baroTemperature is in centidegrees / 10 -> decidegrees.

telemTemperature1 is in degrees * 10 -> decidegrees.

@mojocorp you said that gyro temp is in centidegrees, did you mean baroTemperature?

The 0.5C offset is because original code did compute value in degrees. Integer division in C is rounding positive numbers down (190/100 == 1), with this offset resulting (positive) value is correct. Please read my earlier comments ...

ok, thanks. I did not get that at that time (even if I read it) :)

cj1324 · 2016-09-23T15:07:34Z

Recommendation documentation updates:

Supported RX device

FS-iA4B (http://www.flysky-cn.com/products_detail/productId=46.html)
- Ibus support (ok.)
- Ibus telemetry support (ok.)
- ibus protocol 10ch
- PPM protocol 8ch
- Parallel PWM 4ch
- size: 35.4 * 29.6 * 13 (mm)
- Weight: 10g
FS-iA6B (http://www.flysky-cn.com/products_detail/productId=51.html)
- Ibus support (ok.)
- Ibus telemetry support (ok.)
- ibus protocol 10ch
- PPM protocol 8ch
- Parallel PWM 6ch
- size: 47 * 26.2 * 15 (mm)
- Weight: 14.9g
FS-iA10B(http://www.flysky-cn.com/products_detail/productId=52.html)
- Ibus support (ok.)
- Ibus telemetry support (ok.)
- ibus protocol 10ch
- PPM protocol 8ch
- Parallel PWM 10ch
- size: 51 * 34 * 15 (mm)
- Weight: 17.6g
FS-iA10 (http://www.flysky-cn.com/products_detail/productId=53.html)
- Ibus support (ok.)
- Ibus telemetry support (to be confirmed)
- ibus protocol 10ch
- PPM protocol 8ch (to be confirmed)
- Parallel PWM 10ch
- size: 47 * 33.1 * 14.7 (mm)
- Weight: 19.3g

unitware · 2016-09-23T16:00:48Z

Thanks, what about PPM support? How many channels?

Skickat från min iPhone

23 sep. 2016 kl. 17:07 skrev 寒晨 notifications@github.com:

Recommendation documentation updates:

Supported RX device

FS-iA4B
Ibus support (ok.)
Ibus telemetry support (ok.)
ibus protocol 10ch
pwm 4ch
size: 35.4 * 29.6 * 13 (cm)
Weight: 10g
FS-iA6B
Ibus support (ok.)
Ibus telemetry support (ok.)
ibus protocol 10ch
pwm 6ch
size: 47 * 26.2 * 15 (mm)
Weight: 14.9g
FS-iA10B

Ibus support (ok.)
Ibus telemetry support (ok.)
ibus protocol 10ch
pwm 10ch
size: 47 * 33.1 * 14.7 (mm)
Weight: 19.3g
FS-iA10

Ibus support (to be confirmed)
Ibus telemetry support (to be confirmed)
ibus protocol 10ch
pwm 10ch
size: 47 * 33.1 * 14.7 (mm)
Weight: 19.3g
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

cj1324 · 2016-09-24T04:49:30Z

@unitware already updated.

cj1324 · 2016-09-27T13:42:19Z

@unitware Found BUG in FS-iA4B , Bind may be lost . (Not recommended)

unitware · 2016-09-27T14:48:31Z

@cj1324 Did you run the saleae on that rx as well? Thinking is it a bug in the rx or in the our code? Does it work the same way as the others?

cj1324 · 2016-09-27T14:59:37Z

@unitware
Official reply: They have not tested Ibus protocol compatibility. FS-iA4B recommended with a car or boat use.

Suggested: return FS-iA4B

In addition:
They are ready to release the new receiver FS-X6B
FS-X6B.pdf

unitware · 2016-09-27T15:17:22Z

Ok, the new rx is without ibus telemetry it seems.

Skickat från min iPhone

27 sep. 2016 kl. 17:06 skrev 寒晨 notifications@github.com:

@unitware
Official reply: They have not tested Ibus protocol compatibility. FS-iA4B recommended with a car or boat use.

Suggested: return FS-iA4B

In addition:
They are ready to release the new receiver FS-X6B
FS-X6B.pdf

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

unitware · 2016-10-05T12:07:57Z

@hydra and other admins, Is there any chance of getting a merge before the conflicts start to build up?

ledvinap

IMO this is ready to merge

ledvinap · 2016-10-05T12:35:12Z

docs/Telemetry.md

+    \_______/
+```
+
+It should be possible to daisy chain multiple sensors with ibus. This is implemented but not tested because i don't have one of the sensors to test with.


FC must be last in the chain, it may be mentioned here

ledvinap · 2016-10-05T13:09:22Z

src/main/telemetry/ibus.c

+    IBUS_SENSOR_TYPE_EXTERNAL_VOLTAGE = 0x03
+} ibusSensorType_e;
+
+static const uint8_t sensorAddressTypeLookup[] = {


Maybe comment that Address n is for single sensor case (not chained / chained only with RX internal voltage)
Or change it to A+0 / A+1 / A+2 when placed at position A in chain
And IBUS_SENSOR_TYPE_INTERNAL_VOLTAGE is not sent by this sensor(FC), so it should not be here

ledvinap · 2016-10-05T13:37:43Z

src/main/telemetry/telemetry.c

@@ -69,6 +70,9 @@ void telemetryInit(void)
    initSmartPortTelemetry();
    initLtmTelemetry();
    initMAVLinkTelemetry();
+    #ifdef TELEMETRY_IBUS


Indenting is inconsistent with rest of (or larger part of) code here - #directive should be in leftmost column / use # directive to nest #ifs etc ..

Conditional code is normally indented:
initMAVLinkTelemetry();

#ifdef TELEMETRY_IBUS

Write Preview

Indenting is wrong here - #directive should be in leftmost column / use # directive to nest #ifs etc ..

Conditional code is normally indented:

initMAVLinkTelemetry(); #ifdef TELEMETRY_IBUS initIbusTelemetry(); #endif telemetryCheckState();

unitware · 2016-10-12T17:59:52Z

Ehm, I got my own logic analyzer today and hooked it up. It seems like I need to filter out the stuff that the FC is transmitting since it will echo back again. The packets are the same in some cases so after the first sensor discovery packet the bus will flood with them. Actually it is strange that it works as well as it does.

I'll have a look at it tonight

So do not merge just yet..

Update:
The code is now updated to handle the local echo, and also increases the task frequency so that ibus responses are given in a decent timeframe. The increase of the task frequency is done only if iBus telemetry is runtime enabled.

I also did a rebase to the current master since there were conflicts.

hydra · 2016-10-12T20:43:15Z

please rebase again i just pushed a few changes and merged some PR's.

ledvinap · 2016-10-12T21:30:36Z

IMO outboundBytesToIgnoreOnRxCount is far too fragile.
There are other possibilities:

disable RX before replying to packet (driver modification probably required)
modify singlewire (SERIAL_BIDIR) mode to handle this - listening to self makes little sense, even in other drivers(needs testing). If someone needs it (collision detection?), implement flag to enable it explicitly. I am quite surprised it does not work this way ...
discard Rx buffer after respondToIbusRequest

unitware · 2016-10-13T10:17:08Z

@ledvinap thanks for checking the code

I thought of your suggested alternatives but went for the current one since it felt more safe for me in the respect that it does not affect the drivers - thus not destroying any other functionality. I'm not that familiar with the full codebase to do that safely and with confidence, the current changes could be made within the safety harness of the unit tests.

If you want then please elaborate why you think the counter solution being fragile, it's always interesting to get feedback!

If you or anyone else wants to have a go at doing it differently please do so and either create a pull request towards my ibus-telemetry branch or to cleanflight if this PR has been merged. I can do some testing on it if need be.

A side note: If you do and start thinking of inter packet timeout as a synchronization then take into account that a possible improvement to this is to combine flysky serial RX with the telemetry on the same serial port, it looks like it could be done with some hardware adaption. That's probably another PR, but the gap in between packets will e much smaller, in the vicinity of 1ms.

ledvinap · 2016-10-13T11:46:59Z

@unitware :
Worst possibility is that characters are not echoed back (driver update, different mode etc). Then part of packets would be ignored, probably leading to hard to find bugs/suboptimal performance.
Other sync problems may appear (spurious/lost chars), but checksum should handle them.

Discarding all received chars just after respondToIbusRequest should be quite clean - you don't want to reply to stale request anyway ..

unitware · 2016-10-13T12:08:34Z

@ledvinap :
I think that discarding all received chars after respondToIbusRequest is not enough, we do not know that they hav been sent at that time, they are only placed in the serial transmit buffer (or driver). In that case we need to wait for empty transmit buffer at the driver before discarding. Is this what you mean (waitForSerialPortToFinishTransmitting()), is that ok to use in the telemetry code? In that case it would be a rather easy fix.

ledvinap · 2016-10-13T12:16:49Z

@unitware : Sorry, I overlooked the TX buffering problem ...

ledvinap · 2016-10-13T12:17:32Z

You solution is probably only reasonable given current serial driver state ...

hydra · 2016-10-13T22:52:22Z

so, the lack of flight testing scares me! Has anyone actually flown this code?

hydra · 2016-10-20T14:56:35Z

I will merge this code now, I want to get a new release candidate ready today for people to test this weekend. Please provide feedback on this PR once you've tested it and it was OK, if not OK please raise new issues and PR's as appropriate.

rootik · 2016-10-25T21:50:33Z

~~It seems, it does not work with software serial.~~
Update: it works with SoftSerial!
Just like with SmartPort SoftSerial you need to bridge TX and RX together.

danarrib · 2016-10-25T22:47:32Z

I have a SP Racing F3 and a FS-i6 and FS-iA6b hardware. I'm using IBUS on UART3 (just RX pin is connected to IBUS Signal on the FS-iA6b).

How can I test this?
I have to bridge RX and TX together with IBUS pin? (only one wire from RX pin for both pins on FC?)
What I need to enable in the FC configuration?

rootik · 2016-10-26T05:49:55Z

danarrib, you need to connect TX pin of UART to I-Bus sensor pin of FS-iA6B, like doc says https://github.com/cleanflight/cleanflight/blob/master/docs/Telemetry.md

rootik · 2016-10-26T06:10:24Z

danarrib, connect SP Racing F3 UART TX pin to iBus sensor input pin of iA6B

unitware · 2016-10-26T06:44:17Z

@rootik cool pictures, maybe do a PR with updated documentation?

Thanks for testing, remember that soft serial is not guaranteed to work with 115200 baud rate (unless I'm mistaken)

rootik · 2016-10-26T06:57:37Z

@unitware, I have not yet had the opportunity to test it in flight, but it definitely works on bench.
My setup: SP Racing F3 Acro flight controller, iA6B RX connected to FC (UART2) via iBus serial, minimOSD connected to UART3, iBus sensor input of RX connected to SoftSerial1 of FC (TX and RX pins bind together).

rootik · 2016-10-26T08:10:48Z

By the way, all possible sensors types supported by FS-i6 TX are: Mot Tem ExtV Odo1 Odo2 Spe and reserved - IntV Tx.V Err

0x00 is for "IntV", internal voltage
0x01 is for "Tem", temperature
0x02 is for "Mot", RPM
0x03 is for "ExtV", external voltage
0x7C is for "Odo1", odometer 1
0x7D is for "Odo2", odometer 2
0x7E is for "Spe", speed
0x7F is for "Tx.V", TX battery voltage
0xFE is for "Err", RSSI rate

danarrib · 2016-10-26T12:02:25Z

Ok @rootik . Thanks for the information.
So, there's a way that I can use only one UART port for the FS-ia6b? Like:
FS-IA6B iBus Output ---- UART3 RX
FS-IA6B iBus Input ---- UART3 TX

Can I enable "Telemetry" and "Serial RX" on same port in the ports configuration? Or it must be on separate ports?

rootik · 2016-10-26T12:05:05Z

@danarrib, no, you can't. It must be separate ports.

danarrib · 2016-10-26T12:35:32Z

Ok, Thanks. I'll test it on the weekend. Can someone please provide a .hex file for SP Racing F3 Deluxe?

rootik · 2016-10-26T12:49:03Z

@danarrib, choose SPRACINGF3 board in Cleanflight Configurator tool, select Show unstable releases, select v1.14.0-RC2 and press Load firmware (online). Then follow Recovery/Lost communication section in Firmware flashing tab.
Or alternatively you can download it from here.

rootik · 2016-10-26T18:17:04Z

I have set battery constraints in TX and tested alarm while discharging LiPo. It works flawlessly.

inode- · 2016-10-29T16:04:16Z

Currently testing the ibus feature under naze32 (on softserial).

I'm getting these sensor available and working:

IntV 1
Temp 3
ExtV 2
Tx.V 1
Mot 4
Err 1

I'm seeing that "Mot 4" sensor sometimes it disappear then it appear again. The others are stable. I got two question for you:

do you think it's possible to get the barometer data on one of the unused sensor (for example odometer2)
it will be possible to select which telemetry transmit and which no? Using the softserial I would like to drop much data as possible.

Thank you.

inode

unitware · 2016-10-29T18:56:28Z

@iNode Hi, and thanks for testing!

I have not tested ibus telemetry on softserial myself. The baudrate is high and there is a requirement to respond within a certain short time (unclear how long time that is, but within the range of a ms I think). This might cause the disappearing sensor.

To answer your questions:

its perfectly possible to implement barometer data and map it to a free sensor slot.
likewise it's possible to create a configuration selection on what sensors to send and not.

Unless you are willing to do the coding yourself, then open an issue to get some more people on the idea and discuss possible solutions, and maybe someone who is willing to implement it. I'm sorry to say that I will not find the time to do so in the coming month at least.

inode- · 2016-10-30T09:38:49Z

@unitware on your tests the receiver ask via the ibus only the IDs that he know or ask all the IDs from 0x00 to 0x7F? I'm asking you that to understand better the situation. I was thinking about create an addon to the received to manager the telemetry data not managed by the FS-I6 and show them on a little display.

Known id:
0x00 is for "IntV", internal voltage
0x01 is for "Tem", temperature
0x02 is for "Mot", RPM
0x03 is for "ExtV", external voltage
0x7C is for "Odo1", odometer 1
0x7D is for "Odo2", odometer 2
0x7E is for "Spe", speed
0x7F is for "Tx.V", TX battery voltage
0xFE is for "Err", RSSI rate

cj1324 · 2016-10-30T12:56:07Z

Test on FS-i6S and iA6B.

test result:
0x01 is for "Tem", temperature
0x02 is for "Mot", RPM
0x03 is for "ExtV", external voltage
0x7C is for "Odo1", odometer 1 (The screen is not visible )
0x7D is for "Odo2", odometer 2 (The screen is not visible)
0x7E is for "Spe", speed (The screen is not visible)
0x7F is for "Tx.V", TX battery voltage (good)
0xFE is for "Err", RSSI rate (There are some problems)
.

inode- · 2016-10-30T19:14:10Z

More tests executed, I hope tomorrow to execute a flying test. My testcase is configured with 2 softserial, the first connected to an ubox at 19200 baud, the second used for telemetry. Used CLI to configure the serial port setting (serial 31 1024 115200 57600 115200 115200).

Here the results:

GPS active, Telemetry active. CPU load 40% (telemetry is not working)
GPS active, Telemetry deactive. CPU load 20% (telemetry is not working)
GPS deactive, Telemetry active. CPU load 65% (telemetry is working)
GPS deactive, Telemetry deactive. CPU load 15%

This so high CPU load can cause problem with on fly tests?

unitware · 2016-10-30T19:25:55Z

src/main/telemetry/ibus.c

+                  .report_cell_voltage = false,
+                 );
+
+#define IBUS_TASK_PERIOD_US (500)


@iNode
Regarding the cpu load, you can try to increase this value in steps until you see the telemetry stop working and then back off a bit until it is working again. Then see if you can get GPS online again.

McGiverGim · 2017-02-28T11:56:12Z

@cj1324 I know this is a very old discussion, but... The "Sig.S" telemetry info that appears in your FS-i6S with a value of 10, what does it means? My FS-I6S has the same data, maybe some info about signal?

cj1324 · 2017-03-01T03:29:17Z

@McGiverGim Should be the signal value, did not find the official description.
Debugging values always 10. Can be programmed to modify (unstable)

McGiverGim · 2017-03-01T06:31:00Z

@cj1324 Thanks!

unitware mentioned this pull request Sep 19, 2016

Support FlySky i-Bus telemetry #1125

Closed

unitware mentioned this pull request Sep 20, 2016

Add iBus telemetry option in ports tab cleanflight/cleanflight-configurator#422

Merged

ledvinap reviewed Sep 20, 2016

View reviewed changes

ledvinap reviewed Sep 21, 2016

View reviewed changes

unitware mentioned this pull request Sep 28, 2016

Graft of 'serial RX and telemetry on same port' feature from Betaflight. #2345

Closed

ledvinap approved these changes Oct 5, 2016

View reviewed changes

unitware force-pushed the ibus-telemetry branch from 8ec99dc to 34ca677 Compare October 12, 2016 20:38

unitware force-pushed the ibus-telemetry branch from 34ca677 to dd01488 Compare October 12, 2016 20:49

unitware force-pushed the ibus-telemetry branch from a020587 to 00ef0d6 Compare October 13, 2016 12:25

hydra added the Requires testing label Oct 13, 2016

unitware added 4 commits October 19, 2016 13:05

ignore characters that are echoed back from the bidirectial serial wire

0b16a5e

rescedule telemetry task period only if ibus is enabled

4a108d2

handle all in rxbuffer at once

9cb4cf9

updated function prototype after rebase

def22c8

unitware force-pushed the ibus-telemetry branch from 00ef0d6 to def22c8 Compare October 19, 2016 11:17

hydra added the Enhancement label Oct 20, 2016

hydra merged commit 5f346e8 into cleanflight:master Oct 20, 2016

unitware deleted the ibus-telemetry branch October 20, 2016 16:32

unitware commented Oct 30, 2016

View reviewed changes


		static uint8_t ibusReceiveBuffer[IBUS_RX_BUF_LEN] = { 0x0 };

		static uint16_t calculateChecksum(uint8_t ibusPacket[static IBUS_CHECKSUM_SIZE], size_t packetLength) {

FlySky Ibus telemetry support #2415

FlySky Ibus telemetry support #2415

Conversation

unitware commented Sep 19, 2016 • edited

unitware commented Sep 19, 2016 • edited

cj1324 commented Sep 19, 2016

ledvinap left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cj1324 commented Sep 23, 2016 • edited

unitware commented Sep 23, 2016

cj1324 commented Sep 24, 2016

cj1324 commented Sep 27, 2016

unitware commented Sep 27, 2016

cj1324 commented Sep 27, 2016 • edited

unitware commented Sep 27, 2016

unitware commented Oct 5, 2016

ledvinap left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ledvinap Oct 5, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

unitware commented Oct 12, 2016 • edited

hydra commented Oct 12, 2016

ledvinap commented Oct 12, 2016

unitware commented Oct 13, 2016

ledvinap commented Oct 13, 2016

unitware commented Oct 13, 2016

ledvinap commented Oct 13, 2016

ledvinap commented Oct 13, 2016

hydra commented Oct 13, 2016

hydra commented Oct 20, 2016

rootik commented Oct 25, 2016 • edited

danarrib commented Oct 25, 2016

rootik commented Oct 26, 2016

rootik commented Oct 26, 2016

unitware commented Oct 26, 2016

rootik commented Oct 26, 2016

rootik commented Oct 26, 2016 • edited

danarrib commented Oct 26, 2016

rootik commented Oct 26, 2016

danarrib commented Oct 26, 2016

rootik commented Oct 26, 2016 • edited

rootik commented Oct 26, 2016 • edited

inode- commented Oct 29, 2016

unitware commented Oct 29, 2016

inode- commented Oct 30, 2016

cj1324 commented Oct 30, 2016 • edited

inode- commented Oct 30, 2016

Choose a reason for hiding this comment

McGiverGim commented Feb 28, 2017

cj1324 commented Mar 1, 2017

McGiverGim commented Mar 1, 2017

unitware commented Sep 19, 2016 •

edited

unitware commented Sep 19, 2016 •

edited

cj1324 commented Sep 23, 2016 •

edited

cj1324 commented Sep 27, 2016 •

edited

ledvinap Oct 5, 2016 •

edited

unitware commented Oct 12, 2016 •

edited

rootik commented Oct 25, 2016 •

edited

rootik commented Oct 26, 2016 •

edited

rootik commented Oct 26, 2016 •

edited

rootik commented Oct 26, 2016 •

edited

cj1324 commented Oct 30, 2016 •

edited