FRSKY telemetry integration into Multiwii 2.4 has started

QuadBow · Post by **QuadBow** » Sat Mar 21, 2015 7:23 am

Currently, I am integrating the recent frsky telemetry code into multiwii 2.4 covering following values:

FRSKY FLD-02 first page

FRSKY FLD-02 second page

FRSKY FLD-02 third page

FRSKY FLD-02 forth page

Since I own the FRSKY display FLD-02 I would like to know:
Are there other values (gps altitude, course, gps course, gyro, mag) to be supported by other devices (eg open9x, er0x, th9x,...) ?
Are there other proposals (other use of acceleration entries, other use of RPM, other use of temperature) ?

Please recall, that I will cover the frsky telemetry part only - not the s.port part, which could be integrated into the telemetry files later.

ardufriki · Post by **ardufriki** » Mon Mar 23, 2015 11:49 am

Good news Frsky will be integrated in MultiWii code !!

I have er9x with Frsky option enabled. For now I can visualize RSSI values in my Turnigy 9x transmitter, but I will be amazing to see other values.

The GPS coords I dont know if are implemented in Fsrsky protocol (I think so), but they are a "must", in order to conect to other systems, as Ezio EZGUI, antenna trackers, and so on...

Good job !

QuadBow · Post by **QuadBow** » Tue Mar 31, 2015 3:11 pm

Dear all,

I just want to let you know that Frsky telemetry has found its way to the main trunk https://code.google.com/p/multiwii/source/browse/#svn%2Ftrunk%2FMultiWii_shared with r1754.

Furthermore, I have written a wiki page related to that topic https://code.google.com/p/multiwii/wiki/Frsky_Telemetry_Implementation (r1755).

I am looking forward to your feedback.

ardufriki · Post by **ardufriki** » Wed Apr 01, 2015 8:03 am

Hi Quadbow !! It works fine for me. Tested with this setup:

MW FC --> openlrsng RX >>>>>>>>>>>>>>>>>>>>> Turnigy 9x (moded and w/er9x firmware) ------>BT (HC-05) ---->Android phone (running Frsky apk).

All of this telemetry downlink working ok. I see values in my trasnmitter LCD and weird map position in the android apk (FrSky Dashboard). The main problem I see is that there is no error checking in this protocol (AFAIK), so is useless for Ground station control and antenna trackers.

Anyway, great job !!

happul3 · Post by **happul3** » Wed Apr 01, 2015 8:45 pm

QuadBow wrote:

Are there other proposals (other use of acceleration entries, other use of RPM, other use of temperature) ?

Good to see that telemetry will be incorporated in official version at some point soon. Personally, I've been using multiwii telemetry code fished from old threads with my own cosmetic modifications to re-uses of FLD-02 display "real estate". My personal choice evolved to switching purposes of FLD-02 fields depending on whether 1) copter is armed or not and 2) copter is being flown for fun or to tune/troubleshoot.

When copter is armed my preference is to see temperature fields changed to display altitude and rate of ascent/descent. And if copter is armed and being test-flown, the time fields of Screen1 (xx:xx:xx) show three real-time vibration amplitudes obtained from gyroADCs with simple 2nd order high pass filter.

Other values, which I find useful to display occasionally (can be switched by stick actions when disarmed, no reset is necessary) are averages of motor codevalues during/after flight, single value delta between min and max motor codevalues, and baropid error. I discovered that the motor averages are amazingly revealing of any weight distribution disbalance or minor skew in motor mounting your copter might have and yet you are blissfully unaware. Delta is a simple indicator that you have such a problem but does not let you identify the reason. And baropid error is nice to see to learn using althold mode properly. But those are just my personal favorites, mostly for testing/tunung.

NNagib · Post by **NNagib** » Mon Apr 06, 2015 3:39 pm

Hi, I would like to enable frsky telemetry in multiwii 2.4 (final version). I have frsky D8R II plus receiver, and mega FC (Drotek DroFLy v3).
I have Turnigy 9X flashed with OpenTX and frsky radio module and want to buy FLS screen.

If I understand correctly, I need RS232 to TTL converter (MAX3232CSE) which should be powered with 3.3V, right?

Plüschi · Post by **Plüschi** » Mon Apr 06, 2015 3:55 pm

happul3 wrote:re-uses of FLD-02 display "real estate"

I do the same thing. I display distance to home and course to home.
But i have found the whole frsky telemetry / FLD02 thing is very very slow. It takes over a second from transmitting a value to having it displayed on the FLD02.
Steering a car/boat/plane to home direction with this delay is almost impossible. It will overshoot unless i turn very very slowly.

I immagine a vario with over 1 sec delay is useless as well.

Are there values which are transfered faster?

Hamburger · Post by **Hamburger** » Mon Apr 06, 2015 7:51 pm

as your implementation is for frsky only, using the "telemetry.cpp" for a filename seems to be - not quite appropriate.
Could you please rename that file to better represent what it really contains?

baco · Post by **baco** » Mon Apr 06, 2015 11:50 pm

I have put the FRSKY telemetry long time ago.

For more information:
http://www.multiwii.com/forum/viewtopic.php?f=7&t=1929

QuadBow · Post by **QuadBow** » Wed Apr 08, 2015 8:33 pm

Hamburger wrote:as your implementation is for frsky only, using the "telemetry.cpp" for a filename seems to be - not quite appropriate.
Could you please rename that file to better represent what it really contains?

The files Telemetry.cpp/h are open to future extensions like S.PORT and HOTT even if currently only FRSKY is implemented. So,I deny your assumption that the naming were less appropriate and didn't represent its content. I understand that the naming is fully inline with multiwii policy in order to limit the number of files to the most appropriate number.

Hamburger · Post by **Hamburger** » Thu Apr 09, 2015 7:10 am

Ok.
You wrote some documentation in the google wiki. You do realize that is not the official main mwii wiki anymore?

veloviking · Post by **veloviking** » Thu Apr 09, 2015 1:13 pm

Do we have any chance to get it worked throw S.PORT ?
I had x8r receiver...

QuadBow · Post by **QuadBow** » Thu Apr 09, 2015 8:27 pm

Hamburger wrote:You do realize that is not the official main mwii wiki anymore?

I understood that committers are invited to document their contributions with related wiki entries. What is your concern of doing that?

QuadBow · Post by **QuadBow** » Thu Apr 09, 2015 8:33 pm

veloviking wrote:Do we have any chance to get it worked throw S.PORT ?

I saw a threads mentioning some code snipplets on S.PORT. The current telemetry implementation is in principle ready to support S.PORT. But, as far as I understood, the development needs some more reversal engineering since the protocol is under non disclosure agreement. The first steps could be done right now, but, someone has to do them.

veloviking · Post by **veloviking** » Thu Apr 09, 2015 10:29 pm

On transmiter side looks like same protocol, as my turnigy 9x connected to SPORT of XJT trasmitter (of course I use inverter, as in http://sizz.name/3986-telemetriya-v-tur ... -frsky-xjt its in russian but qute understandable by pictures ) and with usual openex telemetry firmware I see receiver signal level

Looks like arducopter can use SPORT
and it used in megapirateng - https://github.com/MegaPirateNG/ardupil ... 2e30a09fdb
I can du tests, change some settings in code, but unfortunately, I am not developer to make full solution.

QuadBow · Post by **QuadBow** » Fri Apr 10, 2015 9:00 pm

NNagib wrote:If I understand correctly, I need RS232 to TTL converter (MAX3232CSE) which should be powered with 3.3V, right?

Actually, you just need an inverter.This inverter can be realised easily with just one transistor http://static.rcgroups.net/forums/attachments/4/8/8/2/1/6/a6167985-4-MultiWii-FrSky-er9x-inverter-levelconverter_improved.png

If you prefer to buy an inverter instead of solder it, you should consider following:
An RS232-to-TTL converter uses a positive voltage of +12V and a negative voltage of-12V on the RS232 side due to the RS232 protocol specifications.
Thus, in principle it does not help much since you need only 0V and 3.3V. However, there are some RS232-to-TTL converters which you can make work as an inverter.

There are some descriptions how to do it for various converters http://www.multiwii.com/forum/viewtopic.php?f=7&t=1929&start=50#p26175 and http://www.multiwii.com/forum/viewtopic.php?f=7&t=1929&start=50#p29753

Maybe others could contribute more experience with other RS232-to-TTL converters.

PS: the Frsky converter http://www.frsky-rc.com/product/pro.php?pro_id=34 can also be used as an inverter.

happul3 · Post by **happul3** » Tue Apr 14, 2015 4:46 am

Plüschi wrote:
happul3 wrote:re-uses of FLD-02 display "real estate"

I do the same thing. I display distance to home and course to home.
But i have found the whole frsky telemetry / FLD02 thing is very very slow. It takes over a second from transmitting a value to having it displayed on the FLD02.
Steering a car/boat/plane to home direction with this delay is almost impossible. It will overshoot unless i turn very very slowly.

I immagine a vario with over 1 sec delay is useless as well.

Are there values which are transfered faster?

Yes, there are values that transfer faster. The code I am using originally had 4Hz (0.25 sec) update rate for send_Temperature(); and send_Time(); while other data are updated once a second. It is trivial to change overall update rate and/or select items to update with higher or lower frequency.

By the way, I do not find vario even with one sec update to be useless. I like to have vario when the copter is far and high so I can see it but can't visually assess ascent/descent rate.

QuadBow · Post by **QuadBow** » Thu Apr 16, 2015 6:10 am

happul3 wrote:Yes, there are values that transfer faster. The code I am using originally had 4Hz (0.25 sec) update rate for send_Temperature(); and send_Time(); while other data are updated once a second.

This does not seem to be a very good approach since the resolution of time is just one second and temperature changes very slowly.

The implementation mentioned within this thread uses a scheduler with a nearly constant data rate and following update frequencies:
1Hz: coordinates, time, fuel, temperature, course, distance
2Hz: voltage, current, altitude, speed
4Hz: acceleration

If there is the wish to send some data faster, please, let me know.

Plüschi · Post by **Plüschi** » Thu Apr 16, 2015 3:16 pm

happul3 wrote:originally had 4Hz (0.25 sec) update rate for send_Temperature(); and send_Time(); while other data are updated once a second. It is trivial to change overall update rate

I did not mean update rate but delay. Do you think delay is less when i use higher update rate? Possible, will have to check.

happul3 wrote:By the way, I do not find vario even with one sec update to be useless.

It is quite useless for finding thermals. 1 sec delay + 1 sec "human delay" on a plane doing 10m/s (36km/h) is 20m. When you think you enter a thermal you are actually on the way out already.

happul3 · Post by **happul3** » Thu Apr 16, 2015 6:56 pm

Plüschi wrote:
happul3 wrote:originally had 4Hz (0.25 sec) update rate for send_Temperature(); and send_Time(); while other data are updated once a second. It is trivial to change overall update rate

I did not mean update rate but delay. Do you think delay is less when i use higher update rate? Possible, will have to check.

happul3 wrote:By the way, I do not find vario even with one sec update to be useless.

It is quite useless for finding thermals. 1 sec delay + 1 sec "human delay" on a plane doing 10m/s (36km/h) is 20m. When you think you enter a thermal you are actually on the way out already.

I did not realize you meant delay (time lag). I'd be surprised there is 1 sec lag, but stranger things happened

Vario display may be useless for your purposes, but it certainly is not for me. Not everyone flies sailplanes, you know. Last time I cared about thermals was years ago hangliding. Now I just use vario display to help me judge powered ascent/descent rate.

haydent · Post by **haydent** » Fri May 08, 2015 1:00 am

hey quadbow, who got this in to trunk for you? i want to get in smartport integration too, also we can work together to not overlap, though mine focusses on data in from smart port rather than data out in your case, one day data out will be done for smart port too

boaterguy · Post by **boaterguy** » Wed May 27, 2015 10:11 pm

I feel like I'm a little out of place here but the current multiwii2.4 on the google code page does not have the telemetry.cpp/h files. Where can these be downloaded? I found the article on the wiki about it being implemented in r1754, where there are a few affected files, but they cannot be downloaded, just viewed.
Where can I go to download the new files?

Maine_Guy · Post by **Maine_Guy** » Thu May 28, 2015 6:25 pm

I got them at the 'shared' trunk. A PIA to download without additional software.
https://code.google.com/p/multiwii/source/browse/#svn%2Ftrunk%2FMultiWii_shared

I wound up 'viewing raw file' then saving each individually. You also need some code changes in other files - if that's not obvious.

I'm still working out the details on the inverter. I got the HK inverter - but still unsure if that is what I need VS level converter? Glad to have so many people contributing to this effort!

QuadBow · Post by **QuadBow** » Fri May 29, 2015 5:11 pm

Maine_Guy wrote:I wound up 'viewing raw file' then saving each individually.

I agree with you that the way you took is not the most enjoyable one...
Look at https://code.google.com/p/multiwii/source/checkout for better solutions.

Ma[quote="Maine_Guy wrote: I got the HK inverter - but still unsure if that is what I need VS level converter?

ine_Guy"]You also need some code changes in other files - if that's not obvious.[/quote]What should be changed for what purpose?

Maine_Guy wrote: I got the HK inverter - but still unsure if that is what I need VS level converter?

Which one do you mention? Do you have a link?
What kind of display do you use FLD-02 or the transmitter's display?

Maine_Guy · Post by **Maine_Guy** » Fri May 29, 2015 6:03 pm

QuadBow wrote:What should be changed for what purpose?

Just mentioning that you need more than just the telemetry.cpp / h

QuadBow wrote:Which one do you mention? Do you have a link?
What kind of display do you use FLD-02 or the transmitter's display?

I'm (attempting to) display on my Taranis. I have the HK inverter.
http://www.hobbyking.com/hobbyking/store/__24523__ZYX_S_S_BUS_Connection_Cable.html

I figured out, last night, that my AIO FC from HK does not seem to output 5v on the Vcc output for the com ports. Which raises the question - is 4.5-5v input into the sbus OK - or do I need to reduce voltage to 3.3v (which I believe is the sbus 'standard' signal voltage)? Would be much easier to feed the inverter with the reg board voltage than try to reduce. Still unsure what the Vcc on the serial output is supposed to be, since literature suggests it is supposed to be 5v.

I see you answered my post on the other discussion - thanks.
http://www.multiwii.com/forum/viewtopic.php?f=7&t=1929&start=350

That could be dangerous. Some receivers like FRSKY D8R-II (which do you have?) bear only 3.3V at the telemetry port, even if they are fed with Vcc=5V

ardufriki · Post by **ardufriki** » Thu Jun 04, 2015 1:36 pm

does anybody know if frsky protocol has NO checksum in the packets and frsky sport has checksum in them?

haydent · Post by **haydent** » Fri Jun 05, 2015 1:35 am

sport does, dont know about older

ardufriki · Post by **ardufriki** » Fri Jun 05, 2015 8:17 am

thx haydent. I supoussed that because the er9x implementation I have in my turnigy 9x has sometimes garbage data. :-)

haydent · Post by **haydent** » Fri Jun 05, 2015 10:17 am

yeah looking at the telemetry code attached above they dont seem to be using any checksums and it uses the old protocol

LutzB · Post by **LutzB** » Mon Jun 29, 2015 8:32 am

Last weekend I tried to merge the SPort code from http://www.multiwii.com/forum/viewtopic.php?f=8&t=4507 into the Telemetry.cpp/.h files in the shared trunk.
At least I get some values displayed on my Taranis plus, but the performance/lag is quite poor. This is caused by the position of the "run_telemetry()" call in multiwii.cpp. If I change it to right above "computeIMU()" as mentioned in the SPort thread, the lag disappears. :?:

May this change produce any bad side effect? The cycle time is not increased that much. I get many readings of 2800 and some up to 3100/3200, but this can also be caused by the serial GPS.

Performance is important for the SPort code to work, as the telemetry values are polled by the receiver. I have no idea, in what time frame the answer has to be send. Also the main problem is to scale the values to something opentx is expecting. I had a look at the cleanflight code and was able to transmit GPS coords, heading (MAG or GPS), altitude (Baro and GPS) and battery voltage (VBAT, not yet cells).

I will post the changed files during this week when I have cleaned up the code. Please take it as a first start for SPort telemetry. This is my first coding for the arduino so there are many things to optimize for a pro. :ugeek:

Best regards,
Lutz

michar71 · Post by **michar71** » Tue Jun 30, 2015 1:46 am

Here's an idea that I implemented on 2.3 for my quad some time ago that has to do with FrSky comm:
Automatic comm fallback from primary short-range comm channel (Bluetooth/Cable/Wifi whatever) to secondary long-range channel (FrSky)

I've the bluetooth module Rx/Tx wired up to the UART and FrSky Tx wired up in parallel (+ the inverter in-between...)
So while the quad is on the ground/close I can tune parameters via Bluetooth or watch graphs (which works within 10m radius)

I'll have a timeout counter on the Rx signal and if I don't receive anything on Rx for 3 seconds I reconfigure the UART to 2400 baud
and switch to the FrSky protocol.

No idea if anybody else would find that useful but it makes it easy to use both in parallel without swapping wires or hooking up cables....

(I realize this has not much to do with the FrSky protocol but for me the code lives mostly in the FrSky module except the timeout call
so I mention it here...)

Michael

QuadBow · Post by **QuadBow** » Thu Jul 02, 2015 5:02 pm

LutzB wrote:Last weekend I tried to merge the SPort code from viewtopic.php?f=8&t=4507 into the Telemetry.cpp/.h files in the shared trunk.
At least I get some values displayed on my Taranis plus, but the performance/lag is quite poor. This is caused by the position of the "run_telemetry()" call in multiwii.cpp. If I change it to right above "computeIMU()" as mentioned in the SPort thread, the lag disappears. May this change produce any bad side effect? The cycle time is not increased that much. I get many readings of 2800 and some up to 3100/3200, but this can also be caused by the serial GPS.

I put run_telemetry() into the magical time period of 650us used by computeIMU() since it fits in there and does not extend the cycle time. I still can not understand why the performance would be improved if putting it somewhere else. Could you attach your code here for further elaboration, please?

LutzB · Post by **LutzB** » Fri Jul 03, 2015 6:45 am

Hi Quadbow,

find the files attached. I only included the Telemetry.cpp and .h files, as the others were not modified.

QuadBow · Post by **QuadBow** » Sun Jul 05, 2015 11:28 am

Hi LutzB,

Thank you very much for your contribution.
The only thing I had to change was to replace FRSKY_SPORT_SERIAL by TELEMETRY_SERIAL, which is more general and already defind in config.h
The only thing I still have to know is FRSKY_SPORT_A2_MAX. What about its value? Is it fixed or do the users have to adapt it in file config.h?

Best
QuadBow

LutzB · Post by **LutzB** » Sun Jul 05, 2015 3:35 pm

QuadBow wrote:The only thing I still have to know is FRSKY_SPORT_A2_MAX. What about its value? Is it fixed or do the users have to adapt it in file config.h?

This Value has to be the same in tx and rx depending on the used battery. So I would definitely place it in config.h.

QuadBow wrote:Thank you very much for your contribution.

All I did was putting the peaces together, others already developed. It was quite easy and I wonder, why it has not been done before.

@All: Everybody is welcome to extend the telemetry values. I implemented the ones I use, but there my be others interested in different values.

Best Regards,
Lutz

jt41time · Post by **jt41time** » Tue Jul 07, 2015 4:10 pm

i want to make sure i get this right....

1. i can add the two files, telemtery.ccp/.h into my wii folder and add the #define part to config.h and it should compile...?

2. this code will make the rx/tx (uart) throw out frsky telem?

3. I can use a 3dr type radio and send this back to my 9xr(modded) and i can see the telem info on screen? (i have my 9xr setup to se mavlink at the moment and works great)

4. I do not need a level inverter if I'm not useing frsky modules?

5. Can i do this with MW 2.3? or 2.4 only?

QuadBow · Post by **QuadBow** » Tue Jul 07, 2015 9:33 pm

jt41time wrote:1. i can add the two files, telemtery.ccp/.h into my wii folder and add the #define part to config.h and it should compile...?

I will upload the complete telemetry package including other changed files like config.h in the coming days.

jt41time wrote:2. this code will make the rx/tx (uart) throw out frsky telem?

Yes.

jt41time wrote:3. I can use a 3dr type radio and send this back to my 9xr(modded) and i can see the telem info on screen?

In particular, it works with FRSKY telemetry receiver/transmitter combos for the D-serie (standard telemetry, D8R-IIPlus, D8R-XP) or X-serie (S.PORT telemetry, X6R, X8R).

jt41time wrote:4. I do not need a level inverter if I'm not useing frsky modules?

You need a level inverter between the FRSKY receiver and the flight controller's serial port. You need another one between the FRSKY transmitter and your 9xr (mod required). You don't need a level inverter if you use the FRSKY FLD-02 display.

jt41time wrote:5. Can i do this with MW 2.3? or 2.4 only?

You can do so manually like described here http://www.multiwii.com/forum/viewtopic.php?f=7&t=1929&hilit=direct+telemetry But, that was still something unofficial. Meanwhile FRSKY telemetry became a part of the official main trunk https://code.google.com/p/multiwii/source/browse/#svn%2Ftrunk%2FMultiWii_shared.

jt41time · Post by **jt41time** » Wed Jul 08, 2015 12:29 am

"In particular, it works with FRSKY telemetry receiver/transmitter combos for the D-serie (standard telemetry, D8R-IIPlus, D8R-XP) or X-serie (S.PORT telemetry, X6R, X8R)."

If it can get send over the 3dr (uart), then i dont need any of this equipment right?
also, is so, then i wouldn't need any other inverters.

I use a bidirectional 1w link(not 3dr radios). but it works like the 3dr. I send mavlink over it and then the uart gets thrown into the 9xr direct. Works great. But i need something for my MW copters. and i cannot buy (broke as a joke) any other equipment.

QuadBow · Post by **QuadBow** » Sat Jul 11, 2015 6:39 am

Hi all,
I just want to inform you that I have uploaded the files with S.PORT function provided by LutzB.
https://code.google.com/p/multiwii/source/browse/#svn%2Ftrunk%2FMultiWii_shared
So S.PORT users are invited to test and comment.

Hi LutzB,
What about an implementation guide for S.PORT? Could you contribute something similiar to https://code.google.com/p/multiwii/wiki/Frsky_Telemetry_Implementation ?

szakacs · Post by **szakacs** » Fri Jul 17, 2015 1:38 am

I am trying to implement this on a HK Multiwii Pro board and a X8R receiver.
I believe I have configured and uploaded the Multiwii 2.4 with S.Port correctly.
I have built an inverter as descibed here http://i.imgur.com/n7iS5LW.png.
My problem is that as soon as I connect the inverter the MWC freezes/crashes.
I have found that as soon as I connect the S.Port signal to the inverter the signal leds, led2 and led3 on the MWC board flash quickly for a second and then stay full on.
As a test I seperated the tx / rx signal from the S.Port. As soon as I connect the Rx side to the S.Port the MWC board freezes.
Am I missing a step somewhere ?? any help would be appreciated.

QuadBow · Post by **QuadBow** » Fri Jul 17, 2015 2:33 am

Hi szakacs,
Thank you for your feedback. Since I have committed the code without own S.PORT equipment, I am seeking for support from the community, in order to overcome this issue.

Hi LutzB,
I have changed the code you provided slightly in order to get rid of compiler warnings and errors.
May I ask you to test the code from the main trunk https://code.google.com/p/multiwii/source/browse/#svn%2Ftrunk%2FMultiWii_shared? Maybe I have built-in a mistake...

LutzB · Post by **LutzB** » Fri Jul 17, 2015 6:08 am

szakacs wrote:I am trying to implement this on a HK Multiwii Pro board and a X8R receiver.
I believe I have configured and uploaded the Multiwii 2.4 with S.Port correctly.
I have built an inverter as descibed here http://i.imgur.com/n7iS5LW.png.
My problem is that as soon as I connect the inverter the MWC freezes/crashes.
I have found that as soon as I connect the S.Port signal to the inverter the signal leds, led2 and led3 on the MWC board flash quickly for a second and then stay full on.
As a test I seperated the tx / rx signal from the S.Port. As soon as I connect the Rx side to the S.Port the MWC board freezes.
Am I missing a step somewhere ?? any help would be appreciated.

This looks to me more like a hardware problem. Can you check that there is no short in your circuit? I built my converter with the same diagram, so I can confirm that it is working.

I will test the code in the trunk this weekend just to be shure.

szakacs · Post by **szakacs** » Fri Jul 17, 2015 7:22 am

LutzB what value transistors did you use ??. I used PN2222A general purpose NPN switching.

gandalf33 · Post by **gandalf33** » Fri Jul 17, 2015 9:34 am

OpenTX 2.1 impact on Taranis Telemetry

I have updated my radio to the latest 2.1 rev of OpenTX, which had an impact on my regular (non SPORT) telemetry. I'll try to list here the impact has I discover them. The main one is that VBAT did not get recognized anymore, to fix it, I have used a different FRSKY ID to transmit it :

in telemetry.h add :
#define ID_VFAS_NEW 0x39

in telemetry.cpp
replace :

Code: Select all

// Voltage (Ampere Sensor) 
void inline send_Voltage_ampere(void) // Data compatibel to FrSky FAS-100 voltage sensor, FLD-02 uses only analog data A1 and A2
{
  #if defined (VBAT) and not defined(FRSKY_FLD02)
      uint16_t voltage;
      uint16_t Data_Voltage_vBat_bp;
      uint16_t Data_Voltage_vBat_ap;   
      voltage = ((analog.vbat * 110) / 21);
      Data_Voltage_vBat_bp = voltage / 100;
      sendDataHead(ID_Voltage_Amp_bp);
      write_FrSky16(Data_Voltage_vBat_bp);
      Data_Voltage_vBat_ap = ((voltage % 100) + 5) / 10; 
      sendDataHead(ID_Voltage_Amp_ap);
      write_FrSky16(Data_Voltage_vBat_ap); 
  #endif  

  #if defined(POWERMETER)
      uint16_t Data_Voltage_I_Motor;
      Data_Voltage_I_Motor = analog.amperage;
      sendDataHead(ID_Current);
      write_FrSky16(Data_Voltage_I_Motor);   
  #endif
}

by

Code: Select all

// Voltage (Ampere Sensor) 
void inline send_Voltage_ampere(void) // Data compatibel to FrSky FAS-100 voltage sensor, FLD-02 uses only analog data A1 and A2
{
  #if defined (VBAT) and not defined(FRSKY_FLD02)
      uint16_t voltage; 
      voltage = analog.vbat * 10; // with ID_VFAS_NEW you need to send the number of 1/10th of volt you have
      sendDataHead(ID_VFAS_NEW);
      write_FrSky16(voltage); 
  #endif  

  #if defined(POWERMETER)
      uint16_t Data_Voltage_I_Motor;
      Data_Voltage_I_Motor = analog.amperage;
      sendDataHead(ID_Current);
      write_FrSky16(Data_Voltage_I_Motor);   
  #endif
}

Once that change is done, the Taranis will pickup valid VFAS values, add the telemetry source accordingly, and you can setup voltage source to vfas.

As a positive side effect, it solves the issue mentionned here : viewtopic.php?f=15&t=6177 as the heading now accept very well negative value

G

LutzB · Post by **LutzB** » Fri Jul 17, 2015 10:17 am

szakacs wrote:LutzB what value transistors did you use ??. I used PN2222A general purpose NPN switching.

Same here.

gandalf33 · Post by **gandalf33** » Fri Jul 17, 2015 11:56 am

Actually, that 2.1 change is so much cleaner that it makes debuging much easier ! So, in current state, altitude does NOT get transmited to Taranis, the reason being that it requires bp and ap as bellow :

Code: Select all

    #define ID_Altitude_ap        0x10
    #define ID_Altitude_bp        0x21

and the altitude send routine then becomes :

Code: Select all

  #if defined(TELEMETRY_ALT_BARO) and BARO
      int16_t Data_altitude;
      Data_altitude = (alt.EstAlt + 50) / 100;
      sendDataHead(ID_Altitude_ap);
      write_FrSky16(Data_altitude);
      sendDataHead(ID_Altitude_bp);
      write_FrSky16((int16_t) alt.EstAlt);
  #endif

QuadBow · Post by **QuadBow** » Fri Jul 17, 2015 2:45 pm

Hi gandalf33,

Thank you very much or your input concerning the Taranis radio.
I got one question as to the firmware: Are you using the original firmware or OpenTX?

Currently, I am integrating your code changes into the main trunk. You mentioned that the current code is not that clear. You are right, but considering many configurations (e.g. Taranis) makes the code more complex, of course...

In priciple, I don't see any obstacle to integrate your proposal on the voltage.

However, it is still not clear to me what you intend with the altitude change. The altitude (variable alt.EstAlt) is stored in centimeters. My code sends meters. So, is there a need to have the full resolution? Does your Taranis display centimeters?

gandalf33 wrote: #if defined(TELEMETRY_ALT_BARO) and BARO
int16_t Data_altitude;
Data_altitude = (alt.EstAlt + 50) / 100;
sendDataHead(ID_Altitude_ap);
write_FrSky16(Data_altitude);
sendDataHead(ID_Altitude_bp);
write_FrSky16((int16_t) alt.EstAlt);
#endif

If so, you have to change your code, since you send a value of (160 centimeter + 50) / 100 = 2 meter as after point portion and the full value of 160 centimeters as the before point portion. This gives you a result of 160.02. Could you clarify this, please?

gandalf33 · Post by **gandalf33** » Fri Jul 17, 2015 3:08 pm

Hello quadbow

I'm using the opentx firmware (since that's what it was delivezred with), but yesterday, a new version has been released, 2.1.0. This version revamps completely the way the Taranis handles telemetry. In short, when you create a blank model, there is no telemetry. Once you bind it, it starts reading the telemetry entries, and populate your sensors list accordingly (and only properly detected sensors). Because of that I was able to see the missing 'sensors' while before, I was never sure if it was rejected because of formatring for exemple, or because the data was not compatible. Another GREAT benefit is that you can choose the sensor unit, not more knots for GSpeed for exemple, you can choose your unit (m/s, km/h,...)

I had a doubt as well for the code, but your code is this :

Code: Select all

  #if defined(TELEMETRY_ALT_BARO) and BARO
      int16_t Data_altitude;
      Data_altitude = (alt.EstAlt + 50) / 100;
      sendDataHead(ID_Altitude);
      write_FrSky16(Data_altitude);
  #endif

i was unsure of why you where doing that so copied it, as very obviously, you know more than me on the subject ! Since the value changes very frequently, it is very tough to see if the value matches the java gui, but since you introduced a reasonable doubt, I have taken a picture of the taranis screen side by side with the gui, and you are right, there is a différence, i'll change the code accordingly

I know Taranis is a strange beats, but I love it so much ! Attached is my multiwii main telemetry screen

QuadBow · Post by **QuadBow** » Fri Jul 17, 2015 7:14 pm

Hi gandalf33,

Thank you very much for your fast response.
I just wanted to make sure that the after point value really can be displayed.
As you mentioned, it a challenge to abserve the least centimeter values due to flickering - that was the reason for me to round the altitude to meters.

You don't have to change anything, I will take care of it.

QuadBow · Post by **QuadBow** » Sat Jul 18, 2015 5:05 am

Hi gandalf33,

I am just implementing your proposals and wondering, whether you measure the voltage directly or whether you use a FAS-100 device?
Have you also tested the other variables like gps coords, speed, course, amperage, acceleration, temperature, time,.. ?