Go Down

Topic: Crazy idea but bear with me - using sound for data transmission (Read 8728 times) previous topic - next topic

extent


I would like to give my 2 cents here...


Exactly, but here's where the issue of overhead comes in.  Encoding your ascii character in that way only works up to values of 99.  If you want to send the ascii character 117 then you'd need to send 3 tones, '1','1',and '7'.  This is a symbol rate 50% slower than your 2 tone example (Note here that your data rate is still the same, it's just that most of the data is wasted, or overhead)

Each DTMF tone can represent any value from 0-15 (4 bits), and by sending each digit as its own tone you're only using 10/16 of the value payload possible in that tone.

So instead lets look at the number 117 as binary
01110101

Since each DTMF tone can hold 4 bits of data we can break up that number into two chunks
0111 # 0101

and convert each of those to a value.
7 # 5

Then send those two tones (note that it's not the number on the dialpad, but the "index" of the tone from 0-15.  For example the number 7 tone could be the "#" and the number 5 tone could be the "9" key, the specifics don't matter)  On the other end you recombine the binary values again and now you've sent the same character that previously you had to spend 3 tones creating, but with only 2 tones (30% faster!)

For plain text transfers even that still has a lot of overhead (what, something like 70/255)  There are still other tricks that you can do to decrease the overhead even further if you limit the number of characters you send over.

Techone

Quote
Each DTMF tone can represent any value from 0-15 (4 bits), and by sending each digit as its own tone you're only using 10/16 of the value payload possible in that tone.


In that case, a number from 0 to F ( 0 to 15 ). Let use example 117 ---> 75 in Hex, and you right, you are sending in HEX, that is better than decimal.  Then it is possible to send data that way, but it is very SLOW.  I agree with you.

extent

Ok, I do understand all of that.  But baud rate and symbol size both combine to give your gross bit rate.  And your gross bit rate is your total data transfer speed. 

A system with a baud of 1 and symbol size of 8 has the same gross bit rate as one with a baud of 8 and a symbol size of 1.

A system with a baud of 8 and a symbol size of 8 will be much faster because it's gross bit rate is higher.  It's not more effective because of it's baud rate, or because of it's symbol size, but only because it's gross bit rate is higher (both combined).  A system with a baud of 64 and a symbol size of 1 would be equivalent, because once again it has the same gross bit rate.

None of that has any relation to whether the system is appropriate for "numbers" or "letters".  Only the gross bit rate and the required application factor in to determine that.  If a 4 bit/2 baud system is inappropriate for an application (8bps) then an 8 bit/1 baud system would be equally inappropriate (8bps)

On a basic level, the specifics of symbol size only change the way you package your data up for transmission. Not what kind of data you can put into them.

So I'm afraid I still don't get it :/

Now keep in mind I am speaking very generally.  I also understand overhead factors in as well.  If you are not reading from a stream of data, but instead say reading a single 2 bit value over and over then a 2 bit/4 baud system is superior to an 8 bit/1 baud system in both throughput (due to overhead) and latency.  But the OP isn't talking about transmitting a single small packet of data, but streaming arbitrarily large amounts of it.

bilbo

Quote
If you can fit even the 26 letters in common English usage (not counting numbers or punctuation) into the 16 DTMF symbols, recommend contacting a patent attorney immediately to apply for protection of your intellectual miracle.


Hey ke7gkp, if you can fit even 128 ASCII characters in common usage into A message of 2 possible symbols, congratulations, contact a patent attorney right away, you've just invented binary.

DTMF tones could (inefficiently) be used to transfer data in HEX, with 8 times the thruput of a binary signal of the same baud rate.

Go Up