Baseflight aka multiwii port to stm32

shikra · Post by **shikra** » Wed Apr 02, 2014 12:19 pm

Hi all - can anyone advise if "MWheading" sent from baseflight via serial request is -180-+180 like Multiwii or 0-360?
If so - is this correct intention?

Reason I ask is OSD is reporting different heading to stock multiwii code

timecop · Post by **timecop** » Wed Apr 02, 2014 1:27 pm

good question,
https://github.com/multiwii/baseflight/ ... ial.c#L459
I don't know

shikra · Post by **shikra** » Wed Apr 02, 2014 1:59 pm

mmm thanks, looks like it does following it back through....
https://github.com/multiwii/baseflight/ ... imu.c#L233

So should I put an option in OSD to fix... or will baseflight be amended to match multiwii.

timecop · Post by **timecop** » Wed Apr 02, 2014 2:04 pm

You can use the 'capability' bit and check for
#define CAP_PLATFORM_32BIT ((uint32_t)1 << 31)
I guess.

Why would multiwii output -180..180 for heading, isn't "standard" 0..360?

dominicclifton · Post by **dominicclifton** » Thu Apr 03, 2014 11:00 pm

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?

dominicclifton · Post by **dominicclifton** » Thu Apr 03, 2014 11:03 pm

I've done some software serial updates to baseflight today, from the pull request:

"Add support for 2 softserial ports on PWM5+6/TIM3_CH1+2/PA6+PA7 and PWM7+8/TIM3_CH3+4/PB0+PB1.

The software serial ports share the same baud rate both both are independently invertible.

The configuration parameter for inverting software serial ports changed. Use 'softserial_1_inverted' and 'softserial_2_inverted'.

Updated software serial to monitor serial pins for signal changes instead
of periodically sampling pin signals.

When reading the data the timer used is synchronized to the falling edge
of the start bit which allows for better synchronization at higher
speeds. The code has been tested OK from 1200 baud to 19200. 38400
baud was tested and partially usable but has been disabled because there
are too many transmit and receive errors, especially when transmitting
and receiving at the same time.

Due to the way a single timer is used for transmitting and receiving, if
data comes in while transmitting the system may incorrectly transmit a
short or long bit. However at 19200 and below this didn't cause a
problem in the limited testing I performed."

https://github.com/multiwii/baseflight/pull/50

I don't think I'm going to invest any more time attempting to support speeds higher than 19200, at least not until my oscilloscope arrives.
I'm happy with the implementation of two additional serial ports at 19200 though. That should open up the doors for some peripheral expansion.

It should also be possible to have GPS + Telemetry + GUI all working at the same time now, when armed or otherwise. However additional code changes are required for that support.

EDIT: To clarify the ports you use are as follows:

RC5 Software Serial Port 1 RX
RC6 Software Serial Port 1 TX

RC7 Software Serial Port 2 RX
RC8 Software Serial Port 2 TX

Plüschi · Post by **Plüschi** » Sun Apr 06, 2014 1:25 pm

Baseflight - GPS

The baudrate defines of GPS are 0 = 115200, 1 = 57600 , etc, not the other way round like described in baseflightGUI.exe . This needs to be described in CLI variables wiki. The code for -1 = autobaud is not implemented, right?

The gps message parsing is done inside the serial interrupt handler. I dont think this is a good idea. I think using the built-in serial buffer and then poll for new messages all 3.5 ms would be far better idea.

timecop · Post by **timecop** » Sun Apr 06, 2014 7:12 pm

Well, nobody uses baseflightGUI.exe ? I guess.
I agree with GPS parsing. Patches welcome.
There was some work recently to get rid of -1 stuff, actually the autobaud DOES still work - i.e. if theres no data it'll go to GPS_LOSTCOMMS state and will cycle to next baudrate in the list and wait until there's some data received, bla bla until it finds the right rate or just keeps repeating if there isn't one. It just means if you entered wrong baudrate for nmea and you have actual data coming in, it'll eventually find the rate its at (assuming its something standard).

dominicclifton · Post by **dominicclifton** » Sun Apr 06, 2014 9:17 pm

I'm uploading a demonstration showing software serial that I implemented sending telemetry data to an FrSky D4R-II Receiver which is subsequently displayed on a Turnigy 9XR running OpenTX and on an Android phone via bluetooth, all while simultaneously running GPS and MinimOSD. I'll edit this post with the link later on.

Baseflight now supports two software serial ports running at up to 19200 baud on RC5/RC6 and RC7/8 pins.

Enable softserial and FrSKY telemetry on baseflight using the following CLI commands:

feature TELEMETRY
feature SOFTSERIAL
set softserial_baud=9600
set softserial_1_inverted=1
set telemetry_softserial=1
save

Also requires RC input signals to be sent via PPM to baseflight via

feature PPM
save

Works fine with two camera stabilisation servos too, via

feature SERVO_TILT
save

For source see:

https://github.com/multiwii/baseflight
https://github.com/multiwii/baseflight-configurator

For apps see:

https://chrome.google.com/webstore/deta ... figk?hl=en
https://play.google.com/store/apps/deta ... o.multiwii
https://play.google.com/store/apps/deta ... .frskydash
http://www.open-tx.org/

For my Turnigy 9XR Frsky 9XR wiring see here:

https://plus.google.com/+DominicClifton ... BLiy4czD8y

See here for an outdated OpenTX / FrSKY guide for the Turnigy 9XR:

http://forum.turnigy9xr.com/converting- ... -t362.html

See here for an outdated OpenTX / FrSKY guide for the Turnigy 9X:

http://www.rchacker.com/projects/turnig ... -telemetry

dominicclifton · Post by **dominicclifton** » Mon Apr 07, 2014 1:09 am

Here's a video describing the softserial frsky telemetry

https://www.youtube.com/watch?v=dahGlc3 ... e=youtu.be

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.