Temperature & Humidity sensor -with LCD & RF

[will 17]

Hi everyone, this is my credit card size wireless sensor node,

with a 7-seg LCD display showing temperature & humidity, update every second.

using MSP430FR4133 with HDC1080,BMP180 and OPT3002, 

transmit by nRF24l01, which sends out temp,humid,pressure,luminosity and also battery voltage per minute.

 

 

It is all power by a CR2032, and thanks to MSP430FR4133, I can manage to have half an year battery life.

also thanks to MSP430RF4133 Launchpad with build-in energyTrace, I can estimate battery life with a click(no more oscilloscope  )

note that I've actually put an RF430 on the down left ot the board(there is an antenna for that),

which will act as a NFC tag, but it draws too much current (~15uA), so I took it off

and at the down right is the battery voltage measurement with a mosfet to cut the power,

but I found out that I can just measure internal voltage reference to calculate its supply voltage, so I've also remove that. 

 

although I'm pretty much satisfy with this power consumption, but I still think that 16.5uA is a little bit too far from estimating from datasheet

and I am still trying to figure that out

[spirilis 1,264]

Well done!  Where'd you get the LCD?

[chicken 630]

I echo @@spirilis in praise and question.

 

Super nice work. As for the missing 15uA: Did you verify power consumption of the RF module?

[will 17]

I get it from some LCD manufacture at their retail store on taobao

Takes quite some time to find

https://item.taobao.com/item.htm?spm=a1z09.2.0.0.1bs8wy&id=14933583467&_u=j1f5oh4m0dc1

 

 

@@chicken that might be the problem, I've measured current consumption every time I put new part on,

MSP430FR4133 (@LPM3) 1.1uA => SHT21 2uA => BMP180 2.3uA => OPT3002 2.3uA

 

So maybe I'll measure nRF alone to see if it is the problem,

also note that I've seen a strange current curve after transmit

seems to charging some thing, but not sure what happen there.

that also damage the battery quite a lot.

[chicken 630]

Wow, that's a nice display for less than $0.75 US.

 

The curve looks like a cap charging. But as the vertical scale is basically current (P = I*V, but voltage is constant) it isn't a cap, nor is there one big enough on your board that would take 7 seconds to charge.

 

It may be the radio increasing power until it is able to successfully transmit a packet.

[will 17]

After removing LCD from my second board, I got 4uA idle current, which is pretty close to the datasheet.

So the problem is the LCD, which draws about 12.5uA, three times than other component

I have turned on Low power LCD mode, so I guess this is the limit  .

 

I still cannot figure out the strange curve though, I've measure my previous sensor node (Atmega328 + HDC1000 + BMP085)

there is no strange curve like that.

 

Interesting though, my previous sensor node has a lot more idle current(27uA vs 16.5uA), also maximum power(16mA vs 10mA)

but because it doesn't need to wakeup every second for update, the average current is much more than previous one(44.6uA vs 77.8uA)

 

So the Temp&Humid sensor active power consumption actually quite take a lot then I thought. I'll try some other sensor next time.

[dubnet 238]

Excellent project and I really like the overall design (features, board design, etc.)

 

Regarding the strange curve after transmit.  Is it possible that the RF itself may be interfering with the current measurement by inducing a small charge into the measurement circuit itself?

[V0JT4 34]

Very nice project. I'm just wondering if you considered single sensor solution for temp,humid,pressure with BME280?

[will 17]

After quite a while, here is the voltage curve during ~92days

And still keep going, I guess it still cannot get to 180 days because the minimum supply voltage of HDC1080 is 2.7.

but the my other card is using HTU21D, which can operate until 2v.

 

While still testing the battery life, I'm designing the second version, and encounter some problem with BSL.

After seen the GoodFET42 design, I also want to put a USB to UART, so I can upload the firmware with USB.

I tried using python-msp430-tools (bsl5), and connect DTR to RST, RTS to TEST, and checked the BSL sequence and the response using Logic analyzer.

but it seems sending the wrong CRC (I seen the response as CRC error), not sure why python package sends the wrong CRC.

has anyone tried uploading to MSP430FR4133 using BSL?

 

 

Also, I seen 8pino is using PCB as micro USB socket, so I'll also try that

also looking for some new sensor, BME280 looks pretty good.

[chicken 630]

Re BSL: I plan to use the Python libraries myself to let users upgrade the firmware on my AIS Receiver HAT for the Raspberry Pi.

 

At least when trying to combine it with UART BSL compiled from source code (I can't use the built in BSL due to retarded pin assignment) the Python library turned out to be very buggy, to a level where I wonder if it was ever working for UART.

 

If I remember correctly, the bug with the CRC calculation was that it included the BSL header instead of just the payload. Attached the fixed libraries that work for me.

 

My code does not cover getting the device into bootloader mode, i.e. it assumes a separate procedure to get there (in my case selecting a menu option in a serial terminal). From there working with the BSL from Python works like this:

bsl_target = bsluart.SerialBSL5Target()
bsl_target.logger.setLevel(logging.DEBUG)
ch = logging.StreamHandler(sys.stdout)
ch.setLevel(logging.DEBUG)
formatter = logging.Formatter('%(name)s - %(levelname)s - %(message)s')
ch.setFormatter(formatter)
bsl_target.logger.addHandler(ch)
print "Connecting to BSL"
bsl_target.open(args.port)
print "BSL version:", bsl_target.version()
bsl_target.detect_buffer_size()
print "BSL buffer size:", bsl_target.buffer_size
print "Writing into MCU memory"
# bsl_target.memory_write(0x2866, "hello world")
# bsl_target.execute(0x2866)
bsl_target.close()

As you can tell, it's still work in progress. But at least the communication with the bootloader on the MCU is now working.

bsluart.zip

[will 17]

Great thanks!

I modify the uart.py a little bit to fix the CRC bug as you said

and it works!

Thanks a lot 

 

also attached the modified version of bsl5.py

 

Re BSL: I plan to use the Python libraries myself to let users upgrade the firmware on my AIS Receiver HAT for the Raspberry Pi.

 

At least when trying to combine it with UART BSL compiled from source code (I can't use the built in BSL due to retarded pin assignment) the Python library turned out to be very buggy, to a level where I wonder if it was ever working for UART.

 

If I remember correctly, the bug with the CRC calculation was that it included the BSL header instead of just the payload. Attached the fixed libraries that work for me.

 

My code does not cover getting the device into bootloader mode, i.e. it assumes a separate procedure to get there (in my case selecting a menu option in a serial terminal). From there working with the BSL from Python works like this:

bsl_target = bsluart.SerialBSL5Target()
bsl_target.logger.setLevel(logging.DEBUG)
ch = logging.StreamHandler(sys.stdout)
ch.setLevel(logging.DEBUG)
formatter = logging.Formatter('%(name)s - %(levelname)s - %(message)s')
ch.setFormatter(formatter)
bsl_target.logger.addHandler(ch)
print "Connecting to BSL"
bsl_target.open(args.port)
print "BSL version:", bsl_target.version()
bsl_target.detect_buffer_size()
print "BSL buffer size:", bsl_target.buffer_size
print "Writing into MCU memory"
# bsl_target.memory_write(0x2866, "hello world")
# bsl_target.execute(0x2866)
bsl_target.close()

As you can tell, it's still work in progress. But at least the communication with the bootloader on the MCU is now working.

 

uart.zip