Trouble with temp probe and accelerometer
The Lazy Destroyer
Posts: 21
Hi guys have a little problem w/ a project I'm finishing up this weekend. I got the ad592 temperature probe (read using RCTIME) from Parallax and it is acting wierd when coded with the Memsic 2125 GMeter. After playing around with the program I'm thinking that timing, even from different subroutines, affects the readings I get. For example, here is the code I use to read the sensor:
I get the proper readings from the code above. When I copy/pasted it into my working project source code I got a very offset number. The main section of the code is:
I started cutting the program down and changing some things around and I came to the conclusion that time, even in a different subroutine, will affect the output of the TempMain subroutine. For example, if I increase or decrease the amount of times that the GForceMain subroutine gets looped, the readings change. The smaller the times the loop gets run, the closer the TempMain subroutine comes to getting an accurate number. If I put "PAUSE 500" before or after the "GOSUB TempMain" line it will affect it significantly, but if I put "PAUSE 50" it will be offset by only 5 or so degrees much less than pausing it for longer amounts of time.
I'm also thinking that the different readings the accelerometer get take either longer or shorter amounts of time to process, because if I run the two subroutines in a 1 to 1 ratio (ei, take out GForceMain's loop), then the readings I get from the accelerometer also change the readings that RCTIME gives me for the 592 probe
LINK: Here's a video example,
here you can see how the gforces are also affecting the temp readings. I'm figuring the more forces the gmeter is seeing, the longer it takes to process maybe. Just assuming from what I've seen with toying w/ the timing.
Is this something that you all have seen before? I've never used RCTIME before, but wouldn't think it would get affected like this.
Even if I go back to the original TempMain subroutine and take out the "Pause 50" I'm getting different readings. I'm thinking if I code everything up for my project to include EVERYTHING I'm using and then re-calibrate the sensor, maybe that will get me proper readings but still doesn't change how the accelerometer is affecting it, since its values will change often.
What else can I do????
Please let me know if there is more info in particular you guys need.
Kal CON 31530'<-consant from calibration program, resistor/capacitor specific Tempf VAR Word DO LOW 8 RCTIME 8, 0, Tempf Tempf = (((Kal/Tempf*10 + (Kal//Tempf*10/Tempf))-273)*18) + 320 DEBUG TAB, DEC2 Tempf/10, ".", DEC1 Tempf, %11011111, 1 PAUSE 50 LOOP
I get the proper readings from the code above. When I copy/pasted it into my working project source code I got a very offset number. The main section of the code is:
Main: GOSUB TempMain FOR Genx = 0 TO 500 GOSUB GForceMain NEXT GOTO Main
I started cutting the program down and changing some things around and I came to the conclusion that time, even in a different subroutine, will affect the output of the TempMain subroutine. For example, if I increase or decrease the amount of times that the GForceMain subroutine gets looped, the readings change. The smaller the times the loop gets run, the closer the TempMain subroutine comes to getting an accurate number. If I put "PAUSE 500" before or after the "GOSUB TempMain" line it will affect it significantly, but if I put "PAUSE 50" it will be offset by only 5 or so degrees much less than pausing it for longer amounts of time.
I'm also thinking that the different readings the accelerometer get take either longer or shorter amounts of time to process, because if I run the two subroutines in a 1 to 1 ratio (ei, take out GForceMain's loop), then the readings I get from the accelerometer also change the readings that RCTIME gives me for the 592 probe
LINK: Here's a video example,
here you can see how the gforces are also affecting the temp readings. I'm figuring the more forces the gmeter is seeing, the longer it takes to process maybe. Just assuming from what I've seen with toying w/ the timing.
Is this something that you all have seen before? I've never used RCTIME before, but wouldn't think it would get affected like this.
Even if I go back to the original TempMain subroutine and take out the "Pause 50" I'm getting different readings. I'm thinking if I code everything up for my project to include EVERYTHING I'm using and then re-calibrate the sensor, maybe that will get me proper readings but still doesn't change how the accelerometer is affecting it, since its values will change often.
What else can I do????
Please let me know if there is more info in particular you guys need.
Comments
The mesmic is a thermal device, and has a thermal output, so why do you have a temp probe? The answer is probably timing. Could you send a complete code file and the schematic? That would help a lot.
When I get back home later tonight I'll try and get the full code and schematic for you guys.
A couple points:
-Changing any of the pause lengths that are in any part of the main routine change the output of the sensor, generally the longer the overall pause the higher the value it gets from RCTIME and it's following calculation. This also includes the GMeters loop.
-Right now everything (Stamp, backlit LCD, clock/EEPROM/compass/GMeter) are all being powered by the demo board, but I haven't had any issues with this other than some flickering on the LCD screen that I figure is just from noise.
-Sensor is calibrated
' ------------------------------------------------------------------------- ' ------------------------------------------------------------------------- ' {$STAMP BS2p} ' {$PBASIC 2.5} ' ------------------------------------------------------------------------- ' Revision History ' Start date 12/26/05 ' Blake Werner - for Project: Homebrew PCM V1 ' Page 2 ' ------------------------------------------------------------------------- ' ------------------------------------------------------------------------- ' ------------------------------------------------------------------------- ' I/O Definitions ' ------------------------------------------------------------------------- Clock PIN 3 ' Clock (generic) Xin PIN 5 ' X input from Memsic 2125 Switch PIN 6 ' Page change switch ' ------------------------------------------------------------------------- ' Constants ' ------------------------------------------------------------------------- Ack CON 0 ' acknowledgement NoAck CON 1 ' no acknowledgement No CON 0 Yes CON 1 DegSym2 CON %11011111 ' degrees symbol for Serial Cur_home CON 72 'Cursor home position for LCD Cursor_pos CON 71 'Cursor position for LCD (column then row) Clear_screen CON 88 'Clears screen for LCD Tx CON 2 'Transmit pin TO LCD Baud CON 110 'Equals baud rate of 19.2k (LCD) Int CON 254 'To be placed before each instruction (LCD) Kal CON 31530 'Constant for temp sensor Scale CON $0C0 ' 0.75 us per unit (BS2P Specific) HiPulse CON 1 ' measure high-going pulse (G-forces) LoPulse CON 0 ' Same DegSym CON 176 ' degrees symbol for Memsic ' ------------------------------------------------------------------------- ' Variables ' ------------------------------------------------------------------------- x VAR Word GenX VAR Word 'Generic variable for any/all subroutines xRaw VAR Word ' pulse from Memsic 2125 (G-Forces) xmG VAR Word ' g force (1000ths) (G-Forces) 'idx VAR Byte '(Time) 'sec VAR Byte(6) '(Time) minute VAR Byte hour VAR Byte AMPM VAR Bit 'rct VAR Word Tempf VAR Word 'Temp variable ' ------------------------------------------------------------------------- ' Initialize ' ------------------------------------------------------------------------- SEROUT Tx,Baud,[noparse][[/noparse]Int,Clear_screen] SEROUT Tx, Baud, [noparse][[/noparse]Int,104] 'Init graph for LCD GenX = 0 x = 0 ' ------------------------------------------------------------------------- ' Program Code ' ------------------------------------------------------------------------- 'GOSUB GForceMain Main: 'IF Switch = 1 THEN RUN 2 'PAUSE 500 'PAUSE 500 GOSUB TimeMain PAUSE 10 GOSUB TempMain PAUSE 10 FOR Genx = 0 TO 10 GOSUB GForceMain 'IF Switch = 1 THEN RUN 2 NEXT GOTO Main END ' ------------------------------------------------------------------------- ' Subroutines ' ------------------------------------------------------------------------- ' G-Forces Subroutines ' ------------------------------------------------------------------------- GForceMain: GOSUB Read_G_Force ' reads G-force x=((ABS xmG)/20)'+10 IF ABS xmG.BIT15 = 0 THEN GOTO Positive IF ABS xmG.BIT15 = 1 THEN GOTO Negative RETURN Positive: SEROUT Tx, Baud, [noparse][[/noparse]Int,Cursor_pos,11,1," "] SEROUT Tx, Baud, [noparse][[/noparse]Int,124,10,1,1, x] RETURN Negative: SEROUT Tx, Baud, [noparse][[/noparse]Int,Cursor_pos,1,1," "] SEROUT Tx, Baud, [noparse][[/noparse]Int,124,11,1,0, x] RETURN Read_G_Force: PULSIN Xin, HiPulse, xRaw ' read pulse output xRaw = xRaw */ Scale ' convert to uSecs xmG = ((xRaw / 10) - 500) * 8 ' calc 1/1000 g RETURN ' Temperature Subroutines ' ------------------------------------------------------------------------- TempMain: LOW 8 RCTIME 8, 0, Tempf Tempf = (((Kal/Tempf*10 + (Kal//Tempf*10/Tempf))-273)*18) + 320 SEROUT Tx, Baud, [noparse][[/noparse]Int,Cursor_pos,1,2, DEC2 (Tempf / 10), ".", DEC1 Tempf, %11011111] RETURN ' Time Subroutines ' ------------------------------------------------------------------------- TimeMain: I2CIN 0,%11010001,1,[noparse][[/noparse]minute] I2CIN 0,%11010001,2,[noparse][[/noparse]hour] 'conversion: hour = hour - %01000000 ' Conversion for correct 12-hour read AMPM = hour.BIT5 IF hour.HIGHNIB = $3 THEN hour = hour - %100000 IF hour.HIGHNIB = $2 THEN hour = hour - %100000 SEROUT Tx, Baud, [noparse][[/noparse]Int,Cursor_pos,15,2,HEX hour.HIGHNIB, HEX hour.LOWNIB, ":",HEX minute.HIGHNIB,HEX minute.LOWNIB] IF AMPM = 0 THEN SEROUT Tx, Baud, [noparse][[/noparse]"a"] IF AMPM = 1 THEN SEROUT Tx, Baud, [noparse][[/noparse]"p"] IF hour.HIGHNIB=0 THEN SEROUT Tx, Baud, [noparse][[/noparse]Int,Cursor_pos,14,2," "] RETURNJust ran this program, the basic one in the Applied Sensors text I got from Parallax:
' Applied Sensors - AD592.bs2 ' Reading the AD592 temperature sensor using the RCTIME command. ' {$STAMP BS2p} ' {$PBASIC 2.5} Kal CON 15300 ' Constant to be determined. rct VAR Word ' A word variable. TK VAR Word ' Kelvin temperature. TC VAR Word ' Degrees Celsius. DO ' Loop forever. LOW 8 ' Discharge the capacitor. RCTIME 8, 0, rct ' Time for the volts to rise to 1.3 V. TK = Kal/rct*10 + (Kal//rct*10/rct) ' Calculate Kelvin TC = TK - 273 ' and Celsius. DEBUG DEC rct, TAB, DEC TK, ' Show the results. TAB, SDEC TC, 1 PAUSE 50 ' Slows down the program. LOOPThe last line, "Pause 50". If I run it I get the value 1057, but if I change it to pause for say 750, I get 1041 returned as my value, both run within a minute of each other.
So, looking at the program above instead of the whole code I gave a minute ago... is there a reason this is happening? I thought maybe I'm not giveing it enough time to "settle back down" to read RCTIME but the original code (posted above) only has a 50 for a PAUSE value and it loops constantly. Should I look into something else other than RCTIME? This is just odd.
I was in near the same situation when trying to insert in a project multiple items, some of them working in local continuosly and being interrogated on needing.
the solution in some cases was to switch of temporarily the items not necessary (think of a reading from an ADC 12 or more bit of resolution near a switching regulator for a backligth), i solved this switching off the regulator backlight for the few milliseconds it takes to get the reading properly and safely stored in memory).
Perharps this helps.........
Stefano Caruso
By putting the LOW 8 instruction immediately following the RCTIME command, that allows a big expanse of time for the capacitor to discharge and it shouldn't matter if you substitute 750 for the 50 millisecond PAUSE. Most of the RCTIME programs in Applied Sensors have the LOW rcPin instruction immediately after completion of the RCTIME command.
Your program (and the Applied Sensors example) has the following snippet
There is not enough time after the LOW for the capacitor to discharge completely, particularly when you are using the much faster BS2p. With a original BS2, there was around 300 microseconds, but with the fast BS2p there is only 1/3 of that. The reason the timing in the rest of the program affects it is that the voltage on the capacitor continues to rise after execution of the RCTIME command, so
Another way to fix it would be,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com