thinkfat_ has quit [Ping timeout: 260 seconds]
thinkfat has joined #beagle
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #beagle
vagrantc has quit [Quit: leaving]
Guest85 has joined #beagle
Guest85 has quit [Quit: Client closed]
j0rd has quit [*.net *.split]
ikarso has joined #beagle
Shadyman has joined #beagle
insurgent has quit [Read error: Connection reset by peer]
insurgent has joined #beagle
xet7 has joined #beagle
xet7 has quit [Quit: Leaving]
xet7 has joined #beagle
Shadyman has quit [Remote host closed the connection]
xet7 has quit [Remote host closed the connection]
set_ has quit [Remote host closed the connection]
set_ has joined #beagle
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #beagle
<set_> Okay. I am done acting like this mechanical decline in electronics are real. I am building this mower! I have been trying for years to find time and I am "ready."
<set_> If that dude died or not, I think it is on me! I should do it for me and not quit b/c he deceased. Aw! New life!
konsgn has joined #beagle
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
fakuivan has quit [Read error: Connection reset by peer]
fakuivan has joined #beagle
vagrantc has joined #beagle
Guest62 has joined #beagle
Guest62 has quit [Client Quit]
mattb0ne has joined #beagle
lucascastro has joined #beagle
<mattb0ne> question
<mattb0ne> if I am using the ADC on the beagle to read a pressure sensor
<mattb0ne> I have been using the 3.3V on my low side level shifter
<mattb0ne> will that burnout my board
<mattb0ne> can I just step down from 3.3V to 1.8V with a resistor to power my low side to prevent that
<zmatt> exposing the analog inputs to 3.3V will destroy the AM335x
<zmatt> I'm a bit confused though... level shifter? that term generally refers to digital signals so I'm a bit puzzled what you mean here
<konsgn> pocketbeagle has a built in resistor divider meant for measuring 3v3 levels
<zmatt> you can use a resistor divider to scale down analog signals yes (if whatever you're measuring tolerates the resulting load)
<konsgn> also what zmatt said, a resistive divider is all that is necessary to lower the voltage range.
<zmatt> what pressure sensor is this
<zmatt> ?
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt> mattb0ne?
set_ has quit [Ping timeout: 256 seconds]
waldo323_ has joined #beagle
waldo323 has quit [*.net *.split]
akaWolf has quit [*.net *.split]
jfsimon1981_c has quit [*.net *.split]
zmatt has quit [*.net *.split]
russ has quit [*.net *.split]
noahm has quit [*.net *.split]
zmatt_ has joined #beagle
zmatt_ is now known as zmatt
j0rd has joined #beagle
xet7 has joined #beagle
akaWolf has joined #beagle
jfsimon1981_c has joined #beagle
russ has joined #beagle
noahm has joined #beagle
Guest93 has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
<Guest93> Really frustrated with the whole beagle line, I was a fan of the Angstrom images and even early Debian images, but I have burned up several Beaglebone Blacks due to the design of the sensor reading pins, the constant, constant, constant overlay changes, and now, the images on the pocketbeagle that WILL NOT come up as a storage device or USB device
<Guest93> on either Linux or Windows 10 and WILL NOT therefore serve DHCP and I CANNOT therefore connect in any way. This is using multiple images, multiple beaglebones and multiple cables. Yes, I have installed the udev rules. I have tried to install Windows 10 drivers, but oops, NOT SIGNED.
<Guest93> Can anyone point me to why these devices won't get recognized as a USB device?
<Guest93> I get the "heartbeat" leds that lead me to believe the devices are booting properly.
<zmatt> that's really odd, what image are you using?
<Guest93> AM3358 Debian 10.3 2020-04-06 4GB SD IoT
<zmatt> "the design of the sensor reading pins" ? are you talking about the expansion header I/O ? because they're simply the raw processor pins... and yeah those do need to be treated with care
<zmatt> hmm odd, that image should definitely work just fine
<zmatt> it's not showing up as network interface on linux?
<zmatt> what does the kernel log say?
<Guest93> It's not even showing up in /dev as a device.
<rcn-ee> Guest93: since you were playing with Angstrom and Debian... I'm worried the ancient Angstrom u-boot is stuck in eMMC... Do you have a usb-serial adapter to go thru j1 to see what's actually booting?
<zmatt> network devices don't show up in /dev
<zmatt> rcn-ee: well he's talking about pocketbeagle
<zmatt> Guest93: but, I do think that image should also show up as mass storage device indeed... so what does the kernel log say?
<zmatt> Guest93: no udev rules need to be installed btw, nor any drivers installed
<zmatt> that's all things of the past
<Guest93> I'm looking at the kern.log
<Guest93> Hang on
<zmatt> on a modern systemd-based linux system you can get the kernel log using "journalctl -k" (add "-f" to follow it in real-time and/or "-n 100" to show the last 100 lines or "--since=-5min" to show the last 5 minutes)
<zmatt> (it may or may not also still get written to some file, that will depend on distro, whether or not something like rsyslogd is installed, and how it's configured)
<Guest93> I don't have systemd on this machine.
<zmatt> hmm, ok
<rcn-ee> `dmesg | grep cdc` should atleast show something.. as it's cdc gadget..
<zmatt> dmesg works to dump the kernel log too indeed (although it may require root privileges depending on the distro)
Guest93 has quit [Quit: Client closed]
Guest93 has joined #beagle
<Guest93> I don't see anything regarding cdc,
<Guest93> I see it getting recognized as a new usb device.
<zmatt> can you share (using e.g. what the kernel logs when it detects the pocketbeagle?
<Guest93> Kernal log isn't seeing it, unfortunately.
<zmatt> you just said it detects a new usb device
<rcn-ee> Wonder's... are the modules loaded on your linux build?
<Guest93> That was in dmesg | grep usb, but it appears I was wrong.
<Guest93> rcn-ee that is a good question.
<Guest93> What modules should I check?
<zmatt> so nothing shows up at all in the kernel log in response to plugging in the pocketbeagle (after waiting for it to boot)
<zmatt> if it's not detected as device then drivers are not yet relevant
<Guest93> zmatt, correct.
<zmatt> you sure this usb cable is working?
<Guest93> I've tried multiple cables and now I'm trying a different pocketbeagle.
<zmatt> you can use dmesg -w to monitor the kernel log in real time btw
<Guest93> Yup.
<Guest93> Monitoring that too.
<rcn-ee> with: bone-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz you should see:
<zmatt> if pocketbeagle booted from a fresh "AM3358 Debian 10.3 2020-04-06 4GB SD IoT" image fails to show up as usb device at all, the only logical possibilities are a bad cable or some kind of hardware problem
<rcn-ee> do you see "cdc_acm" loaded under lsmod?
<zmatt> rcn-ee: I mean, if the pc isn't even reporting "new usb device found" then it's also not going to load a driver
<Guest93> Aha, I do not see cdc_acm
<zmatt> Guest93: like I said, if it's not reporting the usb device as detected (the first six lines of ) then there's no reason for any drivers to be loaded yet either
<Guest93> So I've tried three cables combinations with three pocket beagles and two microsd cards.
<zmatt> really bizarre
<rcn-ee> i might have missed this... Did you flash it with ?
<Guest93> Yes, balena etcher
<Guest93> On Windows 10
<rcn-ee> Is your linux box native or virtual machine?
<rcn-ee> ps.. you can test the "PocketBeagle" by removing the microSD and pluggin in over usb...
<Guest93> The led lights go through the boot process and finally go to a blinking heartbeat on usr0
<rcn-ee> The "usb" boot rom will show:
<Guest93> It's a native laptop
<zmatt> and the heartbeat means it probably booted ok
<zmatt> (or at least in the process thereof)
<zmatt> so that should exclude a misflashed sd card
<rcn-ee> So without a microsd, you can test the cable+pocketbeagle with TI's boot rom..
<zmatt> indeed, good idea
<Guest93> Ok. Will try that. THANKS!
<Guest93> The power led comes on and stays on and no recognition by the kern or dmesg
<rcn-ee> So on the PocketBeagle that's normal... grab another un-tried usb cable..
<zmatt> the power led is normal, the no recognition isn't
<rcn-ee> (no microsd) usb power -> just PWR led.. ;)
<zmatt> yeah
<zmatt> but yeah, if that doesn't show up either the cable is bad or the usb port on either side is defective
<rcn-ee> i'd also personally try a different usb port on your PC.. Some usb3's can be buggy... find a usb2...
<Guest93> Yup I'm trying a different usb port now.
<zmatt> still weird to get no log message at all though, not even an error
<Guest93> These are the short USB cables supplied with it.
<rcn-ee> Personally, i also have one of these... way to many usb cables. ;)
<zmatt> Guest93: those *should* be fine...
<Guest93> Is there any other way to connect to one of these if I assume it has booted?
<Guest93> Also, It's not coming up on a separate Windows 10 laptop.
<rcn-ee> Classic serial console is enabled on uart (rx/tx/gnd) don't remember which one... 115200/8/n/1
<rcn-ee> i think U0...
<Guest93> I have a 3.3 volt ftdi basic.
<zmatt> serial console, e.g. using a 3.3V usb-serial converter... but the pocketbeagle's serial console does not have an isolation buffer to protect it when the pocketbeagle is powered down so do be careful to only connect it while the pocketbeagle is powered on
<rcn-ee> perfect... 3.3v must be used. ;)
<Guest93> no isolation buffer = sad trombone....
<rcn-ee> No isolation.... so once you wire rx/tx/gnd.... DO NOT send any characters "space"...etc thru the termimal, untill you've powered the board!
<zmatt> but, we know it's not a problem with the image (since even bootrom doesn't show up), and using the serial console isn't exactly a great alternative in the long term
<zmatt> rcn-ee: no, do not connect at all
<zmatt> serial is idle high
<Guest93> "You can't get there from here"
<zmatt> whether you send data or not is irrelevant
<rcn-ee> That's how i blew a bunch of BeagleBone Blue's... Plug in serial... hit space key... then plugged in main power... smoke..
<Guest93> I can't remember how I blew those beaglebone blacks,
<Guest93> I think connecting sensors using the wrong signal voltage.
<zmatt> rcn-ee: there's no reason for the space key to be a relevant part in that... if there's no isolation buffer then connect a usb-serial converter to an unpowered am335x is sufficient to start frying it
<rcn-ee> Black's are a little harder... as main usart is protcted... the rest anything over 3.3v or over 1.8 on adc... when no power...
<zmatt> I mean, most ICs do not appreciate voltages significantly above the relevant supply voltage, whatever it may be.... unless the IC has been specifically designed to tolerate it
<Guest93> Ok, so I can attach the ftdi basic to the pocketbeagle, but DO NOT plug the usb into the ftdi basic if the pocketbeagle isn't powered up and fully booted?
<zmatt> (such as the isolation buffer used to protect the BeagleBone Black's serial console)
<zmatt> Guest93: ehh I don't know if that's safe actually
<zmatt> I doubt it
<zmatt> you'll have the reverse problem: the pocketbeagle's txd would be driving unpowered I/O in the ftdi
<zmatt> it'll depend on how the FTDI's pins behave electrically when unpowered, but it's quite possible it would lead to excessive current
<rcn-ee> Doesn't the FTDI sense the voltage... also connect the vcc reference to v3.3.
<zmatt> rcn-ee: only if someone added a level shifter to it, otherwise definitely not
<Guest93> This is the venerable(?) sparkfun 3.3v ftdi basic
<zmatt> Guest93: honestly I wouldn't mess with the serial console, especially since it won't help you fix your immediate problem
<Guest93> Ok.
<Guest93> I'm going to heed that advice.
<Guest93> Blowing boards is expensive.
<zmatt> yeah, and we know it's not a software issue since bootrom also doesn't show up (when you connect it without sd card)
<Guest93> Ok, now this is interesting.
<zmatt> hmm?
<Guest93> I plugged a mikroe wifi ble click in and rebooted it,
<zmatt> this is pure coincidence and unrelated
<Guest93> Now I see that, which I'm taking to mean that the Mikroe is getting rejected.
<zmatt> charon is a VPN thing on your laptop
<zmatt> which apparently tried to overwrite your /etc/resolv.conf but wasn't permitted to do so
<Guest93> Yeah, I have an ipsec running.
<zmatt> so this has nothing to do with the pocketbeagle
<Guest93> Lol.
<Guest93> I have been wondering why I couldn't get remote dns to resolve.
<Guest93> I should look at dmesg more often.
<zmatt> apparently because your system's apparmor config is wrong
<Guest93> Typical.
<Guest93> So, this is probably a hardware issue? What should I see on a Windows 10 laptop?
<Guest93> None of them are showing as a USB network device or as a USB storage device.
<rcn-ee> On Windows 10... "My Computer" should show a USB Flash drive labeled as BeagleBone..
<rcn-ee> that's the easiest to find.. the rest all show up only in Device Manager..
<Guest93> Ok. I'm not seeing that either.
<zmatt> as a last act of desperation you could try the pocketbeagle without sd card but I think Windows 10 won't recognize it as network interface due to Microsoft periodically making random changes to how Windows recognizes USB devices (and bootrom, being fixed in silicon, obviously can't be updated to meet microsoft's whims)... but it should still be detected as (unrecognized) usb device, with the usual ...
<zmatt> sound windows makes for a new device
lucascastro has quit [Remote host closed the connection]
<zmatt> I think anyway, I don't use windows myself
<zmatt> the next logical possibility is that your hardware, or possibly the entire building, is haunted by ghosts
<Guest93> I probably am not drinking enough. Or maybe too much.
Guest93 has quit [Quit: Client closed]
lucascastro has joined #beagle
<zmatt> maybe there's more than one problem going on, dunno... recently I spent hours debugging an issue with one of our customers that turned out to be four different issues in different components (only one of which ours) ... which made it quite a puzzle
Guest93 has joined #beagle
<mattb0ne> sorry i do not get alerts in wsl
<mattb0ne> readin the chat now
<Guest93> Thank you zmatt and rcn-ee
buckket has quit [Read error: Connection reset by peer]
<Guest93> I'm going to assume this is some hardware, cable or physical problem and work from there.
<zmatt> or ghosts
<zmatt> ;)
<Guest93> Could be ghosts
<mattb0ne> ok good thing I asked so I need a resistor divideder
<zmatt> Guest93: yeah sorry, I can't really make sense of it
<zmatt> mattb0ne: well the main question is what you're doing exactly, and what sensor is this?
<zmatt> like, what you said about a level shifter didn't make sense in context
<Guest93> Does the microusb connector have any pin outs on the pocketbeagle?
<zmatt> Guest93: other than the microusb connector you mean? no
buckket has joined #beagle
<Guest93> I was thinking maybe there is an issue on the microusb pins.
<Guest93> Is there an alternate way to power this?
<zmatt> power it? sure, but it didn't sound like you were having issues powering the pocketbeagle
<Guest93> I'm just spitballing and wondering if powering it and reading over the microUSB may be the issue.
<Guest93> I don't know why it would be, but just desperate.
<zmatt> that doesn't really make any sense
<Guest93> None of this makes sense.....
<zmatt> it may be interesting to measure the voltage on the D+ line to see if it gets pulled up, but from the photo it doesn't look like it's easily accessible
<zmatt> I guess *maybe* it may be possible to get some information from the kernel log on the pocketbeagle via the serial console? but I'm not even sure what I'd be looking for
<rcn-ee> it 'might' show "bad cable error...' ;)
<zmatt> there are easier ways to diagnose a cable though, like trying a different one or trying that cable with another usb device
<rcn-ee> exactly
<rcn-ee> my eye's suck, but one could look at the 5 solder joints... to see if any of them look like a ball or weird..
<rcn-ee> but more then one? randomly less maybe one... but more in the same user..
<zmatt> mattb0ne?
mattb0ne has quit [Ping timeout: 256 seconds]
mattb0ne has joined #beagle
<mattb0ne> zmatt: this is the sensor I am using now but I am going to switch when I get the rest of the set up working
<mattb0ne> its really crappy but I am looking to stream readings from this into the ADC on the beagle
<konsgn> isnt that 5v?
<mattb0ne> yeah i have level shift
<zmatt> a level shifter is not useful for analog signals
<zmatt> you can probably just use a voltage divider to scale its output from 0-5V down to 0-1.8V
<zmatt> although it doesn't specify what its output impedance is, which is kinda important to know
<zmatt> reviews look pretty bad
<zmatt> or at least, very inconsistent
pachenkov has joined #beagle
pachenkov has quit [Client Quit]
lucascastro has quit [Remote host closed the connection]
<mattb0ne> yeah it is horrible
<mattb0ne> just cheap
<mattb0ne> need to get the rest of the stuff working than spring for a better sensor
<mattb0ne> can I buy a mdoule that will do the voltage division
<konsgn> 2 resistors will do that
<ds2> or use an op-amp and worry less about matching
mattb0ne has quit [Remote host closed the connection]
mattb0ne has joined #beagle
<zmatt> the opamp solution also protects against my second worry: if this sensor is powered from 5V then during power-on it'll end up outputting its signal *before* the 1.8V supplies of the beaglebone are powered up
vvn has quit [Quit: WeeChat 3.5]
<ds2> though if you are more a digital person, a MSP430 infront might be better (there are op-amp enabled ones and they seemto behave a little better then raw op-amps)
vvn has joined #beagle
<zmatt> in practice, a resistor divider with fairly large resistor values would probably suffice
mattb0ne has quit [Ping timeout: 256 seconds]
<zmatt> (and maybe a capacitor if noise is a problem)
<ds2> for a pure resistor divider,just watchout as the values may not be a direct scale
<ds2> i.e. current coming from the ADC, loading, etc
<zmatt> ADC leakage is pretty negligible iirc
<ds2> isn't there a noticable current from the SH caps?
<zmatt> I mean, any such current will be very brief, it's only 5.5 pF
<zmatt> that's why the sample-time should be configured sufficiently high
<ds2> yes, but that would require understanding it enough to pick a setting
konsgn has quit [Quit: Leaving]
Guest93 has quit [Ping timeout: 250 seconds]
zjason` has joined #beagle
zjason has quit [Ping timeout: 272 seconds]
XoUoX has joined #beagle
set_ has joined #beagle
nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle