For legal reasons, I can’t post the codes I found on my car. So the script I have on Git Hub WILL NOT work as is, but it’s close.
Git Hub: https://github.com/jryanishere/GM-Car-Automation
I am going to side track in this post as now would be a good time to follow up on what I meant when I said, don’t use the Raspberry Pi Model B, Model B+ and Model 2 B OR Wheezy. If you’re just going to take my word for it, go ahead and skip ahead to Part 6.
Beyond the high idle power draw, I had MAJOR stability issues with ALL of them. I would get the thing working reliably, and a few days later, something else would mess up. If someone asked me at the beginning of all of this: “What do you think the hardest part of this project would be?” I NEVER would have said getting the Raspberry Pi to not be a little bitch. I chased issues for damn months. I’ll save you all of my swearing and jump right to WHY I said not to use them.
Wheezy was a pain in the ass to pair with the MX and once it was paired, it had serious connectivity issues with every Bluetooth dongle I tried.
Wifi was unstable in wheezy. At first, I read about turning off power saving, which appeared to fix it, but it still was dropping after a day or two. It turned out to be the ifplugd package randomly taking down the interface and never bringing it up again.
Multiple Kernel Panics. I thought this was a power issue at first so I bought a lipo battery that can provide charging while powered. Maybe it was the uneven power provided when my car started? Nope. I brought the Raspberry Pi 2 Model B inside on stable power. Nope, still randomly panicked on a known good power cord. I tried multiple Bluetooth and wifi dongles, no go, the Pi 2 B crashed. It crashed even faster when I had a Huawei E303 plugged in as well.
I tried a couple different powered USB hubs (which shouldn’t have been needed! this was a Pi 2 B damnit) and I was having trouble getting the dongles to be consistently recognized.
I tried a new SD card and started fresh with Jessie. The kernel panics continued.
I tried different versions of Python, I switched from Apache to the lighter weight Nginx, and I installed the Jessie Light build without the gui and other useless packages. Panics…
Last thing I tried on the Pi 2 B was making a custom power adapter, volting up to 5.3 volts, connecting it to the gpio pins and giving that a try for a while. About the first 24 hours were good, then the pi 2 stopped booting, for good. Ok, full fuck this mode.
I brought out the Model B+ I had and the original Model B. I bought a few different powered USB hubs to use with them and I got the Wifi/Bluetooth working, but not the cellular dongle. I couldn’t get Usbmodeswitch to work reliably on a powered hub. And when I did get it to work, wvdial sometimes would throw an error. It worked perfectly fine on the same hubs when plugged into my Linux Mint laptop.
I was hundreds of dollars into this and two months into trying to make this stable. I was so pissed. The easiest part of the project suddenly became the hardest.
After trying to get my hands on a Pi Zero the entire time I was swearing at the other models, I settled on trying a Model A+ as a last ditch effort. I set it up with Jessie Lite after everything I have learned from all the previous tries and… it worked. I never had any issues. WTF. What was on all the previous models that was screwing with me?! I never found out. I suspect it was a hardware architecture problem of some sort, but I was never able to confirm it. I was just happy that the Model A+ was relatively stable.
Notice how I said relatively stable up in the last paragraph? There are two issues that you may encounter.
First, the MX Bluetooth is a horribly unstable product with ZERO product support. LESS than zero product support. I am so pissed about this, but I digress. It’s the only commercially available adapter that requires NO aftermarket mods to work on the SW CAN Bus of GM Vehicles. If you downgrade the firmware right when you get it, it helps, a lot. It will now stay stable for just over a week (as opposed to a few days), then becomes unresponsive requiring a power cycle. I have resorted to unplugging it once a week until a few competitors release SW Can capable adapters OR I finally get around to making my own adapter. There is also a timer/relay mod I came up with to reset it once or twice a day, but that’ll be in a much later post, maybe.
No real competitors to the MX Bluetooth yet. In my research, I found one guy that used the STN1170 chipset (made by the same people that make the MX), but the demand just wasn’t there, so he didn’t make another batch. BUT there is a small glimmer of hope. There will be at least one new competing adapter that will hit the market within the next year. I will post on it when the company is ready to send me one.
Second, I haven’t told you about Minicom yet. Minicom is THE BEST serial console that runs completely in terminal, no GUI. If you open a RFCOMM channel, open Minicom, and start sending commands via the Python script, you WILL get a kernel panic. I have not found a way around this. It is only a slight problem for testing. Not a huge deal, but I thought I’d warn you now. As I did for most of my initial testing, you could install the full version of Jessie with the GUI and use CuteCom.
Ok, side track is over. Time to dive into how I finally got all of this to work.
looking forward to the final steps!
…and thanks for the backlink on part 1 😉
jryan, I designed and built a GMLAN Single Wire CAN shield for the Arduino Mega, any interest?
That’s really cool. I would love to be able to dump the MX Bluetooth and have one thing plugged into my obd2 port. Unfortunately, I do not know enough about the Arduino to develop a full solution.
interesting, it wouldn’t be terribly difficult to modify the design to work with the raspberry pi – I’m just curious if there is enough interest in it to open up the design again – SKPang (no affiliation) already has a really nice Raspberry Pi CAN transceiver shield – and the GMLAN should be pretty close drop in. I’m curious on if this is just a one time thing or if you are planning on continuing to develop around this.
I’ve been down this road. If I bought their shield and swapped the transceiver with a TH8056, it theoretically would work. BUT, between needing a raspberry pi 2 and the shield, the power draw would be wayyy too high (over 600mah at idle). The MX Bluetooth has a sleep mode. Between it and the Raspberry Pi Model A+ at Idle, I’m only drawing 130ma when it’s not in use.
A Raspberry Pi Zero would be even better, but I have had trouble tracking one down, at this point, I am just waiting on the C.H.I.P’s that I ordered (super low power, runs linux, on-board bluetooth AND wifi, $9).
The ultimate solution (from a power draw and reliability standpoint) would be a full Arduino setup, but I am NOT a C# programmer and have no idea how to handle multiple aspects of the project with an Arduino (Like wifi control, SW CAN interfacing). I suppose I could have an Arduino shield designed around the STN1170 chip, BUT, I strongly doubt there would be enough interest to cover all the costs involved.
Yea, we reached about the same set of conclusions, I was also looking at Intel Edison, but expense and lack of community support killed my drive on that one. This C.H.I.P. certainly looks interesting, but to your point GMLANs problem is that it’s one OEM so it isn’t scalable for open source work 🙁