STN1110 Bluetooth OBD-II Adapter

Update:  The STN1110 readers have been “discontinued” in favor of my new  STN1170-based Bluetooth OBDII Reader!  “Discontinued” really only means that I’m not actively producing the STN1110 based reader anymore.  Parts are still available and software updates will probably continue to be released by Scantool.net.  I will of course link to those updates as I have in the past.  The only reason I’m discontinuing the STN1110 reader is that I don’t have the time to support producing two different units that pretty much do the same thing (the STN1170 does more in fact).

This page contains all the information for all the legacy Bluetooth OBD-II modules I’ve designed.  These are by far the smallest modules of their kind that I’ve seen.  I have an agreement with Scantool.net to open-source my designs.  The majority of my adapters are based on their STN1110 chip (ELM327 compatible).  All of my Bluetooth OBD-II modules work very well with Scantool.net‘s ScanXL OBD-II diagnostic software for Windows.  Check it out!

For Android users, my Bluetooth OBD-II adapters are an excellent companion for the Torque app ($5 on the Android Market), which is easily the best OBD-II software available for any Android smart phone or tablet.

Palm Pilot and PocketPC users can use OBDGauge, although both of these configurations are untested with my adapters.  Essentially as long as you can pair your Palm Pilot or PocketPC device to my adapter via Bluetooth, OBDGauge should be able to communicate with my adapter.

IPhone/IPod/IPad owners will not be able to use my Bluetooth adapters with their Apple products due to the lack of an Apple authentication chip in my BT module (the BT module also doesn’t support Apple’s authentication protocol).  If you have an Apple device, you will have to purchase a wifi ad-hoc OBD-II adapter if you want a wireless link to your vehicle.  Apple also makes it prohibitively expensive and complicated for hobby type people wanting to connect something via Bluetooth to their iOS device.  I’m not sure if this is also the case with OSX.

Right now I have 5 different modules to choose from, although since Sparkfun discontinued the one Bluetooth module I was using, there are really only 3 modules that have parts available to build.   PCBs and assembled units are available for purchase below (and kits too, but post a message for kit purchase details as they may or may not be in stock at any given time).  The modules aren’t too hard to build yourself, but there are small parts on the unit, which enable this module to be the smallest OBD-II Bluetooth modules on the market today.  It is smaller than the OBDLink MX, which claims to be the smallest adapter in the world.  The smallest passive parts are 0603 and the smallest pin pitch for an IC is 0.5mm.  There aren’t any QFN/DFN/BGA…etc kind of crap on my modules.

Here’s a quick and dirty manual I created that explains how to connect up my modules (or any OBD-II module really) to your vehicle and pair it to your Android phone.  For other operating systems, the process is essentially the same, but not covered in the manual.  Download the manual here:  Bluetooth OBD-II Adapter Manual

To make a complete module, two boards are needed: a driver board and a Bluetooth board.  A STN1110 based Bluetooth board requires the STN1110 universal driver board and likewise, an ELM327 based Bluetooth board requires an ELM327 universal driver board.

Please note that for shipping destinations outside of the USA I am not responsible for any extra customs/duty fees that may be encountered when importing happens, and I am not responsible for lost packages outside of the USA.  A tracking number will be provided if there is one available (depends on shipping method).  If you don’t receive your package within say 4 weeks of me informing you that I shipped your item, I can provide customs form numbers so that you can check with your country’s customs office to see if they have your package. The untracked international shipping method should arrive somewhere between 2-4 weeks of when I tell you the item has shipped. You will not see tracking updates once the package leaves the USA. The tracked international shipping option will get your adapter to you within 1-2 weeks, and the package is tracked the entire trip.

Kits:

RN-42 (FCC Certified) STN1110 Bluetooth Module Kit
Unassembled Kit w/ All Parts
A kit will contain a minimally assembled driver PCB and Bluetooth PCB.  You’ll be responsible for soldering down pretty much all the parts.  Assembly drawings and a page of directions to assemble the kit is included.  All this stuff are available to download via links above. Please read through the kit directions before ordering the kit so that you have some idea of the task you are going to undertake. I can provide some help, but as this is a kit, it is your responsibility to properly assemble, test, and program the unit to your liking. The only assembled/tested piece of the module is the 12V to 5V supply in the kit.  Please leave a comment to purchase a kit as they may or may not be in stock.
Kit: $60 Shipped (USA), $95 Shipped (International, tracked)

Genuine STN1110 Bluetooth OBDII PCBs:

Genuine STN1110 very low-power consumption FCC certified Bluetooth board STN1110 Universal Driver Board Genuine STN1110 non-FCC certified Bluetooth board

RN-42 TopRN-42 Bottom

STN1110 Driver TopSTN1110 Driver Bottom

Bare PCB Only: $13 shipped (USA)
$23 shipped to other countries

Shipping Destination

Bare PCB Only: $13 shipped (USA)
$23 shipped to other countries

Shipping Destination

Out of stock

 

Genuine ELM327 OBDII Bluetooth PCBs:

ELM327 Universal Driver Board Genuine ELM327 non-FCC certified Bluetooth board

Just for completeness, the following modules were also designed, but cannot be built anymore because the BTM-182 Bluetooth module is no longer obtainable:

Genuine STN1110 Bluetooth board (BTM-182 not available) Genuine ELM327 Bluetooth board (BTM-182 not available)

If there is some interest, I could also create a ELM327 based module with the FCC certified Bluetooth module.  I use only genuine STN1110/ELM327 chips in my designs, not ripped-off versions of the ELM327 like the blue Chinese modules on Ebay.

All the designs were created in Altium Designer.  Each zip file contains the Altium source binaries, gerbers, a BOM, a PDF of the schematics, and an assembly drawing showing where all the parts go.

You’ll also need the information in this text file to set up the STN1110/ELM327 chips and their corresponding Bluetooth module on the board:  OBD-II Adapter Setup Commands.  Essentially what needs to be done is both the Bluetooth module’s UART and STN1110/ELM327 UART need to be at the same baud rate to communicate.  On all Bluetooth modules except the RN-42, you have to connect up to the UART side of the Bluetooth module (the side the OBD-II interpreter chip connects to) and enter the module’s command mode and send it commands to get it to match the baud rate of the OBD-II interpreter chip.  On my modules, I have the OBD-II interpreter chips configured to run at 115.2kbps (although they can go higher…I just haven’t tested them higher).

 


The Bluetooth OBD-II adapter is copyrighted under the Creative Commons Attribution 3.0 license.  If you use these sources for creating your own module that you post online, please attribute my module as the original source (as the license states).


 

Creative Commons License
OBDII Bluetooth Module by Andrew Honecker is licensed under a Creative Commons Attribution 3.0 Unported License.

129 Responses to STN1110 Bluetooth OBD-II Adapter

  1. John says:

    This is an awesome project Andy, great job! I’m currently trying to gather information to see what hardware would be best for my project. What I’m trying to do is dump/flash the ECM, it would be for vehicles that use J1850 VPW (GM). Problem is I can’t seem to find hardware that is reasonably priced to do this, I only found a few options and no longer in production sadly. To get to my point, I need hardware that is capable of J1850 VPW 41.6k baud (called 4x mode) and supports in-frame responses. Is it possible to do this with the stn1110? I’m hearing mixed answers. Thanks, -John.

    • Andy says:

      John,

      Well…this is getting past what the STN1110 datasheet says and what it’s typical uses are. If you google for “gm vpw high speed”, the 1st link at scantool.net has one of their employees saying outright that they don’t support VPW 4x mode. For your other question w/ in frame responses, there’s a good chance that’s not supported either.

      You could post on scantool and see if they have any plans for supporting VPW 4x mode and whether or not the in-frame responses would work too. Alternatively, you could email Vitaliy at scantool directly (vitaliy at scantool dot net). He should get back to you pretty quickly, and he’s usually the one to answer the boat loads of questions on a number of forums.

      -Andy

  2. please do add Apple authentication chip in BT module.. so that iPhone user can also use this.

    • Andy says:

      Hi,

      Well…this isn’t so much of a “hardware isn’t available” kinda thing. Even if I made an official apple-compatible Bluetooth OBDII reader, there’s no software support to use it. So while it’s great and all that such a thing would exist, w/o software support, it’s kinda useless =). If you have a jailbroken Iphone, you can certainly connect to my adapter, but unless I didn’t look very hard, I wasn’t able to find any Iphone OBDII software that worked w/ ELM327 (or compatible) OBDII readers. Besides just basic software support, you’d probably want software that didn’t suck too and that had all the bells and whistles of something like Rev for the Iphone (which doesn’t support Bluetooth anything).

      If you really want to use the Iphone and Rev (or some other similar app), your best bet is a wifi adapter. I haven’t made one of those as most wifi modules are expensive, bulky, and power hungry, all of which aren’t what I’m looking for in a device to be plugged in and left installed in a vehicle.

      Plus the whole making a device Apple certified really squashes out the little guys. I don’t have the time or resources to deal w/ Apple and their certification process, nor do I want to pay them royalties. Whatever I made for the Iphone wouldn’t be able to be open source either, which is sucky.

      Hope this helps!

      -Andy

  3. Mansour says:

    Hi Andy,

    I’d like to know if you have complete units ready to ship and if so, how long do you think shipping to Australia will take.

    Thanks

  4. Tiaan Alberts says:

    Hi Andy,

    What will you charge for the following (separate prices please). I will either buy the one or the other:
    10 Assembled units
    10 Kits
    It is for international shipping.

    Regards
    Tiaan

  5. balu123 says:

    Hi Andy

    Could you tell me if you have unassembled Kit STN1110 with RN-42 in stock? What are the advantages between elm327 and STN1110 device. Can I diagnose volkswagen group with this device via android mobile (like with vcds or vag-com)?

    Thank you

    • Andy says:

      Hi,

      I sent you a email about the kit.

      Regarding the STN1110 vs. ELM327, check this out: Granted that’s from the manufacturer of the STN1110, but the only disadvantage (which I’ve mentioned on here before) is that the STN1110 does draw more power than the ELM327 when it is operating. However, when the STN1110’s low power modes are used (which my module takes advantage of), the STN1110 does go into a very low power state when it’s not being used and when power consumption matters most: when your vehicle’s engine isn’t running. I’ve been an ELM327 user for years, but I’m convinced that the STN1110 is superior to and 100% compatible with the ELM327.

      On to your last question, you should be able to connect to a VW’s OBDII bus as long as it doesn’t have some proprietary OBDII connector, in which case you’d need to get an adapter cable. I’m not familiar w/ either of the 2 software packages you mentioned, so I can’t say for sure that my module would work with it, but in general, if either of those software packages support connection to serial ELM327 adapters, they will certainly communicate with my module. My OBDII module can be used with any piece of software that expects to connect to an ELM327 via a serial port.

      -Andy

  6. Ferhan says:

    Andy, great work !
    Do you have the same system working with RN-42-HID ? How hard would it be to use that chip instead of RN-42 ? Are there significant differences in pin layout and protocol ?

    • Andy says:

      Hmmm….I’m not really sure what the HID profile would get you as that’s intended for use as a mouse, keyboard, gamepad…etc (human interface device). All the RN-42’s are pin compatible w/ each other (same base hardware, just different software in each) so you could just plop the RN-42-HID on the module instead of the RN-42 (SPP profile). But still, I’m not seeing how this would really even work, or what you’d be trying to accomplish.

      Have a look at the RN-42-HID user manual here: http://www.rovingnetworks.com/resources/download/120/HID_User_Manual

      Maybe that’ll give you a better understanding of what their intention of use of the RN-42-HID and how you may/may not be able to make it work for whatever you had in mind.

      That being said, if you’re intending to just use the PCB I have for your own uses (nothing to do w/ OBDII at all), then there’s no reason why you couldn’t use the RN-42-HID on my board w/ a PIC24F micro running whatever code you write =).

      Andy

  7. Tiaan Alberts says:

    Hi Andy,

    Thanks for the reply. I understood that the regulation using switch mode is more efficient, but did not know about the start-up currents. So yes you answered all of my questions.

    Thanks
    Tiaan

  8. Tiaan Alberts says:

    This might sound dumb, but why are you using such an expensive 5V regulator. What is the 5V current draw? Your using an 800mA inductor, I can not imagine that the current draw is that high?

    Thanks for open sourcing this project. This is indeed a very nice project. And great job on your PCB layout, very nice.

    • Andy says:

      It’s expensive because there’s a lot of junk built into that switcher such as the output FET and the schottky diode. It was chosen based on space constraints and efficiency. Yes, the inductor’s saturation current is rated much higher than the average current that is drawn from the supply. When the unit is running, up to 150mA can be drawn on the 5V rail. So the inductor’s current comes into play in a few ways; the higher the saturation current, the lower the DC resistance of the wire in the inductor (assuming the value stays the same), which translates to better switcher efficiency due to lower DC losses in the inductor. However, also with the lower DC resistance of the inductor, you get higher start up current (the inductor current peaks at 400-500mA on startup according to the simulation), unless some sort of soft-start is used in the switcher. So choosing the inductor isn’t just a matter of making sure it can handle more current than your average power consumption of the load.

      The other thing that went into picking that switcher is that it’s a 40V to 5V buck w/ 85-90% efficiency in very small package. The high input voltage is needed s there are all sorts of nasty voltage spikes on the “12V” line from the vehicle that easily can go up to 30-40V. I really wanted a 60V to 5V buck, but 40V to 5V is fine I think. There are other switchers out there that have similar functionality, but they wouldn’t fit into the space I needed it to fit in. I had a LM317 in there before, but with the high current draw of the STN1110 when it’s running, the LM317 is terribly inefficient (all LDOs are inherently inefficient when the input voltage is greater than the output voltage and lots of current is flowing through them), which made the module quite hot when running. W/ the switcher, the unit is barely even warm when running. I also saw my power usage drop by roughly 1/2, so even though the switcher is expensive, it’s a much better solution than a LDO for generating the 5V supply from “12V”. LDOs can actually be very efficient, but only when the input voltage is a little bit greater than the output voltage + the LDOs dropout voltage, which is why I have a 3.3V LDO powered from the 5V supply. That conversion is pretty efficient.

      Hope that answers your questions as to why some parts were chosen =). If you know of a different solution, I’m definitely open to it!

      -Andy

  9. David says:

    Thanks for the fast reply . I was most interested in throughput over range, and figured a direct serial or the next step of a usb-serial bridge chip has got to be the fastest method with the best (lowest) latency. I’ve largely had a very disappointing experience with the ELM327 devices. I have several, one serial ,.one usb, and one bluetooth (which works the worst, and is likely to be a cheap chinese crap clone), and in all cases the performance frankly sucks (updates are about 1-2/sec even with only two variables “visible”) which is just too slow. My own non-OBD software stuff talking to a diy EFI controller (megasquirt I, MS-2 as well as FreeEMS), gets rates of 20-70 blocks of data per second, and that is ALL the live data, not just one or two variables. So I’m spoiled there, I know there’s probably lots more overhead in the OBD2 protocol conversion, so I was attracted to something that offer the maximum in speed, preferrably over the lowest latency link (hardwired), which is what draws me to the STN1110 vs the ELM’s

  10. David says:

    If your device and the OBDLink MX use the same (STN1110) chip, how come that OBDLink is 2x as fast? Is it due to the agreement you have with ST.net basically to not out-do their closed source model? (apologies if you can’t really answer that question due to legalese restrictions) Or is it due to overhead with the bluetooth module, or something else ? (overclocked chip?) Does the pre-assembled unit have the bluetooth module carrier board hard soldered to the STN1110 board in the stack, or is on a removable socket stack (like an arduino shield of a different form factor) ? I’m interested in one with a changeable connectivity stack, i.e. unplug one and swap to the other, i.e. bluetooth, wifi, or simple USB (usb to serial) when used in harsh wireless areas where wifi and bluetooth have issues. I know roving networks has a wifi module similar to the bluetooth module though I donno if the pinouts match or not. Thus it would be available to iDevices as well as Android/PC devices that don’t have bluetooth (or a decent working BT environment (I’ve never liked bluetooth’s performance))

    • Andy says:

      David,

      Well…the OBDLink MX uses a sorta-STN1110. The chip in the OBDLink MX has some extra functionality that allow it to talk on the SWCAN and MSCAN busses in certain vehicles (if software supports such a thing). They may also have some performance increases over the STN1110 that anyone can buy, thus eliminating competition performance-wise and new feature-wise using their own part. It sucks that they don’t have a part for sale that does SWCAN and MSCAN like they’ve got in the OBDLink MX, but I guess for business sake, that would be dumb on their end, at least until some other units have the same functionality. However, it is believed that the majority (if not all) of the speed difference is due to the Bluetooth module. They’re using some module that most likely has had a lot of tweaking done to it to make it very low latency. Most all the Bluetooth modules that are off the shelf use a CSR Bluecore4 chip, and the manufacturers base their code of CSR’s 2007 stack. Apparently the newer stack is faster, but at least in RovingNetwork’s case, they don’t intend on using the newer stack from CSR. The OBDLink MX does not use a BlueCore4 chipset. According to the FCCID (which may be a mistake actually as it’s the same FCCID as the Motorla Xoom tablet) on the OBDLink MX, the BT module in theirs is made by Motorola.

      Also keep in mind that I had a BTM-182 module working a little over a year ago now (didn’t post it till August 2011), and I didn’t even know they were planning on a super small BT module like mine till September/October 2011. And they finally came out w/ theirs in late Dec 2011. So if anything, they had my unit, found ways they could improve upon it, and take advantage of that. I don’t know if anything in my design influenced theirs, but I like knowing that mine was available on the web before theirs was announced to the public, and ready to sell (trying to have Sparkfun sell it actually) a little under a year before the OBDLink MX was available for purchase.

      In the stack for the assembled module, the driver PCB contains only transistors, power supplies, and other vehicle interface specific stuff on it. The Bluetooth board contains the Bluetooth module and the STN1110 chip. These two boards are soldered together (aka not easily removable). A removeable top PCB could work, but you’d have a really hard time unplugging the module from the OBDII connector w/ a removable top PCB. Besides that, the USB interface is the only other practical interface that you could throw on top of the current stack of PCBs. All the wifi modules I’ve seen (looking into another now) are either physically too big for my stack, too power hungry, or a combination of both. From the device standpoint, Bluetooth is preferred because it is lower power, less overhead, and your wifi connection is free for browsing the internet while you’re connected to the vehicle. But from the Apple point of view, they’ve made it financially and technically challenging to connect to their devices via Bluetooth (with the exception of BT4 on their newest devices). So I don’t have any plans for a USB interface or a wifi interface due to size reasons for wifi, but you’re welcome to make your own lol =). That’s the whole intent of the open source hardware: Get people to build off of what’s been done and make things better. But if things make sense financially (like you’d be buying a lot of these things if those options were available), we can certainly talk more about that.

      I can tell you right now that I easily get 40-50 feet w/ active data transfer using the RN-42 BT module closed inside my vehicle. If that kind of range isn’t good enough, I believe the RN-41 is a drop in swap for the RN-42 that would offer increased range (my power supply might not put out enough oomph to support that; would have to check on that). I’m not sure what kind of crazy vehicle RF environments you’d be using this in that would cause connectivity problems, but it’s certainly possible that there might be cases where you would lose signal. Still, in practical use cases where you’re within 10 feet of the module (assuming it’s plugged into the standard vehicle OBDII connector), I’ve yet to lose connection w/ my module w/ the testing I’ve done w/ my PC, phone, and tablet on numerous vehicles.

      hope this helps!
      Andy

  11. Pavel says:

    Nice writing, Andy. I can confirm your words mostly. My maximum PID/sec is about 18, but is limited by an old ARM6 based ZTE Blade Android, I suppose. I thought about DIY kit, but I, thank the God, finished with the ready to use version. The unit (2 boards) is very small and w/o an advance SMD soldering skill it would be very difficult to complete the job. The circuit design is clean, mostly based on component’s datasheets/whitepapers. I also have DealExtreme blue plug (USD50), which is not bad (about 12PID/sec), but it has a big power consumption in the idle state. It was a reason I purchased Andy’s product. The idle current (about 60mA) is not a big deal with std. car and its big crank battery as an opposite to hybrids and their, usually, smaller accessory battery.

    • Andy says:

      Right, my module is based on recommended circuitry in datasheets, except that I use a switching power supply, FETs instead of BJTs, and some other differences.

      And as you’ve probably found out, my module is much lower power compared to pretty much anything else out there in the idle state.

      The interesting thing is that the DE module is $50. I thought they were about 1/2 that. Maybe they started using a real ELM327? Who knows. Still, I’ve read about a lot of people w/ issues w/ the blue bricks on CAN bus and non-CAN Ford (J1850 PWM).

      • PaJa says:

        I don’t think so, some guy made a surgery of the DE blue-plug, see: PIC18F2480. I don’t know what is inside of mine, as I sold it few days ago.

        • Andy says:

          It’s likely a cloned ELM327, although ELM Electronics does use the PIC18F2480 if I’m not mistaken. I think the real way to check if it’s a clone or not is to query the chip’s firmware rev. If it’s 1.2 or 1.4a, it’s a clone. The latest ELM327’s are either 1.3a or 1.4b: Real ELM327 Versions

          Really old ELM327s do have older firmware, but at this point in time, it’s unlikely anyone is selling new product w/ the original ELM327’s installed.

          • Daniel Berend says:

            I haven’t found any clones that have the Elm327 label as shown here http://www.elmelectronics.com/ictips.html

            That’s how I found out that Scantool.net was using clones in their Elmscan 5 Compact.

          • Andy says:

            Daniel,

            While there is debate as to whether or not the Elmscan 5 contains a clone chip (aka an illegal, chinese knockoff of a real ELM327 chip), I’d have to give them the benefit of the doubt knowing their reputation as a company and knowing the company’s founder. There is a good chance that the chip used in the Elmscan 5 compact may not be a real ELM327 from Elm Electronics. Rather, it’s probably a ELM327-compatible chip that Scantool designed from scratch, maybe a precursor to the STN1110 or something of that sort. Although if the part number of the PIC used is the same as the cheap chinese clones out there, then perhaps you are correct in what you’re saying. As far as I know, Scantool.net doesn’t make or sell anything cloned from another company.

            -Andy

  12. Phillip says:

    Are the unassembled kits available yet – please email purchase info if so.

    Also, have you had time to confirm reliability above 115k baud? You mentioned your dev unit was at 500k recently, and that one effective ceiling is around 300k. In the context of the “master device” user interface (I intend to use Torque Pro on an Android phone – Galaxy SII – in a 2011 Ford F150), is there a tangible improvement in real data throughput between 115k and 300k? For that matter, is there a tangible improvement between and 115k? More directly, is there a maximum rate in this ballpark at which some/all OBDII-compliant vehicles can output data (which would I guess render the extra headroom between OBD and bluetooth chips as robustness against poor connectivity within the automobile cabin?), or do these rates carry over directly into a more fluid real-time monitoring experience (provided the smartphone/tablet/pc isn’t additionally limiting on its own)? While I’m personally intrigued with the make-magazine-esque ingenuity in your work here and I would enjoy contributing in the small way of purchasing from you, from a practical standpoint of performance per dollar: what should one expect from using your device that would differentiate it from the cheaper ELM327 knockoffs (or even more expensive competitors) out there? Please don’t misinterpret my intent here, just genuinely curious to know how the differences might impact my user experience.

    Thank you for taking us through your excellent work here – this is impressive and engaging stuff.

    • Andy says:

      Phillip,

      Thanks for your interest! Yes, I have parts in stock for the unassembled kits (I’ll email you about payment info if that’s the route you want to go). However, it sounds like you’re looking for something more practical, like plug and play, and if that’s the case, the assembled modules are the way to go. The assembled modules are tested, programmed, and ready to go. The kits, however, obviously are mostly unassembled, untested, and aren’t programmed. The STN1110 chip needs some programming done, along with the RN-42 so that the Bluetooth module can communicate with the STN1110.

      As far as other modules go, the cheap made in china modules on Ebay, DealExtreme…etc are likely using ripped-off ELM327 chips. This is just pathetic on their part in that they’re stealing something another company spent a lot of time developing, proving out, and selling. The chinese ripoffs are cheap, unreliable pieces of garbage in my opinion. The quality control is very poor on those units, and some people will experience communications issues with their modules, while others won’t have perceptible problems. Since there’s essentially no design whatsoever in the chinese modules, they consume a lot of power when the vehicle is off as the ripped-off ELM327 inside is running all the time. The later ELM327 firmware (which won’t be in the chinese modules) does support a low power mode if I remember right. Most all of the Bluetooth OBDII modules out on the market are not FCC certified (making sure the output power of the Bluetooth radio is within FCC, CE, and IT regulations). You will also get fairly low performance with the chinese modules. For some vehicles, particularly older, non-CAN vehicles, you’d never know the difference. My module is also smaller than any of the chinese modules, last I knew.

      For real, legit companies like PLX and the like (not Scantool.net, that’s a different story), as far as I know, they’re using ELM327 chips. The ELM327 isn’t bad or anything, the STN1110 just outperforms it in everything except power consumption, but once low power modes are enabled on the STN1110, it beats the ELM327 in power as well. All legit manufacturers’ Bluetooth modules are larger than mine with the exception of the OBDLink MX. My module, in theory, should perform as well or better vs. any module out there except the OBDLink MX.

      The only module that I know of that outperforms my module in a few areas is Scantool’s OBDLink MX. That being said, there’s probably only a few cases where you’d actually want the extra performance that the OBDLink can provide (although the throughput does depend on your phone, but you do have a pretty new phone, so you could probably take advantage of the extra performance). By extra performance, I’m referring to how many PIDs the unit can pass from the phone to the vehicle and vice-versa. My unit looks like it tops out ~25-30 PIDs/sec via the phone, whereas the OBDLink maxes out at like 60ish PIDs/sec I think. So the main “competitor” to my unit (last I checked anyway) is the OBDLink MX. It’s 2x the cost of mine, but it also supports Medium Speed CAN and Single Wire CAN, which my unit does not support. If you don’t know what those are, you won’t have a need for that feature. Plus torque doesn’t support SWCAN or MSCAN last I knew. The only application that I know of that supports SWCAN and MSCAN is Scantool’s ScanXL and *maybe* OBDWix (unlikely though). So…these features aren’t terribly useful unless you plan on messing w/ those interfaces on your own.

      The OBDLink also has a class 1 Bluetooth radio instead of a class 2 (which mine has). The class 1 radio gives you more range, but at the price of more power consumption. I’m not sure what the extra range would be useful for, but just for the sake of argument, I can leave my unit plugged into my vehicle, have all the doors shut, and still communicate with the module from 30-40 feet away from the vehicle. I’m not sure why you’d be that far away from a vehicle and be communicating w/ it, so whatever. I don’t think the extra range that a class 1 radio gets you is really useful in any way I can think of.

      The OBDLink says it’s more secure w/ the encrypted BT (provided the BT radio in your phone supports encryption too) and its button you have to press for pairing. I haven’t been touting encryption as a fantastic feature, cause quite frankly, there’s very few people that use it. The RN-42 does support encryption, and while I have it enabled on my dev module, I have no way of knowing if it’s doing anything. The encryption needs to be supported by both ends, so if your end doesn’t support encryption, it’s useless anyway. The button press for pairing I think is rather inconvenient, but I suppose it accomplishes the goal of preventing anyone else from pairing w/ your “vehicle”. If this thing is an issue for you (extremely unlikely), you can change the pairing password on my module to whatever you want. It doesn’t have to be “1234”. This doesn’t protect against man-in-the-middle attacks, but this wouldn’t be an issue for probably 99% of people.

      Ok so back to your other questions. 115kbps is likely good enough for most people. I don’t see any performance increase above 115kbps, but that’s due to my vehicle’s ECU not being able to respond to messages at my module’s maximum rate. I get roughly 12-14 PIDs/sec from my 2000 explorer (non-CAN vehicle). A guy over @ priuschat (frenchie is his name on there) bought my module for his CAN bus prius, and he’s maxed out the PIDs/sec my unit can provide. I think this is kinda a worst-case scenario where he’s probably monitoring a ton of PIDs at the same time, and that may or may not be the same way you’d use the device. On my explorer at “only” 14PIDs/sec, all my displays on torque update plenty quick enough for me (most update approximately 2x a sec). If I really want fast updating displays, like O2 sensor graphs, I have only those graphs on another screen, so I get faster updates of those sensors. That being said, he did try running at 500kbps, but he didn’t see any PID/sec improvement. The specs for the RN-42 state that the throughput for the device is limited to 300kbps (over the air) even though you can link it to other devices at a faster rate. Even then, the messages that are being sent are likely not hitting that 300k limit. It’s the latency the RN-42 has that limits the PIDs/sec. Putting the RN-42 in low-latency mode doesn’t seem to affect anything either. If I had a day or two access to a CAN bus vehicle that could max out my module’s PIDs/sec, I’d love to get some testing in to see what I can do to minimize the RN-42’s latency.

      You can also leave my module plugged into your vehicle indefinitely, well, not indefinitely, but if it’s plugged into your vehicle and you don’t drive your vehicle for months on end, maybe spending money on an OBDII module isn’t worth doing. What I’m getting at is my module is quite efficient power-wise when running, and consumes barely any power when you disconnect from it (vehicle could be running or off, doesn’t matter).

      So what this all boils down to is that I think my module is a really good deal for the price. It’ll outperform cheaper modules in terms of reliability, size, radio performance, and OBDII chip performance. My module is entirely made in the USA, not ripped off in china, and has a FCC certified radio (allows me to legally market and sell this thing in the US, Canada, Europe, and other countries that accept FCC, CE, or IT wireless certifications). However, if the lack of a case kinda sucks and you really, really need the super fast update rate of the OBDLink MX, then I guess that extra $110 for their module would be warranted. There’s not much difference from my module to the OBDLink MX except price, and a few obscure features that not everyone would be using/needing. Plus, I beat the OBDLink MX to the market by a year ;).

      Oh yeah, and my module’s hardware is 100% open source. No one else’s is.

      This is the piece of junk blue-brick sold @ DealExtreme (notice in the reviews how most people have issues w/ this thing on one of their vehicles): Junky Blue Brick OBDII Reader

      Hope this helps!
      Andy

  13. Ajish says:

    Thanks for the reply.

  14. Tomi Hautakoski says:

    Hi,

    Would it be possible to send custom messages over CAN protocol to the car using this dongle? I’m asking because I have a car that supports some vendor-specific messages and I would be happy to investigate them if I can just source a suitable OBD dongle for the task.

    • Andy says:

      Tomi,

      Yes, you can send pretty much whatever you want to your vehicle, but you have to do the manipulation. You won’t be able to use Torque or likely any other OBDII software to send custom messages (unless there’s a software package that happens to know what the vendor specific messages are). For instance, if you have a Ford or GM vehicle, Torque and ScanXL pro (both of which can be used w/ my Bluetooth OBDII adapter) do have support for various vendor specific messages. Torque does seem to have support for sending/receiving custom messages, but I have no idea what its limitations are. Other than Torque or ScanXL pro, you could write your own software/code to send whatever message you want. Oh yeah, Torque runs on android devices if that wasn’t obvious at this point =).

      Along the do-it-yourself side of things, all you’d really have to do is connect via the protocol that the vehicle uses (one of the many CAN protocols supported by the STN1110), probably do some setup and message filtering, and then send messages. As far as I know, once you’re connected to the correct protocol, whatever you send to the module gets sent to the vehicle via the protocol of choice, and whatever comes back via that protocol, arrives at your host device (your microcontroller, PC, android device…etc).

      -Andy

      • Tomi Hautakoski says:

        Alright, that sounds excellent!
        The car is actually a full electric one so I’m curious to see what kind of information can be gathered from it 🙂 Probably I’ll do a linux prototype version of my SW and then port it to Android. iPad would be one option but that would require a Wifi dongle and seems to be a too restricted platform for quick development.

        BTW, do you know what’s the protocol used between a Wifi OBD dongle and for example an iPad?

        • Andy says:

          Hmm…I’d guess probably TCP-IP. I suppose it could use UDP, but it seems like it would be bad if the host never got the response. Although, if the host had to keep requesting resends of packets via TCP-IP to the adapter, that would probably cause throughput issues.

          Bluetooth is definitely a cleaner way to go all around for this, but Apple charges royalties and all sorts of other fun stuff to be able to communicate to anything via Bluetooth on their products (dunno if this is true for OSX).

  15. Ajish says:

    You told that your OBDII interpreter chips configured to run at 115.2kbps.Is the STN 1110 chi ps are factory programmed for you? Which RN 42 module you have used for – Is it RN42 HCI over UART ?

    ——————————————————————————–

    • Andy says:

      Ajish,

      Well, the STN1110 chips are factory programmed at 9600bps and the RN-42 modules are programmed to be at 19200bps. I set them both to run at 115200bps, although you can really set whatever baud rate you want. The only catch is that the baud rate of the STN1110 MUST match the baud rate of the RN-42 or else the RN-42 won’t be able to talk to the STN1110. If you have a baud rate you’d rather have to two running at, I can set that. My development module is currently at 500,000bps. Apparently the limit of the SPP profile on the RN-42 is 300,000bps, so setting the rate above that likely won’t get you additional performance.

      The RN-42 module used is the plain RN-42 (not the HCI one) as this is just using the SPP profile.

      Hope this helps!
      -Andy

  16. alex says:

    and the squematics for conections with bluetooth or db9? is possible conect with external cpu ej. arduino,obduino,freeduino etc?

    thanks

    • Andy says:

      Alex,

      I’m not sure what you’re referring to about Bluetooth schematics being posted as those are available for download above. For a complete module, there are 2 PCBs, the Bluetooth PCB and a driver PCB; both schematics are available for download.

      As far as the DB9 goes, no, there’s no DB9 on this as the intent was to have a wireless connection and have the unit be as small as possible. The DB9 connector itself isn’t much smaller than this adapter =).

      Yes, you could hook this up to an external CPU (I’m assuming you’re referring to a wired connection at this point) with some modification. Essentially you’d tap into the UART_TX and UART_RX wires on the Bluetooth PCB and run those directly over to your CPU (3.3V signals, so those would go to a 3.3V CPU. Hooking these up to a 5V CPU/device isn’t recommended w/o level translation).

      Alternatively, you could connect this to your CPU via Bluetooth. You could use the same Bluetooth module that I’m using (RN-42) and put it into host mode and write some code to discover the Bluetooth adapter and talk that way w/o having to modify my adapter at all.

      Hope this helps!

      Andy

  17. PaJa says:

    What STN11100 fw is inside current version? is it possible to update via bluetooth?

    • Andy says:

      Pavel,

      Yes, you can update the firmware via Bluetooth from your PC only. The adapter shows up as a virtual COM port, and Scantool’s firmware updater allows you to select the COM port that the STN1110 is attached to. I’ve never had the opportunity to try a firmware update via Bluetooth as they haven’t had new firmware for the STN1110 in over a year now.

      All my modules have the latest STN1110 firmware of 2.1.3. In the strange event that Scantool does release new firmware, all in stock modules will be updated to the latest firmware.

  18. Murali says:

    Hi Andy,

    Have you considered bluetooth 4.0/smart chip as a wifi option for iphone4s (the ti/nordic ics can work for this purpose)

  19. Ryan says:

    Andy, your product looks awesome, thank you for open sourcing it.

    I am reading through the various docs and am having trouble figuring out if your RN-42 module will work with my 1995 Jeep Cherokee, which not only has the misfortune of being a Chrysler product, is also right on the line of when they were fooling around with semi-OBD compatible designs. So, I thought you might either know already, or be able to take a look at a thread like this and tell me if your module supports my vehicle: http://www.cherokeetalk.com/forum/f29/obdii-trouble-codes-2362/

    Thank you!

    • Andy says:

      Ryan,

      Well…the answer isn’t terribly simple, since as you’ve discovered, your vehicle is on the hairy edge of whether it supports OBDII or not. Although I’m thinking probably not as it would have been produced in 1994… Anyway, there are a few things you can do to try and verify that your vehicle supports OBDII. Take a look at the adapter manual that I crudely wrote up: Bluetooth OBDII Adapter Manual and look at pages 6 and 7. See if you can find the connector in the driver’s side or maybe even the passenger’s side under the dash somewhere. It should look like the connectors on page 6. If you have that, then there’s hope. Next, look under the hood at the belt routing label somewhere in the engine compartment. It’s usually right by the hood latch. On this label (see page 7 of the manual), there should be something that says your vehicle is OBDII compliant/certified if it actually is, although I’m not 100% convinced that if the label makes no mention of OBDII that the vehicle doesn’t support OBDII.

      Ok so if your Jeep has that connector, but the label doesn’t confirm anything, try and take a picture of the connector and send it to me. I can at least confirm if the pins necessary for OBDII are present.

      And yes, it is unfortunate that it is a Chrysler product ;). Sorry, couldn’t resist lol.

      Andy

      • Ryan says:

        Thank you for your answer Andy. I did locate the connector, it is indeed different, and I have given up for the time being. I haven’t been having problems with the car, just wanted to get at all the fancy data.

        • Andy says:

          Ah I see. Well, at least you didn’t buy an adapter and then discovered you couldn’t actually use it. That would’ve sucked =(. You’ll just have to buy a newer vehicle to get the fancy data! That sounds like it could be expensive though…. hehe

  20. Javier says:

    Hi Andrew, have you thought about creating a wifi version so it can be used with Apple devices? Would that be much harder to do?

    • Andy says:

      Javier,

      Yes I have thought about a wifi version, however, I can’t find a wifi module small enough and low power enough for my liking. Also, the wifi modules I’ve looked at are roughly 4x as expensive as the RN-42, so it doesn’t make for a very cost effective solution either. But, I might consider making a wifi version as the Bluetooth version has been quite successful.

      Andy

      • Javier says:

        Thanks for the quick response! I’ve been looking for a do-it-yourself (or put it together) type of kit, and all I’ve found is packaged solutions that are close or over $200, so maybe you can come up with something lower than that 🙂

  21. travis says:

    I don’t see an add to cart for the kit. How do I purchase?

    • Andy says:

      Travis,

      I’ve responded to you via email about the kits. I’ll have a add to cart button at some point in the future for the kits, but I need to make sure I have enough parts in stock for the kits before that happens.

      For others interested in the kits, please leave a comment below and I’ll get back to you via email on how to send payment if you want a kit.

      Andy

  22. Glen says:

    Need price on a kit with all parts ?
    Thank You.

    • Andy says:

      Price for the kit will be $60 shipped, or $90 for a completely tested unit. I’ll email you with payment instructions as I don’t have paypal buttons created for those options yet. I’m waiting on PCBs for the kit, so that’ll be at least 2 weeks out. The assembled unit is available today (STN1110/RN-42 unit).

  23. whitevamp says:

    was just wondering if there is a parts list been looking on the site for a wile and hadn’t seen one.
    and not in the downloads for the pcb’s
    thank you.

  24. Ryan says:

    Awesome Andy. I was just talking with some friends about OBD stuff the other day, and we were thinking that a wireless interface would be slick. Little did I know…

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.