The ADC sometimes responds with negative voltages read on the ADC input due to noise. This can lead to very high illuminance readings at night (4095 << 4 to be exact due to two's complement :) ).
This commit caps ADC readings at 0.
The nRF52833 has only 512 kB of flash. The .dts file was incorrect, as a
product of having it forked from the nRF52840 .dts files, which has 1 MB
of flash.
The new, correct partitions are closely related to the
[nrf52833dk](ec52722861/boards/arm/nrf52833dk_nrf52833/nrf52833dk_nrf52833.dts (L215)).
This change has been planned for a while, and BTHome v2 + Home Assistant
is currently the most convenient, hassle-free and maintained way to
interface with the BLE sample currently.
After we tracked down a rare, annoying bug for the zigbee sample in #150,
this PR does something similar for the ble sample. If there's an error
either initializing the board of reading the sensors, __ASSERT will
reboot the system, instead of letting it hang forever.
Removed the circular supports the extended all the way to the build plate and left small bumps at the top of the case. Replaced with slightly wider and flatter supports that fit within the case constraints. Also slightly enlarged the PCB groove. I found it way too tight and ended up ripping off a batter holder and pads during removal.
Beside having a `CONFIG_BOARD_REVISION` Kconfig string that represents
our semantic versioning for board revisions, the ZigBee sample requires
an integer representation of it. Instead of conditioning the integer
version on the string version only for that sample and having to touch
the ZigBee sample whenever we add a revision, I decided to have a
board-wide config, so that both string and int versions live close to
each other.
Fixes#138.
As endearing as it is to get unactionable hate messages, I would rather we focus our efforts on having fun and fostering a small, great, positive, welcoming community, as it's has been so far.
This code of conduct is from https://www.contributor-covenant.org/, based on Mozilla's. I hope we never have to enforce it, and it sucks that we even have to think about these things. But at least this makes it a little more explicit about what's unacceptable behavior.
In the effort to increse reliability of the Zigbee sample, #126 and #130
introduced handling for possibly rare, hard-to-debug events that may be
occurring. While these changes seem to help in practive, we don't know
exactly how often, if ever, they are triggered.
This PR introduces debug_counters in hope to add some visilibty in these
hard-to-debug, rare conditions.
Calling `prst_debug_counters_increment("some_counter")` will increment a
value stored in flash. These values are then dumped via logging when the
device boots. Moving forward we can also consider exposing these values
via a ZigBee cluster.
