**** BEGIN LOGGING AT Sun Aug 11 02:59:57 2019 Aug 11 03:21:25 set_: that's not remotely the command I gave Aug 11 03:23:35 it would be echo $(( $(cat in_voltage0_raw) * 1800 / 4095)) Aug 11 03:25:05 you were missing the $(..) around cat in_voltage0_raw and putting a space after the $ is forbidden (this is true for both of them) Aug 11 03:26:13 another alternative would be read x which is arguable a nicer way to do it Aug 11 03:27:02 *arguably Aug 11 03:38:45 Oh! Aug 11 03:38:47 Okay. Aug 11 03:39:08 I just soldered the wires together for the PIR Sensor on the BBB.io site. Aug 11 03:39:14 Off to test! Aug 11 03:39:16 Boy! Aug 11 03:39:33 in general though you wouldn't want to do stuff like this in bash scripting anyway, just use python Aug 11 03:39:39 I feel bad for the wires and hopefully this will be a good lesson. Aug 11 03:39:41 Okay. Aug 11 03:39:42 bash is pretty awful Aug 11 03:39:46 I know. Aug 11 03:39:53 I remember reading it a while back. Aug 11 03:39:55 (as a programming language) Aug 11 03:39:58 Right. Aug 11 03:43:32 probably the most stable way to obtain a path to the adc sysfs directory without using udev would be /sys/bus/platform/drivers/TI-am335x-adc/*/iio:device* Aug 11 03:43:51 but even that's still a bit iffy :P Aug 11 03:47:52 Okay. Aug 11 03:47:58 Iffy is my middle name! Aug 11 03:48:16 bzzt, bzzt. Aug 11 03:51:07 Dang it. I got a ROS image on this board. Aug 11 03:56:03 Okay. I am set up for stardom. Now, here comes the truth! Aug 11 03:56:25 Can set_ handle prime time? Aug 11 03:56:30 That is the question. Aug 11 04:05:19 info: No pinmux found P8.13 and P8.19 and then it just keeps saying Motion Detected for: https://pastebin.com/6R2rDzN1. Aug 11 04:05:28 Any feedback? Aug 11 04:07:38 1. if you're trying to do this on a ROS image instead of using a recommended debian image then this isn't going to work Aug 11 04:07:46 I changed boards. Aug 11 04:07:50 It is Debian. Aug 11 04:08:13 does 'config-pin -l P8.13' work? Aug 11 04:08:20 Let me check. Aug 11 04:08:32 and your printStatus function is nonsensical Aug 11 04:08:41 I have to sign in again. Aug 11 04:08:42 Oh. Aug 11 04:08:58 By nonsensical, you mean what exactly? Aug 11 04:09:05 err is never going to be 1, and its value says absolutely nothing about whether motion is detected or not Aug 11 04:09:16 Oh. Aug 11 04:09:21 as the name suggests, it indicates whether an error has occurred or not Aug 11 04:09:21 Okay. Aug 11 04:09:29 Right, this is what I thought. Aug 11 04:10:30 default gpio gpio_pu gpio_pd gpio_input pwm <--- from config-pin -l P8.13 Aug 11 04:11:04 I just figured out what happeneed. Aug 11 04:11:06 Please hold. Aug 11 04:11:06 oh maybe -l doesn't do what I think it does... I never use config-pin Aug 11 04:11:20 whatever the command is to check the mode of that pin :P Aug 11 04:11:45 I am using P8.12, please hold. Aug 11 04:11:49 I will check it. Aug 11 04:12:07 that doesn't explain the error Aug 11 04:12:23 it's not like the software magically knows whether or not you connected anything to a pin Aug 11 04:12:24 P8_12 Mode: default Direction: in Value: 0 Aug 11 04:12:49 I think b/c of the Cape, the BBB thinks that my LED onboard the Cape is being used. Aug 11 04:12:57 what cape? Aug 11 04:13:02 LoadCape. Aug 11 04:13:15 what's the output from sudo show-pins | sort ? Aug 11 04:13:49 Hahahahaha. Command not found. Aug 11 04:13:50 Sorry. Aug 11 04:13:54 so install it Aug 11 04:13:58 Oh. Aug 11 04:13:59 Okay. Aug 11 04:14:00 you've done that often enough Aug 11 04:14:04 I know. Aug 11 04:16:41 https://pastebin.com/wVxBSKYE is the error w/out the (err, x) and just the (x) in my function. Aug 11 04:16:52 Just saying. Now, off to test pins w/ your utility. Aug 11 04:20:07 sudo show-pins | sort? Aug 11 04:20:55 Please hold. I got it. I will show you! Aug 11 04:21:58 https://pastebin.com/BgPY4SYf is the show-pins | sort command. Aug 11 04:22:30 please make your terminal wide enough Aug 11 04:22:37 before running the command Aug 11 04:22:41 because this is just a mess Aug 11 04:23:02 Oh. Aug 11 04:23:03 Sorry. Aug 11 04:23:08 I will start again. Aug 11 04:23:30 you should be, you've used this command before and should have realized this mess is not what it's supposed to look like Aug 11 04:24:12 https://pastebin.com/9MEGF1KP Aug 11 04:24:19 It looked okay on my end. Aug 11 04:24:38 then you should have noticed something was wrong when you created the paste Aug 11 04:24:53 Oh. the next paste is better. Right? Aug 11 04:25:24 anyway, this clearly shows why you can't reconfigure P8.13 nor P8.19, both pins are in use by the cape Aug 11 04:25:32 Dang!@ Aug 11 04:25:35 Okay. Aug 11 04:25:49 I will take the Cape off. Aug 11 04:25:54 Blah! Aug 11 04:26:00 or just use a pin that's free Aug 11 04:26:04 e.g. P8.12 Aug 11 04:26:12 I am using P8.12 for the LED. Aug 11 04:26:18 any of P8.07-P8.12 really Aug 11 04:26:23 That is done. Now, oh. Aug 11 04:26:25 Okay! Aug 11 04:26:27 Please hold. Aug 11 04:26:52 I will use P8.08 for the signal line of the PIR Sensor. Aug 11 04:28:07 Oh. THis is the MotorCape. Aug 11 04:28:20 I changed to pin P8.08. Aug 11 04:28:26 Restart! Aug 11 04:29:33 so, reconfigurable pins are the ones where the name in parentheses at the end contains the pin name (as well as the pin mode)... e.g. for P8_12 in your paste it showed "pinmux_P8_12_gpio_pin" which means it's a reconfigurable pin, and configured to mode "gpio" Aug 11 04:31:11 Okay. Aug 11 04:31:17 I think I can read it for now on. Aug 11 04:32:31 or easier maybe: immediately after reboot (when you haven't used config-pin yet), the lines ending in "_default_pin)" belong to reconfigurable pins Aug 11 04:33:03 Oh. default_pin belong to reconfigurable pins. Got it. Aug 11 04:35:35 Okay. I got some new software and still... Aug 11 04:35:44 It is detecting motion when I do not move. Aug 11 04:35:48 specifically, reconfigurable pins that are still in default mode Aug 11 04:36:30 what kind of output does this PIR sensor have? Aug 11 04:36:33 Oh. So, if the pin is started in a mode and can be altered, it is followed by _default_pin. Aug 11 04:36:51 By output, you mean the wires? Aug 11 04:36:59 if the pin is reconfigurable but haven't been configured yet, it ends in _default_pin Aug 11 04:37:07 Oh. Aug 11 04:37:34 Now, I got that idea. It just needs to be configured then if ending in _default_pin. Aug 11 04:37:35 maybe I should just ask: what sensor are you using? have a name or link? Aug 11 04:37:52 Oh. It is an older model. I need to check. Please hold. Aug 11 04:38:55 It has not markings on it but it has a chip, too tiny to tell. Aug 11 04:39:13 5v, GND, and Out. Aug 11 04:39:33 OH well. I gave it a shot. Aug 11 04:39:39 you don't know where you got it? no documentation? what makes you believe you can connect it to the bbb without destroying it? Aug 11 04:39:51 I have no clue. Aug 11 04:39:56 You are right. Aug 11 04:40:03 I should retire for the night. Aw! Aug 11 04:41:24 @zmatt: Thank you again. I should get a couple new items and all w/ datasheets. Aug 11 04:41:53 like, one module I found on adafruit says it gives a 3V high pulse (of unspecified width) when motion is detected, so that would be compatible, although polling it like you do would be unlikely to ever work, you'd need an edge-triggered interrupt Aug 11 04:42:35 Hmm. Aug 11 04:42:37 Okay. Aug 11 04:42:57 but if you don't know what module you have, you have no way of knowing whether that applies to your module Aug 11 04:43:07 Right. Aug 11 04:43:13 anything powered by 5V should be considered hazardous Aug 11 04:43:20 unless you know it isn't Aug 11 04:43:24 Okay. Aug 11 04:45:03 and apparently some may have an open collector output, in which case you'd need a pull-up resistor (using internal pull-up on the pin *might* suffice although using an external 10K pull-up would probably be better) Aug 11 04:45:40 Alright. Aug 11 04:46:05 I have a 10k ohm resistor attached like the schematic at bbb.io.../.../.../. Aug 11 04:46:50 The resistor is attached b/c of the 5v current from the BBB. Aug 11 04:47:33 Please hold. Aug 11 04:52:39 Okay. Aug 11 04:52:42 I am out. Aug 11 04:52:58 some hardware might be in order. Aug 11 04:53:13 But for now, all I have is this PIR sensor. Off to the store! Aug 11 04:54:12 wait WHAT Aug 11 04:56:50 jkridner[m]: why on earth is there a diagram on the beagleboard.org website where a gpio is given a 10K pull-up to 5V ?! => https://beagleboard.org/Support/BoneScript/PIRMotionSensor Aug 11 04:57:24 set_: do not ever connect a gpio to 5V, whether directly or via a resistor Aug 11 04:57:34 Okay. Aug 11 04:57:36 Done. Aug 11 04:57:51 But for now, I am out of ideas and sleep is in the near future for me. Aug 11 04:58:03 zzzzz! Aug 11 04:59:37 jkridner[m]: (it's also using the wrong pin for 5V to supply the sensor, it should be sys_5v, but that's a lesser concern) Aug 11 05:00:40 set_: and if you're saying the pin is continuously low, then probably it's a PIR sensor with an active-high push-pull output rather than an active-low open-collector output Aug 11 05:01:24 (which would also have saved the gpio from being damaged by the pull-up resistor) Aug 11 05:11:12 @zmatt: I am just following your chats with set_ why should we consider or prefer to use external pull up register instead of internal pull up register that is already there in Beagle Bone Aug 11 05:11:54 the internal pull-up/down is very very weak, it's basically just to keep unused pins from floating Aug 11 05:12:09 they're 100Kohm ± 50% Aug 11 05:13:37 Their watt rating is low something like that as the external have generally a .25w rating which are generally available Aug 11 05:15:56 ?? the internal pull-up resistors don't have a "watt rating", they have such large value that no significant power can ever be dissipated by them Aug 11 05:20:59 watt rating in this context is not a concern anyway... if it were to become a concern, the digital output would probably get destroyed long before the resistor will be Aug 11 05:32:52 Ok thanks for the clarification @zmatt Aug 11 10:54:01 Hi guys. Not sure if this is the place, but here goes. I'm following along in "Mastering Embedded Linux Programming - second edition", and I have reached the point where I am to build the U-Boot bootloader for the BeagleBone Black. This results in the following warnings: pastebin.com/1jvUN0S8 This seems to influence new builds. Has this been looke Aug 11 10:54:02 d at? or where do I report this issue? Aug 11 10:56:46 what u-boot version? Aug 11 10:57:42 I'm on the 2019.07 release. It should be the latest. Aug 11 10:59:54 *shrug* presumably TI will eventually take care of it Aug 11 11:00:46 what's this am335x_boneblack_vboot_defconfig target anyway? I vaguely recall having seen it listed, but I don't think I've ever seen or heard of anyone using it Aug 11 11:02:37 it's the only configuration called something close to BeagleBone Black. I haven't looked closer at it Aug 11 11:02:52 why are you building a custom u-boot anyway? Aug 11 11:03:14 I'm following along with this book. "Mastering Embedded Linux Programming" Aug 11 11:03:40 oh I guess it's possible that the target normally used is one added by rcn and not in mainline... not sure, I've never tried to use mainline u-boot Aug 11 11:03:49 ok, haven't heard of that either Aug 11 11:04:36 who's RCN? Aug 11 11:04:58 so the goal is to build a customized linux system or something? like "linux from scratch" ? Aug 11 11:05:37 robert c nelson maintains the standard kernels, u-boot, and debian images for beaglebone Aug 11 11:05:44 which is what most users use Aug 11 11:06:05 pretty much. Getting a hands-on experience of what it takes to get linux up and running on a custom board Aug 11 11:06:15 ah. gotcha. Aug 11 11:06:32 custom board? earlier you said beaglebone black :) Aug 11 11:07:27 I know, but I'm just learning the software side of things. I need a hardware platform to work with Aug 11 11:07:57 the book also mentions a QEMU vm as an alternative, but I had the BBB lying around Aug 11 11:08:46 but yeah, for a custom board you may need a custom u-boot, and you'll definitely need a custom device tree. those are usually the only two parts that require customization, although you may also need a custom kernel if the distro of your choice doesn't include a kernel with the drivers you need/want Aug 11 11:09:21 that's my understanding so far as well Aug 11 11:09:59 I suspect that mainline u-boot expects you to use am335x_evm_defconfig for the beaglebone, but I'm not sure Aug 11 11:10:53 and in the mainline u-boot git master branch, I see CONFIG_DM_USB=y, CONFIG_DM_SPI=y, and CONFIG_DM_MMC=y in that defconfig Aug 11 11:11:15 so the warnings in your pastebin are either due to using this weird vboot config, or they've been fixed in master Aug 11 11:11:58 ah the vboot config has them too... they've been fixed in master Aug 11 11:12:27 perhaps. I'm on the v2019.07 branch. I guess I should just use the master branch then Aug 11 11:12:38 usually you shouldn't Aug 11 11:12:58 unless you've trying to contribute to u-boot development Aug 11 11:13:14 these are merely warnings, they don't imply anything is wrong Aug 11 11:13:47 well, getting to know how to use the thing would be a good first step before trying to fix things in the thing Aug 11 11:14:54 regardless, those warnings aren't something you need to fix Aug 11 11:15:03 gotcha. Aug 11 11:15:45 Thanks for the response. Just wanted to know if they had been looked at, or if I should worry. Aug 11 11:16:05 It does make sense to look at the master branch to check Aug 11 11:16:28 looking at the dates in those warnings, it's safe to say the u-boot project has probably already been nagging the relevant maintainers for a while about this now Aug 11 11:17:36 oh, you're right. I didn't notice those dates Aug 11 11:17:53 the transition to Driver Model has been going on for years already Aug 11 11:19:42 so many new concepts to dive into. I had heard about Device trees before, but only this week got to know what they were about. And this Driver Model is new too. Aug 11 11:19:55 DM is just an u-boot implementation detail Aug 11 11:20:07 https://www.denx.de/wiki/U-Boot/DriverModel Aug 11 11:21:03 anyway, I'm pretty sure you shouldn't use am335x_boneblack_vboot_defconfig, use am335x_evm_defconfig instead Aug 11 11:21:45 not 100% sure though I'll admit, since like I said I've never tried using mainline u-boot on a beaglebone Aug 11 11:24:17 oh. gotcha. Thanks. I'll make a note of that in my book. It's from 2017 and they are working on a new version. It was set to be published a month ago, but then pushed to next year - and I couldn't wait ;) Aug 11 11:29:27 like, if you want to reproduce an u-boot like the ones used by the official debian images, you'd locate the directory for the mainline u-boot release you're using here: https://github.com/eewiki/u-boot-patches (there's none yet for 2019.07), and apply 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch and optionally 0002-U-Boot-BeagleBone-Cape-Manager.patch (which adds support for overlays and ... Aug 11 11:29:33 ...cape-autodetection) Aug 11 11:31:12 this also used to add an am335x_boneblack_defconfig, e.g. in v2018.09 (which is the released used in the current official images), but it seems that it no longer does (in 2019.04), so I guess am335x_evm_defconfig is used now... either that or not all relevant changes have been ported to these newest versions yet Aug 11 11:35:30 interesting. I will have a look. Aug 11 11:38:29 there's a 2019.07-rc4 folder. That might be close enough, but I don't have anything to help me debug the process if it doesn't work. Aug 11 11:39:29 for stuff like bootloader, generally "well tested in practice" might be preferable to "latest and greatest" ;) Aug 11 11:39:57 but it'll depend on circumstances of course Aug 11 11:41:55 Usually I prefer latest and greatest - my build PC is running Arch Linuc. But for my situation - just starting out with U-Boot - I would prefer things working. Later I might be more bold ;) Aug 11 17:04:49 zmatt: one thing a new bbb would be nice for is to have one with EMMC memory that doesn't wear out like flash memory does, and have enough of it to do a firmware/ota update Aug 11 17:06:47 it already uses eMMC, not raw flash, but eMMC is just flash memory with an embedded controller and therefore wears out just the same Aug 11 17:08:16 and it has plenty of space. we actually reconfigure eMMC in a way that improves both performance and reliability/longevity in exchange for sacrificing 50% storage capacity, and we still use far less than 50% of the remaining space hence have no issues at all doing firmware updates Aug 11 17:09:00 (and we didn't really put any effort into minimizing the use of eMMC space, we haven't needed to so far) Aug 11 18:03:46 it is the ota part that i struggle with. doing an update without physical access Aug 11 18:04:28 yup, that can be tricky Aug 11 18:07:27 ive not been able to find anything that doesn't require pressing the button Aug 11 18:07:56 I have no idea what button would ever be involved in OTA updates Aug 11 18:11:17 step 10: https://medium.com/@zageollc/updating-the-software-image-on-a-beaglebone-black-fc73ffcc700 Aug 11 18:11:25 unless you mean reflashing from sd card, in which case still no button is required, but an SD card is :P (and while I guess it would be possible to involve a permanently install SD card into the OTA update process, it's not something I'd be inclined to consider) Aug 11 18:12:44 that's talking about manual updates, not OTA updates Aug 11 18:13:15 also, the boot button is usually not needed for reflashing Aug 11 18:13:44 most of that document is also outdated Aug 11 18:13:50 you don't need to install any drivers on your PC Aug 11 18:14:05 hmm.. the process i've seen outlined involves having multiple partitions, and two of them being essentially mirrors of each other Aug 11 18:14:28 that is one solution Aug 11 18:14:36 one is the backup, one is the newest install Aug 11 18:15:11 but that means that you need about double the space as the image Aug 11 18:16:17 that makes the update process relatively straightforward, although you'd probably need to build a custom bootloader capable of figuring out which of the two partitions to load linux from (based on some setting), or I guess maybe you could have a small boot partition and two rootfs partitions, not sure Aug 11 18:17:20 regardless of the method, a robust method to update the entire system would require the new system to be on disk at the same time as the old system (to ensure the old system remains functional until the new system is fully in place), hence you can't use more than half the available storage Aug 11 18:19:14 although I guess it might be enough to just have enough free space for a compressed version of the new system, and then arrange the system to boot into an updater that removes the old system before decompressing the new system (taking care to ensure that if power fails during this, you'll simply boot into that same updater again which will again proceed to remove the system (either the old one or the ... Aug 11 18:19:20 ...partially expanded new one) and expand the new system) Aug 11 18:19:59 4gb is a bit tight Aug 11 18:20:05 in all cases it's a tricky process that requires a great deal of thought to ensure power loss at the wrong time doesn't result in a dead device Aug 11 18:20:27 for what? are you storing video files? :P Aug 11 18:22:10 no. 4GB/2 is 2GB, and so a target size might be more like 1.8G to leave a little buffer Aug 11 18:22:15 our development beaglebone (which has development tools installed and such) uses 3.1GB of space currently, but 1.7GB of that is in /home (i.e. me and my fellow devs really ought to clean our shit out again some time soon) Aug 11 18:22:32 our production beaglebones use like 300MB or something like that iirc, I'd need to check Aug 11 18:23:32 340M Aug 11 18:27:34 hays: btw the process for reflashing manually is a _lot_ easier (nowadays anyway) than described on that medium.com page Aug 11 18:28:39 you download the latest flasher image, write it to sd card using Etcher (no need to decompress the image first, Etcher will do so for you on the fly), then boot the beaglebone from it (this might require the use the boot button but usually it doesn't), and wait for it to be done reflashing Aug 11 18:57:48 where is the best detailed technical documentation to be found about the boot process and software design of the beaglebone itself Aug 11 19:16:38 I don't have an answer for that. there's no single source of information for that, and not sure how much of it is documented in the first place (documentation tends to get out of sync with reality anyway) Aug 11 22:01:30 @zmatt: This is the PIR sensor I was describing: https://learn.adafruit.com/pir-passive-infrared-proximity-motion-sensor. Aug 11 22:01:31 ... Aug 11 22:01:59 I looked through my old records. I found some info. about the chips onboard. I will keep researching these ideas. Aug 11 22:04:55 I will look around online and be brb in case you post anything about ideas relating to the PIR and bonescript. Yea boy! Aug 11 22:13:11 In python, I can probably use wait_for_edge w/ Adafruit_BBIO.GPIO as GPIO, right? Aug 11 22:15:37 Should I plug in the wiring to 3.3v instead of 5.0v? Aug 11 22:15:58 I see this particular PIR sensor can handle 3.3v or 3 to 5v. Aug 11 22:41:54 set_: well the image says 3-5V while the description below it says "5V-12V input voltage for most modules", so I'd trust neither piece of information. this page isn't really about any specific PIR, just about PIRs in general Aug 11 22:43:47 if the sensor can run on 3.3V, that would be greatly preferred Aug 11 22:45:21 you should really try to find the *exact* module you're using Aug 11 22:48:10 Okay. I will show you the one on their page. Aug 11 22:48:28 I will try w/ 3.3v instead of 5v to test. Aug 11 22:48:58 no, don't just put random voltages on a module for which you don't know whether it's okay with it or not Aug 11 22:49:05 https://www.adafruit.com/product/189. Aug 11 22:49:10 Okay. Aug 11 22:49:24 That is a good piece of info. Thank you. Aug 11 22:49:40 and you're sure it's this module? Aug 11 22:49:45 I will not test the PIR sensor on the 5v or 3.3v of the BBB until I read more. Aug 11 22:50:27 the photos match the appearance of your module *exactly* as far as you're able to tell from the photos? Aug 11 22:51:01 Yes. Yes. and Yes. Aug 11 22:52:08 well then why would you be inclined to try powering it on 3.3V when the description explicitly states it requires 5-12V and running it on a lower voltage requires patching the board? Aug 11 22:54:11 B/c there is a 3.3v regulator. Aug 11 22:54:18 onboard. Aug 11 22:54:39 yes, which is exactly why you can't power the board at 3.3v Aug 11 22:54:49 And...from what you were stating about the 5v and GPIO, that did not seem like a likely mix of a circuit. Aug 11 22:54:50 Oh. Aug 11 22:55:00 So, the barrel jack needs to be used? Aug 11 22:55:06 no? Aug 11 22:55:11 No? Aug 11 22:55:29 the beaglebone's 5v output is always available (when powered on) Aug 11 22:55:34 Right. Aug 11 22:55:47 I get that idea. I was wondering if you made a mistake in explaining something. Aug 11 22:56:15 So, 5v for the PIR sensor and that is that or I could use some sort of higher voltage and another circuit. Aug 11 22:56:23 I didn't, but I don't exclude that you made one in understanding what I said... right now seem to be confusing all sorts of random things, as usual Aug 11 22:56:34 Okay, okay. Aug 11 22:56:48 @zmatt: I read that article on that page I listed. Aug 11 22:57:01 5v to 12v like you stated for the PIR. Aug 11 22:57:13 So, the BBB has a 5v pin to power things. Aug 11 22:57:14 Okay. Aug 11 22:57:37 this particular PIR sensor, the adafruit one, should be powered by 5V from the beaglebone (P9.07/08) and its output is 3.3V hence can be connected to a gpio of the beaglebone Aug 11 22:57:59 it's a push-pull output so don't connect a pull-up resistor to that line (and certainly not to 5V!) Aug 11 22:59:38 So, I can just use the three wires as is w/out a resistor. That is nice. Is that b/c of the diode on the PIR sensor? Aug 11 22:59:58 ???? Aug 11 23:00:03 Aw! Aug 11 23:01:02 I listened to the schematic online at bbb.io. Aug 11 23:01:52 yeah that schematic is pure bullshit Aug 11 23:01:55 jkridner[m]: ping Aug 11 23:04:36 OH. Aug 11 23:04:38 Okay. Aug 11 23:04:42 No issue. Aug 11 23:04:45 I told you that last time already Aug 11 23:04:55 I left and read the info. today. Aug 11 23:05:01 I saw it though. Aug 11 23:05:23 After the "zzzzz" comment from me, I was already going to sleep. Aug 11 23:06:14 Hey, @zmatt, I will look for other articles on PIR sensors. I have a book for tweepy and Adafruit_BBIO for a PIR sensor. Aug 11 23:06:16 I will test it. Aug 11 23:06:27 I think this is why I purchased this exact PIR sensor. Aug 11 23:09:38 I just signed up for a developer twitter account so I can use this api credentials for "tweeting" my PIR sensor info. Aug 11 23:09:46 Anyway...I will test w/ a LED first. Aug 11 23:10:54 The person in this book, Mr. Rush, explains in his diagram that this PIR sensor does not need a resistor at all. Aug 11 23:11:02 I will have to perform more searches. Aug 11 23:17:53 that's also what I just said Aug 11 23:18:00 00:57 <@zmatt> it's a push-pull output so don't connect a pull-up resistor to that line (and certainly not to 5V!) Aug 11 23:18:14 Got it. Aug 12 00:10:00 zmatt: pong Aug 12 00:10:56 https://beagleboard.org/Support/BoneScript/PIRMotionSensor ... notice any problems with that schematic? :P Aug 12 00:12:02 (apart from the fact that apparently many PIR sensors have a push-pull active-high pulse output rather than an open-collector active-low output) Aug 12 00:12:25 jkridner[m]: gpio is being pulled up to 5V Aug 12 00:12:44 (also, it's using the wrong pin for 5V, but that aside) Aug 12 00:16:17 I'm thinking we should move (and fix) some of these at https://github.com/beagleboard/cloud9-examples and get rid of that selection of tutorials. Aug 12 00:17:15 I mean, some code cleanup would be nice too (use 2-argument callbacks, use "let" or "const" instead of "var", etc), but a schematic that is liable to destroy beaglebones is really not good :P Aug 12 00:32:23 Okay! Aug 12 00:32:29 I can try I guess. Aug 12 00:32:47 But...I think those sources are too complicated for little, ole me. Aug 12 00:33:44 First, PIR time. Aug 12 00:34:39 set_: uhh, what are you replying to / who are you talking to? Aug 12 00:34:56 Um. Cleaning up that software on the github.com repo. Aug 12 00:35:27 I bet I can attempt to try them out and see how far I make it. Aug 12 00:35:31 he was not talking to you Aug 12 00:35:35 Oh. Aug 12 00:35:43 Who is going to do it? Aug 12 00:37:30 I'm assuming that with "we" he meant himself and other people from beagleboard.org who work on this (based on commit log Mark Yoder also contibutes quite a bit) Aug 12 00:37:40 Oh. Aug 12 00:38:04 I was thinking I could try since those people are way too busy to try things like that in which is too simple to them. Aug 12 00:38:06 Heh? Aug 12 00:38:20 I think that made sense. Aug 12 00:50:54 https://pastebin.com/auhr6n31 is my own rendition of what does not work. Aug 12 00:51:21 One PIR Sensor and one LED for notification outside of the command line notifying me. Aug 12 01:46:06 PIR sensors sometimes take up to one minute for activation to occur. Ouch. Back to running source. Aug 12 01:46:29 apparently they have initialization time yes Aug 12 01:46:37 before they become functional Aug 12 01:46:38 I am learning. Aug 12 01:46:44 Right. Aug 12 01:46:48 That is what I learned. Aug 12 01:47:00 Function, function! Aug 12 01:47:17 I was giving it seconds and then shutting down the source. Aug 12 01:47:33 I need to run it for a couple of minutes to test it out. **** ENDING LOGGING AT Mon Aug 12 02:59:58 2019