I don't understand why it was designed to fit nicely in your hand, and why it was made with bright colors.
#1. This thing will be under your steering wheel 100% of the time, so being able to hold it ergonomically doesn't make a lick of sense.
#2. If one of your advertised functionalities is for recovery after theft, the last thing you want is for the thief to be able to spot the dongle and remove it. If I bought one, the first thing I would do is obscure it with hockey tape, but I would be concerned that the wireless capabilities would be hindered.
Those OBD II connectors in cars can be kind of a pain to plug and unplug, so it does need to fit the hand well, but your point about the bright colors is very good. I hope they consider something more discrete.
Ooh, I think I might have had a conversation with Narayan! I was showcasing Routific at that conference when he came to our booth and we talked for a bit. Now I realize that he was showing me a prototype of the Mojio! :)
Worth noting since we're all supposed to be hackers, the connector hasn't changed over the years since '96 OBD II in the US, but there are several protocols and many vendor-specific subsets of interaction. Early "code readers" may not work on later cars despite having the same plug because the underlying protocol is different. It's easy enough to find out what the protocols are on wikipedia if you're interested. What's available greatly depends on the specific vehicle manufacturer but there is a minimum set of data including DTC's (diagnostic trouble codes) for all.
With manufacturer-specific details, there's an unbelievable amount of data and even commands and firmware download capability through that port. A decent PC-based system with specifics for your vehicle added-on is a worthy tool if you tend to do your own car repairs. Or at least you can go into the shop and tell them what part you need and know whether you're being quoted a reasonable price.
Considering the possibilities, I'm very much surprised that Google hasn't entered this space to supplement their traffic intelligence. Just look at the possibilities of the Torque Android app and this Mojio dongle to see how powerful it is.
If Google came out with a bluetooth OBD-II dongle, they could integrate it into Google Maps/Nav and Google Now, both on Android and iOS. And you don't need an expensive cellular connection for a lot of the functionality, driving down the cost.
In the long term, this would have positive effects for them. They would have realtime analytics from the roads to vastly improve traffic analytics in Google Maps. Google Navigation would also be improved for the user by providing realtime information about speed and fuel, which would greatly improve the user experience (more accurate directions, heads up display of speed, and "nearest gas station" when you're running low).
Best of all? It would be $20, and provide them with all the data they need to make their upcoming driverless cars navigate better as well as improving navigation for existing android users in normal cars. It would also tell them how inefficient people are using their vehicles, and use this real crowdsourced data to market the efficiency of their driverless vehicles.
My (outsider's, totally unprivileged) understanding of Google's traffic data is that they combine official trip-time data in partnership with road authorities with realtime data from Google Maps users.
If true, they've already got data without a dongle required.
I'm confused, how does getting the speed directly from the car improve directions and heads-up display of speed over getting the speed from the GPS unit?
The big advantage over built-in car navigation systems vs hand-held GPS units is that they measure speed and distance far more accurately via the wheel sensors. If you live in a city with a lot of tunnels or GPS dead spots, this can make a real difference.
I would imagine the same information applies. If you can blend the GPS and the wheel sensors, you would get the most accurate reading, because wheel sensors can become inaccurate through fitment of different size wheels and/or tyres.
Speed readings obtained from a GPS unit is never going to be as accurate as the reading derived directly from the car, because GPS locations are only accurate to about 10ft (IINM).
GPS extracts velocity data from the doppler shift of the signals, not by subtracting successive locations, so the 10ft accuracy doesn't come into play. My experience with GPS velocity data has been that it's more accurate than the average car's speedometer as long as you have a decent fix.
Of course, having poor signal in urban canyons or tunnels is the sort of thing I didn't think of, and that's where getting data from the car would really be handy.
It depends on a lot of factors, but with GPS there will always be lag and incorrectness. For inner-city driving, the GPS positioning might be really accurate but I doubt the speed calculation would be accurate, due to the constant acceleration, deceleration, and turning. The car's accelerometer will always be more correct.
Plus, my Galaxy S Vibrant has the worst GPS ever released, so I'm very frustrated with not having reliable navigation.
That would be a pretty cool idea. The only thing that Moj.io has over what you're proposing is the ability to be always-on, even when a phone is not in the car (hence the touted ability to detect hit & runs and towing). It would be interesting to maybe have a system that uses and assists apps on the phone but can switch over to its own connection when in a parked car.
I wouldn't be surprised if google acquired these guys to get into the space. Just imagine if it was tightly integrated with Android...and then imagine your google phone speaking perfectly with your google self-driving car. Oh the possibilities.
Exactly, building up this phone functionality is important to do now so that in 2-5 years we the public are more comfortable with the idea of self driving cars due to the incredible usefulness of blending the internet and analytics with vehicles (presented in a far less technical way, of course).
Imagine having an accurate trip-time estimate, adjusted regularly with information on which parking spots are available, and which entrance of a parking lot will have less congestion.
The high cost of driverless cars will make them take a while to catch on. But a cheap dongle can crowdsource this info to benefit us all.
I've recently done some work for a startup that is developing a highly comparable product.
I strongly doubt their "works on any car since 1995" claim. While OBD-II has been an official standard for very long, not all cars support it equally well at all. We've had serious trouble getting it to work with A-brand cars made in e.g. 1999.
Therefore, I believe that them making this claim can mean one of two things:
- They're lying
- Their "prototype" has seen little field testing at this point.
That said, honesty be told, we've been testing in Europe, where the OBD standard has been adopted later. My impression is that moj.io is a North-American only product. Maybe this makes all the difference.
Additionally, however, "Virtual Mechanic" based on OBD-II alone is going to be a half-assed feature (to my understanding). OBD-II contains little more error reporting than that related to emission (i.e. your engine). If your airbag or your breaks malfunction, then this may only be reported through manufacturer-specific protocols. Most importantly, this would mean that a light in your dashboard may be lit, while the Moj.io app says "Running Great!" I highly doubt that they have implemented all manufacturer-specific protocols to a sufficient extent for this feature to work well. It is technically possible, but it needs either a lot of reverse engineering, or a lot of purchased IP.
I really like the other features (FamilyConnect, etc), though, and how they're presented. Well done!
Still, while I like this approach, and while I want this badly myself (and a lot of moj.io seems better planned, marketed and designed than what I've been involved in), based on the above I have strong doubts.
Now, I understand that this may be hard criticism, and maybe I'm completely wrong about some aspects - I'm no real expert here. So if one of the founders reads this, feel free to correct me!
Hi skrebbel, great insights here.
moj.io is a spin out of another company called REV Technologies, that has been doing energy telematics for the US Army with its partners at SAIC and Honeywell Aerospace since 2008. REV has extensive experience with CANbus networks and OBD communication. Our prototype moj.io device has the benefit of all that experience, whereby REV has been controlling power converters, inverters, motor controllers, large lithium battery packs and many other high voltage electronics and communicating over both the low, med and high speed CAN networks of both modern and not so modern cars.
In regards to the Virtual Mechanic app, you're absolutely right. We know that presently it won't be as extensive on european cars as it will be for North America, which is part of the reason for focusing on the North American market for now. But that is just one app, and probably the least interesting one to the general market of drivers out there.
We think the majority of the other apps that we and the dev community will build will only need basic info like odo reading, speed, on/off ignition states and what gear the car is in. So much can be done with that when blended with data from the device's accelerometer, GPS, etc.
Jay
Thanks for the very informed thinking on this! Great dialog.
Wow! A HUGE market that escaped everybody’s attention! There are a few comments that come to mind:
First, this Modj.io company provides free testing ground for car companies to see if there is really a wide demand for such feedback mechanisms in public. At the first sight, I would say that there is, as they outlined in their sample use cases in the video.
Second, the only chance that Modj.io has for survival is a quick ramp-up of user base, because this technology is a perfect example of what car companies will try to use for customer lock-in. Kind of like iTunes for your car, storing driving and tracking data in the cloud. I foresee that every car company will try to develop their own platform, SDK, and an app, with unique synergies coming from having access to their cars’ deep engineering knowledge. Additionally, this will give car companies real-time feedback about the performance of their cars down to the last part that failed. This will allow them to know things like that the left windshield wiper motor batch that fails more often that average was assembled on a Friday night by John Doe. That’s scary level of detail and feedback.
Third, with such level of granularity, insurance companies will have a whole new set of market segmentation metrics, and I wouldn’t be surprised to see attempts in horizontal integration of car companies with such feedback information with insurance providers.
Forth, when each car company starts promoting their own SDK, we will see an aggregator-type company that will produce an abstraction SDK that allows you to write an app once to work on all cars.
Just my $0.02. I’d love to hear your projections as well, or comments on something I missed.
There is a community of OBD2 hackers out there working on this same problem w/ Arduino / Raspberry Pie. In my opinion, this is a feature that will be replaced by manufacturers embracing open APIs for the benefit of a more connected environment. So, while timely now, it will eventually be displaced.
Awesome. We are to 4 in just a few months [1]: Lit Motors C-1, Appcelerator+Denso, Ford's Open API, and now Moj.io. This space is exploding quickly and as a hacker and car enthusiast I can't wait to see what is next. Best of luck on your launch!
Will we be able to modify the software running on the device? I sure as hell don't want information about my car's problems or GPS whereabouts, not to mention a detailed record of when I'm speeding, to be uploaded to "the cloud".
And of course -- the increasingly likely case that "the cloud" gets owned, the hardware devices get some kind of pushed software update, which then proceeds to use manufacturer specific commands to upload new firmware into my car and drive me off the road.
Blah blah. There're good reasons to be reluctant about hooking your car up to the internet and sending your data over yonder.
It looks like potentially nice hardware. Now let me do the software myself.
While you're at it, it'd be nice to just make the software open-source, so that tinkerers can tinker.
Lest I have to JTAG the shit out of the flash chip. Which reminds me to ask -- can you at the very least keep some JTAG or serial headers on there? Please?
Because of licensing and other issues, we aren't certain yet if we can make the firmware of the mojio open source. You can totally write your own apps against our cloud api. This is to abstract away vehicle idiosyncrasies from app developers. That said, we do want more savvy OBD experts to contribute to mojio.
As for your data, you can wipe your data from the mojio servers at any time. Only you can see the data and choose which apps get to see it.
> we aren't certain yet if we can make the firmware of the mojio open source
Please do let me know when you find out. This is a very important factor for me and many others.
> You can totally write your own apps against our cloud api.
I think you might have overlooked the primary point of the post. Many folks don't want and don't trust the cloud. My coordinates, travel history, and vehicle information are my business and are not to be stored in the cloud.
> As for your data, you can wipe your data from the mojio servers at any time.
Except law enforcement.
> Only you can see the data
Except law enforcement. Except hackers. Except the other guy's insurance company's subpoena after an accident. And also, the point about remotely reprogramming the device to reflash my car firmware...
The point is -- many folks don't want to plug their car into cloud services.
> we do want more savvy OBD experts to contribute to mojio.
This is a difficult request when the platform is possibly going to be closed-source. Make it an open project, feel better when you receive funding for an open source project, and fuel good community innovation. Keeping it a closed "cloud api" platform stifles this. By the way, having an API doesn't mean things are "open", for whatever that word is worth now a days.
Anyway, I'd be interested to hear your plans for JTAG/serial headers, if you're going to be keeping the firmware closed-source.
The main issue you are going to have is security. I can't see any evidence on your website or video that you have thought about this aspect.
The combination of a closed-source solution, cloud-connectivity and connecting to the car through OBD-II seems the wrong approach to me.
Closed-source has been the pitfall of many companies in the past because fewer people get to examine the proposed solution and thus much more prone to security implementation errors.
Cloud-connectivity is the heart of what zx2c4 was talking about.
As for the OBD-II port, what you tout as an advantage in your video is actually a disadvantage. First because since 1995, the internet connectivity landscape has changed dramatically, and security strategies have had to adapt. In fact, often struggling to keep up. This means that the OBDII port was never designed with internet connectivity in mind. This is not a commercial advantage but a security concern! Examples like CarShark (http://www.popsci.com/cars/article/2010-05/researchers-hack-...) or the recent string of thefts made easier through the use of the OBD2 (http://jalopnik.com/5923802/watch-hackers-steal-a-bmw-in-thr...) port are proof that the port is not a good candidate for wider connectivity.
In environments where security matters tremendously like nuclear power plants, a core strategy seems to be limiting capabilities in hardware. The OBDII port does not follow that spec as far as I am aware. The communication scheme allows you to do bidirectional communication. This means that if a 0-day vulnerability was found in your system (closed-source only makes this more difficult to patch), attackers could use your infrastructure to write data to the car such as programming in new keys (like the BWM attack). So it seems to me that you would need a hardware-enforced read only port which doesn't exist. Incidentally that is fundamentally the reason behind some car manufacturers ensuring that their entertainment systems (with BT connectivity etc) are fully separate from the car main computer (whose traditional access port is the OBDII).
As we have discussed, even just collecting said data and storing it in the cloud is undesirable outcome for the driver (your customer in theory...).
This is only my 2 cents, I hope it helps you understand why I think this implementation is not a desirable solution and ultimately why I won't be backing this project despite. Don't get me wrong, just like many folks here, I would love to have a JTAG to poke around and make some cool toy applications but I will never use this as you intended it and plug it into a car.
Hi charlesfracchia,
Nobody wants their driving information openly available to the world - neither do we so yes, we have thought about security.
The OBD protocols do not address security and have been hacked but the moj.io does not expose the OBD protocols to the Internet. moj.io communicates to the moj.io cloud over an encrypted VPN.
When you receive a moj.io, you have to pair it to your moj.io account. To do this, you require the serial number of the device and a secret PIN (which you can change and never share). No one has access to your data unless you explicitly grant access (e.g. service garage, insurance company, family member etc.). You also see who is checking you out (once you grant them access)
These people are more selling the apps and the "cloud" stuff than the hardware. If you want the hardware, go to eBay and look for an "ELM 327" - they have bluetooth, USB, and serial ones. I paid under $15 for mine, which is bluetooth. I use it to connect to the "Torque" app on my Android phone. No fancy "cloud," though, and it needs the phone to do anything.
moj.io works in all major urban centers with coverage for
95% of the Canadian and US population
I think this should be near the top. Kickstarter-like projects always forget to account for international backers, which is getting seriously annoying.
Most of the neat things that this device can accomplish could also be done with an OBD-II to Bluetooth interface, which can be had for ~$20 off EBay.
You don't get remote access to the bus, but it's much cheaper. Not sure how they plan to implement some of the non-OBD-II features (remote unlock is a major one) for all vehicles, since there's no standard. But it'll be interesting to see where this goes.
mojio monitors your vehicle battery level and ignition state. It will go into a deep sleep state with only critical functions on (e.g. theft monitoring) if the vehicle is not doing much. If the car battery hits some critical level, it will send you an alert and shut itself off.
I see the advantage of having a sim (the real remote monitoring part) but also the disadvantage of needing a dataplan for the sim and security concerns ... why not just make a bluetooth dongle for a fraction of the price ...
Great comments everyone. We agonized about bluetooth. If we can get bluetooth into the mojio without affecting the delivery dates, we intend to include it in the current version - no promises right now though. That way, people have the option to go without a data plan as needed. Also, there's no data plan lock in to mojio so we are looking for ways where people can either add a device to their existing cellular plan or just pay for months where they need it. We are also exploring ways to offset data plan costs. If we can get a sufficient user base, we all get to enjoy the economies of scale.
I nearly threw my remote at the television when I first saw that they were trying to get people to plug their insurance company into the computer of their car.
OBD computers (especially anything before those even attempting to follow even a semblance of a standard) were a mess. They remain so even still. Lots of proprietary info and divergent technologies.
Nice... though you don't talk about what the data plan will cost. I assume it's basically like having an iPad with various carriers. But I could see that as a possible issue.
Maybe if it could connect to the wifi of my house and send some data then?
Indiegogo backers pay only $7.99/mth or $79/year (US subscribers) for wireless service.
moj.io uses machine-to-machine (M2M) cellular data exchange to send and receive data to and from your car. Unlike email, web browsing, etc, M2M data exchange is very small and requires only a very small data account.
Presently, moj.io will work with any car built after 1995 and has cellular coverage in Canada and US cities.
moj.io is supported by different wireless carriers in the US and Canada. When travelling from network to network, because it is on an M2M connection, there are no roaming fees.
Your moj.io's default international roaming setting is set to Off. Contact us for details on international roaming rates between Canada and the US to enable this setting.
Interesting, lots of products being made by much larger companies already in the market... Audiovox just launched their Car Connection at retail. Not sure if you considered the competition. Calamp, danlaw, xirgo, anydata, etc. etc
i am surprised nobody talked about security...i am guessing the OBD interface in cars can be used to send commands to various components....could somebody hack into your car??
Modern vehicles report OBD-II signals over Controller Area Network, which is used to link most the controllers in your vehicle. All cars after 2008 in the states use CAN for OBD-II.
Most manufacturers have the OBD-II CAN bus connected to the engine controller for diagnostic purposes. If you can gain control of the CAN bus, you can do some real damage to the car. Furthermore, the hardware must write to the bus to get OBD-II data (it's a request/response system), so it's not a read only device.
This, a million times this. My understanding also is that the ODB port on many/most vehicles goes straight into the CAN bus controlling everything in the car. It's entirely possible you could gain control over any microcontroller in the car, send false messages, drown the bus, etc. through a device like this. It's a TERRIBLE idea from a security perspective.
OBD-II, as I understand it, is a multimaster bus protocol, which means any master can send commands. That said, the commands that are exposed to the under-dash interface are restricted to interrogation. The emissions check people can tell how well your O2 sensors are performing but they can't modify the ignition or timing profile, for example.
You can indeed "hack" your car. In fact, ECU flashing is one of the most common upgrades for people who want more power out of their cars because it requires no physical parts.
It's generally done commercially [1][2] though there are attempts at user-configurable software [3]. Now I'm no expert on ECU flashing so these links are just examples.
That doesn't mean that the security issue doesn't exist. Via wikipedia:
"Researchers at the University of Washington and University of California examined the security around OBD, and found that they were able to gain control over many vehicle components via the interface. Furthermore, they were able to upload new firmware into the engine control units. Their conclusion is that vehicle embedded systems are not designed with security in mind."
I have been using a cheap (<$20) OBD-II dongle in my car for over a year now. The Torque app[1] has an impressive feature list and constant updates. I use it with my tablet inverted on the dashboard during night-driving for giving me a heads up display[2]. It's also great for things like acceleration graphs, tracking stats over the internet, and keeping check on the engine's performance/mpg.
In the mobile space, I believe there are some connectors for vehicle monitoring tools and the like -- for tracking performance data on the track or to provide supplementary info to dashcam programs. I don't know of anything standalone like this.
Hah, sadly no. And some enterprising thieves in the UK worked out that in certain model BMWs, you can cut a hole in the side glass and fit a sensor sender unit into the sender, while the alarm is activated. This is because the area beside the drivers mirror is an ultrasonic deadspot. Once the thieves have access to the diagnostic port, then can use the information to program a blank key to a valid key, and then steal the car.
The affected models were 1 series, I believe, and it started getting to the point where the chances of a high-spec 1 series getting stolen were very high. Google '1 series theft problem' for more info. There is a home-security cam of some theives stealing a 1 series in a couple of minutes using this technique.
>All cars and light trucks built and sold in the United States after January 1, 1996 were required to be OBD II equipped. In general, this means all 1996 model year cars and light trucks are compliant, even if built in late 1995.
#1. This thing will be under your steering wheel 100% of the time, so being able to hold it ergonomically doesn't make a lick of sense.
#2. If one of your advertised functionalities is for recovery after theft, the last thing you want is for the thief to be able to spot the dongle and remove it. If I bought one, the first thing I would do is obscure it with hockey tape, but I would be concerned that the wireless capabilities would be hindered.