**** BEGIN LOGGING AT Mon Aug 07 03:00:03 2017 Aug 07 03:39:25 hmmm 3.3v rails on BB Blue don't power down when a sudo poweroff is issued Aug 07 04:23:16 anyone know which serial port GPS connector on BB Blue is mapped? Aug 07 04:29:47 hmmm, S2 Aug 07 04:46:12 MrCurious: that sounds odd? Aug 07 04:46:58 and hazardous. you're definitely not allowed to expose the processor's I/O to an externally driven voltage while it's powered off Aug 07 04:47:33 well, if that was the case… then the BB blue should power off its device rails on shitdown Aug 07 04:47:48 hence the "that sounds odd" Aug 07 04:48:19 must have some sort of protection against powered off signals Aug 07 04:49:24 nope Aug 07 04:50:40 oh wait… the board is powered, just in a not running linux state Aug 07 04:50:43 looking at the schematic, I don't see how it could be possible though Aug 07 04:50:44 ah Aug 07 04:51:01 it crashed during poweroff ? Aug 07 04:51:03 hence the blue light on the board, and responding to button press Aug 07 04:51:25 nope. it goes dark except for 1 blue led, and wakes when i press one of the 4 buttons Aug 07 04:52:01 that sounds more like suspend than poweroff Aug 07 04:52:22 when powered off only the power button should wake it up Aug 07 04:52:57 (and the blue power led would be off) Aug 07 04:55:59 i cant work out how to power it off, as i would prefer that to a suspend, as i would like to keep the batt connected, and serial peripherals inactive Aug 07 04:56:46 I can't think of any reason why poweroff wouldn't work as advertised Aug 07 04:56:55 I've never seen such behaviour myself Aug 07 04:57:01 works same as shutdown -hf now Aug 07 04:57:27 like it doesn't know how to power off or something Aug 07 04:57:44 which kernel are you using? Aug 07 04:57:45 oh well, the boards are cheap ish, so run it until it dies, and then investigate Aug 07 04:57:51 latest debian Aug 07 04:57:59 that's not a kernel version Aug 07 04:58:00 :P Aug 07 04:58:21 true, it isnt connected, and its put away as i am packing up for the night :) Aug 07 04:58:48 but i would say the latest kernel served up by the package manager as of a day or two Aug 07 04:58:57 it doesn't upgrade the kernel automatically Aug 07 04:59:44 then it is using whatever was out of the box Aug 07 05:00:22 since this sounds like a kernel/DT issue, I'd suggest making sure you have the latest version within the series you're using Aug 07 05:00:37 e.g. 4.4.68-ti-r115 if using the 4.4-ti series Aug 07 05:03:44 i will have to look into that in tomorrows creativity burst Aug 07 05:08:52 next step add ros modules for gps and scanse.io lidar, then work out how to expose 4 dc motors/encoders to ros Aug 07 05:14:21 anyone worked with HC-SR04 on beaglebone? Aug 07 05:14:31 can one PRU service more than one of those sensors? Aug 07 05:23:17 think the better answer will be to dedicate an arduino to servicing them, and use a serial port to get data from arduino Aug 07 05:36:29 use an epwm module to generate the trigger pulse and an ecap module to capture the echo pulse Aug 07 05:36:37 that would be my strategy Aug 07 05:37:02 using a PRU would be another fine strategy Aug 07 05:38:08 going to have to look up epwm (PWM) and ecap and learn what they are Aug 07 05:38:16 oh, I see that the echo pulse length is actually also proportional to distance... then you only need eCAP to capture the pulse length and can generate the trigger any way you want Aug 07 05:41:00 yeah, ecap looks promising Aug 07 05:41:29 I initially assumed you'd need to measure time between trigger pulse and echo pulse, which is also possible but more complicated Aug 07 05:41:51 yes, time between trigger and echo is the magic of how it gets distance Aug 07 05:43:58 datasheet says the echo pulse *length* is proportional to distance Aug 07 05:44:55 i believe that is the time between sending and recieving Aug 07 05:44:56 that Aug 07 05:45:22 no Aug 07 05:45:48 so the return signal grows in duration while in travel? Aug 07 05:46:14 I'm assuming there's some processing involved Aug 07 05:46:34 on arduino it is just time between trig and resp is teh distance fuction input Aug 07 05:46:44 I'll admit the datasheet is quite unclear Aug 07 05:47:25 resp going high or resp going low ? Aug 07 05:47:30 i will sort it, was mainly enquiring to see if anyone here had walked that road before, seeking the low hanging fruit Aug 07 05:48:57 I've definitely seen the question before Aug 07 05:49:21 there are multiple ways to solve it... which solution is the easiest depends on what you already have experience with I guess Aug 07 05:50:19 still early days on the quest. learning step. i can do it with AVR, but curious if i can do it with the BB Blue, as it would be nice to have that board be the MAIN sensor handling hub Aug 07 05:51:27 ah, now I see it says it raises the resp output immediately after transmitting the ultrasonic pulse, and then lower it again on receiving the echo Aug 07 05:51:41 hence pulse high-time is proportional to distance Aug 07 05:51:56 i think that is on the 3 pin pings Aug 07 05:52:05 ? Aug 07 05:52:05 the ones i have are 4 pin Aug 07 05:52:16 seperate trig and resp pins Aug 07 05:52:26 yes that's what I am talking about Aug 07 05:52:35 I've never seen or heard of any 3-pin version Aug 07 05:52:51 I think I've seen it implemented for PRU Aug 07 05:53:01 yeah doing it with PRU should be pretty easy Aug 07 05:53:44 including handling multiple sensors (especially since you'll only be measuring one at a time) Aug 07 05:53:47 http://www.ebay.com/itm/3-Pin-Ultrasonic-Sensor-Distance-Measuring-Module-Dual-Transducer-L2V5-/252920630636?_trksid=p2385738.m2548.l4275 Aug 07 05:54:17 assuming a PRU can govern 4 output and 4 input pins Aug 07 05:54:49 there are plenty of PRU pins Aug 07 05:55:12 using normal GPIOs would probably be fine for this purpose too Aug 07 05:55:17 but only 2 pru's, and i suspect the dc motor drivers/encoders may have consumed 1 or both already Aug 07 05:55:58 that I don't know about. one pru is obviously sufficient Aug 07 05:56:57 the datasheet says it's accurate to about 3mm, which is 17 us... so it doesn't require very precise timing Aug 07 05:57:40 (using eCAP or a well-written PRU program would yield 10 *ns* resolution) Aug 07 05:58:12 hy Aug 07 05:58:38 i wanna ask about beagle Aug 07 06:00:09 MrCurious: btw if you want an overview of which pins are usable as PRU io, I have an overview on the "PRU" tab of my spreadsheet -> https://goo.gl/Jkcg0w Aug 07 06:00:52 MrCurious: although, as I said, using normal GPIOs for this instead of the dedicated high-speed PRU I/O would probably be fine too Aug 07 06:02:09 (perhaps a bit spammy on the interconnect if polling is used, but it's also possible to use an irq) Aug 07 06:11:30 if 8 bits (1 byte) can be monitored by a ISR, then it would work fine, just triggering one spig at a time Aug 07 06:12:54 hum, apparently only gpio bank 0 has an irq line to pru... I kinda forgot about that Aug 07 06:13:08 any subset of its 32 gpios can be monitored though Aug 07 06:13:39 but, first just check if a sufficient number of pru i/o is available, since that definitely requires less code Aug 07 06:14:21 or at least use those for the echo signal.. using a gpio for the trigger signal is no problem Aug 07 06:14:24 i have a strong suspicion they are already dedicated for the serial or servo or dc motor and quadrature encoder alreadyt Aug 07 06:14:45 or use eCAP for the echo signal Aug 07 06:14:52 if one is available Aug 07 06:15:00 I have no idea what's used for what on the blue Aug 07 08:36:19 hi Aug 07 14:48:15 jkridner: when i sudp poweroff, all led's but one go off. however, serial devices stay powered. is there a way to shut down the serial power rails? Aug 07 14:48:30 fix the bug in the kernel. Aug 07 14:48:52 sweet! so it is dooable Aug 07 14:59:35 is this for blue Aug 07 14:59:37 ? Aug 07 14:59:57 it is possible to get the PMIC to disable its power rails. Aug 07 15:00:13 but, there's been a bug in the kernel that causes it to hang. Aug 07 15:01:48 MrCurious: ^^^ Aug 07 15:10:22 yes, blue Aug 07 15:10:46 for me, it is non-critical at this point, but would be super nice to have Aug 07 15:53:55 jkridner: where in the kernel does that occur? can we persuade our friend Mr Nelson to push a patch either into his armv7 tree and hopefully eventually 'upstream'?! :) Aug 07 15:54:45 he's patched similar bugs before and likely knows about this one. He had some family engagements recently, but we can probably check with him. Aug 07 15:55:10 * jkridner needs to capture a serial log during the shutdown. Aug 07 15:55:55 I put it on the backlog here: https://github.com/beagleboard/linux/issues/119 Aug 07 15:56:18 says there is a fix, but I don't know if that's right. Aug 07 15:58:56 jkridner: cool, good work, haven't seen Rob for some time :/ Aug 07 16:04:00 jkridner: does your change shutdown SYS5V? Aug 07 16:11:09 ds2: is that the one upstream or downstream of the pmic? Aug 07 16:48:26 it is downstream Aug 07 16:48:36 should have a fet switch on it Aug 07 17:28:05 ds2: change? I'm not sure what that patch does, but certainly the final fix would shutdown SYS_5V. Aug 07 17:28:26 * jkridner just found a recent quirk... Aug 07 17:29:04 you can actually power the system off of SYS_5V... I didn't know that was possible, but the PMIC will actually take it as an input and supply the DC/DC and LDO rails. Found that very strange. Aug 07 17:37:30 niiice. Figures, that pmic ain't great lol Aug 07 18:01:15 that is allowed? Aug 07 20:34:08 jkridner: yeah that works, but I wouldn't recommend it Aug 07 20:37:33 ds2: the lack of shutdown is unrelated to the pmic, apparently it just crashes during shutdown Aug 07 20:37:38 *the lack of power-off Aug 07 21:25:27 downloaded the Windows 64 driver install package BONE_D64.exe Aug 07 21:25:36 It looks like it has Linux drivers in it Aug 07 21:25:41 and not Windows Aug 08 01:59:27 it isnt just 5, but 3.3. that doesnt shut down … Aug 08 01:59:36 (said for completeness) Aug 08 02:21:26 zmatt: the pmic crashes?! or the am335x Aug 08 02:46:47 ordered my 3rd BB blue today thanks to arrow 20% discount **** ENDING LOGGING AT Tue Aug 08 03:00:00 2017