Finally got this thing to work. There may be circumstances that it will give false values as I have not tested every eventuallity, but it seems to work at around normal temperatures and pressures.
I'll try it later. I got a ready made one. Maths is tricky without the functions. I've been looking up fast fourier transfer for a frequency bar graph. Plenty of valid stuff but real and imaginary numbers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here's a routine that I wrote in Qbasic for FFT. May need a bit of work to convert to integer arithmetic and will probably need look-up tables for the SIN and COS. The array AR is the real part and AI the imaginary. Both arrays are overwritten with the result of the FFT. The data needs to be a power of 2 long, but can be zero filled to a power of 2 if not.
M = 8 '256 points
n = 2 ^ M
NV2 = n / 2
NM1 = n - 1
j = 1
FOR i = 1 TO NM1
IF i >= j GOTO 55
SWAP AR(i), AR(j)
SWAP Ai(i), Ai(j)
55 k = NV2
56 IF k >= j GOTO 57
j = j - k
k = k / 2
GOTO 56
57 j = j + k
NEXT i
FOR L = 1 TO M
LE = 2 ^ L
LE1 = LE / 2
UR = 1!: UI = 0!
ANG = PI / LE1
WR = COS(ANG): WI = SIN(ANG)
FOR j = 1 TO LE1
FOR i = j TO n STEP LE
IP = i + LE1
TR = AR(IP) * UR - Ai(IP) * UI
TI = AR(IP) * UI + Ai(IP) * UR
AR(IP) = AR(i) - TR
Ai(IP) = Ai(i) - TI
AR(i) = AR(i) + TR
Ai(i) = Ai(i) + TI
NEXT i
URT = UR * WR - UI * WI
UI = UR * WI + UI * WR
UR = URT
NEXT j
NEXT L
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you David. I found integer fft solutions but I don't really understand fft. Most solutions use pi,log,atn,cos,sin floating point. A sweeping notch filter would be easier.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
David Stephenson,
Thank You for inspiring me to continue on the BME280.
I knew my next step was to hook the Saleae logic analyzer up to watch the I2C. I was fearing this but it was a breeze.
I modified your code to output on the usart and to write out the calibration constants. The constants disagreed with my constants so who is right? The logic analyzer said the both agreed but I would read an extra byte.
My program was printing the wrong calib const about half way down the list even though I knew it had read the correct constants. The indexed variable i was using, was being tranfered to the constants variables incorrectly. I left out indexed "(3)" .... Counting 124567 killed me for a month. Old eyes read it in when it wasn't there.
Now all but the last constant agreed both on the logic analyzer and serial outputs. My program was reading an extra byte. Looking at the flow i found that the last correct byte was being over written by the extra byte. another indexing problem! When falling out of a for/next loop, the last value of the for index is still there ? It was writing over the previous value. Adjusted the for index and it started to work!
I have three of the devices BME280 and they all are reading close to each other and close to the envioronmenal values below 77F(25C). Getting very close , More testing .
I have not worked on your code except to convert to serial and spill the constants. I will say that after the conversion it is not outputing the correct results.
This code needs some cleaning but I will put it out there.
73
Mike
David Stephenson, sir. I fancy this is gcb do-able with bit of help. https://www.youtube.com/watch?v=tCmaOb-VAEo
I can do the graphics from input. what input data? Someone want to co work with me to make a display?
Last edit: stan cartwright 2017-12-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes it should be possible a 64 point FFT should be pretty fast (and it doesn't look like it needs huge accuracy on the y-axis). I suspect the display is going to have to have a paralell interface to get that kind of speed. I've got a 128x64 lcd which might just do it on the SPI interface.
I've collected a lot of atmospheric pressure data (several months) when doing a FFT on the data gives the rather curious graph below.
I tried to extract results from your code to a i2c display. not easy to convert (pour moi) Please could you simplify code to output vars for more universal display options. just pressure,temp,etc. vars. (ie make it an include or dumb it a bit please)
bmp280.GCB (45): Warning: Variable name CAL1 is used for a system bit on the current chip yawn etc/
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The output variable for temperature is TEMP and it is word sized and in deg C x100. I have not yet accommodated negative temperatures as I am more interested in the pressure readings.
The output for pressure is PRESS I have reduced it by 60000 pa (as I am unlikely to go above 13000 ft) and this reduces PRESS to 16 bit word (I add a 6 to the most significant digit when it is outputted to the LCD).
CAL1 is the correction due to height above sea level (12Pa per m).
CAL2 is the correction to get it to agree with the (possibly) correct local reading ( the stresses of soldering have probably taken their toll).
I have had to adjust some of the maths from the datasheet as it was wrong and even when corrected produced a reading that moved in 4 Pa steps. I actually test the maths in QB64 using long intergers and integer division before I put it on the chip.
My FFT above is showing the semidiurnal and diurnal variation in atmospheric pressure somthing that is well known, but difficult to explain.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Following along here..... Can you adapt so the output temperature variable is something like BMP280_Temp? As, I would think a few folks have used TEMP as a temp variable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've noticed that changing the filter value seems to have no effect. I moved the setting of the config register (0xF5) to the initialization routine (where it should be) and still I'm getting the same amount of noise with the filter off and on x16. Yes I've choosen variable names very badly, but I didn't like the manes in the datasheet as they were all too similar (and very long).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally got this thing to work. There may be circumstances that it will give false values as I have not tested every eventuallity, but it seems to work at around normal temperatures and pressures.
Last edit: David Stephenson 2017-12-06
Here's a picture of it working.
I'll try it later. I got a ready made one. Maths is tricky without the functions. I've been looking up fast fourier transfer for a frequency bar graph. Plenty of valid stuff but real and imaginary numbers.
Here's a routine that I wrote in Qbasic for FFT. May need a bit of work to convert to integer arithmetic and will probably need look-up tables for the SIN and COS. The array AR is the real part and AI the imaginary. Both arrays are overwritten with the result of the FFT. The data needs to be a power of 2 long, but can be zero filled to a power of 2 if not.
M = 8 '256 points n = 2 ^ M NV2 = n / 2 NM1 = n - 1 j = 1 FOR i = 1 TO NM1 IF i >= j GOTO 55 SWAP AR(i), AR(j) SWAP Ai(i), Ai(j) 55 k = NV2 56 IF k >= j GOTO 57 j = j - k k = k / 2 GOTO 56 57 j = j + k NEXT i FOR L = 1 TO M LE = 2 ^ L LE1 = LE / 2 UR = 1!: UI = 0! ANG = PI / LE1 WR = COS(ANG): WI = SIN(ANG) FOR j = 1 TO LE1 FOR i = j TO n STEP LE IP = i + LE1 TR = AR(IP) * UR - Ai(IP) * UI TI = AR(IP) * UI + Ai(IP) * UR AR(IP) = AR(i) - TR Ai(IP) = Ai(i) - TI AR(i) = AR(i) + TR Ai(i) = Ai(i) + TI NEXT i URT = UR * WR - UI * WI UI = UR * WI + UI * WR UR = URT NEXT j NEXT LThank you David. I found integer fft solutions but I don't really understand fft. Most solutions use pi,log,atn,cos,sin floating point. A sweeping notch filter would be easier.
David Stephenson,
Thank You for inspiring me to continue on the BME280.
I knew my next step was to hook the Saleae logic analyzer up to watch the I2C. I was fearing this but it was a breeze.
I modified your code to output on the usart and to write out the calibration constants. The constants disagreed with my constants so who is right? The logic analyzer said the both agreed but I would read an extra byte.
My program was printing the wrong calib const about half way down the list even though I knew it had read the correct constants. The indexed variable i was using, was being tranfered to the constants variables incorrectly. I left out indexed "(3)" .... Counting 124567 killed me for a month. Old eyes read it in when it wasn't there.
Now all but the last constant agreed both on the logic analyzer and serial outputs. My program was reading an extra byte. Looking at the flow i found that the last correct byte was being over written by the extra byte. another indexing problem! When falling out of a for/next loop, the last value of the for index is still there ? It was writing over the previous value. Adjusted the for index and it started to work!
I have three of the devices BME280 and they all are reading close to each other and close to the envioronmenal values below 77F(25C). Getting very close , More testing .
I have not worked on your code except to convert to serial and spill the constants. I will say that after the conversion it is not outputing the correct results.
This code needs some cleaning but I will put it out there.
73
Mike
Last edit: mmotte 2017-12-08
As I am following along with interest. Am I correct is thinking this is still 'work in progress'?
Because, the moment this is finished I am hooking up the BME280 here!
Let me know the status when done - in case I miss the final version.
:-)
We are getting close. Some testing and cleaning yet. Not done.
Also i want to make it BMP280 capatible(without the Humidity)..
Who would have guessed that it would take 6 weeks?
David Stephenson, sir. I fancy this is gcb do-able with bit of help. https://www.youtube.com/watch?v=tCmaOb-VAEo
I can do the graphics from input. what input data? Someone want to co work with me to make a display?
Last edit: stan cartwright 2017-12-08
Yes it should be possible a 64 point FFT should be pretty fast (and it doesn't look like it needs huge accuracy on the y-axis). I suspect the display is going to have to have a paralell interface to get that kind of speed. I've got a 128x64 lcd which might just do it on the SPI interface.
I've collected a lot of atmospheric pressure data (several months) when doing a FFT on the data gives the rather curious graph below.
doesn't weather do that?....I just look out the window
I tried to extract results from your code to a i2c display. not easy to convert (pour moi) Please could you simplify code to output vars for more universal display options. just pressure,temp,etc. vars. (ie make it an include or dumb it a bit please)
bmp280.GCB (45): Warning: Variable name CAL1 is used for a system bit on the current chip yawn etc/
The output variable for temperature is TEMP and it is word sized and in deg C x100. I have not yet accommodated negative temperatures as I am more interested in the pressure readings.
The output for pressure is PRESS I have reduced it by 60000 pa (as I am unlikely to go above 13000 ft) and this reduces PRESS to 16 bit word (I add a 6 to the most significant digit when it is outputted to the LCD).
CAL1 is the correction due to height above sea level (12Pa per m).
CAL2 is the correction to get it to agree with the (possibly) correct local reading ( the stresses of soldering have probably taken their toll).
I have had to adjust some of the maths from the datasheet as it was wrong and even when corrected produced a reading that moved in 4 Pa steps. I actually test the maths in QB64 using long intergers and integer division before I put it on the chip.
My FFT above is showing the semidiurnal and diurnal variation in atmospheric pressure somthing that is well known, but difficult to explain.
Following along here..... Can you adapt so the output temperature variable is something like BMP280_Temp? As, I would think a few folks have used TEMP as a temp variable.
I've noticed that changing the filter value seems to have no effect. I moved the setting of the config register (0xF5) to the initialization routine (where it should be) and still I'm getting the same amount of noise with the filter off and on x16. Yes I've choosen variable names very badly, but I didn't like the manes in the datasheet as they were all too similar (and very long).