Anyone used the Bosch BMP085 I2C baro sensor yet ?

[mr.sneezy]

Ignore the cr@p I posted above. I thought I had it worked out but noooo.

PS. I hate the way you can't edit the post for more than a hour or so after putting up some info. What's with that anyway ?

[mackrackit]

PS. I hate the way you can't edit the post for more than a hour or so after putting up some info. What's with that anyway ?

Edits to post do not trigger a notification to those following a thread.

If edits were allowed to far back the whole context of the thread could be changed or useful information lost.

So there is really no reason to allow edits for more than a few minutes to correct spelling, grammar, or typos in general.

[mr.sneezy]

No the title is right....

I've just done some reading at Melabs about Longs in the recent versions of PBP and how they work with 18F series PIC's. I now think I may be doing sensor this the hard way with trying to use a 12F or 16F PIC.

A broad question: If the math involved in using this sensor only uses Longs and no floating point, can I use a 18FXXXX PIC to crunch the signed math, or is there a likely newbie Longs trap to fall into ?

I'd copy/paste the data sheets equations here to show you, but it's copy/paste protected. I'll attach it as a file.
It's only the last conversion from pressure to altitude that seems to use a float, and I can worry about that when I get that far (I hope). Page 12 is the guts of it.

[BrianT]

I have read the Bosch datasheet which is very similar to the Intersema MS5540 family. With the exception of absolute altitude, LONGs and a PIC18F part will handle those formulae easily.

The mathematical gymnastics of handling the Bosch 19 bit variables with 16 bit PBP will consume much code space thus ruling out the 12F series. You will get it into a 16F part on code space grounds but you will have to invent your own way to extend WORD variables up to 19 bits. Why bother?

The 18F series costs hardly any more, at least at hobby volumes, so cut your losses and go for a PIC18F part and take advantage of LONGs. This will automatically take care of negative temperatures which your altimeter will certainly need.

Absolute Altitude needs LOG functions to handle the power 1/5.255 so avoid that by using a lookup table which you can make as accurate as you want by adjusting the size of the table and the interpolation method.

HTH
BrianT

[mr.sneezy]

I have read the Bosch datasheet which is very similar to the Intersema MS5540 family. With the exception of absolute altitude, LONGs and a PIC18F part will handle those formulae easily.
HTH
BrianT

Hi Brian, yes that helps me, a good confidence boost at the very least.
Can I bother you a moment longer ? About two things in the datasheet that you may well understand without looking at it again.

First is that the equations for the temp and pressure conversions have in there a couple of times the value called 'oss', used with a binary shift I think. Do you know what that 'oss' means ?

Lastly, I've been reading the raw pressure value with my code as a 16 bit Word, but it occurred to me now that even if I don't specify the hi-res mode, that I should be reading the full 19bits (LSB being 000 I guess) not just 16. The data sheet doesn't make it clear either way (to me).

TIA,
Martin

[BrianT]

Looks to me the number of places you left or right shift is related to how many samples you take per reading. try and get hold of the C code and see if you can nut it out. In my Intersema code, I do the averaging by a simple sum of n readings divided by n at the end. Again, LONGs take the pain out of needing to know if the sum of 8 samples overflowed a 16 bit variable.

I have failed to find a copy of their C source code on the net. Seems you have to genuflect for one of their distributors to get it.

HTH
BrianT

[mr.sneezy]

Thanks Brian. Did I fail to RTFM :-) I hope not.

I studied a nicely done vario project here using the BMP085 and C30 compiler.
http://www.pixelproc.net/pic24bmp085lcd.html
Didn't mean much to me unfortunately as it's a very busy bit of work.

Yes, I like the simpler add many then divide way of averaging too, it always works well.
Martin