Archive for the ‘projects’ Category:
04 Aug
Looking at our data trends for VIN API, we show about 15% of all requests are for the complete data set. It's the same price as the basic data set and rich with a ton of data.
Check out the data set from this post over 1 and half years ago. On top of the basic data set's year, make and model, the complete data set comes with data like MSRP, MPG (city and highway), dealer invoice, gas tank size, etc.
We get tons of hits for basic data, but at no additional charge we also provide the complete data set. Just add a complete
=> "true" to your request. So simple and there's no performance hit.
For more information, check out or examples and faq.
Enjoy!
Here's another look at the data elements from a comprehensive query:
27 Jul
Been playing around with a lot of USB devices lately, to get them to play nicely with some of our touch screen Rails apps.
One of the devices is a card reader - specifically a MagTek reader, and the same code works for the ELO reader.
I've tried a billion different ways to ensure we're reading in all the data. At first, I was just asking the usb stream to present me with a certain number of characters, b/c that's how all the examples do it.
But we're using a lot of different cards with the readers, so that didn't work too well. So now I just read one character at a time until we find the new line.
Here's the code to find the device, open it, close it and read from it, all whilst finding and converting the data as required.
So using this code, we take the swiped data and send it to our server for storage.
26 Jul
I'm using the topaz model T L462 HSB. It's nice now that it works. But what a PITA to get it going. The biggest problem with the device is the documentation. There is no low level documentation explaining the representation of the bytes coming in over usb. So you are stuck using their libraries which expose some poorly explained API.
Anyway, like I said, great when it works. So I'm working in linux which basically leaves me having to use java libs and a shared object file.
Here's my code:
It sits and waits until the sig pad gets some points on it. Once we have points it waits for a lapse in time where there is no change in the number of points.
Once we've decided that we have captured a signature, we store it to a file.
Then we shell out to a ruby script - see the httpi and curb article - which is how I get the file to our rails server for display and verification from the user.
Now, you'll need a few files. Most of which can be found in the java zip download from the vendor site.
From that zip, you should grab the following:
SigPlus2_60.jar
RXTXcomm.jar
libSigUsb.so - if you need the 64 bit version, go here - http://www.topazsystems.com/Software/libSigUsb7242012.zip
Then I just used eclipse to set everything up and build. Works well so far.
The only thing you may need to change is the model (I have mine set to SignatureGem1X5) and com port (I have mine set to HID1).
15 Nov
If the apk is not available for download yet, you can build it yourself with the fix from here.
Step 1 - Grab the source from svn -
svn checkout http://azilink.googlecode.com/svn/trunk/ azilink-read-only
Step 2 - Update the UdpDriver.java per this azilink issue.
Step 3 - Build and install the apk
# this will give you a build.xml file
android update project --target 2 --path /path/to/your/azilinkdownload/
# after plugging in your device and from your azilink project directory
ant debug install
Step 4 - Install Open VPN
sudo apt-get install openvpn
Step 5 - Grab the azilnk.ovpn file from the downloads section.
Place somewhere you won't lose it.
Step 6 - Copy this resolv.azilink file to the same place as the azilink.ovpn
Step 7 - Copy this azilink script to somewhere you can get to it
Step 8 - Start azilink on your phone.
Step 9 - Run the script from step 7.
That's it.
24 Jan
It can't be a shock to any of you that after many months (wait - more like a full year) of running VIN API completely free and out-of-pocket, it is time to monetize. As I am sure most of you know, the back-end data is quite pricey. For example, a monthly subscription for a "lite" data set (your typical year, make, model, engine type, etc) at one of the better known distributors would run you about $260.00 a month for ~800 VIN decodings. This is some very expensive data at 32.5 cents a VIN. Some of you that use our API are running 50,000+ VINs through in a weekend, that is $16,000! Wow!
Ok, so what did we decide to do? Well first, and most importantly, we decided to keep the service up and running; for a while there it was looking pretty bleak and if you take a second to look at the numbers (financially) you can understand why. Anyway, to be as fair as possible, we did not feel this could be monetized as a subscription-based product, some months you need 500,000 VINs and some only a 1,000. Looking at the data for year, we had many questions - what plan would you pick? should the plan rollover it's unused decodings?
We discovered a lot of complexity in the subscription model, so we decided to setup the pay as you go plan, where you buy your decodings at various bulk levels. For instance, you could buy in groups of 1,000 or 10,000 or 100,000 such that you would realize savings on a price-per-VIN basis the larger the group you purchase. There is no use policy either, so you can sit on the VINs for as long as you want, or you can even buy decodings the day (even the minute) before you need them. No monthly credit card bill, no rollovers, just simple "buy what you need," and if you buy in bulk, you save.
Another consideration in doing this was having to maintain soft limits. For example, if the user purchases the 5,000 VINs per month plan, and the their site does well this month and they need 6000 VINs, should they have chosen the 10,000 VIN plan? We didn't think so, we figured no hard limit, just soft limits, and after the soft limit is hit, we would charge the additional VINs at the current rate per VIN to the user's next month's bill. We tried to explain this to a few current users that are helping us come up with reasonable rates and they were not all that thrilled about it. So we had a problem, we did not want users to pay for what they did not need, but at the same time we did not want to cut users off in the middle of a month when they hit their limit. That entire idea had to be scrapped and along with it went the idea behind the subscription plan itself. We like it though, it's simple now - buy your decodings and use your decodings, we will email you if you are getting low and may want to add decodings to your account.
Subscription models are great for static resources and static services, but not a single one of our customers decodes the same number of VINs each month, so it just won't work. So onward and upward, pay as you go and regardless of how the other API providers offer their service, we are excited to be a little different and lot cheaper as you will soon find out.
Enjoy!
17 Jan
Thanks go to Michael for sharing his hard work with the rest of you VIN API and PHP developers 🙂
I hope this helps -
13 Jan
A few of our VIN API customers have been kind enough to take our Ruby and curl examples and come up with .NET and PHP implementations.
Here is a VB .NET example:
And for PHP, you have this:
Hope this helps and if you have examples for other programming languages, please let us know.
13 Jan
We've just finished adding A LOT more details to VIN API's result set. This time we've added things like MPG, MSRP, cargo room/volumn, etc. See the full list below, it is very comprehensive.
If you use ruby (look for a future post with .NET and PHP examples), and want the complete dataset, you would setup your ActiveResource like this:
And then call our API like this:
The only change (for those of you who have already implemented phase I) is to send in a "complete" parameter with value of "true" ... upon doing so, VIN API will send you the complete dataset versus the basic (and default) dataset.
The results would look like this (in XML) and be prepared because it is lengthy:
That's it, just thought I'd share VIN API's Phase II.
05 Jan
It was very strange, I got a new 2 TB external USB drive for Christmas and I noticed a number of windows (nautilus windows) opening up throughout the night. So I would wake up to find 20 - 30 windows opened to the media mount directory (/media). Overtime and watching the logs, I noticed that the new USB drive was disconnecting itself and then reconnecting. As it would reconnect and mount, the new mount point /media/<some long character string> would pop open in a nautilus window. When the drive would eventually disconnect, the opened nautilus window would no longer have access to the data and would display contents from one directory up (/media). After a couple days I finally found the answer and tried it and it worked as advertised.
For those having the same problem, this is where I found the solution you see below.
$ sudo sdparm --clear STANDBY -6 /dev/sdb
# note that your device could be something else, for example - /dev/sd<something>
And if you get an error, something like this:
change_mode_page: failed fetching page: Power condition
Then you should be able to use hdparm instead, like this:
sudo hdparm -S 0 /dev/sdb
07 Sep
Just a quick note about the Open Flash Chart II plugin for Rails and Rails 3. Rails 3 did a 180 with regards to ERB tags and security. Everything is now considered unsafe HTML. So where we used to be able to do <%= @graph %>, we have to now do <%= @graph.html_safe %>.
Thanks go to kendagriff.
