If you're going to require 2 digits, then that can be done with 2 decimal digits as well. So there's no need for hex, and no need for ascii tables.
However, if you need more than just the 26 letters, e.g. if you also need numbers and/or punctuation, then ascii might be useful, and hex might be useful to encode ascii into 2 digits.
Why do I need to send it to you 2 digits at a time? It's valid hex that converts to ascii, only 1 symbol at a time, which is how he communicated.
He could've done it with just a card for 0 and another for 1 if he really wanted.
The points of my previous comment:
* Ascii is only needed if we need to encode things other than just letters (or if case matters).
* Hex is only better than decimal if hex allows the number of digits to be reduced. If we need to only encode 26 elements, then hex doesn't reduce the number of digits compared to decimal, so hex has no advantage over decimal in the 26-element case.
Using just 0 or 1 will increase the number of digits needed, so has a clear disadvantage compared to hex or decimal.
He had more than 26 things to encode, I believe he started with numbers, letters and a question mark.
> Using just 0 or 1 will increase the number of digits needed, so has a clear disadvantage compared to hex or decimal
Using 0 or 1 decreases that to only 3 cards (including question mark), and increasing the safety margin to 120° on the setup he had. It'd take longer but be more robust.
Ok, then hoten's comment had an error which propagated to my comments:
>26 division of a circle was too much for reliable determination of which sign the camera was pointing at
If we're talking efficiency, I wonder why he didn't consider Morse code. Well I guess that's easy, even though it's faster it takes a skilled operator to read it in realtime, and he had little time to write any individual bit of information down (cumbersomely writing in sand is slow)