The device and software has been working here for a few weeks. Not quite flawlessly, but well enough that I have been considering enlisting my neighbors as beta testers. The first oppurtunity arrived a few nights ago, when my friend's well either ran dry or froze and I was asked to diagnose the problem. By the time I arrived to test the system, the condition had cleared itself and results were inconclusive. A dry well could have recovered in the time it took me to get to the house, while a frozen line could have cleared after my friend had turned on the heat in the space that the water line traversed.

Now that water was flowing and life could resume, we powered up the WellWell and started the WellNow app. The power-on self test ran, and then nothing. No data appeared in the app, something that I feared would happen. Something in the data timing of the well monitoring device has changed and I need to drag out the reverse engineering tools again. This time, however, I have a device that is practically purpose made for the task, it just needs appropriate software. Introducing WellWhat, an infrared to VCD tool chain. Load this firmware in to a WellWell device, pair it to something that can capture serial data. Run the captured data through a few lines of a Ruby app to get a VCD file for Pulseview to display. There are refinements to make in the code, but as things are I can now get the data I need to see what has changed.

This brings us to the meaning of the title of this entry. While developing the new firmware, this time without the assistance of DMA hardware, I ran in to a huge bottleneck. Data transfer between the Z8 and HC-05 is over a serial UART running at about 113kb/s. That is close enough to 115kb/s that it hasn't been a problem until now. Sending just the two byte timestamp values can take longer than than the bit time of the well monitor, leading to lost data and unhappiness. Why not turn up the baud rate, you ask? The next higher baud rate I can use, 250kb/s, is not supported by the HC-05. The '05 does support 230.4kb/s but there would be a more than 8% timing error, a little too much to ensure reliable data transfer. If I were to change the 20MHz oscillator to one running at 18.432MHz, I could turn the baud rate all the way up to 1.15Mb/s but that might require better signal routing and possibly terminations for the signal paths. I think I'll try 460kb/s, when the parts order arrives.