Update README.md

Clikcing

README.md

@@ -5,6 +5,10 @@ Transfer data via Web Audio API.
 
 This experiment had a goal to transfer text or a binary file using sound waves. Binary data is modulated using many oscillators using Mult-Frequency Shift-Keying (MFSK). The audio analyzer is used to demodulate the signal back into its original form.
 
+# How fast can it go?
+
+Fast enough knock your socks off... by erosion. Sticking with just telphone frequencies (300 Hz to 3.4 kHz) I was able to get it working at just under 1 Kbps when using my laptop alone. When communicating with a mobile phone running the same web page, the speeds were dismal. 138 bps for telephone frequencies, 538 bps for human hearing frequencies. The effective data rate is about half of that if you consider the overhead of error correction and packetization headers.
+
 # Setup
 
 Other than using Vite to run the software locally, this is a pure JavaScript application. You can copy all of the files to a web server. Files and folders that may be excluded are:
@@ -23,7 +27,7 @@ Its going to be noisy. The louder the better.
 
 If you don't want noise, you are in luck. As you are running one device, you can send the signal directly to the analyzer in its purest form. Make sure the `Output` is set to Analyser. If you want to experience the audio and the errors often related to demodulating the signal, switch over to Speakers and check the Microphones "Listen" checkbox. The progess bar will show both yellow and red colors. Red indicates the percent of packets that failed while yellow are successful. If packets have failed after the signal stops, the packet numbers will be listed in the `Packet Errors`. You may click the "Request" button to send only those packets. The order does not matter. If a packet is out of range, the sender will continue to send all other valid packets.
 
-Being that you are both the sender and receiver, you have the option to use Automatic Repeat Request. If there are any packet errors after a signal completes, then the process of clicking "Request" will be automated repeatedly until the signal compeletes. Clikcing "Stop" in the `Message` area will not stop the automated process. You'll need to click `Manual Repeat Request` to prevent it from continuing.
+Being that you are both the sender and receiver, you have the option to use Automatic Repeat Request. If there are any packet errors after a signal completes, then the process of clicking "Request" will be automated repeatedly until the signal compeletes. Clicking "Stop" in the `Message` area will not stop the automated process. You'll need to click `Manual Repeat Request` to prevent it from continuing.
 
 Under `Message`, you see an option to `Send First Packet Twice`. I often found that the first packet failed to transfer. Since the first packet containes the data length header, it is fairly important that it comes through so that we can see a progress bar and discard packets that are out of range - even if the crc passes. The failing first packet is really annoying when `Automatic Repeate Request` gets into an endless loop trying to request a single packet. The quick fix was to just send the first packet twice. I suspect the issue is with the first sample period.