<CCFL_Man>
is there any current limiting on the 5V pins of the header when powered with 5V from the usb mini port?
renrelkha has quit [Remote host closed the connection]
renrelkha has joined #beagle
<zmatt>
the 5V output (P9.07 + P9.08) is the 5V supply output of the PMIC, which draws either from USB (max 1.8A) or the 5V barrel jack (max 2A)
<zmatt>
this rail directly or indirectly supplies everything on the board
<zmatt>
drawing 500 mA is probably safe, drawing 1A is probably not a good idea... it'll depend on how much current is being drawn by everything else supplied by that rail, which will vary depending on use-case
<CCFL_Man>
ahh, ok, that makes sense.
<CCFL_Man>
and it cannot be powered if 5V is sourced on the header, right?
<zmatt>
note btw that P9.05+P9.06 are tied directly to the center-pin of the 5V barrel jack. The primary use of these pins are to supply the beaglebone with 5V via the cape headers (as alternative to using the barrel jack or usb), though a cape can obviously draw power from it instead if (and only if) the bbb is powered via the 5V barrel jack, though I'm not sure what max current.
<CCFL_Man>
ahh, right
<zmatt>
heh, had your answer already on its way before you asked ;)
<CCFL_Man>
awesome!
<zmatt>
if your cape needs lot of power, it probably makes more sense for the cape to power the BBB rather than the other way around
<zmatt>
note: when designing capes that use power supplies other than the 3.3V (digital) and 1.8V (analog) supplies provided by the beaglebone, be careful to consider what happens during power-up/down or when the beaglebone is powered off by software (or by a pmic fault)... be careful to ensure the voltage on I/O pins does not significantly exceed the corresponding I/O supply voltage, i.e. 0V when that supply ...
<zmatt>
...isn't on yet
<zmatt>
(the digital I/O pins will _not_ tolerate 3.3V if the 3.3V supply isn't up yet)
<CCFL_Man>
oh, wow
<CCFL_Man>
i was unsure if i wanted to provide 3.3V AVDD from an LDO driven by 5V for my "soundcard"
<CCFL_Man>
or 3.3V from the header, but i imagine it's noisy.
<zmatt>
does the adc have separate analog and digital supply inputs?
<CCFL_Man>
so if i do use the LDO, i'll have to be sure the 3V3 is up
<CCFL_Man>
yes
<zmatt>
so you can probably use the BBB's 3.3V as IOVDD and your own supply as AVDD if you want... though you should double-check the datasheet for that of course
<zmatt>
in fact, AVDD and IOVDD don't even need to be the same voltage (either can be 1.8V or 3.3V independent of the other)
<zmatt>
and "The power-supply sequence between the IOVDD and AVDD rails can be applied in any order. However, keep the SHDNZ pin low until the IOVDD supply voltage settles to a stable and supported operating voltage range.
<zmatt>
"
Shadyman has joined #beagle
<zmatt>
CCFL_Man: btw, you mentioned you needed up to 100 kHz bandwidth... so why 384 kHz samplerate instead of something like 240 kHz ?
<zmatt>
actually, "The device supports an input signal bandwidth up to 80 kHz"
<zmatt>
hmm
<CCFL_Man>
oh yeah, i think the driver does that
<zmatt>
I see the passband of the default decimation filter gets smaller for higher frequencies
<zmatt>
at 384 kHz sample rate its passband is up to 81.4 kHz and its stopband starts at 222.72 kHz
<CCFL_Man>
right
<CCFL_Man>
i guess i'll need to use 768kHz sampling
<zmatt>
why? that wouldn't get you more bandwidth
<zmatt>
since "The device supports an input signal bandwidth up to 80 kHz"
<CCFL_Man>
oh bummer
<CCFL_Man>
what page is that on?
<zmatt>
you can also use 192 kHz samplerate with the "low-latency filter", 88.32 kHz passband
<zmatt>
88.9 actually
<zmatt>
page 30 of the tlv320adc5140 datasheet (that was the part right?)
<CCFL_Man>
yep
<CCFL_Man>
oh no, 6140
<zmatt>
same thing
<zmatt>
basically the same device anyway, seems the dynamic range spec is the only difference
<kveremitz>
zmatt: rcn-ee: jkridner: wanna hear something funny ... I've somehow ended up with an eMMC flasher image ON my eMMC on a BBB :/
<kveremitz>
so if it boots successfully, it attempts to re-write any uSD card I put in it
<kveremitz>
-facepalm-
<zmatt>
kveremitz: generally that happens if people *think* they booted from SD card but in fact booted from eMMC, and then modify /boot/uEnv.txt to make it a flasher
<kveremitz>
rcn-ee: so that was the mystery of the 'failing' images on the GH Issue lol
<jkridner>
I’ve done it on purpose to program SD cards in the past.
<kveremitz>
jkridner: well I suppose if you have a good working image...
<zmatt>
kinda weird that low-latency filter is limited to 3 channels at 192 kHz... that doesn't really make sense to me (since it should be computationally cheaper than a linear-phase filter)
<CCFL_Man>
that's true, but the descimation filters can be disabled
<zmatt>
that sounds unlikely
<zmatt>
(and unlikely to be desirable)
<CCFL_Man>
you think so?
<CCFL_Man>
more image artifacts?
<zmatt>
the only i2c setting with "decimation" in the description is to select between linear-phase, low-latency, and ultra-low-latency
<CCFL_Man>
oh dear, that means i'm stuck
<CCFL_Man>
i knew it was too good to be true
<zmatt>
if you need all four channels then it seems 192 kHz with linear phase filter is the best you can do
<CCFL_Man>
that's true
<zmatt>
it's not super easy to see how fast the transfer function rolls off after 57.6 kHz
<CCFL_Man>
the max that would really be needed in the application is 3
<zmatt>
then 192 kHz with low-latency filter would be better
<CCFL_Man>
you mean the plot?
<zmatt>
probably
<zmatt>
yeah, they don't have a magnification of the transition band
<CCFL_Man>
i wanted to be able to evaluate that
<zmatt>
for the 192 kHz linear-phase filter it seems to be between -10 and -20 dB at 0.4 fS (i.e. 76.8 kHz)
<CCFL_Man>
can gain be added to compensate?
<zmatt>
of course
<zmatt>
(at the cost of also amplifying noise in that region)
<CCFL_Man>
i'll need to figure out if that is a tradeoff
<zmatt>
ah I just noticed that while the low-latency filter has pass-band up to 88.9 kHz, they only specify the phase deviation up to 70.1 kHz (at which point it flies off the chart)
<CCFL_Man>
that's even worse
<zmatt>
well, the axis of the graph goes from -0.5 degrees to 0.5 degrees, so it doesn't take much to "fly off" it :P
<zmatt>
but yeah, that does mean it's impossible to tell from the datasheet how bad the phase deviation gets between 70 and 90 kHz, you'd need to measure it
<zmatt>
and like I pointed out, the low-latency filter also has the caveat that its stopband is well-above nyquist (0.6 fS) hence some of the transition band will have aliasing
<zmatt>
(above 0.4 fS = 76.8 kHz)
<zmatt>
(the ultra-low-latency filter has same pass- and stop-band but terrible phase)
<zmatt>
kinda weird that this thing does not support non-standard samplerates whatsoever
<zmatt>
I've never seen that before
<zmatt>
normally it's like "single rate", "double rate", "quad rate", with (generally overlapping) samplerate ranges for each
<zmatt>
CCFL_Man: btw, since you're going for pretty high bitrates, be sure to design things in a way that supports the adc being either master or slave, so that if one mode gives issues you can try the other
<zmatt>
(i.e. stick the 24.576 MHz audio master clock from the beaglebone into the GPIO1 input of the ADC)
<CCFL_Man>
i was reading in the datasheet that slave mode with the PLL running gives the best performance
<CCFL_Man>
that the PLL runs off of BCLK
<CCFL_Man>
oh, yeah
<zmatt>
I saw they recommend using the PLL, it seems implausible slave mode would be better than master mode, where did you see that?
<CCFL_Man>
it was in one of the supplimental documents that master mode does not allow for high performance
<zmatt>
i did see "For devices configured as master mode in high performance applications, the recommended operating mode is to enable the PLL."
<zmatt>
with PLL enabled there's no logical reason for any difference in performance between master and slave mode, the only difference is in how the data transfer is handled
<CCFL_Man>
yeah
<zmatt>
(and having the side that produces the data be master can make it easier to meet interface timing constraints)
<CCFL_Man>
so i guess the PLL generates the clock in high performance mode from the master clock?
<zmatt>
yeah it'll use the PLL to generate whatever internal clock it needs
<kveremitz>
FEATURERQ: wish people would name their ARM partitions with something other than JUST rootfs LOL , I have about 7 cards, I wnna know WHICH hw its for LOL
<zmatt>
for oversampling and processing
<CCFL_Man>
i still think there is benefit for using the PLL in master mode
<zmatt>
kveremitz: I mean, you could also have set your favorite filesystem labels when flashing those cards
<CCFL_Man>
the BBB has a audio master clock?
<zmatt>
CCFL_Man: I'm not sure why you say "i still think there is benefit for using the PLL in master mode" as if that was ever contested
<zmatt>
it's something I literally said a few lines ago
<zmatt>
yes the BBB has a dedicated 24.576 MHz crystal oscillator which, when enabled, outputs its clock on P9.25 (for use by McASP 0 on the BBB and/or external hardware)
<CCFL_Man>
i said it because some of the people i was working with had disagreed, but they didn't read the datasheet and supplimental documents
<zmatt>
CCFL_Man: well, if a low-jitter 24.576 MHz clock is provided to the ADC then I'm not sure if the PLL makes any difference
<CCFL_Man>
ahh, nice
<CCFL_Man>
oh, that was for another host system, a fpga driven sdr
<CCFL_Man>
but i wanted to develop the "soundcard" for the BBB because the drivers were written
<CCFL_Man>
so i will use that master clock then
<CCFL_Man>
i knew they were wrong when they told me
<zmatt>
it's a good idea to connect it regardless, then you have largest choice in configurations you can try
<CCFL_Man>
exactly
<kveremitz>
zmatt: dayum, I could too :p
<zmatt>
CCFL_Man: ah it's actually quite limited in PLL-disabled mode
<zmatt>
so yeah, PLL definitely needs to be enabled regardless
buzzmarshall has quit [Quit: Konversation terminated!]
<CCFL_Man>
ok, i'll use the masterclock and PLL mode
dyCrazyEd has quit [Ping timeout: 255 seconds]
buzzmarshall has joined #beagle
<CCFL_Man>
if a cape is completely powered from pins 5 and 6, a power adapter is required?
<zmatt>
I feel like I explained those pins in sufficient detail
<CCFL_Man>
you did
buzzmarshall has quit [Quit: Konversation terminated!]
charlie5 has quit [Ping timeout: 255 seconds]
charlie5 has joined #beagle
<CCFL_Man>
i think I'll need to get a power adapter
Guest3542488 has joined #beagle
<zmatt>
how much current are you intending to draw from the beaglebone?
<zmatt>
like I said before, if you need more 5V current than can be drawn from the SYS_5V output from the beaglebone (pins 7 and 8 of P9) then it's worth considering to have the cape supply power *to* the beaglebone (via pins 5 and 6 of P9) instead of drawing from it, that way the cape's power doesn't need to flow through the beaglebone
behanw has quit [Quit: Connection closed for inactivity]
lucascastro has quit [Ping timeout: 265 seconds]
Guest3542488 has quit [Quit: Client closed]
thinkfat has joined #beagle
samael has joined #beagle
thinkfat has quit [Ping timeout: 252 seconds]
<set_>
GenTooMan: Are you up?
<set_>
Anyway, when you awaken, check this out...
<set_>
I have a stepper motor, 12v to 24v, some source, and the source so far can only handle two of the four wires from the stepper. Odd? Yes, but I am stuck.
<set_>
Please hold for the source.
<set_>
https://pastebin.com/zbrAf9k2 is the source w/ two of wires taken up but w/ the MotorCape, I have four wires dedicated to one stepper (Ha) and one L298.
<set_>
I am getting a Light, LED, hence I thought my source from the ole book(s) would guide me to making the button, GPIO.wait_for_edge(Stop, GPIO.RISING), work correctly.
<set_>
...
<set_>
Okay...so the button works for creating the PWM signal to engage. But, it is not creating the GPIO.output to engage. Ahha.
<set_>
Wiring? Hmm. Okay. Wiring...
<set_>
I think the L298 is not supposed to be set up for stepper motors...
<set_>
Argh.
<ketas>
noone talks with set_
<kveremitz>
set_ does a lot of thinking aloud ..
<ketas>
really open guy
ikarso has joined #beagle
<set_>
Oh!
<set_>
Me, me, me!
<set_>
Yep. No one really chats w/ me.
<set_>
It is okay, though.
<set_>
objects!
<set_>
What next?
<set_>
I think that BeagleV is no more. Someone must have pooched the nail...or whatever.
<set_>
Anyway...I guess I should sleep now. Psych or is it sike?
<set_>
Anyway...BBB!
<set_>
Well, I saw that Ubuntu was making one w/ SiFive. What happened? Did the people not want to have their products Open Source?
<kveremitz>
however, the merits of rubber-ducking (ie. explaining to a deaf/mute object/etc) are well-known/-established
<set_>
Fine. I will be quiet. This is not fair. I want my rubber ducky.
<set_>
I thought I could stay quiet. Well, I will after this excerpt.
<set_>
I am not an overseeing body, "As most of you already know." But...I think you guys got the shaft. It is not fair to the .org nor is it fair to the users.
<set_>
That is all.
<set_>
Outside of my jokes and quarrels w/ source, I am not a hater of the beagleboard.org organization.
<set_>
I actually like the products you all have placed upon the world.