Open chrysn opened 2 years ago
QR code on LED matrix sounds right to me. Or NFC.
I really like the QR code idea. I think the medium should be determined by what is supported in RIOT, cost of the part, and availability.
We should settle on something sooner than later.
I checked the QR sizes; even the minimal QR codes (Version 1) have 21x21 modules, which gives 152 bits, or 25 characters in a reduced alphanumeric scheme (if using URI shape, 9 characters or ~49 bit would be left for an affordable name -- might suffice, or we go for non-URI codes).
Still, that's 441 LEDs in a 21x21 matrix (less if we don't populate the always-black pixels, and a smaller matrix if we group the always-on ones). That's not only so much an issue in prices (cheapest I found on RS is 0.012€ making ~5€ in parts), but also in soldering cost (while much of that is tooling, it just takes time to pick 400 of anything around).
For comparison, point LED displays start at 2€ for 5x7 (with similar prices from Farnell, needing 3x5=15 pcs per QR display for ~30€ total); OLED displays start around around 7€ and start at 64x32px. (More square-ish 48x65 for 8€).
Even ePaper is "competitive" there. (With Farnell prices starting around 10€)
That stuff all ain't cheap...
[edit: fixed rounding of price]
I checked the QR sizes; even the minimal QR codes (Version 1) have 21x21 modules, which gives 152 bits, or 25 characters in a reduced alphanumeric scheme (if using URI shape, 9 characters or ~49 bit would be left for an affordable name -- might suffice, or we go for non-URI codes).
Oh, yeah. That's true. We might not have enough pixels for a QR code! I wasn't imagined we'd place 441 LEDs... I assumed some kind of display. Hmm. NFC sounding better to me.
I think the ideal thing would be eink... I haven't considered NFC, I don't know how intuitive it would be and how much work we would require to implement this (is it fully supported by RIOT, do we need a specific MCU or chip, how good is the power consumption, if any)?
I see we have a PN532
driver? I will try to look into it a bit.
Ahh that is a reader, we just need like a tag or something?
A programmable tag might do (something like ST25 series, judging from their description) -- especially, that needs no power at all (when not just being programmed) as it'll be powered up by the reader.
Anything better than a tag should manage to do the same and might still be nice (for it'd allow 2-way communication), and may also power the MCU during communication, but may be more complicated in terms of hardware (especially if used as an alternative power supply for the MCU).
I haven't look into it but the st25dv-i2c might be nice.
I guess the geocache finder would tap their phone, the st25 would send a wakeup signal, the MCU would wake-up, log the tap in the backup register, update the st25 to point to the new link, then enable the st25 to respond?
Hmmm I am liking this more and more, makes it very easy to weatherproof with no buttons...
Hmmm I am liking this more and more, makes it very easy to weatherproof with no buttons...
Or single big button behind rubber. Maybe we just kick the unit :-)
Application now has a display in as per https://github.com/MrKevinWeiss/riot-10-promo-board/issues/9#issuecomment-960593202; showing text and not QR turns the resolution requirements down.
The 7€ OLED display now compete with character-based LCDs that go down to 5€ with much more choice. But OLEDs are much more shiny, and might also have better availability when moving away from the more traditional parts sourcing (also given that some go below 4€ at 50pcs already).
I guess we can't fit the whole "hint" message at once. If that is the case we probably also cannot use eink. So the question is oled vs character. I will look into the power constraints.
Any ideas yet how to "display a time-sensitive web-link"? E-Paper? LCD? LED matrix for QR?