Baseflight aka multiwii port to stm32

User avatar
Dilbert66
Posts: 45
Joined: Fri Apr 04, 2014 6:09 pm

Re: Baseflight aka multiwii port to stm32

Post by Dilbert66 »

What's with the signed values? Anyhow, after converting back to unsigned int and calculating the crc using the ms5611 algo, I get a calculated crc of "0x0c" which matches the word 7 lsb crc. So this would explain why it shows as a 5611. That would be a rare occurence if this is a fluke. Unless my math is wrong. I just used the algo in a short c program but it seems to confirm the reason. Perhaps your idea of having a cli parameter to force sensors would be benefical in such cases. It's easy enough to add .

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Baseflight aka multiwii port to stm32

Post by e_lm_70 »

Dilbert66 wrote:What's with the signed values? Anyhow, after converting back to unsigned int and calculating the crc using the ms5611 algo, I get a calculated crc of "0x0c" which matches the byte 7 lsb crc. So this would explain why it shows as a 5611. That would be a rare occurence if this is a fluke. Unless my math is wrong. I just used the algo in a short c program but it seems to confirm the reason. Perhaps your idea of having a cli parameter to force sensors would be benefical in such cases. It's easy enough to add .


Hi,

I just pass the value on debug[0] to debug[3] ... and read these from MultiWii Java GUI. So, I guess debug is signed 16bit, while the original was unsigned 16bit

A0 register is undocumented on BMP180 specs ... my guess is that they add on BMP180 a similar function as 5611 .. so the CRC is send back correctly ... I don't believe in "luck"

Anyhow, I understand that I'm one of the very rare person using BMP180 ... and for some strange voodo .. TimeCop BMP180 do behave differently ... so ... it is up to you guy to decide what to do.
Personally I would like to see in the CLI which sensor is activated .. and eventually add and remove sensor via CLI ... and store this in the configuration ... but ... I can live also without it, having my custom firmware running for my boards.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Well, fucking lol. So random numbers in "some" BMP180s will succeed MS5611 CRC check. How freakin annoying.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Baseflight aka multiwii port to stm32

Post by e_lm_70 »

timecop wrote:Well, fucking lol. So random numbers in "some" BMP180s will succeed MS5611 CRC check. How freakin annoying.



I don't believe in "random" in the digital world.

But I totally agree with your with the rest of your post : LOL + freakin annoying :)

So far this did "annoyed" me, and indirectly you and Dilbert66 (sorry for it).

Anyhow, if this did never happen to you, and if you believe it is an exception ... everybody can keep going in his way
Hopefully soon the 5611 chip will be so cheap that nobody will bother to use BMP180

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Well, they're calibration constants (I presume) for analogue-ish (mems) sensors, so yeah, they are "random".
Need to see if there's any other clever way to differentiate. MS5611 first byte in eeprom is "manufacturer reserved" i wonder what's in it..

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Baseflight aka multiwii port to stm32

Post by e_lm_70 »

timecop wrote:Well, they're calibration constants (I presume) for analogue-ish (mems) sensors, so yeah, they are "random".
Need to see if there's any other clever way to differentiate. MS5611 first byte in eeprom is "manufacturer reserved" i wonder what's in it..


While A0 register is documented in MS5611 , this register it is not documented in BMP180.

Checking the MS5611 specs .. the CRC used is only 4bit ... so one "random" sequence every 16 will match the CRC check.

The number produced by BMP180 are always the same, so I don't think it does return any calibration constants .. these constant start in a different place on BMP180 and BMP085.

Maybe more then the first 16bit ... it is more interesting the last 16bit value ... since this should have only a 4bit CRC code, and the other 12 .. possibly should be zero with a MS5611.

I would need to check what is the sequence made by my MS5611.

For me, the most easy and universal solution, it is to avoid the auto sense .. and just make all the sensor configurable by CLI ... 99.99% of Baseflight user will use the 5611+6050+5883 sensor .. so ... just put these as default .. and problem not only solved by even simplified ... and less effort in the future for add new sensors .. like the new 9DOF single chip

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Baseflight aka multiwii port to stm32

Post by scrat »

scrat wrote:I have strange problem...but I don't know if is related to BF firmware and looptime. I have the latest BF from 30.4.2014 on my FC. And have set looptime to 3000 and have strange twitching when flying, but not the whole time. But when I leave looptime at default, there is no twitching?


So...yesterday I've tested again and set looptime to 3000 and there was no twitching...so I think maybe the problem is my UHF system when my Tx battery ges below 10V. I have to wait now till battery goes below 10V and test again and wil report back.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Baseflight aka multiwii port to stm32

Post by e_lm_70 »

e_lm_70 wrote:I did update the code after the 8bit vs 16bit issue

Here is the results

-23148 / 14872 / -10713 / 13705
-21333 / 8266 / -1123 / -14260


This is what I get from a genuine 5611 chip .. only last 4 16bit numbers:

/ / /
29026 / 32430 / 27409 / 12954

At every restart I get the same value there ... so PROM ... maybe these are hard coded factory calibration parameters ...

Anyhow ... since CRC is only 4 bit ... every 16 random sequence , 1 will be a valid from CRC point of view.

I would have hope to see a lower value for the last 16 bits ... since per the specs this number should only pass the 4 BIT CRC, and 12 bit should be unused.

User avatar
Dilbert66
Posts: 45
Joined: Fri Apr 04, 2014 6:09 pm

Re: Baseflight aka multiwii port to stm32

Post by Dilbert66 »

timecop wrote:Well, fucking lol. So random numbers in "some" BMP180s will succeed MS5611 CRC check. How freakin annoying.


Perhaps just put the bmp check before the ms5611 detect and it should work. Of course, now we're depending on the bmp chip id to be meaningful. Is it the same chip id for the 180? Seems to work with Hairy Kerry that way though as e_lm_70 noted :)

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Baseflight aka multiwii port to stm32

Post by e_lm_70 »

I have seen CrashPilot TestCode (HaraKiri) .. and there the Baro sensor detection is first check for BMP085 and then check for MS5611 ... and apparently this approach works for my BMP180.
Anyhow, my guess it is that this was an old approach of Baseflight, that is still on Harakiri ... but for some reason the Baseflight development decided to change it.
So .. I guess that there is/was some reason for it ... so, it does not sound a safe solution at first look.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Dilbert66 wrote:
timecop wrote:Well, fucking lol. So random numbers in "some" BMP180s will succeed MS5611 CRC check. How freakin annoying.


Perhaps just put the bmp check before the ms5611 detect and it should work. Of course, now we're depending on the bmp chip id to be meaningful. Is it the same chip id for the 180? Seems to work with Hairy Kerry that way though as e_lm_70 noted :)


5611 has no chip ID, yeah, maybe it's better to shuffle their order around.
There's 16bit 'manufacturer dependent" bytes on 5611 but it doesn't seem to be documented and is probably not to be relied on...

User avatar
Dilbert66
Posts: 45
Joined: Fri Apr 04, 2014 6:09 pm

Re: Baseflight aka multiwii port to stm32

Post by Dilbert66 »

The ms5611 in the gy86 module i have here has zero for those manufacturer bytes so its not always used

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Yeah, zero doesn't sound like a good number to use for identification..

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Baseflight aka multiwii port to stm32

Post by e_lm_70 »

Somebody did notice the following changes on Baseflight:

-------------------
#ifdef BARO
// Detect what pressure sensors are available. baro->update() is set to sensor-specific update function
- if (!ms5611Detect(&baro)) {
- // ms5611 disables BMP085, and tries to initialize + check PROM crc. if this works, we have a baro
- if (!bmp085Detect(&baro)) {
+ if (!bmp085Detect(&baro)) {
+ // ms5611 disables BMP085, and tries to initialize + check PROM crc.
+ // moved 5611 init here because there have been some reports that calibration data in BMP180
+ // has been "passing" ms5611 PROM crc check
+ if (!ms5611Detect(&baro)) {
// if both failed, we don't have anything
sensorsClear(SENSOR_BARO);
}
-------------------

Is this the official solution to the BMP180 issue ?

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

As it works, might as well.
At least BMP085/180 have "ID" byte which is a fixed value, and is less likely to occur inside 5611 calibration data...

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Baseflight aka multiwii port to stm32

Post by e_lm_70 »

timecop wrote:As it works, might as well.
At least BMP085/180 have "ID" byte which is a fixed value, and is less likely to occur inside 5611 calibration data...


Yes or No ... it would have more easy for "simple" people like me to understand.

So, I take it like a Yes, this is the official solution.

I will give it a go/check/test ... after the weekend ... I have my copter ready for my "official" maiden of DIY Baseflight ... and as you wrote somewhere else "If your copter fly well, don't mess with it"

I see that Baseflight team does react very fast on applying changes ... well done, once again.

Tchuss

e_lm_70

HaDe
Posts: 2
Joined: Sat May 10, 2014 10:15 am

Re: Baseflight aka multiwii port to stm32

Post by HaDe »

Hi,

Short question: which toolchain do you use (GCC or Yagarto)?

Long background: my codesize after building the Naze target (using the unmodified current Makefile & sources from GitHub) always seems to end up in about 75-77K code size, while the prebuilts are about 60K. The build runs fine, but I was just wondering about what could be the cause of this difference...

Thanks
Hannes.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

I'm using commercial ARMCC compiler to build. I only maintain Makefile for freetards.
Recommended gnu toolchain is gcc-arm-embedded ( https://launchpad.net/gcc-arm-embedded )

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: Baseflight aka multiwii port to stm32

Post by fiendie »

HaDe wrote:Hi,

Short question: which toolchain do you use (GCC or Yagarto)?


Which compiler do you think Yagarto uses?

HaDe
Posts: 2
Joined: Sat May 10, 2014 10:15 am

Re: Baseflight aka multiwii port to stm32

Post by HaDe »

timecop wrote:using commercial ARMCC compiler to build


This perfectly explains the difference in code size - so it sounds like a good idea to use the Keil ARMCC compiler at work. Thanks for the pointer.

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Baseflight aka multiwii port to stm32

Post by e_lm_70 »

timecop wrote:I'm using commercial ARMCC compiler to build. I only maintain Makefile for freetards.
Recommended gnu toolchain is gcc-arm-embedded ( https://launchpad.net/gcc-arm-embedded )


Except for the code size, is there also a difference in performance between the two compiler?

User avatar
Dilbert66
Posts: 45
Joined: Fri Apr 04, 2014 6:09 pm

Re: Baseflight aka multiwii port to stm32

Post by Dilbert66 »

Most likely there is. You would have to do a comparison. This might be more noticeable if math operations were done. A better compiler will be able to optimize code to work for best speed and size. It's a compromise with GCC and most compilers I believe. You can compile for the smallest size, but that does not necessarily mean the code will run faster. That's why there ore different optimization options.

edit: As a very proud "freetard" myself , the only issue I've ever had with gcc and baseflight was that using the default -O0 (no optiomization) option which is usually used when debugging, i2c reads were returning incorrect values. Switching to -01 and above, worked perfectly fine. I now use -O1 for debug and -Os (size) for production hexes

KC_703
Posts: 58
Joined: Thu Nov 07, 2013 5:29 am

GPS Frsky Telemetry Output requires DMM vs. DDD

Post by KC_703 »

I've been chasing this issue for a bit now. The GPS coordinate output to the telemetry seems to be in the form of Decimal Degrees (DDD), where FrSky/OpenTx wants Degrees Decimal Minutes (DMM). Utilizing the DMM output, Companion9x can export directly to Google Earth and the Taranis would properly provide coordinates from the telemetry screens.

The modification of DDD to DMM seems to be a simple call of the proper variables in the Telemetry_FrSky.C code (starting at Line 125). As far as I've researched, standard NMEA messages use DMM and ublox conforms to this standard. This seems to be further corroborated in the ported multiwii code in GPS.C (Line 804) which describes the conversion from DMM to DDD for further GPS functionality.

FrSky's GPS Sensor v2 (without Naze32) was used to verify that DMM provides accurate coordinates to Taranis and telemetry logs.

With the ublox telemetry output, transforming the coordinates from XXXX.XXXX to XX.XXXXXX resulted in accurate plots in Google Earth. Essentially, transforming the coordinates by .01 in a spreadsheet program and coverting to KML yielded accurate flight paths.


Apologies in advance,if I've simplified this too much... I'm not a programmer and only going on the great comments embedded in the code.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

I opened an issue on github ( https://github.com/multiwii/baseflight/issues/110 ) which is what people reporting bugs should really do, instead of posting in a thread here where it can be forgotten/lost :)

KC_703
Posts: 58
Joined: Thu Nov 07, 2013 5:29 am

Re: Baseflight aka multiwii port to stm32

Post by KC_703 »

Thank you! I wasn't sure whether this would get traction with the community... nor how to open a issue ticket. :)

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Hi! Just posted a code (under the issue link) that does degrees, minutes and decimal minutes. I have no taranis or naze->frsky telemetry attached but the output is in line with the frsky telem protocol pdf. So check it out, if it works.

KC_703
Posts: 58
Joined: Thu Nov 07, 2013 5:29 am

Re: Baseflight aka multiwii port to stm32

Post by KC_703 »

Thanks! I'm not a programmer, and probably couldn't compile to check... But I'll take a look and see if I can use some engineering logic / reasoning.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Hi, KC_703!
Np, downloaded the actual BFr497 from TCs' trunc, changed the frsyk telemetry and compiled it.
I attach a zip here to test for you (including the changed telemetry_frsky.c).
Cheers Rob
Attachments
KC_703.ZIP
Bf r497 with changed frsky gps telemetry output to dddmm.mmmm
(86.16 KiB) Downloaded 145 times

KC_703
Posts: 58
Joined: Thu Nov 07, 2013 5:29 am

Re: Baseflight aka multiwii port to stm32

Post by KC_703 »

Got it. Thank you! I'll load the hex and take a look at the results.

User avatar
Dilbert66
Posts: 45
Joined: Fri Apr 04, 2014 6:09 pm

Re: Baseflight aka multiwii port to stm32

Post by Dilbert66 »

Dilbert66 wrote:
Dilbert66 wrote:
timecop wrote:Hmm, weird. Is it the old plastic (white) cap 5611 or the new metal ones?
I've never used plastic, but out of all the ones I shipped with metal cap I never seen this bad prom CRC.
Baro is the most expensive component on my boards, and while they're sometimes available cheap, I go for the "usual" priced ones as I expect the unbelievably cheap ones to be dodgy. First time I'm seeing this tho.

Hm I was gonna suggest reading prom 1 ushort at a time but it seems its already doing that. Doh.


Found the problem. Baseflight defaults to fastmode clockspeed of 400khz for all i2c comms. The ms5611 on the gy-86 can't handle this speed. Switching to 100khz fixes the issue. This is most likely due to the wire lenght I"m using to connect the module to my breakout board. I'll retest again after I shorten the wires. The weird part is the other chips seemed to be ok with it and I was getting consistent values from the barometer. Well, live and learn. I'd rather be able to use the fastest speed possible if I can. At least I know the module is fine.



Hmm, here's a fun fact. Compiling with -Os instead of -O0 with Debug option gives me the correct values and checksum with the sensor connected with a few inches of cable. with -O0, I get the invalid values again. I'm assuming since the compiler is optomizing more for speed with -O0, that creates more noise? Since the release compiles for size -Os, it's a non issue and the sensors work as they should with that setting.


In case anyone cares, I did find the cause of the incorrect I2C reads using -O0 optimization in GCC. It revolved around this little bit of code in drv_i2c.c
read_p[index++] = I2C_ReceiveData(I2Cx); //read data N-1
read_p[index++] = I2C_ReceiveData(I2Cx); //read data N
index++; //to show job completed

I had to change it to:
read_p[index] = I2C_ReceiveData(I2Cx); //read data N-1 <--- no increment in the array load.
index++; <-- increment here instead
read_p[index++] = I2C_ReceiveData(I2Cx); //read data N
index++; //to show job completed

Without the change the second read_p would always return bogus values. Something werid with how GCC compiled this piece. Using -O1 was fine as the optimizer would fix the issue. Just thought I'd note it for anyone using GCC to debug I2c to watch for this.

Dilbert66



Edit: Latest Baseflight has a fix for this now.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

I've done some cleanup with I2C driver and the issue was confirmed to be resolved on IRC. Probably related to gcc stuffing up register allocation during function calls to I2C_ReceiveData(). Thanks for working through this, Dilbert66

KC_703
Posts: 58
Joined: Thu Nov 07, 2013 5:29 am

Re: Baseflight aka multiwii port to stm32

Post by KC_703 »

Crashpilot1000 wrote:Hi, KC_703!
Np, downloaded the actual BFr497 from TCs' trunc, changed the frsyk telemetry and compiled it.
I attach a zip here to test for you (including the changed telemetry_frsky.c).
Cheers Rob


Following up. The code providing degree decimal minutes (DMM) instead of decimal degrees (DDD) works!

Validated that the Taranis is displaying proper coordinates on the telemetry screen. Companion9x is exporting logged coordinates correctly to Google Earth. And Baseflight Configurator is showing the proper coordinates. Awesome!

Thanks, Rob!


How do we submit this to be merged into future revisions of baseflight?

Regards,
Ken

stevea3342
Posts: 1
Joined: Thu May 29, 2014 5:47 pm

Re: Baseflight aka multiwii port to stm32

Post by stevea3342 »

KC_703 shared witih me the beta hex (that he references above)

I had the same 'working' results. GPS data sent through the NAZE32 telemetry pin back to the Taranis now displays the correct coordinates in google earth when launched from the log viewer in Companion9x.

Thank you very much! I didn't test anything else except a short hover around my house, but all looks well so far.
Steve

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Oh, so the frsky pdf was correct! Thx for the feedback guys, when my Rc tx dies I will buy a Taranis as well. Concerning the posted hex: it is Bf r497 so it is affected by the i2c(?) bug that is fixed now by timecop with his actual release. So if I understand it right you could have full throttle freezes when not using sumsignal (but you are probably on the safe ppsum with frsky)! The zip contains the complete telemetry_frsky.c so it's just replacing the file, complaining about codingstyle and type of code submitting :)
Edit: For completeness actual BFr502 with altered frsky gps stuff attached.
Edit: Edit: Here is a link to the diff: https://github.com/hydra/cleanflight/pull/18
Attachments
Bf r502 FrskyGPSfixed.zip
(87.5 KiB) Downloaded 133 times

KC_703
Posts: 58
Joined: Thu Nov 07, 2013 5:29 am

Re: Baseflight aka multiwii port to stm32

Post by KC_703 »

Perfect. I was just thinking about the test hex being pre-sunday firmware.

I'll give it a go when the weather clears up here...

Thanks again!

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Crashpilot1000 wrote:Edit: Edit: Here is a link to the diff: https://github.com/hydra/cleanflight/pull/18


If its not too much trouble, reopen same PR against baseflight codebase to get appropriate commit credit.

dominicclifton
Posts: 202
Joined: Tue Feb 05, 2013 10:28 pm

Re: Baseflight aka multiwii port to stm32

Post by dominicclifton »

yeah, just like this one:

https://github.com/multiwii/baseflight/ ... 918e1ae6ee

Where *I* spotted and and you purposely don't credit me just like with many other recent commits you're taking from cleanflight. Your attitude to open source is appalling Timecop.

Crashpilot, I would not do what he suggests until he changes his policy towards giving proper credit to everyone.

dominicclifton
Posts: 202
Joined: Tue Feb 05, 2013 10:28 pm

Re: Baseflight aka multiwii port to stm32

Post by dominicclifton »

From IRC tonight:

[2014-05-30 01:29:01] <dongs> adcConfig() looks ok
[2014-05-30 01:29:26] <dongs> only thing..
[2014-05-30 01:29:30] <dongs> wonder if it needs to be volatile
[2014-05-30 01:29:34] <dongs> or else shit gets half writes
[2014-05-30 01:29:43] <dongs> it already is
[2014-05-30 01:29:44] <dongs> hm
[2014-05-30 01:30:04] <Lux> perhaps my hardware has some defect
[2014-05-30 01:30:15] <Lux> I'll try again tomorrow

I see that, so I PM Lux

[01:29] <Hydra> lo
[01:30] <Hydra> yes, the adc init is broken
[01:30] <Hydra> can't tell you in channel as I'm still +q
[01:30] <Hydra> i have the solution to the init.
[01:30] <Lux> hmm so why is it working for dongs ?
[01:30] <Lux> or is he trolling
[01:30] <Hydra> see cleanflight latest adc driver
[01:31] <Hydra> it's because the adc dma index, rank and num channels gets mismatched
[01:31] <Hydra> https://github.com/multiwii/baseflight/ ... _adc.c#L68
[01:31] <Hydra> here
[01:32] <Hydra> try my cleanflight code if you want to get readings from the adc channels
[01:32] <Hydra> to verify your hardware works.
[01:32] <Lux> ah yeah i get it now thanks
[01:32] <Hydra> i tested with olimexino initially but now have that code on my two other quads so I can check them out too make sure it''s ok
[01:33] <Hydra> but i see no reason why it would not work on it
[01:33] <Hydra> yeah, that code is a bit shit
[01:33] <Hydra> since the i = 1 could start at 0
[01:33] <Hydra> to remove line 65
[01:34] <Lux> that too yes
[01:34] <Hydra> please tell dongs that hydra fixed it in cleanflight in the channel
[01:34] <Lux> actually i allready looked at your code, but i didn't get what it fixed ^^
[01:34] <Hydra> yeah, it's quite obscure
[01:34] <Hydra> it took me a while to see it too

Then in #multiwii

[2014-05-30 01:36:08] <Lux> there is a mismatch on rev4 hydra fixed it
[2014-05-30 01:36:43] <dongs> how fucking nice of him.
[2014-05-30 01:36:55] <dongs> maybe if he spent time fixing bugs in baseflight instead of jerking off, maybe we wouldn't have this conversation right now
[2014-05-30 01:36:56] <Lux> numchannels is 2
[2014-05-30 01:37:43] <Lux> and then the index of i only goes to one in the adcconfig array
[2014-05-30 01:37:57] <Lux> but powerchannel is index 2
[2014-05-30 01:38:19] <Lux> i allready saw his fix, but didn't see that tiny difference :/
[2014-05-30 01:38:23] <Lux> until now
[2014-05-30 01:39:08] <dongs> feel free to open a pr without giving credit

*that* is the attitude i'm talking about, if anyone was wondering.

dominicclifton
Posts: 202
Joined: Tue Feb 05, 2013 10:28 pm

Re: Baseflight aka multiwii port to stm32

Post by dominicclifton »

While I'm at it I'll list some other commits that were mine, in cleanflight and pull requests opened, but for which Timecop has purposely not credited me for:

https://github.com/multiwii/baseflight/ ... 8c644baf6c
https://github.com/multiwii/baseflight/ ... 55a8e9a47b
https://github.com/multiwii/baseflight/ ... 5bc054bbdc
https://github.com/multiwii/baseflight/ ... a734628a82
https://github.com/multiwii/baseflight/ ... 2e3dd046be

He's doing this out of spite too not because he's lazy and can't work git. In fact git makes it easy with cherry-pick.

LVNeptune
Posts: 19
Joined: Mon Jan 20, 2014 10:54 pm

Re: Baseflight aka multiwii port to stm32

Post by LVNeptune »

That's dongs for you...It's hilarious more than anything. If you don't expect him to be an ass you are doing something wrong :D

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Baseflight aka multiwii port to stm32

Post by copterrichie »

Where is the unity folks? Ha, flew out the windows I assume.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

He's doing this out of spite too not because he's lazy and can't work git. In fact git makes it easy with cherry-pick.

Sorry, I only speak english. I don't know what cherry-pick is. I'm not a berry farmer.

Where *I* spotted and and you purposely don't credit me just like with many other recent commits you're taking from *****flight. Your attitude to open source is appalling timecop.

Regarding your ADC fix, I never looked at it, since I said I have no interest in backporting shit from your toy branch. After Lux pointed out the problem, we discussed and I resolved the situation, without looking at your stuff. Sorry, life is tough. Maybe if you weren't banned from multiwii org for being a cock, you could have opened a PR and got credit.



I reworked input capture shit without looking at your (no doubt obfuscated and behind several layers of indirection) code. Other shit is trivial. If you wanted credit, you should have played by the rules.

You did this all to yourself, without anyone elses help. Now you get to reap what you sow. I even offered you a solution, but instead you kept getting hung up on irrelevant shit.

dominicclifton
Posts: 202
Joined: Tue Feb 05, 2013 10:28 pm

Re: Baseflight aka multiwii port to stm32

Post by dominicclifton »

The only reason i'm banned on multiwii is because you don't like my fork, plain and simple. you can't deal with people that don't have the same goals as you.

I offered many solutions to your points and there was never any rational answers or alternative solutions to the bits you don't like. There was no such solution to your two main sticking points when you offered my the olive branch after admitting defeat, and the stuff you consider is only 'irrelevant shit' is only irrelvent to you, which is why you're still the only developer...

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: Baseflight aka multiwii port to stm32

Post by Crashpilot1000 »

Hi dudes! Just a few codelines with elementary school mathematics - I really need no credit for that. If you want to credit people than give it to KC_703 and stevea3342 for actually finding the issue and testing and reporting back (even signing up in github and here in this forum).
Cheers Rob

P.s.: Both plz keep up the good work!

Edit, Edit: Concerning the change of averaging Rc signals I am not sure if the original mwii code hasn't an advantage with analog equipment (like 40Mhz). However I agree that the averaging can be minimized with todays digital Rc stuff.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

OK, the GPS fix stuff is merged. I'm hoping to get some confirmation from people in the lockup thread and I can start publishing binaries again.

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Baseflight aka multiwii port to stm32

Post by scrat »

timecop wrote:OK, the GPS fix stuff is merged.


This means?

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Baseflight aka multiwii port to stm32

Post by e_lm_70 »

scrat wrote:
timecop wrote:OK, the GPS fix stuff is merged.


This means?


Possibly the FrSky telemetry issue associated to GPS coordinate that Rob did fix some days ago.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

scrat wrote:
timecop wrote:OK, the GPS fix stuff is merged.


This means?


Yes, don't get your hopes up that GPS is actually working :)

e_lm_70
Posts: 297
Joined: Fri Aug 09, 2013 8:35 pm

Re: Baseflight aka multiwii port to stm32

Post by e_lm_70 »

timecop wrote:
scrat wrote:
timecop wrote:OK, the GPS fix stuff is merged.


This means?


Yes, don't get your hopes up that GPS is actually working :)


What make you hate so much the GPS :shock: ?

I see quite some people reporting working GPS functionality on Naze32 using Baseflight and Harakiri
On MultiWii the "father" of BaseFlight, GPS is working (not perfectly, but good enough for most of the usage) since long time.

I understand that you don't want to test it since you don't care, and since you don't test it, you may don't want to bless the GPS support ... still ... the MultiWii functions for support GPS, that I expect are present in BaseFlight too ... are so simple that should not be a big issue to "bless" them.

PS: If you really don't want GPS support .. why you just did not take away the code in charge to RTH and PH inside Baseflight ?

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Baseflight aka multiwii port to stm32

Post by scrat »

timecop wrote:
scrat wrote:
timecop wrote:OK, the GPS fix stuff is merged.


This means?


Yes, don't get your hopes up that GPS is actually working :)


Just asking. But for me GPS works. GPS PH and GPS RTH.

Post Reply