So my initial testing of an ESP-12E showed that it couldn’t reliably keep up with two 10K PPR encoders (40K count). I discussed this project a great deal with my fellow astronomers on CloudyNights. After doing a lot more research and testing I’ve determined that the ESP8266 even when running at 160Mhz just can’t keep up with two 10K PPR encoders. Continue reading
So yesterday I was all happy that I got my prototype ESP-DSC working. This ended up being short lived as I realized this morning that while it does technically work, the ESP8266 can’t keep up with two medium resolution (2,500 CPR) encoders.
Ironically, I found out that the code was too slow when I started to optimize the code and I realized that the code I has was very very conservative. My original optimization was to speed it up, but maintain that conservative ethos. I figured while I was editing the code, I might as well also add a test to see if the ESP-12F was dropping interrupts… Continue reading
Spent most of my post-St. Patricks day writing code for the ESP-DSC. The big question was always does the ESP-12E have enough horsepower to handle both the encoders as well as doing all the WiFi/communications. So far, I’ve bench tested a pair of 2.5k CPR encoders which translate into 10K encoders after quadrature decoding. Continue reading
So a few years ago, I announced TeensyDSC, project that brings telescope digital setting circles to the iPad and Android devices using WiFi. I’ve been using my TeensyDSC successfully with my telescope and SkySafari on an iPad for a few years, but one thing always bothered me about it: the “COGS” (cost of goods sold) of the TeensyDSC was really expensive: nearly $100. A lot of that cost was in two parts: the Teensy 3.1 ($20) and RN-XV WiFi module ($35).
So I’ve been using EaglePCB for a number of years. I’ve designed and created some open source projects like my SV650 ECU Decoder and TeensyDSC. While I had a cheap ($79) commercial license for a one off commercial project I did, most of my work was done using the $169 “Maker” version for non-commercial use.
Then mid-2016, Eagle was bought by AutoDesk. I’ve only used one AutoDesk product before: Fusion360 which I really like. Sure, it’s not as good as SolidWorks, but I’ve designed parts for both CNC and 3D printing and they’ve come out great. And to top it off, AutoDesk is very gracious in it’s licensing terms- allowing makers like me to use it for free.
So spent a bunch of the time in the garage this weekend working on reverse engineering the SDS protocol on the SV650. SDS is basically ISO9141 aka K-Line which something you often see in a car’s ODB-II port. Unfortunately, SDS is just different enough that you can’t use any commercial off the shelf ODB-II reader to read the messages. The way I have been going about this was pretty painful and taking a lot of time/effort to iterate over so I came up with a new tool chain.
As racers, we’re always looking for an advantage over the competition- better brakes, exhaust, motor work, titanium bolts to reduce unsprung weight- you name it. With the advent of modern electronics, now data logging and analysis is becoming available for not just pro-racers, but club racers as well.
Most data loggers talk about how awesome their hardware is… see how sleek and sexy it looks? It has all kinds of features like GPS and accelerometers which are sampling at many times a second. Just imagine how much data you’ll collect! So then you install the data logger on your bike and you can’t wait until you can go out on track and try it out. Everything is great! Until…
So long story short, I replaced my old GPX Pro with an AiM MXL2 dash. One of the nice things is that the dash supports the Suzuki SDS protocol for the GSXR. SDS is sorta like ODBII for cars- if you’ve ever heard of a “K-Line”, well that is pretty much SDS. Long story short, the MXL2 dash can decode some of the sensors (TPS for example) but others are pretty far off (water temp).
I reached out to AiM to see if they could fix it, but they didn’t have the information necessary to fix their decoding of the messages. They suggested reaching out to Suzuki to get the specs, but I don’t know anyone there and nobody I know seems to know anyone there…
Long story short, I’m going to reverse engineer it myself.
So if you’ve been reading my blog, you know I created a SV650 ECU Decoder which decodes the data stream from the ECU that normally would go to the OEM dash. Recently I upgraded from the GPX Pro to the more powerful and physically bigger AiM MXL2.
So here’s the problem- the new dash is bigger which means I’m having a harder time finding a visible mounting point for my ECU decoder. And while the MXL2 can decode things like water temp, TPS and gear position from the ECU, it can’t decode any EFI warning codes. I didn’t like the prospect of not knowing when the bike was misbehaving due to a bad sensor or damaged wiring harness so I needed to come up with a solution. Continue reading
After comparing AiM, Race-Technology, MoTeC, AEM, RaceCapture/Pro, GEMS, XT Racing, TraqMate, VBox and 2D data logger offerings, I decided to go with the AiM MXL2 for my race bike to replace my XT Racing GPX Pro.
There’s a number of reasons for choosing AiM and their MXL2 over the others, but here’s the short version:
- Software. After using the XT Racing GPX Pro for five years I learned how the hardware is only half of the equation. It doesn’t matter how much data you collect if you can’t display that data as actionable information.
- Support. Many of these companies don’t have any support here in the USA and their support suffers. Even when the company is native English speaking it can take weeks for them to answer even basic questions about their product. AiM often responds in less then 24 hours!
- Pricing. Some companies seem a lot less expensive then AiM until you realize they start charging you extra for critical features that AiM includes by default. That and AiM never charges for software/firmware updates for the life of the product can mean saving hundreds of dollars over the lifetime of the unit.
- Features. The MXL2 is the latest generation hardware from AiM and it has many features that other high-end vendors like MoTeC and 2D charge thousands of dollars more for.
- Ease of Use. Data logging in motorsports has been going on for nearly two decades and many vendors have software which look like it would be more at home running under Windows 95 rather then a modern operating system. AiM is in the process of rewriting their Race Studio Analysis software to take advantage of modern UI design.
- Education. AiM is the only vendor I could find that not only has a lot of Youtube videos explaining how to use their software, but also offer inexpensive classes around the country. I just finished two days worth of classes (cost me $80) and learned not only a lot about AiM’s products and software, but also a lot about how to analyze the data which isn’t really obvious when you’re first starting out.
- Quality. Once you look at the wiring harness connectors on the MXL2 you know this is a serious piece of equipment. The dash is billet aluminum and the buttons are solid. Everything about it exudes quality. Actually, the dash is so solid that I decided to re-enforce the front fairing stay on my motorcycle to make sure it could handle the extra weight!
There are some risks though- AiM while very big in the automotive club racing scene it has a very small (but growing) presence in motorcycles. The good news is that there are very few features that are specific to cars or bikes, so whatever enhancements are added over time should carry over. That said, the factory MotoAmerica Yamaha Team is also using the MXL2 so I’m sure the bikes won’t be ignored completely.