How do I force a serial port write method to wait for the line to clear before sending its data?

Question

Here's some background on what I'm trying to do:

1. Open a serial port from a mobile device to a Bluetooth printer.
2. Send an EPL/2 form to the Bluetooth printer, so that it understands how to treat the data it is about to receive.
3. Once the form has been received, send some data to the printer which will be printed on label stock.
4. Repeat step 3 as many times as necessary for each label to be printed.

Step 2 only happens the first time, since the form does not need to precede each label. My issue is that when I send the form, if I send the label data too quickly it will not print. Sometimes I get "Bluetooth Failure: Radio Non-Operational" printed on the label instead of the data I sent.

I have found a way around the issue by doing the following:

for (int attempt = 0; attempt < 3; attempt++)
{
    try
    {
        serialPort.Write(labelData);
        break;
    }
    catch (TimeoutException ex)
    {
        // Log info or display info based on ex.Message
        Thread.Sleep(3000);
    }
}

So basically, I can catch a TimeoutException and retry the write method after waiting a certain amount of time (three seconds seems to work all the time, but any less and it seems to throw the exception every attempt). After three attempts I just assume the serial port has something wrong and let the user know.

This way seems to work ok, but I'm sure there's a better way to handle this. There are a few properties in the SerialPort class that I think I need to use, but I can't really find any good documentation or examples of how to use them. I've tried playing around with some of the properties, but none of them seem to do what I'm trying to achieve.

Here's a list of the properties I have played with:

• CDHolding
• CtsHolding
• DsrHolding
• DtrEnable
• Handshake
• RtsEnable

I'm sure some combination of these will handle what I'm trying to do more gracefully.

I'm using C# (2.0 framework), a Zebra QL 220+ Bluetooth printer and a windows Mobile 6 handheld device, if that makes any difference for solutions.

Any suggestions would be appreciated.

[UPDATE]

I should also note that the mobile device is using Bluetooth 2.0, whereas the printer is only at version 1.1. I'm assuming the speed difference is what's causing the printer to lag behind in receiving the data.

Solution 1

Flow control is the correct answer here, and it may not be present/implemented/applicable to your bluetooth connection.

Check out the Zebra specification and see if they implement, or if you can turn on, software flow control (xon, xoff) which will allow you to see when the various buffers are getting full.

Further, the bluetooth radio is unlikely to be capable of transmitting faster than 250k at the maximum. You might consider artificially limiting it to 9,600bps - this will allow the radio a lot of breathing room for retransmits, error correction, detection, and its own flow control.

If all else fails, the hack you're using right now isn't bad, but I'd call Zebra tech support and find out what they recommend before giving up.

-Adam

Solution 2

Well I've found a way to do this based on the two suggestions already given. I need to set up my serial port object with the following:

serialPort.Handshake = Handshake.RequestToSendXOnXOff;
serialPort.WriteTimeout = 10000; // Could use a lower value here.

Then I just need to do the write call:

serialPort.Write(labelData);

Since the Zebra printer supports software flow control, it will send an XOff value to the mobile device when the buffer is nearly full. This causes the mobile device to wait for an XOn value to be sent from the printer, effectively notifying the mobile device that it can continue transmitting.

By setting the write time out property, I'm giving a total time allowed for the transmission before a write timeout exception is thrown. You would still want to catch the write timeout, as I had done in my sample code in the question. However, it wouldn't be necessary to loop 3 (or an arbitrary amount of) times, trying to write each time, since the software flow control would start and stop the serial port write transmission.

Solution 3

The issue is likely not with the serial port code, but with the underlying bluetooth stack. The port you're using is purely virtual, and it's unlikely that any of the handshaking is even implemented (as it would be largely meaningless). CTS/RTS DTR/DSR are simply non-applicable for what you're working on.

The underlying issue is that when you create the virtual port, underneath it has to bind to the bluetooth stack and connect to the paired serial device. The port itself has no idea how long that might take and it's probably set up to do this asynchronously (though it would be purely up to the device OEM how that's done) to prevent the caller from locking up for a long period if there is no paired device or the paired device is out of range.

While your code may feel like a hack, it's probably the best, most portable way to do what you're doing.

You could use a bluetooth stack API to try to see if the device is there and alive before connecting, but there is no standardization of stack APIs, so the Widcom and Microsoft APIs differ on how you'd do that, and Widcom is proprietary and expensive. What you'd end up with is a mess of trying to discover the stack type, dynamically loading an appropriate verifier class, having it call the stack and look for the device. In light of that, your simple poll seems much cleaner, and you don't have to shell out a few $k for the Widcom SDK.

Comments

[Adam Davis]

Jason, did you contact Zebra, and what did they say? I'm interested to know how this story turned out...

[Smith.Patel]

It was a while back... I just remember that they recommended software flow control, which we'd already determined as the best approach. I don't remember them mentioning limiting the transmission speed or anything along those lines.

[Smith.Patel]

This would explain why using any of the clear-to-send, request-to-send option seemed to have no effect.

[ctacke]

Do mobile development for a while and you'll tend to collect several "when is a hack not actually a hack" bits. In fact you'll probably create a small library of them. It's one of those things that makes the belief that desktop development and device development are the same pretty much invalid

[Smith.Patel]

ctacke - I have noticed quite a few issues trying to port code from a desktop application over to a mobile app. It seems the Compact Framework never has that one method or property you need for an object, whereas it is available in the regular .NET framework. Grrrr.