test1
March 30, 2017, 03:30:47 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: You can attach photos hosted by the forum rather than using an external image hosting site, this means they will stay forever and not disappear after a year or two.
 
   Home   Help Search Login Register  
Pages: 1 [2] 3 4 5
  Print  
Author Topic: Converting Wacom GD-1218-R from Serial to USB  (Read 28885 times)
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #15 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.
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #16 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).

« Last Edit: December 14, 2011, 09:51:44 PM by bernard » Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #17 on: December 14, 2011, 11:07:11 PM »

So, from here 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.  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.  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.

Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #18 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.
Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #19 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:


* Realterm.jpg (131.17 KB. 701x449 - viewed 490 times.)


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.

Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #20 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.
« Last Edit: December 15, 2011, 03:11:35 AM by Dragon » Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #21 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).
« Last Edit: December 15, 2011, 08:01:31 AM by bernard » Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #22 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.
Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #23 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?
« Last Edit: December 15, 2011, 07:09:57 AM by Dragon » Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #24 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 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;
}
« Last Edit: December 15, 2011, 08:42:13 PM by Dragon » Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #25 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()

(*!)
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #26 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). 

Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #27 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.

Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #28 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.
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #29 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? 
« Last Edit: December 16, 2011, 03:45:42 AM by bernard » Logged
Pages: 1 [2] 3 4 5
  Print  
 
Jump to:  


Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!