2

I'm trying to read data from a COM port which is sniffing a standard receipt printer. I'm using the example from MSDN regarding the SerialPort.DataReceived event found in the docs.

I'm getting data but it's garbled characters. How do I convert that to readable text? Is it encoded binary or something? Can please you offer insights into this kind of serial port programming?

I've searched on the Internet for hours trying figure out how to make it readable text but I'm missing some concepts somewhere between A and B.

enter image description here

I've read somewhere it could be the protocol not matching up. Is there a way to detect this?

Update 1

I'm trying something new from a thread I found here at StackOverflow (I used Update 1) and I'm not sure what I'm looking at now but I get no more weird characters:

enter image description here

So how do I get readable text from here?

Update 2

I am still a little confused.

enter image description here

  private static void port_OnReceiveDatazz(object sender,
                              SerialDataReceivedEventArgs e)
   {
       SerialPort spL = (SerialPort)sender;
       byte[] buf = new byte[spL.BytesToRead];
       Console.WriteLine("DATA RECEIVED!");
       spL.Read(buf, 0, buf.Length);
       Console.WriteLine(Convert.ToBase64String(buf));
       foreach (Byte b in buf)
       {
           //Console.Write(b.ToString());
       }
       Console.WriteLine();
   }
Community
  • 1
  • 1
Rod
  • 14,529
  • 31
  • 118
  • 230
  • 4
    I would refer to the documentation on the printer. It should explain the data being sent. The serial port class simply reads the data, whatever it is, it does not do any conversion for you. – Nate Aug 03 '12 at 15:52
  • 3
    Also, check that your data rate, number of bits, parity, and stop bits match what the printer is using. If any of these don't match, you'll see garbage data. – JamieSee Aug 03 '12 at 15:55
  • 1
    Without knowing the printer protocol you will not be able to make sense of the data easily. What printer model is it? – Strelok Aug 03 '12 at 16:57
  • 2
    I guess you can start at the [manual](http://www.epicpos.com/productdocs/RP-Download-Ithaca-iTherm280-Programmer's-Guide.pdf). – CodeCaster Aug 05 '12 at 22:34
  • Looks like "common garbage" - each one starts with "spades clubs space arrows" (that's my names) and ends with a diamond. That looks like protcol delimiters. I'd dump everything between the delimiters in hex and see if you can figure anything out. – John3136 Aug 05 '12 at 23:44
  • can you share the hex value what you received on that – Arunkumar Chandrasekaran Aug 07 '12 at 13:03
  • Is that binary shown that I can convert to hex? – Rod Aug 07 '12 at 13:11
  • @Rod Yes, you can convert it to Hex. Can you share the code reading the input stream from the printer? – David Aug 08 '12 at 12:52
  • The code I'm using is in the OP which is the link to MS site. Now I noticed in Device Manager there are settings there for protocol as well for the com port I'm listening in on. – Rod Aug 08 '12 at 19:58
  • @Rod - when making question updates, it is generally better to merge new information _into_ posts, or if they are better separated from the original post, as addendums. As it stands, new readers see your updates in reverse order before they know what the question is about. – halfer Aug 09 '12 at 22:44
  • @halfer Thanks for edit, I wasn't sure the best way to go about it. – Rod Aug 10 '12 at 15:08
  • No probs. Imo, if you make it readable to the new reader, since existing readers will have no trouble (they broadly know the question already). – halfer Aug 10 '12 at 15:28
  • I am still struggling with this I apologize for missing bounty award. What do I do to make that part right? – Rod Aug 14 '12 at 04:23

2 Answers2

2

Yeap, you are getting a lot of bytes, if you pay attention you get the ascii number. 5 0, 6 5, etc are the headers of your data.

First of all you need to know the protocol, but if you want "read" that, you must convert it, not with ToString, you need use:

 Convert.ToBase64String(bytes)
Leandro Bardelli
  • 10,561
  • 15
  • 79
  • 116
0

Not sure there is any such thing as a 'standard' receipt printer as even for the same manufacturer these devices tend to differ in functionality between models, They most certainly differ between manufacturers.

Its unlikely that a receipt printer would need bytes in order to express the limited set of characters found printed on most receipts. A few currency symbol, Letters, Number and a few punctuation characters and some control information would mean that these could happily fit into ASCII (7 bits).

You really do need to visit the manufacturer web site if they have one and down load the technical manual or protocol guide if they have one available. This is often quite tricky as not all manufacturers have this information available on line. You may have to contact them directly and get them to Fax or mail you a copy of the protocol specification.

There are blocks of repeating characters in your data, these are most likely the data that tells the printer that another block of information is being sent or a new line is required. These may occur at the start or end of a line of data. For example they may be instructions to the printer to move the print head back to the start of the print line and scroll the paper,in effect the CR/LF instructions for the device.

This type of thing is device dependant and the devices specification will tell you more. What you could possibly assume is that this is not the information you asked to be printed.

If you can't get a protocol document then good old fashioned detective work is all you can fall back on.

I can tell you that the iTherm uses one or more ASCII characters following the ESC character (27) in your bytes, to perform various actions. More information can be found in the programmer guide can at URL starting at page 62. http://www.transact-tech.com/tsg/downloads/28-04430%20Rev%20K%20-%20Insert-M280%20POS%20Programmers%20Guide.pdf

What you should do is match what you asked to be printed (assuming you have the paper output) and the bytes being sent. You know what you should get as print output. You know bytes what it generates, you eliminate the repeated stuff that can't be you information. You then have to work out the rules getting from what you have left to the output you expect.

It would help you to know what the host is sending and what the printer is doing in response

The first few bytes in order appear to be :

(06, *)  = Printer sends ACK (ID) after host send ENQ (id) to printer
(05, n)  = Inquire Printer Status return codes 
...
Code Uniquely
  • 6,356
  • 4
  • 30
  • 40