Actually, an app is more likely to be on a user's phone for this kind of use... Although you can bookmark a website to your homescreen, most users don't know how to do that and even less actually do that.
A mobile app is more likely to be on hand and easy to open in case of a run-in. (Although it's not likely someone would remember to do so if something were happening)
I decided against software USB because the receiver is already spending much of its time trying to meet the real-time limits from the radio decoding, and the USB would be its own big undertaking.
As I stressed in the preceding post (http://spin.atomicobject.com/2014/05/16/radio-system-from-sc...), I'm intentionally doing these things the hard way, so I can learn how more of these things work at a deeper level than "use built-in functionality, configure to run at this baud rate, done". Otherwise, yeah, I'd use a 32-bit ARM chip and a better SMD transceiver. :)
Hello, author here. As I said, mostly stressed in the first post, I'm doing things the hard way as a learning exercise, building a bunch of infrastructure myself. I would use a better radio transceiver and a chip with actual USB and UARTs, etc. if it wasn't a self-study project. :)
There's no way to know that the payload has been received - they're transmitters, not transceivers. The messages are idempotent anyway, so just retransmitting makes the whole system simpler.
Thanks for letting me know. I made sure the ATtiny84s could be re-flashed in circuit in case something like this came up. (I also have 315MHz modules, and will prefer those in the future. Swapping out the transmitters and receivers will only take a bit of resoldering.)
and discussion: https://news.ycombinator.com/item?id=9112930