Learning Arduino

[Loren]

This will eventually become a car project, but for now, I'm just tinkering trying to learn my way around.

The big picture: New Electric Smart car has excellent regenerative braking which makes it very easy to drive with very little use of the brakes. Not using the brakes = no brake lights. Driving the smallest car on the road, I'd kind of like people to know when I'm slowing down, even if I'm not using the brakes! Of course, the hypermiling techniques that I've picked up over the years have me coasting a lot, anyway. So, I've actually had this thought before.

The problem: Need something to activate brake lights under deceleration. There are some off-the-shelf devices made to do this, mostly intended for motorcycles as far as I can tell. Seems to be a very niche product, and anything that was reviewed reasonably well... it already unavailable.

The solution: Build something! Initially, I started looking into Arduino and there are accelerometer modules available for it. Seemed like a pretty easy trick (and still could be), though testing and calibration could be time-consuming. This stuff is CHEAP, and I like to play with electronic projects, so I started ordering stuff.

I may or may not keep up this thread current, but I figured I'd start a little documentation both for my own benefit (I can't remember shit), and maybe as inspiration to others. And, of course, if any of you have experience, you may be able to help me learn.

[Loren]

A few weeks ago, I ordered an Arduino Uno. It's one of the most basic Arduino boards. I bought a clone from Amazon, it was like $26 including the USB cable. Ordered that and the accelerometer board at the same time. Of course, most of these add-on boards are DIRT cheap and you can get 2-5 of the same board for like $10-15. So, I have two of the accel boards.

Started tinkering. Had some old LEDs in the garage, so the first thing I did was set up a test to just turn the LED on and off with some code. Then, I put the LED on a PWM output (Pulse Width Modulation... same way fuel injectors are controlled) so that I could make the LED fade on and off. This will come in handy later, as I'm not a fan of "instant on" brake lights. I like that old-school incandescent bulb fade-on, it just feels a little less "frantic". That was all pretty easy to do just tinkering one night.

Then I plugged in the accelerometer module, installed the driver library for it, and put some code together to activate my "brake light fade" code with the accelerometer. That all came together pretty quickly, too!

The crux of my initial project of controlling brake lights with the accelerometer was looking very promising, and possibly "easy".

I got to thinking about how I'm going to test and tune this setup to work as I want it to. I don't really want to have to look for an LED while I'm testing. I'd rather have an audible signal to let me know both when the decel light is on, and when the actual brake lights are on. So, I ordered a small speaker (yeah, Amazon... I got two).

Spent an evening digging up the right library to let me get something out of that beyond a simple overly-loud tone. (Yeah, I could put a resistor in there or a potentiometer to control the volume... but, the whole point of Arduino is that it should all be software controllable, dammit!) Got that all worked out. So, now I have my LED that fades on... an unobtrusive tone comes on with it. And when the LED reaches full brightness, the tone goes a step louder (to simulate actual brake lights). The LED and tone hold for 5 seconds, and then shut off. Works great! Proof of concept that I can control both the light and the speaker. If/when I get around to testing this setup, that audible signal will be great!

[Loren]

This being a modern car with all the lights controlled by the CAN Bus, I dug up the wiring diagram to find that the signal from the brake pedal goes to the traction control system module on its way to the rear lights. Is that going to be a problem if I activate the brake lights directly? I'll be sending a "brake light switch on" signal to that controller when the brakes are not applied. Could get weird.

So, I did a couple of experiments on the car.

First, I unplugged the 3rd brake light and tapped into that wire. Ran a long wire (okay, not all that long... the distance from the back window to the front seats is only a couple feet!) from there to the front of the car. Plugged into the 12V socket in the console to get power and played with manually putting 12V to the brake lights.

Much to my surprise, that worked well. I can apply 12V and activate the brake lights at will, bypassing the brake switch. And it doesn't freak out anything on the CANBUS system. I even drove it around like that to be sure. Nope, no problem. System doesn't seem to care.

Another thought I had was of putting a relay into that brake switch and CANBUS circuit so that I could activate the brake lights WITHOUT feeding a signal back to the CANBUS controller. Since the controller doesn't care about that alternate 12V input, I don't need to do this. But, I wanted to test it, anyway. Doing what I was doing, though... with the relay and all... would disconnect the actual brake light bulbs from the factory brake switch and that CANBUS module. Would the system detect no brake light bulbs and freak out?

To test that, I removed the other two brake light bulbs. Now I have no brake lights! I didn't even have to leave the garage for that one. As soon as I hit the brake pedal, it popped up a warning that my brake lights were inop! So, I can't interrupt the switch-to-bulbs circuit. (and probably couldn't run LED brake light bulbs without using resistors) But, as noted... I shouldn't need to. Can just apply my 12V to the brake light circuit all willy-nilly and not worry about it!

But, then... I got to thinking about CANBUS. Did some research and found that there are CANBUS modules available for the Arduino. And, as much as I've shunned the whole CANBUS thing in the past... it really doesn't sound that complicated.

If I can get into the CANBUS and monitor speed... I can easily calculate deceleration without the Accelerometer module and simply send a command to turn on the brake lights. Worth looking into.

Ordered a CANBUS module. Okay, 3 of them.

[Loren]

Before messing with the CANBUS on the actual car, I thought it wise to set up some bench testing and be sure I knew how it worked.

As with most Arduino stuff (sort of like working on an old Miata), most paths have been traveled and documented somewhere, just gotta do the research.

To properly test and learn, I found that I'd need a second Arduino. Okeedokee. Ordered an Arduino Nano. Probably what I should have bought in the first place. It's about 1/3 the size and was only like $12 for a clone unit. Mind you, it IS small... I quickly learned that I can't fucking read the pin designations on the board! I have to pull up a photo of it to find the pins. Getting old sucks.

I also got a solderless breadboard to make wiring and testing things easier. I think I have one somewhere on the electronics bench in the garage, but I've not seen it in years. Got another one. It's a bigger one, anyway. (of course, being from Amazon, it was cheaper to buy 3!)

Anyway, I have one Arduino with a CANBUS module set up with code to transmit. And another Arduino set up with code to receive. A twisted pair between them with the proper termination resistor on each end of my simulated CANBUS. Should easily be able to send data onto the bus from one module and read it with the other. Lots of tutorials on how to do that. They all make it sound super-simple.

Wellll... this is where I've been stuck for a week. (Mind you, I'm only working on this a couple times per week. I need to know that I have 2-3 hours available to play, and my mind has to be in the right place, otherwise I don't bother.)

I've tried about 6 different CANBUS libraries (all of them are about the same, I ultimately settled on one that seems to have a lot of users and the author is active in supporting it... and it seemed reasonably well-documented). I've checked and rechecked my wiring. I've checked and reset my settings (there aren't many, but there are a couple that I have to fiddle with).

I can get both modules to initialize and respond so that I know the module itself is not dead. But, when I try to do a send and receive, the data is never received. It's frustrating. It's got to be something simple that I'm missing, but I'm not finding it yet!

I can set up a "loopback test" on each of the modules, and that works. So, again, I know the modules are working, and the Arduino is talking to the module. I just can't get the module to communicate through my simulated CANBUS.

My next step is to rip all of the wiring out and rewire everything from scratch to be sure that it's all wired correctly. Maybe I'm just sloppy on the wiring somewhere? It could happen.

It's getting late-ish tonight. I may or may not play with it. But, I have all day Saturday... we'll see if the mood strikes me.

[Loren]

WOOT!

Looking things over again, it appeared that all of the wiring was correct, and the code settings were correct. Some examples say that the termination resistors on the CANBUS data lines are not required, some say that they are. But, otherwise... everything looked right.

BUT... when I wired up the CANBUS modules, I connected both modules to the power & ground of ONE of the Arduino modules rather than connecting each one to the power from its own Arduino. Could that be it?

Well, after some fiddling, it appears that WAS it. Even weirder... once you get the things initialized, it appears to work at least sometimes with the power DISCONNECTED! I'm not even sure how it's managing that. Pulling enough power to run from the data lines? Weird.

Oh, and the termination resistors ARE required, on at least one end. Appears to work with just one rather than both, but won't work without one. Which sort of makes sense. Something has to terminate that bus to complete the circuit. If I connected to the CANBUS in the car, it would already be terminated somewhere, and I would NOT need it. That's surely why the termination is considered "optional". But, they should make it clear that for the bench test that they're laying out, it IS required.

Only one problem remained. When cycling the system on, the receiving unit would fail to receive about half the time. Hitting the reset button would normally get it working. Or cycling the power again. WTF?

That problem *I think* was due to the INT input on the Arduino not being initialized properly. The code only reads the bus when that input goes low, which the CANBUS module makes it do at the beginning of a data frame. There's a bit of code in the initialization sequence that tells the Arduino which pin to use for that, and sets that pin as an "input". They had that piece of code AFTER the CANBUS module was initialized and set to receive. So, maybe the initial "low" pulse was sent before the pin was activated and that was hanging up the whole system? I say that because moving that INT pin config to earlier in the setup process and putting a 1ms delay after it seems to have solved the problem, or at least made it much less frequent.

So, now that I finally have a working bench CANBUS... I can start experimenting with code to send a specific message (amongst a string of other non-specific messages) from one module, and code to "sniff" for that specific message on the other module and act on that.

Once I've got a better feel for that, THEN I can start connecting to the car, find out what messages I can "sniff", as well as what messages I can send to do things like activate brake lights.

Very happy to be past that initial hurdle that I thought would take about 20 minutes to set up! The rest should be just coding from here, which is the whole point of this exercise. Getting control of the CANBUS is kind of a big deal that can allow a lot of information to be read and a lot of things to be controlled without having to touch ANY other wiring in the car! Just connecting to two wires in the CANBUS is all that's required.

[Native]

I'm reading all of this. Way beyond my simple electronics knowledge, but it's still interesting.

[Loren]

I'm reading all of this. Way beyond my simple electronics knowledge, but it's still interesting.

You could equate it to learning the Megasquirt stuff. It's complex, but if you break it down to its component parts, it's doable.

Quick overview of Arduino stuff as I know it. (and I'm certainly no expert)

The Arduino itself is just a computer. More specifically, it's a programmable micro-controller. It really is a lot like the Megasquirt, especially like the MS3x board. The difference is that instead of being pre-programmed to control an engine with lots and lots of parameters specific to that application... it's got programmable inputs and outputs that you can program to do anything you want.

There are several variants of the Arduino, but the most basic ones are interchangeable. Even the fancier ones will run the same code, they just have more memory (to run more complex programs) and more inputs and outputs, probably more built-in features. I've not even looked at them because I think the basic Arduino "Uno" will meet my needs. And the Arduino "Nano" is functionally identical, just physically smaller.

The Arduino plugs into USB on your computer. You write code on your computer and send it to the Arduino and it runs it. The beauty of it is that it's all open-source, and has a strong community of people who design open source hardware modules and drivers for those modules. So, like the accelerometer module... I didn't have to write the hardcore code to interface with it. I just had to install a "library" and use the fairly simple commands in that library to control it. There are modules available to do lots of things, like switch on/off higher voltage than the 5V that the Arduino works with. (sort of like a relay) Audio amplifiers. Text displays. CANBUS interfaces.

Once it's programmed, you can power it through a USB power source, or any 5VDC power source.

The Arduino has, I think 13 programmable input/output pins. I'm not even sure how they work that internally, but they are software configurable to be an input or an output. Some of them are digital inputs. Some of them are analog inputs. If it's set up as an analog input, then the input voltage gets translated to a value between 0 and 255. (there may be a higher resolution input that does 1024, I've not looked at that) So, like if you wanted to do your own throttle position sensor, you could use a potentiometer, apply a voltage through it, and read that voltage on an analog input pin... now you've got a numerical representation of your analog voltage. Digital inputs can be used for any kind of simple on/off input. Switches and such.

The coding itself is done in C++, but it's not as bad as that sounds. You have to learn the syntax, as with any programming language. But, there are examples and tutorials for most things that can get you started. The programming, because all the "heavy lifting" is done by the people who write the module libraries, is mostly procedural. "If this, then that" kind of stuff for the most part.

So, for my ultimate "turn on the brake lights on deceleration using the CANBUS" project, the code should be something like:
- Read the CANBUS and ignore anything that is not vehicle speed
- Calculate speed vs time (acceleration)
- If decelerating (beyond a certain threshold) for more than a certain amount of time
-- Send the CANBUS command to activate the brake lights
-- Hold them on for 3 or 4 seconds
-- Send the CANBUS command to deactivate the brake lights

That's it in a nutshell, but I'm sure it will get a lot more complicated to get the unobtrusive functionality that I want.

My next round of testing and prototyping will be to simulate that kind of functionality using my bench test CANBUS.

[Loren]

Major progress last night with some experimental coding.

I was able to link my previous "fade the LED on and send a tone to a speaker" code to the CANBUS code and trigger the light with a particular CANBUS message. Works just like it should.

While it does work, there's something else I need to wrap my head around. I'm doing my CANBUS message ID detection with a simple "If" statement, which works. But, there's a means to "filter" by CANBUS ID, which I'm sure would work a lot faster. When I'm dealing with a busier CANBUS on the car, that will probably be a good thing.

The way the filtering works is by using two things. First, you set a "mask" that tells the filter which bits to look at. Then you set the filter to tell it specifically what to look for in those bits. The complicated part (for me) is that when we're looking at this CANBUS data, we usually look at it in Hex rather than Binary... and the filters are all binary. And it all makes sense, I just don't think in Binary!

So, for example, if I'm looking for the message ID 111. That's hexadecimal 111. In decimal, it would be 273 (which is actually how I'm currently filtering it with my IF statement. But, in binary, that 111 hex = 000100010001.

One of the things CANBUS designers tend to do is "flip a bit" between the "send" and "receive" ID's related to the same control. So, that 3-digit hex number is actually 3 bytes. In this case 0001 0001 and 0001. I don't remember the exact method. But, they'll do something like add 8 to it to make it the response rather than the command. Something like that. So, the hex would be 1001 instead of 0001 for the first byte. That's where filtering comes in.

If all I care about is the ID x11 (which could be 111 or 911... both referring to the same CANBUS item), I'd be looking at:

0001 0001 0001 or
1001 0001 0001

I don't really care about the first bit, so I'd set my MASK to
0111 1111 1111

Then I'd set the FILTER to
0001 0001 0001

The first bit doesn't matter (based on the mask), and it's looking specifically for those values in the other bits.

With that filter properly set up, my code isn't analyzing anything other than exactly what I care about.

Anyhow... that's what I have to experiment with next. Binary filtering of CANBUS ID's.

[Loren]

I'm sure this would be easier if I were doing a lot more coding than I have been over the past... 8-10 years. Also easier if I were more experienced working with hex and hex-to-binary conversions.

It would also be a HELL of a lot easier if the silly code library that I was using had some documentation and I didn't have to rely on wading through Q&A stuff on Arduino programming forums that are 3-8 years old... and some of the older stuff is out of date. And they just assume that you know things. Ugh!

Anyhow, I finally got the filtering figured out.

Pretty cool. So, I now have some base code that will turn on my brake light when it receives a certain message ID on the CANBUS, but ignores all other ID's.

And I was right, the benefit of using a filter rather than just doing "if/then" stuff in the code is that when you set a filter, it does that filtering in hardware. It's faster, and it doesn't bog down your code. I've not hit the limit yet, but there IS a finite limit to how much code you can put on an Arduino, and a limit to how much processing you can do. (if you try to do too much, it could slow things down to the point that it wouldn't work properly... so, offloading tasks to the hardware (in this case, the CANBUS interface chip on the CANBUS module) is a good thing.

Next Step: Come up with some code (no, I'm NOT going to write it myself, I know it's out there, just need to find it!) to help me "sniff" the CANBUS on the car. I should be able to connect through the OBDII port. From what I understand, I probably won't be able to SEND commands through that, but I can read the bus. Reading that bus and learning what the ID of things like the speedo and brake light activation are will be a milestone.

Hmmm... another next step that maybe should come first:

I have a 2-controller CANBUS simulation running. One sending, one receiving. That works.

But, what I'll be doing in the car is having my ONE Arduino Canbus Controller receiving data AND sending back to the bus.

So, I should try to simulate that. That means that the unit that I currently have configured to "send" needs to simulate the car. I need to have my "brake light" controlled by that unit. The "receive" unit needs to read a trigger message ID, recognize it, and then return a "turn on the brake lights" message to the other unit.

The plot thickens!

[Native]

[Loren]

Heh. I banged my head against that for another 3 hours last night. The initial code-writing came together quickly. It was just a lot of cut & paste of the previous code, and gluing it together with proper syntax. I got the code to run on both modules without error... but, it's not working.

Troubleshooting. Ugh.

The cool thing is that I can easily switch both modules back to the old code at any time to verify that I don't have a HARDWARE problem. That's nice.

So, where I left it last night was with the old code and everything working... when I pick it up again, I can quickly know that the hardware works (I didn't disturb any wiring) and then get back to it.

The problem is with the receiving unit. It's not receiving. Something to do with the interrupt (INT) input, I think. It's supposed to read the bus when it detects that input, and it's not receiving it. Why? Idunno. Gonna have to study up on it and figure out how it actually WORKS. (A lot of this, for me, involves learning just enough without getting bogged down in the details... because I know I'll forget the details in about 2 days, anyway!) What's supposed to be sending that signal, and why isn't it? Which means that the problem COULD be with the sending unit not triggering something. But, at least I know the hardware works.

[Loren]

Geez, I guess I ignored this for a solid 2 weeks!

Hooked it up again today and poked around. Found that I can physically switch the CANBUS modules and everything continues to work. So, the problem is not with them. That's good.

But, I still can't switch the code from one Arduino to the other to reverse their send/receive status. So, either there's some kind of weird compatibility problem between the Uno and the Nano (clone), or my Nano is borked. Or... I've missed a wiring error after looking at it many times. Any of those are possible!

I went ahead and ordered a package of 4 more cheap Nano clones from a difference source. If one of those doesn't fix it, I also ordered another Uno just like the one that I have. If nothing else, having two identical modules should remove some potential for problems.

Once I'm sure that both ends are capable of sending AND receiving messages over the CANBUS, then I can get to some more interesting testing.

Silly stuff, really. I should just be happy turning the brake lights on and off. But, I'm trying to "fade" them on and off. Which is really "rapidly switching them on and off". The question I need to answer is, how fast can I do that through the CANBUS? Fast enough? I'm betting so. But, I also want to seriously bog the network down with extra messages and see if it can keep up. When I'm connected to the car... that's going to be a busy CANBUS.

Of course, fading the lights isn't necessary. I'd be okay just turning them on and off. But, I've seen at least a few cars (a newer Mazda 3, I think) with LED brake lights that had an obvious "simulated fade". It was a pretty obvious step through maybe 5 levels of brightness. It was quick and smooth, but obviously not seamless if you were paying attention.

Back to waiting for parts. They should be here tomorrow. Then I'm back to waiting on me.

[Loren]

So... yeah, the parts arrived in 2 days. I just had a mental block and couldn't get motivated to mess with it for 2 weeks.

Tonight was the night! Got the new Arduino Uno hooked up. Now I have two identical units. And, sure enough, I can switch the "send" and "receive" programs between the two of them, and it works both ways, as it should.

I may or may not get a wild hair and try the same experiment with two Arduino Nanos. But, I'm more likely to keep playing with this configuration, since it's already hooked up.

Now that I know both units are capable of sending AND receiving... now I can get back to setting one of them up to act as "the car", and the other one to interact with it by receiving messages from it and sending commands to it.

[Native]

[mymomswagon]

I'm waiting for your piggy back dev to make that car go faster.

[Loren]

There's actually a plug & play device that does that. I don't need this car to be faster. It's already pleasantly quick. Not "fast", but enjoyable to drive.

Haven't touched the Arduino in two months, though. Been busy doing other things. It's still sitting here in a box next to the couch, though... never far away if I get the urge!