Baseflight aka multiwii port to stm32

Dilbert66 · Post by **Dilbert66** » Mon Apr 07, 2014 3:04 pm

dominicclifton wrote:
tovrin wrote:What is to stop us from taking a page from his book and creating our own fork

Nothing, and git and github encourages this. However, rather than just merging into a new codebase from baseflight why not contribute to baseflight? As a baseflight developer I'd be happier if we all worked together to improve the overall quality of the code and thus the finished product rather than having another fork?

That would be great but unfortunately every project lead has their own ideas of direction and understandably so. The STM32 landscape is so fragmented right now it's confusing. There's baseflight, Harakiri, Taulabs, jihlean's FF32 work, multitudes of forks, support for the F3/F4 variants, etc. Finding a good project to stick to is not easy. One thing I like about Baseflight is the quality of dev's involved in the project and the group having a priority of ensuring only quality code gets included and it uses the right mechanism for devs to collaborate on it (using Git correctly). Not sure I'm impressed with the project lead's people skills but that's a minor point (<ducking behind my desk>

) Harakiri on the other hand, I'd love to try it more as it adds more features that could be fun to play with. But the way it's development collaboration is done and lack of any version control scares the sh.t out of me! Collaborative patches/updates done via upload to a form? A new repository for each development branch? yikes. It is his fork and he can do what he wants of course. I wish him all the best with it though. It has potential but I'll wait till it matures. Taulabs is overly complex and overkill for a simple controller IMHO and semaphores scare me

Awesome work that you are doing with the softserial code and adding more ports to the port starved little F1 board

F3/F4 would solve that by adding more usarts but then that adds more cost and complexity to the little FC that could

dominicclifton · Post by **dominicclifton** » Tue Apr 08, 2014 12:41 am

Dilbert66 wrote:One thing I like about Baseflight is the quality of dev's involved in the project and the group having a priority of ensuring only quality code gets included and it uses the right mechanism for devs to collaborate on it (using Git correctly).

TOTALLY agreed.

Dilbert66 wrote:Awesome work that you are doing with the softserial code and adding more ports to the port starved little F1 board F3/F4 would solve that by adding more usarts but then that adds more cost and complexity to the little FC that could

Thanks, nice to know it's appreciated. Today I got Graupner HoTT telemetry integrated (early stage, but it works) and timecop has already just integrated it into the git repo.

Some details:

https://github.com/multiwii/baseflight/wiki/Telemetry

The code:

https://github.com/multiwii/baseflight/ ... try_hott.c

dominicclifton · Post by **dominicclifton** » Tue Apr 08, 2014 12:42 am

Speaking of things I did today, I created a wiki page so you can see Eclipse and step debugging via GDB in action and some screen grabs of my configuration.

https://github.com/multiwii/baseflight/ ... and-J-Link

Dilbert66 · Post by **Dilbert66** » Tue Apr 08, 2014 1:26 am

[list=][/list]Thats a good eclipse gdb setup. I was always a command line guy but have warmed up to eclipse in recent times. Not having frsky or graupner tx i cant really test the telemetry part but it sure adds versatility. I use 3dr radios for data. Can hott data streams be used for osd ? Too slow i bet. Would need osd firmware to be coded for it too. U been busy.

QAV400 · Post by **QAV400** » Tue Apr 08, 2014 5:11 am

Edited out

dominicclifton · Post by **dominicclifton** » Tue Apr 08, 2014 2:35 pm

Dilbert66 wrote:Thats a good eclipse gdb setup. I was always a command line guy but have warmed up to eclipse in recent times.

Yes it's good these days.

Dilbert66 wrote:Can hott data streams be used for osd ? Too slow i bet.

Yes, too slow and not the right solution anyway, the MSP (iirc Multiwii Serial Protocol) exists and is what OSD's like KvTeam/Minim use.

IceWind · Post by **IceWind** » Thu Apr 10, 2014 2:52 pm

Hey guys,

I noticed the following, when enable Horizon mode and then disable it. The quad always leans to one side.
I have both Acro and Horizon leveled, so I would expect it to remain leveled when I simply change modes and I'm not giving
any stick input.

I almost use the ACC so I'm not sure if this expected or not, but It seems it shouldn't be happening. the FC should be able to
keep the quad leveled no?

(I have a view somewhere that shows it happening... I'll try to find it out)

scrat · Post by **scrat** » Tue Apr 22, 2014 9:04 am

I see something new at github.

What is: including EMF avoidance

Thanks.

theailer · Post by **theailer** » Tue Apr 22, 2014 10:12 am

It overclocks the naze so there is less noise on the UHF band. Good to have if you use any type of long range system

scrat · Post by **scrat** » Wed Apr 23, 2014 8:15 am

theailer wrote:It overclocks the naze so there is less noise on the UHF band. Good to have if you use any type of long range system

I have LRS and Naze just spews on 432MHZ and I'm using 434MHz to 438MHz.

And from now on...will be naze always overclocked to 84Mhz?

theailer · Post by **theailer** » Wed Apr 23, 2014 8:28 am

You have to enable it in the CLI I think

Dilbert66 · Post by **Dilbert66** » Thu Apr 24, 2014 1:11 am

I'm playing around with an STM32f103RBt6 breakout board and a GY-86 cheapie IMU unit from China. ACC, MAG and Gyro work fine but it was not picking up the ms5611 baro. A quick debug session showed that the chip was responding fine on i2c but was consistently failing the prom crc. Just to see what the heck, I bypassed the crc ack and everything looked to work fine. I can see working data on baseflight configurator and everything responds as it should. I did have to play with the align_xxx values though. Has anybody seen these ms5611's with bad crc's? I'm pretty sure I should not trust it but it would be a shame since it seems to behave fine otherwise. Don't plan on trusting it to an expensive quad though! Good for playing with code. I did order another one to do some comparison. I have an older GY-88 that works ok (with the BMP085).
Here's the sample prom output:
prom uint16_t [8] 0x20000620 <ms5611_c>
prom[0] uint16_t 0
prom[1] uint16_t 51112
prom[2] uint16_t 52224
prom[3] uint16_t 31216
prom[4] uint16_t 28696
prom[5] uint16_t 31630
prom[6] uint16_t 27608
prom[7] uint16_t 59976
i int32_t 134236394
j int32_t 536891288
res uint32_t 0
zero uint8_t 1 '\001'
Well, yes, I am aware that QC on parts from the chinese manufacters is a rarity but thought I'd ask anyways. Noticed that baseflight already had the i2c passthrough option turned on for the module so it was almost plug and play..

timecop · Post by **timecop** » Thu Apr 24, 2014 2:13 am

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.

Dilbert66 · Post by **Dilbert66** » Thu Apr 24, 2014 2:24 am

it's a newer metal one. I know the crc code is fine as I even tried the same values with the AN520 sample code and got the same results calculated crc=0, prom crc=8. Beats me. Well, you get what you pay for I guess. I was thinking it was a flaky i2c bus since I am using soldered on lengths of about 3 inches of wire and that is pushing it for i2c I think but the read data is very consistent and I don't show any i2c read errors in the configurator so that kinda eliminates that. Well, I won't stress over it. Just thought it was an oddity.

Dilbert66 · Post by **Dilbert66** » Thu Apr 24, 2014 2:57 am

Off topic, are you planning on making any more of those stm32f303 boards ? http://i.imgur.com/TTU2NLZ.jpg. Or a variant of the Rev5 board with the f303 (minus the usb chip since you have vcp). I like the fact that the 303's have a more flexible port remapping structure than the f101's giving better access to usart3 and other ports. I'm playing with the 64 pin f103 but really the only thing I get of benefit from all those extra pins is a third serial port. Not worth the larger size and pin count.

scrat · Post by **scrat** » Thu Apr 24, 2014 10:04 am

theailer wrote:You have to enable it in the CLI I think

Yes. That's right.

timecop · Post by **timecop** » Fri Apr 25, 2014 4:12 am

Dilbert66 wrote:Off topic, are you planning on making any more of those stm32f303 boards ? http://i.imgur.com/TTU2NLZ.jpg. Or a variant of the Rev5 board with the f303 (minus the usb chip since you have vcp). I like the fact that the 303's have a more flexible port remapping structure than the f101's giving better access to usart3 and other ports. I'm playing with the 64 pin f103 but really the only thing I get of benefit from all those extra pins is a third serial port. Not worth the larger size and pin count.

Yes, I had hardware for this for a long time. (over a year now).
Current revision uses same microusb port and all top-side mounted parts like rev5, and all sensors on SPI.
I make them in multiples of 6 since thats how many are on the panel and currently i'm all out.

Dilbert66 · Post by **Dilbert66** » Fri Apr 25, 2014 3:25 pm

Thanks TC. I like the specs on it. I'll keep my eye out if you make more. Might be interested if the price is right. Porting baseflight to it should be fairly trivial . All the hard low level work has already been done by jihlean's focusflight port to your board.

Dilbert66 · Post by **Dilbert66** » Sun Apr 27, 2014 2:26 am

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.

prodrones · Post by **prodrones** » Mon Apr 28, 2014 10:33 pm

Hi there
Did someone of you have also boardfreezing since the new update from 24.04.2014 (Baseflight) ? It works in the beginning for about two minutes and freeze completly.

Today i test the new firmware and after about 2 minutes normal easy flight it made a flip. On my workbench i test that strange thing without propellers again and look, after about two minutes freeeze. The only thing you can do in this case is to unplug the battery.
Really strange and i have no clue about them. Someone can help me ?

I have this board MW32 Board: http://flyduino.net/Multikopter-FC_2

Dilbert66 · Post by **Dilbert66** » Wed Apr 30, 2014 1:00 am

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.

timecop · Post by **timecop** » Wed Apr 30, 2014 1:20 am

Sounds like a gcc problem, I use a proper compiler (armcc)

Dilbert66 · Post by **Dilbert66** » Wed Apr 30, 2014 1:23 am

I agree. I always wondered what you used to compile since your hex was always smaller then a gcc optomized version. I believe I will switch.

e_lm_70 · Post by **e_lm_70** » Thu May 01, 2014 7:09 pm

I'm new in Naze32.

I did set up my Ubuntu for compile the Naze code.
Via SVN I got the revision 473.

From the SVN download, I got already a baseflight.hex .. that it is ~157Kbyte file.
After compile I get a baseflight_NAZE.hex .. that it is over 200Kbytes

Why the two file don't match in size ? Why makefile does not produce the baseflight.hex ?

Thanks

PS: Is the Dilber66 already the solution of my question ? Is the baseflight.hex the hex made by TimeCop ? That does use a different compiler ? But the difference is HUGE .. can't be GCC so junky

Dilbert66 · Post by **Dilbert66** » Thu May 01, 2014 11:44 pm

I get 216k with gcc and using -Os optimization and using the Launchpad toolchain. I couldnt' get CodeSourcery to work right. TC gets it at 169k with armcc.

armcc (Keil) is a commercial product and will indeed produce a much more optomized hex. GCC is for us cheap folks

Dilbert66 · Post by **Dilbert66** » Fri May 02, 2014 12:15 am

e_lm_70 wrote:I'm new in Naze32.

I did set up my Ubuntu for compile the Naze code.
Via SVN I got the revision 473.

SVN? That must be the old repository. The project moved to github a while ago. Here is the latest source:

https://github.com/multiwii/baseflight

e_lm_70 · Post by **e_lm_70** » Fri May 02, 2014 6:30 am

Thanks a lot Dilbert

So TC is still on Keil .. as I was reported many months ago.

I have Keil in some PC somewhere ... I will give it a try.

Also .. gotta to look after the latest code too

Mainly ... I see TC code sit in less then 64k flash, my compiled version not ... that means my own code does not fit in cheap stm32 boards that have only 64k memory

Thanks again ... I'm moving my first steps here, and all is looking not as simple as in the 'arduino-tarduino' world of MultiWii with Atmega chips

Still I need to make my mind between baseflight and harakiri ... mainly baseflight has more hope to fit in 64k flash.

timecop · Post by **timecop** » Fri May 02, 2014 6:31 am

Cheap boards with "only" 64K still have 128k flash. Just force flash size to 128 in loader demo and go. No problem.

e_lm_70 · Post by **e_lm_70** » Mon May 05, 2014 12:49 am

timecop wrote:Cheap boards with "only" 64K still have 128k flash. Just force flash size to 128 in loader demo and go. No problem.

Thanks .. the trick did work well

Still I can't make BMP180 working on baseflight ...

The sample working code for arduino related to BMP180 does use "#define BMP180_COMMAND_PRESSURE3 0xF4" instead of Baseflight "#define BMP085_P_MEASURE 0x34"
I did apply this change and as well I did change to 100k i2c speed .. but still without any success.

My BMP180 don't work either in multiwii 2.3 for Atmega chips too ... while the test code "SFE_BMP180" is working fine on my BMP180 and on my custom DIY 10DOF

Can anybody comment if the BMP180 has been tested by anybody before ?

Anybody with latest AfroMini32 with BMP180 ?

Thanks

e_lm_70

Dilbert66 · Post by **Dilbert66** » Mon May 05, 2014 1:45 am

Well, e_lm_70, I think it's time you roll up your sleeves, hook up st-link with openocd or st-util and eclipse and trace the sensor init routine in the drv_bmp085.c code and compare outputs with other working code. Only way you'll know for sure where it fails. If you do find a flaw in the code , great

That will help anyone else who may have the issue you have. Baseflight has been around a long time and I havent heard of anyone else with the issue with that bmp180 , so I'm interested in your findings.

e_lm_70 · Post by **e_lm_70** » Mon May 05, 2014 8:16 am

Dilbert66 wrote:Well, e_lm_70, I think it's time you roll up your sleeves, hook up st-link with openocd or st-util and eclipse and trace the sensor init routine in the drv_bmp085.c code and compare outputs with other working code. Only way you'll know for sure where it fails. If you do find a flaw in the code , great That will help anyone else who may have the issue you have. Baseflight has been around a long time and I havent heard of anyone else with the issue with that bmp180 , so I'm interested in your findings.

You are right .. time to put some debugging check in the code (the "lame" arduino/tarduino style)
I have one SWD ultra cheap debugger, but I never really use it ... I did also remove the SWD port on my STM32 cheap board :oops:

At least I'm able to compile (I have to use Lubuntu over a VMware) ... and it is looking to produce good code.

BMP180 sound very new to me ... I think on eBay the cheap BMP180 module are out since few "weeks" ... so ... I bet there are not many people out using these baro.

Ok ... time to work on it ... I'm mainly lazy .. I would have loved to find a pre-cook solution to my problem .. and I'm quite sure it is more a generic issue .. can't be that I got 7 BMP180 via 2 orders, and all are not working in the MultiWii 085 framework, but do works with the BMP180 sample code/library ... still when I have to, I can code in any platform/environment/language ...

If anybody here have a AfroMini32 new version, or any DIY BMP180 module ... please ... I'm really interested in your experience.

Thanks a lot already for the good advice that I got from you guys here.

scrat · Post by **scrat** » Mon May 05, 2014 9:43 am

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?

e_lm_70 · Post by **e_lm_70** » Mon May 05, 2014 11:08 am

BMP180 war report:

My Baseflight believe that my BMP180 is a 5611 ... this is how it is detected.

Going to remove the 5611 detection ... and see if this will work out.

e_lm_70 · Post by **e_lm_70** » Mon May 05, 2014 11:23 am

e_lm_70 wrote:BMP180 war report:

My Baseflight believe that my BMP180 is a 5611 ... this is how it is detected.

Going to remove the 5611 detection ... and see if this will work out.

Problem solved :ugeek:

I just remove the ! in front of the 5611 detection .. and now Baseflight recognize the BMP180 .. and yes, it is looking it is working fine (I use a modified 085 version ... going to change back to original 085 code and see if original code works)
While the BMP-180 sample code was giving some decent accuracy ... the baseflight alt reading with BMP180 does not look much different then BMP085.

Anyhow ... my DIY 10DOF (6$ cost of production) it is now fully functional on baseflight ... :shock:

I'm very curious to hear from TimeCop .. which type of test he does over his AfroMini32 ... how is possible that my BaseFlight does think it is a 5611 sensor .. and still no i2c error is shown ...

Going to revert back 085 code ... for see if the original code works or not ... in theory it should since it use one of the 4 supported baro reading mode ... no idea which is better, each have a different reading time ...

...

PS: Testing procedure over a BMP180 or any baro sensor ... just blow over the sensor .. and if you get a jump in the alt reading from MW2.3 gui (I'm using the "original" Java GUI) then the sensor is working .. if you blow, but nothing happen ... then it is a fail ... moving up and down the board will cause anyhow to have some micro alt reading change, due to the Z acc sensing "stuffs"

EDIT ... revert back to original 085 code ... and it is still working .. only difference was following

#define BMP180_COMMAND_PRESSURE0 0x34 // (5 mSec)
#define BMP180_COMMAND_PRESSURE1 0x74 // (8 mSec)
#define BMP180_COMMAND_PRESSURE2 0xB4 // (14 mSec)
#define BMP180_COMMAND_PRESSURE3 0xF4 // (28mSec)

So sample code was using 0xF4 ... 085 code is using by 0x34

No idea how baseflight take care of the delay for next reading
I can't notice much of difference between the 0xF4 from 0x34 ... in the accuracy of Alt Reading from MW GUI.
I stay with 085 original code ... so only sensor.c has been hacked up for make the BMP180 to work fine.

timecop · Post by **timecop** » Mon May 05, 2014 11:33 am

Both sensors are on same i2c address, but 5611 will fail to detect because of PROM crc error which doesn't even exist on BMP180.

e_lm_70 · Post by **e_lm_70** » Mon May 05, 2014 11:43 am

timecop wrote:Both sensors are on same i2c address, but 5611 will fail to detect because of PROM crc error which doesn't even exist on BMP180.

Clearly with my BMP180(s), Baseflight believe I have a 5611
Maybe latest BMP180 have a PROM crc error ...
Definitely the 5611 check is not robust enough.

PS: Tarduino debugging style via debug[4] ... was relative fast even for somebody new to the baseflight code.

PPS: Baseflight code I have to say it is looking very clean and well organized .... my compliments to the people involved on it. A different universe compared to the spaghetti code of APM :mrgreen:

timecop · Post by **timecop** » Mon May 05, 2014 2:23 pm

e_lm_70 wrote:Clearly with my BMP180(s), Baseflight believe I have a 5611
Maybe latest BMP180 have a PROM crc error ...
Definitely the 5611 check is not robust enough.

Stepthrough the code and see what it does differently.
It will go into 5611_read_prom() or similar and will calculate it.
see why it succeeds, when it should fail crc.

Dilbert66 · Post by **Dilbert66** » Mon May 05, 2014 2:54 pm

Very curious about that myself as the checksum code is a fairly accurate and a good test. There is even a check to ensure even with all prom at all zero's it wil be caught. It would be very strange indeed if random values would give a correct crc for the prom check.

e_lm_70 · Post by **e_lm_70** » Mon May 05, 2014 2:55 pm

timecop wrote:
e_lm_70 wrote:Clearly with my BMP180(s), Baseflight believe I have a 5611
Maybe latest BMP180 have a PROM crc error ...
Definitely the 5611 check is not robust enough.

Stepthrough the code and see what it does differently.
It will go into 5611_read_prom() or similar and will calculate it.
see why it succeeds, when it should fail crc.

I don't have step debugging ... at least not in a easy way ...

I can try to put some debug stuff .. checking 4 condition per "compile run" ... but it will take some time (maybe not much) ... I will give a couple of go later

Code wise ... it will be for me better to define manually the Sensor on the board, and not to relay on i2c TESTs.
The firmware does not say which Sensor has been detected, only the sensor type is shown in the CLI.

Anyhow ... not sure how many people my have my same problem, since BMP180 it is not that popular ... anyhow my solution is simple .. yes it for now it is a quick an' dirty solution ... very quick (just remove a "!" in the code), but very dirty, since it implies to use the code only for specific sensors ...

I'm still surprise why you see different on your BMP180 sensors ... the GY-68 module is just a Vreg + some caps and resistors + the BMP180 chip ... so ... I don't see how it could behave differently then a BMP180 into a dedicated PCB like AfroMini32 ... possibly mine and yours are from two different "production lot" .. either me or you we may have some old BMP180 sensors.

Dilbert66 · Post by **Dilbert66** » Mon May 05, 2014 2:56 pm

Just dump the 8 prom values and calculated crc with a debug print and see what you get.

e_lm_70 · Post by **e_lm_70** » Mon May 05, 2014 2:58 pm

Dilbert66 wrote:Very curious about that myself as the checksum code is a fairly accurate and a good test. There is even a check to ensure even with all prom at all zero's it wil be caught. It would be very strange indeed if random values would give a correct crc for the prom check.

I don't know these sensor well ... but in theory I see that a function on 5611 could have been ported also on BMP180 ... so .. possibly latest BMP180 have a prom inside like the 5611

Anyhow ... only a proper debug analysis could solve the mystery.

Definitely the code is capable to differentiate 085 from 5611 .. I did test the same code on both AfroMini32 (a old version) and my custom STM32 board + DIY 10DOF

e_lm_70 · Post by **e_lm_70** » Mon May 05, 2014 3:01 pm

Dilbert66 wrote:Just dump the 8 prom values and calculated crc with a debug print and see what you get.

Ok ... I will

e_lm_70 · Post by **e_lm_70** » Mon May 05, 2014 3:17 pm

Ok ... thanks Dilbert66 for the direct and quick tip for testing.

This is what I did add:
drv_ms5611.c: debug[0]=(ms5611_c[0]<<8)+ms5611_c[1];
drv_ms5611.c: debug[1]=(ms5611_c[2]<<8)+ms5611_c[3];
drv_ms5611.c: debug[2]=(ms5611_c[4]<<8)+ms5611_c[5];
drv_ms5611.c: debug[3]=(ms5611_c[6]<<8)+ms5611_c[7];

Clearly I remove the dummy debug[3] from serial.c

This is what my MW GUI 2.3 show me:
-12776 / 23689 / -13494 / 25932

It is looking like my BMP180 have a PROM :ugeek:

Please don't ask me to calculate CRC ... it is self evident that CRC pass the check.

Dilbert66 · Post by **Dilbert66** » Mon May 05, 2014 3:23 pm

the values are 16 bit, you need to show all 8 to be able to calculate the crc from iit. The first one is normally (or can be) zero (manufacturer code).
You are treating them as 8 bit. I don't see why you say it is self evident? What you show doesnt prove anything.

e_lm_70 · Post by **e_lm_70** » Mon May 05, 2014 3:40 pm

Dilbert66 wrote:the values are 16 bit, you need to show all 8 to be able to calculate the crc from iit. The first one is normally zero (manufacturer code).
You are treating them as 8 bit. I don't see why you say it is self evident? What you show doesnt prove anything.

Ups ... I though it was 8 value each 8 bit .. for get all I need two run of the code ... and two version of it.

Ok the value I send out are a mess with mixing up the 16 bit values.
I switch down my virtual lubuntu ... I may give it another go later.

Still the sequence it is not a random sequence ... it does clearly demonstrate that BMP180 does reply to the PROM request.
-> ack = i2cRead(MS5611_ADDR, CMD_PROM_RD, 1, &sig);

What should do a AfromMini32 BMP180 at this point ?

It really puzzle me that my BMP180 do different then TimeCop ... I would be curious to know when TimeCop got his batch of BMP180 chips ... maybe he has old sensors .. or maybe ... he miss this in his QC tests ...
There is no i2c error using official Baseflight firmware and BMP180, this issue could pass unobserved at a quick look.

PS: I'm using default i2c speed ... so I assume BMP180, like 6050 and 5833 works at 400k .. all these 3 sensors as in a sandwich DIY PCB on 3 layers ... "glued" by 4 pins

Dilbert66 · Post by **Dilbert66** » Mon May 05, 2014 3:51 pm

Still doesnt prove anything. bmp180 also stores co-efficients in prom. It just doesnt use a crc to validate them. All you are showing is that there is data at address 0xA0 in the "bmp180". Just post the values you get and I will calculate the crc and then we will know for sure.

Make sure you read it right after the read and not after the crc check since the crc check munges up the lower byte of the crc value.

ms5611_reset();
// read all coefficients
for (i = 0; i < PROM_NB; i++)
ms5611_c[i] = ms5611_prom(i);

**** debug print 16 bit ms5611_c array here *************

e_lm_70 · Post by **e_lm_70** » Mon May 05, 2014 4:11 pm

Dilbert66 wrote:Still doesnt prove anything. bmp180 also stores co-efficients in prom. It just doesnt use a crc to validate them. All you are showing is that there is data at address 0xA0 in the "bmp180". Just post the values you get and I will calculate the crc and then we will know for sure.

Make sure you read it right after the read and not after the crc check since the crc check munges up the lower byte.

ms5611_reset();
// read all coefficients
for (i = 0; i < PROM_NB; i++)
ms5611_c[i] = ms5611_prom(i);

**** debug print 16 bit ms5611_c array here *************

If you assume that the CRC code of baseflight is correct ... it can't be a special lucky combination.

The register A0 in theory is not documented by BMP180 per the specs : http://www.adafruit.com/datasheets/BST- ... 000-09.pdf
BMP180 calibration is from AA to BF

I'm not going to use debug print .. I will use again debug[4]

Before it was in the right place ... but I missed out that these values are 16bit ... at a quick look for some reason I have seen as 8bit stuffs ... also I did assume it was a stream from i2c .. that is normally a 8bit stream ... anyhow

for (i = 0; i < PROM_NB; i++)
ms5611_c[i] = ms5611_prom(i);

-> It was here

// check crc, bail out if wrong - we are probably talking to BMP085 w/o XCLR line!
if (ms5611_crc(ms5611_c) != 0)
return false;

I did shut down my lubuntu virtual machine ... I will provide you the 8 16bit sequence later ...
Either is a CRC bug (I doubt) fail to code a CRC is quite a dummy mistake.
Or simply it is the wrong way to identify the chip.
Also .. maybe some BMP180 are different then other.

I would personally like to see configure the list of sensors, without to trust the auto detect logic.
Code will be smaller and more simple.

Anyhow ... Baseflight it is not really PNP firmware .. so ... by default a 5611+6050+5883 can be consider as present ... every other/different sensor would need to be specified by CLI.

scrat · Post by **scrat** » Tue May 06, 2014 9:15 am

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?

Yesterday I have put looptime to default - 3500 and have no more twitching. Strange...

e_lm_70 · Post by **e_lm_70** » Tue May 06, 2014 1:29 pm

Anybody tried Baseflight on STM32F103RCT6 ?

e_lm_70 · Post by **e_lm_70** » Tue May 06, 2014 10:25 pm

e_lm_70 wrote:Ok ... thanks Dilbert66 for the direct and quick tip for testing.

This is what I did add:
drv_ms5611.c: debug[0]=(ms5611_c[0]<<8)+ms5611_c[1];
drv_ms5611.c: debug[1]=(ms5611_c[2]<<8)+ms5611_c[3];
drv_ms5611.c: debug[2]=(ms5611_c[4]<<8)+ms5611_c[5];
drv_ms5611.c: debug[3]=(ms5611_c[6]<<8)+ms5611_c[7];

Clearly I remove the dummy debug[3] from serial.c

This is what my MW GUI 2.3 show me:
-12776 / 23689 / -13494 / 25932

It is looking like my BMP180 have a PROM

Please don't ask me to calculate CRC ... it is self evident that CRC pass the check.

I did update the code after the 8bit vs 16bit issue

Here is the results

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

Tchuss

e_lm_70