Does tachyon have graphing capabilities? This is pretty cool!
Capable it is, graphing is whatever you tell it graphing is and on what.....
For instance you don't have high resolution VGA but you do have a terminal screen and you could "plot" horizontally up to the width of the screen while scrolling vertically. Last year I played with plotting a circle using the Minsky algorithm and to display it with sufficient resolution I simply reduced the font size of my terminal down to 0.5 so that each character became a "dot".
You can also log the data quite easily into EEPROM (or SD memory) and even time-stamp it with just a few lines of code.
For simple horizontal character plotting just scale your values down to within the character width of the screen so 78.0'F would simply be 78 with perhaps a width of 80 or more available.
I am going to bump this thread because as I was playing with Jonnymac's program I noticed the temp and humidity value were correct when I use the decimal values in the program. Is anyone else getting these weird results?
I just got around to hooking up a DHT22 and I cheated a little by feeding 5V through a red LED to VDD of the DHT22. Anyway the readings are correct as I read 28.6'C and 52.3% RH. This was tested on V4.7.
I just got around to hooking up a DHT22 and I cheated a little by feeding 5V through a red LED to VDD of the DHT22. Anyway the readings are correct as I read 28.6'C and 52.3% RH. This was tested on V4.7.
Here's the raw output
.. 15 DHT . SPACE . 286 523 ok
Peter-Thank you for that. However, what I meant by my post was Jonnymac's program jm_dht11_ez.spin is displaying incorrect values. Specifically, in his demo program he calls out:
pri scan_dht11(pin, secs) { ' call only with cognew()
} | mask, us1, bit1, t, idx, nbit, raw, cs
mask := |< pin ' create mask from pin
secs := (1 #> secs <# 10) * clkfreq ' limit period, convert to ticks
us1 := clkfreq / 1_000_000 ' ticks in 1us
bit1 := us1 * 35 ' minimum threshold for 1 bit
ctra := (%01000 << 26) | pin ' measure positive pulse
frqa := 1
t := cnt
repeat
dira[pin] := 1 ' pull pin low
waitcnt(t += (us1 * 20_000)) ' hold 20ms
dira[pin] := 0 ' release pin
longfill(@raw, 0, 2) ' clear raw and cs
waitpne(mask, mask, 0) ' response low
waitpeq(mask, mask, 0) ' response high
waitpne(mask, mask, 0) ' start of packet
repeat idx from 0 to 4 ' get five bytes (4 raw + cs)
repeat nbit from 7 to 0 ' MSBFIRST
phsa := 0 ' clear timer
waitpeq(mask, mask, 0) ' wait for start pulse
waitpne(mask, mask, 0) ' wait for end of pulse
if (phsa => bit1) ' check bit timing
raw.byte[idx] |= |< nbit ' set bit if 1
repeat idx from 0 to 3 ' validate packet
cs -= raw.byte[idx]
if (cs == 0) ' if good packet
rhtresult := raw ' transfer result to user
badchecksum := false ' clear error flag
else
badchecksum := true ' set error flag
++count ' update reading count
waitcnt(t += secs) ' let loop timer expire
According to the datasheet, byte 0 is the humidty, byte 1 is humidity fraction, byte 2 is temp. whole, byte 3 is temp fraction. When I use the program with just the whole temp. and humidity- ie. using only byte 0 and byte 2; i get 32 deg F and 0% humidity. But, when I change the program to use the temp.+fractional temp, and humidity+fractional humidity (pub rh10 and tf10 respectivily) I get correct values.
I thought it might be due to this segment:
waitpne(mask, mask, 0) ' response low
waitpeq(mask, mask, 0) ' response high
waitpne(mask, mask, 0) ' start of packet
because I thought it was backwards (waitpne is true when the pin goes high etc), but when i changed the program it didnt fix the problem.
I am trying to expand my programming skills, and thought understanding why it wasent working correctly would help, but I cant figure out why it isnt working for whole but is working for fractional humidity and tempurature values.
Comments
Capable it is, graphing is whatever you tell it graphing is and on what.....
For instance you don't have high resolution VGA but you do have a terminal screen and you could "plot" horizontally up to the width of the screen while scrolling vertically. Last year I played with plotting a circle using the Minsky algorithm and to display it with sufficient resolution I simply reduced the font size of my terminal down to 0.5 so that each character became a "dot".
You can also log the data quite easily into EEPROM (or SD memory) and even time-stamp it with just a few lines of code.
For simple horizontal character plotting just scale your values down to within the character width of the screen so 78.0'F would simply be 78 with perhaps a width of 80 or more available.
Try this hybrid print/plot out for instance:
Thanks
Shawn
Here's the raw output
Peter-Thank you for that. However, what I meant by my post was Jonnymac's program jm_dht11_ez.spin is displaying incorrect values. Specifically, in his demo program he calls out:
pri scan_dht11(pin, secs) { ' call only with cognew() } | mask, us1, bit1, t, idx, nbit, raw, cs mask := |< pin ' create mask from pin secs := (1 #> secs <# 10) * clkfreq ' limit period, convert to ticks us1 := clkfreq / 1_000_000 ' ticks in 1us bit1 := us1 * 35 ' minimum threshold for 1 bit ctra := (%01000 << 26) | pin ' measure positive pulse frqa := 1 t := cnt repeat dira[pin] := 1 ' pull pin low waitcnt(t += (us1 * 20_000)) ' hold 20ms dira[pin] := 0 ' release pin longfill(@raw, 0, 2) ' clear raw and cs waitpne(mask, mask, 0) ' response low waitpeq(mask, mask, 0) ' response high waitpne(mask, mask, 0) ' start of packet repeat idx from 0 to 4 ' get five bytes (4 raw + cs) repeat nbit from 7 to 0 ' MSBFIRST phsa := 0 ' clear timer waitpeq(mask, mask, 0) ' wait for start pulse waitpne(mask, mask, 0) ' wait for end of pulse if (phsa => bit1) ' check bit timing raw.byte[idx] |= |< nbit ' set bit if 1 repeat idx from 0 to 3 ' validate packet cs -= raw.byte[idx] if (cs == 0) ' if good packet rhtresult := raw ' transfer result to user badchecksum := false ' clear error flag else badchecksum := true ' set error flag ++count ' update reading count waitcnt(t += secs) ' let loop timer expireand:
pub rh '' Return relative humidity (whole %) return rhtresult.byte[0] pub rh10 '' Return relative humidity (tenths %) return (rhtresult.byte[0] * 10) + rhtresult.byte[1] pub tc '' Return temperature in Celsius (whole degrees) return rhtresult.byte[2] pub tc10 '' Return temperature in 0.1 degree Celsius return (rhtresult.byte[2] * 10) + rhtresult.byte[3] pub tf '' Return temperature in Fahrenheit (whole degrees) return tc * 9 / 5 + 32 pub tf10 '' Return temperature in 0.1 degree Fahrenheit return tc10 * 9 / 5 + 32_0According to the datasheet, byte 0 is the humidty, byte 1 is humidity fraction, byte 2 is temp. whole, byte 3 is temp fraction. When I use the program with just the whole temp. and humidity- ie. using only byte 0 and byte 2; i get 32 deg F and 0% humidity. But, when I change the program to use the temp.+fractional temp, and humidity+fractional humidity (pub rh10 and tf10 respectivily) I get correct values.
I thought it might be due to this segment:
waitpne(mask, mask, 0) ' response low waitpeq(mask, mask, 0) ' response high waitpne(mask, mask, 0) ' start of packetbecause I thought it was backwards (waitpne is true when the pin goes high etc), but when i changed the program it didnt fix the problem.I am trying to expand my programming skills, and thought understanding why it wasent working correctly would help, but I cant figure out why it isnt working for whole but is working for fractional humidity and tempurature values.
I hope I am being clear.
Thanks again,
Shawn
just using the first byte will not give you what you want because byte[0] is not (byte[0]*10+byte[1])/10
Mike
Yes, but isn't byte[0]/[2] the whole number of the humidity/temperature?
I think naming it WHOLE in the comments is misleading, @Peter named it the INTEGRAL part, making more sense.
unless byte[1] or byte[3] just return a value between 0 and 9 the fractional part is not just a decimal fraction below zero.
maybe you can post some readings of byte[0/1} and byte [2/3] to figure that out.
Mike