Newsletter Insert Jan. 2014

Drew & Scott’s Young Gun Automation Insert

Two Ears, One Mouth

Drew Baryenbruch

“There is a reason the maker gave you two ears and one mouth.” That is an adage every young person has heard at one time or another. It always feels like barb but we know it’s sound advice. In a work setting I think those words cut even deeper. As young professionals we all assume the person saying those things thinks we don’t listen or care. That may be the case some of the time but I believe that message is used far more often to say, “Slow down before you make yourself look like an idiot.” Far from a sign of disrespect these mentors are trying to save us from our overeager selves.

We tend to drive our responses to questions at 100 mph. This is our way of insuring everyone knows we know what we are talking about. We think that quick wit shows we have experience and should be taken seriously. The realization that time and true experience will bring is that business isn’t a game of Jeopardy. Being the first to ring in is rarely the key to being rewarded. In fact the result is often far from rewarding. This is because the questions posed to us as solutions providers, integrators or sales people are often not the questions that need to be answered to make our customers successful.

Two Questions, One Answer
I think the adage should be updated to “Ask two questions for every answer you give.” A practice like this helps to insure you are answering the correct questions with far less assumptions. The “Assume” adage being another we are familiar with.

Attentively listening to a customer describe what they believe they need doesn’t do the trick. We work in an ever more complicated market space, you have to verify the customer’s application to make sure your solution matches their need or you will end up with a lot of returns and unhappy customers. Without directed questions listening can be as fruitless as running your own mouth.

A Male Dominated Industry adds Peril
We work in a space that is 90% male making this lesson even more important. I don’t know why we gentleman insist on making gut based assumptions instead of asking for directions but we do. What’s worse is when we do ask for help we are too proud to get the help we actually need. If we are hopelessly lost we don’t ask how to get to our final destination. That would be too easy. Instead we ask how to get to the highway because once there we can somehow wing it.

A lesson can be learned from gas station attendants here. When asked about directions to the highway the good attendant fires back the tried and true, “Where you headed stranger.” They know the educational side of sales & service is making sure you give your customers the directions they need not the ones they are asking for. To do that they need to know the final destination which might turn out to be far closer than the nearest highway.

In our industry that means you need to understand the application and the problem the customer is having. The customer being convinced that your solution/service is what they need is a secondary step which happens only after you feel the same way.

Pieces and Persistence
The first key to understanding anything is to discover the pieces that make it work. The best place to start is at a high level.

Q: “Can you tell me about your application?”

This can generate a very direct response or in some cases a very detailed description containing many aspects of the application that are meaningless to the customer being successful with your solution. You either have to probe further or filter to suite. From a relationship standpoint people that like to share details enjoy someone listening and you are bound to learn a few things you didn’t know. Those shorter on details may need you to direct the conversation more but will certainly be happy to receive the proper solution.

Step back and make sure you ask questions before running into battle armed only with answers. It’s better for everyone.


Drew Baryenbruch

ASCII is the American Standard Code for Information Interchange. It defines 128 different characters; 99 are printable English alphabet letters and numbers and 33 are control characters. The standard can trace its roots back to 1960. The purpose of the standard was to define a printable, which at the time meant recordable, data structure that could be easily interpreted by both machines and humans.

In 1960 computers were glorified calculators. To save or transfer data you printed it on paper, punched it on an encoded card or saved it on a magnetic tape. LBJ’s 1967 mandate made support for ASCII a requirement for all computers purchased by the US government and helped cement ASCII’s rise to power.

ASCII’s Lasting Impact:
This 8 bit standard (which was originally 7 bits) is ubiquitous in computing. When you strike a key on your keyboard it is an ASCII representation that gets sent to your PC. In automation, printers, barcode readers, LED scrolling display, scales and many other reporting devices, still rely on ASCII character based communication. Why? Because it’s so simple.

ASCII characters can be easily sent over serial protocols like RS-232 or RS-485 and those characters can just as easily be placed inside of Ethernet TCP/IP packets. Simple tools like HyperTerminal allow you to view and troubleshoot ASCII based communications.

Defining an ASCII Message from a Stream of ASCII Characters:
The first key to working with an ASCII device is to define a message. A message is nothing more than a string of ASCII characters pulled from a stream of characters on whatever physical layer you are using. The three most common ways to do this are with delimiters, by length and by timeout.

Delimiters: Are defined characters or sets of characters that indicate the start or end of a message. The most common delimiters are nonprintable control characters. The control character <STX>, Start of Text, is a common start delimiter. <CR><LF> are the common end delimiters representing Carriage Return and Line Feed. Carriage Return and Line Feed were physical descriptions of what the printers would do when given these commands.

Length: Is a definition of the number of characters in a message. A message is X number of characters. Once X characters are received you process the message and wait for X number of characters to arrive again.

Timeout: Defines a message by the amount of time that passes after receiving the last character. If no characters are received over X amount of time the message will be considered complete.

Understanding ASCII Messages:
The messages from devices like weigh scales and barcode readers are pretty simple. These devices often produce a single piece of data. The message typically consists of a start delimiter and end delimiters around a string of raw data. Example: <STX>Barcode<CR><LF>  

Devices with a bit more function can represent many pieces of data. It is common for complex devices to implement a control and command language with function beyond what control characters can offer.

Take a weather station for example. The controlling device sends out commands such as <STX>get:temp<CR><LF>. The weather station would reply with <STX>Temp:32<CR><LF>.

These command and response messages are unique to each device and defined in documentation from the manufacturer. While that uniqueness makes implementations custom, these message commands are often abbreviation based making them fairly easy to understand and intuitive to work with.

The same weather station may also support a get all type command. When this command is sent, the unit will reply back with a long string of delimited values.

<STX>ACK:GETALL,13.5,78,180,85,<CR><LF> It is the commanding devices job to parse out those values and based on rules from the device manufacturer, give each parsed value relevance. 13.5 becomes wind speed, 78 the temp, 180 the wind direction and 85 is the humidity.



  • ASCII is nothing more than printable characters and nonprintable command characters to record and pass data.
  • Groups of characters together can make messages.
  • Messages are defined by delimiters, length or timeout.
  • Characters and messages can be passed over any serial physical layers and also delivered in Ethernet TCP/IP packets.
  • The ASCII standard only defines the character set.
  • The meaning of a message is defined by the device manufacture.

While exposure to ASCII its raw state is not as prevalent as it once was, have no fear if your next project requires ASCII. This isn’t a coding language or complex protocol it’s just a group of characters hanging out on the wire. Happy Coding.

If you have any questions, send us an email at