Baseflight aka multiwii port to stm32

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

Dilbert66 · Post by **Dilbert66** » Tue May 06, 2014 10:45 pm

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 · Post by **e_lm_70** » Tue May 06, 2014 11:06 pm

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 · Post by **timecop** » Wed May 07, 2014 5:34 am

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

e_lm_70 · Post by **e_lm_70** » Wed May 07, 2014 8:09 am

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 · Post by **timecop** » Wed May 07, 2014 9:25 am

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 · Post by **e_lm_70** » Wed May 07, 2014 10:02 am

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 · Post by **scrat** » Wed May 07, 2014 10:09 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?

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 · Post by **e_lm_70** » Wed May 07, 2014 10:56 am

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.

Dilbert66 · Post by **Dilbert66** » Wed May 07, 2014 4:28 pm

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 · Post by **e_lm_70** » Wed May 07, 2014 10:10 pm

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.