<set_>
Oh! I got you now. I am w/ you. You used right-angle headers on the UART header(s).
<SJFriedl>
Yes
<set_>
Okay.
<set_>
That works too!
<SJFriedl>
desolder the old ones, solder in a new one but only 3 pins, and I use keying plugs on the RS232 adapter so it can only go in one way.
<SJFriedl>
not sure why they bothered with 7 pins.
<set_>
Or...one could make a...oh. Nice.
<set_>
I was thinking on the cape in question, one could make a cut-out of PCB too.
<set_>
So, the header is accessible that way could be beneficial.
<SJFriedl>
I use a small cable clip to keep this adapter more or less permanently connected
<set_>
Hmm. SJFriedl: What specific UART is this specific header? I think it is UART0, right?
<SJFriedl>
Whatever the serial console is.
<SJFriedl>
I don't use it at runtime, only for initial setup or troubleshooting
<set_>
Yep. Yep. I need to review again but I think it is UART0. Oh. Okay.
<set_>
Oh, yea. It is nice to read logs that way.
<set_>
Do you mess w/ your own builds already?
<SJFriedl>
No, but I start over often enough and re-flash the BeagleBone, and on the wifi unit the serial console is the only way I know how to do this.
<set_>
Sorry. Image building is what I am discussing.
<set_>
Oh.
<set_>
I think beaglebone.local works too!
<SJFriedl>
that wont work until the wifi is set up, and on a newly flashed unit I need the console to get there.
<set_>
For getting the board to locate itself via usb networking, beaglebone.local sometimes works too.
<set_>
Oh.
<set_>
Sometimes, at least for me, I found that it works at times and then does not work at times.
<SJFriedl>
Oh, that would work too, of course.
<SJFriedl>
I guess I've used serial ports on computers for >30 years and this is just an old habit.
<set_>
30 years!
<set_>
I am still new to you! I have been mingling for only about six or eight years.
<SJFriedl>
I'm an old fart :-)
<set_>
ha
<set_>
So, have you ever built a Cape based on a controller and driver for inductive loads?
<SJFriedl>
one of the reasons, now that I think about it, that I mostly don't use the USB port is because the default IP address 192.168.6.x is the same as what's on my network.
<set_>
Oh.
<set_>
Hmm.
<set_>
Okay.
<SJFriedl>
the thing I'm building now drives a relay, but a small one so a simple 2N3904 transistor and flyback diode works fine.
<SJFriedl>
it's an inductive load but a small one.
<set_>
Oh. So, Yep! I am trying to build a thing for 12v motors using a controller and driver but...
<set_>
I need to test more. My motor(s) as of now, do not turn w/ power applied to the breadboard.
<SJFriedl>
Why not get a motor cape?
<set_>
I have two!
<SJFriedl>
they working for you?
<set_>
I do not want another one...oh and yes. They work awesomely. Is awesomely a word?
<set_>
Anyway...
<SJFriedl>
it's a great word :-)
<set_>
I think they are great builds but I want one for myself, i.e. that I actually built.
<set_>
I want to make a TI.com build of a Cape too. I found one a while back.
<SJFriedl>
sounds like a good project
<set_>
Yes. I know I am probably boring you but wait. I will show you the exact controller and driver(s) bring used...
<SJFriedl>
is it an h-bridge ?
<set_>
uc2637 and lm1949 are my two pieces.
<set_>
No. Not an H-bridge.
<SJFriedl>
(looking)
<set_>
Okay.
<SJFriedl>
trying to stick all with TI?
<set_>
For now. I found other parts but I was thinking why not stick w/ them...
<set_>
They still produce updates to their datasheets constantly and offer ideas into how to build test circuits too.
<SJFriedl>
Hmm. I also bought a Power Cape from the same people, and though the 3.3v output is 3.3v, the 5v output is 4.75v. Seems low.
<set_>
Oh? Well, I should check that out. I think you need to supply a barrel jack to the BBB in question.
<set_>
The Cape states it is regulating the 5v via the silkscreen.
<set_>
Let me test something else.
<SJFriedl>
aha. The output of IC2 (pin 4) is right at 5V, but the other side of diode D3 is the lower 4.86
<set_>
I think you are right. 5v is 4.67v on my Cape. I tested from the Cape and the BBBW GNDs.
<set_>
Hmm.
<SJFriedl>
but if you test on the other side of D3, it will be 5
<set_>
say what? Hmm. So, do you think it was built to hinder specific pins from using exactly or close to 5v?
<SJFriedl>
I don't know what the rationale is.
<set_>
Oh.
<set_>
Okay.
<set_>
Me neither.
<set_>
What is the port for VS Code?
<SJFriedl>
Yah, the switching IC is the 5.0v version, and the voltage drop across the diode brings it to ~4.75v. Seems like something the cape docs should have noted.
<set_>
Oops.
<set_>
Ha.
<SJFriedl>
This just looks crazy - they used a 5.0v regulator then drop it with a diode to power the BB at ~4.8v, when they could have used the adjustible version of the same chip and used a voltage divider to set the output so it's 5.0v after the diode. I don't get it
<set_>
One, meaning myself here, the BBB needs under 5v to supply its needs for power?
<zmatt>
no, input should be 5V
<set_>
Hmm.
<set_>
So, what is up w/ the Cape?
<zmatt>
4.75 is already marginal and may cause problems with usb
<zmatt>
SJFriedl: the diode is presumably there to protect the buck converter if the BBB is powered via its 5V barrel jack while the cape is attached (which regrettably causes the 5V input on P9 to become a 5V output since it's tied directly to the 5V barrel jack)
<zmatt>
though it's not clear to me whether that would even bother the MIC4680
starblue1 has quit [Ping timeout: 250 seconds]
starblue1 has joined #beagle
<hnv>
I wonder if the FB pin can be connected after that diode and remain stable
<zmatt>
I see no obvious reason to suspect that the diode is needed at all
<SJFriedl>
I cannot be the first person who has observed this.
<SJFriedl>
I'm pretty special, but not *that* special :-)
<zmatt>
hnv: but if it is, I'd sooner suspect the FB pin is what needs protection than the SW pin, but I guess either could be the case, dunno
Shadyman has joined #beagle
<zmatt>
SJFriedl: this is the first time I've encountered someone using this cape
<hnv>
The FB has the high impedance of an OpAmp in // with a voltage divider, I guess no protection is needed. The series pass transistor may have a emitter-base breakdown voltage gt the 5v rail so maybe it doesn't need protection either... not sure though
<set_>
Wait...
<zmatt>
hnv: it'll also depend on what kind of ESD protection has been implemented
<set_>
So, the barrel jack makes an input of 5v an output of 5v?
<zmatt>
set_: ???
<set_>
I just read what you typed, @zmatt.
<set_>
W/ this Cape attached is what I am describing.
<zmatt>
set_: the barrel jack and the 5V input on the expansion header (P9.05-06) are directly tied together
<set_>
Okay.
<zmatt>
so any voltage you put one one will also appear on the other, since they're literally the same thing
<set_>
Okay.
<set_>
What happens when there is not a barrel jack present?
<zmatt>
what do you mean?
<set_>
It is just as usual, i.e. 5v input?
<set_>
For Cape detection...right?
<zmatt>
?????
<set_>
Okay, so let me try to make more sense here.
thinkfat_ has quit [Ping timeout: 240 seconds]
<set_>
So, say the PowerCape, in which I currently have one attached to the BBBW, is attached and a barrel jack is installed into the connector on the BBBW. Okay so, the PowerCape now on P9.5/6 is output but was input beforehand, e.g. before the installation of the barrel jack?
thinkfat_ has joined #beagle
<set_>
Either way, no issue w/ me. I am just entertaining the idea of working w/ this specific Cape.
<set_>
I got it a while back and wanted to incorporate it in w/ the controller and driver(s) for 12v motors.
<zmatt>
5V output of PMIC is comes either from usb vbus or 5V in, whichever has a higher voltage... or neither when the beaglebone is powered off
<set_>
Okay.
<zmatt>
but the 5v input via P9 and 5v input via barrel jack are tied together, there's nothing preventing power from flowing into one and out the other
<zmatt>
(which has resulted in some capes erroneously using P9.05-06 as power supply input, causing those capes to fail to work when powering the BBB via USB)
<set_>
Okay.
<set_>
Thank you! That is good news.
<set_>
now I know!
<zmatt>
???
<set_>
I did not know.
<zmatt>
which part is "good news" ?
<set_>
me knowing now.
<set_>
If I am to use these boards, I need to know as much as possible...
<set_>
I get sidetracked, as you know, easily. So, to know something else simply by reading makes me feel better.
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #beagle
<set_>
Oh!
<set_>
If you have kernel 5.10.x right now, /lib/firmware/ may or may not have BBORG_POWER-00A2.dtbo available right now.
<set_>
Mine does not from what I can tell right now.
<set_>
The motorCape is not available on the overlays section in the 5.10.x kernel so far either.
<set_>
Oh well. One must wait!
Guest72 has joined #beagle
Guest72 has quit [Client Quit]
<zmatt>
set_: the power cape has no overlay, it wouldn't have any purpose for one
<set_>
Oh. I am using BBIO again and cannot figure out the errors. Are you still involved w/ this lib?
<zmatt>
I've never been involved with it?
<set_>
Oh. Okay.
<set_>
I am reviewing the software now to see if I can do anything to make it work. Blah to that...
<set_>
It is a large lib, i.e. larger than expected.
<set_>
It is going to take a miracle.
<set_>
how can one set up a pwm driver on kernel 5.10.x for use?
<SJFriedl>
is the 3.3v regulator bug a thing on the Black Wireless?
<zmatt>
very much so
<SJFriedl>
I was hoping I didn't have to think about it. Ugh.
<zmatt>
it's also unpatchable on the black wireless since the 3.3v regulator is integrated into the osd335x SiP
<SJFriedl>
I am hoping for some kind of battery / organized powerdown mode, so I have to think about all this.
<SJFriedl>
and more confusion - the output of the power cape by my voltmeter says 4.86v, but my scope says 4.95v. weird.
<zmatt>
yeah, I gave up on that... we do reconfigure the eMMC into its most reliable/robust configuration (pSLC mode with reliable writes enabled), and we try to minimize unnecessary eMMC writes to both maximize its life and minimize the risks of power cuts
<zmatt>
so far these measures appear to have been sufficient, haven't seen any case of a corrupted filesystem yet
<SJFriedl>
my application is an embedded one: keep an eye on some industrial equipment, basically counting product and phoning home to a cloud-based stats system, but the machine has a Big Red Button to just kill the power, and this is used often. I want to give it enough battery or supercap or whatever to power down gracefully.
<zmatt>
our devices are applicances with an on-off switch
<SJFriedl>
hard power or soft power?
<zmatt>
if you're logging to cloud it sounds like you may be able to use a readonly rootfs and avoid eMMC writes entirely?
<zmatt>
hard power
<SJFriedl>
we have to log locally in case there's no connectivity. wifi takes a minute to come up.
<SJFriedl>
I might just run separate power and keep the thing on all the time and be done with it.
<zmatt>
a minute? o.O
<SJFriedl>
or so, maybe 30 seconds. and the internet is not always up or has a problem, we don't want to lose metrics. The machines are labeling covid test collection tubes, a good operator can run >80/minute.
<zmatt>
sounds like it's probably not a lot of data, but yeah if the eMMC is still in its default configuration, any unannounced power loss can potentially cause random corruption (including of data other than the sectors being written)
<SJFriedl>
what should I google to discover this eMMC config issue?
<zmatt>
it's not really an eMMC issue, it's just an obnoxious property of MLC NAND flash
<SJFriedl>
am I better off using an sd card for this?
<SJFriedl>
what is the non-default configuration?
<zmatt>
not unless you get some kind of industrial SLC card
<zmatt>
ask me later, gotto go
<SJFriedl>
thanks for your help. I'll do some digging