💬 Temperature and humidity sensor(ver.ATmega328)+E-Ink display
-
@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 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
-
@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.@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:
https://www.youtube.com/watch?v=KnYcGmJcVtU&feature=youtu.be
That 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...
-
@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.
-
@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.@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. -
@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 -
@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 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 :(
-
@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. -
-
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.
-
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.
-
@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@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
