Bottom Line Up Front

I started with PuTTY; used its serial mode. However, it is not designed to send bytes. I immediately switched to RealTerm. That let me easily send a ccTalk poll command.

TL;DR

A few Google searches for escape sequences and ways to send raw bytes from PuTTY were not successful. It’s a great program just not meant for my needs. That said, PuTTY was already installed and its use gave me a chance to see the bits on-the-wire. I sent quite a few ASCII, A’s already. 

RealTerm has a facility to raw bytes under the “Send” tab. Below you can see there’s two send-buffers. They accept either decimal or hex input. For example, I entered the ccTalk poll command, 2 0 1 254 255 (Strictly speaking, 254 is the command, 2 0 1 and 254 are the destination, number of data bytes sent, and the checksum respectively. More on ccTalk commands in my next blog entry.)

Anyway, by clicking “Send Numbers” you can see the result in the display, and you will note that I prefer to see just the hex. This was previously configured under the “Display” tab by me, but not shown. Hopfully, that’s self-explanatory:

Spoiler alert: Note the second input field, 2 0 1 229 24. The command 229 will be used to continually poll the coin acceptor, keeping it enabled and working. For now, let's continue.

Before I show the result, that is bits-on-the-wire, I placed a probe at the serial Tx line (probe 1) and then on the ccTalk data-line (probe 2):

My (eventual) intent and rational for this probe placement was to see a short command being sent and then more bytes at the data-line (that is, both the PC’s data and that from the acceptor). I’ll show that in the next post. For now, let’s see the bits for just the ccTalk poll command:

The figure above shows each of the btyes sent ( 2 0 1 254 and 255) and that they’re reflected (seen) at probe 2 (on the ccTalk data-line.) Everything is looking good! Let’s power-up the coin acceptor and with luck, we’ll see a response.