Random learnings from this weekend

1) The diggability of the earth at our section varies from beautiful gravel to the devil’s own clay. Shoveling the gravel makes you think that all the world’s problems can be solved with a little hard work. It takes to a shovel, goes where you put it, and stays there. However, shoveling the clay involves kicking the shovel into the sloppy mass, levering away to break out a chunk from a hill with the consistency of treacle, and finally getting that chunk free from the rest only to have it roll off the shovel blade and re-glue itself as firmly as if you’d never bothered. This leads to the conclusion that all human endeavour is futile and you might as well just go and shoot yourself.

2) MAX16836s look to be lovely little chips, kicking out a nice steady 350 milliAmps to drive blindingly-bright LEDs. Most similar drivers are buck-type, needing an inductor, diode, and other random crap to clutter up a circuit board; the MAX16836s just need two tiny capacitors. Thus I want to get my hands on them. Sadly, NZ’s main distributors (Farnell, RS) don’t stock them, the overseas distributors (Digikey, Avnet) have a minimum order of 248, and Maxim will sell direct, with a $50 handling fee on a $2 chip. I have resentfully begged Maxim for samples.

3) The next shiny things that I make will have lithium batteries, not NiMH, for the simple reason that the USB battery charging specification is gibberish. Seriously, “Battery Charging v1.1 Spec”, Section 2.2.2: “Any USB device is allowed to draw a current of ISUSP for an unlimited amount of time from a Downstream Port when not connected.” What? A USB device can use power from a computer that it doesn’t have a connection to? Either the USB Consortium can break the laws of physics, or those words do not mean what you think they mean. Anyway, all the required specification decyphering has been done by companies making battery charge management chips, but only for lithium chargers, not NiMH chargers. So I’m choosing batteries based on whether I will need to understand the specification for how I’m going to be plugging them in. And that’s just odd. Still, this should give me more power density, charging from any USB port, and a slim but non-zero chance of shiny things catching fire.

4) Last week’s policy realisation could be the realisation that everyone gets to once they’ve spent five years in policy and been around the ‘problem=>solution=>oops, new problem’ loop. Said realisation is that any strategy is merely a point-in-time approach to formalising an on-going set of problems, in the hope that will make solutions obvious. In reality, we don’t need strategies, we need strategic capability, i.e. the ability to think about problems in an enduring way, so that we can find some enduring solutions.

This isn’t helped by the tools we have for communicating, especially when we’re communicating about the real world, and specifically any time that someone talks with an organisation, rather than simply buying something from an organisation. Far too many IT tools are transactional and crap at representing on-going relationships. More here on this, in the context of ticketing and problem-report systems, from the Yorkshire Ranter, which should be required reading for all IT geeks who think IT should be useful in the real world.


11 thoughts on “Random learnings from this weekend”

  1. I’m a fan of agent-based message passing rather than transactions. But that might be because I’m enamored by Erlang at the moment (and used to thinking about mind agents in Opencog).

    How many LEDs can each MAX16836 drive? More to the point, how many LEDs do 248 of them drive?

    1. When I’m looking at these kinds of tools (i.e. IT tools for operationalising public policy decisions), I find myself thinking that an underlying actor-based approach is going to map onto the real world far better than any other. Then I start thinking about the relative importance of objects or messages within that approach and my brain ties itself in knots. So it’s probably a good idea that you think about this harder than me.

      For a simpler question, the answer is about ten LEDs per driver, so long as you want the ten LEDs to be doing the same thing. Given that the light source I want to use has RGBW LEDs in one pack, then I need four drivers for source. Hence using a minimum of other components is critical to fitting everything into a tiny area.

      (Much as I’d like to buy 248 of them, I’m not feeling quite that rich today.)

  2. “Not connected” in this context means has not performed any negotiation of power. Since you can draw power from the +5V rail on the USB port without connecting D+/D-, there has to be a power limit disclosed for that. I seem to recall there’s also ways you can request more without a full USB endpoint negotiation.

    They don’t mean unplugged 😛

    1. Yeah, but can I work out what a USB connection is, or how to do the 100/500 mA switch? There’s lots of waffle about enumeration, and occasional waffle about pull-ups, but it’s yet to make sense to my brain.

      And given that there’s (somewhere) a common charger thing and a common port thing for all mobile phones to charge via micro-USB, I’d really like to find a clear guide to the standard and how to use it, coz that’s how I’d like to charge.

      1. In the base USB specs, you can draw 500mA from the port only if you can send the host a configuration descriptor which specifies your maximum power draw of 500mA. That draw assumes a “normal” USB connection, ie it’s attached to something which can actually talk the USB protocol layers and has the 1.5k pull down or pull up resistors on D+/D-. (Those have nothing to do with power, only do to with speed selection.)

        Note that if you do that, you *must* also support suspend mode, which limits draw to something like 2.5mA, and you must also ensure you do not force power up Vbus.

        All of that is the in the base USB 2.0 spec, nothing to do with battery charging spec. That’s also achievable without much work, since you can get, say, FTDI USB Serial chips which can be reprogrammed to request 500mA, and have a suspend output you can tie to switching the charge circuit off. They will also work on real USB ports (but probably not “dumb” charging ports.)

        The USB Charging spec includes that, plus a bunch of ways that you must detect whether you’re attached to a high power port or not. A dumb charger shorts D+/D-, so you need to detect that and then you are free to draw 500mA to 1.5A.

        That said, you need to have some mechanism to control your total draw so it’s lower than the maximum power the dedicated port provides. Spec looks .. interesting on that subject, my analog logic is very weak and I don’t entirely follow why the examples work.

        Thing is, if you only need 500mA then the path of least resistance is to get a USB chip which can request it, and accept you can only charge from ports capable of proper logic. Or draw 100mA and switch to 500mA if you detect a dumb charger attached.

        Doesn’t look impossible, but bags not me implementing it for now 🙂

        1. What he said (I was about to say the same).

          Most real devices (all the ones I tested a while ago) will actually source up to 500mA without any negotiation. Some chargers will source more. If you bundle a charger with your device, then you can pick a suitable one.

          There is a known problem with certain USB charged devices (Motorola, I’m looking at you) that when the battery drops below a certain level, the device can no longer negotiate its power requirements properly and can’t charge. Avoid this pattern.

          One way to control charge rate into a battery is to produce a PWM waveform that results in the appropriate current flowing. This is, however, non-trivial.

          1. Yes, most USB ports don’t implement different current control based on what’s negotiated (or, for that matter, suspend too!) So if a port can do 500mA or more it’ll just do it without any discussion.

            But, unpowered hubs and random laptops might not supply 500mA at all. They’re only obliged by the USB 2.0 spec to provide a minimum of 100mA. In that situation, probably you want something to stop it trying to overdraw since current protection on USB ports is pretty much nonexistant as noted already 🙂

          2. So if I plug an LTC4054 into the power and ground of a USB port, then it might charge the battery, or it might not. Bum.

            If I want to do it properly and have negotiate the 500 mA, what’s the minimum kit that I need to do that? And why hasn’t anyone (that I’ve found so far) built that functionality into a battery charge controller chip?

          3. The reason is it’s quite a lot of complexity adding a full USB endpoint for just a battery. And you’re stuck with a battery-only USB connection, you can’t use it for other parts of a USB-connected device. And what sort of endpoint do you implement? (I guess the answer is HID Power profile… 🙂 )

            I *am* surprised there are so few dumb-charger-capable chips out there, I guess I’m missing how to look for them, or they are being implemented with existing discrete components. Or it’s just too new.

            If you want to go the full negotiated route, then you need any chip which will talk the protocol. Could be a real USB chip like FT232RL, or one of the USB PICs (18F family has at least one USB chip now?), or if you’re brave a sofrware USB implementation like V-USB for AVR chips.

            Fun project 🙂 I’m sort of interested in how hard it would be to hack V-USB
            on an AVR chip to implement both the configuration descriptor approach, and also sink/source enough current thru D+/D- to do short detection for dumb chargers.

            Bags not plugging it into any port on a machine I value in the short term tho 🙂

            I’d be thinking about if I had any other use for USB (eg, serial console, or whatever) and then it’s a bit less of an added expense.

          4. Annoyingly, it seems NXP announced the ISP1601 last year and never shipped it. It would perform the proper D+/D- trickery to detect dumb chargers, while still allowing a normal USB chip on the lines. And the ISP1704 which included a full USB PHY in the same chip.

            Stop publishing datasheets for things you don’t make 🙁

Leave a Reply

Your email address will not be published. Required fields are marked *