**** BEGIN LOGGING AT Mon Feb 22 02:59:57 2021 Feb 22 03:09:47 Hello Feb 22 03:20:32 I am doing a project for college, which I am building a usb cape for beagle pocket. I have the circuitry for the usb hub figured out, I am just in doubt about how to connect to the BP Feb 22 03:21:04 it's called the pocketbeagle, not the beagle pocket Feb 22 03:21:27 some notes about which pin is what: https://pastebin.com/nJCbVsaA Feb 22 03:22:23 sorry, I mixed them up, thanks for the link Feb 22 03:23:57 so will your cape be providing power to the pocketbeagle, or are you powering everything from the pocketbeagle? (the latter might be proble Feb 22 03:24:02 *problematic Feb 22 03:26:17 I was thinking of powering everything from the pocketbeagle Feb 22 03:26:45 I guess it's possible if you're not connecting power-hungry devices Feb 22 03:28:18 I was just asking because I happen to have concrete examples sketched on how to equip a pocketbeagle with a usb host port when you're also providing power to it: https://photos.app.goo.gl/e1663vMMDnEmGZaR6 (left one is the official proper way to do it, the right one is not as nice but you can often get away with it): https://photos.app.goo.gl/e1663vMMDnEmGZaR6 Feb 22 03:28:42 powering everything from the pocketbeagle isn't really harder, I just don't already have sketches lying around for that case Feb 22 03:29:28 probably it's just going to be used for adding wifi or bluetooth via a usb module, or devices with similar power consumption Feb 22 03:29:49 wireless transmitters tend to have quite high peak power consumption Feb 22 03:32:24 anyway, if you're not powering the pocketbeagle from the cape then you're not using P1.01, and in the left schematic you'd use P1.24 (or _maybe_ P1.07) as 5V supply to the usb power switch Feb 22 03:33:58 and the right schematic you'd just ignore the P1.01 connection, it already powers usb vbus from the pocketbeagle (P1.24) Feb 22 03:34:23 ok, I will study these sketches Feb 22 03:37:44 iirc the 5V supply from the pocketbeagle (P1.24 + P2.13) can supply max 1.8A when powered via usb (assuming the usb port can actually deliver that), but it's also used to generate all other (lower-voltage) supplies, and a large chunk of that 1.8A can already be used by the pocketbeagle itself Feb 22 03:39:13 well, maybe "large" is an overstatement, but at least a decent chunk Feb 22 03:41:30 just for clarification, does this device is one of those that are power hungry? Feb 22 03:41:32 https://www.amazon.com/Bluetooth-Adapter-Wireless-External-Receiver/dp/B07YDFZWT8 Feb 22 03:42:59 you're expecting me to magically know power consumption statistics of random products found on amazon? :P Feb 22 03:43:41 my statement was about wifi transmitters in general Feb 22 03:43:42 sorry Feb 22 03:43:48 oh ok Feb 22 03:43:58 with this thing I'd be more concerned about lack of mainline linux support Feb 22 03:44:34 in general usb wifi dongles tend to be very hit-or-miss with regard to linux support Feb 22 03:45:33 note also that usb in general isn't super great on the am335x (especially performancewise), though I don't know how much of that is due to hardware and how much is due to the kernel drivers Feb 22 03:48:34 I found an actual datasheet for some random RTL8821CU-based embedded module powered from a 3.3V supply (instead of via usb) and it specifies a max current of 908 mA during transmit Feb 22 03:53:14 ok, that is very useful information Feb 22 03:53:41 thank you for your kind help Feb 22 03:54:23 found another one that specifies max *average* current during transmit to be typ 330 mA max 400 mA, again at 3.3V (may be lower when powered from 5V of course, depending on conversion efficiency) Feb 22 03:55:47 so values will vary between devices, but still those are substantial amounts of power Feb 22 03:56:39 and more annoyingly the power consumption may also fluctuate rapidly (depending a bit on how much caps they embedded to smooth things out) Feb 22 04:02:22 in the end, will look something like this Feb 22 04:02:23 https://image.easyeda.com/histories/eeabf023006d4692bef92f269817b48a.png Feb 22 04:02:49 but with only 2 usb ports Feb 22 04:08:21 that looks like a terrible way to make a usb hub Feb 22 04:09:14 (and is definitely not usb spec compliant) Feb 22 04:10:15 really? could you tell me more about why its terrible? Feb 22 04:13:44 it's lacking downstream port power switching, overcurrent protection, and a whole lot of filtering Feb 22 04:15:55 I'm checking to see if I can maybe find a good reference, though I'm not sure where to search Feb 22 04:16:11 mind you, your creation will be in good company, lots of usb devices on the market are crap ;) Feb 22 04:16:43 maybe this one is better Feb 22 04:16:45 https://image.easyeda.com/components/061f01320c38401fa7ca10df4f0e1b8c.png Feb 22 04:18:51 it looks worse Feb 22 04:19:26 ok, maybe I am not good judge usb hubs Feb 22 04:19:30 also, it has wires connecting VBUS (mislabeled "VCC") to ground Feb 22 04:20:07 this whole project is for me to learn more about circuitry and be able to tell what it does, what is lacking, how to improve Feb 22 04:20:44 sure, if you're not making a commercial product it doesn't necessarily matter if it's not great Feb 22 04:20:49 to be like you, take a look say that it needs more downstream port power switching Feb 22 04:20:57 or something like that Feb 22 04:21:09 normally you'd want downstream ports to be protected yes Feb 22 04:22:01 the usb spec also *requires* per-port overcurrent protection on self-powered hubs (if you're powering the hub from the pocketbeagle's 5V supply it's effectively a self-powered hub) Feb 22 04:23:04 if you use a hub chip from a reputable company, they should also provide a fair bit of guidelines in their datasheet and/or application notes Feb 22 04:25:03 ok, I will add this in my notes, to look for a better hub chip Feb 22 04:29:41 for example, here's design guidelines given by cypress for their HX2VL hubs: https://www.cypress.com/file/122726/download Feb 22 04:29:59 TI has hub chips too and is usually also quite good on documentation Feb 22 04:33:01 and some example schematic: https://www.cypress.com/file/117531/download Feb 22 04:40:02 Looking at this, I am embarassed by sending the last two Feb 22 04:42:55 no worries, if you buy some random dirt-cheap chinese usb 2 hub I wouldn't be surprised if you'd find something closer to what you were showing than to the cypress schematic :P Feb 22 04:45:41 in the end it's up to you how much you care about making something "right" versus making something that usually seems to work Feb 22 04:46:22 obviously things like overcurrent protection have value ;P Feb 22 04:46:36 like not setting stuff on fire Feb 22 04:47:28 yes over current protection isn't just advisable, you can and WILL blow things out if you don't enforce it. Feb 22 04:48:05 just don't ever connect any defective or incompatible devices and you'll be fine :D Feb 22 04:48:20 I've had 2 USB hub power supplies go "boom" because peripherals asked for say 500ma but drew 800ma. Feb 22 04:48:58 life is more exciting without protection circuits Feb 22 04:49:46 imagine only drawing what you're allowed to :D *glances in the beaglebone's direction* Feb 22 04:50:16 turning usb into a standard way of powering devices has muddied things Feb 22 04:51:00 yeah ... some of the stupid things I've seen... for example fans hand warmers foot warmers and even more questionable USB powered devices. Feb 22 04:52:13 hehe yep Feb 22 04:52:58 If I may bother you some more, in the last schematic, what is DLP11S ? Feb 22 04:53:43 trying to figure this schematic may take some time for a newbie like me Feb 22 04:53:59 it's a common mode choke Feb 22 04:54:07 (you could have found that by googling DLP11S) Feb 22 04:54:48 it's a kind of filter Feb 22 04:55:01 sorry, asking when you can google is annoying Feb 22 04:56:00 https://en.wikipedia.org/wiki/Choke_(electronics)#Common-mode_choke Feb 22 04:57:16 sometimes you see ferrite beads on a cable like this: https://en.wikipedia.org/wiki/File:Ferrite_bead_no_shell.jpg those serve a similar purpose Feb 22 05:00:02 those references probably won't clarify its purpose for you hugely, but unfortunately EMI is a really complicated topic (and I'm no expert on it either) Feb 22 05:03:19 GRS26, it is advisable to filter any input signal going into the hub to prevent noise from interfering with it's operation. Feb 22 05:04:16 I also generally put an inductor on the power supply line to IC's that have to interface to the outside world. Feb 22 05:04:45 but you need to calculate what inductance you use carefully or you could get weird results. Feb 22 05:05:07 I was about to say, adding inductance can also ruin a perfectly good power supply Feb 22 05:06:30 Ok, I will keep that in mind Feb 22 05:06:58 I will follow the schematic and guidelines you sent zmatt, it is very well documented Feb 22 05:07:32 note that this is just a random hub chip google found for me, I have no personal experience with it Feb 22 05:07:56 (or any other hub chip for that matter) Feb 22 05:09:41 well, it does look a lot better than what I already had Feb 22 05:09:48 at least, the circuitry part Feb 22 05:10:51 I was only using that hub chip because I was trying to reverse engineer what this guy did Feb 22 05:10:52 https://www.youtube.com/watch?v=ueKghTIqfxQ Feb 22 05:12:54 uhh, that video doesn't involve any hub Feb 22 05:13:23 sorry Feb 22 05:13:25 wrong video Feb 22 05:14:15 wrong link Feb 22 05:14:16 https://www.tindie.com/products/microwavemont/24-port-usb-20-hub-cape-for-pocketbeagle/ Feb 22 05:15:20 that usb host port cape in the first video also looks wrong btw ;P Feb 22 05:16:19 basically it's the second (simpler) of my two schematics except he's using P1.07 to power the downstream usb port, which I would strongly recommend against Feb 22 05:19:02 really there's no excuse for devices like this to not have their schematic on the website Feb 22 05:19:19 like the vast majority of beaglebone capes Feb 22 05:20:19 Yeah, I have been trying to take photos of the videos of both sides, and look at the images he gives, to try to figure what how everything is connected Feb 22 05:21:00 that seems like an excessive amount of work to try to reverse-engineer a crappy usb hub Feb 22 05:22:12 thats why I am doing this project, I didn't even know it was a crappy usb hub Feb 22 05:24:14 my course didn't focus a lot on studying boards and actual schematics Feb 22 05:25:13 well at least the photos are crappy and there's no schematic so it's hard to tell how crappy the usb hub is... but I meant more, it's a usb hub, that's a really ubiquitous thing, no need to spend a lot of time reverse-engineering this particular one Feb 22 05:25:39 so I am trying to fix these flaws, but it seems I understimated how much I didn't know about circuits haha Feb 22 05:26:22 also be sure to pay close attention to pcb layout guidelines Feb 22 05:26:44 like those two schematics I sent, I spent lots of hours to starting to understand them Feb 22 05:27:12 probably I will spent weeks trying to understand this one https://www.cypress.com/file/117531/download Feb 22 05:29:02 TI's USB 2 design/layout guidelines: https://e2echina.ti.com/cfs-file/__key/telligent-evolution-components-attachments/13-106-00-00-00-00-33-10/USB-2.0-Board-Design-and-Layout-Guidelines.pdf ... not sure why this appnote doesn't exist anyomre, probably replaced by some newer high-speed interface guidelines appnote Feb 22 05:31:10 yeah, https://www.ti.com/lit/pdf/spraar7 is their newer appnote covering usb and other high-speed interfaces Feb 22 05:34:46 anyway, I'm off Feb 22 05:35:33 thanks for the help Feb 22 07:15:18 oh I just love how they start the appnote with the most elusive of problems, pcb weave pattern. Feb 22 07:28:11 all in all the appnote is full of good advice, but it's a mere collection of guidelines. For example, stitching vias: you don't need them if you don't change the reference plane of a signal. Or stubs formed by vias. Yes, the effect is there, but for USB2, how much of a signal degradation will you effectively get? I bet you don't see the effect in the eye diagram... Feb 22 07:29:08 Or stitching capacitors - yes, you can try "healing" a break of the reference plane, but for very high signalling speeds that won't work. Feb 22 11:39:54 GenTooMan: I am on hunt for making the loadCape work on the AI. Wish me luck! Feb 22 11:49:07 Does the LoadCape already work on the AI? Feb 22 11:55:59 Well, if it does not or if it does, the build was successful but w/ error. Feb 22 11:56:11 Dang! Feb 22 11:58:22 Too bad anyway. My uEnv.txt file is empty. Blah. Feb 22 11:58:36 Still fun. Feb 22 11:58:41 No issue here. Feb 22 12:25:09 Oh. Feb 22 12:25:23 Dang. I ruined my entire image to make something work that already works. Blah. Feb 22 13:33:28 * GenTooMan listens to the mind explosion. Feb 22 13:40:04 * set_ is thinking to wait longer next time. Feb 22 13:41:09 remember the motto is "measure more than once cut only once" Feb 22 13:42:38 Right. Cut twice, measure once. Feb 22 13:42:41 Got it. Feb 22 13:43:45 GenTooMan: I am waiting on a reply from some 'very important dictators.' They will guide me on the usage of my motor to the point where I can have peace of mind if I do not have a back up power supply. Feb 22 13:44:03 Usually, the motors have a back up supply in case things go awkward. Feb 22 13:45:07 Do not fret, I will make a post to show and tell for you, society, and my own 'sane-mind excursions.' Feb 22 13:45:24 This one is going to be good! Feb 22 13:46:04 I know everyone thinks I am a bat gone loopy but I have ideas too. Feb 22 13:50:13 I read the instructions. It is basically a failsafe for the motor if it loses power via the mains power. Feb 22 13:50:37 But, either way, it is mains. So, I am a bit fooled by it. Feb 22 13:52:17 set_ you may be giving people too much credit by adding the word think but OK :D Feb 22 13:54:42 Yea well sir, I just want to make sure I can handle what is supposed to happen versus what actually happens. 'play it safe,' was the idea. Feb 22 13:55:22 I know they will most likely sell something to me but the instructions stated it was not mandatory. Feb 22 13:55:33 Precautionary measures...basically. Feb 22 13:58:32 For instance, if I was in the middle of a print or a cut and the power adapter cut out, the back up supply would keep the signals updated until I could solve the issue. Feb 22 14:02:16 Well, I am playing it safe this time w/ the BBAI. I got the LoadCape attached, a fan movin' faster than it ever did alone, and the IoT/TIDL image from bbb.io/latest-images. Feb 22 14:03:31 So, update/upgrade, look through /boot/uEnv.txt to see if it exists, and then add the overlay from +lorforlinux[m] and the rest of you guys. Feb 22 14:05:02 Actually, GenTooMan, I cannot wait to rummage through those .dts files for the BBORG_LOAD-00A2 to sift through it. Feb 22 14:31:44 Oh. Did someone cut out the uEnv.txt file entry sections for uboot-overlays recently? Feb 22 14:45:03 I understand now. It just works. Sorry for creating issues in here. Feb 22 14:46:00 bborg, is that short for beagle-borg? Feb 22 14:56:19 Oh. Feb 22 14:56:21 No. Feb 22 14:56:29 It is short for bb org I think. Feb 22 14:56:38 I am guessing. I am not afflicted. Feb 22 14:57:14 Hey. mru: Sir, um, is character devices used in the new images for TIDL IoT on the BBAI? Feb 22 14:58:12 well, this is definitely a beagleborg: https://photos.app.goo.gl/ZWdwStjPRK7wsebA9 Feb 22 15:00:02 Did you plug it in? Feb 22 15:09:56 Otay. I am figuring it out. This is nifty. Feb 22 15:12:17 Dang...set backs. Feb 22 15:12:27 Sysfs it is! Feb 22 15:28:09 Oh! Feb 22 15:29:23 char dev back in da' hizzy. Hey, um, how do you make gpiomon w/ libgpiod wait for say, three seconds to see output? Feb 22 15:31:20 gpioset --mode=wait gpiochip0 8=1 Feb 22 20:04:49 How can I use the GHI Capes on the AI if there is not a DC barrel jack on the AI? Do I need some extra components or a new circuit? Feb 22 20:05:26 Oh! The power distribution board from GHI? Feb 22 20:06:20 Or...do I plug in the DC Barrel jack to the vdd_5v pins on the AI? Feb 22 20:06:42 w/ GND of course. Feb 22 20:12:27 I will try. Feb 22 21:19:07 I thought I could trick the LoadCape into thinking it was being used w/ power on via the dedicated power supply from the 5v on the PowerCape. Feb 22 21:19:08 Blah. Feb 22 21:19:23 .dts and .dtbo! Feb 22 21:19:26 Argh. Feb 22 21:27:23 Does the LoadCape need to have the GND, PWR, and Sink(n) wired to work or does the LED pop on w/ some source or by way of char dev w/ libgpiod? I mean, can it work w/out the .dtbo compiled for the LoadCape? Feb 22 21:30:14 So, get this. I would need to write/type a .dts file, compile it, and then apply it. Okay. Then, would I need to have access to uboot_overlays? Yes but my uEnv.txt file is emptied and bare. So, I guess I could just make a single-use .dtb w/out the object suffix. Feb 22 21:30:42 Man! Feb 22 21:41:39 I never stacked two capes on the AI before today and I am neverous. Feb 22 21:42:16 so, nervous that I spell it as 'neverous.' Feb 22 22:00:54 Got it. Single .dtb files. Feb 22 22:01:01 Okay. I am on it! Feb 23 01:12:44 I jumped into the Machinekit stuff, again, instead of finishing my .dtb compilation. Feel for a brother! Feb 23 01:13:50 scatter brain over here. Sheesh. GenTooMan: Have you been messing w/ MachineKit at all? **** ENDING LOGGING AT Tue Feb 23 03:00:05 2021