Screen Tablet malarky => Build Logs => Topic started by: DaBotz on March 20, 2014, 06:18:31 PM

Title: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on March 20, 2014, 06:18:31 PM
In the past, I have mounted a variant of the TableMod with a wood case that I called CabinetiQ.
It went too well, so I decided to go for a Bigger tablet this time.

I bought an Intuos2 A3 (yessss - my preciousssss), this beast:


This time, I was very undecided about following Don Shole's specs for his TabletMod XL;

The Intuos2 A3 is more a 16:10 than a 16:9, so the two AOC monitors he suggests falls or too wide ( the e2243f) or a bit too small (the e2043f). Also, in many places I read that each tablet/monitor  combination is slightly different...

I finally entered in Ebay looking for monitors  22" in 16:10, with LED back-lighting.

And here is where I made my first mistake.  I bought an HP LE2201w that was marked as LED back-lighting by the vendor.

I checked some online reviews, where they spoke well of its colours (and one of the reviewers also defined it a LED Screen).

Less than a week and it was mine.

I checked that it worked, and it works well, with quite brilliant colours.

It is not an IPS, but I didn't expect one in a 16:10 format ( it's kind of old, I gather;  though I still prefer it to the frigging 16:9). Still, the colours are one magnitude better than the ones in the CabinetiQ.

I went on to open it up and see what I had in front....   first surprise: two CCFL cables.


So, LED my ass. LE was for Lenovo, evidently. Damn.

There is no separated inverter, it is integrated with the power source, but the driver board is separated...


this is not so much a cause of horror as what I realized soon after.

The LCD panel is a Samsung LTM220MT05


, whose most worrying characteristic is its... DEPTH!

It's 13mm tall (17 with the case covering the circuit board) , and I think it cannot really be slimmed down below 12mm with even the most crafty stripping on my part.

Adding even a lean acrylic glass means It'll end in the 14-15 mm range... this, hypothesizing that I could get rid of all the metal without affecting any functionality (why one of the cables of the CCFL is bigger than the other? probably because the metallic case involving the panel acts as a common ground; I had seen the same with the AUO of the Cabinetic; I had need to ground a metal strip to the panel's circuit board, in order for the back lamp to work properly).

So, now, I do not really know what to do... mount the monitor back together, sell it and look for an AOC e2043f?

Try to dismount the Wacom and see if it can read reasonably the pen position at that height?

But I doubt the sensors table is more than a 4 mm below the surface, and the specs for Intuos2 and 3 states a maximum pen height of 6 mm... even stripping, I would be some 2-3 mm short before placing a glass?

Grrr - I feel stupid...

Anybody that has done a project on an XD knows how much reading height is there, above the circuit board?

[Update from after : with a 3mm glass on top. the pen position is still recognized to an height of some 5 mm... a 13 mm thick panel proved plenty usable]

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: Aerendraca on March 20, 2014, 08:09:29 PM
Doh, I've made this mistake before too.

I have an Intuos 2 A4 12x12 and I've measured a workable reading height of 14mm above the Wacom plastic case. Whilst this is workable it doesn't leave much room to hover above the surface.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on April 06, 2014, 04:42:01 PM
Thanks, Aerendraca.

Update: I've spent some time pondering upon what to do, re-read your post on the 12x12 intuos 2, Aerendraca (which makes clear that, not much may be, but there cold be enough height above the tablet), and finally I decided to strip the LCD.

I did it as carefully as I could, and the result is pretty neat.


... I can still piece the monitor back together and re-sell it, or use it (it's a pretty good monitor) as a "colours mirror" for the Cabinetiq (My philips 226v is a 16:9, which make is it a bit problematic on that respect. Also, I can't seem to find a good calibration for its colours, no matter what; The HP looks a little bit better) .

I carved out most of the backplate of the panel, and kept a vestigial metal frame all around it.

It was inevitable, as the top and the bottom also acts as case for the CCFL, and so couldn't really be eliminated.  Also, it would have been too frail, otherwise.

It is possible that it makes me lose some pixels on top and bottom of the screen. That said, I usually have a mouse at hand for dealing with the main screen anyway...

Width-wise, the screen is also a couple of cm bigger than the active area, (unfortunately, I failed to locate any 21" 16:10). I'll just have to be creative with the "mapping".

As far as I can tell, the remaining frame does not interfere with the pen signal, and I have some mm of "air" above the screen, yet a 1mm acrylic would be better (unfortunately, I think the thinnest one I can find here is 2mm) .

However, I do experience plenty of  jitter and false clicks (well, plenty - it's comparable to the CabinetiQ's in some of its worst days, before beefing up the common mode rejecters solved the issue), which is quite a put off.

I read some quotes of the fact that linking together the panel board and the Wacom base plate can alleviate this symptoms.

I am restive about stitching together directly two things that are not designed to be joined...

I expect that some "trick" is necessary, to avoid polarisation current issues.  Something like a good old capacitor to be placed between the two, as "big" as possible; I'll rummage a bit more, till I find the relevant thread.

Also, I hope the same common mode rejecters that I used with the CabinetiQ could help
(by the way, is it possible that the jitter is also caused by ghosting currents passing through the capacitor  "created" by the tft matrix and the wacom antennas?  the sensibility to the presence of current mode filters on both lines  - at least on the C...Q - would suggest it , in my opinion).

I've also ordered some CCFL extenders from NYJTouch. On the C.Q I just soldered a couple of 220V cables, after having intertwined the strands (soldering did work to carry analogic satellite signals, when I installed my satellite dish, so I did not see how could it go wrong for something so low a frequency)    

They are going to be here in ten days or so.

Anyway, looking through the site, I also found this post - ( - where it is indicated that the LG IPS224V could be a pretty good match for the Intuos2.

Damn, had I read it last month (it's a f***ing 16:9, though).

On the LG site, I see it has been superseded by the "6" series (LG IPS226v). It's a bit too steep for my budget, but I'll keep it in mind.

In the meanwhile, I'll go on with the "case" works and see if the jiiter is still as bad, with no CCFL involved (as far as I can tell, the ccfl are not a notable issue) and with a grounded sheld in front of the power board
(If I have to switch to a NIJtouch controller, I can as well sell the thing and go for the LG anyway. Moneywise, it would be sensible enough).

As it is going to be "thicker" than the C...Q, I went for a thicker (10mm) and stiffier plywood base, in which I drilled a hole the size of Wacom's secondary board.

I'm going to cover the hole with a metal shield that I will connect to "earth" (the power board for the panel is going to be right below it, unless the CCFL extenders prove very but very effective, in which case I could move it around a bit).

[attachment=2]   [attachment=3]

For now, let's keep my fingers' crossed.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on April 12, 2014, 12:45:32 PM

While I wait for the CCFL cable exenders, I built a sling to support the panel circuit board. I fixed on top of it the original board cover, and I hope that the resulting Faraday cage will shield some of the noise.


I acquired a burnt PC power unit and salvaged the ferrite (and soft-iron) nuclei of two of tis transformers, that I plan to use them as common mode chokes on the Wacom USB cable and the VGA cable.

I'll look if I can find another ferrite choke for the fcc that goes from the controller to the LCD panel, and for the CCFL cables (I shall investigate more before trying this last trick, though - while the noise on the CabinetiQ was very much a product of common mode currents seeping in the USB and power cables, I have no idea if the same can be said for this new one.)

That said, even if the panel did prove unsuitable, and I'll have to switch to the aforementioned LG monitor, I still have to add hotkeys and wheels to the thing to get it usable for me.

So, I spent a couple of hours "modding" three mouses (in the end, I'll use three wheels: zoom, brush size and LazyNezumi mode).

By the way, as time goes by, I finally picked a "clean" way to mod the mouses.

It all start buying a small mouse (mini mouse) - in my case, from NGS.

[attachment=2]       [attachment=3]

These  small mouses use a rotary encoder - instead of the usual set of IR diodes that you can find in normal sized mouses - to obviate the lack of space due to the smaller wheel.

The encoder is less durable but a lot more handy than the diodes  

Unfortunately, these encoders are originally with a horizontal axle (obviously), while I really need it to be vertical.

The first time I modded one, I made an unholy mess, with some 80 cm of cables connecting a pcb with the encoder and the three buttons to the original circuit.

Of course, these picked up EM "noise" wonderfully and fed it into the USB system (which is, I gather, not very RF-noise proof).

The second time, it was slightly better.

Third is a charm, as they say.

I decided that less is - in this case - decidedly more.

After having de-soldered the encoder, I bent its three input 90 degrees forward (really, I did it as I was de-soldering them: it's the cleanest way I have to do the job, warm up the thin and bent the damned things out - the pin holes are open on one side ).

Then I de-soldered also the left and right click buttons (one of them, I needed to de-solder anyway, to have a platform onto which to anchor the turned-vertical-encoder)

I soldered the "structural" pin of the encoder to a pretty small piece of PCB, that I glued at 90º from the mouse board (well, actually, it is glued to a small cubic piece of wood that is then glued to the PCB - I'm a wood guy and I didn't have any Lego around; if someone know how to bend PCBs, let me know) so that the encoder axle was vertical (not exactly, damn me). Once the glue was dried and the whole shtick was solid, I re-soldered the encoder's signal pins and verified that it works.

I also placed the removed buttons on two auxiliary PCBs connected with some cm of cables to the mouse board, and verified that they, also, work as they should.

Which is not so obvious: on this mouse, both buttons share a common line, and is the value of a resistance in series with the switch that let know the mouse chip which button is pushed.

As a result of this design (which, among other things, grants that the left click "overrule" the right one), a flimsy solder may transform the left click in a right one.

As knobs, once again I will go with polypropylene office chairs' wheels.

I can't find my preferred - 40mm x 20kg -  , so I have  to use the 50mm (30 kg) I had lying around  (I have bought some to replace the ones under my chair that I accidentally destroyed a while ago - I always buy a spare sample).

Now, there is a moderately simple and very cheap trick to connect these to the encoder...

The hole in their back is slightly less than the girth of a classic aerial coaxial cable, so you can take one, stick it into the hole, cut it after 1-1.5 cm while leaving the copper core intact, and extract the copper core from the cable.

Gently nudge a little more the de-cored cable into the hole (with a hammer, but gently), and then you can carve away the external shielding, leaving a short, reasonably rigid and smooth nylon pivot, pretty rigidly connected to the wheel.

In the place where originally was the copper core (a bit too thin and smooth), I place (very gently, hammering it down, but gently) a tooth-picker that then I slim down a tiny bit hexagonally.

The tooth-picker is strong more than enough to carry the movement to the encoder but its wood is also tender enough that the plastic of the encoder can shape it when posed into the pivot siege, and I count on the nylon to handle side forces (though, the wheels of the Cabinetiq are running on tooth-pickers alone since I modded the first wheel), as I can place it into inside a small hollow screw (used to lodge 6mm screws - threaded for metal and easy removal - in wood).




I have an idea of how placing them together, but I feel it is better that I see if I have to move the power source away, before start cutting plywood.

FOr the moment, the disposition could be something like this


But, as I said, refinement may still come            

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on April 26, 2014, 02:46:43 PM
Fast update: received the CCFL cable extenders from NyJtouch.

Tried a fast run, with power souce aside the screen, tablet upside down, "armor" around the LCD board and two ridiculously oversized common mode chokes on the usb cable.

Jitter is down to 3-4 pixels and no apparent "false clicks". I think it can be done.

I need to think well at the auxliary inputs (three wheels, their buttons,  a touch-pad and a compact keyboard), now.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on May 01, 2014, 01:27:24 AM
Update: I have build it.

[attachment=1]  [attachment=2]

And it works relatively fine.

As I was saying in my last update, jitter with the power source out of the way seemed reasonable.

I have decided, finally, to build the table alone, and leave "stubs" to attach auxiliary inputs after.  This choice, in turn, is due to my decision of using this with Linux - Ubuntu, to be more precise.

Now, in Linux HidMacros does not work, so I'll have to whip some kind of "overriding driver" for the aux keyboard and the wheels.

From the documentation, it could be relatively forward to modify the reference usbmouse.c and usbkeybd.c "base" drivers, but I rather not tie all to such an hazardous step.

Right now I think I should rather draw for a while and see where to put things, before having another hardware spurt.

And, anyway, the proiority seems to be for "enahncing" the stand...

I'd rather not go for an "Ergotron", but I need to have a stand able to present the screen at about half a meter from its base....

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on May 01, 2014, 02:40:26 AM
I should add that I decided to call this UbiQ , now.

"GigantiQ" was a good - slightly self-derogatory - name when I thought it would not work, but now that it does, it is too much bombastic.

Being wary of jitter, I decided to place the power source "aside" the tablet/lcd panel (instead of below) ) and to leave the main connectors on the same side (at the "top").[attachment=1]

This has resulted in a big case (65x62 cm) , because the power source was an horrible 15x18 cm.

Note: one of the many differences between this and the "CabinetiQ" is that UbiQ has no "privileged direction", so "top" is just for the moment.

As I hate the idea of having to manhandle directly the Intuos usb cable, I placed all of it "inside" the shell, with a good length around some ferrite nuclei I scavenged from a burnt down PC power supply, and left just an head to connect with.

... To allow for expansion, I added a powered usb  hub ( to which the Intuos2 is connected), which expose three usb slots on the UbiQ left side (right below the screen buttons).


The aforementioned usb "head" doesn't come from the Intuos, it is the hub root.

When I will have ready the hotkeys "console" (or whatever) all that will be needed is to plug it in.

In the meanwhile, a numeric pad will do (as it has always done with the Huion 610, to date) as hotkeys hardware.

The Linux driver has almost no GUI interface, but it is very configurable through a command line tool called xsetwacom.

I'd rather not touch the true configuration files of the Wacom, as making a mistake there breaks the X11 server and  I know for experience that it may be quite bothersome to "rollback" from that state - in my system, it combines with the CIFS initialization that fails at boot because it starts before the network service, and it all makes things a bit less straightforward.

Among the many "valuable pluses" of the linux driver, it allows to set an "active area" bigger than the "physical" active area of the tablet.

This means that it has been possible to calibrate the UbiQ - that has a screen wider than the physical area - without touching the projection on screen, just resizing its logical area.

Which, in turn, makes easy to handle multi-monitors, as it just need to use a mapToOutput command to link the tablet to its screen.

The driver also allows to set the number of samples over which the pen positions (and pressure) are averaged ( a sliding door average).

Selecting a value of 5 samples, jitter goes down very nicely to around 2-3 px, which I can work with, without making the pen too sluggish, so I proclaim myself content of the result.

Finally, but not lastly, the driver allows to set a pressure curve that is a 4-points bezier, so I have compensated for the "horrible" off-the-shelf pressure curve of the Intuos2.

Anyway, as an example, here is the current configuration for the UbiQ,  


For the moment I am pretty happy with this build, though I'll have to create a  new stand for it...

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: Aerendraca on May 01, 2014, 04:02:21 AM
Amazing stuff, an excellent job well done! Now you get to have a play! I'm a bit jealous.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on May 06, 2014, 01:08:28 AM
Thanks, Aerendraca. I am playng with it... more fiddling than drawing, though.

I am getting "around" the "issues" of the UBiQ.

I replaced the stand that I used initially, the "Moloch" from the CabinetiQ, with a pivoting wooden arm attached to the library in my sitting room.

It is ugly as hell, but it works (and I do not know if I have the "tecnology" to d a better work; yes, an iron tube could be smaller, but I do not care that much for soldering steel beyond not-stressed works like the shield I placed around the power unit

I then proceeded to modify some of the pieces in the old stand, and use it as a height-regulable support.

Even uglier.

I have managed to place together a python script that allows to change the Wacom driver smoothness from inside GIMP (and, by the way, plug ins in GIMP can be associated to key short-cuts) even if, maybe, the best solution would be to use a bash script and an alias for it, so that the fas setting can be invoked system-wide.

Right now, the biggest "problem" is that I see no fast way to create wheels in Ubuntu.

I could create an overriding driver for the class of usb mouse that I use for building the wheels, but I can't seem to be able to convince Linux to give me all the headers that I need (or something).

That said, should I count it as a successful build?  It does work fine...


Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: Aerendraca on May 06, 2014, 07:52:06 AM
I agree that this is a successful build and have used my new privileges to move the thread. Once again great job!

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on May 14, 2014, 07:30:21 PM
Fast update: I have built the keyboard/wheels control, here it is:


Getting the wheels to work in Ubuntu has proven relatively simple ("simple" being an euphemism, of course).

I achieved it using the xinput set-button-map command, and a small utility called imwheel (which allows to replace wheels events with keystroke macros, depending also on the active window).

I remapped the "usual" buttons of my mouses to button IDs beyond the reach of "normal mouses", and used xbindkeys to bind them to a script that raises/lowers the Wacom driver smoothing factor, and to  the brush hardness (in all, the mouses do what I need, wthout interfering with the works of the normal pointers).

For the moment, I'm still fighting with the keyboard, as my "main" keyboard, a wireless Logitech K400, does not accept to keep its own layout and follows whichever was that of the last keyboard used.

My idea was to set up a bogus keyboard layout made of "out of boundaries" unicode characters, and to use Autokey to bind macros to the keys, but this would end in the K400 emulating the same unusable layout the first key I press on the command keyboard, so I would have to have a third keyboard (even just a numeric pad) to reset thek400 to a usable layout...

A hassle, in a word.

Here is, also, the last version of the UBiQ configurator and of other scripts I use, to whomever it may concern.

And a bogus logo, of course.


P.s. - Yes, Yes, I realize now what that border around the keyboard and the wheels looks like... I suppose I'll change it, the next time I have to modify any thing.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: Aerendraca on May 15, 2014, 07:42:47 AM
 :D I totally hadn't noticed about the border until you pointed it out!

It looks pretty well made, how is it in terms of position? Is it natural to use?

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on May 15, 2014, 06:13:02 PM
Position-wise, I still have to figure where to place the screen.
For the moment, as I use it on my sofa, the command board is in a pretty good position, i.e. where I naturally left the hand before building it.

If I had to use it in the same place where I have the Cabinetiq, I'd have to raise it some ten cm and place it parallel to the main screen.

It would take a couple of minutes... under the left border of the Screen I have left 4 threaded support for 6mm screws, so I can wiggle it around quite a bit.

At the moment, the only thing I miss is some labels to put on the command keyboard, as I do not remember what key is what.

I'm still bending my mind around the k400 issue, though...

That buggers me, because it look some kind of not-complyingness on the Logitech part (the fact that it does not notify itself as a keyboard and a pointer is "odd").

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on May 21, 2014, 08:49:33 PM
Here, a video with the beast in action: (


Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: Aerendraca on May 22, 2014, 08:04:31 AM
Great video DaBotz, it's nice to see it fully in action. Looks great and seems like it works very well. Very nice.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on May 25, 2014, 11:11:57 PM
Thanks, Aerendraca.

It is true. My little "UBiQ" works well.
I started populating the keyboard with my short-cuts labels.


I also realized that imwheel - the utility I use to "hook" the wheels to GIMP functions - while it is much more limited than Windows' HidMacros on the inputs "it sees" (but, in GIMP shortcus are all fully programmable, so HidMacros would not be really needed even if there was a Linux version of it) , on the other side it not only allows to program the wheels output depending on the active window name but, also, on which modifier is pressed.

So, right now, I have set:

Left Wheel:
  No modifiers: Zoom
  Shift: Select next/previous layer   
  Control: Layer Opacity
  Shift+Control: Move Layer Up/Down the layers pile

Right Wheel:
  No modifers: Brush Size
  Shift: Brush Angle (useful for some brushes like, for example, "grass")  
  On Ctrl: Brush Opacity
  Shift+Control: Brush Hardness

I realize now that it would have been better to "disable" the "Fn" button, when I opened the keyboard - it would have been enough just to slip a bit of duct tape between the membranes, to achieve it.

Had I did it, now it would be easy to "fuse" that key with Control, to have a bigger (easier to push) Ctrl button ("Fn" keys are confusing enough with a straight keyboard; with it stacked vertically they have almost no meaning).

Alas, I didn't.
Also, I think that with a little effort I can get the wheels to "Switch mode" in the same way of the touch ring in the Intous4, though I think I would use the two unused mouse buttons at the bottom of the dashboard, and not the buttons below the wheels to control things...

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on July 04, 2014, 11:57:10 PM
Horrible Update

The romance between UBiQ and Ubuntu is no more!!!!

Apparently, there is an update (in the linuxwacom driver, or somewhere else) that "breaks" the driver stack for Intuos and Intuos2.

Damn... I am back to use Windows7, Photoshop Elements, LazyNezumi and Hidmacros.


While I was checking that it was not an hardware problem, I opened up

UBiQ, and took some shots of the interior.

Here the photos of ubiq:

[attachment=1]       [attachment=2]

And of the control board:

[attachment=3]     [attachment=4]     [attachment=5]

I must say, disappointed as I am with the  damned update, it's probably for the better.

I couldn't really use GIMP's smudge tool, and Photoshop does not see the pressure input when installed in Ubuntu.

Only, Windows is so cranky...

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on July 21, 2014, 01:19:41 AM
Added some more common mode chokes, and moced away one of the already present. This last action made a lot of difference... oddly enough, I moved it nearer the video board, but redusced problems. Why ? No idea.

17 seconds of jitter from really near the pen.

If only I could get rid of what's left of it.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: Aerendraca on July 21, 2014, 06:24:25 AM
Is that the worst of the jitter or are there places on the screen which are worse?

When you say you moved one of the chokes nearer the video board, do you mean the graphics card or the lvds controller?

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on August 14, 2014, 07:30:39 PM
I moved the second big filter between the the tcon board and the lvds controller, but I also rotated it 90º from the previous position, which may have broken whatever magnetic entanglement was going on in the original  position.

The screen has CCFL lights, and - as could be expected for interfering screen - jitter is worse near them, becoming quickly unusable in the last 10 mm nearing the edge.

Oddly enough, it is not as bad near the lower lamp as it is near the upper lamp, where I suppose the tcon board is not fully shielded.
The main effect seems to be a "distortion" on the y axis reading of the position of the pen (where the general Jitter is, instead, mainly an x axis issue: looking at the driver test page, aside the worrying tool serial number 0x00000001, both x axis tilt and position jitter is more than twice that on the y axis).

The pen appears to "leave" the cursor behind, but I am not able to tell whether it is the lamp, or the metallic case still present distorting the electromagnetic field in that zone, the source of the issue.

Combined with the tablet not reaching the left and right borders, I'd say that it is better to keep the drawing area inside of 2 cm from each border, which suits me well.

As a long time paper dog, the border area is sacred for me (it's used to hold the paper on watercolours, or editorial annotations on comics...) and I never go there on paper, even when drawing sketches.

Also, the unusable space is mainly occupied by the Windows status bar (on the right), the Photoshop status bar (bottom), the Photoshop toolbox (on the left - I don't really need to reach it, as I use hotkeys for tool selection, but it is a bit difficult to get what is your current tool without it) and other seldom used PS options (top).


On a side note, I moved the UBiQ where I used to keep the CabinetiQ (Simply, I can't concentrate much on a sofá).

So, I finally found why C..Q was so randomly, with his jitter.

The earth dispersal is less than ideal, and noise just goes around from one appliance to the other (no idea how much would cost fix it... more than change the screen to a less jittery one, for sure).

In the new place, some random clicks are back and jitter is a bit worse, and gets a lot worse when the other computers - and monitors - in the room are active. Or if the hard drives work hard.

Also, there is some more jitter near the vertical edges, than what was there in my flat. I suppose it is a matter of the ground not dispersing the noise generated by the ccfl in the metal casing.

Finally, I'd say that the main problem is still not what I call "random" jitter (which could be mitigated a bit more, maybe) , but rather what I call "geographical" jitter.

This is shot of a line made with a ruler, going back and forth five times.


The random jitter is the reason why the line is not just 3 pixels wide, but the overall wavy shape is a proof of the presence of a "fixed" decorrelation between the movement on x and y axis, that depends on the position/movement of the pen (by the way, also my beloved Huion H610 has the same issue, and that without placing a screen over it).   


On a side note, I have an half Idea of building a couple of capacitive "wheels" and some touch buttons, to place under the glass.

I bought an Arduino clone that should arrive next week, and it seems simple enough. Maybe.   

I've seen a library that would do the trick, using one digital out as " source" and measuring the time that the various pins need to react, and I think two wheels would "eat" up 7 digitals I.O. , leaving 7 inputs for buttons.

Not so easy... the tricky part is designing the wheel plates, taking into account that the glass is 3mm thick, and then the software so that it ignore false touches.

On the other hand, the rotary encoders in my current, repurposed mouse wheels have a 15º step (24 positions in a complete turn), and I am not sure that I can manage to be able to do the same (the issue, mainly, being the glass thickness getting in the way of the single sensor spatial sensibility... the examples I have seen around, of pcb with drawn wheels, have something like 5 sectors).   

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on October 07, 2014, 07:55:58 PM
I started looking into the capacitive commands idea...

It looks like a lot more experimental than the rest of the stuff.

I hooked up the Arduino clone to a breadboard, with one 5M resistor, and a whole a4 sheet of aluminum foil as sensor, below a 3mm thick glass. It saw my hand from around 10 cm above the glass.

So, I cut out "the excess" of foil, and left a "sensor" of, more or less, the probable size of a finished button.
; the end result is something like this:


I based the trick on a library that can be found at (

I tried various values for the resistor, but for the moment I do not know what to make of the first results.

The whole gig seems to be a lot more "temperamental" than I'd really like it to be.

I hope I will be able to tell more, soon.


Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: Aerendraca on October 07, 2014, 10:11:50 PM
I think the reason its temperamental is because you don't have a ground plane for the switch. I think its the case that whilst you can get a capacitive button to work while it's 'floating', it becomes alot more stable when you have another piece of foil that is connected to ground and placed underneath separated with some tape. The point of this is to pull the capacitive button towards ground making it less floaty. This is typically how capacitive buttons are made up on PCBs.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on October 08, 2014, 03:08:51 PM
Thanks, I forgot that detail.

As ground, should I use the GND pin of the Arduino (which, I suppose, is the GND of the USB, and, through this, is grounded to the PC and the general ground dispersal), or would it be better to connect directly to grid's ground?

Oh, well' I'll see, next time I try.

For now, the oddest thing was that when I touched the glass, the capacity went DOWN, when she's supposed to rise. That was really baffling...

Thanks again, aerendraca.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: Aerendraca on October 08, 2014, 09:50:49 PM
Yes, I think it should be the ground of the arduino. Not sure about the capacitance going down, probably just an anomaly related to the absence of a ground.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on October 29, 2014, 06:23:35 PM
I still can't figure head or tail, of the capacitive side of things.

To restore my self-esteem, I tacled one of the issues of my set-up.

Namely that hidmacros, handy as it may be, does not switch configuration on a window name base, like the intuos driver can.

I wrote a small java program that kills HM, changes the hidmacros.xml file, and then restarts HM, when the foreground window change and it happens that the new window has associated a set of macros.

You can find it here:

it must be placed in the same directory as HIDMacros .exe.

When launched, he launches HIDMacros and then creates a directory called repository (or something, I may change it).

This will contain a "lock" file (to avoid launching more than one instance of the daemon), a list of ignored applications (explore.exe and others) which will be considered non existing, an xml file containing the skeleton of the macro it uses to "mark" each file, and a directory called "macros" containing a copy of the current hidmacros.xml configuration file (called, instead, generic_application.stored.xml).

Here, more copies will be added.

All the saved files are simply text, so you can change them as you better saw fit (as long as you do not "break" them... aside from the xml, the others are just columns of application's names, with no trailing spaces).

When hidmacros saves his config file, the daemon saves a copy of it in the repository, marking it with a "bogus" macro (actually, it's a"loopback" macro, that tells the daemon to show a credit message) and procedes, from then on, to replace the hidmacros file when you work with that window.

Said copy will be associated to the last "acceptable" window to have been in foreground (when you save using save configuration... Note: if the daemon needs to mark the macros set, it will kill and relaunch hidmacros so that the added/modified mark macro is visible).

It attaches an icon in the tray, through which he can be controlled.

On a double clicks, it shows the macro sets presently defined.

Right click, it shows a menu with stop, enable-desable-delete macros sets, enable/disable expansion mode options.

With the expansion mode disabled, "unknown" application are treated as instances of a "generic application", and thus a macro set named "generic application" is used.
As I said, it is just a copy of the hidmacros.xml file that was there when the daemon was first launched, but it can be modified as every other app.

When "expansion" is enabled, unknown applications are ignored till HIDmacros does not save his macros. Then, the recently saved set of macros is "hijacked" and used as that application, specific, set.

So, let's say I need to "port" the macros form photoshop to Manga studio.

All I have to do is open Photoshop, wait for the daemon to popping me that the switch of HM config has been done (unless the current is a file marked to be used with Photosop, however it takes an half second... I trimmed its timing more for less resource consumption than for user-friendliness), then alt-tab to manga studio and then, tab to hidmacros and re-save the configuration.

The daemon will see to it that that config will be saved as the one for Manga studio.

It is pretty crude, and probably can and should be tweaked-developed a lot (for example, could be added a "sudden-death, restart after a couple of minutes" feature, so that when you touch a dead accent key in your "main" keyboard, hidmacros is killed for a while, or a way to add some arbitrary modifier key) but, for the time being, this is as far as I can go with it.

If someone is proficient with java and wants to pick it up, the jar also contains the source code and the project files from Eclipse.

I know, it's an unholy mess... it is a couple of years that I do not program, so all the good habits were lost.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: Aerendraca on October 29, 2014, 11:16:55 PM
Excellent work DaBotz! I'll have to give this a go as it could be super useful in the future when i try to implement a leap motion controller to my build.

I think a whole bunch of bongofishes will find this tool useful.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on October 30, 2014, 12:39:31 PM
I hope it wil be appreciated.

Right now, my PC still runs on XP (HM relies on directInput, so it has some issues with mouses in Windows 7, for example), so it is tested only for that -
I hope it still works on other Windows(es).

However, the source code is inside the jar (alas, compiled and sources are "meshed", there is no separate "src folder"), so it should be simple to fix the errors that would arise on newer OS.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on November 05, 2014, 08:20:48 PM
I placed a revision of the "daemon" in the folder.

It no longer shuts down automatically when Hidmacros stops, rather I reversed the relationship... always
checking for HM was rather a resource hog, and sometimes misfired too. 

This version also allows to define "modifiers", i.e. a way to have more than one hot-keys layout for each application.

They are not so fast in response (something like a couple of seconds),  so they are not exactly the same as actual keyboard
modifier keys (Alt, Shift, Ctrl etc. ).

Also, they can't be combined... but, on the other hand, they are absolutely arbitrary, both in name, keys they are
latched onto, and duration .

Unfortunately, they are not that easy to set up.

More or less, you set the daemon in "Expanding mode", you define a macro with the modifier "call" in the base version
 of the macros you use with an application (if no "modifier" macros are present, the last version adds four sample calls),
save the macros to make it definitive, call the key that starts the modifier, wait till the demon says a new modifier
has been defined, and then save the macros again (possibly, after having switched back to the application you mean to
set the modifier for, just to be sure) so that it creates in the repository an aptly named
copy of HidMacros config file.

I'll have to build a wizard, one of these days.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on January 10, 2015, 09:47:34 PM
It seemed that I had a mishap with the USB hub, so I opened the UBiQ and made a short video.

I know It's messy but, please, don't shot the pianist.

Te actual mishap was this:
I disconnected the power cable to the screen, and hence the USB received some kind of spike that sent it in lock.

Once cut the juice again, and disconnected the usb cable, it all went back to normal.

I didn't expect UDB hubs to be able to require a complete reset...

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: Aerendraca on January 11, 2015, 09:50:00 AM
Nice video! That Gigantiq really is, well, gigantic! It's good to finally see the inside of your beast.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on January 13, 2015, 08:58:55 PM
As a side note, I have found a Intuos2 0608 (without pen) for 9$ (+ 25$ of shipping ... still a third of what some Spanish douche is asking for a  0405 - with pen).

I decided to use it as a complement to the Gigantic, mapping a 100x62 mm corner of it as mouse replacement, in general apps, and as jitter-free support for drawing my usual "scratchy" etchings in the Graphic apps...

Originally, I thought of placing a screen on top of it, of course.

But the controller for the LP116 I had lying around kind of drove crazy my desktop graphic board (I tried to use a DVI-HDMI plug... maybe that was the issue), so that has been put on hold.

On a side note, the Wacom 6.2.0w5 driver that I use seems uncapable of driving the Intuos4in CabinetiQ, though its release notes state taht it should be able to do so.

Is it possible that it is due to an uncomplete uninstall of the previous Intuos4 driver?   Misteryum fides.

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on March 06, 2015, 06:40:08 PM
Info 1: the guy who wrote HIDMacros released the code in GItHub.

It is in Delphi (damn), so I can't really manhandle it the way I'd like (never been a Delphi man, and TurboDelphi isn't freeware any-more anyway).

The main trick seems to be in the winhook.dll, so I could just flip it out and reverse enginer- merge it with my java daemon... but that's still a lot of work and I have other things to boil.


I revised the stupid daemon, it now has backups ( when you save, it also saves a copy of the old configuration, numbering it), allow to call "modifiers" (it's brutal... you switch between entire, alternative keyboards configurations) and for a toggle on/sleep (that can be called "through" HIDMacros) so that you can "snooze it" when you happen to change window often.  


Depending on the route of the USB cable, the naked XD-0608-U shows an Y-axis jiitter (on position and tilt) comparable to UBiQ (on screen - in mm on the board, the half).


I tried to use my old CabinetiQ, on a computer where I can't install my Lazynezumi pro... God, how much it sucks! No random noise, true, but lines got mangled by quite a bit of "geographic" jitter...

Also, as I cannibalized the old wheels and keyboard set-up for UBiQ, I found that having just Wacom's Ring and Hotkeys was unbearable for me.
I had to re-add at least a numeric pad, for tool selection.

I got used too much to the Big Ugly Beast.

Title: Re: Gigantiq - a tale of desmeasured greed - update(again)
Post by: DaBotz on April 02, 2016, 08:15:10 PM

I recently bought a "Classic pen", and started using it.

Yesterday, I had a bit of a problem with the USB hub I use for UBiQ and the other slow peripherals( keyboard and mouses).

Essentially, I had to reset it

After ferreting out the issue, I found that I was having some problems with the pen... and LESS with the old grip pen.

Popped out the button cover, and fiddled with the frequency screw, I found that the "Classic Pen" was out of tune with the XD-1218 inside UBiQ.

Re-tuned it, the jitter went down nicely to its historical minimum, as can be appreciated by this:

(Video captured with the pen lying on a stand).

I have a question... also the newer Intuos-es need to be tuned every now and then?

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: Aerendraca on April 03, 2016, 09:35:14 PM
Im not sure if the newer intuos pens have a way to tune them. Maybe I'll take the I4 pen apart and have a look.

Title: Gigantiq - The return of Gigantiq
Post by: DaBotz on July 16, 2016, 11:01:06 PM
OK... here I am again.

I finally decided to buy one of those cordless numeric pad, so I relegated my old "main" numeric pad to the sole tools selection ( and a couple of othe things) that I do not use too often, while the new cordless is devoted to the stuff I can't live without (zoom, brush size, lazy nezumi level, brush hardness and opacity... ).


However, over time I accumulated some little issues with my main build (all the other builds are still around and kicking)  - the glass has gotten a couple of small scratches in the middle of my "drawing area" - very shallow, around one cm long... but when I land on one, the sensation is - appropriately - grinding.

Also, at the time I forgot to re-place the upper frame to close off the panel ( that I had modified, nonetheless.... forgot, it was some 0.4 mm and I thought I was border-line functional, for the pen height from the tablet) and a couple of speckles of Dust have crept between the LCD and the diffuser... In all, it was time for an overhaul.

At the same time, I  finally managed to grab a LG IPS224v (that, apparently, is a good match for the I2 (
) at a good price and an Intuos 2 12x12 (at 26 Euros - then, 30 Euro of shipping made me say the same as many Italians: Fottute Poste!).


So, an Audacious plan formed in my head... use the 12x12 to test how things go with the LG and to check that I have the I2 take sizes correctly, in my sketch-up models, then build a case for the Intuos 2 12x18 and the LG and then, when all is ready, open the UBiQ, take out the panel ( it is kept in position by four screws),  sneak the Intuos 12x18 out ( it is kept in position by the screen, and the walls of the sub-assembly) and the Intuos 12x12 in, to use it as secondary windows screen... or something.

As test computer, having fried my last laptop (the graphic board), I am using a RapsberryPI B (my emergency torrent machine... had that power adapter fried a month later, it would be a PI2... twice the memory and six times faster, for the same money)...
Note: I lost some hours because I was so dumb as to try to build the wacom kernel driver on a 4gb sd card... one step requires installing some2 GB of source code, and the PI crashes - and becomes unresponsive, so one has to re-flash the OS - when it eats up all the available space.

With a 16GB card, it worked flawlessly, and I could see again the no-nonsense greatness of the LinuxWacom Driver: the Intuos 2 works, the intuos 4 works, the graphires work with that! And you can conjure up a swicth screen button in some 20', for the I2 (OK, getting the Intuos 4 oleds and buttons to work, it is possible but takes up an afternoon, and you have to draw your icons)


The level of my hubris knows no limits, really...

I started dismantling the LG (of course) after having tried the Bhrazz opening gambit ( I think that it interferes a little bit.... a magnitude less of  when I tested the stripped UBIQ the first time - I wanted to cry, when I tried that).  


The main board is a square, 11.5-12 cm of side, some 2 cm of "respect" depth - I'll have to revise my sketch-up model.


The cable to the buttons is some 15 cm long ( may need extending), and the cables to the led strip are similar. The builder to whom I  am inspiring myself, though, managed to extend the led strip cables using two of these


, so, extending should be doable.

However, the backplate is no aluminium at all but, rather, iron.

So, I am now pondering how to proceed forward, as I fear to damage the led bar, that seem to be clamped in place and kept by some solid looking edges...  


Before I forget, the panel is a LM215WF3(SL)(E1)


Fingers crossed... hoping I do not break anything .

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on August 17, 2016, 10:51:45 PM
As it turned out to be quite a different build, I opened a separate Thread, (

Title: Re: Gigantiq - a tale of desmeasured greed.
Post by: DaBotz on May 09, 2017, 08:52:19 PM
Update on the old big monster...

After having shoved a Intuos 2 12x12 inside, I did not use it much as a tablet, as I made the mistake of letting the tablet all on one side (as not to carve more the panel that holds it in the "subassembly" ).

However, these last few days I could not bear its black mass  any more (which was among the reasons why I decided to try with the LG 20MP48, when I got another Intuos 2 extralarge... also, I wanted an IPS led), so I decided to overhaul it a bit.

I planned changing its "front plate" to a yellow one (yes, it's cardboard... so, it is not a big work to do) and, as I was opening it, cleaning up a bit things ( I added some threaded holes in the back, last time I modified it, and let the wood dust go around) and centering both the screen, and the tablet behind it, around the middle line of the case (before, I left an offset to the right of a cm or so, so that I could leave  numeric pad on the left side).

I verified that, without the noise produced by the screen borders (or, maybe, by the bending of the EM field around the ends of the TCon board RF cage) , the jitter is down yet a notch and is on par with that that affects its successor's centre.

I do not know how I am going to use it, as its bulk is still a bit in the way ( though it is far less depressing, now that it is not a black slab any more)  of a use as a second Cintiq (or, ahem, 3rd cintiq, in my case) , but I wanted to report it.