Project Logs

Collapse

• More commands | More nicey

  TinLethax • 08/31/2021 at 16:03 • 0 comments

  recently I came across the Linux commit by alistair23. The newer w9013 variant seems to support the X/Y tilting and Pen distance detection. In his commit have something that currently mainline doesn't have, It's the other commands. You can set the report rate and put device to sleep and wake them - via command obviously. Unfortunately, my w9013-s have the firmware version 0x0333 which isn't support the X/Y Tilting and Pen Distance report. but I yet to test the variable sample rate and sleep/wake mode, since this feature is really useful for my Wac0m RipOff BLE project.

  His version of wacom_i2c.c can be found here

• Wac0m RipOff BLE is here !

  TinLethax • 08/31/2021 at 07:50 • 0 comments

  I finally made the functional version of this project with Bluetooth (ignore the "Low energy" for now 😅). I'm using nRF51822 with Arduino core made by sandeepmistry on GitHub and I ported the HID code to make it compatible with Digitizer. I created new project page in Hackaday.io here.

• Wac0m RipOff BLE coming soon !

  TinLethax • 08/14/2021 at 05:01 • 0 comments

  I'm really excited to tell you that the next revision of Wac0m RipOff project is coming with Wireless Bluetooth Low energy support ! Yesterday I've been researching for the suitable Bluetooth-Capable MCU. I came across many like HC-05 with RN-42 firmware (HID capable), STM32WB (Also HID capable) and nRF51822 (Arduino compatible). but I decided to go with Arduino again this time because : USB is hard, Bluetooth is 1000 times harder! (Except for the last one). 

  first, the HC-05 module (based on BC417 made by CRS). Though the RN-42 firmware is just a firmware not really a code, but Someone on Arduino forum found out that in the firmware has the HID descriptor embedded byte by byte, and only way to implement my own HID descriptor is to modify the firmware. But there're couple reasons that keeping me away from using HC-05 

  1. I need to write the Python script to rearrange the memory address (the firmware is plain text) that look like this :

  @06eb31 0005 
  @06eb32 0001 
  @06eb33 0009
  @06eb34 0006

  That portion of code is the HID descriptor taken from that .xpv firmware file  

  That is possible to write some script to move the byte to next mem address (but since I don't code Python sadly), but the next reason is make it almost impossible.

  2. These HID descriptor likely has the pre-defined array size and event memory address is fixed. so I really need to dig down to the compiler + CPU programming manual. that will cost me (probably) years to finally made through it, but I don't have that much time. so I move to next solution

  Second, STM32WB. To be honest, I really love using STM32. It's IDE (CubeIDE, formerly knows as ACE) is based on Eclipse, and I've been using for 3 years now. It's really easy to use but also really advance in the same time. I came across the STM32WB30CE, BLE capable (via another Cortex M0 beside the main M4 core). I thought that the BLE middleware is really easy to use like USB (<- not easy, just not CRAZY COMPLEXT). Thing went unexpected. The BLE middleware is really complicated. Also in order to make radio works. It's required the external 32MHz Xtal (My habit : avoid using external OSC, just lazy to design the HF board). So again I abandoned this idea.

  Last one, nRF51822 (NRF51822-04 module to be precise). I came across video on the Hugatry's HackVlog YouTube channel making video about Arduino with that Nordic NRF thingy. I did some little research and find out that this Nordic chip is really flexible, I can literally remap i2c pin to any pin any where! so I only need a small nRF51 module board with couple pins exposed to use with Wacom w9013. All the thing to do is just to port the BLEHID library (done), port the sketch (done) and test it out (not yet, haven't buy that module). 

  Once I got the nRF51 module on hand. I'll make video about it too.

  P.S. for who wonder Why I don't go with ESP32. That thing is too powerful, I'd probably use 1 out of 10 from it. 

• Ported to Teensy++ 2.0

  TinLethax • 07/28/2021 at 15:53 • 0 comments

  two days ago, I ported the WacomRipOff project from STM32 to Teensyduino. And It works ! only change I've done is instead of using interrupt waiting to receive the data from w9013, polling is the way to go because the Interrupt on my teensy is buggy. Anyway here is the GitHub repo https://github.com/TiNredmc/WacomRipOff_Teensy

• Finally working!

  TinLethax • 07/26/2021 at 11:48 • 0 comments

  I finally make it working (at least on Windows 10). I already committed to my GitHub, so the latest code is now working! Also, I'm now understanding the way to report the correct hid event, so let me guide through. the number in parentheses corresponding to bit number of actual report. 

  Pen report only :

  -	(7)	(6)	In-range(5)	2nd barrel btn(4)	Eraser Tip Down (3)	1st barrel btn (2)	Invert (1)	Pen  Tip Down (0)
  No pen	0	0	0	0	0	0	0	0
  Pen Tip Hove	0	0	1	0	0	0	0	0
  Pen Tip Down	0	0	1	0	0	0	0	1
  Eraser Tip Hover	0	0	1	0	0	0	1	0
  Eraser Tip Down	0	0	1	0	1	0	1	0
  1st barrel BTN	0	0	1	0	0	1	0	X
  2nd barrel BTN	0	0	1	1	0	0	0	X

  X means don't care : can be Pen tip touch surface or just hovering.

  Total packet report :

  Report ID (fixed)	0 (7)	0 (6)	0 (5)	0(4)	0(3)	0(2)	1 (1)	0(0)
  Pen report	NULL	NULL	InRange	BT2	Ersr	BT1	invrt	Pen
  X (Lower byte)	7	<	-	-	-	-	-	0
  X (Upper byte)	15	<	-	-	-	-	-	8
  Y (Lower byte)	7	<	-	-	-	-	-	0
  Y (Higher byte)	15	<	-	-	-	-	-	8
  pressure (Lower Byte)	7	<	-	-	-	-	-	0
  pressure (Higher Byte)	15	<	-	-	-	-	-	8

  X max is 21424, Y max is 13390, Pressure max is 2047. all min at 0

• Many attempts had done, Really needs help.

  TinLethax • 06/25/2021 at 08:20 • 0 comments

  I've tried many way to report the event, but it seems like Windows and Linux has difference under the hood input HID system. BTW the HID descriptor I wrote is followed the Microsoft's Document about the necessary HID report and report sequence (hovering pen, pen down, eraser side hovering, etc...). But even I following the Microsoft's guideline. Windows is still acting weird, for example my STM32 doesn't even send the pen down bit, but windows just buggy thinking that the pen is down the whole time render this unusable.

  If anyone out there had knowledge about these USB HID report, Digitizer HID. Help would really be appreciated.

• digitizer is now working (partially)

  TinLethax • 06/12/2021 at 04:38 • 0 comments

  Couple minutes ago I finally get the USB HID work ! By changing the USB device name from "Wacom Rip off" to "Wac0m Rip off". I still had no idea why this change make the cursor actually move (as I said earlier that the "evtest" did shows event report). But I suspect that the word "Wacom" is used for driver probing (grep from device name to load driver, Name match ?).

  Anyway, There're main 3 problems

  1. Y axis is inverted

  2. Hovering the pen over the pad does generate event, but cursor doesn't move along unless pen tip is down

  3. Sometime Eraser side works with randomly having problem from number 2

  The 2 latest commits are on my GitHub repo. 

• USB HID is now report correctly

  TinLethax • 06/11/2021 at 14:25 • 0 comments

  I be able to get the STM32 to report the USB HID event correctly, But still can't move the cursor on both Windows 10 and Linux (Debian X.org). but for some reason, it's behaving like relative mouse on Android 11 (My Xperia 10 II). So anyway, the code is already on my GitHub repo.

• Code on GitHub.

  TinLethax • 06/08/2021 at 13:24 • 0 comments

  Here's the code I just push to my repo on GitHub, Note that I'm using the STM32F3 Discovery board (DISCO). here's the repo https://github.com/TiNredmc/WacomRipoff

• STM32 as USB HID and interfacing the w9013

  TinLethax • 06/08/2021 at 12:55 • 0 comments

  Yesterday I've been working with my STM32F3 Disco board to interface with the w9013 chip on the Wacom i2c digitizer. By far, I wrote the HID descriptor and be able to send packet to the host. but I still have problem interfacing with w9013 (probably I2C pull up problem). I will create new GitHub repo of this soon.

View all 10 project logs