Bongofish
May 27, 2018, 06:02:47 AM *
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: Interfacing a TabletPC digitizer  (Read 11354 times)
Aerendraca
Administrator
Hero Member
*****
Posts: 1068


View Profile
« Reply #45 on: May 05, 2016, 11:33:12 AM »

Ok so the Teensy appears to work fine. You definately have a Teensy/Clonsey version 2.0? I'm just wondering if there might be an issue with the code between versions off Teensy, different setup/pin configs like you suggested. My experience here is limited by the way, I'm familiar with Arduino but have never used a Teensy, or for that matter, done the Waxbee conversion.
Logged
Pesho
Hero Member
*****
Posts: 275



View Profile
« Reply #46 on: May 05, 2016, 11:46:14 AM »

It's definitely a clone because the traces for the 3.3V regulator on the bottom are different from those in the pictures. Original teensy uses a SOT-223 regulator, whereas the pads on the clone are meant for a smaller SOT-23 one. I had to rework the traces a bit to put in a larger SOT-223 regulator since the other type can't handle a current of 500mA and is probably a bad idea. It's not so much that it's a bad clone, rather that the waxbee code is likely very specific to PJRC's Teensy... Only one way to find out i guess.

Other than that, seems like i'm having better luck just using plain serial over the FTDI USB interface - you just hook it in, do an "inputattach" in linux and it just works. The fact it freezes after a certain time is annoying though... I'm curious to hear any ideas on why that would happen. Data coming in too fast for the chip to handle perhaps?
Logged
bernard
Administrator
Hero Member
*****
Posts: 2589


pato mania


View Profile
« Reply #47 on: May 06, 2016, 02:57:08 PM »

Hello Pesho et al, maybe I can be of any help?  I've done ISDV4 conversion before  Grin

The only (typical) difference between a "real" teensy and clones is just the bootloader code. I assume the clone has a similar external crystal like the teensy?  If not then that could be one reason. But if the CPU model is the same, then it is the same. There are no "AVR clones" (AFAIK).

Can you take close up photos of your setup?

Why do you need 500mA? Maybe that is your issue?  Like it starts doing things and the tablet (or whatever you are powering?) suddendly eats lots of current, voltage drops and something browns-out? (i.e. Brown-out is a state that makes chips go bezerk - typically happens when the voltage gets out of range -- a well know technique to "break" through security features...).

Yes, Linux drivers still work fine with serial tablets! No real need for USB emulation on Linux. This is mostly for Windows (and Mac OSX).
Logged
Pesho
Hero Member
*****
Posts: 275



View Profile
« Reply #48 on: May 07, 2016, 12:31:17 PM »

Hey bernard, been awhile!  Grin

Yeah, i figured the hardware ought to be identical - same AVR microcontroller and *mostly* the same PCB layout. The clones weren't much cheaper than the original either, only by a dollar or two... They have 16.000Mhz crystals, only visible difference is the regulator footprint. I figured the use of a SOT-223 regulator in the original Teensy design was made so it could handle the 500mA maximum from the USB spec. That, and i had alredy bought the regulators based on the info from PJRC's website and didnt want to get SOT-23's just for that... Roll Eyes Since i got two, i left one of them unmodified, but it does the same thing, so i doubt it's a brownout.

Unmodified Teensy clone Top:

* TeensyT.JPG (103.6 KB. 1024x768 - viewed 150 times.)


Unmodified Teensy clone Bottom:


* teensybottom.jpg (174.14 KB. 1380x1833 - viewed 153 times.)


Modified Teensy clone bottom:


* TeensyM.JPG (109.59 KB. 1024x768 - viewed 166 times.)


Why does serial not work on Windows btw? Can't properly handle the USB-RS232 adapter?


« Last Edit: May 07, 2016, 12:53:33 PM by Pesho » Logged
bernard
Administrator
Hero Member
*****
Posts: 2589


pato mania


View Profile
« Reply #49 on: May 07, 2016, 07:14:09 PM »

About the power:  For an ISDV4 -- you probably won't need 500mA of power -- the board will pull something under 100mA (like 80mA) -- I say probably because I never measured yours of course. Only a couple others I had around here.  I mean, the old and huge 12x18 inches UD and Intuos2 serial board with leds et al do not really exceed 100mA either!

Your SOT-223 is going to work and is probably a better part anyway.

Now the tricky part: why it suddendly decides to stop... ISDV4 are much simpler to deal with -- they have nearly zero configuration and uses a steady serial port speed (the UD/Intuos2 boards starts at 9600 baud then you tell them to go to a faster speed -- if you screw up something and gets desynchronized, you won't talk to the same speed and hence "loose connection" until you reset).

Now I will just dump what I saw from experience, I have no idea if it applies to you.
Not a big change but MAYBE you are running into a RTS and possible DTR handshake problem thingy -- especially if those pins are not connected (these are inputs) -- that would mean they are "floating" -- floating means that it can go high or low depending on...  mood.  Grin   Well maybe after 30 seconds the "mood" changes? lol.  Make sure those are grounded -- Here I mean on the side of the tablet.  Can you take a picture of your device connector and point what is what -- I do not even recall if those HAVE RTS and/or DTR to start with !!  Note that these are the handshake pins going towards the tablet that will "halt" the bytes going out if high. There are other handshake pins (DSR/CTS) going the other direction (outputs) (which we don't care, they should be left unconnected -- as we do not really need to be "handshaked" -- well, potentially yes if this is hooked to the PC directly, but at these low speeds, I am sure your Linux system will handle/buffer everything without loosing anything, and if it ever does loose a byte it will resync on the next packet anyway!).

Logged
Pesho
Hero Member
*****
Posts: 275



View Profile
« Reply #50 on: May 07, 2016, 09:12:10 PM »

Nice, didn't realize they drew so little. Makes sense if you're putting together a TablePC and need to squeeze out as much battery life as possible.

As for why it decides to stop... that's a really good hunch! The bytes really do just "stop" as if it's waiting for something to happen. I included DTR and RTS in my cable (see pic on page 2 of this thread), but never connected them. Does it matter if i ground them to the chassis or the USB/RS232 board's GND pin?
Logged
bernard
Administrator
Hero Member
*****
Posts: 2589


pato mania


View Profile
« Reply #51 on: May 07, 2016, 11:21:42 PM »

The GND signal is what I am talking about.  We say "grounding" but it is not in the shield-protection sense but rather talking about "signals". Just connect it to the GND wire/pin/whatever is in the same "connection" (not sure how your setup looks like).

Make sure you do not mix up which signal is which (can get quite confusing) -- and labels can be written in "reverse" sometimes (Wacom often reversed the silk markings in some serial boards - not talking ISDV4 boards here, but the *-R models).  That is why I always talked about the serial driver chip pinout and never the silk markings next to the internal connector (when there was one).
Logged
Pesho
Hero Member
*****
Posts: 275



View Profile
« Reply #52 on: May 08, 2016, 12:32:05 PM »

Ok, i tried connecting DTR and RTS to ground - same deal. I may have the pin numbers wrong though, so they might not even be DTR and RTS to begin with... My setup is pretty basic, just the standard digitizer cable with the leads broken out and crimped:


* DSCF2481.JPG (145.4 KB. 1024x768 - viewed 157 times.)


If it's any help, here's what i get right before it stops if i set xsetinput to "dump":

Code:
25 (%) 06 (x) 02 (x) f0 (x)
a8 (x) 26 (&)
01 (x) 04 (x) f0 (x)
ac (x)
27 (') 06 (x) 00 (x) f0 (x)
ac (x)
26 (&) 05 (x) 04 (x) f0 (x)
ac (x)
27 (') 03 (x) 00 (x) f0 (x)
ac (x)
24 ($) 04 (x) 00 (x) f0 (x)
ac (x)
24 ($) 03 (x) 02 (x) f0 (x)
ac (x)
04 (x) 00 (x) 06 (x) f0 (x)
ac (x) 04 (x) 03 (x)
00 (x) f0 (x)
ac (x)
04 (x) 07 (x) 04 (x) f0 (x)
ac (x) 04 (x)
07 (x) 04 (x) f0 (x)
ac (x)
04 (x) 02 (x) 06 (x) f0 (x)
ac (x)
04 (x) 05 (x) 04 (x) f0 (x)
ac (x)
04 (x) 07 (x) 06 (x) f0 (x)
ac (x)
04 (x) 07 (x) 06 (x) f0 (x)
ac (x)
05 (x) 06 (x) 00 (x) f0 (x)
ac (x)
04 (x) 03 (x) 02 (x) f0 (x)
ac (x)
05 (x) 02 (x) 06 (x)
f0 (x)
ac (x)
06 (x) 05 (x) 00 (x) f0 (x)
ac (x) 06 (x)
01 (x) 00 (x) f0 (x)
ac (x)
06 (x) 07 (x) 06 (x) f0 (x)
ac (x)
07 (x) 03 (x) 00 (x) f0 (x)
ac (x)
07 (x) 07 (x) 04 (x) f0 (x)
ac (x)
07 (x) 04 (x) 06 (x) f0 (x)
ac (x)
07 (x) 01 (x) 04 (x) f0 (x)
ac (x)
07 (x) 02 (x) 06 (x) f0 (x)
ac (x)
07 (x) 02 (x) 06 (x) f0 (x)
ac (x)
06 (x) 01 (x) 02 (x) f0 (x)
ac (x) 06 (x) 05 (x)
06 (x) f0 (x)
ac (x)
06 (x) 07 (x) 06 (x) f0 (x)
ac (x)
07 (x) 03 (x) 06 (x) f0 (x)
ac (x)
07 (x) 05 (x) 06 (x) f0 (x)
ac (x)
07 (x) 03 (x) 02 (x) f0 (x)
ac (x)
07 (x) 04 (x) 02 (x) f0 (x)
ac (x)
06 (x) 06 (x) 06 (x) f0 (x)
ac (x)
06 (x) 04 (x) 06 (x) f0 (x)
ac (x)
06 (x) 04 (x) 06 (x) f0 (x)
ac (x)
07 (x) 05 (x)
00 (x) f0 (x)
ac (x)
07 (x) 02 (x) 00 (x) f0 (x)
ac (x)

« Last Edit: May 08, 2016, 12:42:36 PM by Pesho » Logged
bernard
Administrator
Hero Member
*****
Posts: 2589


pato mania


View Profile
« Reply #53 on: May 10, 2016, 04:00:55 AM »

There might be a pin to "activate" ("enable") the board.  If this is floating (as in unconnected), then... same stuff (or rather influenced by environment).

I should search and re-read the posts and docs we have for this to remind me. It's been a while...

These ISDV4 boards were always a bit of a mystery. They do not all behave the same. Information is typically very difficult to come by.

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


pato mania


View Profile
« Reply #54 on: May 10, 2016, 05:39:17 AM »

Another theory about the stop:

I was peeking at previous threads -- now I remember the ISDV4 protocol has a "start" and "stop" command.  It is the character "0" and "1" respectively.   It also has a * command. You might have to press return (but not sure).

http://forum.bongofish.co.uk/index.php?topic=2325.msg19082#msg19082

You do have the TXD (or the data transmission pin) going to the tablet connected, right?  If it is not connected, then, again, floating.. might actually echo the RXD and if a "1" is sent (and echoed), then it would stop itself.

Can you send commands like with your keyboard (how are you setup anyway?) 
Logged
Pesho
Hero Member
*****
Posts: 275



View Profile
« Reply #55 on: May 10, 2016, 03:30:49 PM »

OK, i think i finally got to the bottom of this!  Roll Eyes

The setup - i have RX, TX, +3.3V and GND from the digitizer connected to the corresponding pins on the USB/RS232 board, nothing else. I connected to ttyUSB0 using a proper terminal program (gtkterm) and there's data showing up when moving the pen. What was causing problems was that any time an intermittent error occured (like nudging the cable slightly or breathing wrong to make it lose connection), the tablet would just stop sending and receiving data. Judging by the activity LEDs on the board, it seems like it does an "initialization" when a connection is first made and then just streams the pen position. If the connection drops even once, you need to issue a connect command again to "reinitialize it" and it will starts sending data again. For gtkterm this means hanging up and reconnecting to ttyUSB0. One more thing worth noting is that when telling Linux to hook up the USB-serial port to the mouse cursor with inputattach, you need to use a baud rate of 19200 or more in order for the cursor to actually move. I was having problems with data coming in but no cursor activity because i was using a rate of 9600.

It's pretty surprising how easy it is to get these TabletPC digitizers running on Linux with "dumb" hardware like the FTDI board for less than 3$. Pressure works really well by default too. I'd like to experiment with trying to get this working on Windows also - i have a feeling there will be no problem getting data from something like HyperTerminal, but actually pointing the Wacom ISD driver to that particular USB-RS232 port is probably going to be the challenge. For the record, the board im using is one of these. It supports 3.3V which can be set with a jumper. The connections on the 14-pin connector are as follows:

Pin 1 -> GND
Pin 13 -> VCC 3.3V
Pin 10 -> TX
Pin 9 -> RX

I've tested this on an SU-12W07E-01X and an SU-025-C02, both work well.
« Last Edit: May 10, 2016, 08:45:50 PM by Pesho » Logged
bernard
Administrator
Hero Member
*****
Posts: 2589


pato mania


View Profile
« Reply #56 on: May 11, 2016, 05:53:08 AM »

Good news!

I tried to connect to the ISD driver (serial port) in Windows and failed.  Getting to connect to a serial port that is not an "internal" one I could never find how. I looked inside tech manuals on certain laptop and saw how it was connected through a "super io" chip (the chip that was on those old IO expansion boards!!).

Not saying it is impossible, just saying that it reminded me that I looked hard.
Logged
Pesho
Hero Member
*****
Posts: 275



View Profile
« Reply #57 on: May 11, 2016, 03:31:18 PM »

OK, i now have the digitizer successfully outputting data in Windows as well. FTDI have made it very easy by providing drivers for their chip that include a "Virtual COM Port" driver which emulates a standard COM port. Once that is installed i can run HyperTerminal with that COM port and see data coming in the same fashion as Minicom and Gtkterm on Linux. Makes sense, since the Arduino IDE uses the same port for most of their AVR boards which don't have native USB support and feature the same FTDI chip for communication.

The driver can be found HERE.

Now the more tricky part will be fooling the Wacom driver that the virtual COM port is a serial digitizer. I tried installing some drivers from HP for their TC4400 notebook, but they fail to detect anything. If there's any progress i'll post it here.
« Last Edit: May 11, 2016, 03:35:24 PM by Pesho » Logged
XDjackieXD
Sr. Member
****
Posts: 137


*me trying to draw*


View Profile WWW
« Reply #58 on: May 11, 2016, 03:38:07 PM »

You might have to take a look at how these tablets get detected inside the convertibles.
If you need any help I have a Fujitsu T730 here and both a working Windows and Linux (primary) installation which I could do some debugging on.
The tablet gets connected as /dev/ttyS4 on Linux so a "real" serial port not an USB <-> serial converter.
Logged
Pesho
Hero Member
*****
Posts: 275



View Profile
« Reply #59 on: May 11, 2016, 03:50:39 PM »

The main difference between Windows and Linux is that Linux supports these things natively, whereas Windows needs a special driver. I've ran both ttyS and ttyUSB digitizers at once on the same laptop and Linux doesn't care at all - both work. The issue with Windows is likely the same as with most of the old "real serial" tablets - getting the driver to look at the correct port.
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!