Hi all,
I just bought an FrSky Taranis for my quad copter and needed to get the Mavlink data up on the Taranis LCD telemetry display. So here is my solution using a Teensy3.1 as a converter between MavLink and the S.Port on FrSky X8R.
See attached file below...
Replies
thx,
i also noticed that something is strange with gps on teensy2. maybe because the softSerial and the high amount of frsky messages we transmit. i will try to decrease messages by removing not needed messages like accelerator x y z and pitch values. also gps altitude is not important for the lua script.
if you comment the function call "parseStatusText(statustext.severity, statustext.text)" this will nit change the estimated memory use. so i am wondering why this help. if you compile on arduino ide on the bottom left you see the estimated memory use against the available board memory. tests on teensy2 give me good results if i reach ~ 500byts free. so maybe you can try to comment some more text messages in Average.ino. the strings eats a lot of memory.
/g
wolke
hi,
i fix the gps problem in last commit. hopefully it works correct also on locations with negative gps coordinates. i am in Europa. we have positive values here.
the problem on teensy2 was, that abs() produce arithmetic overflow with the ap_longitude and ap_latitude value.
/g
wolke
I have tested your latest commit on a pro mini and still no go.
Still have to comment out
parseStatusText(statustext.severity, statustext.text); to get the data to flow
and the GPS is still garbled numbers.
hmm,
need more info because the gps problem on pro mini. for example debug output from for example (ap_latitude/100)*6 in FrSkySPort.ino "FrSkySPort_ProcessSensorRequest(uint8_t sensorId)" case SENSOR_ID_GPS: .
"parseStatusText(statustext.severity, statustext.text)" is not the problem. the problem are the amount of strings initialised in Average.h " void parseStatusText(int32_t severity, String text)". i test it on an similar atmel 328p based board. you must comment ~18 strings more as on teensy2 to reach an working setup. this mean it is only an memory problem. not the Flash Memory, i mean the estimated memory consume from sRam. atmega 32u4 have 2,5kb sRam and atmega328 2kb.
/g
wolke
I looked at the "parseStatusText(statustext.severity, statustext.text)" and you are correct. not that I ever doubted you, I commented out a heap of strings and the data started flowing.
Unfortunately I am punching far above my weight range and have no real idea on how to solve the GPS issue. My problem is that I do not have a full understanding of the math being applied. So I will be patient and hope somebody else has time to look at this issue..
I could not leave it alone and after some trial and error I have a GPS solution that works on a pro mini.
If somebody could explain why it works I would be grateful.
What I came up is this :-
uint32_t latlong2 = 0;
case 0: // Sends the ap_longitude value, setting bit 31 high
if(ap_fixtype==3) {
if(ap_longitude < 0){
latlong2 = ap_longitude * -1;
latlong=(latlong2/100)*6 | 0xC0000000;
}
else
{
latlong=(ap_longitude/100)*6 | 0x80000000;
}
FrSkySPort_SendPackage(FR_ID_LATLONG,latlong);
}
break;
case 1: // Sends the ap_latitude value, setting bit 31 low
if(ap_fixtype==3) {
if(ap_latitude < 0 ){
latlong2 = ap_latitude * -1;
latlong=(latlong2/100)*6 | 0x40000000;
}
else
{
latlong=(ap_latitude/100)*6;
}
FrSkySPort_SendPackage(FR_ID_LATLONG,latlong);
}
break;
This is based on https://github.com/wolkstein/MavLink_FrSkySPort/commit/b5e4f546df3d...
what I found is that the pro mini would not work with :-
if(ap_fixtype==3) {
if(ap_latitude < 0 ){
latlong = latlong * -1;
latlong=(ap_latitude/100)*6 | 0x40000000;
If I change to this :-
Create a new variable -- uint32_t latlong2 = 0;
if(ap_fixtype==3) {
if(ap_latitude < 0 ){
latlong2 = ap_latitude * -1;
latlong=(latlong2/100)*6 | 0x40000000;
It works on the pro mini.
I am from Sydney Australia and our latitude is negative.
I am a complete newbee at this, but what I see is that the
latlong = latlong * -1; is the issue
i think you found this here: https://github.com/wolkstein/MavLink_FrSkySPort/commit/b5e4f546df3d...
i noticed that math abs() on teensy 2 and pro mini produce an arithmetic overflow ot variable ap_latitude and ap_longitude . thats why i remove abs() and use the simple methode (*-1) to generate absolute values.
inside the original code for teensy3.1 math abs was used. maybe because teensy3.1 is 32bit hardware math abs() works correct here.
Thinking that rather than having all the strings in parseStatusText, you could length check the strings in combination with a check of the first x characters required for each string to make it unique in combination with the length. It's a bit of a hack... But I'd hoped it'd get around the RAM constraint.
Was going to try it myself, had been playing on a pro mini, then a pro micro, then I bricked my micro and someone gave me a 3d printer and Oh look, a squirrel!
I also had the GPS weirdness. Not debugged yet due to time and squirrel factor, am in Sydney, Australia if that helps.
Same battery gauge , Ivales roll&pitch section and Wolkes radar, and status texts like scottyfly .
Wolkes code did have voice alerts for prearm checks I just didn't realise because I hadn't copied all the sound files, but now there is a text screen as well.
-
90
-
91
-
92
-
93
-
94
of 186 Next