Lithium polymer (LiPo) batteries are strange beasts. I can’t simply measure the current voltage and tell you how full it is. (You can on throw-away AAs.) Worse, a nearly-full battery and a nearly-empty read about the same voltage until it become really empty and the battery dies.

Determining the LiPo battery’s state of charge requires an algorithm that monitors the battery over time and over a few charge cycles. The simplest way for me to do it for the are-you-ok widget is to buy the monitoring in the form of a small board: the LiPo Fuel Gauge.

However, while not adverse to reading datasheet, I just wanted to plug this board into my system and have it work. I did read the example code: it reads the percent from a register and sets up an alarm-interrupt I don’t care about.

I should have been more suspicious when my full battery read a state of charge (SOC) that was in the 30,000s but really, I didn’t care the actual number as long as I could see the power go down over several days. Except, with deep sleep working, the power is taking much longer than several days to go down. Last time I read the battery, it said 18664. Reading the voltage with a DVM showed it to be very high.

Then I broke that battery’s wire so I need to switch to another module (a very small one this time so I can check the fuel gauge better). Also, this time I’m going to read the datasheet, to get it set up properly.

I figured I might as well take notes here. Maybe note a few things about how to write instructions since that’s also on my mind. The intro starts off pretty good and a line caught my eye in the third paragraph.

A quick-start mode provides a good initial estimate of the battery’s SOC.

Good, that’s what I need. And I already know I can connect to it, at least to read registers. I can probably write registers but I don’t have that code for this chip.  (That’s like 3 minutes of coding and 4 minutes of testing so this isn’t a major deal.)

Next in the datasheet is a bunch self-congratulatory blahblahs that don’t help me solve my problem. Why do they do that? I already bought the thing, quit selling it to me and tell me the good stuff. I get through the “for the electric engineer” tables (those can be important to me but on first skimming, I tend to let the data slide over my brain), then  messy graphs followed by more coy hinting at their algorithm and finally to a section called IC Power-Up.

When the battery is first inserted into the system, there is no previous knowledge about the battery’s SOC.

Since the LiPo’s state of charge depends on it’s history, the first power up is tricky. It goes on to say about how the fancy-schmancy algorithm will converge with time. This was what I was depending on before (and about where I stopped reading the datasheet before). Eventually, the fuel gauge figures itself out, after a few charge and discharge cycles. Of course, if you are talking about months, then that isn’t so useful.

I want a way to charge the battery fully (because the charger says it is done and it have been charging for several hours) and then tell the fuel gauge it is full. Ideally, that will be covered in the Quick-Start section that is next.

A quick-start is initiated by a rising edge on the QSTRT pin, or through software by writing 4000h to the MODE register

Yay? Ok, so now I know how to go into quick start mode but what does that do? It doesn’t tell me. This is why I hate reading datasheets sometimes. It is like talking to a recalcitrant four-year old.

Moving on, maybe things will become clear if I keep reading. The next section is ALERT Interrupt. I don’t want that (not enough pins on the Electric Imp, maybe I could use pulldowns to double up the wakeup pin but that seems too much like work; I don’t mind polling the fuel gauge every hour since the unit needs to wake up and check-in to the server anyway).

The next section is on Sleep Mode. That should be interesting but since I can’t kill batteries, I haven’t done the last few power optimizations: put this and the accelerometer into sleep mode when they aren’t needed.

Let’s see, I can reset the fuel gauge, as though I power cycled it. Whee. (That was an unenthusiastic whee in case you couldn’t tell from the tone.)

Now for the Registers section. As a software person, this is the section I usually skip to. If this datasheet was a walnut, this would be the delicious meaty core.

Usually.

The SOC Register really should be giving me a percent full.

Units of % can be directly determined by observing only the high byte of the SOC register. The low byte provides additional resolution in units 1/256 %.

Ok! So my last reading was 18664, in hex that is 48 EB. Looking at only the high byte hex 48 equals decimal 72. My battery is 72% full. Look at that, it makes sense now.

On April 8th, my reading was 24839, in hex that is 61 07. So hex 61 is 97%.

Essentially I’ve been reading it wrong. To be fair to my previous self, I did look at the figure that showed how to read it which says something different than the text. (Different and implausible but I know why I decided I could just read the 16-bits and concatenate them together.)

This is an easy fix to my software. Where the code used to have

local tmp = (data[0] << 8) + data[1];

I modified it to

local tmp = data[0];

As I only care about the top byte.

Well, while I knew I needed to fix the output issue, the information was decreasing reasonably as I discharged the battery, I know there was just a units or conversion issue. That isn’t why I’m reading the datasheet. I need to know how to tell it that my battery is full. But I should only do it in a manufacturing mode or something, definitely not on every boot or even on every power cycle.

Happily, the next table is about the MODE register which mentions the Quick-Start command. That references the “Quick-Start description section”, what I read before that mentions there is a Quick-Start mode but not how to use it. Searching through the document for Quick-Start leads to nothing.

The MODE register section says the only valid setting is the quick-start setting. I feel like I’m reading an Escher print turned into words.

Ahhh, the version register is next to be described. What could possibly go wrong? Well, for one, it doesn’t tell me what to expect. I read the register and get a value. Is it a good value? Many (most!) vendors suggest what to expect, reading the version register (or whoami) is a great way to verify that I’m communicating properly with the chip. Alas, not for this IC monstrosity. (Ahh, it isn’t that bad, I’ve read far worse datasheets but this one is remarkably easy to pick on.)

I mean, in the next section, it goes over the CONFIG register (which incidentally is where the sleep mode is set). There is a bit in CONFIG called X (Don’t Care).

This bit reads as either a logic 0 or logic 1. This bit cannot be written.

I suppose it is my scotch-and-ice-cream dinner or the last nine pages of nonsense, but this statement strikes be as funny. “This bit cannot be written”, wanna see me try? Because I can write it. The IC may ignore it but I can so write it if I want to.

Next there are some applications of this chip, how to use it for multiple LiPo cells. That’s all very interesting but actually not.

Then there are several pages describing the communication method (two-wire so they don’t have to license from whoever holds I2C’s patent, how can you patent such things?). I don’t care about this as I have that part working.

And then the end. It includes an address only about five miles away. I want to go and ask them to explain to me if there is a way to tell their chip that the battery should be pretty full since I just finished charging it during my hokey manufacturing process.

Instead, with the data format fix, I’ll just plug in another battery and see if it is recognized as full and discharges normally. It is supposed to converge, might as well let it.

And the next time I see a MAXIM part, I will (once again) read the internet-supplied example code and not bother with the datasheet until I absolutely have to. Though, I’d still rather buy MAXIM than Infineon parts.

But that’s a separate rant, for another day.

 

My are-you-ok widget is working pretty well. With some help from the folks at Electric Imp, I got the system deepsleeping. Now I can’t calibrate the fuel gauge because I’m not discharging my battery fast enough. (Problems like these, I can fix!)

Elizabeth sent me a picture of the prototype manatee plushie. It is adorable. Thus, we are getting closer to creating a second, much cuter unit. This leads to an entirely new set of questions.

First, Elizabeth warned me that she told her sister about the project. Her sister, while disliking the cuteness factor of a plushie, has apparently told many other people, generating interest. I was amused that Elizabeth seemed concerned about her sister’s lack of discretion.

Remember, Elizabeth and I did a podcast about the idea. And I’ve been posting here, the code is on github. The goal is not discretion. So what is the goal?

My goal with this project is to build instructions so anyone can build the system. The whole device will cost about $100 and require a bit of soldering (I don’t see how I can get around that), but it is all soldering headers or big wires into holes, nothing too arduous. The instructions will include the code, along with places that require modification (and examples for the different options). It isn’t intended to be a kit that a novice, non-technical person can put together. But anyone who reads MAKE magazine or has every held an engineering job should be able to muddle through.

I don’t know what I’m going to do with those instructions, I’ll let you know when I figure it out. Actually, I’ll  probably post proto-instructions here as I go along, trying out different things.

The first step of the instructions will be a parts list. Happily, that one is easy, I created a public wishlist for this project on Sparkfun. Next, I need to describe how to solder this together, that’s easy enough, though the wiring is not exactly trivial. (Note: I do want the reader to have some perfboard and some wire, I’ll need to note the assumptions in the instructions.)

I’m thinking about building unit #2, documenting it for the instructions. Here, have a picture of the kit as ordered:

photo

The more interesting parts come after soldering. If I set up unit #2 to work with my Electric Imp, will it always belong to my account? Or can I transfer it later? Right now, until the code is settled, I want it to belong to my Electric Imp work space. But for the instructions for other people to follow, I don’t want that to be true.

I shot an email over to an acquaintance at Electric Imp, asking about transferring accounts. We’ll see what he says. In the meantime, I can use my current Impee (the SD card looking thing) in the newly built hardware. Once I’ve built it.

As I think about how to give this to Elizabeth, I’m finding more questions- is there one agent per Impee? Or does this agent cover multiple? I hope the former though it would mean replicating code. With the latter, I’ll need to name the Impees better and figure out how to store per-Impee configuration.

I haven’t worried too much about configuration. I sorta plan to do it via an HTML web page but I don’t have a particularly well thought out plan. I sketched up a possible webpage but plan to leave that very late in the game. If I’m designing for engineers, they’d probably rather change the parameters in code than have another piece to worry about (ok, that’s how I feel right now, I acknowledge it isn’t true for everyone).

AYOK configuration page

My brain is churning with all the things that need doing, that need considering. I think I’ll go solder parts. That should calm it down and clarify what the next steps are. Though, one of the next steps is to give Elizabeth working hardware, either tomorrow or next weekend. Ideally tomorrow.

 

Happily, one of my co-conspirators in the are-you-ok widget knows how to sew which means that we can progress to the next steps of development: productization.

Here is what it looks like now.

naked gadgets

That is distinctly not cute. The jar of frosted glass is to hide the LED, so it doesn’t shine brightly in my eyes, the glass diffuses the LED. This is not a long term solution.

Right now the LED color is related to whatever the acceleration is: if the board is in the shown configuration, then the LED shines blue. If I tweak it to be on one edge or the other, it shines red or green. I enjoyed playing with the accelerometer to color translation but it was always just a diversion, to make sure I could see what I was doing.

So, why is the device going to have an LED? It is important for the user to know the unit received their attention. But I also need to show errors: low battery and no WiFi connection. With an RGB LED, my plan was:

  • GREEN or WHITE = acknowledge
  • YELLOW = low battery
  • RED = no WiFi

But now that we are talking about building the plushie, there were many good questions about the LED.

Three LED options

I am currently using a simple, standard RGB LED. If we use it, we’ll have to put it behind something (i.e. fabric that passes the light or milk jug material to diffuse the glow).

There is another option. I have small LEDs that are intended to be sewn into a device, to be shown. We could make them into coat buttons (one green, one yellow, one read).

When purchasing for this widget, I got a larger (no more powerful, just physically larger) LED with built in diffuser. This lets the light be a nose or center of a bowtie, something external to the device. I finally connected it today, it looks really nice (taking a picture of a lit LED is not a good way to see it, let’s just say that diffuser creates a gentle glow).

Gentle green glow

The LED will be on a long set of wires, 5-12″ depending on what is needed. The wire leads (shown in the glowy picture) will be clipped so there is little or no metal showing but there will be about an inch of rigidity after the LED.

Either of the two RGB LEDs can be hot glued to fabric or their wires can be sewn into the fabric. Either way will secure them. The single-color LEDs have those easy-sew holes.

The accelerometer will also be on a five-wire cable. It can be placed away from the rest of the electronics and the battery. This will let it be in the hand if we want the user to shake hands to wake up the widget. Or it could be on the head and the user can pat it. (And this is why an accelerometer is superior to a button. (I hope!))

The rest of the electronics (battery, charging board, electric imp board and the connections) should all be low in the creature, keeping its center of gravity low to allow for upright posture of the animal. Further, the back should velcro closed; we need to program the Imp for the WiFi of the house: we will need access to it.

Next, the system is battery powered (USB charging). The USB port (or cable) needs a way to be inserted, ideally without slipping out all of the other electronics guts.

A few more thoughts on making the plushie: child-safe material is critical, nothing flammable. I will make the electronics as safe as I can but having something like nylon which is both electrostatic and amazing flammable, well, I strongly prefer felt.

In my ayok widget, I have a battery. To make it last, I want the high power things to sleep as much as possible.

The Electric Imp is the largest power consumer, followed by the accelerometer, and then the battery-monitoring fuel gauge.

Happily, the Imp has a low power mode. When I say imp.sleep(5.0) to sleep for five seconds, in low power mode. Though it isn’t a very low power mode, for one thing, the WiFi remains powered up.

They offer another mode, a deeper sleep more: imp.deepsleepfor(). In deep sleep, it consumes only 6uA (which is a tiny amount if you are a cell phone and a medium-to-large amount if you are a wearable device).

Foolish me, I thought I could replace my imp.sleep calls with imp.deepsleepfor calls, do a little bit of tweaking (i.e. tell the server I’m going to sleep), and it would work.

Suddenly my system kept crashing.

I feel like that represents my often-rocky interactions with Electric Imp. I still think it is a good platform for hobbyists but it is often deeply frustrating. When I first started working with (playing with?) the Imp, I wrote an in-depth review/rant detailing its shortcomings. I opted not to post it here, instead sending it to the Imp folks in hopes my time and frustration could help them make a better product. Some of those things have gotten better in the intervening six months but many things got worse. Let’s just say I wouldn’t dream of using it in a product and if things continue to be bad, well, there are other options for home hobbyists.

Anyway, back to my crashing system.

It turns out that sleep() returns to where it was but deepsleepfor() restarts execution. This is clear in their examples (but not documented in the text). There is a work-around: if the non-volatile RAM is configured, then the system has been booted before. If it has not, then this is a cold-start so I should configure the accelerometer. (I very sincerely hope that “reprogram the code” is considered a cold-start and erases the nv space.)

As a developer, I understand why this happens this way, my annoyance is primarily because I feel like they hid it from me. No, they probably didn’t. But yes, their documentation should be better.

I did fix the crashing (and not through their nv hack, instead they have a function that can tell me what the reason for the wake up is: hardware.wakereason(). Yes, I did implement the nv hack before finding that.

Now, my Imp isn’t crashing any more. I made some tweaks, trying to get rid of the slightly alarming note in the logs:

[Status] Device disconnected; 585 bytes sent, 0 received, 585 total

CaptureStatus

I couldn’t find anything about that in their documentation. But it is worrisome so I tried to remove it. My efforts led to my card not updating and the system not running at all. The error I got was unsatisfying.

CaptureHippos

I fiddled with it for a few minutes, updated this post. My device finally came back. But I think I’ve reached maximum annoyance level for the day. (If I’m going to be this frustrated, I want to get paid for it.)

I spoke at the embedded systems conference (EELive!) last week. Things went reasonably well, some events grated on me (and will for a bit though I suspect no one else noticed).

On Thursday afternoon, I gave a surprisingly well-attended talk, especially as it was near the end of the conference. My presentation was titled “What marketing won’t tell you about the Internet of Things”. Obviously, I fished for controversy.  However, once I talked mentioned my presentation was about how consumers were not being well-served by the IoT, particularly in the area of configuration, well, it wasn’t as contrarian (or iconoclastic, a word I like much better, or curmudgeonly, a word I like less well) as it might have seemed.

At the conference, I was asked by three different folks to write for them (four if you count UBM, the organizers of the conference, for which I have already written). None of them offered to pay me.

I’m honored to be asked but my time is valuable.

That probably lacks tact or subtlety or something.

Part of me thinks writing for well-advertised blogs is a good idea: it helps sell my book and I am currently looking for a new contract. It is just a blog entry or two (or four).

On the other hand, it is for their sites (two of which I can’t even read anything on because of the hideous amount of flashing advertising, two of which I haven’t read in the past so I don’t know the state of their blinkage). I can blog here if I want to, anytime, about anything; I don’t even have to edit it or use proper words in any sort of standard order. Also, no stupid flashing ads.

I don’t really advertise this blog and I can’t say I think many people read it. Strangely, this is a big plus for me. If I wanted more readers, I’d tweet more and crosslink from the podcast. But this is a forum I can use for half-baked ideas, where I don’t need to be a shiny-polished professional.

Back to the first hand. On one of the sites, an audience member for my talk wrote up a short set of blurbs from my talk but it boiled an hour long talk into a thirty second read; my talk made little sense if that was what you heard of it. It was great to get the write up but frustrating to read the comments because they seem to think I’m an idiot. I could do ~10 entries, using my slides and talk. If I wrote them all next week and slated them to release every week, it probably would be only about two days’ worth of work.

Back to the other hand, these sites depend on content. That is how they make money. Why am I doing their job for them? Why would I work for free so they can get paid? Exposure is insufficient, I’m feeling a little overexposed right now anyway.

Do I even want to get paid? We just did our taxes and more revenue streams makes for more complexity. Also, why would I work for less money than I do when engineering? That grates more than taxes: the blogs can’t pay me engineering rates, mine are too high. Working for less devalues my time. (But working for free is pro bono, a different compartment.)

I have many options for what to do with my free time:

  • work on educational, nonpaying personal projects (ayok widget, soldering things, this blog, our podcast, take an online class or two)
  • take a break from tech, exercise more and genuinely slack
  • fish for jobs, emailing friends and checking job boards (though most of my business comes from referrals so job boards don’t pan out)
  • write for other blogs, get exposure for podcast and book, maybe ask them to pay me though it will be at a fairly low rate
  • house and business chores (reconcile business bank statements, make a new website for Logical Elegance (one that loads faster and links to the podcast), gardening)

Given this list, how should I prioritize it? Actually, I think it is in priority order (if priority is akin to desire to do these things).

For the two weeks prior to the conference, I spent about an hour a day working on my presentation (this is the problem with hour long presentations, practicing takes awhile). I can’t say I don’t have the time right now, I could put that time into writing blogs. I will need to figure out which ones and what I want to say there. (Converting the presentation to blog posts would work on one of two of the options. Two others suggested topics, one of which requires somewhat-interesting research.)

To sum up: I’m ambivalent. In the short term, committing to someone else’s blog (or even a magazine) seems foolish, especially as I’m uncertain what I’d get out of it (other than a headache trying to read my post amidst flashing ads).