**** BEGIN LOGGING AT Fri Jan 07 02:59:57 2022
Jan 07 03:06:00 <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?
Jan 07 03:06:56 <set_> Anyway, no issue. I just thought I could rehash the issue of me not knowing anything (as usual).
Jan 07 03:11:52 <GenTooMan> of all the things I miss in life, I forget what it was the most
Jan 07 03:20:03 <mranostaj> so does the beaglebone ai have a special defconfig? because the bb.org_defconfig is getting super hot
Jan 07 03:23:28 <rcn-ee> mranostaj, you can nuke the am3 stuff. ;)
Jan 07 03:23:41 <rcn-ee> sorry it's a kitchensink...
Jan 07 03:24:54 <mranostaj> rcn-ee: but is there a defconfig i can sanely use? :)
Jan 07 03:25:36 <rcn-ee> so while i've tested the BBB with omap2plus defconfig, i've never tried that on a bbai... it might work...
Jan 07 03:26:46 <mranostaj> hmm but is there a x15/ai one floating around also using the 5.10 branch
Jan 07 03:27:11 <rcn-ee> oh, grab ti's config... (opens browser)
Jan 07 03:27:38 <rcn-ee> https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-5.10.y/patches/ti_sdk_dra7x_release_defconfig
Jan 07 03:27:49 <rcn-ee> i use it for reference, when ti makes a change..
Jan 07 03:29:59 <rcn-ee> mranostaj, while in that branch.. ti has config builder... run: ./ti_config_fragments/defconfig_builder.sh -l
Jan 07 03:30:17 <rcn-ee> that's where i borrowed it's output from: https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-5.10.y/build_kernel.sh#L50-L73
Jan 07 03:30:50 <rcn-ee> all that is in our 5.10-ti branch direct copy from ti..
Jan 07 03:31:23 <rcn-ee> https://github.com/beagleboard/linux/tree/5.10/ti_config_fragments
Jan 07 03:38:46 <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?
Jan 07 03:39:04 <rcn-ee> they wouldn't really be tested.. but i think TI tests them...
Jan 07 03:41:04 <mranostaj> can't hurt to generate but i'll look at the branch too
Jan 07 04:10:08 <hays> hmm... does the pocketbeagle exist?
Jan 07 04:10:48 <vagrantc> i have one, but it had a few too many sparks one day
Jan 07 04:28:51 <mranostaj> hays: you mean the supply chain.. and backorders? or that i've seen one? :)
Jan 07 05:14:22 <mranostaj> rcn-ee: using that fragment it still overheats and shut down
Jan 07 05:24:42 <hays> mranostaj: well sometimes things are obsolete or otherwise canceled vs. hard to get a hold of
Jan 07 05:25:02 <hays> so was curious if the pocket was former or latter
Jan 07 05:51:13 <mranostaj> hays: was looking at mouser recently.. did notice some backordered till like dec 2022
Jan 07 15:33:04 <rcn-ee> mranostaj, did you plug in the fan cape? https://www.newark.com/element14/6100310/beaglebone-ai-fan-cape/dp/50AH3704
Jan 07 15:33:24 <rcn-ee> bbai likes to overheat idling in it's default state...
Jan 07 19:09:46 <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)
Jan 07 19:10:10 <zmatt> why would you do such a thing /o\
Jan 07 19:18:45 <jfsimon1981> hi, can someone please help with using pwm ?
Jan 07 19:18:49 <jfsimon1981> thx
Jan 07 19:19:47 <zmatt> configure period (in ns), configure duty_cycle (in ns), set enable to 1
Jan 07 19:20:00 <zmatt> update duty_cycle to change pwm output
Jan 07 19:20:31 <zmatt> keep in mind that the 'a' and 'b' channels of one ehrpwm instance are required to have the same period
Jan 07 19:23:18 <jfsimon1981> i have difficulties enable the pwm channels:
Jan 07 19:23:20 <jfsimon1981> -bash: echo: write error: Device or resource busy
Jan 07 19:23:36 <jfsimon1981> -bash: echo: write error: Invalid argument
Jan 07 19:23:38 <zmatt> what period did you configure?
Jan 07 19:24:19 <jfsimon1981> better now, it was 0
Jan 07 19:25:58 <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
Jan 07 19:26:25 <jfsimon1981> when writing 1 to enable although period was 0
Jan 07 19:27:37 <zmatt> that should return EINVAL, not EBUSY
Jan 07 19:27:59 <zmatt> "Invalid argument", not "Device or resource busy"
Jan 07 19:28:46 <jfsimon1981> i try writing to pwm-3:0 for pin 9_14
Jan 07 19:28:54 <zmatt> ?
Jan 07 19:28:59 <jfsimon1981> i can't export pwmchip
Jan 07 19:29:04 <zmatt> they're already exported
Jan 07 19:29:14 <jfsimon1981> ok
Jan 07 19:30:04 <zmatt> there's udev rules that export them and create symlinks in /dev/pwm/
Jan 07 19:30:33 <jfsimon1981> ok, nothing yet to scope though
Jan 07 19:30:38 <zmatt> (at least some versions of the udev rules do this)
Jan 07 19:30:50 <zmatt> did you configure the pin to pwm mode using config-pin ?
Jan 07 19:31:07 <jfsimon1981> checking
Jan 07 19:31:41 <jfsimon1981> yes
Jan 07 19:32:18 <jfsimon1981> with "config-pin P9.14 pwm"
Jan 07 19:32:36 <zmatt> what period and duty_cycle did you configure?
Jan 07 19:33:19 <jfsimon1981> duty 50
Jan 07 19:33:34 <jfsimon1981> period 250000
Jan 07 19:33:44 <jfsimon1981> enable 1
Jan 07 19:33:50 <zmatt> 50 nanoseconds? does your scope have enough bandwidth to see pulses that narrow?
Jan 07 19:34:22 <jfsimon1981> duty 125000
Jan 07 19:34:59 <jfsimon1981> on device pwm-3:0
Jan 07 19:35:17 <zmatt> I have no idea what that is, pwmchip numbering is arbitrary and undefined
Jan 07 19:35:28 <jfsimon1981> ok
Jan 07 19:35:35 <zmatt> use the symlinks in /dev/pwm/ if you want to be sure you're using the right device
Jan 07 19:36:00 <jfsimon1981> i measure on pin 9.14 not sure which pwm this will be. Trying other ones.
Jan 07 19:36:10 <zmatt> P9.14 is ehrpwm1a
Jan 07 19:36:45 <jfsimon1981> i see those only
Jan 07 19:36:46 <jfsimon1981> pwm-0:0  pwm-1:1  pwm-4:0  pwm-6:0  pwm-7:1   pwmchip1  pwmchip4  pwmchip7
Jan 07 19:36:46 <jfsimon1981> pwm-1:0  pwm-3:0  pwm-4:1  pwm-7:0  pwmchip0  pwmchip3  pwmchip6
Jan 07 19:36:56 <jfsimon1981> at /sys/class/pwm
Jan 07 19:36:59 <zmatt> 20:35 <@zmatt> use the symlinks in /dev/pwm/
Jan 07 19:37:17 <jfsimon1981> ok i missed that
Jan 07 19:37:18 <jfsimon1981> thx
Jan 07 19:37:30 <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
Jan 07 19:39:17 <jfsimon1981> many thanks
Jan 07 19:39:24 <jfsimon1981> works
Jan 07 19:39:38 <jfsimon1981> yep i missed the dev tree
Jan 07 19:39:49 <jfsimon1981> that's all right with this one
Jan 07 19:41:13 <jfsimon1981> Doing IR detection, i needed an accurate pwm for that purpose, since IR modules required 38 kHz or kHz modulated signal.
Jan 07 19:41:50 <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
Jan 07 19:42:14 <zmatt> I have a similar rule for gpio, though I'm not sure if that one's installed by default
Jan 07 19:44:12 <zmatt> IR detection or IR transmission?
Jan 07 19:44:41 <jfsimon1981> detection
Jan 07 19:45:05 <zmatt> huh, why do you need a PWM output for that?
Jan 07 19:45:53 <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.
Jan 07 19:46:12 <zmatt> ah to test your IR receiver
Jan 07 19:46:43 <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.
Jan 07 19:47:51 <jfsimon1981> Found this in the application note
Jan 07 19:47:51 <jfsimon1981> https://www.vishay.com/docs/82741/tssp4056sensor.pdf
Jan 07 19:49:33 <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
Jan 07 19:49:59 <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.
Jan 07 19:50:13 <zmatt> ah, that kind of detection
Jan 07 19:50:17 <jfsimon1981> i see
Jan 07 19:50:25 <zmatt> I assumed communication, never mind
Jan 07 19:50:33 <jfsimon1981> for this purpose nope
Jan 07 19:51:37 <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?
Jan 07 19:53:42 <jfsimon1981> to modulate 38 kHz i need the PWM, there's no modulator in the LED, it's just an IR led 940nm.
Jan 07 19:53:59 <zmatt> I understand
Jan 07 19:54:17 <jfsimon1981> i think both approaches are possible
Jan 07 19:54:41 <jfsimon1981> i'd need 2 PWM then.
Jan 07 19:54:43 <zmatt> they are, but the response w.r.t. frequency would be hard to predict and dependent on the filtering
Jan 07 19:54:46 <zmatt> no
Jan 07 19:54:50 <zmatt> why?
Jan 07 19:55:18 <jfsimon1981> one for modulating 38 kHz and one for signal power modulating much higher frequency
Jan 07 19:55:30 <zmatt> just vary the duty cycle between 0 and period/2
Jan 07 19:55:58 <jfsimon1981> yep
Jan 07 19:56:24 <jfsimon1981> i'll test that way, did'nt thought of it
Jan 07 19:57:37 <zmatt> I think the amplitude of the fundamental frequency of a pwm signal is proportional to sin(Pi*duty_cycle/period)
Jan 07 19:57:57 <zmatt> with a maximum at duty_cycle=period/2
Jan 07 19:58:15 <mranostaj> rcn-ee__: fan cape on order now :). have a desk fan on it for now :)
Jan 07 19:58:42 <jfsimon1981> i did'nt know
Jan 07 19:59:33 <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
Jan 07 19:59:45 <rcn-ee__> mranostaj, the 'fan cape' also disables the 400Mhz opp.. if you have fan force the overlay...
Jan 07 19:59:54 <rcn-ee__> (or patch the dt..) to remove the 400mHz opp..
Jan 07 20:00:17 <jfsimon1981> there are 38 kHz and 56 kHz, apparently those are the 2 standard mainly used
Jan 07 20:00:27 <mranostaj> rcn-ee__: heh board is a little ducted tape together i see :)
Jan 07 20:00:46 <jfsimon1981> successfully modulating at 38 k now.
Jan 07 20:00:58 <mranostaj> i assume the fan runs at full blast on startup right?
Jan 07 20:01:19 <zmatt> I saw someone mention they figured out how to control the fan
Jan 07 20:01:31 <rcn-ee__> mranostaj, yeap.. nmingotti figured out control...
Jan 07 20:01:38 <rcn-ee__> it's a black box micro..
Jan 07 20:01:49 <zmatt> jfsimon1981: I mean for a 38 kHz pwm signal
Jan 07 20:01:51 <rcn-ee__> it was also the last design by "x" before we moved everything to seeed...
Jan 07 20:02:47 * mranostaj facepalms
Jan 07 20:03:18 <hnv> Good news: A lot of BBBs just arrived to my country.. and in a great timing (R-Pi s shortage)
Jan 07 20:03:39 <jfsimon1981> yes
Jan 07 20:03:44 <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
Jan 07 20:07:05 <rcn-ee__> zmatt, that was a face palm, @jkridner noticed that last year i think.. pmic isn't even wired to lower voltage..
Jan 07 20:08:45 <zmatt> it is though?  or does the swapped (and entirely unnecessary) connection to the pmic's second i2c port demolish the entire bus?
Jan 07 20:12:22 <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
Jan 07 20:14:20 <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
Jan 07 20:15:42 <zmatt> I'm pretty sure the system wouldn't even boot if communication with the pmic were impossible
Jan 07 21:21:32 <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?
Jan 07 21:23:26 <Guest2922> If you would like the email me the answer I can be reached at andrew.shotwell@caci.com
Jan 07 21:24:34 <mranostaj> rcn-ee__: heh so the PIC emulates the id ROM for the fan cape?
Jan 07 21:30:48 <rcn-ee__> mranostaj, yeap!
Jan 07 21:41:20 <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 ...
Jan 07 23:01:26 <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)
Jan 07 23:03:27 <zmatt> https://docs.google.com/spreadsheets/d/1IRxNrCeXii06Tpk8fV3QymuzZsq19atB-PwzpGEGt-k/edit?usp=sharing
Jan 07 23:03:38 <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
Jan 07 23:04:02 <jfsimon1981> i'm implementing the limit finder now ... (ir reception threshold). Interesting
Jan 07 23:04:08 <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
Jan 07 23:04:57 <jfsimon1981> Got something, i'm trying to move objects, see if the device detects the diff.
Jan 07 23:05:35 <zmatt> this sounds like something for which you'd want a detector that outputs an analog value
Jan 07 23:05:54 <jfsimon1981> yes harmonics are mostly discarded.
Jan 07 23:05:56 <zmatt> (or use some off-the-shelf proximity sensor)
Jan 07 23:08:55 <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.
Jan 07 23:10:37 <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
Jan 07 23:10:53 <zmatt> not sure what you mean by the graphic interface and such... what does that have to do with a sensor?
Jan 07 23:12:01 <jfsimon1981> i mean thus i decided to incorporate all that with the bbb
Jan 07 23:12:15 <jfsimon1981> the optical sensor it not too difficult to build
Jan 07 23:12:58 <zmatt> wouldn't ultrasonic be more accurate?  those are pretty cheap and ubiquitous
Jan 07 23:13:18 <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.
Jan 07 23:13:37 <jfsimon1981> I think ultrasonic would be a right way, i did'nt think of it
Jan 07 23:13:55 <jfsimon1981> maybe both approaches would do.
Jan 07 23:14:00 <jfsimon1981> ir/us
Jan 07 23:15:36 <jfsimon1981> love it, that seems to work ...
Jan 07 23:16:04 <zmatt> the am335x has some nice peripherals that can measure pulse width and pulse distance with 10ns or even 5ns resolution
Jan 07 23:16:31 <jfsimon1981> definitely seem to work
Jan 07 23:16:44 <zmatt> nice
Jan 07 23:16:50 <jfsimon1981> happy
Jan 07 23:17:46 <jfsimon1981> by the way i ramp the duty cycle and find the reception thrshold
Jan 07 23:18:05 <jfsimon1981> so that approach looks to be working.
**** ENDING LOGGING AT Sat Jan 08 02:59:56 2022