💬 Temperature and humidity sensor(ver.ATmega328)+E-Ink display
-
-
Nice work! Do you have a model number or link for the display?
-
-
SOFTWARE development is complete, everything is perfectly fit in 328 stone, and graphics and fonts... ...If you like - do like
-
of course it looks nice, "old school" work
just curious about the indoor range of the nrf24, where's the antenna??
-
@scalz said in
Temperature and humidity sensor with 1.54 E-Paper display:of course it looks nice, "old school" work
just curious about the indoor range of the nrf24, where's the antenna??The antenna is located on the inside of the first Board. All lines on both boards are separated from the antenna. Connection is great. OTA works without errors with full packages at a distance of 10 meters.
-
@scalz said in
Temperature and humidity sensor with 1.54 E-Paper display:old school
this is the fastest way to make a prototype
-
Now the most important thing is to develop a great body on a 3D printer
-
How do you achieve 3 years of runtime? How often do you wakeup the Atmega to measure the values and send them?
-
@gloob
If all average. And the battery capabilities and consumption of the device in pulse mode. Get the next 600/0.025/24/365=2.73 years.
Very conditional..but with reserve. If you put power to 9V, it is even longer, but the thickness of the device body is 2.5 mm more. The power supply parameters of the Converter allow (3.3 V TO 10V)The parameters of sending data in my program are configurable. Limited to an interval of 1 to 60 minutes.
I am very pleased with the testing of the device. At the moment there is one problem, the lack of space in atmega328. The solution to the problem may be to add flash memory to store the images, but again this is an unnecessary power consumption, perhaps better just a more ascetic output of the information to the screen.
-
@berkseo said in
Temperature and humidity sensor with 1.54 E-Paper display:
... At the moment there is one problem, the lack of space in atmega328.Maybe use an nRF52832 instead? Relatively speaking, they have much more available memory. It would be a shame to lose the nice look of your display.
-
@neverdie While it seems to be enough space)), with difficulty, but enough. I thought about using NRF5, now study it. ...I have been following your posts, you have come a long way in learning NRF5, you have a lot of success. Now I am interested in the possibility of waking NRF5 on demand on the radio.
-
Where can see see the eagle file of your PCB design?
-
This post is deleted!
-
@berkseo: do you have already any kind of code you could share? Even if it's alpha? I'm working a a very similar project also with 1.54 e-paper. Sor far it exceeded the RAM/FLash (both) of the 328p. I was using the GxEPD lib. I guess I have to use someting more memory efficient? Or what have you used/done with/for the e-paper?
-
@heinzv from a few posts up:
At the moment there is one problem, the lack of space in atmega328.
-
@mfalkvidd
that is what I'm arguing since quite a while and my major concern with the 328p. It has a ridiculous small ram and flash if you want to do something with things like an e-paper display. An almost empty mysensors temp sensor sketch with just adding the GxEPF lib and declaring the minimum display object leads to 101% RAM and flash is also runnin out. TFT and OLED displays are energy killer and e-paper see to be a ram killer.
So I'm trying to either to find a bare e-paper library (I've got some C code from Heltec) which I'll try or I have to give up to connect an e-paper to a 328p and really use a second MCU just for e-paper (as it was proposed), even if I don't like to have two MCU's, two sketches etc.
I see that nearly nobody is building a battery powered sensor with a display.
MCU's which can deal with all that (a lot of ram, flash, low energy modes) are the ESP MCU's but the sleep behavior seem to be an obstacle for the projects and nobody dares to deal with it - only the ESPeasy project is using and accepting the ESP deep sleep behavior with the warmstart concept.
So I will furthe rinvestigate which project will be the base for my battery powered sensors with a nice display.
-
...added some new photos
-
@heinzv said in
Temperature and humidity sensor with 1.54 E-Paper display:do you have already any kind of code you could share? Even if it's alpha? I'm working a a very similar project also with 1.54 e-paper. Sor far it exceeded the RAM/FLash (both) of the 328p. I was using the GxEPD lib. I guess I have to use someting more memory efficient? Or what have you used/done with/for the e-paper?
I mostly used the Standard Waveshare code for these displays +a bit of my features. I do not have a ready-made universal solution for you, because I did not have a task to write a library, I have only an optimized program for atmega328, especially for my device. Later, when the device is ready (very soon) , I will publish the program on my git
-
@heinzv said in
Temperature and humidity sensor with 1.54 E-Paper display:that is what I'm arguing since quite a while and my major concern with the 328p. It has a ridiculous small ram and flash if you want to do something with things like an e-paper display. An almost empty mysensors temp sensor sketch with just adding the GxEPF lib and declaring the minimum display object leads to 101% RAM and flash is also runnin out. TFT and OLED displays are energy killer and e-paper see to be a ram killer.
So I'm trying to either to find a bare e-paper library (I've got some C code from Heltec) which I'll try or I have to give up to connect an e-paper to a 328p and really use a second MCU just for e-paper (as it was proposed), even if I don't like to have two MCU's, two sketches etc.
I see that nearly nobody is building a battery powered sensor with a display.
MCU's which can deal with all that (a lot of ram, flash, low energy modes) are the ESP MCU's but the sleep behavior seem to be an obstacle for the projects and nobody dares to deal with it - only the ESPeasy project is using and accepting the ESP deep sleep behavior with the warmstart concept.
So I will furthe rinvestigate which project will be the base for my battery powered sensors with a nice display.Basically, the task I set for myself, I performed. The device works well, now 4 such temperature sensors are being tested in my house. My family likes this idea, because you can always look at the temperature in the room. Everything I wanted to do in my program, I did. All the code fit fine, I would say more I left room for cryptography, and cryptography of sufficient volume)). In the near future I will make a version of the program that will use external memory, because it is on my device. OTA has been shown not to be required on battery powered devices, especially those that always have physical access.
-
Here's how the test program works now:
T&H sensor 1.54 e-ink – 00:40
— Andrew EfektaSBThat in the most immediate plans:
Add a screen restart once a day or perhaps after a number of readings updates.
Add logos at the beginning of the download)).
To use flash memory.
...And I hope that maybe someone will like this project, and he will try to write his own version of the program...
-
Just made improvements on the Board:
-
..another photo with temperature sensors
-
@berkseo So I'm couris how you fit all in the 32k flash and 2k ram. Where can we get the code of the sketch? Do you make it available? I have the same requirement beside I wanted to use the RFM95 instead of the NRF24.
-
@heinzv He did say above that he'd make it available on his git after his device is ready, sometime soon.
@sberkseo Nice that you were able to solder on the smaller 328p chip.
-
@heinzv it's a great project and it will make me build some e-paper nodes.
But I don't understand why you don't want to switch to NRF52 ? You would have way more power and memory than you need, and much lower consumption in sleep mode.
-
@nca78 you're right, it has more RAM/Flash, low energy for battery usage and I have seen modules which are also around 4€.
I'll rethink my MCU strategy again for the battery sensors as I have seen that nRF52 is full supported (with sleep, deep sleep) in mySensors right?
Is this a board you can recommend and is there a PCB which can carry this barebone board? I would also like to use in in conjunction with an RFM95 (LoRa).
https://www.aliexpress.com/item/nRF52832-2-4GHz-Wireless-rf-Module-CDSENET-E73-2G4M04S-SPI-SMD-rf-Receiver-transmitter-Bluetooth-Module/32819293925.html?spm=2114.search0104.3.1.154316a3exrCMu&ws_ab_test=searchweb0_0,searchweb201602_5_5724111_10065_10068_5724211_10547_5723812_10548_5724311_5723712_5890011_10696_5723212_5724011_10084_10083_10618_5722212_10304_5970011_10307_10820_5723412_10821_5723312_10302_5723612_5723112_5910011_5723912_5722312_10059_5722112_100031_5725111_10103_5725011_5722412_5723012_5990011_5980011_5724911,searchweb201603_1,ppcSwitch_3&algo_expid=a0777517-1560-4235-9f5e-6be74d13d07d-0&algo_pvid=a0777517-1560-4235-9f5e-6be74d13d07d&transAbTest=ae803_1&priceBeautifyAB=0
-
Neverdie has created a few, https://www.openhardware.io/view/436/nRF52832-Breakout-Board for example
-
@nca78 said in
Temperature and humidity sensor with 1.54 E-Paper display:it's a great project and it will make me build some e-paper nodes.
But I don't understand why you don't want to switch to NRF52 ? You would have way more power and memory than you need, and much lower consumption in sleep mode.Such a sensor will be, until everything suits in 328 (consumption, memory). I'm still studying the NRF52 chip. Of special interest is the awakening from an external request. The standard implementation in NRF24 compatibility mode is not impressive
-
@berkseo Nice board and idea - would you mind posting your pcb layout files and testing sketch for the community?
-
@tekka
I think that I will update the information from few days on openhardware.io. Waiting for new PCB with the changes (rev2), their photo was spread higher in this topic. It is necessary to check them, if everything is ok, I update the information.
-
maybe someone can tell me why my Gerber files don't work here?
Latin letters?
-
-
@berkseo I have the same problem. This has been going on for some time now. @HEK needs to fix it, but hasn't. So, I end up posting images from OSHPARK, or else it looks like a mouse has gnawed away at my PCB. @HEK, how about fixing it?
-
Yeah, openhardware.io is dependent on the https://github.com/tracespace/gerber-to-svg / https://www.npmjs.com/package/pcb-stackup-core project. I use it to generate an svg which then is converted to png with alpha channel which is feed into some three.js magic hack on the frontend to "cut the holes" using alpha in the png.
Some gerbers seems to render a bit funny. I have tried tweaking it and have sent bug reports to the author a few times. But pcb-stackup is a slow progressing project. The outline have been disables due to even worse rendering in many occasions. Not sure what triggers faulty renderings. Kicad/Eagle gerbers seems to work better for some reason.
In this specific case I guess the problem is because you're using a none-standard naming of the gerber files. Check some other project on openhardware.io that renders fine to see the correct naming of the different layer-files.
-
@hek FWIW, in the past it seemed to work fine. Only in the last year or so has it stopped working correctly. So, maybe if you/they revert to an earlier version....
-
@heinzv
I have not been able to run these modules, it seems they are problematic...but found as it seems to me the best
I know that with these modules can be more or less tolerable work in NRF DK. But I needed the modules that each user would be able to programming in Arduino IDE as simple as atmega328
-
I have been working with serial driven screens for a while. They work!
I just noticed there's also an e-paper version. Perhaps it's interesting?
https://www.waveshare.com/wiki/4.3inch_e-Paper_UART_Module
-
The project is closed. See the continuation of this development in the new project - https://www.openhardware.io/view/629/EFEKTA-TempandHum-sensorver-nRF52832-E-Ink-display
