Felix wrote: > That's a new business idea, a camera module with built-in QR reader > firmware, with UART output; could be interesting for some integrators. Oh, > wait!! That already exists!![1]
Looks expensive, though. > You can always opt to hash some data (e.g. the url) and get something > shorter. Yes, and it doesn't even have to be globally unique. If you have, say, 1000 accounts, 20 bits would be enough for only one collision (on average). With 48 bits, you'd then be collision-free with a probability of 99.998% Plus 8 bits for CRC, three for lead-in, and five for the message type (0 = service hash, 1 = account hash, the rest reserved), we're at only 64 bits. Not too bad. Actually, best to double the last bit of each non-lead-in byte and grow the lead-in to 9 bits. That way, the code can be sent continuously and the device can automatically synchronize. That would then be 64 + 7 + 6 = 77 bits. > Also in my jsfiddle I've put 100ms between bits, but you can try > to lower it to 33ms (most of monitors works on 60hz, so it should work). You probably also get some jitter from the browser and background system activity. And then everything gets modulated by the refresh rate. So you'd probably want at least 3 refresh cycles per bit. Next: a suitable sensor. The one in [1] doesn't seems to be very effective. Alas, there's no part number one could use to get the characteristics. - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
