Sensebender Micro
-
ok, it seems the aggregated upload is solved with the change from Thomas.
Now I modify the "14" in "11" as suggested by martin. I have 105% now, but that could be right because I measure 3.1V from my 2 fresh AA'sThe only 'new issue' I discovered is that one sensor actually stops being received updates from due low power. The measured voltage on the batteries is still 2.1V and the battery indicator was at 23%.
Could it be that I have bad fake radios that don't operate lower then 2.1V? (since there is no other external components added to my setup, I suspect only the radios). -
I'm having trouble with the transmission times.
// How many milli seconds between each measurement 900000 is 15 minutes #define MEASURE_INTERVAL 900000 // How many milli seconds should we wait for OTA? 3000 is 3 seconds #define OTA_WAIT_PERIOD 3000 // FORCE_TRANSMIT_INTERVAL, this number of times of wakeup, the sensor is forced to report all values to the controller #define FORCE_TRANSMIT_INTERVAL 30 // When MEASURE_INTERVAL is 60000 and FORCE_TRANSMIT_INTERVAL is 30, we force a transmission every 30 minutes. // Between the forced transmissions a tranmission will only occur if the measured value differs from the previous measurementI would expect a wake up and measure every 15 minutes. transmit if greater than .5 and go back to sleep
also i would expect a forced transmission every 30 minutes.
but that doesn't seem to be happening.
here are my last few transmit times
4:07pm
5:59pm
6:15pm
6:47pm
7:50pm
8:34pm
9:10pmI don't see a static 30 minute transmit.
(from 4pm to 6pm?) i'm sure the temp and/or hum changed in 2 hoursany suggestions on what may be wrong?
default sketch (1.3 from git) but changed the measure intervals
sensor lib 1.5
thanks -
I'm having trouble with the transmission times.
// How many milli seconds between each measurement 900000 is 15 minutes #define MEASURE_INTERVAL 900000 // How many milli seconds should we wait for OTA? 3000 is 3 seconds #define OTA_WAIT_PERIOD 3000 // FORCE_TRANSMIT_INTERVAL, this number of times of wakeup, the sensor is forced to report all values to the controller #define FORCE_TRANSMIT_INTERVAL 30 // When MEASURE_INTERVAL is 60000 and FORCE_TRANSMIT_INTERVAL is 30, we force a transmission every 30 minutes. // Between the forced transmissions a tranmission will only occur if the measured value differs from the previous measurementI would expect a wake up and measure every 15 minutes. transmit if greater than .5 and go back to sleep
also i would expect a forced transmission every 30 minutes.
but that doesn't seem to be happening.
here are my last few transmit times
4:07pm
5:59pm
6:15pm
6:47pm
7:50pm
8:34pm
9:10pmI don't see a static 30 minute transmit.
(from 4pm to 6pm?) i'm sure the temp and/or hum changed in 2 hoursany suggestions on what may be wrong?
default sketch (1.3 from git) but changed the measure intervals
sensor lib 1.5
thanks -
@mvader If your interval between readings is 15 minutes and the force transmit interval is 30, your actual interval is 15minutes * 30 = 7.5hours. Also, see this thread for sleep time accuracy. 15 minutes of sleep can last 16-17 minutes...
@Dwalt said:
@mvader If your interval between readings is 15 minutes and the force transmit interval is 30, your actual interval is 15minutes * 30 = 7.5hours. Also, see this thread for sleep time accuracy. 15 minutes of sleep can last 16-17 minutes...
really.. hmm
so if you look at the default comment
when MEASURE_INTERVAL is 60000 and FORCE_TRANSMIT_INTERVAL is 30, we force a transmission every 30 minutes.
That says measure for temp/hum every 1 minute - send if greater than .5 (defined later in the sketch)
regardless of what goes on send stats every 30 minutescan you help me understand why those 2 number would be multiplied together? one shouldn't have anything to do with the other.
i read that as they are definitions for 2 different process.
but i may be totally misunderstanding.I do buy the sleep accuracy part of it though :)
-
@Dwalt said:
@mvader If your interval between readings is 15 minutes and the force transmit interval is 30, your actual interval is 15minutes * 30 = 7.5hours. Also, see this thread for sleep time accuracy. 15 minutes of sleep can last 16-17 minutes...
really.. hmm
so if you look at the default comment
when MEASURE_INTERVAL is 60000 and FORCE_TRANSMIT_INTERVAL is 30, we force a transmission every 30 minutes.
That says measure for temp/hum every 1 minute - send if greater than .5 (defined later in the sketch)
regardless of what goes on send stats every 30 minutescan you help me understand why those 2 number would be multiplied together? one shouldn't have anything to do with the other.
i read that as they are definitions for 2 different process.
but i may be totally misunderstanding.I do buy the sleep accuracy part of it though :)
@mvader No, it is not 30 minutes, the FORCE_TRANSMIT_INTERVAL counts the number of 'wakeup and take a reading' events, which in the original sketch is every 60 seconds. After 30 wakeup-and-read without a transmit, force a transmit. If you change your FORCE_TRANSMIT_INTERVAL to 2, it will transmit every 30 minutes if the readings do not change more than 0.5.
The MEASURE_INTERVAL is based upon time (millis) and the FORCE_TRANSMIT_INTERVAL is based upon counting events (wakeup cycles).
-
@mvader No, it is not 30 minutes, the FORCE_TRANSMIT_INTERVAL counts the number of 'wakeup and take a reading' events, which in the original sketch is every 60 seconds. After 30 wakeup-and-read without a transmit, force a transmit. If you change your FORCE_TRANSMIT_INTERVAL to 2, it will transmit every 30 minutes if the readings do not change more than 0.5.
The MEASURE_INTERVAL is based upon time (millis) and the FORCE_TRANSMIT_INTERVAL is based upon counting events (wakeup cycles).
@Dwalt said:
@mvader No, it is not 30 minutes, the FORCE_TRANSMIT_INTERVAL counts the number of 'wakeup and take a reading' events, which in the original sketch is every 60 seconds. After 30 wakeup-and-read without a transmit, force a transmit. If you change your FORCE_TRANSMIT_INTERVAL to 2, it will transmit every 30 minutes if the readings do not change more than 0.5.
thanks for the clarification! :+1:
-
D3 is available on the side-pins. D2 is routed to the radio but can be used with some hacking.
@hek said:
D3 is available on the side-pins. D2 is routed to the radio but can be used with some hacking.
I need 2 interrupts and would prefer using the external interrupts even though it might work with pin change interrupts. When looking through the forum I saw this answer from @hek but have not found any further reference to how this should be done in order not to disturb any radio functions. Anyone knows?
-
I don't know if the radio actually drives the interrupt "output" pin on it's pinheader as default, or if you have to set it up when initializing the radio (@hek might have some input on this part :))
If it drives the interrupt pin by default, then you need to either cut a trace on the sensebender, or cut / remove the pin in the pinheader on the radio module.
-
@tbowmo said:
I don't know if the radio actually drives the interrupt "output" pin on it's pinheader as default,
I think it does actually.
-
No, it isn't currently used by the MySensors library. It could be used to wake up the board when detecting radio transmissions...
But keeping MCU sleeping and the radio listening still uses up batteries far too quickly so I guess it's still not an option. -
No, it isn't currently used by the MySensors library. It could be used to wake up the board when detecting radio transmissions...
But keeping MCU sleeping and the radio listening still uses up batteries far too quickly so I guess it's still not an option.@hek @tbowmo Thanks! Cut the radio IRQ pin and soldered a connection to D2. Tested to attach both interrupts and it works using a modified SenseBenderMicro sketch. "The Thing" will when ready be placed in my mailbox (which has mail-in and mail-out doors) and as a bonus report the outside temp, humidity and battery status. Does not solve any of this worlds biggest problems but it is fun :-)
-
Hello,
one simple quick question, does this board can be used to create door sensors ? I do not need the temp/hum sensors, but I'm interested with the small footprint and the battery optimized board to make smallest door sensors (and some buttons).
regards,
-
@tbowmo
Well can't I use this board without using the temp/hum sensor ?This board is quite small and allows to stack the radio module with minimum place. Also it works at 1Mhz, I guess it's a bit better than an Arduino Pro @ 3.3V ?
-
Well I do, but I think that using a Arduino Pro 3.3V will be less effecient, but maybe I'm wrong ?
I'm currently using temp/hum/motion sensors with Arduino Pro 5V, but they are not battery powered. Now I need to make very small sensor with battery, and I thought that maybe this sensebender board is my solution ?
-
Well I do, but I think that using a Arduino Pro 3.3V will be less effecient, but maybe I'm wrong ?
I'm currently using temp/hum/motion sensors with Arduino Pro 5V, but they are not battery powered. Now I need to make very small sensor with battery, and I thought that maybe this sensebender board is my solution ?
@petoulachi to make the pro mini as efficient as the SenseBender, you need to cut some traces on the board. There are forum topics for battery optimizing a pro mini. The SenseBender has these optimizations built in.