**** BEGIN LOGGING AT Tue Nov 24 02:59:57 2020 Nov 24 03:04:52 Too late...dang it. Nov 24 03:05:09 I erased the contents of the SD Card, I am setting up a new image, and starting from scratch. Boo! Nov 24 04:05:01 mattb00000ne: don't guess, just measure (with the cape not installed on any beaglebone). a simple continuity test may suffice (to confirm the absence of a short between SYS_5V and VDD_5V) though a resistance measurement may be better (to confirm they're not even connected a little bit) Nov 24 04:05:58 zmatt: I measured Nov 24 04:06:01 and check the current supply capability of the AI meets the requirements of the cape Nov 24 04:06:12 they are not connected Nov 24 04:06:23 i need to check the current needs of the campe Nov 24 04:06:25 cape Nov 24 04:07:23 like, on the BBB the power led would turn off in case of overcurrent, but I don't know if that's the case on the bbai Nov 24 04:08:00 remind me again why you're messing with the ai? Nov 24 04:08:41 hmm Nov 24 04:08:49 just for kicks and I have one Nov 24 04:08:51 holiday week Nov 24 04:08:52 power led indicates VDD_3V3 is up Nov 24 04:09:18 so that would seem to suggest the processor should probably be running Nov 24 04:09:29 so you could check the serial console Nov 24 04:09:37 cool Nov 24 04:09:48 not sure what a cape could do to cause boot failure on the AI Nov 24 04:10:19 if the cape wanted more power than the BBAI could give it would just not boot? Nov 24 04:10:24 whats the fail safe Nov 24 04:10:26 its sysboot pins aren't on the expansion headers like they are on the BBB Nov 24 04:10:54 generally speaking the pmic is responsible for monitoring that Nov 24 04:11:07 lemme see what supply is going to the cape anyway Nov 24 04:12:45 hm Nov 24 04:13:00 an always-on 5V supply... that kinda sucks Nov 24 04:14:10 why? just bad power usage Nov 24 04:16:31 risky if a cape e.g. generates its own 3.3v supply from sys_5v and drives beaglebone IOs from that... that's not really safe on the BBB either, but on the BBB the hazard would be limited to a very brief moment during power-up while on the BBAI it can persist indefinitely (if the board is connected to power but not powered on) Nov 24 04:17:47 shouldn't be a factor in this case since this cape was designed to be powered from vdd_5v of the BBB anyway (which, when the BBB is powered via the barrel jack, is also an always-on 5V supply since it directly connects to it) Nov 24 04:19:24 and if you draw too much current from sys_5v on the BBB, the PMIC will power off Nov 24 04:20:23 while on the BBAI there doesn't really seem to be any overcurrent protection, that'll be up to the USB-C supply Nov 24 04:21:18 back Nov 24 04:21:23 internet is spotty today Nov 24 04:21:36 may of missed a statemtn Nov 24 04:21:42 mattb0000ne: https://pastebin.com/c6Sywj1m **** BEGIN LOGGING AT Tue Nov 24 07:44:48 2020 **** BEGIN LOGGING AT Tue Nov 24 07:47:40 2020 Nov 24 10:35:51 Hi! On what pin I should connect LED to monitor the PocketBeagle board is ON or OFF state? The board is in the BOX and I need external LED for check it's status. Nov 24 13:14:37 the pocketbeagle has a 5V supply output (P1.24 / P2.13) and a 3.3V supply output (P1.14 / P2.23) Nov 24 13:19:47 if the forward voltage of the led (at the desired current) is substantially below 3.3V then using the 3.3V supply is more efficient, otherwise use the 5V supply. in either case use an appropriately sized series resistor (i.e. (supply voltage - led forward voltage)/(led current) ) Nov 24 13:50:34 But what if I turn off the board by command? The 3v3 pin would bee in HIGH state. I mean maby is there any pin that turns HIGH only when the board is ON. Regardless the external voltage. Nov 24 13:51:02 no, both supplies turn off when the board is powered off Nov 24 13:51:20 they are controlled by the PMIC Nov 24 13:51:49 ah. ok Nov 24 13:54:04 After I burnd one board I use BC817 for GPIO control :) Nov 24 14:01:07 the current through a gpio should be limited to a few mA Nov 24 14:02:16 (and in input mode they should not be exposed to higher voltages than the 3.3V supply, keeping in mind that that's 0V when the board is powered off) Nov 24 14:05:59 I have another question. How does the LED on LAN port works? That one wich response for data activity. I mean the algorithm. Does it blink once for some time when the byte pass-through? I want to make a LED witch is blinking the same as LAN LED. I read a datasheets on LAN controllers LEDs, but only general information is given. Nov 24 14:10:39 on the BBB you mean? I'm not sure what you mean... the ethernet link/activity leds are controlled by the ethernet phy, not by software Nov 24 14:12:12 most ethernet phys have one or more led outputs, their behaviour/pattern will vary per phy and is sometimes configurable Nov 24 14:15:39 I mean the usual led on any router's LAN/WAN port. Yes it's controlled by phy. And I dont know how. The same is with HDD LED on any PC motherboard. Especially the old ones. When wee "feel" the device through this LED. Nov 24 14:16:23 I don't understand what sort of answer you're looking for by "how" Nov 24 14:17:07 controlling the led(s) is simply part of the functionality of the phy Nov 24 14:17:23 you're pretty much asking "how does electronics work?" Nov 24 14:20:05 The algorithm. some thing like: When the byte is recieved, blink led for 10 ms. If next byte comes in 5 ms - turn off the led for 2 ms... or something like that. Nov 24 14:20:21 like I said, that will vary per led Nov 24 14:20:56 per phy Nov 24 14:20:58 sorry Nov 24 14:21:03 (distracted) Nov 24 14:23:32 Maby, but still... the principal must bee the same. And no one write the algorithm. I believe that there is some standard for that blinkings. Nov 24 14:24:50 *principle Nov 24 14:25:19 there isn't, though "blink a led" is such a trivial thing that there's not a exactly a huge solution space Nov 24 14:27:07 Its time for some reverse engineering with oscilloscope and LAN module... Nov 24 14:27:30 the main variation is what happens if the trigger repeats during the flash interval Nov 24 14:28:02 e.g. if there's a flood of activity, does the led just stay on or does it blink at a fixed interval? Nov 24 14:28:50 Exactly. It's the subject of interest. Nov 24 14:28:54 I prefer the former, many phys do the latter Nov 24 14:29:02 on some phys it's configurable Nov 24 14:29:40 I can't imagine what you could see on a scope that's of any interest Nov 24 14:30:29 If you can access the LED, or the trace that drives it, just tack an op-amp follower on there to pick off the signal. Nov 24 14:30:32 like, it's easier to see what the led does just by looking at it than using a scope Nov 24 14:30:38 first chanel connect to LED, second - to RX line. Nov 24 14:30:59 Ragnorok: why on earth would you need that? Nov 24 14:31:36 Dunno. It just seemed like Siegurd wanted to know when the LED was flashing. Nov 24 14:31:58 Why bother telling how it's done if one may just read the LED activity? Nov 24 14:32:06 Yes but when you download file at 100 Mbits/s how can you tel the timings? Nov 24 14:32:20 Siegurd: and you'll see that the led turns on when data is transmitted or received, provided it was initially idle Nov 24 14:32:33 if traffic keeps coming most phys blink the led at a fixed rate Nov 24 14:33:18 (so basically any traffic will enable the fixed blinking pattern and after some time of no traffic the led is turned off) Nov 24 14:34:10 On a Black there's a thing that drives the on-board LED. I have a front panel indicator that uses that and it flashes pretty much in sync with the back one. Nov 24 14:35:15 /sys/class/net/eth0/statistics Nov 24 14:35:22 linux allows you to configure a led as network activity indicator Nov 24 14:36:05 (in which case it is obviously software-controlled, by the kernel, unlike the integrated ethernet leds which are hardware-controlled) Nov 24 14:36:14 zmatt: its logically, bud maybe there is some dependence between bytes in RX/TX buffers and blinking period? Nov 24 14:36:37 Siegurd: I don't think I've ever seen a phy that does that Nov 24 14:39:02 ragnorok is there any information about the LED flashing algorithm? Nov 24 14:41:24 No. I didn't care about that. I cared that the front panel LED relatively accurately showed activity b/c the on-board LED is hidden. Nov 24 14:42:07 https://elixir.bootlin.com/linux/latest/source/drivers/leds/trigger/ledtrig-netdev.c is the driver Nov 24 14:43:02 based on a quick glance it's exactly what I said earlier Nov 24 14:43:16 Go go gadget open source. lol Nov 24 14:43:20 i.e. the simplest, dumbest thing you can think of Nov 24 14:43:32 like basically every phy Nov 24 14:45:19 what does phy mean? Nov 24 14:46:15 a device handling the physical layer of a protocol Nov 24 14:46:50 I typically only see it in reference to Ethernet, but that could just be me. Nov 24 14:47:14 not just ethernet, though they are the most commonly seen Nov 24 14:47:23 often a phy is integrated into a device Nov 24 14:47:33 like, the AM335x has two USB 2 phys Nov 24 14:47:47 I figured it was just me. (wink) Nov 24 14:48:26 personally I find it useful to disable all leds when possible, by writing 0 or none into some /sys/class/leds/ files Nov 24 14:48:43 it's not just you, ethernet phys are definitely the easiest way to come across the word "phy" Nov 24 14:48:58 mm302: you can configure the default led configuration via DT Nov 24 14:49:32 true, I'll look into that as some point, the default bbb led is too bright Nov 24 14:49:33 so they acquire your desired behaviour during very early boot Nov 24 14:50:17 thick black tape works too :-D Nov 24 14:50:36 Ah, there is also a PWM (led_set_brightness) Nov 24 14:51:12 if you're using a pwm-led instead of a gpio-led yeah Nov 24 14:53:02 what do you mean by pwm-led? PWM can be made by GPIO Nov 24 14:58:46 as in, whether it's using the leds-pwm or leds-gpio driver Nov 24 14:59:04 Ok, if there is a way to set any GPIO connected LED to act like network activity LED, how can I do it on PocketBeagle board for ent0 interface? Nov 24 14:59:05 pwm does not use gpio Nov 24 14:59:16 pwm functionality is separate from gpio functionality Nov 24 14:59:28 only a few pins on the BBB support pwm Nov 24 14:59:43 *eth0 Nov 24 15:00:02 the pocketbeagle has no ethernet interface Nov 24 15:01:06 it has wirtual one (USB). Nov 24 15:01:15 which is usb networking, not ethernet Nov 24 15:01:27 :P Nov 24 15:01:36 :) Nov 24 15:02:13 But it is shown in interfaces list. Same as wwan0. Nov 24 15:02:40 ? Nov 24 15:02:55 enh0 pocketbeagle Nov 24 15:03:02 there shouldn't be Nov 24 15:04:01 a wwan0 interface only makes sense if you connected an LTE modem or something like that Nov 24 15:04:35 Yes, I connect the modem Nov 24 15:06:31 anyway, setting up a gpio or pwm output as (kernel-controlled) led requires a small device tree snippet Nov 24 15:07:00 I switch between modem (wwan0) and virtual usb LAN (eth0) interfaces. Nov 24 15:07:25 usb is usb0, not eth0 Nov 24 15:07:51 oh, indeed sorry Nov 24 15:08:03 usb0 Nov 24 15:09:46 zmatt: is there a chance to find the instructions for setting up a gpio as (kernel-controlled) led? Nov 24 15:10:33 I see no reason to be pessimistic, I'm sure there's a chance Nov 24 15:13:20 ;) Nov 24 15:18:46 https://fabiobaltieri.com/2011/12/03/network-activity-led-linux/ I found that interesting :) Nov 24 15:32:10 I can make an example, but not right now Nov 24 15:35:27 Thanks, sure, take you time! Nov 25 02:10:35 whats the baud rate for beaglebone ttl line Nov 25 02:10:58 I tried the 9600 bps but I get garbage back Nov 25 02:16:36 115200 Nov 25 02:19:12 ok that may be why I got this https://pastebin.com/r82B6qXJ Nov 25 02:19:37 using a wrong baudrate will result in garbage yes Nov 25 02:31:24 is there a simple way to see what usb port you are plug into in linux Nov 25 02:31:31 for windows I could look at device manager Nov 25 02:31:38 and see which com port was active Nov 25 02:31:43 i am looking in /dev Nov 25 02:32:14 is my usb /dev/usb Nov 25 02:32:20 whatever is in that folder? Nov 25 02:38:19 check your kernel log Nov 25 02:38:42 it will mention usb devices when plugged in Nov 25 02:39:14 usb serial devices show up as /dev/ttyACM* or /dev/ttyUSB* Nov 25 02:41:08 seems to disconnect after detection Nov 25 02:41:09 https://pastebin.com/XPz5Hmhp Nov 25 02:45:44 need a better wifi router Nov 25 02:50:19 mattb000ne that might be the problem, you are using wifi <-- generally a bad idea I've found. Nov 25 02:51:02 the way the internet is wired to the house makes it challenign Nov 25 02:51:20 i was looking into moca adapters Nov 25 02:52:48 Well at least you aren't using a string, I saw someone did that for an internet connection. Nov 25 02:53:14 anyhow I have a router and cables to each device. Nov 25 02:54:47 I had to use wifi for a while but it was sadly flaky. Nov 25 02:55:40 around here a certain company has wifi routers as honey pots to capture peoples smart TV information. Nov 25 02:58:20 so the baudrate cleaned up the mess Nov 25 02:58:32 and with the cape on I do get some messages so it is trying to boot Nov 25 02:58:34 https://pastebin.com/mgseFwCE Nov 25 02:58:56 failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND Nov 25 02:59:00 does not sound good lol **** ENDING LOGGING AT Wed Nov 25 02:59:57 2020