I have an old 12"x12" digitizer laying around with no I/O cable. With the rise in need for a tablet of some kind for drawing and such, I decided I should take advantage of my summer.

Lacking an I/O cable, and lacking pinouts from Googling, ripping it open was the way to go. After AHelper1 was brought back to life with a fresh install of Debian, the hunt for communication began.

The internals of the digitizer were scary. I have good reason for that, the PCB's coating on the back side of the ~2sqft board was bubbling up and was chipping away, traces exposed, drops of solder in weird places, scratches, etc.. The digitizer is powered by an i8051 and used 16 (iirc) analog demultiplexers for positioning (magnetic pen and cursor).

The I/O cable was odd, requiring a 12VDC 200ma supply and RXD/TXD RS232 lines sent through a standard RJ45 jack with a DE25 or DE9 for the PC connection. After fighting off faulty intermediate cables to join a RJ45 to a DE9 and picking between the digitizer's 2 separate TXD lines (one goes through a hex buffer, the other to a RS232 line driver. Clearly the hex buffer line was correct Neutral), I was able to send data.

I found xf86-input-summa, however the protocol it used wasn't compatible with this digitizer (might have been for a different tablet model). I took a brute-force approach with spamming 1,2, and 3 byte commands over to determine more of the protocol as the existing one wasn't fully correct. I was able to map out resolution codes, polling, a 130Bps echo mode, different types of halting, etc..

A few test programs were made that could send files to the digitizer one character at a time and echo them back as well as a terminal graphics-style drawing program that showed the pen location as well as drew based on button ID pressed.

Since I wasn't able to find much information on this myself, I will dump my findings here, including images of the PCB, pinout for the RJ45 cable, and protocol information.


Code:
Protocol Information:

Format:    RS-232-C
Baud rate: 9600
Data bits: 8
Stop bits: 1
Parity:    Odd
Flow Ctl:  None

Commands
========
"\0" - Resets certain modes
"P" -- Requests position information (See position data structure)
"x" -- Returns ".#99DB"
"r" -- Stalls tablet(?), next command ignored.
"s" -- Same as r, next command ignored. (Exceptions)
"st" - Acts as prompt.
"y" -- Next prompt showed no pen down. Maybe 5 bytes read weren't position?
"z" -- Sent after "y", prompts resumed.  (Does "y" set a mode, or is "z" nothing?)
"\x81" - ??
"\x93" - Sets T flag (tablet ID).
"\xC0" - Enables continuous data stream mode *only* while in proximity.
"\xE1" - Acts as prompt. (Noted that data seemed wrong)
"\xEB" - Enabled echo mode. Echos back written data (only first byte received is valid).
         Responds @ 130Bps, exists on '\0'.
"\x__\x01" - First byte seems to not matter, tried with 0x31 and 0x0F.
             Enables continuous data stream mode *only* while in proximity. '\0' disables.
"\x93\x50" - Halts tablet until tablet powerdown. ('\0' has no effect?)
"\x__\x5B" - Starts echo mode, same as "\xEB".
No 3-byte commands found so far

The digitizer will send position data on its own whenever a button is held, no command
is needed to enable this.

Resolutions
===========
The SummaSketch starts out in ~450 counts/inch mode (max 5850 counts).  There is no known code for this resolution yet nor how to revert back to the default state.
xf86-input-summa sent 'a' after each resolution then expected some size information afterwards.  This does not appear to be the case at all. "a" has no meaning.
"e" - Resolution around 195 counts/inch, max around 2345
"f" - Resolution around 247 counts/inch, max around 2975.
"i" - Resolution around 495 counts/inch, max around 5945.
"j" - Resolution near 1 count == 0.001 in, max around 11700.
"l" - Resolution at 1 count == 1 inch, max is 0-11 horiz. 0-12 vertical (odd)
"q" - Resolution near 1 count == 0.001 in, max around 11900.

 == POSITION DATA STRUCTURE ==
7   6   5   4   3   2   1   0   | PH - "Phasing bit", always 1
------------------------------- | Pr - 0 on proximity, else 1
PH  PR  T   Sx  Sy  Fc  Fb  Fa  | T - Tablet ID
0   X6  X5  X4  X3  X2  X1  X0  | Sx, Sy - Sign bits for X and Y. 1 is positive, 0 negative.
0   X13 X12 X11 X10 X9  X8  X7  |   Always 1 in absolute positioning.
0   Y6  Y5  Y4  Y3  Y2  Y1  Y0  | Fc, Fb, Fa - 3-bit value for buttons
0   Y13 Y12 Y11 Y10 Y9  Y8  Y7  |

 == BUTTON VALUES ==
:: Stylus         :: Cursor
F | Tip | Barrel  F | 1 | 2 | 3 | 4
----------------  ------------------
0 |     |         0 |   |   |   |   
1 |  X  |         1 | X |   |   |   
2 |     |   X     2 |   | X |   |   
3 |  X  |   X     3 |   |   | X |   
                  3 | X | X |   |   
                  4 |   |   |   | X
                  4 | X |   | X |   
                  5 | X |   |   | X
                  5 |   | X | X |   
                  6 |   | X |   | X
                  6 | X | X | X |   
                  7 | X | X |   | X
                  7 |   | X | X | X
                  7 | X | X | X | X


Todo:
  • Digitizer supports absolute and relative modes, command in xf86-input-summa said "E" is relative and "F" is absolute.
  • Get more info on y, r, s, t, x, z.
  • Pinout needed
  • Images and screenies


Now, the issue I have is interfacing with this digitizer. I am looking at getting the digitizer working with X11, however must be configurable from a userland program. This boils down to changing configuration (nothing that needs real-time changing), such as changing the absolute/relative mode, updating resolution, changing the target screen area, and setting up hotspot locations. It would be ideal that the userland program can be notified by digitizer events as well.

Now, I don't know where to go at this. I haven't touched any of these parts of the underlying X11/Linux device drivers, so excuse my scrambling around looking at various things. I looked at an input driver with xf86, but it doesn't seem like I can communicate inwards (unless I can perform magic with removing the driver, changing config, and reinserting it). I saw that xf86 docs say to not directly write input drivers anymore and instead to write kernel modules using evdev. I haven't had luck finding out how to "nicely" open an arbitrary serial device (either /dev/ttyS* or /dev/ttyUSB*). With the kernel module route, configuring and communicating with it should be simple from what I am reading, however I haven't had much luck with finding information on communicating back to X11.

Any suggestions on a way to get a driver written for X11 using an arbitrary tty device allowing configuration from the user while using it? I am assuming kernel module is the way to go, but lack of info...

<edit>

Directly using uinput right now, will see how this goes.

<edit>

FTDI-based USB serial cable came today, works great with AHelper0. I can finally stop using AHelper1 and continue on.

Code:
[ 7851.520088] usbcore: registered new interface driver ftdi_sio
[ 7851.520125] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 7851.520338] ftdi_sio 2-1.4:1.0: FTDI USB Serial Device converter detected
[ 7851.520395] usb 2-1.4: Detected FT232RL
[ 7851.520399] usb 2-1.4: Number of endpoints 2
[ 7851.520402] usb 2-1.4: Endpoint 1 MaxPacketSize 64
[ 7851.520406] usb 2-1.4: Endpoint 2 MaxPacketSize 64
[ 7851.520409] usb 2-1.4: Setting MaxPacketSize 64
[ 7851.521200] usb 2-1.4: FTDI USB Serial Device converter now attached to ttyUSB0
[ 7980.664954] input: SummaSketch II as /devices/virtual/input/input19


<edit>

Warning about polling continuously using "P" - Pressing any button on any input device causes a jitter in the Y axis. Letting the SummaSketch send the data itself shows no jitter and is in general smoother.

<edit>

Played a few games of UT with the cursor and for a short amount of time with the pen. Worked very well, actually. I did that more of a joke since I wasn't expecting my relative mouse part of my driver to be stable. The cursor has a felt pad that caused it to wobble back and forth, all-in-all fine. Will work more on the pen (something is wrong with the secondary button) and make more progress on the driver and the Qt interface.
I have still been working on this. Right now, I have been getting the interface for the configuration utility for the driver(s). I'll have screenies once functionality is added.

(I still need to add the pinout for the serial cable)
IPC working somewhat, just need the frontend to have the drive initiate device communication.

<edit>

The frontend talks to the backend, initializes the driver and lets me use it. I am adding in code to actually configure and read back configurations in the driver.
Mirroring the source over on github. Should stay up-to-date eventually.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement