I am at the initial spec stage of an IoT project and I’m very happy and excited to see that WisBlock might offer all of the building blocks I need. Very impressive! I would love some help in defining the components and the strategy, please.
In brief:
Battery powered devices are providing access control via RFID tags and being deployed in locations with no other power source (solar, AC, etc.). Devices can be accessed once every two years to change batteries. There are no practical size or weight restrictions so batteries can be high capacity, however power optimisation is required to keep costs down.
Strategy and components:
User presents key to RFID reader (RAK13600),
system checks if UID exists in F-RAM (RAK15003), if yes,
system logs timestamp and UID to F-RAM and opens electronic door latch.
once per 24 hours, system wakes up on RTC IRQ (RAK12002) and transmits previous 24 hour’s access logs to server via LoRaWAN, along with battery State of Charge as reported/monitored by Coulomb counter (RAK16000) and
receives updated user UID list, plus any OTA firmware, etc.
I don’t have much experience with microcontrollers but, given the tight energy requirements, my initial research (including this excellent post by @beegee) would suggest that the nRF52840 (RAK4631) is a good candidate. And to complete the setup, given the need for two IO modules (NFC & Coulomb sensor), I guess I am looking at one of the two Dual IO Base Boards.
Phew!
So, here come the questions:
I understand that nRF52840 doesn’t have ‘the easiest’ power management, but is it ‘the best’ option (from those available on WisBlock) in terms of potential power optimisations?
I have seen similar systems which require the user to push a switch in order to activate the RFID antenna. This is clunky from a UX perspective. I’m guessing this is a fairly well-trodden path so I’m hoping for some battle-tested techniques for allowing the user to simply present their card, but without requiring the PN532 to be always on, i.e. implementing some kind of duty cycle… what might this look like for the RAK13600 (with nRF52)?
I have read that, while IRQ is possible with the PN532, it’s likely that the UID will get lost before waking up the system. Assuming it is possible to implement a duty-cycle-read with the NFC, what would be the technique to store the detected UID prior to waking up the rest of the system and then cross-checking it with the values in F-RAM? Does the PN532 have a suitable internal register for this? Should I be looking to store the read value in the F-RAM as well? Advice needed here please.
And for bonus points:
4. The excellent linked post mentions IRQs from the SX1262 LoRa transceiver. If the LoRaWAN server were to initiate 24 hour communication then I guess I wouldn’t need the RTC. It would also allow the list of authorised UIDs to be updated in real-time, rather than every 24 hours. But what are the energy implications of this, vs using the RTC?
I should also probably state: while I’m extremely happy to see Arduino examples, I’m not afraid to explore other options (RUI3, etc.) if they were to provide significant energy savings. That said, time to market will be important and so the Arduino route will definitely assist with rapid prototyping.
Beside of power management, there is a problem with GPIO conflicts.
The RAK13600 is using already 3 of 6 IO pins, which makes it difficult to add additional sensors.
The combination of RAK13600, RAK16000 and the RAK15003 will work, but adding the RAK12002 is a problem, as there are IO conflicts, whatever Sensor Slot I tried. WisBlock Pin Mapper
For (1) RUI3 provides a lower sleep current than the Arduino BSP. You might be able to save ~10uA.
(2) Agree, pushing a button is not a good solution.
(3) Use a LED that lights up once the system is awake and has read the tag
(4) Using the LoRaWAN server to wake up the system once a day would require that the nfc reader node is in Class C. Which means the LoRa transceiver has to be in RX state all the time, this would add ~6mA of current consumption.
I am not sure if the timers of RUI3 or Arduino supports a 24h interval (never tried that long interval), but a workaround could be to use the maximum possible interval and count the wake-ups and after 24 times, send the data.
The timers are working with milliseconds, the value is a 32bit unsigned. So you should get
4,294,967,295 ms == 4,294,967 seconds == 71,582 minutes == 1193 hours. But I never tried such a long interval
Thanks for the response @beegee. Thanks too for going to the effort of checking the pin mapper. I had tried to load it in both LibreOffice and Google Sheets but as your website suggests, it doesn’t work. Seeing as it’s an indispensable tool for selecting components it would be great to see it built into the website, or a standalone tool.
Two questions about the RAK13600 NFC unit. Do you know how long the module takes to read a card after power on? This will be important to know in order to create the duty cycle. I’m hoping I could switch the module off for around 3 seconds then power up for ~200ms. This would give quite a long battery life. Also could you give me the dimensions of the antenna please? I can find these anywhere.
Your suggestion of counting the wake-ups is an interesting one. My units don’t need to phone home at an exact time each day, just roughly every 24 hours. So if I’m implementing a duty-cycle on the NFC then I guess I could count those and do without the RTC altogether, although these will need very short durations and may accumulate quite a lot of variance over time.
It is at the moment limited to modules that are compatible with the Meshtastic firmware.
The goal is to show conflicts while selecting modules for a WisBlock device.
For your other questions, I don’t have the module at hand, can’t answer them. Maybe @carlrowan
has the module?
I finally got access to a computer with Excel and I’ve just realised I made a mistake in my original post. The coulomb counter is RAK16002, not RAK16000. I cannot find RAK16002 on the Pin Mapper.
As I mentioned above, I made a mistake in my initial parts list. RAK16000 should be replaced with Coulomb Counter RAK16002 which isn’t listed in the Pin Mapper, so I added it as follows:
however I am hoping this won’t be a problem: it seems that the AL/CC on IO6 of the Coulomb Counter is the pin is used for interrupts. For my application I will not need interrupts, I simply need to read the charge %age at 24 hour intervals and send it via LoRaWAN.
Without diving too deep into the NFC Module, I am assuming that I will need the “WAKE_UP_MCU” feature. I am not sure of the implications of having the two modules physically ‘wired’ to IO6 but only utilising one of them in software. Can you foresee any issues with this, or am I good to proceed?
