vagrantc has quit [Quit: leaving]
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #beagle
thinkfat has joined #beagle
thinkfat_ has quit [Ping timeout: 256 seconds]
florian has joined #beagle
Shadyman has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
florian_kc has joined #beagle
florian has quit [Ping timeout: 272 seconds]
rob_w has joined #beagle
thinkfat has quit [Remote host closed the connection]
thinkfat has joined #beagle
nslu2-log has quit [*.net *.split]
vigneshr has quit [*.net *.split]
pbrobinson has quit [*.net *.split]
vitorio has quit [*.net *.split]
hays has quit [*.net *.split]
hays has joined #beagle
pbrobinson has joined #beagle
vitorio has joined #beagle
nslu2-log has joined #beagle
vigneshr has joined #beagle
Abhishek_ has quit [*.net *.split]
philenotfound has quit [*.net *.split]
philenotfound has joined #beagle
Abhishek_ has joined #beagle
otisolsen70 has joined #beagle
Morshing has joined #beagle
set_ has quit [Ping timeout: 256 seconds]
ikarso has joined #beagle
javaJake_ has joined #beagle
javaJake has quit [Ping timeout: 260 seconds]
javaJake_ is now known as javaJake
shoragan has joined #beagle
florian_kc is now known as florian
spout has joined #beagle
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #beagle
javaJake has quit [Remote host closed the connection]
javaJake has joined #beagle
spout has quit [Ping timeout: 250 seconds]
Shadyman has quit [Quit: Leaving.]
ikarso has quit [Quit: Connection closed for inactivity]
lucascastro has quit [Ping timeout: 260 seconds]
buzzmarshall has joined #beagle
buzzmarshall has quit [Remote host closed the connection]
lucascastro has joined #beagle
argonautx has joined #beagle
lucascastro has quit [Ping timeout: 260 seconds]
Guest9883 has quit [Ping timeout: 250 seconds]
lucascastro has joined #beagle
Guest57 has joined #beagle
Guest57 has quit [Client Quit]
lucascastro has quit [Ping timeout: 246 seconds]
argonautx has quit [Quit: Leaving]
florian has quit [Quit: Ex-Chat]
hnv has quit [Quit: WeeChat 2.3]
Morshing has quit [Remote host closed the connection]
Guest98 has joined #beagle
lucascastro has joined #beagle
zjason`` has joined #beagle
zjason` has quit [Ping timeout: 246 seconds]
Guest98 has quit [Quit: Client closed]
mattb0ne has joined #beagle
<mattb0ne> How can you upgrade from buster to bullseye on the BBB
<mattb0ne> I need a new version of a package and I need to upgrade to do it
<rcn-ee> mattb0ne: just one package?
<rcn-ee> (which package)
set_ has joined #beagle
<mattb0ne> pyqt5
<rcn-ee> ah, that looks fun. ;)
<rcn-ee> (qt5 would need to be rebuilt..)
<rcn-ee> just edit /etc/apt/sources.list buster -> bullseye..
<rcn-ee> then sudo apt update ; sudo apt install apt dpkg ; sudo apt update ; sudo apt upgrade.. ;)
<mattb0ne> even after going to bullseye?
<mattb0ne> I need something later than 5.11
<mattb0ne> i saw that bullseye had 5.15
<rcn-ee> no... sadly, pyqt5... to backport that from bullseye to buster, would need the whole qt5 stack. ;)
<mattb0ne> damn
<mattb0ne> not sure I want to do that
<rcn-ee> grab a spare board, install teh "lxde" image from here.. and sadly qt5...
<rcn-ee> lxde -> sorry xfce...
<mattb0ne> how solid are these images
<rcn-ee> what feature are you woried about...
<rcn-ee> other then using v5.10.x-ti they are not any more tested then I tagged teh 2020-04-06 image 2 years ago...
<rcn-ee> if you don't like v5.10.x, you can downgrade to any other major brnach:
<rcn-ee> otherwise feel free to dist-upgrade your version of buster..
<mattb0ne> i am stuck in package limbo with pyqt5, I just do not want any other headaches
<rcn-ee> pyqt5 depends on qt5... so it's already a headache..
<mattb0ne> lol
<rcn-ee> you know, i see a lot of v5.9.x in pyqt's depends...
<rcn-ee> i wonder if it would bui.d
<rcn-ee> sudo apt update ; sudo apt install devscripts
<rcn-ee> cd ./pyqt5-*/ ; debuild -us -uc
mattb0ne has quit [Quit: Client closed]
otisolsen70 has quit [Quit: Leaving]
mattb0ne has joined #beagle
<mattb0ne> back
<mattb0ne> having some difficulties with windows 11 arrrgggg
<rcn-ee> Sorry i tired the above on Buster, pyqt5 has more things that needed to be backported to Buster... Just grab a spare microsd and start fresh with bullseye, and set it up to mirror what your buster image does today..
<mattb0ne> ok
<mattb0ne> this sucks
<mattb0ne> I was fine and someone when and updated a package and broke my whole setup
<rcn-ee> which package update broke it for you?
<mattb0ne> pyqtgraph is the one complaining
<mattb0ne> if I downgrade it wants pyqt4
<mattb0ne> which gives me other headaches
<rcn-ee> yeah it depends on qt4..
<rcn-ee> here's all teh old debian versions..
<rcn-ee> qt5 first in python-pyqtgraph (0.10.0-2) python-pyqtgraph (0.11.0-6) _. full qt...
<rcn-ee> qt5 first in python-pyqtgraph (0.10.0-2) python-pyqtgraph (0.11.0-6) _. full qt5...
<mattb0ne> so just to be sure if I switch to these monthly that are on bullseye I wont have a problem or I still will
<mattb0ne> I know you answered but I am dense on these things
mattb0ne has quit [Quit: Client closed]
xet7 has quit [Remote host closed the connection]
z6np-6w has joined #beagle
rob_w has quit [Read error: Connection reset by peer]
solrize has joined #beagle
mattb0ne has joined #beagle
<mattb0ne> back
<mattb0ne> are these monthly flasher images
<mattb0ne> not working for me
gurki has joined #beagle
<rcn-ee> what's "not working for me"
Posterdati has quit [Ping timeout: 260 seconds]
<mattb0ne> I cannot load the monthly was it a flasher image?
<rcn-ee> flashers cost me 2x the space.. (as we are adding arm64 and riscv) images..
lucas_ has joined #beagle
<rcn-ee> if you want a flasher, i have one line command listed here: "eMMC flasher"...
<mattb0ne> ok
<mattb0ne> so I would boot from SD with the bullseye image
<mattb0ne> then input those commands and it will move the OS from the SD to flash memory?
lucascastro has quit [Ping timeout: 260 seconds]
<rcn-ee> correct..
<rcn-ee> after typing that first command, the microSD is now a "auto eMMC flasher" so if you have a bank of BBB"s you can flash them one at a time with the same microSD..
<mattb0ne> would I restart and hold the button or the first one is already convereted
<mattb0ne> converted*
<solrize> if i want to run a cpu intensive dsp operation, is it reasonable to do the analog i/o on the pru's, and the math in the application processor?
Posterdati has joined #beagle
<zmatt> solrize: what do you mean by "do the analog i/o" ?
mattb0ne has quit [Ping timeout: 250 seconds]
<zmatt> if you want to process samples from the integrated adc on the cortex-a8 then just using the kernel driver to stream the data probably makes more sense than using pru
<zmatt> but there are certainly situations where using pru to perform i/o and then streaming that data to the cortex-a8 (e.g. via a ringbuffer) for further processing makes sense
<zmatt> your description is too vague to really make any kind of judgement on whether it does in your specific situation
<solrize> zmatt, it's an audio dsp application, 8 khz samples, can i do that with accurate enough timing from linux?
nslu2-log has quit [Quit: Disconnecting from stoned server.]
<zmatt> solrize: linux isn't responsible for the timing, that depends solely on the adc configuration
<zmatt> (unless you use the sysfs mechanism to read a just single sample, but you obviously shouldn't)
nslu2-log has joined #beagle
<zmatt> normally the adc periodically samples the enabled inputs, at a rate that depends on the configuration defined using device tree properties, and the linux driver will stream these to memory using DMA
<solrize> zmatt, ah ok, i didn't realize that. yeah that would do it
<solrize> thanks
<zmatt> some details about this DT configuration and resulting timing:
<solrize> is there also a dac?
<solrize> and is there just one adc muxed between those pins?
<zmatt> not really no, there are pwm outputs but no sigma-delta modulator or something... could be something that could be made with pru probably
<zmatt> (dac)
<zmatt> and yes it's a single adc shared between the 8 inputs, i.e. it will sample and convert the enabled inputs sequentially, not simultaneously
<zmatt> if you want something better you may want to consider interfacing an external audio codec
<zmatt> but it depends on the application... if you're doing 8 kHz sampling then it doesn't sound like you're aiming for particularly high quality anyway
<solrize> well it's going into a radio tranceiver... wondering if pocketbeagle would be suitable for this
<solrize> in order to get slightly higher audio sample rate, and do more modulations
<solrize> and the general conveniences of programming linux ;)
<zmatt> ah
<zmatt> yeah, that doesn't sound like it needs a particularly good audio quality
<solrize> cool, pocketbeagle is still a nice board despite being kind of old by now thanks
<zmatt> and for the output you could probably perform the sigma-delta encoding in advance for the various tones you need to generate and have PRU output those directly (and then add an analog low-pass filter)
<solrize> oh interesting point yeah
<solrize> or just add a dac... this is not so tiny any more but it is still ok
<solrize> do you think the adc resolution matters much? i am wondering why the original design uses the pjrc teensy 3 (which has 13 bit adc's but is cpu limited) instead of the teensy 4 (much faster cpu, but 10 bit adc)
<zmatt> for this? nah
<solrize> hmm maybe can just use teensy 4 then
<zmatt> the am335x adc is 12-bit
<solrize> i was looking here and it says 10
<zmatt> up to 200 kHz sampling (shared across the inputs, so up to 25 kHz when having all 8 inputs enabled)
<zmatt> am335x is what's on the pocketbeagle and beaglebone
<solrize> right yeah, 12 bits
<solrize> don't need 8 inputs but need about 4, two of them slow
<solrize> well maybe a few more really slow, for stuff like battery monitoring
<zmatt> that would just make things inconvenient
<solrize> hmm they would interfere with the audio sampling?
<zmatt> yes
<solrize> oh blech. i see
<zmatt> like, the best you could do is probably run the slow ones at half the sampling rate by using the sampling pattern { 0, 1, 2, 0, 1, 3 } (where 0 and 1 are the fast inputs and 2 and 3 the slow ones)
<solrize> that sounds ok, or could just use a tiny mcu board for the slow stuff
<zmatt> assuming the kernel driver tolerates having multiple steps for the same input (the adc is fine with that, dunno the driver)
<zmatt> or some i2c adc
<solrize> yeah
<zmatt> or use a proper external adc for the fast stuff and the integrated one for the misc inputs
<zmatt> plenty of options
<solrize> two of the slow channels are to read a touch screen, so an mcu could do that whole thing and just report coordinates
<zmatt> well the integrated adc is also a resistive touchscreen controller
<solrize> yeah i guess so, if sampling and dma are how it is usually done
<solrize> oh interesting
<solrize> maybe can ditch the touch screen altogether, and use a phone for the UI
<zmatt> all valid options
<solrize> i wonder if the whole thing can be done as a phone app, with just the adc/dac external? hmm
<zmatt> as if your phone doesn't have an audio adc and dac? :D
<solrize> yeah maybe that suffices
<solrize> oh right, need the rf stuff
<zmatt> you can bet that your phone's adc and dac are better than what the pocketbeagle or a teensy has to offer
<solrize> i'm a good linux programmer but don't know that much about hardware or phone apps
<zmatt> and definitely more processing power
<solrize> interesting
<solrize> just using the 3.5mm headphone jack (which on my phone sucks pretty bad, and which is going extinct on newer phones though)
<solrize> i guess getting a carefully chosen phone for the purpose is acceptable
<zmatt> newer phones probably still support analog audio in/out via the usb-c port (via a passive converter) ?
<zmatt> anyway, lots of ways you could implement this
<solrize> there are analog pins in usb-c? omg
<solrize> ok thanks
<solrize> i'll look into stuff some more
<zmatt> there's a weird but standardized hack to use the usb-c plug to transform analog audio yeah
<rcn-ee> solrize: usb-c alt mode's..
<solrize> yikes that poor little connector
<solrize> yeah i was looking there too
<solrize> they are going to send 240 watts of power and multi-ghz signals through it
<solrize> and also analog
<rcn-ee> scarry, i won't trust that signal. ;)
<zmatt> well, when Audio Adapter Accessory mode is used there's no digital data going over it
<solrize> ah you mean there are the two traditional signal pins, and these modes change their functions
<solrize> so no using with a hub
<solrize> ok
<zmatt> and charge-through in that mode only supports 5V 500 mA
<rcn-ee> actually in audio mode, tx/rx's get disabled... so your device only has to worry about 240 watt's thru Vbs/gnd.. so audio might be fine.. at full load..
<rcn-ee> as long as that load doesn't change...
<zmatt> 2.5 W max
<rcn-ee> ah, i see that at the bottom.. was thinking about the normal power charging..
<rcn-ee> thanks!
<zmatt> the audio accessory grounds both CC pins (which is how the phone recognizes it)
<zmatt> which prevents charger current detection and PD communication
<solrize> ok i will read this
<solrize> yeah jeez, i sort of had the idea of using the phone to power the external stuff.. i thought there was a way to do that with usb-c
<zmatt> hence no way to go above 5V 0.5A
<zmatt> sure, but not in audio accessory mode
<solrize> but 2.5w into the phone sounds like plenty, i hope, to be able to run the thing from external power
<zmatt> anyway, all this is of course only relevant if you actually want to get into making a phone app
<zmatt> which is its own set of headaches
<solrize> yeah :(. i've never done it but it's closer to my clue area than this electronic stuff
<solrize> ok well i'll think about this some more, i gotta go now before the bank closes. thanks 1e6 again
Shadyman has joined #beagle
ft has quit [Ping timeout: 260 seconds]
ft has joined #beagle
nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle