evck

Hey, I also did this recently: https://www.evenchick.com/blog/blogging-with-org-mode.html

Yes, there will be :)

CANtact - http://cantact.io

Open source hardware for communicating on CAN buses, which are the main network used in today's automotive systems. Hardware has been around for about a year, but I'm currently working on new open source software for visualizing and communicating on CAN buses. Hoping to demystify automotive electronics and make them more accessible!

If this works, it seems pretty strange to build their own devices with it. With a patent on the methods they could make a fortune licensing the technology to Si companies. They would reach the market much quicker too.

However, having worked on BMS systems for lithium batteries this sounds very fishy. Maybe they've hit on something spectacular, but it seriously looks like snake oil based on the info they've provided thus far.

SEEKING WORK - Remote (Toronto area) Embedded systems developer with experience in hardware design and firmware. I can help with ground up hardware design, prototyping, and bringing a product to market (DFM, DFT). I've worked with a wide range of microcontroller architectures and tools, and have additional experience in automotive systems and bootloaders.

More info: http://evenchick.com

Email: eric@evenchick.com

I'm personally a fan of Adam Savage's Still Untitled [1] and The Amp Hour [2]

[1] http://www.tested.com/still-untitled-the-adam-savage-project

[2] http://www.theamphour.com

It appears that they plan to do EMV in the future. This is rather scary, since you're trusting their hardware, and probably your phone, with the private key in your chip card.

While copying magstripes is already easy, no merchant will accept a stock magstripe card for a credit transaction, because it's clearly fraudulent.

If merchants will accept coin, it creates trust for this devices, and lookalikes. I think it would be much easier to create Coins, or Coin clones with stolen credit card data. This is rather concerning.

On another note, I really want one of these to tear apart and mess with. The hardware is pretty slick.

I suppose our experiences differ. I've found the majority of classes to reward most the points on exams that require knowing how to do a specific subset of problems from the course.

I think my most memorable first day was going around a track in a Tesla Roadster, and a pre-production Model S. It's going to be hard to top that one.

I would really appreciate your feedback. Can't see your email though. Could you get in touch through my site (under About)?

Thanks for sharing that, I'll check it out. One problem I'm looking forward to working on is what the embedded device will do to take care of communications, and what the firmware to do that looks like. Lots of neat problem including authentication, minimizing power consumption, etc...

Nice. Maybe my project to set up a bunch of open source toolchains for firmware development would be interesting then. Thanks for the feedback!

Haven't done anything high speed, but I'm not too worried since it's short. It might not be perfect on the first run, but hopefully it'll work.

8 GHz and multiple traces would be a bit more concerning without impedance control. Hope it works out.

I'd like to write more hw stuff for the HN audience. I'm curious if there's anything in particular that the HN community, who seem to be more sw focused, would like to see.

Yep, it's an OSHPark render. I'm not quite ready to release the design files, so I figured I'd post that picture since it's nice an purple.

I'd also recommend OSHPark.

That might take a lot of Nerf darts.

Yep, US EPA's 5 cycle analysis tends to produce lower MPG number.

Assuming that the Model S uses the HV pack and a DC/DC to power the 12 V bus all of the time (like the Roadster), it would make sense that parking the car overnight in the cold would cause issues.

All other EVs that I know of shut off the battery contactors when the car is keyed off, and rely on a 12 V SLI battery (usually lead-acid) to support the vehicle when the power is off. The roadster did not do this, which is explained in Tesla's BMS documentation [1]. This means that any quiescent current consumed by the 12 V system will drain the main battery pack.

[1] http://webarchive.teslamotors.com/display_data/TeslaRoadster...

The real question is: "Is 2007 the year of the Linux Desktop?"

Worked at Tesla and never got to see the 'recharge now' warning. That would be quite alarming.

The Art of Electronics by Horowitz & Hill gets my vote. A bit outdated, but the fundamentals don't change. Third edition is vapourware, but expected out late 2013.

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.

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.

Bootloaders are pretty ubiquitous in embedded systems today; just about every device with a microcontroller runs one. I'm writing one to learn about them and support specific protocols. This is a first working prototype of a bootloader, but it does explain how they work and what they do.

Yeah, I'd chalk this up to poor management. Any manager who doesn't listen to "hey, you have a serious problem here" isn't doing their job.