<RossSchulman[m]>
Is there a convenient list of those somewhere? :)
starblue1 has joined #beagle
thinkfat has joined #beagle
starblue has quit [Ping timeout: 240 seconds]
thinkfat_ has quit [Ping timeout: 272 seconds]
zmatt has quit [Ping timeout: 272 seconds]
zmatt has joined #beagle
mattb0ne has quit [Ping timeout: 250 seconds]
mattb0ne has joined #beagle
Guest27 has joined #beagle
<Guest27>
Starting a project to make a backup harddrive to use in the field to interface directly with a camera like upper end Sony and Canon. I would like to utilize the speeds associated with USB C and also that is now the USB interface cameras are moving to. I am unclear if something like the BeagleBone AI uses USB C for just power or power and data. If
<Guest27>
it is only power does someone have a suggestion for a single board low power platform that might run something like little-backup-box.
buzzmarshall has quit [Quit: Konversation terminated!]
<GenTooMan>
to be fair USB-c is a mess you can be quite evil with it.
<zmatt>
usb-c is a mess yeah
<zmatt>
and iirc it's also not easy to find a small simple type-c controller that supports data swap
<zmatt>
let alone have a linux driver that somehow ties into the musb driver (dunno even what the mechanism for that is or is intended to be)
rob_w_ has quit [Ping timeout: 256 seconds]
rob_w_ has joined #beagle
rob_w_ has quit [Remote host closed the connection]
rob_w has quit [Quit: Leaving]
samael has quit [Read error: Connection reset by peer]
<Konsgn>
Is there a acceptable approach to tying in usb-c data role with musb core?
<GenTooMan>
I believe Apple could have done a great job if they had thought things through more carefully but typical Apple is to ram things through and ignore the consequences.
<Konsgn>
haha, couldn't you recharge your early macbook by plugging a usb-c cable between both port? You gotta respect that they solved perpetual energy.
<zmatt>
Konsgn: I vaguely recall having at least seen bits of DT bindings suggesting intended mechanisms for such but I don't know 1. if I remember correctly 2. if those have been implemented yet or are just good intentions
<zmatt>
Konsgn: I mean, yes? how would it know it's not charging an external device while it's receiving power from some other external source?
<Konsgn>
There is a file exposed in the debug fs that you can set to 1 to force usb roles. was planning to use it.
<zmatt>
I mean, that's a hack you can use if you don't have a working driver for your type-c controller
<Konsgn>
zmatt, I do think they fixed that issue. perhaps by sending data packets to detect if a macbook is connected
<zmatt>
you'll need to have userspace soft-disconnect the port, communicate with the type-c controller to perform the data role swap, and then manually force it into host role
argonautx has quit [Ping timeout: 258 seconds]
<zmatt>
what if you want to charge two macbooks from one usb-c power source by daisy-chaining the macbooks?
<Konsgn>
detect the serials perhaps?
<Konsgn>
now I'm curious if that is possible
<zmatt>
you could also just ignore the "issue" since it requires doing something dumb and the only negative result is a bit of energy wasted
<Konsgn>
daisychaining i mean
<zmatt>
well it should work, it should have worked unless they "fixed" this "issue" in a way that makes it no longer work
<Konsgn>
To me that functioning state just feels wrong.
samael has joined #beagle
<Konsgn>
hmmm, perhaps they never fixed it.
<zmatt>
why? if the middle device is capable of supplying enough current for the downstream device and can handle the total current on its upstream port to the power source, why wouldn't you be able to daisy-chain?
<Konsgn>
seems like you can, and plugging in to yourself will also charge
<zmatt>
yes, you'd need something like a spanning tree protocol to completely avoid power-cycles
<Konsgn>
Hmmm, I wonder if a daisy chain loop of macs will balance their batteries to the same level
<zmatt>
what happens if you just connect two macbooks? who charges who?
<Konsgn>
No clue
<zmatt>
there's no point in a power-loop, it'll always waste power
<Konsgn>
But someone is charged I think.
<zmatt>
yes I assume it's arbitrary, I wonder if it matters which side you plug in first
<zmatt>
and whether there's a way in the UI to swap roles
<Konsgn>
Waste power yes, but that is also a side effect of battery balancing in a pack of cells
<zmatt>
no there isn't
<zmatt>
actually, now that I think about it, shouldn't the loop prevent charging because it notices it can't supply the current required?
<zmatt>
I guess it's a bit tricky because the power negotiation isn't that fine-grained
<GenTooMan>
yeah it's more like hammer nail mentality.
<zmatt>
I'm trying to think what happens.... it definitely won't be charging the battery _at all_ since there's no actual power available for that
<zmatt>
with a 1 device loop that is
<zmatt>
with a 2 device loop it's a bit more complicated to say what happens exactly
<zmatt>
it'll depend on implementation details
<Konsgn>
with 1 device loop, there will just be energy loss at whatever the loop design is.
<zmatt>
but, I'm pretty sure all that happens is that current will be sent in a loop between the two devices, this loop will be supplied by one or both of the devices from their batteries, and neither battery will charge
<zmatt>
and no balancing happens
<zmatt>
if I had to make a prediction, that would be it
<zmatt>
with the caveat that it's definitely possible to get different results, depending on exact implementation details
<zmatt>
especially if you use two dissimilar devices rather than two devices of the same model
<Konsgn>
It may depend on the negotiated voltage, if the voltage was greater than battery I would imagine that some energy gets to the battery
<zmatt>
I expect both devices to negotiate the same thing if they're the same type of device
<zmatt>
and the usb-c voltage is not that relevant I think
<zmatt>
it'lll get converted anyway
<Konsgn>
Well, they have to for a connection. And while it would be converted, I think it gets converted down/up to batt v
<Konsgn>
with the energy going past the battery it may feed some current into it.
<zmatt>
that's not how it works
<zmatt>
there's still a charger in between the system rail and the actual battery
<zmatt>
while discharging the system rail will be slightly lower than battery, while externally supplied it will be higher than battery and it needs to be higher than battery charging voltage to be able to commence charging the battery
<Konsgn>
maybe I'm not describing it right.... and in the chip from ti I was working with, it's not a full on charger, the only thing between batt/system is a mosfet/shunt
<zmatt>
that mosfet + its control logic *is* a charger
<Konsgn>
okay, then we are saying the same thing.
<zmatt>
the problem is, to get the system rail of one device higher than its battery requires getting more energy *into* that system via the loop than *out* of it
<zmatt>
despite the losses
<Konsgn>
yes but energy could be pulled from the other devices battery to get the system rail above a discharged batt v
<zmatt>
it could happen I guess, it'll just depend on the details
<Konsgn>
Yea, i wonder if anyone tested this.
<zmatt>
it's not like it would be useful in any case, given that you'd be continuously wasting power and continue to do so once balanced
<zmatt>
a better way to balance would be have the devices communicate and use power role swap to have the device with higher remaining battery capacity supply the one with lower remaining battery capacity
<zmatt>
or something like that
<zmatt>
but usually it would be better to have the device with lower capacity just draw its operational power from the device with higher capacity without actually charging its battery
<zmatt>
that pools the batteries without wasting power on charging one battery from the other
<zmatt>
in cases where you do want one device to charge the other, I think it's more likely you'd want to charge the recipient at the expense of the donor as opposed to balance them
<zmatt>
in the end it's all entirely dependent on the user's intentions, hence best solved by explicit control in the user interface
florian has quit [Quit: Ex-Chat]
<Konsgn>
agree with explicit control, and i think one additional pd specified token of information should be wall-powered/battery, watt-hour capacity, and current watt-hours
<Konsgn>
it may actually have that already....
<zmatt>
unlikely, the recipient doesn't care about these things, it just cares about being allowed to draw power
<zmatt>
there are only some special conditions on recipients which a very depleted battery (which are allowed to be a bit more dumb and rude about attempting to draw power)
<zmatt>
jkridner[m]: it seems logs.nslu2-linux.org is gone
xet7 has quit [Read error: Connection reset by peer]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
argonautx has joined #beagle
dinuxbg has quit [Ping timeout: 258 seconds]
xet7 has joined #beagle
Shadyman has joined #beagle
m-atoms has joined #beagle
<m-atoms>
coming to you live from hexchat, about time I moved away from the web interface
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 272 seconds]
dinuxbg has joined #beagle
akaWolf has quit [Ping timeout: 265 seconds]
akaWolf has joined #beagle
russ has joined #beagle
mattb0ne has joined #beagle
CrazyEddy has quit [Ping timeout: 252 seconds]
CrazyEddy has joined #beagle
Konsgn has quit [Read error: Connection reset by peer]
<ryanh>
basically, i can't find a way to store authentication passwords hashed through connman. I'm thinking of something like the nmcli --ask option. am I missing something obvious or is this not supported? if this is not supported do people just network manager in this situation?