will 17 Posted August 18, 2016 Share Posted August 18, 2016 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 timotet, Fmilburn, terjeio and 8 others 11 Quote Link to post Share on other sites
spirilis 1,265 Posted August 18, 2016 Share Posted August 18, 2016 Well done! Where'd you get the LCD? Quote Link to post Share on other sites
chicken 630 Posted August 18, 2016 Share Posted August 18, 2016 I echo @@spirilis in praise and question. Super nice work. As for the missing 15uA: Did you verify power consumption of the RF module? Quote Link to post Share on other sites
will 17 Posted August 19, 2016 Author Share Posted August 19, 2016 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 1 Quote Link to post Share on other sites
chicken 630 Posted August 19, 2016 Share Posted August 19, 2016 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. Quote Link to post Share on other sites
will 17 Posted August 23, 2016 Author Share Posted August 23, 2016 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. Quote Link to post Share on other sites
dubnet 238 Posted August 23, 2016 Share Posted August 23, 2016 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? zeke 1 Quote Link to post Share on other sites
V0JT4 34 Posted August 24, 2016 Share Posted August 24, 2016 Very nice project. I'm just wondering if you considered single sensor solution for temp,humid,pressure with BME280? Quote Link to post Share on other sites
will 17 Posted November 27, 2016 Author Share Posted November 27, 2016 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 1 Quote Link to post Share on other sites
chicken 630 Posted November 27, 2016 Share Posted November 27, 2016 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 1 Quote Link to post Share on other sites
will 17 Posted November 29, 2016 Author Share Posted November 29, 2016 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 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.