It wasn't a book, it was on Johansen's laptop. And the ASCII was for communicating by pointing the camera on the mars rover, because it couldn't be positioned precisely enough for 26 different positions.
Why, wasn’t The Martian an example of hard sci-fi, a story that conforms strongly to the known laws of physics? Not necessarily probability, economics or politics, but hard sci-fi is written to be plausible.
The story is enjoyable, but like most such tales is amounts to building a string of deadly obstacles for the protagonist and then giving him just enough to survive each one. (FWIW the least realistic step was the ship turning around to get him, because spaceships typically don't carry any extra fuel. But in general there were too many resources lying around for him to use, especially the unattended lift vehicle. The plutonium core and the potatoes were a nice touch, though.)
It's been a while since I've read the book / seen the movie, but I believe the ship intercepted a resupply payload launched from earth as it was performing it's slingshot.
> FWIW the least realistic step was the ship turning around to get him, because spaceships typically don't carry any extra fuel.
The turning around and returning to Mars bit may have been realistic. They would have needed fuel to get into Earth orbit. (That said, the timing to return to Mars in any sane trajectory would likely be off.) The real problem would be getting into Mars orbit at the end of the return journey.
Even hard science fiction takes liberties since it pushes the boundaries of science or engineering. It explores the plausible, rather than what has been accomplished. If it didn't do so, it would not differ all that much from regular fiction (i.e. the story may be made up, but it is anchored in everyday reality).
As for the ASCII table, I wouldn't be surprised if it is one of the most commonly reproduced data tables in print and I would be surprised if it wasn't the mostly commonly reproduced table digitally. Virtually every *ix system will have a copy of it. The documentation for most development tools will probably have it. All you need is someone technically inclined in your life, which you will almost certainly have on a mission to Mars, and you will likely have a copy of an ASCII table (whether anyone knows it is there or not).
I mean, why even use an ASCII table at that point? For initial comm you could just do A=0, B=1 etc. for initial comms (until you get to the point you want to reprogram the eeprom) you can have higher bandwidth communication.
If I remember correctly, the book addressed this. 26 division of a circle was too much for reliable determination of which sign the camera was pointing at, so 16 (hex) made the angles more workable.
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)
You can't represent 26 possibilities with a single hex digit. So it'll require 2 hex digits.
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.
He later painstakingly translates machine code transmitted via the camera to the rover which patches the software to allow him to chat via text, so hex came in handy
I didn't say it needs to be sent 2 digits at a time.
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.
> 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
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.
