I'm still new at coding and was able to put together some code from other sources for a simple weather station I built. Everything seems to be working fine but I do get the occasional hiccup where temperature readings on the display show additional decimals points beyond 0.1-0.9. I inserted a round command to round to the nearest decimal which I thought would take care of that but it still happens randomly. There are no issues when displaying temperature readings through the shell. It seems to add additional decimal points at random temperature readings just on the display. I've included pictures and code. Definitely would appreciate any help I can get figuring out this issue. Thank you.
from machine import Pin
import utime as time
from pico_i2c_lcd import I2cLcd
from machine import I2C
from DHT22 import DHT22
i2c = I2C(id=1,scl=Pin(27),sda=Pin(26),freq=100000)
lcd = I2cLcd(i2c, 0x27, 2, 16)
dht_data = Pin(15,Pin.IN,Pin.PULL_UP)
dht_sensor=DHT22(dht_data,Pin(14,Pin.OUT),dht11=False)
while True:
T,H = dht_sensor.read()
#Converted to Fahrenheit (FT) for LCD display
FT = T*1.8+32
if T is None:
print(" sensor error")
else:
print("{:3.1f}'C {:3.1f}%".format(T,H))
#DHT22 not responsive if delay too short
time.sleep_ms(500)
lcd.clear()
lcd.move_to(0,0)
lcd.putstr('Temp:')
lcd.move_to(10,0)
#If using Celsius, change (FT) to (T) and "F" to "C" on line below
lcd.putstr(str(round(FT, 1))+"F")
lcd.move_to(0,1)
lcd.putstr('Humidity:')
lcd.move_to(10,1)
lcd.putstr(str(H)+"%")`
what it normally looks like
the hiccup that randomly appears
Related
I have a micropython program on a ESP32 connected to a stepper motor via a driver board.
The software runs in a while true loop. I'm trying to get the azimuth difference between 30 second previous azimuth reading and the post 30 second azimuth reading, then send the difference to the stepper motor. Unfortunately they will not let me post all my code, so here is a small example.....
import math
import time
import Stepper
from machine import Pin
s1 = Stepper.create(Pin(26,Pin.OUT),Pin(25,Pin.OUT),Pin(33,Pin.OUT),Pin(32,Pin.OUT),
delay=2)
while True:
xxxxx loop in here I have working code that updates the Azimuth of the sun in
realtime every 30 seconds XXXXXXX
s1.angle(azimuth, -1)
time.sleep(30)
I'm trying to run the code below on an ESP32 TTGO T-display running micropython from loboris. (It's esp32 pre-loaded with display drivers for TTGO Display) I have attached a GY-906 temp sensor through i2c for testing. i2c.scan() finds it without issue on 0x5a [80] like it is supposed to, but when I request temperature data, the response is always 0xFF instead of proper temperature readings.
When I run the exact same code on a WeMos D1 (only difference is the pin numbers) I get temperature data returned. I am attaching both logic analyzer screenshots hoping someone can tell me what I need to do differently. Both are directly wired from 3.3, gnd, and the 2 i2c pins.
Things I have tried: adding pull up resistors to SDA, SLC (10k, 1k, 100). Switching to different i2c pins. Result seems to be the same. What am I missing? Is there supposed to be a resistor somewhere I don't know about? Other hardware? The screenshots make me think that the GY906 is responding, just the wrong response value.
Main Code
import temp_sensor
Pin = machine.Pin
I2C = machine.I2C
i2c = machine.I2C(0, scl=Pin(22), sda=Pin(21), freq=100000)
temp1 = temp_sensor.Temp.init(i2c)
print(temp1.read_object_temp())
time.sleep(1)
print(temp1.read_object_temp())
time.sleep(1)
print(temp1.read_object_temp())
time.sleep(1)
print(temp1.read_object_temp())
temp_sensor.py
import mlx90614 ##From https://github.com/mcauser/micropython-mlx90614
class Temp():
def init(i2c):
try:
sensor = mlx90614.MLX90614(i2c)
except:
print('couldnt connect to an i2c temp sensor')
sensor = False
else:
print('temp found')
#return sensor
finally:
return sensor
bad esp32 TTGO T-Display:
good 8266:
For anyone receiving 1037.55 responses from your gy-906 or MXL90614 sensor, that translates to 0xFF, 0xFF or all high (ones) from the sensor. This seems to happen when the sensor doesn't understand how to respond. (Thank you, #jasonharper for helping me understand this)
Here's how the math works:
The 0xFF, 0xFF in decimal is 65535.
The sensor resolution is 1/50 of
a degree which means you divide 65535 x 0.02 to convert to Kelvin, or
1310.7 (K)
Kelvin to Celsius (subtract 237.15) gets you 1037.55 C
Celsius to Fahrenheit gets you 1899.59 F
Bottom line, your sensor is hiccuping because it doesn't like the stop bit between the write and read, or you have a problem with your I2C bus, either the protocol is doing the request wrong or you have a cabling issue (length or wire gauge or connection, etc).
If it's the protocol like it was for me, see if anyone has updated the I2C system library recently and try a different version if possible.
I traced this issue down for days. Luckily I had a number of different MicroPython capable chips and was able to narrow it down to an old version of the machine.I2C library adding that stupid "stop" above.
I bought a $10 protocol analyzer on amazon to make that image above, and I tried loading the code on each of these: Wemos D1, HitLego ESP32S and TTGO T-Display. By trying the code on each, I was able to narrow it down to only the T-Display not working, which needed an custom old firmware version to get the ST7789 display working. The next step is to try to update and recompile the display library from loboris to work with the most recent Micropython firmware. If I make it work, I will reply below.
I'm trying to get temperature from LIS3DH sensor (accelerometer with integrated temperature sensor)
I'm using Particle electron board that contain that sensor.
The datasheet provide too few information
set TEMP_EN and ADC_EN from TEMP_CFG_REG register.
I read value that fluctuate continuously and does not correspond, to temperature.
Do you know which register I have to consider to get it works ?
The datasheet states that to connect ADC3 to the temperature sensor, set both TEMP_EN and ADC_EN of the TEMP_CFG_REG register to 1.
Then read OUT_ADC3_L to get the raw value and use the Temperature sensor characteristics table for conversion.
Hope this helps.
I am writing some simple code using MicroPython running on a Digistump Oak, which is basically an ESP8266 breakout board. I'm trying to understand the behavior that I see when performing periodic reads of the sensors via i2c.
The following code (which reads the value of the ACCEL_XOUT_H and ACCEL_XOUT_L registers) works just fine:
>>> from machine import Pin, I2C
>>> bus = I2C(scl=Pin(2), sda=Pin(0))
>>> while True:
... h, l = bus.readfrom_mem(0x68, 0x3b, 2)
... print (-((((h<<8)+l)^0xFFFF) + 1) if (h & (1<<7)) else (h<<8)+l)
(That print statement is just performing the conversion from two's complement.)
As expected, that prints out values from the accelerometer that change in approximately real time as I move the imu around.
But if I introduce a delay into the loop, such as...
>>> import time
>>> from machine import Pin, I2C
>>> bus = I2C(scl=Pin(2), sda=Pin(0))
>>> while True:
... h, l = bus.readfrom_mem(0x68, 0x3b, 2)
... print (-((((h<<8)+l)^0xFFFF) + 1) if (h & (1<<7)) else (h<<8)+l)
... time.sleep(1)
...I see some very strange behavior. The values returned by the i2c read operation continue to remain the same for many iterations after the imu has changed orientation. I'm at a loss as to what is going on here: the i2c read operations read from the registers on the imu, which according to the documentation are updated at the sampling rate, which in a default configuration is going to be 1Khz. I don't see anything in the code or data path that could be latching or caching these values somehow.
This is the documentation on the accelerometer registers, as found in the Register Map and Descriptions document:
These registers store the most recent accelerometer measurements.
Accelerometer measurements are written to these registers at the
Sample Rate as defined in Register 25.
The accelerometer measurement registers, along with the temperature
measurement registers, gyroscope measurement registers, and external
sensor data registers, are composed of two sets of registers: an
internal register set and a user-facing read register set. The data
within the accelerometer sensors’ internal register set is always
updated at the Sample Rate. Meanwhile, the user-facing read register
set duplicates the internal register set’s data values whenever the
serial interface is idle.
Since I'm sleeping between read calls, I'm pretty sure the i2c serial interface is idle by any definition, and I don't see anything else seems relevant to this behavior.
Do you have any suggestions as to what could be going on here?
Looking for some help to be honest, This is not my area of knoladge atall.
Ive read around the question of powering my Pi with a battery, now I nabbed one of these guys for my phone
http://www.amazon.co.uk/13000mAh-Portable-External-Technology-Motorola-Black/dp/B00BQ5KHJW/ref=sr_1_cc_1?s=aps&ie=UTF8&qid=1420826597&sr=1-1-catcorr&keywords=anker+astro+e4
Incase the link dies in the future;
Item model number: AK-79AN13K2-BA
Anker® 2nd Gen Astro E4 13000mAh 2-Port (3A Output) Fast
Max 3A Out
5V Out
Now, from what i've read there have been mixed notes of, don't use batterys, only use this battery, don't do this, don't exeed this magical number ( which was differant each time ). so any help would be grately needed. If i was to power my pi via this thing. im I going to get a poof of smoke and need to replace the poor pi :(
A raspberry Pi is powered via USB, which means that it simply takes the 5V supplied via USB to run. As long as your current source is stable (ie. it doesn't change when you draw current from it), no device will care whether it is a battery or a switching power supply. Now, a bare raspberry Pi B uses less than 2W of power, 2W/5V = 0.4A = 400mA, so if that battery pack lives up to its specification, you are going to be fine. The device is spec'ed to provide 13000mAh, so at a constant current of 400mA, this would last you more than 32 hours.
Now, most people attach something to the raspberry, and that something will also draw power, but just add that power to the calculations above, to see if it's going to work out.