Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Guitar Hero: 4'33"

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


                   

A Standard for the Transmission of IP Datagrams with Human Voice

.. human binary communication
  (+5)
(+5)
  [vote for,
against]

This idea is a more feasible alternative to the already excellent RFC 1149. (see link)

Use humans to talk binary to each other. Any medium will work. Whispering in the ear, on the phone, walkie- talkies, shouting to another person half a block away. When you hear someone telling you a string prefaced by "incoming binary transmission". You sit at the closest keyboard and start typing (because you're not going to remember it and it has to be translated to binary to make sense)

Let's say you are trying to send a 128 byte long binary file.

There are several options. Some more practical than others:

- Raw binary. Ex: 11110001 11010100. This will yield bandwidth of approx 2 bit/s with many errors .. it's bad and annoying

- Decimal. Ex: 241 212. Bandwidth ~ 4 bit/s

- Hexadecimal. Ex: F1 D4. Bandwidth ~ 8 bit/s

- Binary-to-word encoding. Ex. vehicle. Bandwidth ~ 16 bit/s

- Binary-to-word encoding is a map of 65535 common english words to a binary index from 00000000 00000000 to 11111111 11111111

... and no, you don't have to use the full protocol with it's overhead. Let's say all you want is to do is send that 128 byte binary file to your friend with your voice, just use a tool that encodes it into words, and then speak for about a minute while your friend types it into his computer. Done.

While 16 bit/s is respectable, you could double and triple it with compression depending on what content you were sending.

ixnaum, May 11 2016

RFC 1149 https://tools.ietf.org/html/rfc1149
[ixnaum, May 11 2016]

Barely vaguely related... A_20staple_20form_20of_20memory
[normzone, May 11 2016]

[link]






       So the logical use for this system would be instances where lossy transmissions are okay?
normzone, May 11 2016
  

       With well chosen words in the binary-to-word encoding dictionary, it doesn't have to be lossy.   

       Ex: How likely is it that you will mess up if I tell you the word: "vehicle" ? Even if you don't know how to spell it, that's probably ok because spell check can correct it as long as the dictionary doesn't contain similar words. (which it won't)   

       And if you are really concerned, break up the binary string into 10 word sentences. Each sentence will have CRC attached to it. If you get it wrong you just retransmit the last 10 seconds.
ixnaum, May 11 2016
  

       I should also add that the encoding dictionary is optimized for statistically more likely binary numbers being shorter to type. Ex: 00000000 00000000 would be "a". And 11111111 11111111 would be "in"
ixnaum, May 11 2016
  

       I am slightly disappointed. I was hoping for precisely-modulated yodelling. Or perhaps whistling.   

       Incidentally, if you ever accidentally phone a fax machine, you can confuse it and keep it talking for over a minute by whistling at it.
MaxwellBuchanan, May 11 2016
  

       I would dispute that there are 65535 common English words in most senses of "common". Also, many of the words involved would be quite long, so I doubt the bandwidth would be as much as that for any set of 65535 words in English.
nineteenthly, May 13 2016
  

       Indeed. I think I did something similar to this and decided that the best way of doing it would be to have a system for assigning sequences of bits to specific syllables which became "nonsense" words.
nineteenthly, May 13 2016
  

       You could use NATO alphabet. That would certainly help in understandability.
mofosyne, May 13 2016
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle