the first thing that strikes me is that you are using a separate cog to read the temp, but there's no means for the cog to return its data to the main program ... you need to pass the address of the variable datastring[noparse][[/noparse]8] when you make call for cognew(temphum, @stack2). The cog correctly uses the pins you defined because they're defined as constants and take on the specified values at compilation. But when the temphum cog is running it knows nothing about the location you think the main program is using when it uses datastring[noparse][[/noparse]8].
you can try something like cognew(temphum, @tempval, @stack2)
- this tells temphum the address of the variable tempval (@=address of)
and then inside temphum you'd need·to do something like ...
pub temphum(x)·· 'here x takes on the passed address @tempval
...[noparse][[/noparse]code] ...
long[noparse][[/noparse]x] := temperature
- this writes data into x, which is actually tempval ... of course you need to adjust this to suit your variable names etc
you have to convert your sht.readtemperature value...
what you get back... as a raw reading is something on the order of 6777...
if you look at Cam's demo, this will all be fairly clear ... but just to paraphrase Cam's routine
the integer portion of your temperature in degrees C would be (raw value -3966)/100
the decimal portion will be (raw value -3966)//100
If you want to convert that to degrees F... there is also an equation in Cam's demo (from the SHT people) .... but first you get the degrees C AND then you can convert to F.
I put it together to study the relationship between temperature, set point and g measurements... then I got busy doing
something else... I modified it today to highlight the SHT reading and C degree value. It handles noise really well... and
you will notice that if you start the application and then the temperature in the room goes up, the temperature change is reflected by false acceleration, which contributes to a false MPH reading... on the other hand, if you start the application and the temperature goes down, nothing happens.
See if you can figure it out[noparse]:)[/noparse]
If my memory is working, the Memsic2125 unit has two pins we aren't using... an analog temperature out... and a reference voltage. I think if you put these into a ADC, we won't need the SHT. The ADC mentioned in Hanno's recent CC article seems like
it would be perfect.
The decimal portion calculation as above will produce some errors... [noparse]:)[/noparse]
Rich
The 2125 is internally compensated for temperature... So, it could be that most of what I am seeing is because I am not waiting long enough for it to stabilize...something else to look at[noparse]:)[/noparse]
I have had it running all day, and it is handling minor temperature changes really well.. with an ambient temperature in the room of about 28 C. Tonight I am going to turn the temperature in the room up and then go bowling. I'll let you know hat I see.
The results are in... my prop room reached a toasty 35.33 C.... which translates to roughly 98.6 F.
AND my accelerometer is reading... 172 MPH and climbing... I will now turn off the heater and report back tomorrow.
Rich
By the way... my bowling team won for the first since last summer!!!!
Much to my surprise, this morning's results are equally miserable(but now the mph is in the negative direction. But there is hope... if you follow the value of levelx, which results from the calibration step... it definitely seems to be related to ambient temperature. So the next step is to figure out a temperature calibration step... which might or might not require digitizing Tout.
And in the area of normal temperatures... the unit might be reasonably self-adjusting as long as the temperature is within a small range, I suspect that this range will be related to the initial calibration temperature. But I thought that negative temperature changes had no effect too... and they obviously do.
I don`t get what you mean, sorry, my english is far from perfect...
My memsic2125 has nothing to do with the temperature sensor... the memsic is used for pitch and roll sensing and that works perfect! My problem is only the sensirion that returns the same value whatever the temperature is...
Comments
you can try something like cognew(temphum, @tempval, @stack2)
- this tells temphum the address of the variable tempval (@=address of)
and then inside temphum you'd need·to do something like ...
pub temphum(x)·· 'here x takes on the passed address @tempval
...[noparse][[/noparse]code] ...
long[noparse][[/noparse]x] := temperature
- this writes data into x, which is actually tempval ... of course you need to adjust this to suit your variable names etc
I hope that's all you need to do!
Post Edited (bozo) : 3/4/2009 7:52:07 AM GMT
PUB TempHum(a,b,pindat,pinsck) sht.start(pindat, pinsck) repeat long[noparse][[/noparse]a] := sht.readTemperature 'temp (raw) long[noparse][[/noparse]b] := sht.readHumidity 'humidity (raw) waitcnt(cnt+clkfreq/2) 'if too frequent will affect sensor tempCON _clkmode = xtal1 + pll8x _xinfreq = 10_000_000 led = 6 wateralarm = 5 rx = 1 tx = 7 temphumdata = 12 temphumclk = 11 adccs = 14 adcclk = 13 adcdata = 15 VAR long stack1[noparse][[/noparse]50] long stack2[noparse][[/noparse]50] long datastring[noparse][[/noparse]17] byte ip byte ir long rawT, rawH OBJ serial : "Extended_FDSerial" compass : "Compass_IO_mini" sht : "Sensirion" acc : "memsic2125" acc2 : "memsic2125" bs2 : "BS2_FUNCTIONS" convert : "Simple_Numbers" math : "Floatstring" f : "Floatmath" PUB main BS2.start (8,9) 'compass.start dira[noparse][[/noparse]led]~~ dira[noparse][[/noparse]adccs]~~ dira[noparse][[/noparse]adcclk]~~ acc.start(4, 2) acc2.start(0, 3) ip := 0 ir := 0 datastring[noparse][[/noparse]0] := "s" datastring[noparse][[/noparse]1] := "," datastring[noparse][[/noparse]2] := 0 'pitch datastring[noparse][[/noparse]3] := "," datastring[noparse][[/noparse]4] := 0 'roll datastring[noparse][[/noparse]5] := "," datastring[noparse][[/noparse]6] := 0 'heading datastring[noparse][[/noparse]7] := "," rawT := 0 'temp datastring[noparse][[/noparse]9] := "," rawH := 0 'hum datastring[noparse][[/noparse]11] := "," datastring[noparse][[/noparse]12] := 736 'depth datastring[noparse][[/noparse]13] := "," datastring[noparse][[/noparse]14] := 0 'water alarm datastring[noparse][[/noparse]15] := "," datastring[noparse][[/noparse]16] := "e" cognew(TempHum (@rawT, @rawH), @Stack2) repeat until rawT <> 0 repeat until rawH <> 0 Serial.start(rx,tx,3,38400) '(rx pin, tx pin, mode, baudrate) repeat serial.tx(datastring[noparse][[/noparse]0]) serial.tx(datastring[noparse][[/noparse]1]) serial.dec(datastring[noparse][[/noparse]2]*-1) serial.tx(datastring[noparse][[/noparse]3]) serial.dec(datastring[noparse][[/noparse]4]*-1) serial.tx(datastring[noparse][[/noparse]5]) serial.dec(datastring[noparse][[/noparse]6]) serial.tx(datastring[noparse][[/noparse]7]) serial.dec(rawT)'(datastring[noparse][[/noparse]8]) serial.tx(datastring[noparse][[/noparse]9]) serial.dec(rawH)'(datastring[noparse][[/noparse]10]) serial.tx(datastring[noparse][[/noparse]11]) serial.dec((datastring[noparse][[/noparse]12])) 'serial.tx(datastring[noparse][[/noparse]13]) 'serial.dec(datastring[noparse][[/noparse]14]) serial.tx(datastring[noparse][[/noparse]15]) serial.tx(datastring[noparse][[/noparse]16]) serial.tx(13) waitcnt(14_000_000 + cnt) 'datastring[noparse][[/noparse]6] := compass.heading 'read compass 'datastring[noparse][[/noparse]14] := ina[noparse][[/noparse]wateralarm] 'read water alarm input pin !outa[noparse][[/noparse]led] 'flash status led 'pitch if ip == 0 datastring[noparse][[/noparse]2] := (acc.my/1680)-187 if datastring[noparse][[/noparse]2] > 45 ip := 1 if datastring[noparse][[/noparse]2] < -45 ip := 2 if ip == 1 datastring[noparse][[/noparse]2] := ((acc.mx / 1680) - 337) * -1 if datastring[noparse][[/noparse]2] < 45 ip := 0 if datastring[noparse][[/noparse]2] > 90 ir := 2 if datastring[noparse][[/noparse]2] > 135 ip := 0 if datastring[noparse][[/noparse]2] < 136 datastring[noparse][[/noparse]2] := (datastring[noparse][[/noparse]2] * -1) + 181 if ip == 2 datastring[noparse][[/noparse]2] := ((acc.mx / 1680) - 336) if datastring[noparse][[/noparse]2] > -45 ip := 0 if datastring[noparse][[/noparse]2] < -90 ir := 1 if datastring[noparse][[/noparse]2] < -135 ip := 0 if datastring[noparse][[/noparse]2] > -136 datastring[noparse][[/noparse]2] := (datastring[noparse][[/noparse]2] * -1) -180 if ip == 0 datastring[noparse][[/noparse]2] := (acc.my/1680)-187 'roll if ir == 0 datastring[noparse][[/noparse]4] := (acc2.my/1600)-249 if datastring[noparse][[/noparse]4] > 45 ir := 1 if datastring[noparse][[/noparse]4] < -45 ir := 2 if ir == 1 datastring[noparse][[/noparse]4] := ((acc2.mx / 1600) - 162) if datastring[noparse][[/noparse]4] < 45 ir := 0 if datastring[noparse][[/noparse]4] > 135 datastring[noparse][[/noparse]4] := ((acc2.my/1600) - 434) * -1 if datastring[noparse][[/noparse]4] > 180 ir := 2 if ir == 2 datastring[noparse][[/noparse]4] := ((acc2.mx / 1600) - 167) * -1 if datastring[noparse][[/noparse]4] > -45 ir := 0 if datastring[noparse][[/noparse]4] < -135 datastring[noparse][[/noparse]4] := ((acc2.my/1600) - 72) * -1 if datastring[noparse][[/noparse]4] < -180 ir := 1 if ir == 1 datastring[noparse][[/noparse]4] := ((acc2.mx / 1600) - 162) if datastring[noparse][[/noparse]4] < 45 ir := 0 if datastring[noparse][[/noparse]4] > 135 datastring[noparse][[/noparse]4] := ((acc2.my/1600) - 434) * -1 if datastring[noparse][[/noparse]4] > 180 ir := 2 if ir == 0 datastring[noparse][[/noparse]4] := (acc2.my/1600)-249 'depth outa[noparse][[/noparse]adccs] := 0 datastring[noparse][[/noparse]12] := bs2.SHIFTIN(adcdata, adcclk, BS2#MSBPost,12) outa[noparse][[/noparse]adccs] := 1 PUB TempHum(a,b) sht.start(temphumdata, temphumclk) repeat long[noparse][[/noparse]a] := sht.readTemperature long[noparse][[/noparse]b] := sht.readHumidity waitcnt(cnt+clkfreq/2)what you get back... as a raw reading is something on the order of 6777...
if you look at Cam's demo, this will all be fairly clear ... but just to paraphrase Cam's routine
the integer portion of your temperature in degrees C would be (raw value -3966)/100
the decimal portion will be (raw value -3966)//100
If you want to convert that to degrees F... there is also an equation in Cam's demo (from the SHT people) .... but first you get the degrees C AND then you can convert to F.
Hope this helps.
I put it together to study the relationship between temperature, set point and g measurements... then I got busy doing
something else... I modified it today to highlight the SHT reading and C degree value. It handles noise really well... and
you will notice that if you start the application and then the temperature in the room goes up, the temperature change is reflected by false acceleration, which contributes to a false MPH reading... on the other hand, if you start the application and the temperature goes down, nothing happens.
See if you can figure it out[noparse]:)[/noparse]
If my memory is working, the Memsic2125 unit has two pins we aren't using... an analog temperature out... and a reference voltage. I think if you put these into a ADC, we won't need the SHT. The ADC mentioned in Hanno's recent CC article seems like
it would be perfect.
The decimal portion calculation as above will produce some errors... [noparse]:)[/noparse]
Rich
Post Edited (rjo_) : 3/6/2009 10:30:43 PM GMT
The 2125 is internally compensated for temperature... So, it could be that most of what I am seeing is because I am not waiting long enough for it to stabilize...something else to look at[noparse]:)[/noparse]
I have had it running all day, and it is handling minor temperature changes really well.. with an ambient temperature in the room of about 28 C. Tonight I am going to turn the temperature in the room up and then go bowling. I'll let you know hat I see.
Rich
AND my accelerometer is reading... 172 MPH and climbing... I will now turn off the heater and report back tomorrow.
Rich
By the way... my bowling team won for the first since last summer!!!!
Post Edited (rjo_) : 3/7/2009 12:12:24 PM GMT
Much to my surprise, this morning's results are equally miserable(but now the mph is in the negative direction. But there is hope... if you follow the value of levelx, which results from the calibration step... it definitely seems to be related to ambient temperature. So the next step is to figure out a temperature calibration step... which might or might not require digitizing Tout.
And in the area of normal temperatures... the unit might be reasonably self-adjusting as long as the temperature is within a small range, I suspect that this range will be related to the initial calibration temperature. But I thought that negative temperature changes had no effect too... and they obviously do.
Rich
My memsic2125 has nothing to do with the temperature sensor... the memsic is used for pitch and roll sensing and that works perfect! My problem is only the sensirion that returns the same value whatever the temperature is...