Harakiri aka multiwii port to stm32

strips · Post by **strips** » Thu Sep 11, 2014 1:15 pm

Mr-Fiero wrote:@ Crashpilot1000

maybe this might work better. I have more to do on it but its a start. Basic settings are in there. I am not a coder, so I dont know where to put only the UBX configs. Anyways, I figure this would enable me to use gps_type = 1 and have these settings push to the Ublox.

https://github.com/mr-fiero/TestCode3/b ... /drv_gps.c

Sweet! Good work Mr-Fiero!

I was tempted to do this but was put off when I figured it would take time and manual work

Mr-Fiero · Post by **Mr-Fiero** » Thu Sep 11, 2014 4:15 pm

NEO6 25mm Ant

if anyone wants this file, the min SV elevation has been set to 6. Its better and will drift less, but you will see less SV's (which is a good thing if they are noisy). Stock params has it at 4. I sometimes run my units at 8, so this file is a trade off in-between and should work pretty good. The other previous changes have also been applied to this config. I do not have extra MSG's running(not needed), but it does include the SVINFO being active.

115200 baud port speed.
Messages Active :
NAV-DOP
NAV-POSLLH
NAV-SOL
NAV-STATUS
NAV-SVINFO
NAV-TIMEGPS
NAV-VELNED

Mr-Fiero · Post by **Mr-Fiero** » Thu Sep 11, 2014 4:43 pm

strips wrote:
Mr-Fiero wrote:@ Crashpilot1000

maybe this might work better. I have more to do on it but its a start. Basic settings are in there. I am not a coder, so I dont know where to put only the UBX configs. Anyways, I figure this would enable me to use gps_type = 1 and have these settings push to the Ublox.

https://github.com/mr-fiero/TestCode3/b ... /drv_gps.c

Sweet! Good work Mr-Fiero!

I was tempted to do this but was put off when I figured it would take time and manual work

I am still working on it. It should be pushing, but I have an issue when I switch gps_type = 1, the FC does nothing after. Its very strange. There is no reason I can see since its only pushing to the uart2Write exactly whats in the code. But I know its something in that block because i had the gps_type by default to 4 and it works until i stich to type 1. Once I figure out how to push it, I want to finish putting all the better settings into the Ublox config defaults on the gps driver file. If I can get it all working, it would be nice especially if auto-baud worked. I'll figure it out....eventually.

strips · Post by **strips** » Thu Sep 11, 2014 5:18 pm

Mr-Fiero wrote:
strips wrote:
Mr-Fiero wrote:@ Crashpilot1000

maybe this might work better. I have more to do on it but its a start. Basic settings are in there. I am not a coder, so I dont know where to put only the UBX configs. Anyways, I figure this would enable me to use gps_type = 1 and have these settings push to the Ublox.

https://github.com/mr-fiero/TestCode3/b ... /drv_gps.c

Sweet! Good work Mr-Fiero!

I was tempted to do this but was put off when I figured it would take time and manual work

I am still working on it. It should be pushing, but I have an issue when I switch gps_type = 1, the FC does nothing after. Its very strange. There is no reason I can see since its only pushing to the UART1 serial exactly whats in the code. But I know its something in that block because i had the gps_type by default to 4 and it works until i stich to type 1. Once I figure out how to push it, I want to finish putting all the better settings into the Ublox config defaults on the gps driver file. If I can get it all working, it would be nice especially if auto-baud worked. I'll figure it out....eventually.

If I knew how to set up dev environment and debugging I could take a look at it. But have no experience with C. I prefer PLSQL and xNIX scripting but that's no help here.

Crashpilot1000 · Post by **Crashpilot1000** » Thu Sep 11, 2014 6:54 pm

Mr-Fiero wrote:...
I am still working on it. It should be pushing, but I have an issue when I switch gps_type = 1, the FC does nothing after. Its very strange. There is no reason I can see since its only pushing to the uart2Write exactly whats in the code. But I know its something in that block because i had the gps_type by default to 4 and it works until i stich to type 1. Once I figure out how to push it...

Hi!
The original config block has a size of less than 190 Bytes so an unsigned bytevariable is used as counter. Your config block looks bigger than 255 byte so you have to change one line here: https://github.com/Crashpilot1000/TestC ... gps.c#L231

Code: Select all

    uint8_t i;

to

Code: Select all

    uint16_t i;

That will solve your trouble.
Cheers Rob

Mr-Fiero · Post by **Mr-Fiero** » Thu Sep 11, 2014 7:17 pm

GPS testing might SUCK today. my weather certainly does.

http://www.thesuntoday.org/solar-observ ... e-and-cme/

Mr-Fiero · Post by **Mr-Fiero** » Thu Sep 11, 2014 7:18 pm

Crashpilot1000 wrote:The original config block has a size of less than 190 Bytes so an unsigned bytevariable is used as counter. Your config block looks bigger than 255 byte so you have to change one line here: https://github.com/Crashpilot1000/TestC ... gps.c#L231
Code: Select all
    uint8_t i;
to
Code: Select all
    uint16_t i;
That will solve your trouble.
Cheers Rob

Thank you very much....I will test tonight then on the FC. Somehow I knew it was the array lengths . that's why i was re-doing exact lengths in the config block to see if it would pass it better. I cant wait to try it now that you pointed out the issue. I think it was not per array, but the whole block(never thought of that, and I wouldn't of recognized it like you did), and it was probably aborting on something like port settings, or just crashing all together on proc.

Mr-Fiero · Post by **Mr-Fiero** » Fri Sep 12, 2014 1:08 am

@ Crashpilot1000 Oh, wow, works very well now. Thanks for the help Rob. Now is there any way I can compile with https://github.com/mr-fiero/TestCode3/b ... /drv_gps.c to the absolute newest code? I would like to test everything with the new Gtune and I dont think you have posted current sources...I might be missing where it is so if i am, just ignore me...when i did a fork, it included an old config i was playing with from your master, and it didnt have any Gtune in it cause when I added Gtune to the config.c, it had compile errors in my fork.

oh, and another thought. Do you have an idea that the gpsinit could be sent first at 9600buad every boot, then send a second time at the set gps baudrate? If this could be done, it would enable every GPS to always preset no matter what. This would be very useful say for a gps that has no eeprom as ublox likes to default to 9600. I suck at programming...i dont know it and would really appreciate any ideas...thanks in advance. I can probably figure out a way to do it, but it will be messy code probably. lol.

btw, about the pictures of the mod, i did take some with a USB microscope. I just dont remember where I put them on my drives so when I find them, I will post them.

Mr-Fiero · Post by **Mr-Fiero** » Fri Sep 12, 2014 2:27 am

Oh, my, I just flight tested and wow, i got a tight PH.

All I did is compile my git fork, but with my config.c from my fork as well, calibrated the mag, and acc, set my aux, and flew.... Thats it. No changes.

check the video. Yes it dropped in alt, but that was me bringing it down a touch only.
https://plus.google.com/114605860380045 ... ww6XVPXrNG

This is my indoor machine. lol. so GPS was not properly setup or tweaked. I usually only use this machine for practice indoors when the weather is really bad. The blades are not even balanced. I should do that though soon. just lazy about it.

Crashpilot1000 · Post by **Crashpilot1000** » Fri Sep 12, 2014 3:22 am

Thanks for the feedback and the video! There are currently no changes in drv_gps.c besides yours - so you can simply exchange the files. There are some changes in config.c you might consider. I did a "diff" and they showed up...:

This line was changed: https://github.com/Crashpilot1000/TestC ... nfig.c#L78 . Reason: Some ppl seem to like messing with some android app during flight, so if they *somehow* issue the command "reset config" they might loose their coptertype (hex/octo etc), RX configuration etc. while airborne. So this simple check avoids that. Maybe not relevant for you but just a safety fix before someone finds that the hard way.

You will have to add this line: https://github.com/Crashpilot1000/TestC ... fig.c#L212
and this https://github.com/Crashpilot1000/TestC ... fig.c#L231
and this https://github.com/Crashpilot1000/TestC ... fig.c#L147
and uncomment the G tune stuff here: https://github.com/Crashpilot1000/TestC ... fig.c#L215

The ublox baudrates are forced here in "UbloxForceBaud" https://github.com/Crashpilot1000/TestC ... gps.c#L292 .
So it does exactly what you propose if I understand you correctly. So it throws the "set wanted baud string" at the ublox at 5 different baudrates (9600, 19200, 38400, 57600, 115200) because it does not know where the ublox stands at power up. At the end of the sequence it is assumed that the ublox understood the command at some point of time (probably on the first 9600-run). After that the/your config block is transmitted.

Mr-Fiero · Post by **Mr-Fiero** » Fri Sep 12, 2014 3:24 am

So it does exactly what you propose if I understand you correctly. So it throws the "set wanted baud string" at the ublox at 5 different baudrates (9600, 19200, 38400, 57600, 115200) because it does not know where the ublox stands at power up. At the end of the sequence it is assumed that the ublox understood the command at some point of time (probably on the first 9600-run). After that the/your config block is transmitted.

Thats what I had hoped it would do. I saw that in the code but didnt know if it worked. I will test with a GPS set to 9600 and see if it works.

update:

when i uncomment the Gtune in config.c, i get compile errors.

Code: Select all

                     ^
%% config.c
.//src/config.c: In function 'resetConf':
.//src/config.c:212:8: error: 'config_t' has no member named 'rc_oldyw'
     cfg.rc_oldyw                  = 0;          // [0/1] 0 = multiwii 2.3 yaw, 1 = older yaw
        ^
.//src/config.c:215:8: error: 'config_t' has no member named 'gt_lolimP'
     cfg.gt_lolimP[ROLL]           = 20;         // [10..200] Lower limit of ROLL P during G tune.
        ^
.//src/config.c:216:8: error: 'config_t' has no member named 'gt_lolimP'
     cfg.gt_lolimP[PITCH]          = 20;         // [10..200] Lower limit of PITCH P during G tune.
        ^
.//src/config.c:217:8: error: 'config_t' has no member named 'gt_lolimP'
     cfg.gt_lolimP[YAW]            = 20;         // [10..200] Lower limit of YAW P during G tune.
        ^
.//src/config.c:218:8: error: 'config_t' has no member named 'gt_hilimP'
     cfg.gt_hilimP[ROLL]           = 70;         // [0..200] Higher limit of ROLL P during G tune. 0 Disables tuning for that axis.
        ^
.//src/config.c:219:8: error: 'config_t' has no member named 'gt_hilimP'
     cfg.gt_hilimP[PITCH]          = 70;         // [0..200] Higher limit of PITCH P during G tune. 0 Disables tuning for that axis.
        ^
.//src/config.c:220:8: error: 'config_t' has no member named 'gt_hilimP'
     cfg.gt_hilimP[YAW]            = 70;         // [0..200] Higher limit of YAW P during G tune. 0 Disables tuning for that axis.
        ^
.//src/config.c:221:8: error: 'config_t' has no member named 'gt_pwr'
     cfg.gt_pwr                    = 0;          // [0..10] Strength of adjustment
        ^
.//src/config.c:231:8: error: 'config_t' has no member named 'esc_nwmx'
     cfg.esc_nwmx                  = 1;          // NewMix: 0 = mwii style, 1 = scaled handling of maxthrottlesituations
        ^
make: *** [obj/NAZE/config.o] Error 1

Oh, its not important, my only reason for a fork was for a workspace, so i'll just pull to local from your repo and replace the gps driver file. Thats all i wanted to work on anyways. I will keep the fork, only to update that file as there is some more trivial settings I want to always push to the GPS. If you test the file and like it, you can always put it in the master. maybe you could have a gps_type = 5 as Ublox tweaked

Crashpilot1000 · Post by **Crashpilot1000** » Fri Sep 12, 2014 4:01 am

I was thinking you download the actual sourcecode (https://github.com/Crashpilot1000/TestC ... master.zip) then replace drv_gps.c with your version then patch up your config.c (make a copy..) and copy it over as well. That should do it. The compile errors you see seem to be mainly missing definitions in mw.h and that means you didn't download the actual source?
EDIT: Uups you already explained that... sorry dude!
Cheers Rob.

Mr-Fiero · Post by **Mr-Fiero** » Fri Sep 12, 2014 5:03 am

OK, I compiled with your defaults Rob, only replacing the drv_gps.c . Gtune is working fine again from your master repo.

Anyone want to help me test? here it is for anyone who is interested. This HEX has a modified drv_gps.c file, and its only an experiment at this point. my own experiment to try to enhance the Ublox GPS engines the best I can. The real magic of course of anything working with GPS is Harakiri (and MultiWii). I'm just trying to get the Ublox to work a bit better.

set gps_type = 1 will use the new Ubx protocol settings/tweaks so no GPS programming should be required via Ucenter
but you still have to set your own settings in Harakiri and have a tuned machine before testing GPS functions.

Backup your known working settings if you are already tuned.
once flashed, put your settings back into your FC
also, make sure mag calibration, and acc are done, or GPS functions will not enable
use a map before flying, on your gui, and see if it looks like it has less deviation. Also, you can tell if its updating NAV rates fast as this config has updates at 5.95Hz.
It wont matter the generation of Ublox you have, your GPS will take these configs fine as they apply to all Ublox. I dont do anything to newer GLONASS so dont worry.

Remember, everyone, this file is only for ones who are interested in trying something new. Dont risk your machine if you cannot beta test. I have flown on the new GPS configs myself, but further testing is needed. I however have not flown on this newest hex file, but it did compile correctly and is working on my 450 with Gtune working as well. It seems to be working. Only waiting for the weekend to test more.

If anyone does test, let me know if it was a tighter PH than usual on your machine. My hopes are if it works better for everyone, maybe it will make its way into Harakiri master repo.

strips · Post by **strips** » Fri Sep 12, 2014 6:21 am

Mr-Fiero wrote:OK, I compiled with your defaults Rob, only replacing the drv_gps.c . Gtune is working fine again from your master repo.

Anyone want to help me test? here it is for anyone who is interested. This HEX has a modified drv_gps.c file, and its only an experiment at this point. my own experiment to try to enhance the Ublox GPS engines the best I can. The real magic of course of anything working with GPS is Harakiri (and MultiWii). I'm just trying to get the Ublox to work a bit better.

set gps_type = 1 will use the new Ubx protocol settings/tweaks so no GPS programming should be required via Ucenter
but you still have to set your own settings in Harakiri and have a tuned machine before testing GPS functions.

Backup your known working settings if you are already tuned.
once flashed, put your settings back into your FC
also, make sure mag calibration, and acc are done, or GPS functions will not enable
use a map before flying, on your gui, and see if it looks like it has less deviation. Also, you can tell if its updating NAV rates fast as this config has updates at 5.95Hz.
It wont matter the generation of Ublox you have, your GPS will take these configs fine as they apply to all Ublox. I dont do anything to newer GLONASS so dont worry.

Remember, everyone, this file is only for ones who are interested in trying something new. Dont risk your machine if you cannot beta test. I have flown on the new GPS configs myself, but further testing is needed. I however have not flown on this newest hex file, but it did compile correctly and is working on my 450 with Gtune working as well. It seems to be working. Only waiting for the weekend to test more.

If anyone does test, let me know if it was a tighter PH than usual on your machine. My hopes are if it works better for everyone, maybe it will make its way into Harakiri master repo.

Cool. So this is with Robs latest source and your ublox config? I might be able to give it a run today. But have to tape/strap down a gps on my Nemesis first

Need to design a top battery / gps mount and print it at some point.

Regarding any other config already existing on the GPS. I believe only the lines being pushed by Harakiri now will change. So by your comment with Glonass it will still be enabled if it was already enabled?

Mr-Fiero · Post by **Mr-Fiero** » Fri Sep 12, 2014 6:26 am

yes its Robs code pulled from repo just a few hours ago.

Does not matter whats on your GPS, I am trying to push everything via the changes in the GPS driver file. But it does not do an EEPROM save, so your Ublox will be fine with its already programmed config. Just while you boot with this firmware, it will re-program while using.

I dont touch GLONASS at all, mostly because I was working on generation 6. If its enabled, it will stay that way. I dont like GLONASS being enabled myself as it only has to add more deviation, but you can test with it and see if it does anything. You can also disable it yourself via ucenter and re-test. I would be curious of those results, but i dont have a generation 8 engine. generation 7 wont do both at the same time, its one or the other, so its not a good test. My configs only overlay already existing configs in the Ublox. They are common settings and will be compatible with newer generations. nothing is permanent either. a power cycle of the GPS will restore its own programmed settings via EEPROM.

strips · Post by **strips** » Fri Sep 12, 2014 7:36 am

Mr-Fiero wrote:yes its Robs code pulled from repo just a few hours ago.

Does not matter whats on your GPS, I am trying to push everything via the changes in the GPS driver file. But it does not do an EEPROM save, so your Ublox will be fine with its already programmed config. Just while you boot with this firmware, it will re-program while using.

I dont touch GLONASS at all, mostly because I was working on generation 6. If its enabled, it will stay that way. I dont like GLONASS being enabled myself as it only has to add more deviation, but you can test with it and see if it does anything. You can also disable it yourself via ucenter and re-test. I would be curious of those results, but i dont have a generation 8 engine. generation 7 wont do both at the same time, its one or the other, so its not a good test. My configs only overlay already existing configs in the Ublox. They are common settings and will be compatible with newer generations. nothing is permanent either. a power cycle of the GPS will restore its own programmed settings via EEPROM.

Thanks,

I'll try to set my Neo 8 to defaults and see if Harakiri does flash it. Both Glonass and GPS is active by default. I will try to connect by USB after it has been flashed by Harakiri. I don't know if it will work of fry it but its all bent in the corner anyways

By connecting USB I should be able to connect ucenter while its also connected to Harakiri

I don't have to many hours to test so we will see what I can manage at the model airfield today.

strips · Post by **strips** » Fri Sep 12, 2014 8:26 am

Oh no.. I just found what broke on my Neo8. The USB port. I can see a SMD diode missing an it is probably a protection diode. Well, still got the serial line

scrat · Post by **scrat** » Fri Sep 12, 2014 9:30 am

This code works on rev5?

strips · Post by **strips** » Sat Sep 13, 2014 12:02 am

scrat wrote:This code works on rev5?

Yes. TestCode3 works on Naze32 rev5. That'd what I'm using.

strips · Post by **strips** » Sat Sep 13, 2014 12:09 am

Tried to get my Nemesis airborne today. Had to give up. The rubber bobbins between clean and dirty part of frame is way too soft. Trying gtune it couldn't get PIDs low enough. I could see the clean part almost be stable in air while dirty part was oscillating heavily. So I have just replaced the rubber bobbins with aluminum standoffs. Maybe I can test tomorrow.

Mr-Fiero · Post by **Mr-Fiero** » Sat Sep 13, 2014 2:18 am

Everything is pushing fine...I setup a GPS with really obvious wrong settings and it pushed from the FC....but, the autobaud is not working! I tried with the GPS at 9600 and it would not communicate. but once set to 115200, the GPs grabbed all other settings fine.

So, my next wish/step is to look at how to push atleast to the 9600 baud initially as all Ublox's are this setting by default.

watch out, these days right now are really bad for GPS because of the sun flare activities. So make sure you do a fair compare.

Mr-Fiero · Post by **Mr-Fiero** » Sat Sep 13, 2014 7:01 am

strips wrote:Tried to get my Nemesis airborne today. Had to give up. The rubber bobbins between clean and dirty part of frame is way too soft. Trying gtune it couldn't get PIDs low enough. I could see the clean part almost be stable in air while dirty part was oscillating heavily. So I have just replaced the rubber bobbins with aluminum standoffs. Maybe I can test tomorrow.

I had an issue like that on one unit, all i did for a quick fix that worked very well, is stick a square piece of soft foam inbetween the dampeners to give it more stability. It was on a unit that I thought I would mount everything above the dampeners. I mean everything including camera. I thought having more mass up above would dampen more. It did, but also had the side effect of being sluggish on sensing the movements. It was so bad, it would oscillate back and forth quickly on any and all axis. So the foam was a desperate move as I wanted to fly that unit with the camera that takes stills. Its worked VERY well to this day, so I didn't bother with a re-design. If it ant broke, dont fix it....right? So it stays as it is now.

I find with the 32bit boards, they don't suffer the same issues for vibration anyway. It seems that it can filter it out very well. I have one unit that has no dampening, and has vibrations bigtime and it flies nice with Harakiri/flip32+.

just a thought for a quick fix.

My batts are charged! Hopefully I can have a busy day flying tomorrow. Our weather has been pretty crappy for the last week, so lets see if we get a good day in.

Mr-Fiero · Post by **Mr-Fiero** » Sat Sep 13, 2014 7:28 am

OK, I found a pict of the SAW filter added to the Neo6. I will post an edited photo later and try to explain it. Right now you can see the board before I cleaned it and if you look close on the right top section, you can see the filter added right at the input of the ublox engine. After the SAW, I had to re-route the power for the active antenna and that is why you see the cap, and resister moved the way they are. I did not have room to keep the antenna connector, but I wont miss it. I prefer a solder connection.

When I was done, I conformal coated the whole board, and then put heat-shrink around everything and sealed the ends of the heat-shrink by pinching together with forceps (works awesome) while the heat-shrink was still very hot.

https://plus.google.com/114605860380045 ... eZvV2earWG

When I flowed the solder, I used a low temp solder paste and also protected the ublox engine from heat. With the low temp solder paste it melted at 280. very low, and this minimized any damage to other parts.

It was very small work, and I had to use a magnifying glass. I guess I am showing age cause i used to be able to see small stuff. I have done %50 of my GPS's this same way and they seem to work pretty good. But I'm not sure yet if I like it. Its the cheapest way to filter the GPS but its a bit of an effort. I think better filtering will always be best at the source, where second and third harmonics originate. Its just more expensive for low pass or high pass filters. But I am a cheap ass, and I am glad to save money, even if I have to punish myself. lol. keeps the learning curve up.

Crashpilot1000 · Post by **Crashpilot1000** » Sat Sep 13, 2014 5:36 pm

Mr-Fiero wrote:...Everything is pushing fine...I setup a GPS with really obvious wrong settings and it pushed from the FC....but, the autobaud is not working!..

The code is basically this: https://code.google.com/p/multiwii/sour ... PS.cpp#251.
I trusted in Mr eos Bandis work and didn't dig deeper into that so I haven't been digging not half as deep as you into that matter but I think you might be right and wrong at the same time. I think that code was designed to feed mainly ublox that have no eeprom and they default understanding nmea. I think those codes might not be understood if ublox is in binary only mode? The Ubx speed change is also used in passgps and I changed the speed a lot there and it always worked (too lazy to wire up an FTDI to ublx each time..). I tested the ubx with: 38400, 57600, 115200 Baud because only these Baudrates can cope with the data at 5Hz and are relevant for in flight operation.
Maybe it is better to outline that the gps_type = 1 is more for the ppl that have a factory default ublox and want to have it setup for a working result and gps_type = 4 is for the advanced user that can customize it with ucenter for the best result in their region (esp thinking of Australia here.. Japanese Sbas sats trouble/troll them and that must be Timecops fault ... no, just joking..). But I am really open for suggestions in that area to change the config block to somthing better and I definitely stand by to be corrected because I am not sure how many BS I just wrote.
Thank you very much for posting a picture of your SAW filter wire-up! I am not allowed to run 1.3GHZ here but hey, many ppl will find it very useful!
Here are some links that also deal with that subject that might be interesting:

Basic Ucenter usage for dummies like me:
https://code.google.com/p/ardupirates/w ... PSTutorial

1.3GHZ Video and GPS disturbance:
http://www.electronicarc.com/catalogo/p ... 3da12ba890
http://diydrones.com/forum/topics/arduc ... %3A1175591
http://diydrones.com/forum/topics/arduc ... %3A1175524
http://diydrones.com/forum/topics/arduc ... %3A1178440

Groundplate:
http://diydrones.com/forum/topics/arduc ... t%3A868946
http://autoquad.org/wiki/wiki/autoquad- ... oundplane/
http://autoquad.org/software-downloads/?did=1
http://diydrones.com/forum/topics/how-to-gps-shield

Cheers Rob (sorry for my Grenglish)

Mr-Fiero · Post by **Mr-Fiero** » Sat Sep 13, 2014 6:02 pm

My settings I have put into the driver were somewhat conservative so its more compatible for everyone, but still has fixes needed. gps_type = 4 I will still use for more aggressive settings myself. the array i posted in the driver is one that can be used by everyone that uses 32bit compatible flight controllers. 8bit just wont do the baud rates, and therefore are self limiting for NAV/Info rates. Especially if SVINFO is being sent over the serial. I have not found any settings in Ublox for a different update rate for SVINFO. I wish, NAV could be 5Hz and SVINFO could be 1Hz, but there are no specific settings to do that. Something I am researching into.

You are thinking right about why its not autobaud. but, why have it so elaborate. Its very clear, either a GPS is programmed, or not. If not they will always be 9600. So why not just send first time at 9600, and then at 115200? You are also right, 115200 buadrate is desired for several reasons, first delays, second so we can have higher NAV rates. These flight controllers handle that baud, so why would anyone want less speed? The best solution however, is to look at having it autobaud, and then set the port speed to whatever the FC is set for gps buad. I will look at that with my limited programming skills, and see if there is a fix. If I can fix it for the Ublox it would be best for slower FC's and they would be able to use it as well by just having buad set in their params. 8bit FC's are good with 38400 buad, and sometimes 57600 without errors on the serial line.

You know, if I knew programming better, you can poll the Ublox on init, have it read status, put it in variables, and then have the active vars print at a status screen. If only, I knew code.......

About the extra filters I need, is because I am licensed as a tech class in amateur radio, so I use OpenLRS freqs, 1.2Ghz video and both interfere with my GPS if I am not carefull. I use filters on every frequency. Open LRS has a harmonic in my video freq, and video has a harmonic/spur on the GPS. I can see the harmonics/spurs with the Anritsu sitemaster I have onhand. With all my filters, at this point everything is working very well, but its really tight. One good thing, if I am ever flying with someone else, the chance of ever interfering with their stuff is minimal.

Mr-Fiero · Post by **Mr-Fiero** » Sat Sep 13, 2014 9:37 pm

I flew a total of 8 batteries @ 4400mah x 15minutes per today. GPS PH was working very well for me. I was flying my junker quad with the toasted bearings that for some reason keeps on chugging. Its actually my fav just because its an anomaly. I have new bearing, but I'm just seeing how long it lasts since I started using that RCL1000 lube. There is no way it should of lasted this long. The lube is freakin awesome. I lube every day after 2hours of flight.

One thing though, I have never really tested the range, but today i flew it 190M high, and 1890M away. I was very surprised to still have video as on this unit its only a 1.2Ghz 100mw TX. I guess my homemade antenna's rock. I am very surprised, and its actually kinda fun. I can cover my whole town now. Even more. Yes, I did test my fail-safe first before attempting this. Also tested RTH a few times.

One thing that happened this time, and has happened in the past. While flying the altitude reset to 0. I was about 100M high when it happened, but nothing else reset like distance to home. Its not a big deal because I already knew my height, so when it resets to 0, i just use that as my current altitude, and adjust accordingly to the new readings. Like I have said, I have seen it before, but its very rare. Its nothing to do with GPS either as i had 9SV's and everything was fine at the time. I was flying in PH, but it didnt seem to do anything when it hit 0 on the reading. It did not climb, or descend, but still held position.

Gtune worked very well, but it did over-adjust slightly. I ran it long enough to see it start to twitch, then it would adjust back, then up again till twitch. i let it run a few cycles of this and it didnt seem to average in the middle. i did this for 5 minutes, but then decided once it smoothed, to de-activate Gtune, land, and save. I am really enjoying the Gtune as it makes for a quick setup.

strips · Post by **strips** » Sat Sep 13, 2014 11:56 pm

I have been playing with gtune to dial down my Nemesis. I am suprised how different roll and pitch is. It is still slightly wobly but I'll probably be able to turn it down a bit my self.No more battery and it's too late to do more tonight

I had to lower the low limit on gtune to 1 to get this result.

I did some quick tests on PH but got some heavy drift and aborted as I do not have much space out on the porch. Remembered I had forgot to set magnetic declination. Just to verify. +2deg 23 min east is set as 223?

Still a short test after this and trimming acc it held for 15 - 20 sec and it suddenly wanted to go somewhere. Aborted and will test more later. As Mr-Fiero has pointed out there is some solar activity going on and I am experimenting with GPS+Glonass. Am using gps_type 4. Got 14 - 16 sats. HDOP indoors in ucenter <1.

@Rob
How about sending sat count and/or HDOP (if available) to telemetry. A mavlink->FrSky project I have seen are using temp2 as sat count. This would be awsome for logging on my Taranis.

What's the reason for "- Set minimal looptime to 3000" in the readme? I just tested on looptime=2000 and esc rate 490.

regards
Stian

Crashpilot1000 · Post by **Crashpilot1000** » Sun Sep 14, 2014 2:13 am

Dude, plz tune up the copter from ground (acro) to top (GPS).
1. Set up your copter properly (acro, level, mag and THEN do GPS)
2. The Gtune result shows that you generally need more p on the Pitch than the Roll axis that is for sure. If you are happy with the numbers is a different story I can not comment on. Maybe Gtune isn't working for you then - however do you have a link to your copterdesign? Maybe it's something with its' geometry?
3. Looptime. Harakiri is in its' most parts independent of the looptimes (contrary to Multiwii, Baseflight and Cleanflight) however a looptime of 3ms is recommended because setting it lower will cause to much fail of keeping the predefined timeframe because GPS functions will break up a targeted looptime like 1ms (1000) or so. Lower Looptimes are supproted for ppl that don't use additional stuff. So maybe they see an advantage running at 2ms. Gtune has just been tested with 3ms looptime.
4. Frsky: Show me the documentation of "temp2" and every available parameter can be sent at your wish (I have no taranis here).

strips · Post by **strips** » Sun Sep 14, 2014 7:59 am

Crashpilot1000 wrote:Dude, plz tune up the copter from ground (acro) to top (GPS).
1. Set up your copter properly (acro, level, mag and THEN do GPS)
2. The Gtune result shows that you generally need more p on the Pitch than the Roll axis that is for sure. If you are happy with the numbers is a different story I can not comment on. Maybe Gtune isn't working for you then - however do you have a link to your copterdesign? Maybe it's something with its' geometry?
3. Looptime. Harakiri is in its' most parts independent of the looptimes (contrary to Multiwii, Baseflight and Cleanflight) however a looptime of 3ms is recommended because setting it lower will cause to much fail of keeping the predefined timeframe because GPS functions will break up a targeted looptime like 1ms (1000) or so. Lower Looptimes are supproted for ppl that don't use additional stuff. So maybe they see an advantage running at 2ms. Gtune has just been tested with 3ms looptime.
4. Frsky: Show me the documentation of "temp2" and every available parameter can be sent at your wish (I have no taranis here).

Thanks, yes I know lower level functions should work before trying a higher level function. But I'm at a point where it should work after doing this stuff way too late at night. Just some minor tuning left. Gtune has given me a very much better starting point. I would never have made changes as gtune has.

I'll revert looptime to 3ms. Even though everything else was working ok it might have thrown the GPS out of wack. I could not see any better or worse gtune performance/tuninig with 3ms or 2ms looptime.

You got a quick overview of FrSky telemetry values here https://github.com/vizual54/APM-Mavlink-to-FrSky/blob/master/Protocol.txt. Some use an implementations of temp2 as sat count and fix type uses 3 digits. 2 first are sat count and last is fix (0-1 is no fix, 2 is 2D and 3 is 3D). So 083 would be 8 sats and 3D fix. I really don't know if you need fix type? I always seem to have 3D. Analyzing log would be annoying with this setup.

What is the best value(es) for verifying GPS quality? Maybe sat count in temp2 (0x05) and horizontal_accuracy/HDOP in fuel (0x04)?

Mr-Fiero · Post by **Mr-Fiero** » Sun Sep 14, 2014 8:30 am

2D and 3D can be set in Ublox. by default you will usually show a 3D fix after 4SV's. Harakiri by default wants 6SV's, so that's fur sure a 3D fix. I fly alot with anything over 6SV's and have excellent PH. Yes there is a flag of status, but its not valuable. PDOP HDOP would be nice to have displayed, but its not really that critical. I find if I use my android in the field connected via Bluetooth to the FC, I look at the map for what my deviation looks like. If it stays tight, then everything is good. I like a pre-flight check any ways. Battery voltage also as a pre-flight check on the OSD is nice, cause atleast I know I did not mix batts up. If ever I do not have my phone, the light flashing on the FC gives you the number of SV's. You need 6 before flight, before arming because your home position will be set. Usually after my first cold start, if I get what looks good, my following warm starts are just as good and usually the same SV's within 20 seconds. I give the following flights a minute or two any ways. I don't usually check the gui after my first one. I have never had an issue. either the day is good, or very noticeable, bad.

Several times when I find it is bad for deviation, I then check the android for solar radian levels, and it always verifies what I already saw. Its not too often there is a bad day, maybe once a month, but since I am having good success with my GPS, I am not second guessing any more. This has been the same on every one of my units.

Strips, try a lower acc lpf setting (default is 10 maybe your higher?) . maybe your motors are a bit hot for your craft and its trying to compensate by low PID's. That of course is assuming your balanced and dont have a major vibration issue. I myself have never seen such low values. I do however understand that your pitch and roll are different. I saw Gtune compensate on one of my crafts that my vibration dampeners are closer together on roll. They are closer because the mount was for an APM2.5. With your craft your roll is more sensitive because side to side your craft is narrow. But, your values on your roll are really abnormally low. Gtune did find something, it is needs to be looked at. also, once you fly, check your motors in the CLI. dont reboot, just log in and they will give you total load percentages for each motor and you can look for anything abnormal. Just a good check.

Rob is right. For GPS its critical to have it tuned. Really critical. You have mentioned in the past I think about vibrations. I had a craft, that last week, I found a bent motor shaft. Ever so slight and hard to notice. It was always a little quirky, and my PH was not as tight. It was always a bitch to tune. One night I was just tinkering and thought I could hear the bell housing scrape the magnets. It was very hard to hear. Took it apart and checked the shaft, and yep, it was bent. Replaced it, and wow, everything locked in on the craft. It works so well now. I cant believe it made that much difference. So, it does not hurt just to take a really close look.f
-------------------------------
Yea, I flew 2180M 190M high with only 100mw 1.2Tx video, and survived. LOL. I so freakin impressed. Yea, I had to beat my previous distance......I was very close to battery life (not including my safety margin) due to a slight wind today working against me. Now I cannot wait to make the light weight multicopter my main one. (I still like my beater multicopter the best) I have already tested it to use 1/3 less power. Gtune did tune it really nice and it flies good. everything is awesome on it and it does PH very well also. the only thing missing is a video cam and I need another 100mw tx. I want to keep it light so I have to order the 11g 700TVL camera on ebay when budget permits.

strips · Post by **strips** » Sun Sep 14, 2014 9:38 am

Think I found a nasty bug!

I am testing with FrSky X4R-SB RX. Where I'm using SBUS to CPPM converter. On the RX you set fail-safe mode on the TX. I select "No Pulse" to simulate a failing RX og RX getting disconnected. The Naze32 reboots when I turn off my Taranis to test failsafe. This happens when armed and flying or disarmed.

Just for kicks I also pulled the servo cable (PPM) and Naze32 starts to beep regularly they way it should. So obviously the SBUS to CPPM decoder and/or RX does something funny Harakiri or Naze32 doesn't like. Looks like I have to dig up the old scope and see what's going on.

strips · Post by **strips** » Sun Sep 14, 2014 3:19 pm

@Mr-Fiero
Thanks.

I do not have much vibrations. I'm very satisfied with my new HQProp 5040. What difference will acc lpf do in rate mode? I have replaced my rubber bobbins with alu so the FC should feel all vibrations/minor movements. I have emptied 4 batteries today and gtune actually went all the way down to 1.0! It is actually very smooth and acceptable in rate mode. I ended up in roll P = 1.2. Maybe this is because the KISS ESCs with regenerative breaking? They might give more control on lower P?

My setup is no longer over powered. I have 3S on 2300kv and 5040 props. AUW is ~550-570g and throttle is just above 50% in hover.

My problem now is self level. It's very sluggish and low on pitch. Roll is good enough.

And I had to test PH on the airfield. I verified 17SVs in GUI and seemingly very stable lat/long coordinates. I took off in PH and it flew almost straight forward 100 meters before I took control. This happened every time. Of course I took of in the same direction every time. So I do not know what is going on.

stevef1966 · Post by **stevef1966** » Sun Sep 14, 2014 6:54 pm

hi yall, what is the advantage of installing this firmware over the current 2.3 from the baseflight GUI, sorry i am new :-)

Mr-Fiero · Post by **Mr-Fiero** » Sun Sep 14, 2014 7:01 pm

strips wrote:And I had to test PH on the airfield. I verified 17SVs in GUI and seemingly very stable lat/long coordinates. I took off in PH and it flew almost straight forward 100 meters before I took control. This happened every time. Of course I took of in the same direction every time. So I do not know what is going on.

I know you probably did this, but it seems that you have nothing for GPS functions. I could see maybe a few meters if things are not perfect, but not 100M. If the mag is not calibrated you will have no GPS functions. Do a "status" in CLI just to make sure. The fact you know your number of SV's tells me you have communication as you would of had to read it via OSD or something else connected to the FC. Something is wierd.

That is good you said Gtune has you in better values and it seems more stable.

strips · Post by **strips** » Sun Sep 14, 2014 8:18 pm

stevef1966 wrote:hi yall, what is the advantage of installing this firmware over the current 2.3 from the baseflight GUI, sorry i am new

GPS functionality is the biggest reason to go for Harakiri. It requires more work in CLI to set up as there is no GUI for most functions.

strips · Post by **strips** » Sun Sep 14, 2014 8:36 pm

Mr-Fiero wrote:
strips wrote:And I had to test PH on the airfield. I verified 17SVs in GUI and seemingly very stable lat/long coordinates. I took off in PH and it flew almost straight forward 100 meters before I took control. This happened every time. Of course I took of in the same direction every time. So I do not know what is going on.

I know you probably did this, but it seems that you have nothing for GPS functions. I could see maybe a few meters if things are not perfect, but not 100M. If the mag is not calibrated you will have no GPS functions. Do a "status" in CLI just to make sure. The fact you know your number of SV's tells me you have communication as you would of had to read it via OSD or something else connected to the FC. Something is wierd.

That is good you said Gtune has you in better values and it seems more stable.

I am still very low on P on roll! But I got a pretty smooth rate mode and horizon is acceptable. I can flip with ease

I tested with gps_type = 1 now and your config got pushed. I only get 9SVs now

Obviously Glonass gets deactivated but I'm not sure because I can not get gps passthrough to work. It worked earlier today.

Take a note that I have not changed anything else other than gps_type = 1. Now I get a pretty agressive toilet bowl. So I re-calibrated mag but its the same. I did some flying only in mag and i get the occational unwanted yaw. So I believe I got mag interference or maybe the GPS gets swamped by RX and VTX antennas.

So I need to do more mag-flying to make sure it's rock solid.

But the 100m "flyaway" I can not explain. Because it worked now with no changes. Right before it flew 100m strait ahead I did view the GPS in Baseflight GUI. Thats when I had 17 sats.

Mr-Fiero · Post by **Mr-Fiero** » Sun Sep 14, 2014 8:51 pm

I did nothing in the config for GLONASS, its just not there. No string is sent for that. the fact you are seeing less SV's, is because its now rejecting noisy or inaccurate ones. This is better than allot of bad SV's.

I agree with you, something must be up with your mag. also, maybe try a little less gps_expo just to see if it tightens your PH up a bit.

Vertigo · Post by **Vertigo** » Sun Sep 14, 2014 9:34 pm

Is there an (idiot) guide to downloading, installing and configuring harakiri?

rank · Post by **rank** » Mon Sep 15, 2014 1:39 am

Any1 is using mini32 with Harakiri? Planning to put it on a miniquad.

strips · Post by **strips** » Mon Sep 15, 2014 8:06 am

Vertigo wrote:Is there an (idiot) guide to downloading, installing and configuring harakiri?

I have a quick and diry post about flashing here http://www.rcgroups.com/forums/showthread.php?t=1653753&page=285#post28963817.

This fw requires some research. Reading this thread should get you far

strips · Post by **strips** » Mon Sep 15, 2014 8:25 am

Mr-Fiero wrote:I did nothing in the config for GLONASS, its just not there. No string is sent for that. the fact you are seeing less SV's, is because its now rejecting noisy or inaccurate ones. This is better than allot of bad SV's.

I agree with you, something must be up with your mag. also, maybe try a little less gps_expo just to see if it tightens your PH up a bit.

Lowered gps_exp by half. I thought I had a sloppy PH. It was messing back and forward and semi-circling in a radius of about 2 - 4 meters. But it broke out of circling and slowly drifted in one direction at lest 10m before I took control. Actually I'm not sure if it was in PH mode the way it moved. So I'm back at fixing the mag interference. I have a H-quad where the PDB is about 2.5 cm below Naze32. And the battery cable sticks out to the side on level with the PDB and backwards. And the battery is resting 4-5cm above the Naze32. I had hoped routing the wiring away from Naze would do the trick. I need to look into strapping the batt under the quad as a first test. Maybe a groundplane between Naze and PDB.

I have another question. Should I be able to have two way comm with GPS passthrough? I was able to view the GPS output in U-center with passthrough yesterday. But I can't seem to get it to work today. Is it enough just to click "PassGPS" in Baseflight GUI?

Mr-Fiero · Post by **Mr-Fiero** » Mon Sep 15, 2014 3:35 pm

in theory PassGPS in baseflight GUI would work, but its really hit and miss.

I usually drop to a terminal, then enable passgps from there, once in that mode, then I exit the terminal, and then open baseflight gui directly in that tab. Seems to work better. The FC will stay in that mode until reboot.

tomm · Post by **tomm** » Mon Sep 15, 2014 7:17 pm

@rob
regarding number of sats on frsky telemetry there was a topic some days ago on a german forum.
http://fpv-community.de/showthread.php?22307-TELEMETRIE-am-NAZE32&p=665861&viewfull=1#post665861
schnellmaleben posted some code fragments, but it's over my head to add this to harakiri, so maybe it's a good time to ask

would be nice to have, especially cause i can't see the leds on my flip32.

@mr fiero
excellent work on gps-settings. with your settings on an older ublox 6, i get less sv's but a much better ph.
or better to say, i have a working ph at all since testcode 3.
many thanks, both of you

regarding passgps for dummies (like me)
command is not only 'passgps' but passgps followed by a number in exchange to the baudrate. took me some time, cause i always tried it with 'passgps 115200', what is (obviously) wrong notation.
and as mr fiero already mentioned: best (or probably only) way to use it, is from cli

Mr-Fiero · Post by **Mr-Fiero** » Mon Sep 15, 2014 7:33 pm

and as mr fiero already mentioned: best (or probably only) way to use it, is from cli

Once you activate passgps it from the CLI, close terminal (FC stays in passgps mode till reset), you can run the gui after and connect. Make sure you are already selected on the gps tab, and correct baud in gui. While the FC in in passgps, You can also connect with Ucenter this way. Or even switch between both. but if you switch, just make sure you close comm before next program want to use that comm port.

I actually use passgps, and connect over Bluetooth, and or gui. Its forgiving, but while in that mode, its only GPS info, so don't expect any other menus in gui to work (till reboot/reset). You already know that I'm sure, I am just being clear for others.

I am glad you had a better PH! I too had good success this weekend, and it worked on 3 of my units very well. I am still wanting to test over time, just to be sure, but it was nice PH for me this weekend as well. I was also using Neo6 engines on everything I had, two units with 25mm antenna, and one with 35mm.

Baldrick · Post by **Baldrick** » Tue Sep 16, 2014 11:47 am

Just found this forum and I'm pleased to find there is a lot of good info on here. Thanks to all contributors to this thread and please excuse my dumb questions.....

1 Does the gpspass allow you to send data to the gps ? I connected to u-centre using gpspass and can read the gps data, but if I change a parameter and "send" it to the gps, then reconnect, the parameter reverts back to the old one. I don't know if it's not sending it, or the gps is not storing the change. I changed the gps type to 4 before doing this.

2 Every time there is an update or a patch to the Harakiri software do I have to re-flash the new update and re-input all my changed pids/settings ? Or is there any way to just install the patch ?

3 Do I need to change anything on the gps in u-centre ( e.g pedestrian mode ) or will the software change ALL the needed settings if I use gps_type =1 ?

strips · Post by **strips** » Tue Sep 16, 2014 12:12 pm

Baldrick wrote:Just found this forum and I'm pleased to find there is a lot of good info on here. Thanks to all contributors to this thread and please excuse my dumb questions.....

1 Does the gpspass allow you to send data to the gps ? I connected to u-centre using gpspass and can read the gps data, but if I change a parameter and "send" it to the gps, then reconnect, the parameter reverts back to the old one. I don't know if it's not sending it, or the gps is not storing the change. I changed the gps type to 4 before doing this.

2 Every time there is an update or a patch to the Harakiri software do I have to re-flash the new update and re-input all my changed pids/settings ? Or is there any way to just install the patch ?

3 Do I need to change anything on the gps in u-centre ( e.g pedestrian mode ) or will the software change ALL the needed settings if I use gps_type =1 ?

1. Don't know yet. But to store settings in Ucenter it is not enough to just send. You need to save config to store values.

2. It is always recommended to set default or erase and restore backup.

3. Depends on what settings your gps comes with. If you set gps_type 1 Harakiri will push it's configuration to the gps. With gps_type 4 you need to configure the gps.

Baldrick · Post by **Baldrick** » Tue Sep 16, 2014 12:27 pm

1 didn't know that. I will try a save config as well.

2 o.k

3 I know it pushes the config to the gps, but does it send ALL the recommended parameters, or just the important ones ?

Thanks for the quick reply......

Mr-Fiero · Post by **Mr-Fiero** » Tue Sep 16, 2014 6:14 pm

@ strips. Yes, you can push config while in gps pass, I do it quite often, even over the bluetooth. On my computer though, I have to have Ucenter set to 9600 buad when using bluetooth even if everything else is set to 115200.

@ baldrick, fyi, you should atleast set the baudrate in uncenter. I dont find it always works for finding the gps buad before gps_type = 1 pushes config. My experimental hex/firmware I last posted, wants 115200 buad on the GPS port.

bulesz · Post by **bulesz** » Tue Sep 16, 2014 6:17 pm

Crashpilot1000 wrote:...
@Bulesz: Thanks for the BF4 fight on Tuesday! .. Though "lancang dam" ended up in a nasty baseraping session... leaving no chance for them ... that was not very gentleman like....but hey, they would have done the same with us. BTW: I think they hated our supply/engineer/attack heli combo...
...
Cheers, happy WE and no crashes!
Rob

We can play that "flying tank" anytime mate!

bulesz · Post by **bulesz** » Tue Sep 16, 2014 6:38 pm

Crashpilot1000 wrote:
....

@Vertigo: I should do a readme on the failsafe. If the internal Failsafe of Harakiri (not speaking of internal FS settings of your receiver here) is triggered it tries the best to do something healthy with the copter depending on available sensors and their status. If GPS becomes unhealthy and a Baro is present it will center the (virtual) roll / pitch sticks, engage level mode (and magmode to try stabilizing yaw) and do an autolanding (without PH because GPS isn't working..).
Please look into config.c for details on parameters.

Besides having FEATURE_FAILSAFE enabled there are some variables that might be of interest for you:
https://github.com/Crashpilot1000/TestC ... fig.c#L279
https://github.com/Crashpilot1000/TestC ... fig.c#L295
Code: Select all
cfg.rtl_mnh = 0; // (0 - 200m) Minimal RTL hight in m, 0 disables feature
cfg.rtl_cr = 80; // [10 - 200cm/s] When rtl_mnh is defined this is the climbrate in cm/s
cfg.rtl_mnd = 0; // 0 Disables. Minimal distance for RTL in m, otherwise it will just autoland, prevent Failsafe jump in your face, when arming copter and turning off TX
cfg.gps_rtl_flyaway = 0; // [0 - 100m] 0 Disables. If during RTL the distance increases beyond this value (in meters relative to RTL activation point), something is wrong, autoland

cfg.fs_delay = 10; // in 0.1s (10 = 1sec)
cfg.fs_ofdel = 200; // in 0.1s (200 = 20sec)
cfg.fs_rcthr = 1200; // decent Dfault which should always be below hover throttle for people.
cfg.fs_ddplt = 0;   // EXPERIMENTAL Time in sec when FS is engaged after idle on THR/YAW/ROLL/PITCH, 0 disables max 250
cfg.fs_jstph = 0; // Does just PH&Autoland an not RTL, use this in difficult areas with many obstacles to avoid RTL crash into something
cfg.fs_nosnr = 1; // When snr_land is set to 1, it is possible to ignore that on Failsafe, because FS over a tree could turn off copter
Will it fly to the African East coast (as Naza's seem to do), or will it hover, autoland, or something?

Yes, why not, probably pretty places there... Ok serious now. If something goes wrong (like jammed motor in an hexa/octo etc, suddenly mag going crazy, strong unfightable wind etc.) and copter is spiraling away the calculated distance between the homeposition on engaging RTL and the currently gps reported spot distance to home will increase and not decrease like expected. So the RTL is a return to somewhere else for whatever reason. That's where gps_rtl_flyaway comes into play. Lets say you set gps_rtl_flyaway = 50 (meters).
Failsafe occurs 800m away from the homepoint and RTL is engaged (you or failsafe). Those 800m are calculated and stored for comparison. If on the supposed way home the distance increases beyond your threshold of 50 m (like distance suddenly 850m) it will try PH and autoland. So it will flyaway but not too much.
fs_ddplt is a dead pilot detection in seconds. So if the RX is still receiving healthy but unchanged signals for that period of time (in seconds) dead sticks/internal TX error or a dead pilot is assumed and FS engaged.
fs_jstph is for the people that don't want RTL (even if possible) but just a PH and autoland (flying in the woods or other cluttered areas).
rtl_mnh is the minimal hight in meters BEFORE RTL to avoid trees etc. So copter does PH checks if minimal hight is ok, climbs if necessary (with predefined climbrate rtl_cr) and then does RTL. So if rtl_mnh = 35 (meters, more than enough to avoid trees in my area..) and RTL engaged in 100 m hight, no climbing/descending is done just RTL sequence (autoland).
fs_rcthr is just for the guys that don't have a baro to ensure a smooth autolanding (that value is ignored, if baro is present). Even the cheapest Bosch baro can save your copter a great deal (broken arms, bent motors etc..), so hard to understand why not to have such a simple safety device even if no althold is desired in flight. If it's going down with a baro guided autolanding or just a predefined throttle makes a difference... that difference can be much more expensive than a 4$ BMP breakout board...
rtl_mnd is the minimal distance in meters where a complete RTL sequence with - if defined rtl_mnh - is done. Reason: Failsafe can be just engaged if the copter is airborne. The airbornestatus is assumed after an autostart sequence (like as_trgt = 2 (meters), althold and throttlestick middle -> airjump to 2 meters - don't try this indoors...) or if the esc_nfly throttle is exceeded. So in the worst case you exceeded esc_nfly on the ground and the copter thinks it could be airborne and you have set a minimal RTL hight like rtl_mnh = 35 meters and something goes wrong with your transmitter (you turn it off, or it fails) it will do PH and climb to 35 m and that maybe into your face. So if you set rtl_mnd = 20 meters an RTL sequence in that radius around the homeposition will not be possible, you will have to walk and pick it up. If RTL is triggered (by you or failsafe) beyond that distance, a complete RTL will be done.

What is a Homeposition in Harakiri?
The homeposition is set when Harakiri has a valid set of Lat/Lon GPS coordinates and the copter is armed. So simply watch the red led. It will start to flicker when 5 sats are found and you can count the flickers to know how many sats are seen right now. After a flicker block a pause of 2 seconds is done, then the flickerblock is send again. Example: you see it flicker 2 times and then pause (ca. 2secs) and then flicker again lets say 3 times. You know Harakiri received valid GPS data coming from 6 sats and then having most probably better data from 7 sats etc. If you arm now your homeposition will be taken from these reported values.
Worst case: User: "Fu** that red LED stuff I want to fly" Lifts off with no red led flicker (no sats, no homepos). During flight a FS occurs (user: "Ohh sh*t..") with no homepos -> Autoland (or no baro: fs_rcthr and fs_ofdel). Or during flight 5 sats are reached and copter (obviously) armed - Homepos set somewhere on the flightpath. FS occurs - copter will do "RTH" to that random point of the flight where the homelock was done.
Other example: Copter is sitting in place A with sufficient GPS reception and was armed but then disarmed and carried to place B while still under power and then armed again - liftoff etc.. In this case the last armingpoint (place B) is the homeposition. So armed status will set a homeposition if at least 5 sats are present, disarming will clear the homeposition.

-Sorry for my bumpy English-
Cheers Rob.

Mate thank you verymuch for your detailed FS explanation!