As you can see from the video, I’m decoding the temp in Fahrenheit, but adding Celsius support would be really easy. All of the SV650 error codes; including the TPS adjustment indicator is supported. Right now the only real difference between my decoder and the stock dash is that you don’t need to short the two wires to read the error codes when there is an error- I automatically switch to displaying the codes when there is an error condition. It would be easy to support the default behavior of just turning on the EFI warning light and only showing the codes when in “dealer mode”.

All buttoned up in it’s enclosure:

I hope to be able to take video of the box on my race bike next week!

So I got the new boards back from OSH Park:

The boards look really good. I’m waiting on some parts to show up from Mouser, but was able to mostly populate the board with all the parts. The nylon standoff under the LED display really provides a lot of strength and stability, only issue being that it’s just a millimeter or so too long, but nothing that my grinder can’t easily fix.

Really looking forward to testing on Saturday in the shop and then hopefully on Monday for my first track day of the season at Thunderhill!

So my v2.0 boards were a complete dud.  Turns out some how I messed up the design and ended up wiring up the connector to the wiring harness backwards so nothing works.  Wasn’t a complete disaster- I was going to have to do another revision of the board either way, but it does slow things down.

Anyways, I just finished the v3.0 board design which:

• Fixes the pin out on the wiring harness connector
• Adds a 5mm LED for low fuel light warning
• Adds some holes in the PCB for adding standoffs to support the LED display
• Removes the terminal block option

Most everything should be pretty self explanatory, but I wanted to take a minute to explain the last item. The first version of the board didn’t have the OEM connector for plugging directly into the stock wiring harness, instead I had a terminal block to connect the wires. I ended up removing the terminal block from this version because:

1. I figured the majority of people would use the OEM connector
2. I was a bit worried about the reliability of using a terminal block- especially in racing
3. Adding the fuel light meant less available PCB space and needing to add a 6th connector
4. People can order the board without the OEM connector and solder directly

Top side of the v3.0 board

Back side of the v3.0 board.

Anyways, I just submitted the order to OSH Park today- should be a part of March 27th’s panel, and so I should have the boards back by mid-April.

So I got the v2.0 boards back today from OSH Park and they looked really good:

Front side of the v2.0 PCB

Back side of the v2.0 PCB

The back side of the PCB has solder holes for both the stock dash connector as well as a 5 screw terminal block in case you’ve already modified your wiring harness. As you can see, no problems mounting the connector for the wiring harness or LED display:

Front of PCB with all components mounted.

Back of v2.0 PCB board showing all components mounted

Side view of the PCB with all components mounted.

As you can see from the side view, I’ve “floated” the LED display off of the PCB. This was to make the LED closer to flush with the case once mounted and thus easier to read. The down side is that now the display is only supported by the 5 wires which isn’t very strong. So I’m probably going to have to add some holes to the PCB for some standoffs to support the LED display.

Front of case showing 3 warning lights and 4 digit display for error codes & water temp

As you can see, I’ve gotten pretty good with drilling the holes out for the indicator lights, but cutting that hole for the LED display was really painful. I used a sharp utility knife to cut the hole rather then a dremel to be more precise, but I just ended up getting a blister from working so hard. :(

Back of case showing connector for SV650 dash wiring harness

Here you can see the hole I cut with a dremel for the wiring harness connector. It’s serviceable but not that professional looking IMHO. One thing I haven’t done is cut a hole in the side of the case for the USB connector. Since I’ll be able to view the ECU error codes on the display, there’s no longer a need to plug in a computer to read the codes, so no hole. If I have to reprogram the Teensy board for any reason, it’s just two screws to remove the board from the case.

So I plan on testing the board on Saturday. Feel pretty confident that it should work. I do plan on doing another revision of the board to include:

1. Standoffs to support the LED display
2. A 5mm LED for low fuel light

The good news is that I’ve aslo mapped the ECU values to temperature so the 4 digit LED display can now have a secondary purpose: showing the water temperature when there isn’t an EFI error code. So basically, this little board will have everything you’ll need to remove the 2nd gen SV dash and run a GPX Pro, Starlane, AIM or other aftermarket dash unit.

But assuming the board works on Saturday, there’s no reason I can’t sell one of the other v2 prototype boards (will have everything except the low fuel light). The one thing I haven’t figured out is how I can accurately and easily cut the holes for the LED display and wiring harness connector. If I can’t come up with a better solution, I’ll probably end up including the case, but it’s up to the end user to cut the holes. I’m not really happy with that idea, but I can’t spend an hour on each unit trying to cut square holes with an exacto knife in ABS plastic.

So I got the first boards back from OSH Park:

And with the all the components populated:

And finally in the small ABS plastic enclosure:

At this point I decided to do a little more with my decoder and add:

1. LED display for decoding FI codes without a computer
2. Water temp decoding on LED display
3. Plug-n-play. No more cutting & soldering your wiring harness in order to connect.

All this while keeping the same form factor of a small 2.4″ X 2.27″ X 1.0″ box:

and back:

Normally you do this with the stock dash, but I wanted to use my GPX Pro dash and didn’t want two dashes on my race bike. Unfortunately, the PCB on the dash is just one large unit (including the tachometer) and so there wasn’t an easy way to just use the parts I needed (a red idiot light and the LCD which displays the error code).

I did some research and found out that the ECU to dash communication is a simple 7800 baud serial data stream comprised of 8 byte messages sent every 10 seconds. I ended up doing a quick prototype with an Arduino Uno board I had laying around:

Suzuki SV650 ECU/FI Warning Decoding via Arduino from synfinatic on Vimeo.

Once I got it working I quickly realized two things:

1. The Arduino board is too large and unwieldy to use on the motorcycle.
2. The Arduino uses it’s serial line for the USB which meant I had to do 7800 baud completely in software which used up a lot of CPU time.

I finally ended up picking the Teensy 2.0 board by PJRC. It’s about half the cost of an Arduino, a quarter of the size and has hardware serial support for both USB (good for logging) and on pins (good for listening to the ECU).

In the past I had played around with Eagle, but I always found it confusing and hard to use. This time I decided to try out DipTrace. Overall, I found DipTrace much easier to use, but it uses Wine under Linux/OSX and so it can be a bit buggy which really removed the polish from what overall seems to be a great app.

In the end I ended up with this board which is just a little bigger then 2×2″:

PCB board

The biggest surprise and hardest part of the whole project wasn’t writing the code for the Teensy or designing the circuit, but rather trying to find a nice enclosure for the board and then designing the board to fit it properly. Realizing you have to think in 3D space (I had to lay down the LM7805 power regulator so the cover would fit!) and figuring out where the mounting holes should go (the spec sheet for the enclosure was painfully obtuse about this).

Things I’d like to do in the next version:
1. LED display for printing EFI error codes so you don’t have to plug in your computer
2. Add support for displaying water temp (I’m using my GPX Pro for this, but it’s included in the data stream)
3. Find a source for the dash wiring harness connector so you don’t have to splice your wiring harness
4. Read tach signal (again I’m using GPX Pro so this is pretty redundant for my needs)

Overall, I’m in love with the GPX Pro- it’s a great cost effective solution for capturing and analyzing data while you are driving or riding (all my tests were done on my SV650 race bike). The unit is easy to install, use and surprisingly easy to read, even in strong sunlight- probably due to it’s use of a grey-scale LCD display rather then a color display that is used on laptops and iPads. The software “GPX Studio”, is also easy to use and has tons of great information, but unfortunately Windows only (no plans on a OSX or Linux port, but it works great under VMWare/Parallels). I really learn a lot by looking at my brake markers and corner speed.

XT Racing has the best customer service I’ve experienced- quickly responding to bug reports and feature requests. They have even helped me debug problems over a weekend so that I would have a properly working unit in time for my races!

There are a few problems that I have had with the GPX Pro:

They seem to have been fighting a reliability issue with their LCD display. I went through 3 units in one year (they’ve paid shipping both ways every time and even sent one 3-day so I’d have it in time for a race weekend). Apparently I’m not the only one having issues. They believe they’ve figured out the cause of the problem and my current unit has the “fix” and so far so good- it appears their solution has worked. Either way, I’m 100% confident that XT Racing will stand behind their product and resolve the issue.

The second issue is that the unit has to be reformatted/reset to factory defaults about once a year due to performance issues that crop up. After a while, the unit becomes so slow, that it just locks up and crashes. XT Racing claims it’s due to a file system issue that the flash memory is using (this problem I was told has been resolved in the newer GPX Pro 4/8 units). So far, the problem has always been fixed by reformatting the device, but doing so means you lose all your settings. The good news is that it takes a while for this problem to crop up, so I think I’ll only have to reformat my unit once a year.

XT Racing is a small company. That’s good because is means you don’t talk to some technical support guy, but rather to one of the engineers who designed the product if you have a problem. If you find a bug in the firmware/software they’re really good about fixing it right away (I know a guy who sent in a bug report on Friday afternoon and got the fix on Saturday in time for his races). XT Racing is also very willing to work with people- even making me a custom NPT threaded temperature sensor for my SV650.

The pros are:
- Very inexpensive for the features compared to the competition
- Easy to install & good documentation
- Software is easy to use (works fine under VMware/etc too if you run OSX/Linux)
- Great technical support. Their engineer has responded to my emails over the weekend and they’re very good about integrating feedback into their product.
- Amazing customer support.
- Their analysis software (GPX Studio) is a free download on their website and they’re happy to send you some sample data so you can play with it if you’d like to see what it can do.

Cons:
- Reliability could be improved

Basically XT Racing is a small company who seems very customer focused and has bent over backwards to make me a happy customer. I’m sure Starlane, AiM, MoTeC are great too, but IMHO the price/feature sweet spot is clearly with the GPX Pro.

Things definitely started on the wrong foot with the first race of the season being cancelled due to weather conditions. That left six races for the season- four at Thunderhill and two at Sonoma Raceway (aka Infineon, aka Sears Point). I had worked a fair bit on my fitness and mental preparation in the offseason and it definitely showed in my riding- I was much more consistent and my practice times were finally only a second or two off of my race times which really helped me with bike setup and consistency and confidence in my races.

That said, not everything went as planned. Halfway through the season at a trackday at Thunderhill, I started having problems with the transmission in my bike- specifically, the bike would jump down a gear under high load. Thanks to KC at BRG Racing I was able to get a “new” (meaning well used) motor in my bike just in time to make the next round. After talking with KC during the race weekend I realized that all this time I had been “doing it wrong” on downshifts and not blipping the throttle. Well at least we now knew what caused the transmission to start having problems after a year and a half. The problem was that I had tried to learn to blip the throttle a long time ago and just couldn’t seem to make it work at all. I talked to KC about it and the mechanics of body position, braking hard and blipping all at once and we quickly realized that I needed to change a few things and so I spent the rest of Saturday practice that weekend re-learning how to downshift.

Turned out I learned how to properly blip the throttle much quicker then I had hoped for and ended up having a good race weekend even though the high humidity was causing a lot of problems with the jetting and we were way way down on power. The next round was at Sonoma Raceway which started off badly when my front Woodcraft tire warmer stopped working due to a sliced wire (my fault) and I ended up sliding on my back at the top of Turn 3a on my out-lap on the last session of the day on Friday. We ended up getting the bike put back together late Saturday morning and ended up finishing the weekend in high spirits even though I had a hard set of races due to arm pump. I really want to thank Paolo at For The Track for lending me a front tire warmer for the races so that I didn’t have to go out on cold tires and Jose for giving me a replacement rear master so I could pass tech.

Thanks to Woodcraft’s great customer service, I got my tire warmer fixed in time for the final race of the year at Thunderhill. Unfortunately, I knew this spare motor I was running was way down on power and Thill being a horsepower track that left me at a much bigger disadvantage then at Sears.

Things didn’t really start out that well in my first race because the bike jumped out of gear twice during the race. Honestly, at this point I was ready to give up because I didn’t trust my equipment, but everyone on the team rallyed around me and helped motivate me to go out again. During the warmup lap I pushed the transmission hard to see if it would happen again and it seemed OK, so I decided to go for it.

My last race of the season was Formula IV which is dominated by guys on SV650 “superbikes” with GSXR front ends and even a guy racing a de-stroked Ducati 749 which people estimate makes almost 100HP. My poor bike with it’s hand-me-down old motor was dyno’d at 56HP after tuning and seemed to have a inconsistent gearbox problem. To say I’m not competitive is an understatement. But the transmission held up perfectly and I was able to find something extra in that race and have a good battle with Jason Vestri (#770) for almost the entire race. Looking back, I know I would of beat him to the line on the last lap had my rear tire not gone off (I had decided to go with a warm well used tire rather then a newer cold tire for the race), but woulda, coulda, shoulda- we’ll never know.

This was another hard year, between a rain out, getting taken out at one of the fastest corners and mechanical issues but I left with a real sense of accomplishment in that I know I really improved as a racer and even with all the ups and downs really enjoyed the year. But I also have come to the conclusion that it no longer makes sense to race without really competitive machinery (my ’99 SV650 will never be truly competitive with the EFI second gen SV’s which dominate the 650 Production class) and so I’ve decided to come back next year with a much better bike which should be able to compete up front of 650Twins and Formula IV. No more excuses, now it’ll all be on me!

Finally, I’d like to thank:

• KC and everyone at BRG Racing for building my motor, general mechanical support and all the mentorship throughout the year. KC’s love for the sport is infectious and he’s taught me a lot. You guys rock!
• Chris and the gang at CT Racing/Pirelli for hooking me up with those great Pirelli tires and the awesome service!
• Jim and Nickie at Catalyst Reaction and Dave at Feel The Track for handling all my suspension needs this year. You guys have always been there for me and made me feel like your most important customer time and time again!
• Helmut and Linda at Helimot for making the best fitting and safest leathers and gloves. I’ve been taken out, knocked off, run off and just plain rode over my head and each time your stuff has kept me safe!
• Jeff and Lance at Viets Performance for always hooking me up with parts at great prices so quickly. Knowing I can always count on you guys to get me the parts I need when I need them makes things a lot less stressful!
• Gerry at GP Frame & Wheel for keeping my bike straight when bad things happen
• All the AFM staff and turn workers who make each race weekend possible. Without your efforts there would not be an AFM!
• And last but not least my wife Wendy, who supports me every day and my crazy hobby of being a club motorcycle racer. I love you!

Looking forward to next year!

Overview

So basic summary of the above is, create a CF where each row corresponds to a date range of data for a single metric. Often times, you’ll see people suggesting making each bucket being a days worth of data. If you’re storing 5 minute averages, then that’s 288 columns/row.

Here’s an example CF for storing network interface counter statistics:

create column family InterfaceStatDaily
    with column_type = Standard
    and key_validation_class = AsciiType
    and comparator = LongType
    and default_validation_class = LongType
    and comment = 'Storage for 5min interface stats';

So I create rows like:

InterfaceStatDaily['myhost|eth0|ifInOctets|20121001'] = [
    [ 1349049600, 19245 ],
    [ 1349049900, 23475 ],
    [ 1349051200, 173445 ],
    ...
]

Would create a row for the ifInOctets counter on the network interface eth0 for myhost for Oct 01, 2012. The first value (at 00:00:00) is 19245 and the second value at 00:05:00 is 23475, etc. Notice I’m storing column names as LongTypes using Epoch time… this is much more disk space efficient then Time-UUID’s.

In my case, according to this calculator a column with a LongType name & value would be 31 bytes. However, we’re really only storing 12 bytes of data (4 bytes epoch + 8 byte value) so the vast majority of our disk space is overhead. In my case, a years worth of data for would be ~1.173TB/year (12 * 31 * 60 * 24 / 5 * 365 * 30000) just for the 5min values assuming 30K ports * 12 stats/port and doesn’t include replication (at RF=3 you’re talking nearly 3.6TB/year!), row/sstable overhead for indexes or bloom filters or creating aggregates. Even for a database like Cassandra which scales really well, this is stupid- especially if you’re trying to keep your nodes down to the 300-400GB recommended limit.

Using Vector Compression

The solution is to add a second Column Family:

create column family InterfaceStatCompressed
    with column_type = Standard
    and key_validation_class = AsciiType
    and comparator = LongType
    and default_validation_class = BytesType
    and comment = 'Vector compressed storage for 5min interface stats';

And then write your rows like this:

InterfaceStatCompressed['myhost|eth0|ifInOctets|2012'] = [
    [ 1349049600, Vector[19245, 23475, 173445, ... ],
    [ 1349136000, Vector[823445, 1366, 2343461, ... ],
    ...
]

First you’ll notice the row key is slightly different, instead of a day, the last part of the row key is the year. The column name is the start of each day in Epoch time. The next thing, is for a given column, rather then storing a single value, we store a vector of a days worth of data as a byte stream of 2,304 bytes (8 bytes/value * 288 values = 2,304).

Note, I wrote the above as Vector[xxx,xxx,xxx,...], but really what that means is converting all your values to 64bit integers, concatenating them together and writing them as a single value like:

0x0000000000004b2d0000000000005bb3000000000002a585

Which is the actual bytes for the first 3 values for the Vector[19245, 23475, 173445, ...].

Note: Our first idea was to write the data as an AsciiType of comma separated array of values. But it turns out this is less efficient then the above solution unless your data is very sparse or is storing small values as a comma separated array of 32bit hexadecimal values takes up to 2,591 bytes.

The advantage here is that the amount of overhead you’re dealing with is greatly reduced because now there are only 365 columns/year instead of 105,120. Compacting a day’s worth of 5min values in a single column as a byte vector and storing a years worth of data this way would result in only ~305GB/year (before replication, etc). This would require 2,327bytes/col (15 + 8 + 2,304), but that would store a day’s worth of 5min values (288) a savings of 74%. (~850,000Bytes stat/interface/year or ~10MB interface/year). Even better news: column families like this are highly compressible so you’ll get even better results if you enable compression!

If you have sparse data, for missing individual values I just used a ‘magic’ value of 2**64-2 as a placeholder. If for some reason, the entire days worth of data is zero (a common occurrence for me), I store the single value 2**64-1 rather then a vector of 288 copies of 2**64-2.

Bringing It All Together

The downside is of the InterfaceStatCompressed Column Family is that you have to do a read/write of a full day’s worth of data. That is usually great for reads since most applications like graphing require reading multiple datapoints anyways, but for writing the current values as you poll them, having to constantly read the current days worth of data, add the new datapoint and write the new column would kill our write performance.

The solution and best balance then is to write the current values to InterfaceStatDaily as they come in, and then once a day read the previous day’s complete row and write it to InterfaceStatCompressed and then delete the original row. That gives you the best of both worlds: high read and write throughput and reasonable disk space usage.

Of course, the down side of this is now you have your data in two different CF’s with different layouts. Hence you’ll need to wrap whatever API access layer you’re already using (Hector, Pycassa, etc) to intelligently query the two CF’s based on whatever date range you’re querying and return the values in a single format. However, considering the significant disk space savings, I found this to be well worth doing!

Work arounds for Time-UUID

Note: Often you’ll see recommendations to use Time-UUD’s because if there is a chance of two values getting the same timestamp as one write will overwrite the other. This can happen for a click stream (two users clicking on the same link at the same time), but won’t happen for things like interface stats. If your timestamps can’t be written at some kind of consistent interval (like 5 minutes in this example) then the solution above probably won’t work for you.

Ok, so what if you need to write your data at Time-UUID or your timestamps aren’t written at a specific interval? Well you can still use this solution, but with a few changes:

1. Specify InterfaceStatDaily to use TimeUUID as your column comparator
2. When writing InterfaceStatCompressed sum() all the values for each 5 minute interval and write that at set intervals.

Obviously doing this you will loose sub-5minute resolution (or whatever time interval you choose) in the compressed data, but you won’t be storing all those extra timestamps. If your needs require high precision timestamps for recent data and less precision for historical data then this may be a great work around.

If you don’t need high precision for current data, then one way to limit the differences in your CF’s and the wrapping API’s is to use Epoch column names with Counters for InterfaceStatDaily. That way every time someone clicks on a URL (or whatever you’re counting) in a 5 minute time period, you just increment the appropriate counter. Note that counters may not work well for every use case, so be sure to research their limitations before using them.

The key thing is when you run your daily vector compression job, you want to balance your time interval resolution to how often you actually are getting data. Ie: if you’re getting writes approximately every 60 seconds, don’t use 5 second resolution or the vast majority of your storage space will be the 2**64-2 place holders indicating no data!

“Honestly that’s a hard question for me to answer in words. Usually I’m pretty analytical about things and can logically explain things. Motorcycles and racing in particular isn’t at all like that for me.

At first I started racing because I wanted to be faster. No visions of glory, winning championships or grand goals really- they all seemed impossible at the time when I was struggling to do a 2:20 on my 748 at Thill. Hell, for a long time my only goal was “don’t finish last”. I’m not racing for bragging rights or trophies to collect dust in a cabinet although those things are fun and I enjoy them as much as anyone else I suppose.

The closest I can come up with why do I race now is, because that’s who I am. If I didn’t race a part of me would die along with it. I have plenty of hobbies- guns, photography, etc, but I don’t identify myself as a hunter, photographer, etc. I’m a motorcycle racer. Now I’d just like to be a better one.”