1 Topic by dbtayl (edited by dbtayl 2019-03-05 09:29:30)

  • Registered: 2014-06-15
  • Posts: 146

Topic: Building Senoko boards: How-to

Seems like a lot of people want Senoko boards, but they can't get them. I'd like to at least mention here that if somebody was willing to spend the time and front the money to build a batch, it really shouldn't be that hard to do. Note I do that kind of thing a fair amount, so take that with a couple kilos of salt. I've considered doing the work myself, but I really don't want to deal with international shipping, possibly defective boards, collecting money, etc. Just seems like more than I want to deal with right now.

If somebody else wanted to do it....

How you'd do that looks something like this:

1. Grab the Senoko design files from here: http://bunniefoo.com/novena/senoko-batt … d-pvt1.zip ("everything in a ZIP archive" on this page: https://www.kosagi.com/w/index.php?titl … n_Source).

2. Verify all the parts on the BOM are still available- some may have gone EOL. You can skip this step, but you'll end up coming back to it anyway when you get to the next step and your manufacturer tells you they can't buy parts. I vaguely recall making a couple substitutions when I built my board. Fortunately most things (diodes/capacitors/inductors/resistors/transistors/etc.) are easy to find substitutes for. If a major part (eg, the gas gauge) has gone EOL... well, hope it hasn't. Otherwise you'll (very probably) need to re-design the board and firmware.

3. Get a quote to have boards populated/assembled (see below)- or multiple, to price-shop

4. Place order

5. Wait

6. Go through the headache of collecting payments and distributing boards


Step 3 seems to be what people think is magic/impossible/requiring special knowledge- it really isn't. Basically you need 3 things, all of which are provided for you:

1. Gerber files. These are the polygons representing the shapes of copper, silkscreen, and soldermask layers of the boards. Since these have been fabbed, you should have no issues here- just send the provided ZIP file.

2. BOM. Again, provided. This is the list of parts you want to stick on your boards, with manufacturer and supplier information. This one you would probably want to double-check for parts gone EOL and update as appropriate. Pretty easy to check- just look up the part numbers in the BOM at the supplier listed and see if it says "active", "obsolete", etc. Two large suppliers are Mouser and Digi-Key- if one doesn't have it, check the other.

3. Pick-n-place files. Again, provided. This file tells the automated machines where on the board (and in what orientation) each BOM line item goes.


So you grab those files, send them off for a quote, and then place an order. Where you do that is up to you- two places I know of that provide turn-key board fabrication and population are Advanced Assembly (https://www.aapcb.com/) and Ninja Circuits (http://www.ninjacircuits.com/). There are others as well, but I've worked with both of the above at various points in time.

A (possibly-cheaper) alternative would be to get the boards made at one of the many Chinese PCB fab services (they just need the Gerber files), then find another company to do the assembly (pretty sure Ninja Circuits will do that, not sure about Advanced Assembly).


I don't know exactly what the cost of either option would be- guessing maybe $150/board if you can get 100ish of them made. I'm guessing here- could be more or less. It will decrease significantly with quantity- I know one board I did recently was something like 10% more expensive (in absolute terms) to go from 20 to 30 boards. Setup cost for these projects is high, so the more boards you can spread that over the better it is for you.



Hopefully this is helpful and somebody feels confident enough to put something together.

  • Registered: 2014-06-09
  • Posts: 124

Re: Building Senoko boards: How-to

I have been thinking about organizing a crowdfunding campaign for a new batch of Senoko boards, but all the experiments I did drove me to the conclusion that there is something wrong with the current design of the Senoko boards, and I currently believe that the fault is to be found inside the gas gauge chip. Therefore I would prefer to have the Senokos redesigned with a better chip. Does anyone feel able to do the redesign and provide me with an offer for that? I am willing to get the production organized.

  • Registered: 2014-06-15
  • Posts: 146

Re: Building Senoko boards: How-to

That's going to be more work than just swapping out the IC. On the TI page for the gas gauge (http://www.ti.com/product/BQ20Z95), they recommend their BQ40Z50-R2 (www.ti.com/product/BQ40Z50-R2) as a replacement. It's not a drop-in substitution, but skimming through the datasheets they seem fairly close. From a board layout perspective, at first blush it doesn't look too awful. The only thing I saw in the datasheet that looked odd was "suitable for batteries between 100 mAh and 29 Ah". If that means "cells", totally fine. If that's total capacity, certain battery configurations you might conceivably see could exceed that. I didn't see anything saying WHY that range was suitable, so it's hard to gauge if it would be a problem in practice.

Of course, there ARE other IC options there, but I only did a few minutes of looking.

Note that firmware may be a challenge. I haven't ever looked at the firmware, but it may or may not require significant changes to work with a new chip. I'm assuming that it could be modified without requiring Novena kernel changes, but that should also be looked at.

  • Registered: 2014-06-15
  • Posts: 146

Re: Building Senoko boards: How-to

After a little more digging, it looks like swapping parts shouldn't be too bad- I'll try to take a stab at it. If/when I finish, it would probably be good for somebody to take a look at the design to sanity-check things. You don't need to be an expert, but a second set of eyes checking the design vs datasheet recommendations.

Firmware also looks like it shouldn't be a huge problem. Maybe even a non-problem. From a 5-second grep, it appears that because both chips speak "SMBus", they'll work roughly interchangeably as far as the firmware is concerned. Again, it would probably be good for somebody to actually verify that; all I did was grep for BQ20Z95 (case-insensitive), didn't actually look at the SMBus code.

  • Registered: 2014-06-09
  • Posts: 124

Re: Building Senoko boards: How-to

While we are at it, could you perhaps also cleanup the communication mess on the i2c bus? As far as I remember, there is a shared i2c bus between the Novena and the Senoko, and additionally a UART interface between the Novena CPU and the Senoko controller. I would prefer to have the i2c bus split into 2 busses, so that the Novena-Senoko communication only uses the UART. I think this would also increase correctness of the communication and reduce problems.

  • Registered: 2014-06-15
  • Posts: 146

Re: Building Senoko boards: How-to

The STM32 microcontroller is on the I2C bus/SMBUS because it needs to talk to the gas gauge and whatnot. When you first apply power to the board, it sets up the battery capacity, number of cells, charge rate, etc. This happens quite likely before the Novena is even started, much less booted enough to do so itself.

Note that the STM32 can also block the Novena's access to the I2C bus/SMBUS (Q102/Q103)- presumably it does that until it's done setting everything up, and then hands over control and essentially ceases to exist on the bus.

The UART, on the other hand, is there solely as a side channel to the Senoko so that you can configure it and have some manual control.

So long story short, I don't think there's a need to change that particular setup.

(Note that I may be wrong about the above- but that's my current understanding based on the schematics and notes therein)

  • Registered: 2014-06-09
  • Posts: 124

Re: Building Senoko boards: How-to

From my point of view, there is a need to seperate the I2C bus into 2 busses.
Yes, the STM32 should initialize the gas gauge, and it should be the only one talking to the gas gauge. From my point of view, it is a bad idea that both Novena CPU and the STM32 talk to the gas gauge, since those communications can collide.
No, the STM32 does not cease to exist on the bus, it can still control the gas gauge.
I would suggest that we disconnect the I2C bus into 2 busses, one on the Novena and one on the Senoko, and that we route any needed communication over the UART bus instead.

8 Reply by dbtayl (edited by dbtayl 2019-03-19 11:01:34)

  • Registered: 2014-06-15
  • Posts: 146

Re: Building Senoko boards: How-to

The STM32 could be made to cease to exist on the bus- that's just firmware. Whether it actually does or does not at this point I haven't checked. I know for certain it's easy to do this on the STM32 series of microcontrollers. If the system is designed such that the STM32 and Novena are both trying to control things at the same time (barring user UART input), I'd agree that's a messy design, though I'm assuming that's not the case at this point (feel free to correct me if I'm wrong).

The problem with routing SMBus messages through the UART is that it screws up the Linux side of things- instead of a small, one-time firmware tweak to the Senoko to enforce the desired behavior (ie, "initialize gas gauge and go away unless told otherwise"), you'd forever have to patch the Linux kernel to handle battery management over UART. I really don't like that option. It's possible there's a UART <-> SMBus driver already written, but I kind of doubt it, given that SMBus is literally designed for doing exactly what we're doing here.

The issue arises due to the way SMBus works. While it's kinda-sorta I2C (in that the I2C peripheral on chips will handle the physical signalling), I2C and SMBus are two slightly different things. The salient detail here is that I2C is pretty much the wild west of addressing and communication (every chip can pick whatever address it wants and arbitrarily choose packet formats) while SMBus is more rigidly defined (set addresses for different types of chips, specified message types and formats, etc.- see here for example: http://sbs-forum.org/specs/sbdat110.pdf). This means that the kernel can talk "SMBus" and not care what chip is actually implementing the battery control, just that it complies to the spec. Which is nice, since it means we can swap out the gas gauge and not presumably not require any (or only minor) changes on the Novena side. But if you wanted to do the control over UART, you'd have to write your own kernel driver to bridge UART <-> SMBus.

ETA: Irrelevant to this post, but poking at the firmware I'm seeing that there IS at least some manufacturer-specific SMBus code for doing "non-standard" actions- eg, clearing "permanent failure" flags. May have to adjust that if we swap chips.

ETA: OK, so the Senoko DOES take over the SMBus once every 52.5 seconds to handle the charger (plus at some points if the user explicitly requests it). Aside from this, it's not doing anything on the bus after initial setup. This takeover is in the charger thread ("chg_thread" function in chg.c), which at first glance seems to just make sure everything is up and running (within specified parameters). It also handles hard-poweroff if the battery gets low. So that's a low chance of collision, but not impossible. I don't see any collision-avoidance (nor am I aware of any "standard" method of doing so off the top of my head, though it's late).

The Senoko CAN block communication from the Novena, so presumably it could do this while talking to the charger. This would potentially cause a few timeouts on the Novena side, but should prevent garbled communication, assuming all devices handle interrupting transmissions partway through/repeated starts.

  • Registered: 2014-06-09
  • Posts: 124

Re: Building Senoko boards: How-to

Then the question is whether the Senoko actually does block the communication or not. And what happens when it unblocks the communication? Can it cause the Senoko to receive only half of a command, resulting in a different interpretation of the command?
I have seen far too much errorneous behaviour of Senokos that I want to rule out every possible potential issue that can be easily designed away.

  • Registered: 2014-06-15
  • Posts: 146

Re: Building Senoko boards: How-to

I had a long-winded reply here, then lost it.

The short version is:

  • I was wrong; the "disconnect SMBus from Novena" line also cuts power to the Novena

  • The STM32 on the Senoko supports multimaster I2C without any special configuration or firmware; it shouldn't cause bus issues

  • The i.MX6 in the Novena may or may not support multimaster nicely; see https://github.com/xobs/novena-linux/co … d1a88f2706, which indicates a patch to try to make it behave better. Unclear as to what issues it expects to solve.

  • Multimaster issues should be accompanied by "I2C bus is busy" errors in the kernel log

  • I don't see a way around the multimaster issue since both the STM32 and the Novena need to talk to the gas gauge off and on

Could you elaborate on what Senoko issues you're aware of? I know of the gas gauge firmware being FUBAR, anything else?

  • Registered: 2014-06-09
  • Posts: 124

Re: Building Senoko boards: How-to

* Senoko seldomly randomly turns on Novena, without any pressure on the power buttons
* Senoko measures completely different voltages than the cells actually have. I tried to graph them and saw very strange curves. (The voltages are definitely correctly at the input pins.) The result of these measurement problems is that Senoko turns the Novena off shortly after power gets unplugged, even though the battery is full and functional.
* The voltage measurements are very far off. Firmware-flashing sometimes helps for a day, on the next day the problem can come again.
* If I remember correctly, the i2c bus-mastering from the battery controller caused issues on the configuration flash of the DRAM modules.

From my point of view, there are too many different chips on the i2c bus, and I am not sure, whether all of them are multi-master capable, so I would really prefer to have this potential problem ruled out.