Sleep() is a bad design, but appears to be my only option

What you are doing is called blind-cycle synchronization. It is not necessarily bad design. If your device does not have the functionality to indicate that it is ready for more data or not, this is the only way to do it.

It is common for devices to specify a maximum data rate, or minimum amount of time between bytes.

I think the idea of this being bad practice comes from cases where you blindly pick a delay value (performance will suffer if it is larger than it needs to be), if you have better synchronization methods available, or if you are using delays to cover up timing problems (say, in a multithreaded application).

Another reason Sleep might not be the right thing is you may want the functionality to quit early. If you instead did

WaitForSingleObject(hTerminatingEvent, 600);

You could have another thread signal the event that you want to quit and terminate early. (In this case this function call will continue after 600 ms even if the event isn't signaled.)

On Windows, I'd use a waitable timer for this instead of Sleep(), but if your hardware needs delays, then you're going to need delays.