Moj.io: Connect your car to the world around you | Hacker News Reader

Moj.io: Connect your car to the world around you

moj.io

145 pointsmck-82 comments

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.

We are indeed. We intend to offer multiple colors and will allow users to choose a color if we exceed 5000 units.

This may be a long shot, but were you at Launch@Grow?

Actually, yes we were! Did you go on any of the startup crawls?

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! :)

At the Roundhouse Community Center? Yes that was me :)

Small world indeed -- impressive work; Keep it up!

It is my understanding that hockey tape is electromagnetically transparent for most purposes.

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.

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.

Two options of models would be a great idea; like iPads: one with cellular, and one without. One version gives you a few more features.

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.

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?

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.

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).

Your car speed can be used in tandem with the relatively inaccurate location given by a GPS unit to give a better location reading. More info here: http://en.wikibooks.org/wiki/Robotics/Navigation/Localizatio...

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.

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.

And going over sweet jumps

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.

I don't think it escaped everybody's attention.. there are several companies/people working on this.

Citation needed.

Some of them do work in the shadows. Since they're not a social media startup they don't need the big media attention ;-)

http://news.ycombinator.com/item?id=4851589

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.

If you want to build your own, start with OpenGuage: http://code.google.com/p/opengauge/

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!

[1] http://news.ycombinator.com/item?id=4746532

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.

I agree with zx2c4 whole-heartedly!

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)

https://www.youtube.com/watch?v=-TrEdSlo1-4

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.

I wonder what the power draw is? a tad worried my car wont start after longterm parking.

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.

Superb! Thanks so much for clarifying that.

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 ...

What is the Bluetooth going to connect to when the car owner isn't the one driving?

It seems that it's got some sort of whispernet type service, but I agree with you, paying for data would make this way less useful.

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.

So such a port exists in all cars since 95, and no one did something like that?

Progressive Insurance did :|

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.

This looks very promising. Good potential for affordable fleet-tracking.

I'm also excited to see a local (Vancouver) company with such a polished offer. I'll be following this one closely.

Same here -- I'll be interested to see if they go head-on against Webtech Wireless

I had a roommate with one of these ODB connector dongles. He paired it with his phone, and was able to get tons of information about the car.

He could even shut off various warnings/status lights, which was handy (my car at the time had a faulty sensor).

He may have been using the Torque app, for Android. I have it and it is excellent.

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?

From their indiegogo page:

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??

ODB means On Board Diagnostics. A majority of vehicles only report information - its not generally a control interface.

This. It's read-only, as far as I'm aware.

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."

Hence the use of "majority".

Thank you for finding that link, I was trying to find this[1] presentation for my comment, but couldn't.

[1] - http://users.cis.fiu.edu/~carbunar/teaching/cis5374/slides/a...

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.

[1] http://changegears.wordpress.com/2011/05/17/apr-stage-1-ecu-... [2] http://www.velocityfactor.net/scripts/prodview.asp?idproduct... [3] http://www.tactrix.com/index.php?option=com_content&view...

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.

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.

I'm really glad this wasn't around when I was a teenage driver.

I went to http://www.moj.io/obd as instructed by the FAQ to learn more about the OnBoard Diagnostic port, but got a 404.

Edit: clarity

the security benefits are questionable, as thieves will learn very quickly to locate the OBD II port and remove anything plugged in.

Is anybody else using the OnBoard Diagnostic port? Is there some connector for an Arduino? I love this approach.

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.

Yes, Ford's OpenXC uses the OBD-II port, and talks to Android through an Arduino.

Website: http://openxcplatform.com/

OpenXC post on HN: http://news.ycombinator.com/item?id=4745039

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.

[1] https://play.google.com/store/apps/details?id=org.prowl.torq... [2] http://www.youtube.com/watch?v=4OPH7ZJJHV8

This is brilliant. Very well laid-out with a nice polished design. Might just have to check this out.

There's no security in place against the diagnostic port? I mean other than lock and key.

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.

Why "Works with any car built after 1995", what's special about 1995?

>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.

http://www.obdii.com/connector.html

It works with OBD-II. All cars built after 1995 were mandated to support OBD-II:

http://en.wikipedia.org/wiki/On-board_diagnostics

Accoding to wikipedia (http://en.wikipedia.org/wiki/On-board_diagnostics) starting from 1996 The OBD-II specification was made mandatory for all cars sold in the United States.

The world around you minus syria!

I hope they didn't pick the name moj.io because they couldn't find a better .io name :) http://and.io

Reply on news.ycombinator.com