I think the movement counter field of data format 5 could be repurposed here, for example by incrementing movement counter on both acceleration event and hall event and using the last bit as activity ongoing / hall open bit.
Digital IO is pretty much required, interpreting analog value for each different magnet and positioning would be complex. In theory the same code which is used with buttons could be used here, as it’s a matter of having a pull-up and detecting when the hall sensor closes. Some care must be taken to not bleed the battery via pull-up if the hall sensor is closed most of the time.
So a tag is considered either stationary, in which case the movementCounter is movements going past it or it is moveable(even slightly) in which case movementCounter is the movements it makes( however small)
In my case it wouldn’t be a good solution since i get some false increments from ACC sensor (unwanted vibrations) and common counter would be rather problematic for presence monitoring tasks, where is needed to separate the ACC readings.
My suggestion is to implement in firmware a selector for MC counter, where one can choice if the counter should be taken from ACC, Hall or both sensors combined.
Good feedback, thanks .
Adding support for a hall sensor itself should be pretty straightforward, but the next question is how to handle the firmware variants in builds. We have already 4 boards with 4 firmware variants each, so the GitHub releases tend to get cluttered.
Selecting modes with buttons would be cumbersome and configuring the mode over GATT would be a lot of work. Of course it would be possible to a write one-off version similar to acceleration measurement firmware.
A great place to establish Configuration Information, changeable at deployment i.e. not at compile time, is in the User Configuration Information Register which can be modified using DFU. No special tools or source programming expertise required.
The UICR updated over DFU wouldn’t really bring advantages over hardcoded configuration, but configuring over GATT definitely would.
@Alex how is your schedule? We could do this as a consulting project at Ruuvi if you’re in a hurry, or we could wait until the Ruuvi Connector system is ready and we can add the support then.
I have some very small reed switches which fit into the ruuvi case. Could using these instead of the Hall effect sensor mitigate the “Some care must be taken to not bleed the battery via pull-up if the hall sensor is closed most of the time.” problem?
The reed switch has the same issue, if there is a pullup/-down in RuuviTag and the pin is driven to other state through reed switch there’s going to be a notable leakage current.
Might that leakage be reduced to an acceptable level by having the "sourcing " side of the switch connected to an output pin (example P0.30 ) (rather than to ground) which is only driven 1% of the time.
The best solution is to use a hall sensor with push-pull output so that there’s no pull-up/down needed. The second best solution is to disable the pull resistor when the switch is activated and poll the pin every now and then.
In general any leakage is not acceptable, the baseline consumption of RuuviTags is a few microamperes and even 1% of the (3 V / 13k ohm) is 2.3 microamperes, which would be the biggest single component in idle consumption.
Hi Otso,
Thank you for your interest. I’m not in hurry, it’s just a hobbyist, not professional purpouse. I was looking how I can do this by myself but unsuccessfull. That’s why I’m more than happy to hear that the Ruuvi team is interested to help us. Really appreciate this.
BTW - The suggested method with power switch has some disadvantages and I woudn’t like to use it.
I wish I could help you somehow with this topic but I’m lacking knowledge on this field and have no other idea than being a beta tester or just send you a crate of beer
@otso if I can gain confidence in the right configuration (guide) to add a hall inside a ruuvitag enclosure I’ll plan to integrate into a commercial application
Buttons - Espruino should be ok for getting started, on open drain hall sensors it’s equivalent to 0 V connection.
We’re also aiming to add a Hall sensor to RuuviTag at the same time with the Ruuvi Connector, but this isn’t 100 % certain before the PCB is tested and schedule of new revision is open.
@otso keeping inside the existing enclosure is important ( we need the one tag be mulifunction) just add magnet for door/window application. - happy to try options but sooner than later!!
Could you explain please how do you plan to integrate the Hall sensor? Would it be on board the Tag, or it require the Connector board with external power supply? Should this be working “out of box” or some DIY is needed?
If the Hall sensors fits in board, it will be out of box. In meanwhile, some DIYing is needed, on current tags the Hall needs to be soldered on the pins on the bottom of board and firmware needs to be adjusted for Hall.
.
