Bongofish

Screen Tablet malarky => Tablet Conversion to USB => Topic started by: Dragon on December 06, 2011, 08:53:24 AM



Title: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 06, 2011, 08:53:24 AM
So, I'd like to convert my GD-1218-R to USB.  Let me start out by quoting Bernard:

Warning: This mod will permanently disable the external serial & power connections (along with the power switch on the side of the tablet). Playing with electronics is not without risks. You can break or burn anything including your fingers.

I started with the GD-0912-R thread (http://forum.bongofish.co.uk/index.php?topic=1927.msg15014;topicseen#msg15014) and read it till I understand most of it.  I compared the pictures with my board, but unfortunately there are some differences:

[attachment=1]

I then emailed Bernard the following questions:
After staring at the pictures for awhile I realized that the "TR1R\nR1R" label on my board means that the component on left is the TR1R and the component on the right is the R1R.  They seem to do that when there isn't room to put the label next to the component.

My board has a power switch and it doesn't look like the 0912 does.  Will I still be able to use the power switch?  Will having the switch change how I have to do the circuit?  Maybe I should connect 5vcc to one of the pins on the power switch instead?

Does having a power switch imply it uses more power and thus won't run off 500ma usb?  The 12V DC brick says it outputs 200ma so 500ma seems like more than enough, but I'm not sure if fewer volts means more amps required...

The post says " The pad that is "alone" is the one we care about." on the TR1R.  I don't know what that means.  Since my TR1R is in a different location and orientation, how do I know which two pads to connect?

Bernard's response:
Lots of questions :)

I think it would be good that you start a thread to mod your board -- take another thread as template -- this will serve as an example for the next person wanting to do exactly this.  We would then modify-back the first (or second) post to put the essential details about doing this mod.

I never saw your model, but from the 1 sec quick glance I had on your picture, I instantly recognized a lot of the familiar chips -- which is no surprise, it has been the same over the years.

If you feel lucky, you can go and follow the same pinouts. If, instead, you want to be extra careful, -- hey -- maybe the designer -- *this time around* swapped pin 10 and 11 assignations on one of the chip. The rs232 driver chip contains the same circuit replicated and thus one could pick any of the driver circuit for any signal. It just happened that I never saw a different assignation so far, (and I have seen a lot).

There are ways to check on the assignations, and for this, you need a multi-meter (continuity).    You start from the serial port well know signals (the DB9) and you build a "table" similar to what I did for the other ones.  Eventually it boils down to know which pin on the serial driver chip is assigned to what (on the TTL side).

Power switch:  Some of the serial boards have a power switch but none of the USB boards have one.  In WaxBee, you can configure how much mAmp your device wants (this is inside one of the USB descriptor). (@5V) -- yes it is max 500mA@5V -- but you better keep that configuration number low because the USB host (the PC) will actually negotiate the power with the teensy and if there is not enough mA available, it will refuse you to augment to 500mA or whatever mAmps you configured).  All USB devices are guaranteed to have 100mA. I know your board is big, but I am pretty sure this is not going to be a problem power wise, you should have enough. I have a working GD-0912-R converted to USB with power (I think) under 100mA.

If you have a multimeter, you will be able to measure the current (eventually). You have to hook the multimeter in "series" with the power line. Watch out that stuff are connected and multimeter is setup correctly before doing that test.

As you saw, the switch is not on the 5V but on the incoming external power source.  It will be disconnected unless you hack something up.  (cut all the traces going to it and make the 5V go through it).  I am not even sure that it would works fine, because the USB signals will still be connected. There is something about a resistor for the device detection. So I am not entirely sure how the detection works in this case, windows might freak out a little. (saw a device that is not responding). You could test that actually. Personnaly, I would drop the switch if I were you.  On thing: the 5V power you get from the Teensy board. So if you really want to turn off everything, you gonna have to find a spot to hook to the 5V *before* the teensy use that 5V.  The Teensy has the USB connector and feeds off the 5V directly (you might be able to bypass it on the teensy board by cutting a trace -- would have to check that).

For the TR1R (the little device with 3 pins with the letter y on it) just orient it exactly the same way as mine and you will then know which is which.   Look at the table and try to replicate connecting one thing with another.  That TR1R is just another serial port driver (because the ADM202 didn't have enough driver circuits, Wacom decided to the "missing" one from scratch with analog parts instead of getting a bigger ADM202-like part). The transistor is the main part of that circuit.

We need to ground the TTL side.

Before touching anything, plan well.   Start with the ground and 5V power first and test that. Do the serial signals after.

--------

Ok, so, I'd like to go the "careful" route and trace things out, as long as it doesn't take hours.  I do have a multimeter and I know how to test voltage, resistance/continuity, even amps (although doing that still feels dangerous since it can blow a circuit if done wrong).

I'd like to keep the power switch because this tablet will double as a monitor and it would be nice to turn off the tablet part without turning of the monitor or unplugging the USB port (those Mini USB jacks are only rated for 10k connect/disconnects or something).  But if I have to lose the switch, I can live with that.  Bernard makes a good point that the 5V connects in to the Teensy before it hits the Wacom so it does seem very difficult to make the Wacom switch cut power to the Teensy...

Bernard says "You start from the serial port well know signals (the DB9) and you build a "table" similar to what I did for the other ones.  Eventually it boils down to know which pin on the serial driver chip is assigned to what (on the TTL side)."  So that's probably where I should start, but I have little idea what any of the things are that he's referring to.  I think he may be talking about this table:

Code:
                    | Internal connector |            | ADM202 pins
 Direction | PC DB9  | (board marking)    | CheckPoint |  RS --- TTL
-----------+---------+--------------------+------------+-------------
 <--tablet | 2 (RXD) | 7 (TXD)            | CP1        |  14 <-- 11
 -->tablet | 3 (TXD) | 8 (RXD)            | CP2        |  13 --> 12
 -->tablet | 4 (DTR) | 6 (/DSR)           | CP3        |   8 --> 9
           | 5 (GND) | 4 (GND)            |            |
 <--tablet | 6 (DSR) | 5 (/DTR)           | CP4        |   7 <-- 10
 -->tablet | 7 (RTS) | 2 (CTS)            | CP5        | R2R --> TR1R

I'll see if I can make sense of that next.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 06, 2011, 07:41:15 PM
Using the volt meter on my board and Bernard's table, CP1 is connected to pin 14 of the ADM202 like in the table.  I assume the "14 <-- 11" in the table means pin 11 of the ADM202 is connected to pin 14 of the ADM202 internally (which matches the circuit diagram of the ADM202), but I don't know why that's mentioned in the above table.  Volt meter does not show continuity between pin 11 and 14 even when positive and negative probes are switched.

To anyone wanting to check their own board, chips like the ADM202 will have a notch cut or small circle indented or some other marking in one corner of the chip indicating that's where pin 1 is.  Pins are then numbered along the closest edge to the notch that contains pins.  When you run out of pins on one side, follow the edge of the chip around the corner and when you turn a second corner and reach another pin, that's the next pin number in the sequence (pin 9 in the case of ADM202).

I found the DB9 (actually DE-9) pin numbers here (http://www.nullmodem.com/DB-9.htm).  DB9 is just another name for the end of the serial cable of the Intuos.  I later noticed there are also tiny numbers printed by each hole in the Intuos DB9 connector!  By placing one end of a straightened paper clip in hole number 2 of the DB9 female connector and touching the volt meter probe to the paper clip, I confirmed it's connected to CP1.

I think "Internal connector (board marking)" 7 refers to the white connector that CP1 is connected to, and that fits with the GD-0912 board markings (the white 1 on the left of the connector indicates pin 1, the white 10 on the right indicates pin 10).  However, my board markings appear to be reversed so CP1 is connected to pin 4 of my connector.  I'll have to build a modified table:


Code:
                    | Internal connector |            | ADM202 pins
 Direction | PC DB9  | (board marking)    | CheckPoint |  RS --- TTL
-----------+---------+--------------------+------------+-------------
 <--tablet | 2 (RXD) | 4 (TXD)            | CP1        |  14 <-- 11
 -->tablet | 3 (TXD) | 3 (RXD)            | CP2        |  13 --> 12
 -->tablet | 4 (DTR) | 5 (/DSR)           | CP3        |   8 --> 9
           | 5 (GND) | 7 (GND)            |            |
 <--tablet | 6 (DSR) | 6 (/DTR)           | CP4        |   7 <-- 10
 -->tablet | 7 (RTS) | 9 (CTS)            | CP5        | R2R --> TR1R

I updated the table above with how my board connects things and tested every point.  Only the Internal connector pin numbers are different.
DB9 pin 7 connects to the bottom side of the R2R in my picture.  The bottom left pin of TR1R is grounded.

So, here are my remaining concerns:
  • There does not seem to be any connection between any of the R2R pins and any of the TR1R pins.  Should there be?   Actually, by looking carefully at the traces I did discover that the top of R2R connects to the left of D1R and to the bottom of R3R.  The top left pin of TR1R connects to the top pins of both R3R and R4R, so there is an indirect path from R2R through R3R to TR1R but there's no direct continuity.  However, if I switch to resistance, there's 5.67kohm between the bottom pin of R2R and the top left pin of TR1R, so they are connected after all.  There's .993kohm resistance between the bottom pin of R3R and top left TR1R so I assume that R3R and similar are resistors.  R3R has 102 written on it which I assume means 1.02kohms while R2R has 472 for 4.72k ohms which together are close to the 5.67kohm resistance I read.
  • Should I be testing anything in relation to "14 <-- 11", "13 --> 12", "8 --> 9", and "7 <-- 10"?  I did check resistance from pin 11 to 14 and it was infinite.
  • Is there anything else I can check before I start soldering?


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 06, 2011, 08:37:52 PM
The other half of the equation is programming the Teensy USB.  I plugged it in and used waxbee.jar on Win7 and it seemed to work fine.  It said it successfully programmed the device.  I did notice that when I first plugged in the Teensy it had a slowly flashing orange light but after programming it has no light.  Is that normal?

I guess I need to make a new configuration file for the GD-1218 since GD-1212 is the largest tablet in the existing config files.  In GD-1212-R to Intuos2 12x18.tmpl.txt, can I just change SLAVE_TABLET_X/Y_MAX to equal USB_TABLET_X/Y_MAX?

I don't see anything else I would obviously need to change other than the name of the file, NAME, and DESCRIPTION.  Am I missing anything?


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 08, 2011, 04:18:08 AM
WaxBee Templates:  I suggest that you use the internal Waxbee editor (Raw Config Editing...) to modify the template files instead of modifying the tmpl.txt directly (although I purposely format those template files to be easily read and modified by a "human").   BTW, after editing it, you could also save it as another template so it is kept around. And when it works, I will bundle your template it in the project.

Teensy:  It is normal that the led does not blink after programming the Teensy.  Essentially, the teensy is always shipped with a "led blink" program.  We erased that and replaced it by our own.

So pick the template "GD-1212-R to Intuos2 12x18", then go to "Raw Config Editing" and ... hum yipes!  I think the numbers inside GD-1212-R template are not good. But no worries, they are very easy to fix!

So, yes, you are right, X and Y need to be equal.  Equal because both tablets are 2540 lpi (or 0.01mm per line) and they are both 12x18 AND they both have a 1.2 cm (1200) menu strip at the top (if I remember correctly).  (which is good news btw!).  If we make the math: we have 12 inches vertical (Y) and 18 inches horizontal (X), and an additional 1200 in the Y direction.  That makes:

Y = 12 inches * 2540 lpi + 1200 =  30480 + 1200 = 31680
X = 18 inches * 2540 lpi  =  45720

Actually as I am writing this, I am modifying it, so here's the content of the template file:
(I kept the menu strip as part of the active area -- so you now have an intuos2 menu strip -- if you can enable it in the drivers of course)

New template file (name = GD-1218-R to Intuos2 12x18.tmpl.txt )

Code:
#------------------------------------------------------------------------------
# WaxBee configuration
#------------------------------------------------------------------------------
NAME = "GD-1218-R to Intuos2 12x18"
DESCRIPTION = "Converts an Intuos 12x18 (GD-1218-R) to a USB Intuos2 (XD-1218-U)"
SLAVE_TABLET_X_MAX = 45720
SLAVE_TABLET_Y_MAX = 31680
USB_TABLET_X_MAX = 45720
USB_TABLET_Y_MAX = 31680

# Valid choices for USB_PORT:
# 0: DISABLED
# 1: DIGITIZER
# 2: DEBUG

USB_PORT = 1

# Valid choices for SERIAL_PORT:
# 0: DISABLED
# 1: SLAVE_DIGITIZER
# 2: DEBUG

SERIAL_PORT = 1

# Valid choices for ADB_PORT:
# 0: DISABLED
# 1: SLAVE_DIGITIZER

ADB_PORT = 0
USB_DEVICEDESC = @[
0x12, # bLength
0x1, # bDescriptorType
0x0,0x2, # bcdUSB - the Graphire3 is set at 1.1 (0x110) -- hope that is not a problem
0x0, # bDeviceClass
0x0, # bDeviceSubClass
0x0, # bDeviceProtocol
0x8, # bMaxPacketSize0 for endpoint 0
0x6a,0x5, # vendor id - WACOM Co., Ltd.
0x45,0x0, # product id - Graphire3 6x8
0x26,0x1, # bcdDevice - "version number" of the Wacom XD-1218-U
0x1, # iManufacturer
0x2, # iProduct
0x0, # iSerialNumber
0x1 # bNumConfigurations
]

USB_CONFIGDESC = @[
0x9, # bLength - USB spec 9.6.3, page 264-266, Table 9-10
0x2, # bDescriptorType;
0x22,0x0, # wTotalLength (9+9+9+7)
0x1, # bNumInterfaces
0x1, # bConfigurationValue
0x0, # iConfiguration
0x80, # bmAttributes
0x32, # bMaxPower (mA/2)(XD-1218-U = 140mA, Teensy = ??? : Total: 100mA)
0x9, # bLength - interface descriptor, USB spec 9.6.5, page 267-269, Table 9-12
0x4, # bDescriptorType
0x0, # bInterfaceNumber
0x0, # bAlternateSetting
0x1, # bNumEndpoints
0x3, # bInterfaceClass (0x03 = HID)
0x1, # bInterfaceSubClass (0x01 = Boot)
0x1, # bInterfaceProtocol (0x02 = Mouse)
0x0, # iInterface
0x9, # bLength - HID interface descriptor, HID 1.11 spec, section 6.2.1
0x21, # bDescriptorType
0x0,0x1, # bcdHID - Intuos2 is using HID version 1.00 (instead of 1.11)
0x0, # bCountryCode
0x1, # bNumDescriptors
0x22, # bDescriptorType
0x9a,0x0, # wDescriptorLength  HIDREPORTDESC Length (Graphire3 is 0x0062)
0x7, # bLength - endpoint descriptor, USB spec 9.6.6, page 269-271, Table 9-13
0x5, # bDescriptorType
0x81, # bEndpointAddress  1 | 0x80
0x3, # bmAttributes (0x03=intr)
0xa,0x0, # wMaxPacketSize
0x5 # bInterval max number of ms between transmit packets
]

USB_HIDREPORTDESC = @[
0x5,0x1, # USAGE_PAGE (Generic Desktop)
0x9,0x2, # USAGE (Mouse)
0xa1,0x1, # COLLECTION (Application)
0x85,0x1, #   REPORT_ID (1)
0x9,0x1, #   USAGE (Pointer)
0xa1,0x0, #   COLLECTION (Physical)
0x5,0x9, #     USAGE_PAGE (Button)
0x19,0x1, #     USAGE_MINIMUM (Button 1)
0x29,0x3, #     USAGE_MAXIMUM (Button 3)
0x15,0x0, #     LOGICAL_MINIMUM (0)
0x25,0x1, #     LOGICAL_MAXIMUM (1)
0x95,0x3, #     REPORT_COUNT (3)
0x75,0x1, #     REPORT_SIZE (1)
0x81,0x2, #     INPUT (Data,Var,Abs)
0x95,0x5, #     REPORT_COUNT (5)
0x81,0x3, #     INPUT (Cnst,Var,Abs)
0x5,0x1, #     USAGE_PAGE (Generic Desktop)
0x9,0x30, #     USAGE (X)
0x9,0x31, #     USAGE (Y)
0x9,0x38, #     USAGE (Wheel)
0x15,0x81, #     LOGICAL_MINIMUM (-127)
0x25,0x7f, #     LOGICAL_MAXIMUM (127)
0x75,0x8, #     REPORT_SIZE (8)
0x95,0x3, #     REPORT_COUNT (3)
0x81,0x6, #     INPUT (Data,Var,Rel)
0xc0, #   END_COLLECTION
0xc0, # END_COLLECTION
0x5,0xd, # USAGE_PAGE (Digitizers)
0x9,0x1, # USAGE (Digitizer)
0xa1,0x1, # COLLECTION (Application)
0x85,0x2, #   REPORT_ID (2)
0x9,0x0, #   USAGE (Undefined)
0x75,0x8, #   REPORT_SIZE (8)
0x95,0x9, #   REPORT_COUNT (9)
0x15,0x0, #   LOGICAL_MINIMUM (0)
0x26,0xff,0x0, #   LOGICAL_MAXIMUM (255)
0x81,0x2, #   INPUT (Data,Var,Abs)
0x9,0x3a, #   USAGE (Program Change Keys)
0x25,0x2, #   LOGICAL_MAXIMUM (2)
0x95,0x1, #   REPORT_COUNT (1)
0xb1,0x2, #   FEATURE (Data,Var,Abs)
0x85,0x3, #   REPORT_ID (3)
0x9,0x0, #   USAGE (Undefined)
0x26,0xff,0x0, #   LOGICAL_MAXIMUM (255)
0xb1,0x2, #   FEATURE (Data,Var,Abs)
0x85,0x4, #   REPORT_ID (4)
0x9,0x3a, #   USAGE (Program Change Keys)
0x25,0x1, #   LOGICAL_MAXIMUM (1)
0xb1,0x2, #   FEATURE (Data,Var,Abs)
0x85,0x5, #   REPORT_ID (5)
0x9,0x0, #   USAGE (Undefined)
0x26,0xff,0x0, #   LOGICAL_MAXIMUM (255)
0x95,0x8, #   REPORT_COUNT (8)
0xb1,0x2, #   FEATURE (Data,Var,Abs)
0x85,0x6, #   REPORT_ID (6)
0x9,0x0, #   USAGE (Undefined)
0xb1,0x2, #   FEATURE (Data,Var,Abs)
0x85,0x7, #   REPORT_ID (7)
0x9,0x0, #   USAGE (Undefined)
0x95,0x4, #   REPORT_COUNT (4)
0xb1,0x2, #   FEATURE (Data,Var,Abs)
0x85,0x8, #   REPORT_ID (8)
0x9,0x0, #   USAGE (Undefined)
0xb1,0x2, #   FEATURE (Data,Var,Abs)
0x85,0x9, #   REPORT_ID (9)
0x9,0x0, #   USAGE (Undefined)
0x95,0x1, #   REPORT_COUNT (1)
0xb1,0x2, #   FEATURE (Data,Var,Abs)
0x85,0xa, #   REPORT_ID (10)
0x9,0x0, #   USAGE (Undefined)
0x95,0x2, #   REPORT_COUNT (2)
0xb1,0x2, #   FEATURE (Data,Var,Abs)
0x85,0xb, #   REPORT_ID (11)
0x9,0x0, #   USAGE (Undefined)
0x95,0x1, #   REPORT_COUNT (1)
0xb1,0x2, #   FEATURE (Data,Var,Abs)
0xc0 # END_COLLECTION
]

USB_HIDREPORTDESC2 = @[
]

USB_STRING1 = "WACOM"
USB_STRING2 = "XD-1218-U - WaxBee emulation"
USB_STRING3 = ""
USB_STRING4 = ""
USB_STRING5 = ""

# Valid choices for USB_PROTOCOL:
# 4: WACOM_PROTOCOL4
# 5: WACOM_PROTOCOL5
# 6: WACOM_BAMBOO_TOUCH

USB_PROTOCOL = 5
USB_ENDPOINT0SIZE = 8
USB_ENDPOINT1SIZE = 10
USB_ENDPOINT2SIZE = 0
USB_ENDPOINT3SIZE = 0
USB_X_MIN = 0
USB_Y_MIN = 0
USB_X_MAX = 45720
USB_Y_MAX = 31680
USB_X_ANCHOR_MIN = 0
USB_Y_ANCHOR_MIN = 0
USB_X_ANCHOR_MAX = 0
USB_Y_ANCHOR_MAX = 0
USB_PRESSURE_MAX = 1023

# Valid choices for USB_BUTTON_ENCODING:
# 0: NONE
# 1: WACOM_INTUOS2_1218

USB_BUTTON_ENCODING = 0

# Valid choices for SLAVE_PROTOCOL:
# 1: WACOM_ADB
# 2: WACOM_ISDV4
# 3: WACOM_PROTOCOL5
# 4: WACOM_PROTOCOL4
# 5: WACOM_ISDV4_TOUCH
# 6: TOPAZ

SLAVE_PROTOCOL = 3

# (not implemented yet) Orientation affect X,Y coordinates but should also
# affect "tilt" and "rotation" values accordingly.
# NOTE: Data is rotated before MIN/MAX/ANCHOR transformation#

# Valid choices for SLAVE_ORIENTATION:
# 0: NORMAL
# 1: ROTATED_RIGHT
# 2: UPSIDE_DOWN
# 3: ROTATED_LEFT

SLAVE_ORIENTATION = 0
SLAVE_X_MIN = 0
SLAVE_Y_MIN = 0
SLAVE_X_MAX = 45720
SLAVE_Y_MAX = 31680
SLAVE_X_ANCHOR_MIN = 0
SLAVE_Y_ANCHOR_MIN = 0
SLAVE_X_ANCHOR_MAX = 0
SLAVE_Y_ANCHOR_MAX = 0
SLAVE_PRESSURE_MAX = 1023

# Configuration of special "Active" areas on the tablet (like a button).#
SLAVE_ACTIVE_AREAS = @[
]


# 16Mhz is not recommended with 3.3v supply.#

# Valid choices for CPU_CORE_CLOCK:
# 0: F_16MHZ
# 1: F_8MHZ

CPU_CORE_CLOCK = 0

# Serial port speed at initialization time.#

# Valid choices for INITIAL_SERIAL_PORT_SPEED:
# 0: BAUD_9600
# 1: BAUD_19200
# 2: BAUD_38400

INITIAL_SERIAL_PORT_SPEED = 0

# Serial port speed during normal operation.#

# Valid choices for SERIAL_PORT_SPEED:
# 0: BAUD_9600
# 1: BAUD_19200
# 2: BAUD_38400

SERIAL_PORT_SPEED = 2

# Maximum time before packet gets repeated.
# 0 to disable; max: 1200 ms#
IDLE_TIME_LIMIT_MS = 50

# Power up setup of GPIO pins
# Syntax: comma separated list of commands. Example:
# C7^,D4-,P250,D4+,P500,D4-
# D4 : Pin D4, + drive high (VCC), - drive low (GND), ^ pull-up, ~ floating, Pn Pause for "n" ms#
GPIO_INIT = ""

# Multi-purpose internal debug data. To be left empty for normal operation.#
DEBUG_DATA = @[
]

#==============================================================================
# A note about this file and its format for the braves that wants to tweak stuff
#------------------------------------------------------------------------------
# Do not change anything here unless you think you know what you are doing. :)
#
# Note that even if it stops working (a thing that can happen quite easily),
# there are virtually no chances that you break something 'physically'.
#
# In any case, it cannot 'brick' the WaxBee, there is always a way out. At worse,
# it might crash your OS (or the USB driver) or make it install USB drivers you
# did not want. Nothing that cannot be fixed.
#
#------------------------------------------------------------------------------
# Configuration items have the format :
#
#   NAME = 123
#
# Numeric values can be expressed as base-10 (decimal) or base-16 (hexadecimal)
# The hexadecimal notation requires 0x to be prepended. Example: 0x5e
#
# Text requires double-quotes as delimiters.
#
# Text comments starts with a # and goes up to the end of the line. Empty lines
# are OK.
#
# Each entry has a multi-line comment shown before. These are fixed. They will
# will be overridden when the WaxBee Config utility writes-back this file when
# 'saving'.
#
# Each value can have a one-line comment attached which will be shown after the
# value on the same line. This comment is tied to the value and will be
# retained after a read/write of the file (unless the value changed).
#
#   USB_PORT = 2  # DEBUG
#
# About multi-byte values (e.g. @[ ... ] ):
#
# The values are separated by commas and can be expressed as base-10 (decimal)
# or base-16 (hexadecimal). The hexadecimal notation requires 0x to be
# prepended.
#
# Each value is normally shown one byte (8 bits) at a time, but two bytes (16
# bits) are supported.# Currently, only bytes in 'Little-Endian mode' is
# supported. Use the notation: LE16() (i.e. Little Endian, 16-bits).
#
# For example:
#
# LE16(0x0c17),
#
# A one-line comment can be 'attached' to a value location, that comment
# reflects all the bytes that occurred before the previous comment and should be
# shown together (on the same line).  These comments are tied to the 'values'.
# These comments will be retained when the WaxBee Config tool reads/writes a
# configuration file.
#
# Typically a configuration is always a 'copy' of an existing one which already
# contained commented values
#
#==============================================================================



One thing you might tweak is the mAmp setting.  This is in the "USB Configuration Descriptor". Look for the line

 0x32,      # bMaxPower (mA/2)

-- it is currently set at 100mAmp.  This field is defined as the number of mAmp divided by two.  100mAmp / 2 = 50.  (0x32 is 50 in hexadecimal notation). If 100mAmp is not enough you might try 150mAmp.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 08, 2011, 04:38:56 AM
The ADM202 chip contains drivers and receivers -- it basically convert from/to TTL voltages (0v -5v) to/from RS-232 voltages (+12v..-12v or so).  So putting the probe on both sides of a receiver circuit will not yield continuity. The Teensy is TTL. So we need to know which Serial pin function is associated to which TTL signal to discover where we need to solder our precious wires.

Surface Mount Resistors markings:  What you need to remember is that the last digit is a power-of-10 multiplier.  so  100 is 10*100 Ohm or 10 Ohm.    102 is 10 * 102 Ohms = 1000 Ohm or 1k.

It is normal that the Transistor pad are not in continuity with the stuff around it. One of the leg is actually in continuity with the TTL pin on the Wacom chip (that's pretty far on the circuit, almost half that board), and this is the signal we are interested in.  We want to ground it essentially. This is because it is one of the serial handshake signal and if we leave it like that it will go "high" and "block" part of the serial communication.  Again, just rotate my picture (or your picture) until the part is in the same direction and you will know which pad we need to ground.

CheckPoints: (CP1, CP2..) -- these often change from one board to another.  So are those in the table you posted all accurate?  If not, we should remove (or modify) them.  I am thinking about the next person who will attempt to follow your steps. I mean, when you are about to "potentially damage" your board, it is always good to triple check everything. Anything that does not "fit" becomes a big source of stress.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 08, 2011, 06:17:02 AM
Thanks, Bernard.  Everything I could test in my table is accurate, including checkpoints.  The only thing that changed were the internal connector pin numbers.  The only part I couldn't (or didn't know how to) test were the right side values in the "14 <-- 11", "13 --> 12", "8 --> 9", and "7 <-- 10" column.  I did test the left side values. (14, 13, 8, and 7 are correct).


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 14, 2011, 08:47:12 AM
Well, I went ahead and did it.  The Intuos 1 is now soldered to the Teensy.  When I plug in the USB the teensy flashes fast for about a second, then stays lit solid for a second, then goes dark.  Using the latest Wacom drivers 6.1.7-3.  The tablet has power and shows a red LED.  When the pen is pressed on it, LED turns green.  Wacom control panel seems to think an Intuos 2 is connected (although I don't see how to check to make sure it really thinks it's connected) but moving the mouse and clicking the pen has no effect.

What's the next step in troubleshooting?


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 14, 2011, 02:18:38 PM
You have good signs. The tablet appears to be fine and the teensy is responding to USB.  There is a "diagnostic" panel under the wacom control panel's "about" page. But you will probably won't see anything in there.

My guess is the serial connection between the teensy and the tablet, either something is not properly grounded or the TX/RX is not connected correctly (or there is a short of some sort). The next step is to flash a "debug" template for a GD-* board and run HID Listen.  For the soldering and connections, can you take a close picture of the area?


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 14, 2011, 05:58:20 PM
Here's the wiring diagram I made before I started.  Red means cut, yellow are wires.

[attachment=1]

Finished wiring:

[attachment=2]

UPDATE: A few weeks later I noticed the lower left yellow wire in the picture above was loose where it connects to ground near the left side of the off-white serial connector on the Wacom board.  This is presumably because it's very hard to get the ground-plane hot enough to properly bond to the solder.  I had the same problem on my 0405 build.  So don't solder your ground wire to the ground plane like I did above, solder it somewhere like the ground pin of the serial connector or to the metal on either side of the serial connector.  The ground-plane is a large, irregularly shaped piece of metal in the circuit board that all ground points connect to.  You can sort of see its size and shape as a lightening in the color of the green plastic.  Its large size spreads heat away from any point you try to solder to and makes the solder unlikely to bond firmly.

Closeup of ADM202.  The bottom left five pins are cut and I verified with the sharp end of a pushpin there is no connection between top of cut leg and bottom soldered wire:

[attachment=3]

Another angle:

[attachment=4]

I also used a pushpin to verify the wires connected to ADM202 are making contact with the edges of the pads beneath them.  No wires are shorted.  I did the same for VCC and the grounds.  No soldered wires are loose and do not move with light pressure from a probe.  Solders on the Teensy side are quite solid.

Is there any other way to verify the ADM202 wires are making solid contact with the pads?

Another thing I noticed last night was the Wacom control panel showed an option to change settings for a pen, but then I disconnected the tablet and reconnected it and the pen disappeared from the control panel.  I had the pen sitting on the tablet and about 30 seconds later the control panel crashed.  That makes me think it may have been getting data from the Teensy but the data was malformed in some way and crashed it.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 14, 2011, 06:43:58 PM
Everything in "Firmware > Test Tools" and "Firmware > Program Device with Test Firmware" is greyed out so I can't run HIDListen.  I tried using the "GD-0912-R Debug" template, unplugged the USB and plugged it in again, and same effect.

I'm using WinXP 32bit and Bernard mentioned in another thread that Firmware couldn't be flashed without a 64bit OS, but maybe that's changed.  Maybe HID Listen won't run in 32 bit?

EDIT: I brought the tablet over to my Win7 64bit machine and plugged it in, waited the little bubble in the lower right of the screen to say it had installed driver software, and then brought up waxbee.jar and it also had all greyed out tools.

Also, when I said earlier that Wacom's control panel had detected a pen, I was wrong.  It was showing something else (a menu control or something) that later disappeared before it crashed.  I did the diagnostics in the About dialog and it showed the Intuos2 connected but all the fields on the pointing device side were empty whether I moved the pen close or not.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 14, 2011, 07:09:13 PM
Here's what the Wacom control panel looks like using the firmware template Bernard posted earlier.

[attachment=1]

I also found the Wacom HID dump utility on google code but it only reports what you see in the screenshot - it doesn't show anything different when I move the pen close (not sure if it's supposed to).

Before that crash I mentioned earlier the "Tool:" and "Application:" rows in the control panel had become blank so they didn't show "Functions" or "All".


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 14, 2011, 07:26:01 PM
I now support 64 bit Windows for flashing the Teensy.

Use Paul's HID Listen software instead of the one bundled in WaxBee (that one does not work).   Paul built a Windows, Linux and Mac OSX version.

http://www.pjrc.com/teensy/hid_listen.html



Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 14, 2011, 08:09:57 PM
Thanks, Bernard.

I've made some progress.  I realized that the firmware reprogram wasn't working on Winxp 32.  It showed that it was starting to flash and then it crashed silently, leaving an error log instead of showing the success dialog.  I didn't realize for a while that anything was going wrong.

So I flashed it on my Win7 machine.  Still nothing.  But then I wondered if maybe I should turn the tablet's power switch on?  Doing so made the Wacom control panel recognize a pen!  But that's it - it wouldn't move the mouse and diagnostics always said the pen was out of proximity and at 0,0.

So apparently the power light and the green LED when pen is clicked didn't mean all the internals of the tablet were turned on.  The power switch still needed to be turned on.

EDIT: After I fixed the root of the problem (discussed later) that was sending bad data to the Teensy, I can now turn the power switch off and it still works fine, so apparently my turning on the power switch hadn't really done anything (or maybe it altered voltages/resistances enough to get some data through?  Who knows.)

I tried Paul's HID Listen and it just said listening for device endlessly.  So I flashed the GD-1212-R Debug firmware and now HIDListen shows lots of stuff when the pen is put in proximity and moved.  My command prompt scroll buffer overflowed, but here's the end of the data (the last thing I did was press the pen tip hard in the lower left corner):

*(?!)F8x78Ç
*(?!)80Ç
*(?!)80x78Ç
*(?!)80x78Ç
*(?!)80x78Ç
*(?!)80°
*(?!)F8x78x78Ç
*(?!)800000°
*(?!)F8Ç
*(?!)80°
*(?!)F8°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)80x78Ç
*(?!)80x78x78°
*(?!)F8x78x78Ç
*(?!)80000000x7800Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x7800Ç
*(?!)80°
*(?!)F8x78x78Ç
*(?!)800000x78x78x78°
*(?!)F8Ç
*(?!)80Ç
*(?!)80Ç
*(?!)800000Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78x78Ç
*(?!)800000x78x78Ç
*(?!)80x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80x78x78Ç
*(?!)80x78°
*(?!)F8x78x78Ç
*(?!)800000Ç
*(?!)8000x78Ç
*(?!)80x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80x78x78°
*(?!)F8x78x78Ç
*(?!)80000000x7800°
*(?!)F8Ç
*(?!)80Ç
*(?!)80Ç
*(?!)8000Ç
*(?!)80Ç
*(?!)80x78°
*(?!)F8x78x78Ç
*(?!)800000x78x78x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8°
*(?!)F8x7800Ç
*(?!)80°
*(?!)F8x78x78Ç
*(?!)800000x78x7800Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8°
*(?!)F8x78x7800Ç
*(?!)80°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)80000000x78Ç
*(?!)80x78Ç
*(?!)80Ç
*(?!)80°
*(?!)F800x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)80000000x78x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78x78Ç
*(?!)80Ç
*(?!)80x78°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)800000x78x78°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)80°
*(?!)F800Ç
*(?!)80Ç
*(?!)80x78x78x78Ç
*(?!)80Ç
*(?!)800000x78x78x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78Ç
*(?!)80x78x78x78Ç
*(?!)80Ç
*(?!)800000°
*(?!)F8Ç
*(?!)80°
*(?!)F8°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78x78x78x78x78x78Ç
*(?!)80000000x78x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78x78x78x78x78Ç
*(?!)800000x78x78Ç
*(?!)80x78Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78x78x78x78x78Ç
*(?!)800000°
*(?!)F8Ç
*(?!)80°
*(?!)F8°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)80°
*(?!)F8°
*(?!)F8x78x78x78x78x78Ç
*(?!)800000x78x78x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78x78x78x78x78x78Ç
*(?!)80000000x7800°
*(?!)F8Ç
*(?!)80Ç
*(?!)80°
*(?!)F800°
*(?!)F8x78x78x78Ç
*(?!)80Ç
*(?!)800000x78x78x78°
*(?!)F8Ç
*(?!)80Ç
*(?!)80°
*(?!)F800°
*(?!)F8x78x78x78Ç
*(?!)80Ç
*(?!)80000000x78Ç
*(?!)80x78Ç
*(?!)80Ç
*(?!)80°
*(?!)F8Ç
*(?!)80x78x78x78x78Ç
*(?!)80Ç
*(?!)800000x78x7800Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78°
*(?!)F8x78x78x78Ç
*(?!)80Ç
*(?!)800000Ç
*(?!)8000x78x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8Ç
*(?!)80x78x78x78x78Ç
*(?!)80Ç
*(?!)800000x78x78x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8°
*(?!)F8x78x78x78x78Ç
*(?!)80Ç
*(?!)800000x78x78x78°
*(?!)F8Ç
*(?!)80Ç
*(?!)80°
*(?!)F800°
*(?!)F8x78x78x78Ç
*(?!)80Ç
*(?!)800000x78x78Ç
*(?!)80x78Ç
*(?!)80Ç
*(?!)80°
*(?!)F8°
*(?!)F8x78x78x78x78Ç
*(?!)80Ç
*(?!)800000Ç
*(?!)8000x78x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8Ç
*(?!)80x78x78x78x7800Ç
*(?!)800000x78x78x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78x78x78x78Ç
*(?!)80Ç
*(?!)800000°
*(?!)F800x78x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78x78x78x78Ç
*(?!)80Ç
*(?!)80000000x78Ç
*(?!)80x78Ç
*(?!)80Ç
*(?!)80°
*(?!)F8°
*(?!)F8x78x78x78x78Ç
*(?!)80Ç
*(?!)80000000x78Ç
*(?!)80x78Ç
*(?!)80Ç
*(?!)80°
*(?!)F8Ç
*(?!)80x78x78x78x78Ç
*(?!)80Ç
*(?!)80000000x78Ç
*(?!)80x78Ç
*(?!)80Ç
*(?!)80°
*(?!)F8Ç
*(?!)80x78x78°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)80000000x78°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)80°
*(?!)F8Ç
*(?!)80x78x78°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)80000000x78x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78x78x78°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)800000°
*(?!)F8Ç
*(?!)80°
*(?!)F800Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8Ç
*(?!)80Ç
*(?!)80°
*(?!)F8x78°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)800000x78Ç
*(?!)80°
*(?!)F8°
*(?!)F8x78°
*(?!)F8x78°
*(?!)F8x78°
*(?!)F8x7800°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)800000°
*(?!)F8°
*(?!)F8Ç
*(?!)80°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)80Ç
*(?!)80°
*(?!)F8°
*(?!)F8Ç
*(?!)80°
*(?!)F8Ç
*(?!)80x78°
*(?!)F8x78Ç
*(?!)80Ç
*(?!)800000Ç
*(?!)80Ç
*(?!)80°
*(?!)F8Ç
*(?!)80x7800Ç
*(?!)800000000000°
*(?!)F8x78x78Ç
*(?!)800000000000000000

(*!)


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 14, 2011, 08:16:02 PM
Here's a full log (attached).  I placed the pen in the center of the tablet and lightly dragged it to lower left corner (I tried not to click but it detected some pressure cause the LED turned green), lifted it, then pressed it hard, then removed it.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 14, 2011, 08:47:52 PM
Do not panic or worry -- I am pretty sure we will find the culprit. (unless you need that tablet working today?)

I will analyse the output.

In the meantime, you can also try to setup the serial port driver by following the instructions here: http://www.pjrc.com/teensy/usb_serial.html  but use the version on the waxbee site: http://code.google.com/p/waxbee/downloads/list   then you need to grab a term software (can't remember the name of mine) and connect to the COM port that the virtual driver created.    None-8 bit-1 stop bit Speed is either 9600 or 38400 (tablet has 2 modes, starts at 9600 and you then tell it to go at 38400 speed).

Try the command  ~#<enter>
also try:
~C<enter>

I think that command worked because I saw it in the hid.txt output.

Check out the following to see the commands that are being used to talk to the tablet. Try them manually.
http://code.google.com/p/waxbee/source/browse/WaxB_Adb2Usb/protocol5_serial.cpp

I have little time, but I will assists you as much as I can.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 14, 2011, 08:53:19 PM
I'm in no rush (other than being impatient =) ).  Since this tablet wasn't compatible with the monitor I got for my cintiq build I'm going to sell it eventually once this mod works.

I was also wondering if the same firmware will work on the Teensy for all monitor sizes?  When you flash it you have to choose the display it's for, so I hope that doesn't mean it's tied to a particular display.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 14, 2011, 08:58:43 PM
no,no. Not tied to a display. This is just converting the tablet to USB.


It is true that on the waxbee main panel there is a monitor selection, but that was for features that are not implemented -- I wanted to provide some visual configuration of the aspect ratios and alignments (which is not there at all). (I think I should hide all that future stuff, it is confusing to users).



Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 14, 2011, 11:07:11 PM
So, from here (http://www.pjrc.com/teensy/usb_serial.html) I downloaded the windows installer, serial_install.exe, and ran it using right click > "Run as..." > "Administrator".  It installs an INF file that supposedly points to a standard windows driver used to access a usb device as a serial device.

Next I used the Teensy loader from here (http://www.pjrc.com/teensy/loader.html).  It says to press the button on the Teensy, which I did.  Then I went to File > Open HEX File and chose usb_serial-2011-07-06.hex from here (http://code.google.com/p/waxbee/downloads/list).  Next I chose "Operation > Program", then "Operation > Reboot".

Windows XP comes up with the Found New Hardware wizard.  I told it not to connect to the internet to search for driver software and clicked Next.  It found the software locally (thanks to running serial_install.exe earlier) and installed "USB Serial (Communication Class, Abstract Control Model)".

To figure out which COM port the serial USB is on, right click My Computer and choose "Properties".
Pick "Hardware" tab, then click "Device Manager" button.
Choose "View > Devices by type"
Expand the "Ports (COM & LPT)" section of the hardware tree.
Look for something like "USB Serial (Communication Class, Abstract Control Model) (COM4)".

Next, ran Start > All Programs > Accessories > Communications > HyperTerminal

Told it to not make HyperTerminal my default telnet program.
It asks for the name of a New Connection so I typed "Waxbee" and clicked Next.
Told it to "Connect using: COM4" (based on the COM port we found was assigned to USB Serial above).  Click Next.
Set the next dialog to "Bits per second: 9600", "Data bits: 8", "Parity: None", "Stop bits: 1", "Flow control: Hardware".  Click OK.

As soon as Hyperterminal connected, "9600" appeared on the screen followed by what seemed to be newline without line feed (or line feed without newline?).  So the cursor appeared on the line below 9600 but to the right of the final 0.
I typed ~#<enter> and got no response.  Same for ~C<enter>

Call > Disconnect.
File > Properties > Connect To tab > Configure button > Bits per second: 38400.  OK, OK.
Call > Call
This time it printed 38400 with the cursor on the next line to the right of the final 0.
No response to ~#<enter> or ~C<enter>

I tried Flow control: None and Flow control: Xon/Xoff with the same results.
Also tried unplugging and replugging USB with same results.
Ctrl-Enter and Shift-Enter appear to possibly send just CR or LF (at least Ctrl-Enter moves the cursor down a line without moving it left just like what Wacom seems to do after the "9600"), but sending one or the other or both in either order didn't prompt a response.

I'm pretty sure the "9600" and "38400" are coming from the tablet because I don't see that text when connecting to COM3 and I also don't see it if I disconnect and reconnect at the same baud rate so I think it's a notification of a change in baud rate from the tablet.



Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 15, 2011, 12:39:33 AM
The 9600 and 38400 is a piece of text that my little serial driver outputs -- it is just there to tell that it understood that you want to change to 9600 or 38400 bauds.  This string is not coming from the tablet but from the firmware on the Teensy. (that means you picked the right COM port and the teensy can talk to you correctly). Now we want to talk with tablet.

I use RealTerm from http://realterm.sourceforge.net/index.html#downloads_Download

The serial port setup:
Baud: 9600 or 38400
Parity: None
DataBits: 8
Stop Bit: 1
No XOn/XOff
No DTR/RTS/CTS/whatever handshaking (if there such options).

For RealTerm, you can setup with:

- Display As Ascii
- Half Duplex (to see what you are typing)
- Port tab, pick Baud rate
- make sure you have Parity=None, DataBits=8, StopBits=1, FlowControl=None
- Pick your port, then press "Open" (if you want to change port settings, it is better to depress Open first)

Now enter again ~#<enter>
you can also try just #<enter>  (this a "factory reset" and may reset the baud rate back to 9600 bauds)
If you move the pen, do you see anything?  (this is supposed to be binary data)
The commands ST<enter> (start) and SP<enter> (Stop) tells the tablet to start/stop transmitting pen coordinates.

It is weird that you do not see anything, since I saw the ~# command in the hid.txt file.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 15, 2011, 02:48:02 AM
Wow, realterm looks so hacker...  Cool.  =)

Unfortunately I was getting the same behavior with realterm.  It would display baud rate but not respond to ~# or # when followed by CR or LF.  However, since you mentioned it should show something when the pen is moved, I put the pen on it and moved it and saw a bunch of binary stuff.  I think I then typed #CR (that's what the terminal shows), got a single binary character as response, then tried ~# and it seemed to respond with the model string.  I tried ~# again and got the same model string but the start of the string was binary garbage.  I tried again and got the model again but more garbage.  I think I also tried # and ~C but I didn't see any recognizable response, if any.  After that it stopped responding to ~# again:

[attachment=1]

I wonder if there could be some sort of interference scrambling some of the data?  Or a weak solder?  Or maybe the binary data over the model string came after the model string and was some stray pen data (though I didn't have pen in proximity) that overwrote the model because it began with a CR and no LF.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 15, 2011, 03:06:17 AM
I turned on "newLine mode" which I think forces all CR or LF to generate a new line.  Then I tried sending dozens more # and ~# and couldn't get that model string to come up again whether or not I moved the pen first.  I did notice that moving the pen tended to display nothing for a little while (5+ seconds) and then I'd suddenly get a rush of binary.  Moving the pen just a little and pulling it away didn't always show anything.

I unplugged the tablet and plugged it back in and finally got #~#CR to show the model string without even moving the pen around.  But the first 3 characters were garbage instead of "GD-" and since "newLine mode" was active I think that definitely means the first three chars were corrupted.

I also noticed whenever I move the pen or type something to the terminal the teensy flashes as if it's getting data but it doesn't always output anything to the terminal.

I guess another possibility is the mamps setting is too low for this board?  I don't know if it's possible to tweak that in this serial debug mode.  It seems less likely to be a problem since I would expect the tablet to cut out when the pen was moved on it (drawing extra power), not when the pen was away.

EDIT: Two other ideas - bad Teensy board?  I could try the other one.  Or is it possible I need to cut off the ADM202 chip instead of just cutting the five pins?  I wanted to leave things as unmangled as possible in case I wanted to try to undo my changes, though I doubt I'd be able to get that TR1R back on.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 15, 2011, 04:04:33 AM
I just saw that the garbage "binary" data is actually showing the value in that very small space -- like E0  for 0xE0 !  I never realized this until now.  Pretty cool stuff.

Yes, there could be a bad ground somewhere or some glitchy setup.  The teensy itself is grounded, right?  The thing is: it appears to work.  Maybe something is "floating". I wish I could connect my scope which is about 6 inches away from my hands right now.  Let me review your photos.

You can always change the mAmp settings in waxbee.  The "templates" are just "pre-filled configuration values".  For the power, I do not know what happens if the device pulls more power than negotiated. I guess it depends on the internal USB controller.  It may very well be that nothing happens.  Especially for a 200mA spike for example.

EDIT: try grounding the teensy closer to the serial signals maybe. (But I doubt this would make a big difference).


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 15, 2011, 05:21:29 AM
Yes, the teensy is grounded.  I get continuity between the frame of the USB plug and a ground point on the Wacom.

I also double checked the pad of pin 9 on the ADM202 is continuous with ground points elsewhere on the board.  I also tried measuring resistance and I got 0ohm for a second or two and then it crept up to 6.3 ohm and slowly down to 5.3 where it stayed.  I tried measuring resistance between two ground points next to eachother and they stabilized at 3.2ohm.

There is no continuity between pins 11 and 12 (TX/RX) but there is less than infinite resistance.

I did see in the original log I captured with the HID listener it said:

WaxBee -- bzz! bzz!
Serial/ADB tablet to USB converter.
 slaveXMax:30480 slaveYMax:24060 usbXMax:16704 usbYMax:12064
protocol5_serial::init()
~#GD-1218-R00,V1.2-7
Serial Tablet - GD-1218-R00,V1.2-7
Intuos

so it seemed to respond to the ~# without any garbage.  So I went back to that firmware and tried hid_listener again but now it always gets stuck here:
WaxBee -- bzz! bzz!
Serial/ADB tablet to USB converter.
 slaveXMax:30480 slaveYMax:24060 usbXMax:16704 usbYMax:12064
protocol5_serial::init()
~#

I tried unplugging and plugging the USB at least ten times and it never got past that point.  Touching the pen to the tablet also does not produce data in hid_listener anymore.

I tried setting the Debug firmware to 150ma instead of 100ma but hid_listener behaves the same way.  I also tried 200ma.

I started testing resistance and resistance between the TX/RX pins 11 and 12 was only like 233ohms.  I was thinking about how Jan said she used flux remover on her project and I read that flux can cause low levels of conductivity, so I tried swabbing at the pins with a q-tip.  Now volt meter says 233kohms with red probe on pin 11 (which makes me wonder if I really saw 233ohms before or if I misread 233kohms) or around 23 mega ohms with red probe on pin 12.  Pin 9 to 10 either way is 39kohm, 9 to 11 is 39kohm.

After my qtip treatment, hid_listener showed the expected responses each time with six plug/unplugs and the pen sent data through hid_listener again.  Unfortunately, the Wacom driver still doesn't recognize any pen movements with the regular Teensy firmware.

I also tried the serial firmware and got it to respond correctly to ~# and ~C at least 30 times, although I might have seen one garbage response but I'm not sure if it was because it was overwriting the old buffer (I hadn't discovered the CLEAR button yet).  I switched from 9600 baud to 38400 baud and closed the connection and opened it again but it will not respond to ~#/C at 38400 baud.  It still works when switched back to 9600 baud.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 15, 2011, 05:29:07 AM
Success!  I changed the "baud rate during normal operation" to 9600 in the standard template file and flashed that and now I can move the cursor and click using the tablet!

But I wonder why it won't work at 38400?  Still has flux residue maybe?  I'm not sure how else to clean it other than to go out and buy flux remover, but apparently there's different remover for different kinds of flux so I'll probably have to order it online...

UPDATE: I scrubbed at the pins for awhile with a soft toothbrush and rubbed the end of a spudger between the pins as well so they look much cleaner.  I also cleaned between D2/D3 on the Teensy.  Resistance changed from 233kohm to about 1mohm.  Resistance between pins 9 to 10 and 9 to 11 remained at 36kohm.

Unfortunately it still won't work at 38400.  I connected using HyperTerminal and Realterminal and sent dozens of ~# and never got a response.  I also tried 19200 but in that case the Teensy doesn't respond with "19200" and it doesn't respond to ~# so I assume that's an unsupported speed.  What seems weird is using the debug firmware set to 38400 "baud rate during normal operation" and running hid_listener, the tablet responds.  Maybe debug firmware is hard coded not to exceed 9600 baud?  I also tried standard firmware at 38400 baud again but the tablet doesn't respond to pen movement.

It's possible some flux flowed under the ADM202 where I can't scrub it off.  Maybe I should cut it off completely now that I know it works at 9600 baud.  It seems usable like that - do you think it even matters if I get it working at 38400?


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 15, 2011, 08:39:23 PM
I cut off the ADM202 completely and very thoroughly cleaned again with a soft toothbrush dipped in 70% rubbing alcohol this time.  I tried to make sure the bristles got under the yellow wires too.  Things look even cleaner now but resistances haven't changed.

Wacom driver and usb serial still won't respond at 38400.  I then tried issuing the "BA38" command at 9600 baud.  No response to that, and sending ~# at 9600 baud continued to get the standard response.  Then I tried BA19 for 19200 baud.  No response, but sending ~# no longer gave a response either.  I changed the port speed in realterm to 19200 and Teensy responded with "19200" and ~# got a response.  I tested sending hundreds of ~# and never got corruption.

So I changed the standard firmware to 19200.  I put the pen down and it moved for a second and would not move again.  I unplugged the USB and tried again, same thing.  I repeated that two more times.

So I don't know if I'm still getting corruption at 19200 that happens to always happen after about a second (seems unlikely), or if there's something wrong with how the Teensy handles 19200.  I also noticed in serial mode that if I set the terminal to 19200 right from the start and connect to the Teensy,  Teensy does not respond with "19200" and I can't send any commands.  If I set the terminal to 38400 right from the start I get the "38400" response from Teensy, so it's handling it differently somehow.

Also, I was looking at the Linux source here (http://wacom-tools.sourcearchive.com/documentation/0.8.0.2/wcmSerial_8c-source.html) and found this function:

static int serialSetLinkSpeedIntuos(LocalDevicePtr local)
{
      WacomCommonPtr common = ((WacomDevicePtr)(local->private))->common;

      if ((common->wcmLinkSpeed == 38400) &&
            (common->wcmVersion < 2.0F))
      {
            ErrorF("Wacom: 38400 speed not supported with this Intuos "
                  "firmware (%f)\n", common->wcmVersion);
            ErrorF("Switching to 19200\n");
            common->wcmLinkSpeed = 19200;
      }
      return serialSetLinkSpeedProtocol5(local);
}

So apparently there are Intuos models with firmware < 2.0F that don't support 38400.  Since my response to ~# is GD-1218-R00,V1.2-7 I'm guessing that means I have firmware 1.2-7.  The next function shows that ProtocolV will also work at 19200:

static int serialSetLinkSpeedProtocol5(LocalDevicePtr local)
{
      int err;
      char* speed_init_string;
      WacomDevicePtr priv = (WacomDevicePtr)local->private;
      WacomCommonPtr common = priv->common;

      DBG(1, priv->debugLevel, ErrorF("Switching serial link to %d\n",
            common->wcmLinkSpeed));

      /* set init string according to speed */
      speed_init_string = (common->wcmLinkSpeed == 38400) ?
            WC_V_38400 : WC_V_19200;

      /* Switch the tablet to the requested speed */
      err = xf86WcmWrite(local->fd, speed_init_string,
            strlen(speed_init_string));

      if (err == -1)
      {
            ErrorF("Wacom xf86WcmWrite error : %s\n", strerror(errno));
            return !Success;
      }

      /* Wait 75 mSecs */
      if (xf86WcmWait(75))
            return !Success;

      /* Set speed of serial link to requested speed */
      if (xf86WcmSetSerialSpeed(local->fd, common->wcmLinkSpeed) < 0)
            return !Success;

      return Success;
}


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 15, 2011, 09:06:54 PM
I tried the standard driver at 19200 again and it actually never behaves "normally" with the mouse.  I put the mouse somewhere near the middle and move it around and after awhile (sometimes immediately, sometimes after a few seconds of moving) the cursor jumps to the top of the screen about 50 pixels from the left side.  The cursor remains stuck there until I move it using the regular mouse, then it will jump back to the same point randomly as I move the pen.

Sometimes it jumps to somewhere along the bottom edge of the screen (can't tell exactly where since only one pixel of the cursor is visible, but the taskbar opens).

I captured a log with hid_listener using a driver set to 19200.  Notice at the end it says there's an out of range packet.  Maybe Teensy is hard coded to use Protocol 4 with 19200 or something?  Can you tell if anything in this log is corrupted?  This is just the end of the log.

*(?!)9Eå
*(?!)86?1Eÿ
*(?!)98?18f66`60ÿ
*(?!)9800Ç
*(?!)80Ç
*(?!)80ÿ
*(?!)98Ç
*(?!)8000P
*(?!)9Eå
*(?!)8600ÿ
*(?!)98ÿ
*(?!)98?18`60å
*(?!)86?1E~7Eÿ
*(?!)98Ç
*(?!)8000P
*(?!)9Eå
*(?!)86µ
*(?!)E6ÿ
*(?!)98?18¦
*(?!)FE`60?1800x78ÿ
*(?!)98Ç
*(?!)8000P
*(?!)9Eå
*(?!)86å
*(?!)86ÿ
*(?!)98å
*(?!)86ÿ
*(?!)9800?18?1800x78ÿ
*(?!)98Ç
*(?!)8000P
*(?!)9Eå
*(?!)86f66f66ÿ
*(?!)98?18?18å
*(?!)86`60x78ÿ
*(?!)98Ç
*(?!)8000P
*(?!)9Eå
*(?!)86?18f66ÿ
*(?!)98¦
*(?!)FE`60P
*(?!)9E?1E~7Eÿ
*(?!)98Ç
*(?!)8000P
*(?!)9Eå
*(?!)86¦
*(?!)FEP
*(?!)9Eå
*(?!)86Ç
*(?!)80¦
*(?!)FE`60?0600Ç
*(?!)80Ç
*(?!)80ÿ
*(?!)98Ç
*(?!)8000P
*(?!)9Eå
*(?!)86å
*(?!)86f66ÿ
*(?!)98°
*(?!)F8`60`60Ç
*(?!)80Ç
*(?!)80ÿ
*(?!)98Ç
*(?!)8000a
*(?!)E0å
*(?!)86?06å
*(?!)86å
*(?!)86°
*(?!)F8`60?1Eå
*(?!)86Ç
*(?!)80ÿ
*(?!)98Ç
*(?!)8000a
*(?!)E0å
*(?!)86f66å
*(?!)86ÿ
*(?!)98°
*(?!)F8`60ÿ
*(?!)98?1Eÿ
*(?!)98Ç
*(?!)80ÿ
*(?!)98Ç
*(?!)8000a
*(?!)E0å
*(?!)86~7Eå
*(?!)86P
*(?!)9Ea
*(?!)E0`60µ
*(?!)E600P
*(?!)9EÇ
*(?!)80P
*(?!)9EÇ
*(?!)8000a
*(?!)E0å
*(?!)86µ
*(?!)E6Ç
*(?!)80å
*(?!)86P
*(?!)9Ea
*(?!)E0`60µ
*(?!)E600µ
*(?!)E6Ç
*(?!)80P
*(?!)9EÇ
*(?!)8000a
*(?!)E0å
*(?!)8600`60?18a
*(?!)E0`60?1800°
*(?!)F8Ç
*(?!)80a
*(?!)E0Ç
*(?!)8000a
*(?!)E0å
*(?!)86å
*(?!)86`60ÿ
*(?!)98?18`60µ
*(?!)E600°
*(?!)F8Ç
*(?!)80a
*(?!)E0Ç
*(?!)8000a
*(?!)E0å
*(?!)86?18ÿ
*(?!)98?18µ
*(?!)E6?1E00?0600°
*(?!)F8Ç
*(?!)80µ
*(?!)E6Ç
*(?!)8000a
*(?!)E0å
*(?!)86°
*(?!)F8å
*(?!)86å
*(?!)86Ç
*(?!)80ÿ
*(?!)98`60µ
*(?!)E600°
*(?!)F8Ç
*(?!)80µ
*(?!)E6Ç
*(?!)8000a
*(?!)E0å
*(?!)86¦
*(?!)FEÿ
*(?!)98?18Ç
*(?!)80`60µ
*(?!)E600µ
*(?!)E6Ç
*(?!)80µ
*(?!)E6Ç
*(?!)8000a
*(?!)E0å
*(?!)86f66f66?18?06`60å
*(?!)86`60µ
*(?!)E6Ç
*(?!)80µ
*(?!)E6Ç
*(?!)8000a
*(?!)E0å
*(?!)86Ç
*(?!)80P
*(?!)9Eå
*(?!)86Ç
*(?!)80x78`60å
*(?!)86?1EP
*(?!)9EÇ
*(?!)80°
*(?!)F8Ç
*(?!)8000a
*(?!)E0å
*(?!)86¦
*(?!)FEf66P
*(?!)9E`60`60µ
*(?!)E600å
*(?!)86Ç
*(?!)80¦
*(?!)FEÇ
*(?!)8000µ
*(?!)E6å
*(?!)8600`60?18?18`60?0600~7E

(*!)
a
*E000µ
*(?!)E6å
*(?!)86`60ÿ
*(?!)98ÿ
*(?!)98?06`60µ
*(?!)E600f6600`60µ
*(?!)E6å
*(?!)86°
*(?!)F8å
*(?!)86å
*(?!)86P
*(?!)9E¦
*(?!)FEÇ
*(?!)80Ç
*(?!)80f6600?18?06`60µ
*(?!)E6å
*(?!)86f66f66å
*(?!)86°
*(?!)F8Ç
*(?!)8000?1E?18?06`60µ
*(?!)E6å
*(?!)86a
*(?!)E0f66?18a
*(?!)E0Ç
*(?!)8000`60µ
*(?!)E6µ
*(?!)E6?1800µ
*(?!)E6å
*(?!)86?06f66Ç
*(?!)80å
*(?!)86Ç
*(?!)8000µ
*(?!)E600P
*(?!)9Eµ
*(?!)E6?1800°
*(?!)F8å
*(?!)86x78å
*(?!)86P
*(?!)9Ex7800?0600P
*(?!)9Eµ
*(?!)E6?1800°
*(?!)F8å
*(?!)86µ
*(?!)E6`60ÿ
*(?!)98µ
*(?!)E600Ç
*(?!)80P
*(?!)9E?1EP
*(?!)9Eå
*(?!)86?0600°
*(?!)F8å
*(?!)86?06ÿ
*(?!)98?18?06Ç
*(?!)80å
*(?!)86`60P
*(?!)9Eµ
*(?!)E6?0600°
*(?!)F8å
*(?!)86µ
*(?!)E6?18ÿ
*(?!)98a
*(?!)E0?06ÿ
*(?!)9800~7Ef66?0600°
*(?!)F8å
*(?!)86ÿ
*(?!)98ÿ
*(?!)98Ç
*(?!)80P
*(?!)9E~7E?06?0600å
*(?!)86f66a
*(?!)E000?1Eå
*(?!)8600f66Ç
*(?!)80`60?06`6000ÿ
*(?!)98µ
*(?!)E6Ç
*(?!)8000?1Eå
*(?!)86ÿ
*(?!)98f66å
*(?!)86?18?06?1800ÿ
*(?!)98µ
*(?!)E6Ç
*(?!)8000?1Eå
*(?!)86?06?06P
*(?!)9E°
*(?!)F8P
*(?!)9EÇ
*(?!)80f6600ÿ
*(?!)98µ
*(?!)E6Ç
*(?!)8000?1Eå
*(?!)86?1E?06å
*(?!)86ÿ
*(?!)98P
*(?!)9EÇ
*(?!)80f6600ÿ
*(?!)98µ
*(?!)E6Ç
*(?!)8000?1Eå
*(?!)86?1E?06ÿ
*(?!)98Ç
*(?!)80P
*(?!)9E00`60ÿ
*(?!)98µ
*(?!)E6Ç
*(?!)8000?1Eå
*(?!)86Ç
*(?!)80P
*(?!)9EÇ
*(?!)80ÿ
*(?!)98?1E?06?0600ÿ
*(?!)98µ
*(?!)E6Ç
*(?!)800000000000000000
[USB Packet - Out of range packet (all zeros)]
proxOutTrigger()

(*!)


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 15, 2011, 09:13:53 PM
Seeing *(?!) is wrong to start with. So ALL is corrupted. *(?!) means the decoder is hitting an invalid case.


the protocol5 code is hard-coded to do the following:


        /**
         * BA38: set port speed to 38400,
         * IT0: set max reporting speed.
         * MT0: disable multimode (in case this was enabled)
         * ID1: dunno what it does.
         */
        void enableFeatures()
        {
                serial::sendString("MT0\rIT0\rID1\rBA38\r");
        }

if the BA38 command is not recognized by the tablet that would mean that your board will still stay at 9600 baud -- right?  (you have to try it out with the serial driver).  That would mean you would need to set the "Normal" Baud Rate to 9600 (not 19200). 



Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 15, 2011, 09:23:20 PM
..so that means WaxBee has a bug for the baud rate of older GD-XXX boards.   I can make a similar fix but annoyingly the baud setting is in the template file not in code. And I do not want to have different templates for different boards (difficult to know your GD board version). It would be nice that it auto-detects it.  mmmm.  Maybe I could have a new baud rate option for the "Normal" baud rate named something like "Intuos1 auto-detect".  If I do that and make a new version, I might throw in a new tablet string initialization option.



Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 15, 2011, 10:17:21 PM
You could also make it check if the config file is set to 19200 then send BA19 instead of BA38.  But it seems like having auto detect be the default would make the most sense since that's what the linux driver does (at least based on the two functions I looked at, which isn't much).  Having the option to force particular baud rates is mostly useful for testing, or if someone messes up their board somehow so it can't support the higher speed.

Yes, the standard Teensy firmware works with the Wacom driver when set to 9600 baud but not 19200 or 38400.  I would guess the corruption with firmware set to 19200 isn't true corruption but happens because the port speed is set to 19200 but the tablet ignores the hard coded BA38 and sends data at 9600.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 16, 2011, 03:14:59 AM
So my question is now: does it work when you set the normal speed to 9600 bauds?    ---  I just read in another thread that it worked.

And do you have menu strip working or not?  If not, then I would disable it in the templates by default (by putting MIN Y to 1200 instead of 0).  Well, your suggestion of sending a BA19 is way quicker to implement. I think I'll do that instead.  Just too bad it won't be "easy" to know to put 19200 bauds when your board is "old".  Is there a sticker on the board that would hint at the ROM version?  So we could write in the tutorial to look at the sticker to see if it is above or below 2.0? 


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 16, 2011, 04:09:50 AM
Quote
So my question is now: does it work when you set the normal speed to 9600 bauds?

Yeah, it works at 9600.  That's what I meant when I said "Yes, the standard Teensy firmware works with the Wacom driver when set to 9600 baud but not 19200 or 38400."

The menu does seem to work but I didn't test it carefully.  I noticed that when I move the mouse over the menu area the mouse changes to the little grey "1", "3", etc shape, but when I click the menu I didn't see anything happen.  Also, I couldn't get the "2" to appear when hovering over menu number 2.  So I'll have to do more testing.

I don't see anything on the back that indicates the firmware version but maybe the -R00 at the end of the serial number indicates something...  I've attached a picture of the label.

[attachment=1]


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 16, 2011, 04:21:22 AM
On Ultrapads, you had a sticker on the EEPROM chip on the PCB that had the firmware version.  Anyways. I think there is none in more recent models.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 16, 2011, 04:50:16 AM
I tested that all the menu buttons work when pressed in the center of the button.  Woot!  The only weird thing I noticed is with the grey rectangle icons I mentioned.  I can't get the grey rectangle with the "2" in it to appear no matter where I place the pen, but clicking menu 2 still works.  The grey rectangle with the "1" only appears when the pen is held at least 3/5ths of the way across the menu from the right edge of the area and about 1/10th up from the bottom, yet the 1 menu activates when the pen is clicked at least 1mm from the right of the menu area.  Menu 3 and 4 show the grey "3" and "4" starting at the exact edges of the menu (actually, the area might be offset to the left by under 1mm).  Menus 5 and above seem to show they grey numbers at the appropriate edges, but I didn't test them extensively.

As for the firmware, there is something that looks kinda eprom-ish with a white sticker that says "0130003" but who knows what that means (Jan 30 2003?).  There's a picture of my whole PCB in the first post if you want to look at it.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 16, 2011, 05:05:44 AM
Two other glitches:

The Intuos 1 mouse is not recognized at all.  It doesn't even show up as a tool in the Wacom control panel.  I think you mentioned in another thread this wasn't implemented because you don't know the tool ID for the Intuos 2 mouse...  Damn.  I think you also mentioned that the linux drivers list the Intuos 2 mouse tool id, but only part of it.  I was thinking that maybe that part of it is always the same and the rest of the number varies by the individual tool for use in distinguishing different tools of the same type?  Like how it recognizes two different but identical model number pens.

EDIT: That made me think of testing a second Intuos1 pen with the tablet.  It is not recognized as a second pen and behaves exactly like the first pen.  So you aren't passing through the unique part of the pen ids through the driver.

If you have the Wacom control panel open and you unplug the tablet and plug it back in, the Tool and Applications rows go blank and if you click things the control panel tends to crash.  Like I had the "Functions" dialog open when that happened and when I closed the Functions dialog, it crashed.  Not really a big deal but figured you should know.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 16, 2011, 07:41:32 AM
Is the mouse really that important?  Did you ever used a mouse with a wacom product before? I had a Graphire3 with a mouse.  The problem is that you have to move your mouse following the X axis of the tablet to move the mouse horizontally.  If my hand is in diagonal and I move the mouse sideways, the mouse will go in diagonal on the screen!!  Simply impossible to use.  In other words, it does not look at the "rotation" of the mouse -- where it is pointing at and do the "math" to compensate. (maybe this is different with the GD because the tablet knows about the mouse Z-rotation?) -- From my limited mouse experience, it just makes the mouse totally unusable!!!   So I am not bothering too much with it -- unless someone tells me it would be really interesting and they really use it.

The list of tool ids (or full serial number) -- is quite large. (just look at the linux driver)

One thing I tried doing in the code is to simply make the mouse act appear as a stylus -- but I am not sure if this is broken or not currently. I guess this is broken (?).  The issue with this is that you could not configure the mouse differently than the pen in the control panel and supporting all the buttons on the mouse might not work either. (since a stylus only has 2 side switches).

Second pen?  What do you mean?  The dual-tracking feature? AFAIK, GD boards do not support dual-track (two devices simultaneously being moved on the tablet). I think only Intuos2 boards does that.  (Intuos3 and 4 does not do it either).  Either way, the tool id would be the same if you have twice the same pen model.  Internally it is some sort of "parallel channel". I do not support simultaneously dual-tracking pens. (simply because this is yet another feature that is not popular -- even Wacom dropped it).  The Eraser has a different tool id (you know that the eraser is actually a separate, independent pen that is just at the other end of your pen -- with its own coil and circuit).  (at least this was true for the Ultrapads, it was two separate boards). They still appear as different devices.

Having two different pens with different serial numbers (a black one and a grey one for example) I think would allow for different settings for each (pressure, relative/absolute, button assignments, etc.)  So you know that when you use the black one, it is configured to do xyz stuff which would be different with the "grey" one.

The tool id in the linux driver is a shortened portion of the serial number (I think it takes a couple of sections of the bigger number). Yeah, maybe there is a variable part to that serial number (but I doubt it).  I think the linux driver did this to come up with unique values that fits in an integral type easily "switch-able" in the source code (for speed).

You can see the serial number in the diagnostic panel. If anyone has a real USB intuos2 with a tool, he could just go to that About -> Diagnostic panel, put the tool on the tablet and copy the serial number appearing there.  It would be awesome.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 16, 2011, 07:55:55 AM
I don't use the mouse either, although I used to WANT to use it with 3D Studio Max because it has five buttons and I wanted to map the extra buttons to rotate and zoom the 3d model...  except the Wacom drivers were so limited in how you could configure those buttons that it wouldn't work.  I asked them to add some simple thing like the ability to make the button hold down control or alt and they never did it.  So I ended up writing a 3ds max plugin that made it work, but it was kind of glitchy.

Anyway, the main reason I want mouse support is so when I sell the tablet I can say it works like a stock USB Intuos 1 and since I'm selling it with the mouse, it only makes sense to make it support the mouse.  But maybe I'll work on adding that functionality myself when I have time.  And no, the mouse does not work at all with Waxbee.  It doesn't move the cursor or show up as a tool or recognize button clicks.

What I mean with using multiple pens is not to use them at the same time, but to have them show up as multiple tools in the Wacom control panel, and each tool remembers separate settings.  Each pen has its own internal ID unique among all pens Wacom produced and normally each pen will show up as a separate tool in the Wacom control panel.  Then you can do things like set one pen to be a brush in Photoshop, another to be an airbrush, and so on... at least I think you can do that.  Again, not a feature I personally use (although it sounds like something I might use if I were doing serious art), but something that would be good when claiming to have the same functionality as a standard USB tablet.

I do have two Intuos1 pens and two Intuos1 mice so if there's a way to get their serial through Waxbee we could see if there's a variable part to the serial.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 16, 2011, 08:28:59 AM
Flash the debug template, run HID Listen and see what it outputs, it is supposed to output a "tool id" that is close to the Linux driver.  What numbers you see appear? This serial number is sent when the pen/mouse comes "in proximity".

Code:
uint16_t toolid = (((uint16_t)buffer[1] & 0x7f) << 5) |
(((uint16_t)buffer[2] & 0x7c) >> 2);

/*
uint32_t serial = (((uint32_t)buffer[2] & 0x03) << 30) |
(((uint32_t)buffer[3] & 0x7f) << 23) |
(((uint32_t)buffer[4] & 0x7f) << 16) |
(((uint32_t)buffer[5] & 0x7f) <<  9) |
(((uint32_t)buffer[6] & 0x7f) <<  2) |
(((uint32_t)buffer[7] & 0x60) >>  5);
*/
console::printHex(toolid, 8);

eraser_mode = 0;

switch (toolid)
{
case 0x007: // 2D Mouse
case 0x09C: // ?? Mouse
case 0x094: // 4D Mouse
case 0x096: // Lens cursor
penEvent.is_mouse = 1;
break;

case 0x812: // Intuos2 ink pen XP-110-00A
case 0x012: // Inking pen
case 0x822: // Intuos Pen GP-300E-01H
case 0x852: // Intuos2 Grip Pen XP-501E-00A
case 0x842: // added from Cheng
case 0x022:
case 0x832: // Intuos2 stroke pen XP-120-00A
case 0x032: // Stroke pen

case 0x112: // Airbrush
default: // Unknown tool
penEvent.is_mouse = 0;
break;

case 0x82a:
case 0x85a:
case 0x91a:
case 0x0fa: // Eraser
eraser_mode = 1;
break;
}


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 16, 2011, 09:01:06 PM
I've attached a log of all my tools.  I first touched a pen in the center of the tablet, then a different pen, then a mouse, then a different mouse.

I see two locations for the 0822 pen tool type:

Serial Tablet - GD-1218-R00,V1.2-7
Intuos
¬
*C2A41080010 0C7F03000
0822

*A0)29%2508A41838000000
[USB Packet - In Range packet, eraser=0]


*E0)29!21(28@40h6804y7907

and

¬
*C2A41
0A1311014   09`6000
0822

*A0*2AT5407p70h68000000
[USB Packet - In Range packet, eraser=0]


*E0*2AR5207q710300407y79

I'm guessing that the number immediately before the tool type is the unique id, but I should have placed the two pens down again to see which number stayed the same...

The mice are seen as tool type 0094:

¬
*C204R52232`60017370000
0094
®
*A8/2F-2Dh68v76x78000000


*AA/2F-2Dh68v76x78000000

®
*A8/2F434h68v76030000000


and


¬
*C204R52232 2003~7E`6000
0094
®
*A8+2B/2F   09@40x78000000


*AA+2B/2F   09@40x78000000

®
*A8+2B535)29A41h68000000

PS, waxbee also works fine with the Wacom driver on Win7 64bit.  =)


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 16, 2011, 11:16:27 PM
I see in the traces that the mouse does not have a "USB Packet Range eraser=0" message  which means not much is being sent.

I suspect that the following line serial_protocol5.cpp is the culprit, but not sure.  We would need to carefully look at the mouse-generated packets.   I see a lot of A0 for the pen and AA/A8 for the mouse which might be why it is not even behaving like a mouse.


else if (((buffer[0] & 0xB8) == 0xA0) || ((buffer[0] & 0xBE) == 0xB4))


The tool id -- btw-- is for both intuos1 and intuos2.  That makes me think that *maybe* that serial number is compatible ?  Maybe I could just send the original serial number across up to the USB???


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 17, 2011, 02:37:54 AM
Wouldn't hurt to try passing the unique ID through.  The idea is just to identify each pen, not necessarily to send through a serial that would actually belong to an Intuos2 pen.  As long as the serials are the same length, I doubt it matters what value you send as long as each pen has a unique value.

It looks like the mouse packets are totally different than pen packets.  From http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37/plain/drivers/input/tablet/wacom_wac.c:

/* 4D mouse, 2D mouse, marker pen rotation, tilt mouse, or Lens cursor packets */
   if ((data[1] & 0xbc) == 0xa8 || (data[1] & 0xbe) == 0xb0 || (data[1] & 0xbc) == 0xac) {

      if (data[1] & 0x02) {
         /* Rotation packet */
         if (features->type >= INTUOS3S) {
            /* I3 marker pen rotation */
            t = (data[6] << 3) | ((data[7] >> 5) & 7);
            t = (data[7] & 0x20) ? ((t > 900) ? ((t-1) / 2 - 1350) :
               ((t-1) / 2 + 450)) : (450 - t / 2) ;
            input_report_abs(input, ABS_Z, t);
         } else {
            /* 4D mouse rotation packet */
            t = (data[6] << 3) | ((data[7] >> 5) & 7);
            input_report_abs(input, ABS_RZ, (data[7] & 0x20) ?
               ((t - 1) / 2) : -t / 2);
         }

      } else if (!(data[1] & 0x10) && features->type < INTUOS3S) {
         /* 4D mouse packet */
         input_report_key(input, BTN_LEFT,   data[8] & 0x01);
         input_report_key(input, BTN_MIDDLE, data[8] & 0x02);
         input_report_key(input, BTN_RIGHT,  data[8] & 0x04);

         input_report_key(input, BTN_SIDE,   data[8] & 0x20);
         input_report_key(input, BTN_EXTRA,  data[8] & 0x10);
         t = (data[6] << 2) | ((data[7] >> 6) & 3);
         input_report_abs(input, ABS_THROTTLE, (data[8] & 0x08) ? -t : t);

      } else if (wacom->tool[idx] == BTN_TOOL_MOUSE) {
         /* I4 mouse */
         if (features->type >= INTUOS4S && features->type <= INTUOS4L) {
            input_report_key(input, BTN_LEFT,   data[6] & 0x01);
            input_report_key(input, BTN_MIDDLE, data[6] & 0x02);
            input_report_key(input, BTN_RIGHT,  data[6] & 0x04);
            input_report_rel(input, REL_WHEEL, ((data[7] & 0x80) >> 7)
                   - ((data[7] & 0x40) >> 6));
            input_report_key(input, BTN_SIDE,   data[6] & 0x08);
            input_report_key(input, BTN_EXTRA,  data[6] & 0x10);

            input_report_abs(input, ABS_TILT_X,
               ((data[7] << 1) & 0x7e) | (data[8] >> 7));
            input_report_abs(input, ABS_TILT_Y, data[8] & 0x7f);
         } else {
            /* 2D mouse packet */
            input_report_key(input, BTN_LEFT,   data[8] & 0x04);
            input_report_key(input, BTN_MIDDLE, data[8] & 0x08);
            input_report_key(input, BTN_RIGHT,  data[8] & 0x10);
            input_report_rel(input, REL_WHEEL, (data[8] & 0x01)
                   - ((data[8] & 0x02) >> 1));

            /* I3 2D mouse side buttons */
            if (features->type >= INTUOS3S && features->type <= INTUOS3L) {
               input_report_key(input, BTN_SIDE,   data[8] & 0x40);
               input_report_key(input, BTN_EXTRA,  data[8] & 0x20);
            }
         }
      } else if ((features->type < INTUOS3S || features->type == INTUOS3L ||
            features->type == INTUOS4L) &&
            wacom->tool[idx] == BTN_TOOL_LENS) {
         /* Lens cursor packets */
         input_report_key(input, BTN_LEFT,   data[8] & 0x01);
         input_report_key(input, BTN_MIDDLE, data[8] & 0x02);
         input_report_key(input, BTN_RIGHT,  data[8] & 0x04);
         input_report_key(input, BTN_SIDE,   data[8] & 0x10);
         input_report_key(input, BTN_EXTRA,  data[8] & 0x08);
      }


They also handle extra info relating to airbrush:

   /* airbrush second packet */
   if ((data[1] & 0xbc) == 0xb4) {
      input_report_abs(input, ABS_WHEEL,
            (data[6] << 2) | ((data[7] >> 6) & 3));
      input_report_abs(input, ABS_TILT_X,
            ((data[7] << 1) & 0x7e) | (data[8] >> 7));
      input_report_abs(input, ABS_TILT_Y, data[8] & 0x7f);
   }


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 17, 2011, 04:00:18 AM
The code you are showing is the USB packets parsing or the serial packet parsing? I think it is the USB one (but not sure).

Passing down the entire unique ID will work in terms of unicity. I have a TODO in the code to do just that actually.  But I think it still has to be recognized by the Wacom driver to enable the specific tool-related features, no?  Would need to try it out actually. To pass down the serial id, we have to introduce the concept of a serial/tool id in the centralized "pen_event" structure and pen_event "sequence". Since this is centralized, we need to make it work for all combinations of tablets. Lots of tablets (like the ultrapads, ISDV4 penenabled and Topaz) do not have such concepts. And BTW, because of that, I always "loose" the first packet with coordinates with UltraPads (because I use the first packet "event" to send the tool id instead of sending the first coordinates). In older tablets, the first packet contains coordinates.

I do not have the list of IDs for neither tablets (what will happen when we emulate a Bamboo, an intuos4 or a Cintiq eventually?) the best would be to "map" valid numbers from the old series to the newer series.  So potentially we could have some sort of internal "tool ids" (+ keep the original serial number around if any) and depending on the tablets either generate a generic serial id for mapping the internal tool id or, if that works, pass on the original id.

Most of the people I have encountered only have the stylus and for those that have a mouse, it was just collecting dust. Nobody had an airbrush and one had a "lens cursor" I think (on an Ultrapad), which works like a pen in that case (if I recall correctly).

So, yeah, WaxBee is certainly not complete and misses a lot of features (that is why the version number does not start with "1" yet) :). Especially when talking about stuff that only a few people use (like airbrushes). There is a huge difference between making software "functional" vs. completing it. It's the 80/20 rule: it takes 80% of the time to do the last 20% of the work.

But you can help by finding a working serial id for your mouse, and there is a way to try it out using the "debug" field at the bottom of the configuration.

First, this is my "own" spec that I use for talking like an intuos2. The red packet are the ones containing the serial id. Do you think you could come up with a packet for a mouse?

Code:
// USB Protocol V (5)
//
// Data gleaned for the Intuos2
// Button 0 = side switch near the tip (not working with eraser)
// Button 1 = side switch away from the tip (not working with eraser)
//
// [color=red]02 C2 85 20 16 00 2C D0 00 00[/color]   In Range: NORMAL PEN
// [color=red]02 C2 85 A0 16 00 2C D0 00 00[/color]   In Range: ERASER (PEN)
//
// 02 A0 91 06 66 9F 00 20 40 B8   Pen Data (see below)
// ...
// ...
//
// 02 80 00 00 00 00 00 00 00 00   Out of range
//
//
// Pen Data: 02 A0 91 06 66 9F 00 20 40 B8
//
// [0] 02  HID report identifier (02)
// [1] A0  1 1 p 0  0 b c i   p = prox, b = button1, c = button0, i = index
// [2] 91  x x x x  x x x x   x pos
// [3] 06  x x x x  x x x x
// [4] 66  y y y y  y y y y   y pos
// [5] 9F  y y y y  y y y y
// [6] 00  p p p p  p p p p   pressure (1024)
// [7] 20  p p t t  t t t t   t = tiltx - 0 = -60 degrees, 40 = 0, 7F = +60 degrees
// [8] 40  t u u u  u u u u   u = tilty - 0 = -60 degrees, 40 = 0, 7F = +60 degrees
// [9] B8  d d d d  d 0 0 0   d = sensor z distance 0x26..0x0D
//
// touch = pressure > 10
//


BTW, the "debug" data can be used to try out things. You essentially encode the USB HID reports yourself and and dump it there. Not that difficult actually. Probably 3 packets would be enough (or duplicate packet blocks to make the tool stay in proximity for a longer time. This is to see if the wacom driver recognizes it (using the About->Diagnostic panel  -- you see the serial number in there btw).

Check out the template that has a  "+ playback" in the name. I copied the relevant piece here:


# Multi-purpose internal debug data. To be left empty for normal operation.#
DEBUG_DATA = @[
0x1,      # debug type = 1 (USB endpoint packets playback)
0x1,      # trig on "1=Prox out" (0=powerup)
0x1,      # endpoint 1
0xa,      # 10 seconds to wait before starting
0x3,      # repeat sequence 3 times
0xa,      # 10 ms between packets (in 10 ms increments)
0xa,      # packet size (data of that size follows, up to the end of the binary field)
0x2,0xc2,0x85,0x20,0x16,0x0,0x2c,0xd0,0x0,0x0,      #
0x2,0xe0,0x1c,0x2d,0x48,0x29,0x0,0x27,0x43,0x68,      #
0x2,0xe0,0x1c,0x54,0x48,0x20,0x0,0x27,0x43,0x68,      #
0x2,0xe0,0x1c,0x7e,0x48,0x23,0x0,0x27,0x42,0x68,      #
0x2,0xe0,0x1c,0xab,0x48,0x2b,0x6,0x27,0xc3,0x68,      #
0x2,0xe0,0x1c,0xab,0x48,0x42,0x9,0x28,0x43,0x68,      #
0x2,0xe0,0x1c,0x9f,0x48,0x58,0x8,0x28,0x43,0x68,      #
0x2,0xe0,0x1c,0x75,0x48,0x50,0x34,0x28,0x43,0x68,      #
0x2,0xe0,0x1c,0x53,0x48,0x4b,0xb8,0xaa,0x43,0x68      #
0x2,0x80,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0      #   // tool out of proximity


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 17, 2011, 04:46:47 AM
I was thinking about doing some development on waxbee myself, but based on this post (http://forum.bongofish.co.uk/index.php?topic=1934.msg14426) it sounds like you've got a complicated development environment that you don't remember how to replicate...

Have you ever used VirtualBox?  If you're willing, you could make a Clonezilla copy of your development machine, use Clonezilla again to extract the cloned drive to a VirtualBox machine, and then in the virtual machine, delete/uninstall any personal information/programs you've got and send the virtual machine to whoever you want to use as a development environment.  Once space is freed up, I could shrink the hard drive of the virtual machine or send you instructions on how to do that too.  Send me an email if you're interested in details of all this.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 17, 2011, 05:23:35 AM
I am sorry but this cloning thing appears to be too much work for the little time I have. My "development machine" is really big and full of other stuff. Besides it is not *that* complicated. Also you do not need to use the same tools as well!!  I use Eclipse CDT running on top of the AVR GNU tool chain -- the tool chain was "installed" for me by the WinAVR installer. Someone already made the bridge with Eclipse CDT. The "complex" part was to tweak the Eclipse so it works the way *I* like it. Really, you do not need that. Actually you do not need Eclipse at all. Just use WinAVR (like a lot of people are using) -- I am just more comfortable with all the little features built-in Eclipse and have my java project (WaxBee) within the same IDE.

If you want to go down the Eclipse path, then I can duplicate the relevant subdirectories. (Eclipse is just an exploded "zipped" file, there is no such thing as an Eclipse install program so there is nothing stored in the Windows registry or other external hacks like that. I can have 20 Eclipse installations side by side and they will not even know about each other).

Really, WinAVR (and its install program) is the tool that do all the hard work (setting up the AVR GNU Tool Chain).  I would suggest that try to make it work. I have the gcc/g++/linker command line options that I use. Also you do not need to build all the little tools and the build the native dlls (but you could as well to support Linux!). You essentially probably only need to build the AVR project and potentially the Java WaxBee tool(s).

Don't get the wrong message, I am very positive about this and helping you out. If you make it work with WinAVR or with some other way, well this is a very good thing for the project and to attract developers to give a hand. "Streamlining" a development environment was on the TODO list like any other feature. It needs to be done. I had to pick my battles. Last time I seriously worked on WaxBee was to create a "button system" (which is not finished btw). Once you have something working, we can commit the supporting files and document the procedure in the wiki or in a text file. :)



Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 17, 2011, 11:52:28 PM
On the checkout page (http://code.google.com/p/waxbee/source/checkout) it says to type this:
svn checkout http://waxbee.googlecode.com/svn/trunk/ waxbee-read-only

but that results in an error: "svn: URL 'http://waxbee.googlecode.com/svn/trunk' doesn't exist"

This works:
svn checkout http://waxbee.googlecode.com/svn/ waxbee-read-only

So what's next?  I assume I want to compile \waxbee-read-only\WaxB_Adb2Usb but there's no makefile.  I see .project and .cproject files for Eclipse and .cproject has a wide variety of gcc and g++ command lines embedded in it... but which to use?


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 18, 2011, 04:29:11 AM
yes, you would want to generate .hex file out of the WaxB_Adb2Usb project.

Options for the different tools:

avg-g++ : (for .cpp files)
  
-Wall -O3 -fpack-struct -fshort-enums -funsigned-char -funsigned-bitfields -fno-exceptions -mmcu=atmega32u4 -DF_CPU=16000000UL
  
avr-gcc : (for .c files)
  
-Wall -O3 -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega32u4 -DF_CPU=16000000UL

The "linker" options (-Wl,x,x,x,x)

-Wl,-Map,WaxB_Adb2Usb.map,--cref -mmcu=atmega32u4

...
Then the resulting .hex file must be in a directory which is on the java classpath when running the WaxBee config java tool. (or replace the .hex file at the same location in the most recent binary waxbee-xx.jar distribution file).


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 18, 2011, 07:20:21 AM
Thanks for the compiler options!  With a little research I found the "Mfile" tool that comes with AVR and used that to generate a Makefile.  After a little tweaking to make it match your command line options I got a hex file built and shoved it into waxbee.jar with this command:

...\waxbee>jar -ufv waxbee.jar -C ...\waxbee\source\waxbee-read-only\WaxB_Adb2Usb WaxB_Adb2Usb.hex
adding: WaxB_Adb2Usb.hex(in = 67412) (out= 23640)(deflated 64%)

Ran waxbee.jar and had it generate another .hex file (oddly, my final hex turns out to be 70kb but before putting my hex into the jar, the final hex files were 78kb).  Flashed the hex file to Teensy and it works!  Huzaah!

I've attached the Makefile I use in case anyone else wants to compile it.  All I had to do was install Win-AVR from here (http://winavr.sourceforge.net/download.html), leave default install options like "Add to PATH".
Get the source code with "svn checkout http://waxbee.googlecode.com/svn/ waxbee-read-only"  I actually had svn installed on my Mac (it might come preinstalled since I don't remember installing it) so I ran the command from there, but on PC you can download TortoiseSVN or various other similar tools.
Put the Makefile from this post in ...\waxbee-read-only\WaxB_Adb2Usb
Open a command prompt
cd ...\waxbee-read-only\WaxB_Adb2Usb
make

Well, it won't let me attach a file of "Makefile" type, so you can download the file here (http://www.dracoventions.com/products/2empowerFM/download/Waxbee/Makefile).  I can't paste the Makefile into this post because little things like having tab characters instead of spaces are actually important (which is stupid but these files were probably invented before the concept of copy and paste).  So be sure to right click the link above and choose "Save as..." instead of viewing it and copying.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 18, 2011, 07:52:41 AM
Awesome!  Makefile committed.  8)

Also added a comment on the project page pointing back to this thread.  (we can update later with something better not relying on bongofish servers and people reading the whole thread)

So you only need to checkout the source from SVN and you will have the Makefile readily available.

I see that the list of C/CPP files is "hardcoded" in the Makefile.  I wonder if we could just put *.cpp? -- (that would be awesome since I would not need to update the Makefile each time I add/remove/rename C/CPP source files).



Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 18, 2011, 07:56:57 AM
I found a XC-100 (intuos2) mouse in my basement!  Yay!  I did not think I had one of those, but I actually do!  When I get a chance, I will hook up a USB intuos2 to my machine, run a usb tracer utility and dump the mouse-related packets. But probably this will not happen before christmas, I am far too busy atm.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 18, 2011, 04:55:29 PM
Woot!  Intuos2 mouse!

I updated the Makefile (http://www.dracoventions.com/products/2empowerFM/download/Waxbee/Makefile) to just compile *.c and *.cpp and it works great.  =)


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 18, 2011, 06:00:33 PM
Very cool. I committed the new version.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 29, 2011, 11:19:57 PM
I've updated it to pass through the Intuos1 tool serial number.  The serial shows up in the About > Diagnostics dialog but it doesn't show up as a second tool in the Wacom control panel.  According to this topic (http://forum.wacom.eu/viewtopic.php?f=3&t=4816) the different settings for different pens was a feature removed from recent driver versions!  Stupid.  From what I've read elsewhere, different settings for different pens has also had support reduced or removed from Photoshop and other paint programs.  I don't get it.

Anyway, do you want to grant me access to upload my changes to svn or do you want to review them somehow?


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 30, 2011, 04:25:04 AM
send me a patch file and I will review it. We can then see how we do the commit.

Ah! Wacom is weird sometimes. The old ultrapads had tons of features built-in. As time passes, they are going "dummier" and "dummier".  (for example, before you could do multiple area mappings on the same monitor). Or support for dual devices.

So you are saying that the intuos1 tool id is recognized through an intuos2 device? The Wacom drivers recognizes it as the good tool?


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 30, 2011, 07:46:39 AM
Quote
So you are saying that the intuos1 tool id is recognized through an intuos2 device? The Wacom drivers recognizes it as the good tool?

"Tool id", at least in the language being used in the Waxbee source code, is a 16 bit value that is unique for every type of tool across the entire Wacom line.  So an Intuos1 pen has tool id 0x822, an Intuos2 pen has tool id 0x852, etc.  Actually, the serial interface on my Intuos1 reports "tool id" for the 4D mouse as 0x094 but if I pass that tool ID to the USB Wacom driver, it also considers it a 4D mouse and it shows a picture of an Intuos2 style 4D mouse in the Wacom control panel.  So I think they may have left tool id unchanged for certain devices.  I also tried using 0x09C which the Wacom driver also shows as a 4D mouse with the same picture and rotation works but the scroll wheel does not.  Weird.

At any rate, the tool-specific "serial number" is a separate concept from the "tool id".  The serial number is just a 32 bit value that is different for every single tool (it's different for my two Intuos1 pens and my two Intuos1 mice) and, if I'm reading the Linux drivers correctly, the serial number seems to be 32 bits for every Wacom that supports the concept of a tool serial number.  So yes, I can pass the 32 bit value detected by the serial side to the USB side and it's accepted by the Wacom driver and shows up in the "Device S/N" field of About > Diagnose.

I've also finished handling the serial 4D mouse packets and passing them on to the USB interface so my 4D mouse is working as far as moving the pointer.  The rotation and scroll wheel also work correctly, but none of the buttons works.  I can see the button bits are changing on the serial side, but the values I pass to the USB side are ignored.  I've checked a bunch of times that I'm sending the values expected by the USB linux driver for a 4d mouse so I'm not sure what else to try at the moment.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 30, 2011, 08:51:36 AM
Ok, I got the 4d mouse buttons working by setting protocol5_packet.bit6 to 1 which is how it's set for the regular stylus.  Oddly, the Linux driver doesn't care if that bit is set or not as far as I can tell.

In the serial protocol, bit6 is actually the proximity bit, so I tried using it for proximity and setting bit5 (the USB proximity bit) to 0.  When I put my Intuos1 stylus near the Wacom control panel in the About > Diagnose dialog about 10 different tools suddenly showed up in my available selection of tools.  I think I must have activated a debugging bit because many of the tools don't actually exist such as "Rotation stylus", "Designer pen", "Wood pen" and "10 button stylus"!

[attachment=1]

I also tried setting bit5 to 1 and using bit6 as proximity but it wouldn't recognize the stylus, so I returned to using bit5 as proximity and just keeping bit6 set to 1.

Now I think everything is working great except I just noticed my stylus eraser isn't being detected as an eraser... grrr.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 30, 2011, 08:56:30 AM
Awesome!  

The linux driver code only decodes what it wants to look at. The Wacom driver might be looking at more bits. Would it be valuable to put my Intuos2-series XC-100 2D Mouse under the USB packet sniffer -- does this device have the same buttons as the 4D mouse of yours?

Looking forward to review the code! (you can email me the patch)

I need to understand this tool id vs. serial number thingy a bit more. I am under the impression that the tool id is constructed using bits and bytes from from the serial number and I thought this was a Linux driver-only "concept". But you may prove me wrong.  :P


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 30, 2011, 09:47:15 AM
I'll have to figure out how to make a patch with svn.  I'm more used to git.

The problem with the eraser on my stylus seemed to be corruption in the control panel data.  Neither pen pressure nor eraser pressure were showing up in the control panel (but they did show up in About > Diagnose).  I removed my stylus from the list of tools, which crashed the control panel, and when I put it back it was detecting eraser pressure on the eraser tab and pen pressure on the pen tab.

The Intuos2 4D mouse has the same number of buttons as the Intuos1 4D mouse.  The only difference is the scroll wheel on the intuos2 mouse is where the middle button is on the Intuos1 mouse.  You can click the scroll wheel to act as the middle button.

If you packet sniff your Intuos2 mouse we can maybe confirm what bits should appear after hid_identifier, though the bits I've used seem to be working fine.

BTW, here's comments I added to the code describing how the bits for tool id and serial are encoded:
Code:
// This is how the tool type is decoded by the USB linux driver:
//   (data[2] << 4) | (data[3] >> 4) | ((data[7] & 0x0f) << 20) | ((data[8] & 0xf0) << 12);
// And this is how the serial is decoded:
//   ((data[3] & 0x0f) << 28) + (data[4] << 20) + (data[5] << 12) + (data[6] << 4) + (data[7] >> 4);
// We need to reverse these equations to encode the tool id and serial.  If you look at the equations,
// Tool id (T) is encoded using 20 bits and serial (S) is encoded using 32 bits.  However, notice that
// tool id decodes to a 24 bit number where only bits 23-16, 11-0 are assigned values stored in the
// encoded data.  It would be logical to place bits 15-12 as the last 4 bits of data[8] but the
// decoding equation ignores those bits using & 0xf0.  That could be a bug in the decoding equation.
// Either way, these bits are all 0 in the data we plan to send so it doesn't matter for our purposes.
// The tool id bits are spread out in a strange pattern, presumably because tool type started out as 12 bits
// and was later padded to 24 by placing additional bits in the last half of data[7] and the first
// half of data[8].
// data[2]  [3]      [4]      [5]      [6]      [7]      [8]
// TTTTTTTT TTTTSSSS SSSSSSSS SSSSSSSS SSSSSSSS SSSSTTTT TTTT????
// Bit numbers (a 3 above a 1 means bit 31):
// 11987654 32103322 22222222 11111111 11987654 32102222 1111
// 10           1098 76543210 98765432 10           3210 9876

More evidence that the serial number is a separate 32 bit value from the tool id is that the About > Diagnose dialog shows S/N as a value like "0x12345678".  This is a 32-bit number in hex and it displays the same 32 bit number I pass to it in the data above and it doesn't include the tool id.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: bernard on December 31, 2011, 06:57:06 AM
The XC-100 is a 2D mouse with 2 buttons (not a 4D mouse with 4 buttons).


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Dragon on December 31, 2011, 07:23:35 AM
The XC-100 is a 2D mouse with 2 buttons (not a 4D mouse with 4 buttons).

Whoops, you did say it was a 2D mouse originally - I missed that bit.

I think the best thing would be to simply test your mouse to see if the 2D mouse code I added works and if not, then you can packet sniff.

But basically a 2D mouse is the same as a 4D mouse except it has two fewer buttons and a "relative" scroll wheel that just sends +1 or -1 scroll events each time you roll the wheel a little.  The 2D mouse does have a middle button which is activated by pushing the scroll wheel in.

The Intuos1 4D mouse has a "throttle" scroll wheel that sends a value between -255 to +255 depending how far you push it up or down.  I assume the Intuos2 4D mouse is the same, except its scroll wheel replaces the middle button instead of being located where your thumb is.

Also, the 4D mouse reports its rotation between 0 and 360 degrees.  From looking at the linux driver, I don't think the 2D mouse reports rotation.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: tufty on March 31, 2014, 12:16:20 PM
I need to understand this tool id vs. serial number thingy a bit more. I am under the impression that the tool id is constructed using bits and bytes from from the serial number and I thought this was a Linux driver-only "concept". But you may prove me wrong.  :P
According to Wacom, the unique tool id is a catenation of the tool id (16 bits, although not all used) and the serial number (32 bits).  In other words, the tool serial number is only guaranteed unique within a particular tool type.

The tool id gives you what type of tool you're dealing with (and, with a little creative masking, you can say, for example, "pen" vs "mouse", where pen might mean any stylus-type device, and mouse means any mouseish thing).  Then you can use the serial number to distinguish between multiple similr devices on the same tablet.

Simon


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: Aerendraca on March 31, 2014, 08:14:20 PM
Hey Tufty, this is quite an old thread now, but hey, all new information is great, maybe it'll help someone out.


Title: Re: Converting Wacom GD-1218-R from Serial to USB
Post by: tufty on April 01, 2014, 08:33:28 PM
Hey Tufty, this is quite an old thread now, but hey, all new information is great, maybe it'll help someone out.
It's info I've gleaned from some (mac-specific, but still generally valid in this respect) wacom docs whilst in the process of decrypting the ADB intuos tablets.  Chapter and verse from wacom :

Quote
• Device ID
A new feature to the Intuos series is Device ID. A chip with a unique number is inside every device so every device can be uniquely identified. With Device ID you can assign a specific tool to a specific device or use it to "sign" a document. You can restrict access to document layers to particular devices and have settings follow a device to other machines.
The ID code from the device is in two sections. It is the combination of the two that is guaranteed unique. One section, the highSN, is actually a code unique to each device type. The other section, the lowSN, is a unique 32 bit number within a device type. lowSN may be repeated between device types, but not within a type.
The highSN is a coded bit field. Some bits have special meaning to the hardware, but are not of interest to a developer. What is of interest is:
There are 12 bits total.
The upper 4 bits, and a couple bits in the lower four, identify the device. The middle 4 bits are used to differentiate between electrically similar, but physically different devices, such as a general stylus with a different color. So to figure out a specific device type you mask with 0x0F06. For example maybe 0x0812 is a stylus that is black, 0x0802 is the standard stylus included in the box, and 0x0832 may be a stylus with no side switches.
The currently supported type are:
General stylus: (highSN&0x0F06)==0x0802 Airbrush: (highSN&0x0F06)==0x0902
4D Mouse: (highSN&0x0F06)==0x0004
5 button puck: (highSN&0x0F06)==0x0006
To create the unique ID just concatenate highSN (without masking with 0x0F06) and lowSN to make a 48 bit (you will probably use 64 bit) serial number.
and
Quote
Remembering Tool Settings
A really simple but useful feature you can add to your application is the ability to remember settings for each of a user’s
tools. For instance, a user may have three Intuos styli and would like to set one to the paint brush, another to pencil, and the third to the clone tool. Then as the user puts one pen down and starts to use one of the other pens, your application could recognize this and automatically switch to the correct tool pre­defined for that pen.
The secret to this feature is the combined use of the uniqeID of the proximity event and the deviceID of the proximity and pointer events. Keep a list all known devices and the settings for each device. Then as you get proximity events, check to see if you already have a device with that uniqueID in the list. If so, then switch to the settings for that device and update the deviceID. If not, then add that device to the list. While you receive pointer events with the same deviceID, you know the user is still using the same tool. On the rare occasion that you start getting pointer events with a different deviceID without first getting a proximity event, simply ask the tablet driver to resend the last proximity event (a.cm). You should also save this list in your preference file so that the next time the user runs your application, the settings for each tool will be remembered.
Important:
You may be tempted to bypass the uniqueID and just use the deviceID. However, Wacom will not guarantee that the deviceID for a tool will remain the same. The uniqueID is guaranteed to remain the same for a transducer at all times. Even if a transducer with a uniqueID of 425 on one computer is used on another computer, it will report its uniqueID as 425 on the other computer.