**** BEGIN LOGGING AT Fri Apr 19 02:59:57 2019 Apr 19 04:20:58 Hi ,I am able to connect my BeagleBone Black wireless to my WIFI at home using connmanctl , because I have the router IP address. Apr 19 04:22:25 I have 2 questions, first, can I connect my beaglebone to my Phone's internet if I turn the hotspot on ? second, I don't know how to find the Router IP address for the University Internet is there a way to do that? or other way to connect to it Apr 19 14:16:55 m Apr 19 16:50:03 I just have received Comms cape. I plugged it in, but it seems I need to do something more to enable it. As the first thing I can see is that BBB ground pins are not ground anymore: they show 360 Ohm between them and the real ground. What do I need to do? Apr 19 17:02:04 ehh what? Apr 19 17:02:26 dreamhiker: there's only one "ground" on the BBB Apr 19 17:03:30 and all ground terminals are solidly connected together via the ground plane Apr 19 17:05:04 But multiple grounded pins, Like P9.1, P9.2 Apr 19 17:06:48 yeah, and like I said those are all solidly connected together, so if you're measuring a non-negligible resistance between them then you're probably just making poor contact with something or otherwise messed up the measurement Apr 19 17:08:17 btw beware that the rs485 transceiver on the comms cape won't work if the beaglebone is powered via usb (due to a design mistake in the cape) Apr 19 17:10:34 the comms cape has no overlay, so you just need to configure the appropriate pins with config-pin. I don't know if there's any documentation for it, but it's two-page schematic is simple enough to understand Apr 19 17:12:55 I do not have an external power supply and I use usb to power BBB. Is it OK? For now I just need to enable CAN communication. Apr 19 17:13:39 if you only need CAN then it should be fine yes Apr 19 17:15:27 Now, as far as "ground pin resistance", it is 360 ohm. But when I shutdown BBB it becomes 20 ohm. And more importantly, even the simplest GPIO to set the pin does not work anymore Apr 19 17:15:45 360 ohm between what and what? Apr 19 17:16:04 also doing a resistance measurement on a live circuit is a recipe for failure Apr 19 17:16:42 360 ohm between P9.11 and real ground Apr 19 17:16:53 since a resistance measurement is done by injecting some current and measuring the voltage between the terminals Apr 19 17:17:12 ?? P9.11 isn't a ground pin Apr 19 17:18:01 My mistake! P9.1 i meant Apr 19 17:18:10 what do you mean by "real ground" ? Apr 19 17:18:53 P9.1 *is* real ground Apr 19 17:18:58 for the BBB Apr 19 17:19:15 Ground wire of 110 V Apr 19 17:19:38 why would you expect it to be connected to that at all? Apr 19 17:20:38 I mean, I guess it probably is, via the usb ground to your computer, and then via your computer's power supply to protective earth Apr 19 17:21:01 20 ohm sounds plausible enough to me for that rather long path Apr 19 17:21:29 the 360 ohm is a nonsense value, the result of trying to perform a resistance measurement on a live circuit Apr 19 17:23:16 protective earth is really only relevant to mains-powered equipment Apr 19 17:23:19 My electric knowledge is limited, but we have a few device and boards. My understanding is that there is a common ground (otherwise nothing would work). This is the same ground us the ground wire of 110V power line. Am I correct? Apr 19 17:23:27 you are not Apr 19 17:25:39 the protective earth wire of your mains power is for the metallic enclosures of mains-powered equipment, to ensure that if mains power somehow accidently ends up connected to any part a human can touch, a short-circuit to protective earth is created and a fuse will blow, rather than creating an opportunity for a human to get electrocuted Apr 19 17:25:59 that's the sole purpose of this wire Apr 19 17:26:25 any connection of that to the ground of low-voltage equipment is an accidental side-effect, and often actually undesirable Apr 19 17:28:32 interfaces between devices do not necessarily require a shared ground, and when it does a ground wire is part of the interface Apr 19 17:33:25 but in general, if you're creating a setup out of multiple boards, it's a good idea to ensure their grounds are properly interconnected Apr 19 17:33:38 Thanks! Apr 19 17:34:32 if there's an interconnection to protective earth, preferably ensure there's only one Apr 19 17:36:41 or if that is too restrictive, at least avoid creating a large ground-loop, e.g. by making sure all mains-powered equipment involved is plugged into the same outlet (via a power strip) Apr 19 17:43:14 Thank you for your explanations! more importantly, if i understand you correctly, I do not need to do anything to enable the cape. Is this correct? Apr 19 17:43:49 that depends on what you mean by "enable" Apr 19 17:44:39 but like I said earlier 19:10 < zmatt> the comms cape has no overlay, so you just need to configure the appropriate pins with config-pin. I don't know if there's any documentation for it, but it's two-page schematic is simple enough to understand Apr 19 17:44:56 if an overlay is created for it, then that step will no longer be necessary Apr 19 17:45:18 Enabling here means to do something that the cape is powered one. Apr 19 17:45:24 powered on .. Apr 19 17:46:01 it is powered directly from the beaglebone's 3.3v supply Apr 19 17:46:10 (except for the rs485 transceiver) Apr 19 17:46:25 Yes Apr 19 18:32:57 zmatt: sorry still the things do not work as expected. I have a simple test, where I connect P9.12 (as out) to P9.11 (as in). Apr 19 18:33:07 I am sending commands: Apr 19 18:33:28 echo 1 > gpio60/value Apr 19 18:33:40 cat gpio30/value Apr 19 18:34:03 echo 0 > gpio60/value Apr 19 18:34:09 cat gpio30/value Apr 19 18:34:26 did you change the direction of gpio60 to output? Apr 19 18:34:27 everything works as expected Apr 19 18:34:32 ok Apr 19 18:34:45 but when I put the cape it stops working Apr 19 18:34:56 allow me to vrify one more time ... Apr 19 18:35:26 ehm, of course? the cape uses P9.11 Apr 19 18:36:10 if you're doing what you just described using those pins with the cape attached, you're lucky if you didn't damage the hardware Apr 19 19:15:07 Could you explain why? Apr 19 19:16:24 because you were connecting outputs together (P9.11 configured as output and the output of the level shifter for the rs485 received data signal Apr 19 19:16:55 which basically means you were creating a short-circuit via a processor pin Apr 19 19:26:43 Oh, I did not realize that the cape hardwires anything Apr 19 19:27:04 ... how did you think a cape worked? Apr 19 19:27:28 again, examine the schematic of the cape, it's pretty simple Apr 19 19:27:40 how does bbb works? Apr 19 19:27:44 :) Apr 19 19:28:12 by connecting other stuff to a whole bunch of processor pins Apr 19 19:28:12 I am looking at the schematics Apr 19 19:28:42 and those obviously have fixed configuration Apr 19 19:29:04 rcn-ee[m]: why doesn't the comms cape have an overlay yet? it looks like it would be a pretty simple one Apr 19 19:30:23 Yes, but most of the pins on BBB can be configured (to be GPIO, or I2c, etc.). I just thought that capes are pass-through, unless the pins are configured] Apr 19 19:30:36 Thank you for pointing my mistakes Apr 19 19:31:03 how would the hardware connections on the cape magically change based on how the pins are configured in the processor? Apr 19 19:31:27 good question Apr 19 19:31:29 :) Apr 19 19:32:10 anyway, part of the issue here is that the comms cape doesn't have an overlay yet... with most capes, the appropriate overlay would be applied automatically and this would remove the ability to reconfigure the pins used by the cape Apr 19 19:54:10 Zmatt, the other day I was playing with GPIO. I did echo 1 > Apr 19 19:54:27 echo 1 > value; echo 0 > value Apr 19 19:54:39 there was no transition; Apr 19 19:54:54 I had to put a sleep in between Apr 19 19:55:07 Are you aware of this? Apr 19 19:55:09 what made you think there was no transition Apr 19 19:55:16 since I can assure you, there was Apr 19 19:56:12 I would love to agree with you, but the osciloscope did not find any. Apr 19 19:56:29 in fact, since the sysfs interface is pretty slow, it will give a pulse that's several orders of magnitude larger than the minimum pulse width a gpio can produce Apr 19 19:56:52 Since you are so certain, I will try again Apr 19 19:57:09 I am 100% certain Apr 19 19:58:49 It is logical. I will try it again. Apr 19 20:00:05 Why on the schematics they have *2, like B9.1*2, B9.11*2 Apr 19 20:01:06 yeah not sure what they mean by that... maybe they write it like that because it's a pass-through connector? Apr 19 20:02:00 or actually, is it a pass-through connector? based on the image it looks like SMD, which implies it has separate top and bottom connectors Apr 19 20:02:47 so then that's what they mean I guess, they only use one schematic symbol but it's implicitly two connectors in parallel (the top and bottom) Apr 19 20:03:57 thanks Apr 19 21:31:17 zmat: I have reverified Apr 19 21:31:19 echo 1 > gpio67/value;echo 0 > gpio67/value Apr 19 21:31:31 and it works indeed Apr 19 21:31:48 I'm curious, how wide is the pulse? Apr 19 21:31:53 250 us pulse on BBB Apr 19 21:32:05 holy shit that's awful XD Apr 19 21:33:29 sleep 0 gave a pulse of 10 ms Apr 19 21:33:47 yeah a lot of time is lost on process spawning and shit like that Apr 19 21:36:31 perl -E 'open my $fh, ">", "value" or die $!; $fh->print(1); $fh->print(0)' Apr 19 21:37:00 would be a simple way to check the time it takes without unnecessary system calls Apr 19 21:37:43 actually, better: Apr 19 21:38:13 perl -Mautodie -E 'open my $fh, ">", "value"; $fh->syswrite(1); $fh->syswrite(0)' Apr 19 21:39:08 the one with 'print' probably doesn't work actually, the writes will get buffered and combined Apr 19 21:43:06 40 us Apr 19 21:43:20 yep, that sounds more like what I was expecting Apr 19 21:43:39 which is a mere 1000 times longer than the shortest pulse a gpio can produce, but hey :) Apr 19 21:43:47 i do not even know what to expect :) Apr 19 21:44:41 I still have X15 boards that I would not mind using. But it seems everything is more complex there. Starting with gpio. What do you think? Apr 19 21:45:51 do people even use x15? Apr 19 21:45:58 (if the gpio is set and cleared by consecutive write-transactions issued by the cpu to the gpio controller, e.g. using back-to-back cpu instructions, the expected pulse width is 40 ns if I remember correctly) Apr 19 21:46:29 ok Apr 19 21:47:17 the remaining time (i.e. effectively all of the 40 us) is just overhead in the kernel Apr 19 21:48:32 and yeah, everything is definitely more complex when using the x15... or at least, connecting hardware (due to the obscure connectors) and configuring the pins Apr 19 21:49:11 well the x15 is basically also the base board of the AM572x-EVM Apr 19 21:49:27 so in that sense it certainly gets used Apr 19 21:49:51 there are probably also people actually doing stuff with the x15, but not too many I suspect Apr 19 21:52:00 ok Apr 19 23:25:48 .. Apr 19 23:28:00 x **** ENDING LOGGING AT Sat Apr 20 02:59:56 2019