A buggy dongle that sends characters too fast? Hmm. Maybe the serial dongle isn't preserving application timing because of buffering?
No, a buggy dongle that doesn't signal to the driver that its buffer is full, or a driver that doesn't respect a signal and/or manage the buffer properly. A UART is a tiny 16-byte buffer and whatever is managing that has to ensure not to overrun it. It's a super simple piece of hardware, and if something isn't managing it properly then you just end up with garbage going out the serial line.
By writing to it slowly from the application you're working around that issue. If we know the radio can take the data at a full 9600 baud (which we do) then there's really not any other explanation for the application's speed of writing the data affecting the result, IMHO.
Now we're back to lowering the latency timer. For example: the application sends a record, waits for processing, and then sends another record. If the dongle/driver buffers across two records, and then blasts out the entire block it could nullify the record processing timeout. Lowering the latency timer might help with this as it reduces buffering.
Have you looked at the code? That's not what is happening. We're waiting for an ack after every block we write to the device. The inter-character delays being introduced basically mean we never fill the tiny buffer in the UART.
My experience was FTDI chipsets were most reliable in many ways. They responded well to a change in the latency parameter I mentioned earlier. Prolific USB dongles come in second to FTDI in my experience.
Yep, me as well, although Jim's testing just now seems to indicate that they are the least reliable, which surprises me. I'm not really sure what the "latency" setting is affecting, and I'm not aware of any such equivalent on non-Windows platforms. I also think that the non-Windows platforms seem to be unproblematic, IIRC.
--Dan