[Printers] Dot positions of the Kyocera C5016N
Michael Sleator
sleat at hottie.net
Tue Oct 25 00:50:37 PDT 2005
This appears to be the same scheme used by the Toshaba FC22. I've
posted an image from that to the mailing list. Mine came out rotated
90-degrees with respect to yours, but it is clearly the same encoding
method.
Let's use your orientation, for the sake of discussion, but if you
will pardon me, I'd like to speak of the rows and columns numerically
in base 10. Your single character labels are more convenient for
ASCII drawings, as you've made, but my reason for going against your
convention is that it will make some of the patterns more obvious
and, I think, in the long run easier to discuss.
I think we can safely disregard the blank row and column that separate
the copies of the pattern for the moment. I also agree that the
triplet at the top center appears to be some sort of marker, so
let's disregard that for the moment as well. Still lacking any
real sense of which direction would most naturally be "up", let
us keep 0,0 as you have it, in the lower left corner of your pattern.
One of the first things I noticed was that, apart from the top row,
each row has even parity. This is true for both your data and mine.
There doesn't seem to be an obvious parity column, though. Looking
more closely, I observe, as you did, that column 8 is, apart from
in rows K and L, entirely blank, and forms a sort of gutter between
the two halves of the pattern. So I propose that we just skip that
column in the numbering.
Now things are starting to look rather interesting. We have two halves,
each containing 8 columns of interest. But look! All rows have exactly
one dot in each half, except rows 0, 5, 10, and 15. This is true for
both your data and mine. So your observation about the significant
vertical unit is holding up. Ignoring those rows for a moment, it
looks like what we have is some sort of one-of-eight coding. So of
course those rows will have even parity, by definition, but that
appears to be not very interesting.
Let us further label the structure as we see it now. We have four blocks
of rows: 1-4, 6-9, 11-14, and 16-19. Each of these has a low byte
(cols. 0-7) and a high byte (cols 8-15). For simplicity, lets call
the low bytes A and the high bytes B. Lets number the blocks in
increasing order of their row numbers: Blk 0: rows 1-4; Blk 1: rows 6-9;
Blk 2: rows 11-14; Blk 3: rows 16-19. Now we can refer to blocks as 0A,
0B, etc., and bytes as 00A, 00B, etc.
Here's the structure (with my data filled in):
A B
19 - - - - - - - 0 - - - - - - - 0
18 - - 0 - - - - - - - 0 - - - - -
17 - 0 - - - - - - - 0 - - - - - - 3
16 - - - - 0 - - - - - - - 0 - - -
15 - - - - - - - - - - - - - - - -
14 - - - - - - 0 - 0 - - - - - - -
13 - - - - - - - 0 - - - - - 0 - -
12 - - - - 0 - - - - - - - - - 0 - 2
11 - 0 - - - - - - - - - - - 0 - -
10 - - 0 - - - 0 - - - 0 - 0 - - -
09 - - - - - - - 0 - 0 - - - - - -
08 - - - - - - 0 - - - - - - - 0 -
07 - - - - - 0 - - - 0 - - - - - - 1
06 - - - - - - 0 - 0 - - - - - - -
05 - 0 - 0 - - - - - - - 0 - 0 - -
04 0 - - - - - - - - - - - - - 0 -
03 - 0 - - - - - - - - - - - - - 0
02 - - - - 0 - - - - - - - - - 0 - 0
01 - - - 0 - - - - - - - - - - - 0
00 0 - - - - - 0 - 0 - 0 - 0 - 0 -
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
Several features are striking. First, note that blocks 3A and 3B are
identical. This is true for both your data and mine. Block 0B is
interesting in that the alternating pattern in my data is like that
in your data, except that mine is in the high half of the byte and
yours is in the low half.
So what are we to make of rows 00, 05, 10, and 15? First I note that
byte 0B is identical in both data sets. This, and the enticing pattern
of alternating bits suggests a marker. Whether it is in reality
a start or and end marker remains to be seen (and, in some sense,
is purely a matter of convention). In byte 0A, both data sets have
bit 0 set, but yours has bit 4 and mine bit 6 as the additional bit.
Nothing obvious there.
In row 5, we have interesting case. You show bits 1, 3, 5, and 7 set.
I have only two bits, 1 and 3. Can you recheck your data and make sure
that bits 5 and 7 are indeed set in this byte? The presence of a 4-bit
pattern in one data set and not the other might be highly significant.
I have checked my printer output carefully, and my transcription seems
to be correct. Based on everything else, it would be startling to find
four dots in that byte.
In the high byte of row 5, we again have one bit in common and one bit
different. Likewise in row 10, both bytes have one bit in common and one
different. In fact, it is the same bit that is in common in both bytes.
Furthermore, your byte 10B is the same as my 10A (but my 10A is not the
same as your 10B). Perhaps this means nothing. In such a small data set,
one can find patterns in pure randomness if one looks hard enough.
Row 15 is striking because it is completely empty, and seems to set off
the identical blocks 3A and 3B in a special way.
The multi-bit bytes could be pure delimiters, or they could be combined
delimiters and payload data. If they were pure delimiters, one would
expect them to be the same in the two data sets. Also, the fact that
they always have at least one bit in common between the two data sets
whispers of combined delimiter and payload. Furthermore, given the
possibly unique nature of byte 00B (hence the importance of my question
about your 10B), and the structure of block 0B, I'm inclined to treat
that whole block as a special case. (And I now wish that I had labled
that side as A, rather than B, but I'm too lazy to go back and change
the whole writeup now.) This might be an argument for reading the entire
code on a block-by-block basis, rather than row-by-row. If the multi-bit
bytes do indeed carry payload data, this interpretation suggests that
they should be grouped with the following block. That is, byte 00A
would be part of block 0A, byte 05B part of block 1B, etc.
Your observation that apart from the one triad there are no adjacent
dots must be significant. This means that the coding is even more
restricted than a simple one-of-eight code. One way to satisfy this
constraint would be to use a one-of-four code, and simply use the odd
numbered bits in one row and the even numbered bits in the next.
On reading, then, we collapse bits 0 and 1 into bit 0, bits 2 and 3
into bit 1, etc. Each block is now neatly 8 bits in the final decoding
(assuming pure delimiters). Also, block 0B is looking more and more
sensible, though the difference between your block 0B and mine is
still puzzling.
And now I think I've got the "delimiters" figured out. They appear to
be odd column parity over each pair of columns within the block. I'll
use the notation 01B.2, for example, to refer to bit 2 of byte 01B. In
my data, 00A.0 is set because 03A.1 and 04A.0 are set. 00A.6 is set
because none of 01A.6, 01A.7, 02A.6, 02A.7, 03A.6, 03A.7, 04A.6 and
04A.7 are set. And so on. So having all four bits set in your 05A
does indeed make sense! This also explains why row 15 is empty.
So what do we have after all of that? Well, disregarding blocks 0B, 3A,
and 3B, we have five blocks that boil down to eight bits of payload data
each. That's 40 bits, or 64 if we include all eight blocks. This leaves
the question of ordering and assignment. Since in our geometric arrangement
the parity bits come at the bottom of the block, perhaps this is a clue
that we should be going in the other direction so that the parity follows
the data. It's still unclear how to sequence the blocks, and whether
there's any particular relationship between the A and B blocks of a pair.
Block 0B is still interesting. The fact that it has the same bit
repeated four times, but it's a different bit for your data and mine,
is curious. Perhaps it is just a high-order bit of a serial number
or manufacturer's ID. If I get some more time to tinker with this,
I'll try a few possible decodings and see if anything jumps out as an
obvious choice. It may be necessary to get some actual "ground truth",
such as a serial number, to sort this out completely.
I apologize for the rather stream-of-consciousness nature of this post.
I was essentially typing away as I figured things out, and I can't quite
bring myself to go back and tidy it up and make it appear as though it
all came in one devine revelation.
Michael Sleator
sleat at sleator.com
>The array for this printer has 18 columns and 23 rows (including empty
>ones). I considered the empty column and one of the empty rows to be
>the last one, which fixed the origin of my coordinates (the empty rows
>are F and M). There are almost no adjacent dots (only a triple near
>the top), which leads to the idea that the encoding is not simple
>binary.
>
>Here is a sample (sorry, I don't know neither the SN nor the time of
>printing, '-' means blank, '+' means dot, columns are enumerated 0..M,
>rows are enumerated 0..H):
>
>M ---- ---- ---- ---- --
>L ---- ---- -+-- ---- --
>K ---- ---- ++-- ---- --
>J ---+ ---- ---- +--- --
>I ---- --+- ---- ---+ --
>H ---- -+-- ---- --+- --
>G +--- ---- -+-- ---- --
>F ---- ---- ---- ---- --
>E ---- --+- ---+ ---- --
>D ---+ ---- ---- +--- --
>C ---- +--- ---- -+-- --
>B ---+ ---- --+- ---- --
>A +-+- ---- ---+ ---+ --
>9 ---+ ---- ---- ---- +-
>8 ---- +--- ---+ ---- --
>7 ---+ ---- ---- +--- --
>6 ---- +--- ---+ ---- --
>5 -+-+ -+-+ --+- --+- --
>4 ---- --+- ---+ ---- --
>3 -+-- ---- ---- +--- --
>2 --+- ---- ---+ ---- --
>1 -+-- ---- ---- +--- --
>0 +--- +--- -+-+ -+-+ --
> 0123 4567 89AB CDEF GH
>
>First impressions (positions are named in the form column/row, i.e.
>H0 is the rightmost position in the bottom line):
>
>If we ignore the triple 08K,9K,9L] (which is special anyway for having
>adjacent dots), the rows G,H,I,J contain the (hex) pattern 00080240
>twice, separated by the column 8 (which becomes empty once the triple
>is ignored).
>
>The dots in the rectangle 15...7D form a visible pattern which almost
>repeats itself if translated 8 positions to the right and 5 positions
>down (i.e. in the rectangle 90...F8). Additionally, a smaller pattern
>in the lower left corner (00..45) almost repeats itself 10 positions
>right and 5 positions up (A5..EA).
>
>It might therefore be that the significant vertical unit is 5 rows.
>
>Alternatively, the code might be rotated +/- 90 degrees, i.e. consist
>of horizontal bytes. In this case, columns 0..7 and 9..G might be
>data and 8 and H separators.
>
>The byte sequence in the left half (top to bottom, LSB left) would be:
>11,02,04,02, 40,AA,10,08, 10,08,05,08, 10,08,40,00, 01,20,40,08
>right half:
>55,08,04,08, 04,22,04,08, 04,80,44,02, 10,08,04,00, 01,20,40,08
>
>Ralf
>--
>GS d->? s:++>+++ a+ C++++ UL+++ UH++ P++ L++ E+++ W- N++ o-- K-
>w--- !O M- V- PS+>++ PE Y+>++ PGP+ !t !5 !X !R !tv b+++ DI+++
>D? G+ e++++ h+ r? y?
>
>_______________________________________________
>printers mailing list
>printers at frotz.zork.net
>http://frotz.zork.net/cgi-bin/mailman/listinfo/printers
More information about the printers
mailing list