power hub

[mmoskal]

This summarizes the current proposed solution to power delivery by @sehodges @jamesadevine and @mmoskal

Requirements

• need to provide ~1A to a few devices each; this is to support multiple servos or neopixel strips
• things should not get hot or physically break => should not run more than 1A over any of our cables for more than ~0.5 second
• should be maximally user-friendly - ie. the less types of cables/ports/... the better

Proposed solution

Introduce a multi-channel power provider. Channels isolate power delivery into sub-buses. GND is common between sub-buses. In normal operation data is also common, but the provider can briefly separate them.

Every channel is limited to ~1A. The provider detect if there is more than one power channel (from a single or multiple providers) connected to a sub-bus; we call this condition an over-power. If an over-power is detected, the power to the sub-bus is cut off. After ~2 second the power is restored, and the provider checks for over-power again.

Implementation

Each channel is fitted with a ~1A current limiter, an analog switch, and a Padauk MCU. The analog switch is between the common data bus in the power provider and the data connection on a given port. The Padauk data line is connected directly to data port, and the Padauk can also operate the switch.

In normal operation all the switches in all channels are closed, connecting the data lines of all ports.

We introduce a special PWR packet, which is indicated by using 0x3d as the service_index. The payload of PWR is to be determined, but it should be at least 4 bytes.

The Padauk operates as follows:

• when it wants to provide power, it enables the current limiter, waits 20-50ms (random), and checks for over-power by simply sending PWR packet
• when providing power, it checks for over power every ~500ms
• during reception of Jacdac packet, if the packet starts like a PWR packet, then it opens the switch for say ~20us
• if a full PWR packet is received with CRC correct, the current limiter is disabled
• if the current limiter is disabled, try to enable power (as described above) every ~2 seconds

It is also possible to have additional low-powered (or not powered) ports on the power provider. The data lines of these are simply connected to the common data bus of provider.

Details

• it seems the Padauk doesn't have to be a full Jacdac device - no announce or config needed
• the RX code will have to be unrolled but then it should be easy to check for PWR packets and throw the switch
• the SOT23-6 package has 4 GPIO, one of which is open drain or input only; if we want an LED to show status (plus Jacdac data and analog switch control), this leaves one pin for current limiter - can it work with just one pin?

Questions

• what's the payload of PWR packet?
• should the Padauk send something when it detects an over-power? - note that if you have two power providers connected via the high-power ports, they will ping-pong power every 2s
• should the Padauk send something when it detects an over-current?

[mmoskal]

Example "schematics"

[mmoskal]

Some more notes:

• if we get PWR packet while limiter is disabled, we delay enabling it for another 2s - this will prevent power-switching between providers; is that good? (it will be random which one wins the first round)
• I think, instead of flipping the switch on receive, we should flip it during send of the PWR packet (I think best would be for the duration of first or last byte) - this way we're only sending it to our sub-bus and others don't have to worry about getting it
• if we want to do this with a single chip (G0 or something), we would need the analog switches and additional switch that transfers data line from G0 to one or all of the ports; we would also need need GPIOs to detect self-loops

[mmoskal]

Follow up:

• the switch needs to be flipped on receive (not send) after all - otherwise if PWR packet comes from one provider to another, we can't say to which channel

For the GO, forget about additional switches on G0 - below is schematic.
The procedure is as follows:

• on detection of beginning of PWR signal - open all switches, look for wiggle at Wi lines - if any has wiggle it's an over-power on that one
• to test for over-power - open all switches except for one, transmit PWR, look for wiggle on the lines with open switches

[sehodges]

I think we proposed 2x GPIOs per current limiter? that let's us ensure the port is off until/unless MCU drives GPIO, and also lets MCU detect overcurrent.

[sehodges]

we could combine that port on/off control GPIO with the LED, but having a separate GPIO for the LED saves a component and lets us do things like blink the LED to convey a particular status

[mmoskal]

If the device is not user-programmable, then we could probably get away with 1 GPIO per limiter. But I think typically we would have the pins to spare 2.

[sehodges]

I don't buy the 'lower power sockets' yet. Would we be better making that 3rd low current limiter that currently drives 2x low power sockets instead be a high current limiter that drives a single 3rd high power socket (for the cost of an extra Padauk)? The user could add an external passive hub if what they really wanted was two sockets for lower current modules.

[mmoskal]

You're right in general, but I think there might be a special case - a single high-power channel provider. In that case you could add a completely unpowered connector (without the 0.1A limiter) for zero cost, that would allow you to connect many of these single-channel providers together.

Also if you keep the 0.1A limiter, you could connect two multi-channel providers together without triggering the "power switching" between them. Not sure if there is any value in that though.

I guess another reason could be if you get 2.4A on input then I guess you could only have 2 1A channels, but you could add 0.1A. Not sure what you get on input though.

Also, I was thinking, one way to make a power provider give more juice is to make it into battery pack - it would be charging through USB-C or whatever, but you can drive as much as the battery lets you (so for big ones 10A or so).

[pelikhan]

Extra passive hub, do you mean a pcb that only has gnd/data lines connected to the edge connectors?

Best if all connectors on the power have the same behavior IMO

[mmoskal]

by passive hub we mean one that connects all three signals, but is otherwise just a piece of pcb

[pelikhan]

I'm siding with Steve as to provide another high power plug rather than low power ones. Eventually there will be many variations of these theme made by vendors.

[sehodges]

If you have 2.4A on the input you can still drive 3x 1A outputs. Sure, you won't get 1A on each simultaneously, but I think you'd still get what you want/expect a lot of the time. Agreed that a single-channel, single socket high power provider is only useful when there are no other power providers. We probably want to mandate a minimum number of sockets for power providers. A 5V 10A supply will give you 50W. You can do quite a lot of damage with 50W. I think we should be careful. Steve

[pelikhan]

What is the strategy to differentiate a high power line? A silk drawing?

[sehodges]

do we need to? we already had the idea of low power providers (like the micro:bit jacdapter) vs high power/smart providers.

having said that, I think the high power ones will have LEDs (and the low power ones probably not, to save space/cost/current).

[mmoskal]

Another take - there could a module that has two Jacdac plugs and bridges the data line but not the power line. It would then have a Padauk and a switch on the data line, so it would not pass through PWR packets. You could have two sub-networks powered with separate power supplies and bridge them with it.

I guess in most circumstances a multi-channel power provider is more user-friendly, but one way to think about it, is several single-channel quite dumb providers bridged with such modules.

[pelikhan]

like an opto-isolator for jacdac? sounds useful.

[sehodges]

We talked about that idea in the communal area outside Tom's old office in B99 when James was interning :-). Now we have a relatively cheap implementation! Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Peli de Halleux ***@***.***> Sent: Thursday, May 13, 2021 6:58:15 PM To: microsoft/jacdac ***@***.***> Cc: Steve Hodges ***@***.***>; Mention ***@***.***> Subject: Re: [microsoft/jacdac] power hub (#373) like an opto-isolator for jacdac? sounds useful. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fjacdac%2Fdiscussions%2F373%23discussioncomment-735091&data=04%7C01%7CSteve.Hodges%40microsoft.com%7Cf790ca41ea4f4664d13f08d91638af06%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637565254985360808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=g2t3uVOvkkrmv68PXdWvBktNgpOkPweJYoiP38Gpvlk%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAC6R2Z7Q2IZHXVWRGWTAPWTTNQHLPANCNFSM44LBSNTA&data=04%7C01%7CSteve.Hodges%40microsoft.com%7Cf790ca41ea4f4664d13f08d91638af06%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637565254985370803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0IGO%2F3NMagJ2D6qWpFoXSTtf5fQ6kV3K4w5hPuPge18%3D&reserved=0>.

[jamesadevine]

I think I'm more convinced by the opto isolator option!