Double-check the embedded devices manual to see if it has any type of flow-control (XON/XOFF, RTS/CTS, DSR/DTR) available. Hacking in timeouts to replace flow-control is guaranteed to be a continual headache.

NOTE: Some embedded devices don't use a standard flow-control mechanism, but they echo the characters back to the sender. You can use that for flow control by not sending another character until you receive the echoed one. That way, you know that the device has seen your character and is ready for the next one.

Also, some embedded devices are line oriented, in that they just buffer the characters until a carriage return is detected. In most of those devices I've worked with, there wasn't a problem with the timing between the characters .. the time that was critical was the time after the carriage return was received, as that's when the command is parsed and executed. If that's the case, and if the device has a prompt, you could just send the entire command and then wait for the next prompt.

Finally, I've never used Device::SerialPort before (all my embedded work has been in assembly, C and C++), but a quick review shows that it has possible support for all the schemes above. First, I'd look at changing read_char_time(0) to something else, to make it wait for each character. That seems like it would be the first step in making sure that the character was sent before proceeding to your timeout. If there's some buffering going on, it could hide it from you with the current setting you're using. Secondly, the write_done() or write_drain() functions might allow you to ensure the data is sent before starting a timeout. Review the other functions, I'm sure there are other bits in there...

I hope you find something in this rambling post useful...