Secure 5-button keyfob with enclosure (was: 8-button keyfob)
-
Oh, A7, yeah, I remember something like that. Does the LED flash with the coin cell? The one I took from an RGB strip doesn't light up on blue at 3V because of the required forward voltage. I fear green might have the same fate when the battery voltage drops ...
Looks like V1.1 is required.Looking forward to hearing from the actual radio tests. Depending on that V1.1 might get some more caps or a HT7333 so it is possible to use a LIR2032.
-
Hi,
till now just tested from supply of USBasp programmer -3.3V, today I hope, I will have a time to play little bit with it :)
I already order couple of RFM95 for testing LoRa I hope RFM95 have the same footprint like RFM69HCW ;)
As a option for v1.1 is good to have some LDO in SOT23-5 package (SPX3819M5-L-3-3) with possibility to bypass - than You can use CR2032 and LIR2032 as well :thumbsup:
Next idea for v1.1 is to have RX,TX,DTR,GND and VCC pins somewhere on the edge of pcb for debugging and uploading sketch via bootloader and serial port
MiKa -
Hi,
till now just tested from supply of USBasp programmer -3.3V, today I hope, I will have a time to play little bit with it :)
I already order couple of RFM95 for testing LoRa I hope RFM95 have the same footprint like RFM69HCW ;)
As a option for v1.1 is good to have some LDO in SOT23-5 package (SPX3819M5-L-3-3) with possibility to bypass - than You can use CR2032 and LIR2032 as well :thumbsup:
Next idea for v1.1 is to have RX,TX,DTR,GND and VCC pins somewhere on the edge of pcb for debugging and uploading sketch via bootloader and serial port
MiKa@MiKa The SPX3819M5-L-3-3 has massive (well, comparably) quiescent current. Ten times the HT7333. That alone will suck a LIR2032 empty in about a month. I think I can fit the SOT-89 of the HT7333 package next to the LED. Alternatively, one could conider boosting with a MCP16252.
Serial flashing capabilities requires one more capacitor and resistor ... And the routing is also already pretty difficult. What is the avantage? As far as I can see, it is just another flashing device ...
I do intend, though, to add 2 pins rx/tx to the icsp header. How did you do that one, by the way? Does your version already have the bigger holes? In the most recent version, it is intended to take a machined female header. with that, it fits into the enclosure. I am still thinking about changing it over to SMD pads, which I would interface with pogo pins. -
Thanks, I'll change that.
BTW, I found another reason against adding a serial programming interface: To safe power, brownout detection should be disabled. If the battery runs low, erratic behavior may occur, which includes jumping to arbitrary addresses in flash. If a bootloader is still there, there is code to write to the flash, which might damage the programming. On the other hand, I highly doubt that a failing mcu will manage to go through the full process of sending an authenticated button pres, especially since high current RF tasks are involved.
So it is probably generally advisable to not have the Arduino bootloader on there. -
V 1.1 of pcb should have really bigger side pads for battery holder, I already destroyed one pcb pads when I put in coin battery, probably reason is overheating this small pads during soldering the battery holder :angry:
@MiKa I have made a big new push to the repository. Here are the changes from the commit:
- Doubled size of battery pads.
- Added HT7333 to allow for LIR2032 lithium coin cell (Bridge pads for CR2032).
- Changed A7 to A2 to make LED work.
- Added SMD contacts for TX and GND for debug output (interface with pogo pins).
(Getting TX out was hard enough, RX just wasn't worth it, I thing we really do not need to send anything to a keyfob :))
I would have liked to put a step-up converter on there, but I have not found a possibility for one that does not need an inductor that is too bit to fit on there.
-
@MiKa I have made a big new push to the repository. Here are the changes from the commit:
- Doubled size of battery pads.
- Added HT7333 to allow for LIR2032 lithium coin cell (Bridge pads for CR2032).
- Changed A7 to A2 to make LED work.
- Added SMD contacts for TX and GND for debug output (interface with pogo pins).
(Getting TX out was hard enough, RX just wasn't worth it, I thing we really do not need to send anything to a keyfob :))
I would have liked to put a step-up converter on there, but I have not found a possibility for one that does not need an inductor that is too bit to fit on there.
-
@elcaron you will need at least TX from your board in order to personalize the atsha204a. Lest you personalize it before you solder it on the board. The personalizer can operate without TX.
-
@Anticimex Why? I thought there is SKIP_UART_CONFIRMATION. I have to set USER_KEY, but isn't that generated once for the whole network? I figure it doesn't have to be the keyfob node that does that ...
-
Wow, good progress! :)
Finnaly I start up sketch, but with USBasp is not possible to upload firmware to atmega when the radio is connected :angry: I put temporary radio via pin socket and I need to remove radio during programming :open_mouth: , maybe RFM69HCW need to have connected RESET pin or some pull-up is missing.
From sleep mode Im able to wake up node just via SW5 wchich is conneted to pin D3 (INT1), Its possible to wake up from some sleep mode also via another pins (except D2 which is INT0)? -
@elcaron yes, but how would you obtain the atsha204a serial if you want to be able to whitelist your keyfob?
-
@Anticimex Ok, I see ...
Well, good that we have TX now :) If my current version works, I'll personalize the ATSHA outside of the board. It's really easy to solder with a hot air gun. -
Wow, good progress! :)
Finnaly I start up sketch, but with USBasp is not possible to upload firmware to atmega when the radio is connected :angry: I put temporary radio via pin socket and I need to remove radio during programming :open_mouth: , maybe RFM69HCW need to have connected RESET pin or some pull-up is missing.
From sleep mode Im able to wake up node just via SW5 wchich is conneted to pin D3 (INT1), Its possible to wake up from some sleep mode also via another pins (except D2 which is INT0)?@MiKa What? Unsoldering the radio is terrible ... I really don't see a reason for that, it should be SPI and the radio should do nothing ... maybe we need to pull CS low to make sure the radio is not selected? Someone here should know that ...
Regarding wake up: Yes, THAT I know about :) All the button pins are on PCINT1_vect: https://playground.arduino.cc/Main/PinChangeInterrupt
Consider setting a mask to limit it to the 5 button pins. -
@elcaron sure, that works. Just remember to take a note of the serial. Or use the TX pad you just made and run the personalizer again :)
-
@Anticimex If the personalizer can read it indefinitely, can't I just send it out over the radio?
-
Wow, good progress! :)
Finnaly I start up sketch, but with USBasp is not possible to upload firmware to atmega when the radio is connected :angry: I put temporary radio via pin socket and I need to remove radio during programming :open_mouth: , maybe RFM69HCW need to have connected RESET pin or some pull-up is missing.
From sleep mode Im able to wake up node just via SW5 wchich is conneted to pin D3 (INT1), Its possible to wake up from some sleep mode also via another pins (except D2 which is INT0)? -
- How can it be sniffed if the transmission is AES encrypted by the RFM69?
- How is it pointless if it could be read by a bad guy from a lost keyfob? I thought it was the point of the ATSHA that it can be safely lost.
I thought security was given because a badguy cannot change the ATSHA id and also cannot extract the PSK. SO the id doesn't seem private.
-
@elcaron No problem, I playing with it when I have time :) I will play now with interrupt changing :)
btw. LIR was an good idea, I have for test now CR2023 which have cca 2,75V and working distance from the gateway is really low. :)@MiKa The LIR2032 have much smaller capacity, tough. The 4uA quiescent current of the HT7333 alone will suck them dry in about a year. Probably even destroy them, due the lack of undervoltage protection :(
The solution is far from optimal.
What tantalum cap capacity did you use? How low is the range?
