I recently got wind of sweet deal on a Planet Eclipse eTek3 paintball marker and I took it. The gun is great. It's well designed, light, easy to use, and it's electronic.
Being me I naturally started to look into what upgrades, customizations, and hacks were available for it. I was surprised to find there were no hacks AT ALL to be found anywhere in Google for it. I figured at least people would be doing simple things like putting in circuits to simulate rapid trigger pulling... but nope; nothing out there. I did find all sorts of other parts I could spend large sums of money on to swap out the "board" (aka single sided PCB with a single MCU on it- this isn't rocket science) to something with more blinking lights and LCD's! Oooh boy! Oh no, wait. I'm not a 13 year old kid and I'm not dazzled by blinking lights and the ability to modify the colour of my OLED screen or -GASP- 2 MIPS!
All these wickedly overpriced and overhyped electronics did get me thinking so I opened up the marker and looked at the board.
I was pleasently surprised when I found that the heart of the stock board was a PIC18F1320 MCU (10 MIPS BTW). I know the PICs well and I immediately located the ICSP traces on the PCB. After a little rummaging around in the basement I found my USB Willem with ICSP header and wired the two together. I dumped the PIC and was not terribly surprised to find that the application code and bootloader were both read and write protected. I was more surprised to find that the on-chip eeprom memory was readable and writeable.
The hex values I saw were few enough that I thought they could easily map back to the variables the gun offered (trigger de-bounce, balls per second caps, dwell, shots to trigger auto-fire, etc.) so I reset the board to defaults, dumped the hex values and repeated the process making single changes. It was pretty easy to see what was what and I quickly figured out the math behind the hex -> real world value and the checksum routine. (8bit math FTW!)
Once I was pretty confident I could make a change and set the proper checksum I modified the values and wrote back to the PIC. I fired up the gun and verified that I had indeed changed the variable correctly (the firing mode to be safe) and I gave myself a pat on the back for spending about 4 hours to do what could be done with the board still in the gun in about 30 seconds. :p
The obvious goal was to see if I could put in a value that exceeded what the stock board would allow. For example, the stock board won't allow you to go over 15.4 balls per second in the ramping mode. An aftermarket board will go up to the theoretical physical limit of the gun which is ~25bps. I made the change, flashed the settings back, and fired up the gun. I was VERY excited to see the gun flash twice in the tens indicator proving that I had indeed just set the gun to shoot at 20bps - 4.6bps faster than "allowed"... for free.
Of course, just because the little blinking lights says it'll shoot 20bps doesn't mean it will so I loaded up some reballs and tested. WOW! 20bps is stupidly fast!
Up next: tweaking the values to make a full auto mode for the big game Sept 19 :D
P.S. I thought about detailing the entire hack along with how to decode the hex values and calculate the checksum but I think it's better not to. If you're not smart enough to read this post, do the work, and figure out the math on your own it's probably better off that you don't do it.
EDIT: Added links
Thursday, 2 September 2010
Monday, 10 May 2010
Easy Workaround for Oracle Linked Server Problem with TIMESTAMP(6) Column
I've got a lot of SQL servers at work. And those servers link to a lot of other servers. MySQL, Oracle, SQL 2005, 2008, etc.
For the most part linked servers are frowned on from my perspective but I can't keep people from getting things done so they do get setup. Most of the time the four part naming convention works just fine although MySQL in particular seems to need OPENQUERY Oracle never has... until today.
For some reason running a query against an 11g R1 Oracle DB kept returning this:
Msg 7354, Level 16, State 1, Line 1557
The OLE DB provider "OraOLEDB.Oracle" for linked server "XYZSERVER01" supplied invalid metadata for column "CREATEDDATE". The data type is not supported.
The column type in Oracle was timestamp(6) and no matter of cast or convert would avoid the problem. Selecting without the offending column still produced the error. I was about to start looking for newer OraOLEDB drivers when I thought about the MySQL issue. I also did a little checking and found this KB:
SELECT
*
FROM OPENQUERY(XYZSERVER, 'SELECT COUNT(foobar) FROM XYZSCHEMA.XYZTABLE')
Worked great; problem solved :)
I'm also going to pose the solution to the forum post below as it seems to be related...
http://social.msdn.microsoft.com/Forums/en/transactsql/thread/fd1cb0c8-efb5-4a94-b00d-b2aeb91dd771
For the most part linked servers are frowned on from my perspective but I can't keep people from getting things done so they do get setup. Most of the time the four part naming convention works just fine although MySQL in particular seems to need OPENQUERY Oracle never has... until today.
For some reason running a query against an 11g R1 Oracle DB kept returning this:
Msg 7354, Level 16, State 1, Line 1557
The OLE DB provider "OraOLEDB.Oracle" for linked server "XYZSERVER01" supplied invalid metadata for column "CREATEDDATE". The data type is not supported.
The column type in Oracle was timestamp(6) and no matter of cast or convert would avoid the problem. Selecting without the offending column still produced the error. I was about to start looking for newer OraOLEDB drivers when I thought about the MySQL issue. I also did a little checking and found this KB:
SELECT
*
FROM OPENQUERY(XYZSERVER, 'SELECT COUNT(foobar) FROM XYZSCHEMA.XYZTABLE')
Worked great; problem solved :)
I'm also going to pose the solution to the forum post below as it seems to be related...
http://social.msdn.microsoft.com/Forums/en/transactsql/thread/fd1cb0c8-efb5-4a94-b00d-b2aeb91dd771
Wednesday, 28 April 2010
Subaru Part Review: GrimmSpeed Up Pipe for 02-10 WRX
I got a GrimmSpeed uppipe today and I'm very impressed with the quality. I already have a GrimmSpeed crosspipe and this is right on par with the quality I expect. The welds are perfect, the flanges are thick and straight, and the coating is perfect. It's boderline artwork.
I was so impressed I decided to get some specs on it and post them up.
The inlet port to the upipe (exhaust manifold outlet) has a radius nearly 10mm larger than stock. The pipe tapers smoothly to the outlet (turbo inlet) where its radius is about 4mm larger than stock. The stock uppipe weighs in at about 7 - 7.5lbs and the GrimmSpeed piece is about 3 lbs lighter.
The lowdown:
If you're on the fence about this part hopefully this info plus the vendor info pushes you over the edge. It's a solidly built piece and you won't be disappointed.
If you're in Canada, support Touge Tuning. I've had nothing but excellent experiences with them and from what I can tell their prices can't be beat!

I was so impressed I decided to get some specs on it and post them up.
The inlet port to the upipe (exhaust manifold outlet) has a radius nearly 10mm larger than stock. The pipe tapers smoothly to the outlet (turbo inlet) where its radius is about 4mm larger than stock. The stock uppipe weighs in at about 7 - 7.5lbs and the GrimmSpeed piece is about 3 lbs lighter.
The lowdown:
- thicker flanges
- ceramic coating for to keep the heat in
- mandrel bent pipe vs. stock crush bends
- ~20mm diameter larger inlet (94.56mm) & ~8mm larger outlet (86.76mm)
- 3lbs weight savings
If you're on the fence about this part hopefully this info plus the vendor info pushes you over the edge. It's a solidly built piece and you won't be disappointed.
If you're in Canada, support Touge Tuning. I've had nothing but excellent experiences with them and from what I can tell their prices can't be beat!

Tuesday, 20 April 2010
MS DTC Problems With Oracle Linked Server & Windows 2008 x64 R2 Cluster (Server: Msg 7391, Level 16, State 1)
If you are getting this error (Server: Msg 7391, Level 16, State 1) trying to run a transaction using a linked Oracle server then I may have the fix you're looking for. I had to troubleshoot a problem with a new Windows 2008 Enterprise R2 x64 cluster today that was a real pain.
To get things ready normally you need to at least do the following:
Normally things would work at this point. No such luck today though! No matter what I did I couldn't get a specific stored procedure a user wrote to without firing off the "unable to enlist" error. Other DTC transactions worked just fine.
The solution was simple (but tricky for non-Oracle DBAs); I had to install the "Oracle Services for Microsoft Transaction Server 11.1.0.7.0" service and reboot.
Now, I *could* have re-written the query but since it was already working on another QA box and the user is going to be re-working the whole solution shortly I didn't see much point. Plus I wanted to know HOW or IF it could be made to work on this cluster! ;)
Hope this helps someone else out there!
-A
To get things ready normally you need to at least do the following:
- install the Oracle drivers & reboot
- set "allow in process" on the provider in SQL
- ensure the default DTC is the clustered resource
- enabled DTC for network access and set correct authentication.
Normally things would work at this point. No such luck today though! No matter what I did I couldn't get a specific stored procedure a user wrote to without firing off the "unable to enlist" error. Other DTC transactions worked just fine.
The solution was simple (but tricky for non-Oracle DBAs); I had to install the "Oracle Services for Microsoft Transaction Server 11.1.0.7.0" service and reboot.
Now, I *could* have re-written the query but since it was already working on another QA box and the user is going to be re-working the whole solution shortly I didn't see much point. Plus I wanted to know HOW or IF it could be made to work on this cluster! ;)
Hope this helps someone else out there!
-A
Subscribe to:
Posts (Atom)