Let’s revisit the LPC810 and the RFM69. Things are starting to come together at last.

I’ll pick up where I left off three weeks ago, making two LPC810’s talk to each other via RFM69’s and then picking up the results on a Raspberry Pi over I2C. Hang in there!

• Debugging the RF link – Wed
• Picking up a signal – Thu
• Debugging the I2C bridge – Fri
• Keeping track of the milli’s – Sat

You know the drill by now: one article per day, as things become ready for publication.

(For comments, visit the forum area)

There is a lot more to go into w.r.t. the LPC810 µC and the RasPi/Odroid Linux boards, but since surprisingly many design decisions are related to that main driving force of electricity called “voltage”, this is a good opportunity to first cover those basics in a bit more detail.

Here is the list of upcoming articles, one per day:

• The water analogy – Now
• Heat versus momentum – Thu
• Voltage sources – Fri
• Level translation – Sat

Here’s a nice diagram from Wikipedia with all the rechargeable battery technologies:

Quite a variety, and all of them with different trade-offs. Read the articles to find out why it matters, when to stack ’em up, how to avoid problems, and what buck & boost is about.

(For comments, visit the forum area)

The “LPC810 meets RFM69” series, is being postponed a bit longer than anticipated, the relevant pieces are simply not ready and stable enough yet to present as working code. With my apologies for this change of plans. I’ll definitely get back to this – count on it!

For now, let’s start exploring another piece of the puzzle, when it comes to setting up a wireless network, and in particular a wireless sensor network (WSN)

• Pies, Bones, and Droids – Now
• Ian started it all with Debra – Thu
• Linux, pins, volts, and ports – Fri
• Meet Raspie and Quadie – Sat

As usual, each of the above articles will be ready on subsequent days.

If you’ve always wanted to try out Linux without messing with your computer – here’s a gentle introduction to the world of physical computing, from a Linux board’s perspective!

(For comments, visit the forum area)

The code presented last week – or should I say last year? – was unfinished. In fact, it wasn’t even tested, just designed and written in a way which “should” work, eventually…

The thing with communication is that you’ve got two pieces which need to work together, but they are running on different bits of hardware, which makes it harder to see the big picture and reason about what’s going on. Getting to that first data exchange can be tricky.

In this case, we’ve also got an I2C link in there, so there are in fact three systems involved, and in addition, we’re going to need a way to re-program those two LPC810 µC’s:

Let’s get on with it and figure out how to make this stuff work:

• One step at a time – Now
• Decoding incoming data in Go – Thu

Update – With apologies, I’m going to postpone the following three posts a bit longer. Too many distractions here, keeping me from working on this with proper concentration:

• Debugging the I2C bridge – Wed
• Debugging the RF link – Thu
• Keeping track of the milli’s – Fri

Lots of pesky little details to deal with and quite a few bugs to squash, as you’ll see…

(For comments, visit the forum area)