Application

[MrKevinWeiss]

This is where we can narrow down what the actual application will look like.

So far I have written my best guess in the readme. Let's hear everyone ideas early and we can sort out what is feasible to accomplish and what can be pushed to the next board/iteration.

[MrKevinWeiss]

The one thing we should note is that this will be an outdoor device...

[MrKevinWeiss]

I added something with the tamper protection mentioned in #1

[MrKevinWeiss]

How would we feel if we used some 3d printers for custom enclosures that looked like the crosswalk switches (they would have to be customized for each country I guess). Hide in plain sight :)

[mcr]

How would we feel if we used some 3d printers for custom enclosures that looked like the crosswalk switches (they would have to be customized for each country I guess). Hide in plain sight :)

I guess you mean the boxes that control the crosswalks, not the lights. So no Ampelmännchen?

[MrKevinWeiss]

I feel like putting up fake Ampelmännchen would cause some legal issues :laughing:

[chrysn]

(Assuming "Application" is the right thing to put this under, please redirect if not)

AIU the current direction of the default application and GC "game" (assuming #4 comes out with "no display but NFC") is that "you go there, find the cache, press a button, it reports the button press asynchronously via TTN, and you NFC". Then there is a score board of how often the cache has been found (from the button press counts), and who found it (from delivering the NFC-claimed tokens).

Thing is, any assurance you get of having been there at that time (that'd be reported through the LoRA network and logging of button presses) can just as well be obtained through the NFC. To me that begs the question: What does the LoRA backbone add to the game, or (conversely) how do we alter the game to make better use of that backbone?

(Granted, it already adds battery telemetry and more precise time, but the former can be smuggled out through the tokens, and the latter can be lower-bounded by a signed time from the game server passed on through the phone, and upper-bounded by the token's registration).

[chrysn]

... and if for some reason we go for "yeah it really doesn't need to have long-range radio": Do we need a battery at all? Tapping might take 30 seconds then (with a "please stay around while we give you a proper response"), but if we don't need to power an EPaper as in this reference application note, we might do better.

(Edit: For reference, from 23C3 I still have an RFID detector armband. Soldered from 3 loops of copper wire and a single LED. Using my phone while touching the band makes the LED blink frantically.)

[mcr]

To me that begs the question: What does the LoRA backbone add to the game, or (conversely) how do we alter the game to make better use of that backbone?

If you were arguing as a product manager, about MVP, then it would be a really good question. As you said WAY better battery-wise to issue a signed COSE and have the provide game app relay that to HQ.

I like the second half of the question. I don't have a good answer.

Part of my answer is that this isn't just for geo-caching, but that geocaching is a good demo of some set of capability.

[mcr]

... and if for some reason we go for "yeah it really doesn't need to have long-range radio": Do we need a battery at all? Tapping might take 30 seconds then (with a "please stay around while we give you a proper response"),

So, you are saying, some kind of energy harvesting? That demonstrates a different thing, but that might make it more widely interesting. (We have no publically accessible LoRAwan here, and likely will never have it without a $$$ SIM from our duopoly)

[chrysn]

So, you are saying, some kind of energy harvesting?

That is how NFC (with passive tags, which are not really passive as in passive-electronics but more like secondary radar powered by the initial radar probe) works -- and whether the electronics that build the response are those built into the transceiver or whether that's powering external circuitry is to some extent an implementation detail.

Whether that makes sense to use depends on the application we're defining; if the application turns out to not meaningfully use power in another way, it might suffice.

[MrKevinWeiss]

What does the LoRA backbone add to the game, or (conversely) how do we alter the game to make better use of that backbone?

I actually was thinking that LoRa would not be involved the at time of button push as this can be done with syncing the link with NFC. I also suppose the usage can be tracked by those look for the hint on the site (or app or whatever). The battery life and general state of well being would be the value we can get from this. I also wanted to feature LoRa as it is some part of RIOT.

The harvesting small amounts of power from an NFC chip is cool, but more an electrical engineering and dare I say bare metal type application. The very least I would say we push it into possible future work.

@leandrolanzieri pointed out the idea of making this a phone free geocache, with that in mind, and given the simplifications that the original idea allow, maybe we should repurpose the application. Maybe make it more like a capture the flag type thing, where someone can press one of 3 buttons for each "team", this functionality would also allow more complex tasks to be assigned such as all three devices in a given area must have a certain color in order for the next hint or something. This would require LoRaWAN telemetry as well as remove the requirement for a phone.

We have no publically accessible LoRAwan here, and likely will never have it without a $$$ SIM from our duopoly

I remember the craziness of the Canadian ISPs... they have a strong enough lobby to keep out the American providers last I heard. However, anyone can deploy a LoRa gateway for pretty cheap and the ttn map shows quite a few nodes available throughout Canada.

[chrysn]

Phone free geocache / geogame is nice. Might be a bit like ingress (just smaller scale and with physical devices), with the LED showing whether Red or Blue controls it on a single button press, and then you morse in your faction ID through a button (OK, or do it lazily with multiple buttons).

Some USB charging tracking would still be an option, like "I assigned it to my team, and now I'm charging it, so the other team is locked out for some time" or what-so-not. (That'd also serve as commissioning port to put in the eSIM, or for offline firmware updates and debugging).

[MrKevinWeiss]

Some USB charging tracking would still be an option

Oh that is a good idea!

[MrKevinWeiss]

OK, after some more conversations I would propose the following:

• No phone requirement or interaction (this really pushes a lot of fun logic away from the firmware)
• Keypad to enter a personal or team id (ids can be mapped or reserved in a lora application)
• Hints displayed on the device (eink or lcd)
• If the hint to the next node is lost, the lora application pushes the next hint during the downlink
• Charging locks your team for x amount of time
• If a team comes during a lock, they enter a queue and will claim the node once the lock is up (limited size queue, cannot repeat)
• Charging while another team is locked will be ignored

This now makes the embedded side pretty interesting, moving away from the cost effect "push all logic to the phone" mentality. This would also mean that the LoRAWAN connection is needed.

The firmware updates still will just be provided by a debugger or basic usb/uart bootloader I guess.

We will make provisions for an NFC tag that could be used either for uploading when a LoRa connection is not present or simple bootloading, but that will be a future endeavor.

[mcr]

OK, after some more conversations I would propose the following:

• No phone requirement or interaction (this really pushes a lot of fun logic away from the firmware)

okay, but if a BTLE or NFC is possible, then it would be nice to have this on the board for future efforts.

The firmware updates still will just be provided by a debugger or basic usb/uart bootloader I guess.

But, we'll use riotboot... _dfu?

[MrKevinWeiss]

okay, but if a BTLE or NFC is possible, then it would be nice to have this on the board for future efforts.

Yup, we can add in pinouts for the modules (NFC tags right? not a reader).

But, we'll use riotboot... _dfu?

Yup, dfu or serial. I don't think the samr34 has a ROM bootloader so it would have to be that!

[leandrolanzieri]

• Charging while another team is locked will be ignored

I'd prioritize charging over common locking, as a prize.

[chrysn]

Keypad and display in the default configuration makes this also almost a pager (someone might publish a buzzer hack on it), a web browser (for the patient -- or to ensure someone's version of the web is really accessible) and a calculator. Nicely suitable for add-on applications without bloat relative to the original geocache-and-capture-game idea. I like, I upvote.