Mlink-FrSky-Telemetry converter

Tobi · Post by **Tobi** » Sun Jul 26, 2015 8:51 pm

Hello,

now I have got a Taranis 9x+. Because I use a ACT-TX-module, I whant to convert a MLink-data-stream to FrSky-protocol - sending over the RS232-interface in Tarans battary-case. In the documentation I found a baud-rate of 9600.
I try to find some informations on frSky-protocol, but there are some facts I did noch get clear. Maybe someone could give me som advises:

1. In TX-Setup I can change the status of the serial Port from "off" over "S-Port Data Out" to <emty - whithout any text>. Folowing the manual there shoud be something like "telemetry". Is this just a little bug or is this option deactivated?
2. For my first tests I used a arduino whith an ATMEGA328 (arduino ProMini 5V 16MHz). Some sites say, that the serial-signal has to be inverted. Is this correct using the Taranis-serial-port? I tried both - inverted and not inverted -without any success.
3. In first step I whant to send a verry simple stream like this:

0x7E 0xFD i sensor einheit daten[0] daten[1] NULL CRCLow CRCHigh 0x7E

where the variables (all 8bit unsigned integer) are:
i = 2 to 6 ( I was not shoure, so I tested all - what is correct?)
sensor = 0x01 (or 0x02, or 0x03...)
einheit = 0x28 (current)
daten[0] = 0x01 (only for the test...
daten[1] = 0x23 ...some numbers - later there should be values from MLink)
NULL (I found, that this is not used)

CRCLow CRCHigh :
I found this code for calculating this:
"uint16_t FcsCheck(uint8_t *pdata,short num)
{
static uint16_t CRCTable[]=
{<see below>}

uint16_t FCS=0x0;
for(int i = 0 ; i < num ; i++)
{
FCS = (FCS>>8) ^ CRCTable[(FCS^pdata) & 0xFF];
}
return FCS;
} "

The return-value is split into the two bytes whith:

uint16_t CRC = FcsCheck(daten,2);

byte CRCLow = (uint8_t) (CRC & 0x00FF);
byte CRCHigh = (uint8_t) ((CRC & 0xFF00)>>8);

But all this has no effect. The Taranis says still "no data".
If anyone could give me some assotiations or corrections, I would be verry glad.

Thanks and best regards from Germany

Tobi

static uint16_t CRCTable[]=
{0x0000,0x1189,0x2312,0x329b,0x4624,0x57ad,0x6536,0x74bf,0x8c48,0x9dc1,0xaf5a,0xbed3,0xca6c,0xdbe5,0xe97e,0xf8f7,0x1081,0x0108,0x3393,0x221a,0x56a5,0x472c,
0x75b7,0x643e,0x9cc9,0x8d40,0xbfdb,0xae52,0xdaed,0xcb64,0xf9ff,0xe876,0x2102,0x308b,0x0210,0x1399,0x6726,0x76af,0x4434,0x55bd,0xad4a,0xbcc3,0x8e58,0x9fd1,
0xeb6e,0xfae7,0xc87c,0xd9f5,0x3183,0x200a,0x1291,0x0318,0x77a7,0x662e,0x54b5,0x453c,0xbdcb,0xac42,0x9ed9,0x8f50,0xfbef,0xea66,0xd8fd,0xc974,0x4204,0x538d,
0x6116,0x709f,0x0420,0x15a9,0x2732,0x36bb,0xce4c,0xdfc5,0xed5e,0xfcd7,0x8868,0x99e1,0xab7a,0xbaf3,0x5285,0x430c,0x7197,0x601e,0x14a1,0x0528,0x37b3,0x263a,
0xdecd,0xcf44,0xfddf,0xec56,0x98e9,0x8960,0xbbfb,0xaa72,0x6306,0x728f,0x4014,0x519d,0x2522,0x34ab,0x0630,0x17b9,0xef4e,0xfec7,0xcc5c,0xddd5,0xa96a,0xb8e3,
0x8a78,0x9bf1,0x7387,0x620e,0x5095,0x411c,0x35a3,0x242a,0x16b1,0x0738,0xffcf,0xee46,0xdcdd,0xcd54,0xb9eb,0xa862,0x9af9,0x8b70,0x8408,0x9581,0xa71a,0xb693,
0xc22c,0xd3a5,0xe13e,0xf0b7,0x0840,0x19c9,0x2b52,0x3adb,0x4e64,0x5fed,0x6d76,0x7cff,0x9489,0x8500,0xb79b,0xa612,0xd2ad,0xc324,0xf1bf,0xe036,0x18c1,0x0948,
0x3bd3,0x2a5a,0x5ee5,0x4f6c,0x7df7,0x6c7e,0xa50a,0xb483,0x8618,0x9791,0xe32e,0xf2a7,0xc03c,0xd1b5,0x2942,0x38cb,0x0a50,0x1bd9,0x6f66,0x7eef,0x4c74,0x5dfd,
0xb58b,0xa402,0x9699,0x8710,0xf3af,0xe226,0xd0bd,0xc134,0x39c3,0x284a,0x1ad1,0x0b58,0x7fe7,0x6e6e,0x5cf5,0x4d7c,0xc60c,0xd785,0xe51e,0xf497,0x8028,0x91a1,
0xa33a,0xb2b3,0x4a44,0x5bcd,0x6956,0x78df,0x0c60,0x1de9,0x2f72,0x3efb,0xd68d,0xc704,0xf59f,0xe416,0x90a9,0x8120,0xb3bb,0xa232,0x5ac5,0x4b4c,0x79d7,0x685e,
0x1ce1,0x0d68,0x3ff3,0x2e7a,0xe70e,0xf687,0xc41c,0xd595,0xa12a,0xb0a3,0x8238,0x93b1,0x6b46,0x7acf,0x4854,0x59dd,0x2d62,0x3ceb,0x0e70,0x1ff9,0xf78f,0xe606,
0xd49d,0xc514,0xb1ab,0xa022,0x92b9,0x8330,0x7bc7,0x6a4e,0x58d5,0x495c,0x3de3,0x2c6a,0x1ef1,0x0f78};

Post by **Kilrah** » Sun Jul 26, 2015 9:00 pm

What OpenTX version and language? Are you using the internal module? Are you doing the setup in companion or on the radio?

Tobi · Post by **Tobi** » Sun Jul 26, 2015 9:18 pm

Hello Kilrah,

I use opentx-taranis-plus-2.017. Lanuage is German.
I do not use the internale module because I prefere ACTs S3D-T.
ACT uses MLink.
My plan is to get the MLink stream from ACT-TX- module, convert it to FrSky stream and send it
to the Taranis over the backwards serial port.
I do not use any FrSky recivers.

Best regards

Tobi

Post by **Kilrah** » Mon Jul 27, 2015 6:24 am

OK, then when "Serial Port" is set to "Telemetry" on the hardware tab (it should be there unless the German translator got it wrong), the internal module is OFF and the external one is set to PPM you should have a setting on the telemetry page whether the telemetry supplied on the serial port is "D-type with hub" or Smart Port type.

You should choose the one you prefer and make a translation device form M-Link to one of these. The D protocol is described in publicly available documentation, Smart port isn't but is easy to understand either from OpenTX sources or from other projects that implemented it (cleanflight, openXsensor,...)
What you listed above does not look like either of them.

The port is indeed RS232 serial (or inverted TTL).

Oh and alternatively you could implement the M-Link protocol in OpenTX natively... the new system in OpenTX 2.1 makes that relatively easy.

Tobi · Post by **Tobi** » Mon Jul 27, 2015 7:53 am

Hello Kilrah,

thanks for the inormations! If it would be possible to implement MLink directly, that would be the best way. I will try this first. Thanks for this tip.

Best regards

Tobi

Tobi · Post by **Tobi** » Mon Jul 27, 2015 8:38 am

Hello Kilrah,

now I did the update to 2.1 - it works fine and now there is the option "telemetrie" readable.
Thats fine - so obviously it was a little problem of translation - never mind

.
You wrote, that an implementation of M-Link protocol in OpenTX would be relatively easy.
Please could you give me a tip how to do this? Maybe by LUA?

Best regards

Tobi

Post by **Kilrah** » Mon Jul 27, 2015 9:42 am

No, lua does not have access to the "raw" stream, only to the sensors that are populated by OpenTX.

First have a look at the telemetry system, you'll see that telemetry.cpp/h implement a pretty generic set of fields including a protocol that are populated by frsky_d.cpp/h for D type FrSky telemetry and by frsky_sport.cpp/h for Smart port type FrSky telemetry.

You'd write a new parser similar to those for mlink telemetry that decodes what's received and fills the sensors with relevant info.

Tobi · Post by **Tobi** » Mon Jul 27, 2015 11:32 am

Hello Kilrah,

thanks a lot, but I am afraid this is to much regarding my knowlage. In first step I failed to find the files

. And than there are a lot of questions left such as how to build an binary-file to upload to TX etc. . Becaus I can not expect you to give me all the informations from scratch I beleve, I will give it up... But maybe you could give me some helpful links.

I did a MLink-library for Arduino last year and it works fine on a stand allone display based on ATMEGA328.
I send the code to Bertrand and Franck a view days ago. Maybe some of you are interested in to implement it to OpenTX.

Best regards

Tobi

Tobi · Post by **Tobi** » Mon Jul 27, 2015 10:43 pm

Hello Kilrah,

until I could modify the code, I will try the external conversion. So I made a little controller-program which generates a
datastrem of this form:

0x5E SenorID DataLow DataHigh 0x5E

Should this work? I set it to Taranis TX line (right pin on right plug in battary-bay) both inverted and not inverted (5V controller TTL). I set "FrSky D" and alternativly "FrSky D(cable)" ("telemetry" is set in general setup for serial port) and chose some senors which should match the structure of data stream. But it still do not work.

By the way, if there is a data stream which fit to the correct structure but if wrong sensors are implemented in model setup is there still
the message "no data" in telemetry-screen or shoud it disappear?

Best regards

Tobi

Post by **MikeB** » Mon Jul 27, 2015 11:15 pm

That's the data you would send to a receiver. The data from a DJT includes an extra "wrapper".
You need this protocol document: http://www.frsky-rc.com/download/view.p ... -Telemetry.
When you download it, make sure you save it with a file extension of .pdf.
You need to put your data into a "user packet", and be sure to note the part about "byte stuffing".

Mike.

Tobi · Post by **Tobi** » Tue Jul 28, 2015 5:07 am

Hello Mike,

thanks for the link.

Now I send a stream like this (including "byte stuffing"):

0x7E 0x7D n 0 SenorID DataLow DataHigh 0 0 0 0 0x7E

I tryed n = 2...7 but still with no effect.

Best regards

Tobi

Post by **Kilrah** » Tue Jul 28, 2015 5:36 am

You forgot the 5Es in the hub protocol, and where do you get those "n"?

Should be something along the lines of
0x7E (frame start) 0xFD (user) 0x05 (len) 0x5E (hub header) SenorID DataLow DataHigh 0x5E (hub tail) 0x7E (frame end)

Post by **MikeB** » Tue Jul 28, 2015 8:52 am

0x7E 0x7D 5 0 0x5E (hub header) SenorID DataLow DataHigh 0x5E (hub header) 0 0x7E
EDIT, should be: 0x7E 0xFD 5 0 0x5E (hub header) SenorID DataLow DataHigh 0x5E (hub header) 0 0x7E
11 bytes in total.

Mike.

Tobi · Post by **Tobi** » Tue Jul 28, 2015 10:07 am

Hello Mike, hello Kilrah,

thanks for the correction. Now I do understand the protocol.
I tested it in Mikes version - again inverted and not inverted but eaven with no effect.
The TX shows "no data".

Best regards

Tobi

Post by **Kilrah** » Wed Jul 29, 2015 9:23 pm

I believe his 2nd byte is 0x7D when it should be 0xFD. I wasn't sure if the "not used" bytes were to be included or omitted, I guess I got that one wrong.

Post by **MikeB** » Wed Jul 29, 2015 10:23 pm

Yes, should be FD, I did a copy/paste and didn't look closely enough. I've edited my original post to show this correction.

Mike.

Tobi · Post by **Tobi** » Thu Jul 30, 2015 7:13 am

Hello Mike, hello Kilrah,

I did not see it, too. Its a bit tricky not to change "7" and "F"

. But now I can see a dummy value for Temperature. That means, it works. But the TX still shows "no data" - I will do some changes and tell you the result

. Many thanks!

Best regards

Tobi

Post by **MikeB** » Thu Jul 30, 2015 9:08 am

It may be that openTx expects to see a 'FE' packet (remote voltage and link quality) before it stops reporting "No Data".

Mike.

Post by **Kilrah** » Thu Jul 30, 2015 10:08 am

Yes most likely, AFAIK RSSI is used to determine whether telemetry is being received or not so you might need to send dummy RSSI frames, probably repeatedly to prevent the timeout.

Tobi · Post by **Tobi** » Thu Jul 30, 2015 11:49 am

That sounds good - I will implement it as soon as possible, because MLink covers RSSI, too.
Now I see nearly all data I send. I am verry happy

.

But there are two things, I do not get clear. Maybe you have informations:
1. The ID 0x03 ID_VOLT is not recognized - but 0x3A Voltage (Ampere Sensor) works (not like FrSky-Doku but it works)
2. much more sensible: I did not found a ID for vertical speed that works. Someone said it is 0x39 but this do not work. Do you know the correct ID?

Post by **MikeB** » Thu Jul 30, 2015 11:58 am

An ID of 3 is RPM on the hub protocol.
Try an ID of 48 (decimal, 0x30 hex) for vspd. This is an addon as FrSky don't provide a vspd on the hub protocol. It was added for use by the openXsensor project.

Mike.

Tobi · Post by **Tobi** » Thu Jul 30, 2015 12:42 pm

Hello Mike,

super! Thats it. Now I have got all infos to make the translator-modul. As soon as it is finished, I will post the codes.

Thanks a lot for yous an Kilrahs verry nice help. Thats great.

Best regards

Tobi

Tobi · Post by **Tobi** » Thu Jul 30, 2015 9:14 pm

Hello Mike, hello Kilrah,

all works fine, except voltage in both versions, voltage-amp-sensor and cell-voltage.
For example cell-voltage 4,2V cell 1:
0x7E (frame header)
0xFD (user data)
0x05 (5 data bytes)
0x00 (dummy)
0x5E (hub header)
0x06 (ID for cell voltage)
0x34 (4,2V = 0x0834 -> low byte first)
0x18 ( high byte + cell index in upper 4 bit)
0x5E (hub tail)
0x00 (dummy)
0x7E (frame tail)

If I send this, a sensor named "Cels" appears but the value is all times "---"

For voltage_amp-sensor I send

0x7E (frame header)
0xFD (user data)
0x04 (4 data bytes)
0x00 (dummy)
0x5E (hub header)
0x3A (ID for voltage before ".")
low byte
high byte
0x00 (dummy)
0x00 (dummy)
0x7E (frame tail)

0x7E (frame header)
0xFD (user data)
0x05 (5 data bytes)
0x00 (dummy)
0x5E (hub header)
0x3B (ID for voltage after ".")
low byte
high byte
0x05 (hub tail)
0x00 (dummy)
0x7E (frame tail)

Only a sensor named 003B appears with the value after "." . The before "." value is ignored - in first test it appears but then never more!

I use this structure for other folat-values and it works good.
Do you have some ideas?

best regards

Tobi

Post by **MikeB** » Thu Jul 30, 2015 10:09 pm

The 16 bit value for the cell data is actually not as described.
The coding is:
V7 V6 V5 V4 V3 V2 V1 V0 C3 C2 C1 C0 V11 V10 V9 V8

Where C3-C0 are the cell index and V11 to V0 are the cell voltage.

For the volt-amp sensor, you are showing, in the 3B data 0x05 for the hub tail, not 0x5E, maybe a typo in your post!

A reminder, have you read the part(s) about byte stuffing?

Mike.

Tobi · Post by **Tobi** » Fri Jul 31, 2015 6:15 am

Your right! 0x05 is a copy-paste error. In code it is 0x5E.
The structure of 16bit cell value is not correct in frsky-pdf. I use the form as you discribed.

I do the byte stuffing in form
1. 0x7E->0x7D 0x5E and 0x7D-> 0x7D 0x5D for ad0-ad1-rssi frame
2. 0x5E->0x5D 0x3E and 0x5D-> 0x5D 0x3D for framed hub data.

Or must it be alway in form 1 ?

best regards

Tobi

Tobi · Post by **Tobi** » Fri Jul 31, 2015 7:46 am

Ok, byte stuffing ist still a additionbal problem. I made some tests -> both stuffings are necessary!
Now all values 125,126 and 94 (0x7D, 0x7E, 0x5E) works but not 93 (0x5D)! The telemetry reading stops until it is 94, than it goes on normally.
The voltage problem ist still there.

best regards

Tobi

Tobi · Post by **Tobi** » Fri Jul 31, 2015 9:06 am

I saw this by byte stuffing:
If I send 0x5D 0x3D for 0x5D this sended value will be ignored, but should show decimal 93.
If I send
- 0x5D 0x3E for 0x5D it shows decimal 94
- 0x5D 0x3C for 0x5D it shows decimal 92

So the stuffed value is XORed with 0x60 as it is shown in pdf. But only 0x3D XOR 0x60 will not be shown on screen.
Could this be a little bug in OpenTX or did I something wrong?

Best regards

Tobi

Tobi · Post by **Tobi** » Fri Jul 31, 2015 7:16 pm

and now the last answer of my own post

:
In the code of OpenVario I found the comment, that the voltage-ID 0x3A, 0x3B not realy works. It is replaced by 0x39 as a singel value with 10mV resulution. That works good.

Now only the byte stuffing problem is left.

Post by **MikeB** » Fri Jul 31, 2015 9:01 pm

The byte stuffing needs to be done in two parts.
First, the 'hub' protocol that is
5E ID datalow datahigh 5E
The 5E bytes are always sent as they are, but any of the ID and data bytes that are 5E or 5D are stuffed as described. In this operation 7E and 7D values are NOT stuffed.
The resulting sequence of bytes are then packed into USER packets, a maximum of 6 bytes in any one packet, including stuffing bytes.
Then, the USER packet is processed. The leading and trailing 7E bytes are sent as they are, and any 7E or 7D bytes in the packet are then stuffed as required.

So, suppose the user data is 0x39 0x5D 0x7E
This is sent as 0x5E 0x39 0x5D 0x3D 0x7E 0x5E, 6 bytes in total. Pack this into a user packet:
0x7E 0xFD 0x06 0x00 0x5E 0x39 0x5D 0x3D 0x7E 0x5E 0x7E
Then stuff this into:
0x7E 0xFD 0x06 0x00 0x5E 0x39 0x5D 0x3D 0x7D 0x5E 0x5E 0x7E
This is then what you send.

If the user data, after stuffing, exceeds 6 bytes, then you have to put them into TWO user packets.

Mike.

Tobi · Post by **Tobi** » Sat Aug 01, 2015 3:39 pm

Hello Mike,

thats a verry good explanation! Thanks. It took me some time to change my code. It runs but the problem of 93decimal is still there. In the new version it appears 96 if I send 93 (92,94...125,126 etc. works).
If I change the secound hub-stuffing from 0x5D 0x3D to 0x5D 0x3C (just for fun) 92 is displayd. In version 0x5D 0x3E it shows 94. But 0x5D 0x3E shows 96 and not 93 as it should. I can not find any error in my code. It is not such long:

#define PROTOCOL_HUB_HEADER 0x5E
#define PROTOCOL_HUB_STUF 0x5D
#define PROTOCOL_HUB_STUFX0 0x3E
#define PROTOCOL_HUB_STUFX1 0x3D
...
if (data == PROTOCOL_HUB_HEADER)
{
hub[hub_index++]=PROTOCOL_HUB_STUF;
hub[hub_index++]=PROTOCOL_HUB_STUFX0;
}
else if (data == PROTOCOL_HUB_STUF)
{
hub[hub_index++]=PROTOCOL_HUB_STUF;
hub[hub_index++]=PROTOCOL_HUB_STUFX1; //< Here is the problem located I beleve...
}
else hub[hub_index++]=data;

Maybe you can have a look

.

Best regards

Tobi

openrcforums

Mlink-FrSky-Telemetry converter

Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter

Re: Mlink-FrSky-Telemetry converter