set_ has joined #beagle
<set_> I missed everything! Dirt in my lungs. Yay!
<set_> BBB. Sorry.
buckket has quit [Remote host closed the connection]
nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle
buckket has joined #beagle
<nmingotti> set_, it is a subject started days ago, before the 30 Dec i guess ;)
<nmingotti> long story short, i also have the BBB since a long time, now trying the BB-AI which is more powerful but also heats a LOT
<nmingotti> bought FanCape, problem it is super noisy => impossible to reach the author is in holiday => i made my pwm to control the FanCape fan speed
<nmingotti> => needed to run the script that control it via systemd at boot, that required help from udev, this is the part i made today
<set_> Nice!
<set_> Does it work?
<nmingotti> now time to bed for me, in Moscovian holiday it is late night and if my wife wakes up she will be pretty much furious
<nmingotti> YES :) working
<set_> Nice! Double Nice.
<set_> Okay.
<set_> Well, if you have to go, I must go too.
<set_> Dirt is not going to make itself.
<nmingotti> okis, c u !
<set_> Dang it. Sorry. Still cloudy!
<nmingotti> bye all
nmingotti has quit [Quit: Client closed]
<set_> nmingotti just liked me. It was awesome.
<set_> I feel it, man.
<set_> I feel it.
vagrantc has quit [Quit: leaving]
CrazyEddy has quit [Ping timeout: 240 seconds]
CrazyEddy has joined #beagle
<set_> For when you get around to it, @zmatt, were you being serious about that odd piece of add-on to the OrangeRX, i.e. R110XL?
<set_> B/c...I will try it. GenTooMan knows
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #beagle
* GenTooMan wonders what set_ is frying.
<hays> zmatt: thanks for the help the other day. is it ok if I occasionally ask questions here or would you prefer i take them elsewhere
<set_> Hamburgers!
<set_> Fried cheese alawishious! I am building my squad up, toughness. BBB style. I just typed that out. Yes sir!
<set_> Anywho. So, @zmatt, no. That receiver thing you showed me will not work, i.e. as there is only one port that is supposed to go where?
<set_> Anyway, no issue. I just thought I could rehash the issue of me not knowing anything (as usual).
<GenTooMan> of all the things I miss in life, I forget what it was the most
mranostaj has joined #beagle
<mranostaj> so does the beaglebone ai have a special defconfig? because the bb.org_defconfig is getting super hot
<rcn-ee> mranostaj, you can nuke the am3 stuff. ;)
<rcn-ee> sorry it's a kitchensink...
<mranostaj> rcn-ee: but is there a defconfig i can sanely use? :)
<rcn-ee> so while i've tested the BBB with omap2plus defconfig, i've never tried that on a bbai... it might work...
<mranostaj> hmm but is there a x15/ai one floating around also using the 5.10 branch
<rcn-ee> oh, grab ti's config... (opens browser)
<rcn-ee> i use it for reference, when ti makes a change..
<rcn-ee> mranostaj, while in that branch.. ti has config builder... run: ./ti_config_fragments/ -l
<rcn-ee> all that is in our 5.10-ti branch direct copy from ti..
<rcn-ee> mranostaj, since it's mostly a script and fully automated when i push builds.. do you want me to generate ti's dra7x_release for am57x and other for am33xx builds?
<rcn-ee> they wouldn't really be tested.. but i think TI tests them...
buzzmarshall has joined #beagle
<mranostaj> can't hurt to generate but i'll look at the branch too
vagrantc has joined #beagle
<hays> hmm... does the pocketbeagle exist?
<vagrantc> i have one, but it had a few too many sparks one day
vagrantc has quit [Quit: leaving]
hnv has quit [Quit: Client closed]
<mranostaj> hays: you mean the supply chain.. and backorders? or that i've seen one? :)
buzzmarshall has quit [Quit: Konversation terminated!]
<mranostaj> rcn-ee: using that fragment it still overheats and shut down
<hays> mranostaj: well sometimes things are obsolete or otherwise canceled vs. hard to get a hold of
<hays> so was curious if the pocket was former or latter
<mranostaj> hays: was looking at mouser recently.. did notice some backordered till like dec 2022
starblue has quit [Ping timeout: 240 seconds]
Shadyman has quit [Quit: Leaving.]
starblue has joined #beagle
vigneshr has joined #beagle
hnv has joined #beagle
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle
otisolsen70 has joined #beagle
jfsimon1981 has quit [Read error: Connection reset by peer]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
<rcn-ee> bbai likes to overheat idling in it's default state...
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Client Quit]
jfsimon1981 has joined #beagle
lucascastro has quit [Remote host closed the connection]
buzzmarshall has joined #beagle
rcn-ee_ has joined #beagle
rcn-ee has quit [Remote host closed the connection]
lucascastro has joined #beagle
florian has quit [Quit: Ex-Chat]
Shadyman has joined #beagle
rcn-ee_ has quit [Ping timeout: 256 seconds]
rcn-ee has joined #beagle
rcn-ee_ has joined #beagle
rcn-ee has quit [Ping timeout: 256 seconds]
<zmatt> goddamnit TI... they gave pruss a nice peripheral for doing bidirectional I/O ("EDIO, part of IEP"), and then on the am335x at least completely botched the integration by creating two pinmux modes for it, one that is input-only (output-enable is ignored), and one that is output-only (input always reads as zero)
<zmatt> why would you do such a thing /o\
<jfsimon1981> hi, can someone please help with using pwm ?
<jfsimon1981> thx
<zmatt> configure period (in ns), configure duty_cycle (in ns), set enable to 1
<zmatt> update duty_cycle to change pwm output
<zmatt> keep in mind that the 'a' and 'b' channels of one ehrpwm instance are required to have the same period
<jfsimon1981> i have difficulties enable the pwm channels:
<jfsimon1981> -bash: echo: write error: Device or resource busy
<jfsimon1981> -bash: echo: write error: Invalid argument
<zmatt> what period did you configure?
<jfsimon1981> better now, it was 0
<zmatt> I have no idea how you got EBUSY though, that doesn't seem to be an error you should ever be able to get from trying to configure or enable pwm channels
<jfsimon1981> when writing 1 to enable although period was 0
<zmatt> that should return EINVAL, not EBUSY
<zmatt> "Invalid argument", not "Device or resource busy"
<jfsimon1981> i try writing to pwm-3:0 for pin 9_14
<zmatt> ?
<jfsimon1981> i can't export pwmchip
<zmatt> they're already exported
<jfsimon1981> ok
<zmatt> there's udev rules that export them and create symlinks in /dev/pwm/
<jfsimon1981> ok, nothing yet to scope though
<zmatt> (at least some versions of the udev rules do this)
<zmatt> did you configure the pin to pwm mode using config-pin ?
<jfsimon1981> checking
<jfsimon1981> yes
<jfsimon1981> with "config-pin P9.14 pwm"
<zmatt> what period and duty_cycle did you configure?
<jfsimon1981> duty 50
<jfsimon1981> period 250000
<jfsimon1981> enable 1
<zmatt> 50 nanoseconds? does your scope have enough bandwidth to see pulses that narrow?
<jfsimon1981> duty 125000
<jfsimon1981> on device pwm-3:0
<zmatt> I have no idea what that is, pwmchip numbering is arbitrary and undefined
<jfsimon1981> ok
<zmatt> use the symlinks in /dev/pwm/ if you want to be sure you're using the right device
<jfsimon1981> i measure on pin 9.14 not sure which pwm this will be. Trying other ones.
<zmatt> P9.14 is ehrpwm1a
<jfsimon1981> i see those only
<jfsimon1981> pwm-0:0 pwm-1:1 pwm-4:0 pwm-6:0 pwm-7:1 pwmchip1 pwmchip4 pwmchip7
<jfsimon1981> pwm-1:0 pwm-3:0 pwm-4:1 pwm-7:0 pwmchip0 pwmchip3 pwmchip6
<jfsimon1981> at /sys/class/pwm
<zmatt> 20:35 <@zmatt> use the symlinks in /dev/pwm/
<jfsimon1981> ok i missed that
<jfsimon1981> thx
<zmatt> showing me which pwmchip numbers you have is useless since, 20:35 <@zmatt> I have no idea what that is, pwmchip numbering is arbitrary and undefined
<jfsimon1981> many thanks
<jfsimon1981> works
<jfsimon1981> yep i missed the dev tree
<jfsimon1981> that's all right with this one
<jfsimon1981> Doing IR detection, i needed an accurate pwm for that purpose, since IR modules required 38 kHz or kHz modulated signal.
<zmatt> yeah I've been advocating for using udev to create convenient symlinks to hopefully combat people hardcoding paths or numbers into software that aren't actually stable but can change based on kernel version or device tree configuration
<zmatt> I have a similar rule for gpio, though I'm not sure if that one's installed by default
<zmatt> IR detection or IR transmission?
<jfsimon1981> detection
<zmatt> huh, why do you need a PWM output for that?
<jfsimon1981> so I get an IR led and a receiver module which I need to figure out the right tuning, so i need flexibility on frequency.
<zmatt> ah to test your IR receiver
<jfsimon1981> The ir module works with a band pass filter hence the ir led needs to be modulated at 38 kHz. I also need to test it, right, and tune it.
rcn-ee__ has joined #beagle
rcn-ee_ has quit [Read error: Connection reset by peer]
m-atoms has joined #beagle
<jfsimon1981> Found this in the application note
<zmatt> the uarts on the am335x actually support IR transmission and reception (both IrDA and free-format, with integrated carrier modulation/demodulation) ... the problem is as usual driver support, or lack thereof
<jfsimon1981> the principle is to move the emitter modulation from best working frequency (38 kHz) downward until loosing the ir reception. this gives the IR reflection level. Based on this we can evaluate the presence of objects.
<zmatt> ah, that kind of detection
<jfsimon1981> i see
<zmatt> I assumed communication, never mind
<jfsimon1981> for this purpose nope
<zmatt> wouldn't it make more sense to keep the frequency at 38 kHz and use the duty_cycle to (sort of) modulate the signal strength?
<jfsimon1981> to modulate 38 kHz i need the PWM, there's no modulator in the LED, it's just an IR led 940nm.
<zmatt> I understand
<jfsimon1981> i think both approaches are possible
lucascastro has quit [Remote host closed the connection]
<jfsimon1981> i'd need 2 PWM then.
<zmatt> they are, but the response w.r.t. frequency would be hard to predict and dependent on the filtering
<zmatt> no
<zmatt> why?
<jfsimon1981> one for modulating 38 kHz and one for signal power modulating much higher frequency
<zmatt> just vary the duty cycle between 0 and period/2
<jfsimon1981> yep
<jfsimon1981> i'll test that way, did'nt thought of it
<zmatt> I think the amplitude of the fundamental frequency of a pwm signal is proportional to sin(Pi*duty_cycle/period)
<zmatt> with a maximum at duty_cycle=period/2
<mranostaj> rcn-ee__: fan cape on order now :). have a desk fan on it for now :)
<jfsimon1981> i did'nt know
<zmatt> and all of the harmonics are odd multiples of the fundamental frequency, i.e. 114 kHz or higher, so probably blocked by the bandpass filter
<rcn-ee__> mranostaj, the 'fan cape' also disables the 400Mhz opp.. if you have fan force the overlay...
<rcn-ee__> (or patch the dt..) to remove the 400mHz opp..
<jfsimon1981> there are 38 kHz and 56 kHz, apparently those are the 2 standard mainly used
<mranostaj> rcn-ee__: heh board is a little ducted tape together i see :)
<jfsimon1981> successfully modulating at 38 k now.
<mranostaj> i assume the fan runs at full blast on startup right?
<zmatt> I saw someone mention they figured out how to control the fan
<rcn-ee__> mranostaj, yeap.. nmingotti figured out control...
<rcn-ee__> it's a black box micro..
<zmatt> jfsimon1981: I mean for a 38 kHz pwm signal
<rcn-ee__> it was also the last design by "x" before we moved everything to seeed...
* mranostaj facepalms
<hnv> Good news: A lot of BBBs just arrived to my country.. and in a great timing (R-Pi s shortage)
<jfsimon1981> yes
<zmatt> rcn-ee__: I still find the 400 MHz "opp" odd... since it's not a defined opp you can't use a lower voltage, and without being able to drop the voltage it *should* actually result in higher power consumption (by reducing idle time for the same workload) if power management, specifically cpuidle, is working like it should... which may not be the case
<rcn-ee__> zmatt, that was a face palm, @jkridner noticed that last year i think.. pmic isn't even wired to lower voltage..
<zmatt> it is though? or does the swapped (and entirely unnecessary) connection to the pmic's second i2c port demolish the entire bus?
<zmatt> that second port will just see nothing but start and stop conditions, so I doubt it will ever touch either of the bus lines
m-atoms has quit [Ping timeout: 256 seconds]
m-atoms has joined #beagle
<zmatt> but that second i2c interface is meant for hardware-controlled dvfs (which is not supported by the SoC) and merely exposes a small subset of the registers exposed on the first i2c interface, so it's entirely irrelevant
<zmatt> I'm pretty sure the system wouldn't even boot if communication with the pmic were impossible
waldo323 has joined #beagle
lucascastro has joined #beagle
Guest2922 has joined #beagle
<Guest2922> Hi my company is looking to export a BBONE-BLACK-4G overseas but as the compliance person I need the ECCN tariff schedule and country of Origin how do you guys provide that if at all?
<Guest2922> If you would like the email me the answer I can be reached at
vagrantc has joined #beagle
<mranostaj> rcn-ee__: heh so the PIC emulates the id ROM for the fan cape?
Guest2922 has quit [Quit: Client closed]
<rcn-ee__> mranostaj, yeap!
set_ has quit [Ping timeout: 256 seconds]
<jfsimon1981> zmatt, i'll try your approach, doing the c++ program to estimate the distance based on when the ir receptor triggers, and playing with the duty to follow the reception limit. See if that works ...
otisolsen70 has quit [Quit: Leaving]
set_ has joined #beagle
hnv has quit [Quit: Client closed]
set_ has quit [Remote host closed the connection]
set_ has joined #beagle
<zmatt> jfsimon1981: I also realized my earlier remark about a pwm spectrum's signal having only odd harmonics is nonsense, that's only true for a square wave (50% duty cycle)
<jfsimon1981> I think there must be, but the module has a band pass filter, that's leaving off most signal passed 1.3:1 frequency ratio
<jfsimon1981> i'm implementing the limit finder now ... (ir reception threshold). Interesting
<zmatt> yep, and a pwm signal's spectrum definitely only consists of harmonics of the pwm frequency, so only the fundamental should pass the bandpass
<jfsimon1981> Got something, i'm trying to move objects, see if the device detects the diff.
<zmatt> this sounds like something for which you'd want a detector that outputs an analog value
<jfsimon1981> yes harmonics are mostly discarded.
<zmatt> (or use some off-the-shelf proximity sensor)
<jfsimon1981> they were too slow, so i have to build a custom one. It may exist as we need but the BBB also includes a graphic interface so on.
<zmatt> too slow? there's a huge variety of proximity sensors, it can't be that hard to find one that meets your needs and isn't too painful to interface to the bbb
<zmatt> not sure what you mean by the graphic interface and such... what does that have to do with a sensor?
<jfsimon1981> i mean thus i decided to incorporate all that with the bbb
<jfsimon1981> the optical sensor it not too difficult to build
<zmatt> wouldn't ultrasonic be more accurate? those are pretty cheap and ubiquitous
<jfsimon1981> it may need to be customized in dimension and sensitity, i did'nt look too much into the market. I went for testing see if the approach works.
<jfsimon1981> I think ultrasonic would be a right way, i did'nt think of it
<jfsimon1981> maybe both approaches would do.
<jfsimon1981> ir/us
<jfsimon1981> love it, that seems to work ...
<zmatt> the am335x has some nice peripherals that can measure pulse width and pulse distance with 10ns or even 5ns resolution
<jfsimon1981> definitely seem to work
<zmatt> nice
<jfsimon1981> happy
<jfsimon1981> by the way i ramp the duty cycle and find the reception thrshold
<jfsimon1981> so that approach looks to be working.