**** BEGIN LOGGING AT Thu Mar 01 03:00:00 2018 **** ENDING LOGGING AT Thu Mar 01 04:44:32 2018 **** BEGIN LOGGING AT Thu Mar 01 04:46:03 2018 **** ENDING LOGGING AT Thu Mar 01 04:54:46 2018 **** BEGIN LOGGING AT Thu Mar 01 04:55:11 2018 **** ENDING LOGGING AT Thu Mar 01 05:02:41 2018 **** BEGIN LOGGING AT Thu Mar 01 05:05:00 2018 Mar 01 07:22:35 Does anyone have experience using MATLAB 2017b and BBBW? I can't even get the test to work. Mar 01 08:18:19 zmatt: hey dude, I've written a ppm decoder for the PRU0 and I wanted to know if you could take a quick look at it to give any suggestions? Mar 01 08:18:50 zmatt: https://pastebin.com/gyBYMX77 Mar 01 08:43:16 hfs what is going on ahah Mar 01 10:08:47 Hello Mar 01 10:09:31 lo Mar 01 10:12:34 For some reason I can't ask a question on the support Mar 01 10:12:51 topic just doesn't add there Mar 01 10:40:06 loader: please explain yourself Mar 01 12:24:25 if "config-pin" shows up again while I'm not around: pru's compare-and-branch instructions have a really bizarre definition: Mar 01 12:24:28 qblt label, a, b means jump to label if b < a Mar 01 12:24:31 note the swapped arguments Mar 01 13:24:29 Hello can we run Matlab trained Neutral network on Beaglebone Rev6 Mar 01 14:10:39 Hi, is there anybody responsible guy for partnerships with beagle? Mar 01 17:00:22 Hm, I'm getting confused with dt overlays again. I'm trying to enable I2C2 for the grove connector on a BBG. I tried adding uboot_overlay_addr4=/lib/firmware/BB-I2C2-00A0.dtbo Mar 01 17:00:41 blathijs: if you're using a recent system, you should not need to explicitly deal with overlays whatsoever Mar 01 17:00:53 and in fact enabling any overlay will probably just cause issues Mar 01 17:01:08 It worked for SPIDEV :-) Mar 01 17:01:35 ... skip ahead: It seems that the bonemux-helper is hogging the pins and I've read that it enables the module when a pin is enabled, but I couldn't find how to control it Mar 01 17:01:38 Is that config-pin? Mar 01 17:02:01 (Since I thought config-pin was for the "universal cape", which seems to be a different thing from the bonemuxhelper) Mar 01 17:02:28 bone-pinmux-helper, that is Mar 01 17:02:39 Any insight there? Mar 01 17:03:57 Ah, found "config-pin -i p9_20", which suggests that the pin defaults to i2c if no cape is loaded, so I should probably not touch this stuff at all Mar 01 17:06:24 I'm still a bit confused about the distinction between the pinmux helper (which is in the base overlay) and the universal cape overlay, but that might be a matter of terminology.. Mar 01 17:08:00 Interestingly enough, bone-pinmux-helper is only used for P9.19/20, which probably explains with the SPIDEV0 overlay is still working Mar 01 17:10:07 everything you're saying sounds really confusing and messed-up... bone-pinmux-helper instances should be used for all pins *except* p9.19-20 since those are always configured for i2c-2 Mar 01 17:10:17 however all this is only true when cape-universal is enabled Mar 01 17:10:21 zmatt: Seems that changed in january Mar 01 17:10:29 which is true by default, but I think it may be automatically disabled if you try to load overlays Mar 01 17:10:30 zmatt: https://github.com/beagleboard/linux/commit/97653ff93cebadcfaab7a7c3cba5c26cbecbb81b Mar 01 17:10:46 Yeah, the universal overlay is disabled if any cape overlays are specified Mar 01 17:11:32 interesting, they made p9.19-20 configurable? doing so in the base dts instead of in universal is probably a bug though Mar 01 17:12:02 zmatt: What was the reason to not have them configurable before? Mar 01 17:12:33 because using them for any purpose other than i2c conflicts with the cape auto-detection done at boot Mar 01 17:13:16 Ah, right. So you would have to disable the autodetect in uEnv too, then. Mar 01 17:13:19 (indeed, not loading any overlays gives me a i2c2 device, so I should have checked that first :-p) Mar 01 17:13:37 not loading any overlays should give you all i2c and spi devices among other things Mar 01 17:13:55 i2c2 should be there in all cases Mar 01 17:14:23 and yes reusing those pins should only be done if cape-autodetection is disabled, but I don't think there's any way to do that yet Mar 01 17:17:22 I don't think SPI is enabled by default (that is, the device is, but not the pinmux) Mar 01 17:18:34 Ah, and the reason loading the SPIDEV0 overlay worked, without conflicting with the universal cape, is that having dtoverlay=... in uEnv.txt disables the universal overlay. For I2c, this didn't work, because the pinmux-helper is in the base instead. Mar 01 17:19:12 zmatt: So IIUC, the correct way to enable SPI now is to use config-pin to set up the pinmux, not load the SPIDEV overlay? Mar 01 17:19:28 for pins p9.19-20 you mean. yes, you should preferably just consider those to be fixed-function rather than configurable (even if they are configurable now) Mar 01 17:19:34 yes Mar 01 17:20:08 I mean, using overlays is still supported, but afaik that's mostly just for backwards compatibility Mar 01 17:20:24 zmatt: Ok, thanks. Any canonical place early in the boot to put these config-pin calls? Mar 01 17:20:28 Or a config file perhaps? Mar 01 17:30:34 no idea, sorry :) Mar 01 17:31:00 personally I use neither overlays nor cape-universal, so I don't have a huge amount of advice to give with regard to them Mar 01 18:38:54 zmatt: k, thanks (also for all previous assistance, much appreciated!) Mar 01 18:40:31 Perhaps the pinmux-helper for p9.19/20 is in the base dts, since it needs to default to i2c mode? Though I could imagine the pin mux is normally programmed in the base dts and then taken over by the pin mux in the universal overlay Mar 01 18:41:36 yeah I realized that too after saying it.... I mean, they could have configured it fixed to i2c in the base dts but override that in the universal overlay, but there wouldn't be any point really Mar 01 18:43:25 The current approach could conflict with cape overlays, but those can't be (automatically loaded) without i2c2 anyway, as you suggested. Mar 01 18:45:14 well, like I said, using these pins for any purpose other than i2c will have some degree of conflict with cape auto-detection Mar 01 18:45:48 so making them configurable like this was imho not smart Mar 01 18:46:28 instead there should just have been an option to disable cape auto-detection, and have variants of the universal overlay to be used when cape-autodetection is disabled that allow those pins to be configured Mar 01 18:46:49 (defaulting to gpio in that case instead of to i2c) Mar 01 18:47:17 and disabling cape-autodetection with universal disabled should just leave the pins unconfigured to allow them to be configured by an overlay Mar 01 18:49:27 Hey! Mar 01 18:49:57 Anyone here? Mar 01 18:51:19 http://www.catb.org/esr/faqs/smart-questions.html Mar 01 18:51:51 whether anyone is here right now, at a specific time, is not a productive question. people tend to glance at irc occasionally, and most are not likely to react to "anyone here?" Mar 01 18:52:22 if you want to ask something, ask it (and stick around to allow time for someone to see the question and answer it) Mar 01 19:07:57 Thanks for the heads up. I'l; ask better questions Mar 01 19:13:20 HELP Mar 01 19:13:35 well there are always worse examples Mar 01 19:14:48 I have a beaglebone black that I want to controll a 32x64 RGB LED Matrix. I am looking for where pins from a HUB75 goto on the P8 or P9 header Mar 01 19:15:15 * zmatt googles hub75 Mar 01 19:16:15 I have, but I have the ribbon cable and no mating connector on the board Mar 01 19:17:53 gkasinec: looks like you'd need a bit of hardware to interface them anyway, since they use 5v logic Mar 01 19:19:36 I am a mechanical engineer with no electronic knowledge. I find connection diagrams for raspberry pi but nit BBB Mar 01 19:20:09 there shouldn't be much difference, the rpi also has 3.3v gpio Mar 01 19:21:05 for instance, the R0 pin on the matrix goes to what pin on the BBB header Mar 01 19:21:50 uhh, if you intend to use gpio to control the display, you can use pretty much any pin Mar 01 19:22:00 a few of them are reserved or special-purpose Mar 01 19:22:20 I am concerned I will damage the board Mar 01 19:23:06 as long as you don't expose any bbb pins to 5v you're not likely to damage the board Mar 01 19:25:51 if you want a list of all pins with special-purpose ones explicitly marked, you can try my show-pins script for example: https://github.com/mvduin/bbb-pin-utils/#show-pins Mar 01 19:27:28 note that some special functionality can be disabled to free up more pins for gpio, for example disabling hdmi will make a lot of extra pins available Mar 01 19:33:56 "There's zero documention out there on how these matrices work, and no public datasheets or spec sheets" Mar 01 19:33:59 that's just wonderful Mar 01 19:36:55 oh and they have no pwm capability built in... so if you want to be able to dim the leds (instead of just turning them on/off) you might want to use a PRU core to generate this protocol (which somewhat restricts which pins you can use) Mar 01 19:47:02 gkasinec: maybe this might be of use to you -> https://trmm.net/Octoscroller Mar 01 20:31:53 zmatt: Earlier you said that using config-pin is the new way to enable hardware (e.g. SPI) and using overlays is not, but I guess that overlays will continue to be supported, since that is how capes are configured (so the base dtb cannot claim resources that conflicts with cape overlays) Mar 01 20:32:13 correct Mar 01 20:34:44 So I'll just continue to use the SPI overlay, since that is effectively the overlay for my cape (the rest is all userspace) Mar 01 20:34:51 Slowly, pieces are falling together :-P Mar 01 20:45:25 testing Mar 01 20:45:32 success Mar 01 20:45:32 \help Mar 01 20:45:35 fail Mar 01 20:45:53 lol I was just trying to get the help command to run Mar 01 20:45:56 :) Mar 01 20:46:18 Anywho, I'm also wondering if someone can point me in the right direction with some power questions I had with the beagle bone blue Mar 01 20:46:41 maybe someone can if you ask those questions Mar 01 20:46:43 I can't find the relevant documentation on the DC power jack labeled 12V Mar 01 20:47:24 How much current it draw, voltage range (although there is a voltage range on a bubble diagram on GitHub) can I plug the DC jack power in at the same time as USB? Mar 01 20:47:50 ^ I can't find that explicitly listed anywhere Mar 01 20:49:24 1. I'd say worst case 10W + whatever the battery charger is using to charge the lipo battery (assuming one is attached) Mar 01 20:50:39 voltage range would be the intersection of the input voltage ranges of the AP1509 regulator and the MP2615 charger ic Mar 01 20:50:51 you can probably just look up their datasheets Mar 01 20:51:20 and yes there's no problem in attaching usb at the same time... it would be rather annoying if there were Mar 01 20:51:20 awesome thanks Mar 01 20:51:31 perfect Mar 01 20:51:40 thanks for that info Matt! Mar 01 20:52:06 in general I can't find much documentation on the beagle bone blue Mar 01 20:52:30 is it expected that you look up the parts list and schematic and work backwards from the individual components? Mar 01 20:52:36 it's not just the blue that suffers from that problem :) Mar 01 20:52:55 https://github.com/beagleboard/beaglebone-blue/wiki has some info Mar 01 20:53:02 but other than that, dunno Mar 01 20:53:52 Oh cool I didn't know about that wiki tab on github Mar 01 20:54:25 alright I'm taking off to get working on this then, thanks again for your help Matt :) Mar 01 21:07:07 AP1509, not the best choice I'd say... but popular Mar 01 21:09:47 yeah I noticed its datasheet doesn't even specify things like output ripple Mar 01 21:12:10 efficiency at high load and high stepd Mar 01 21:12:17 down ratio ... Mar 01 21:12:43 switching frequency requires rather large coils... Mar 01 21:14:15 on the other hand, decent output current, package simple to solder, integrated switch, low external component count... Mar 01 21:14:22 kit friendly Mar 01 21:21:06 playing a bit with TI's power designer, a nice balance seemed to be a design based on the tps563200 Mar 01 21:33:00 agreed Mar 01 21:33:37 and the ti datasheet is much better Mar 01 21:50:50 LM53602 is also quite nice, but not as easy to handle Mar 01 21:51:01 ground pad under the chip Mar 01 21:51:45 no problem to reflow, but a bit dificult with a soldering iron ;) Mar 01 22:04:22 not really a relevant factor the blue obviously Mar 01 22:13:45 that tps is a sweet chip Mar 01 22:13:57 great decision by the bb designers Mar 01 22:15:17 hmm, which? Mar 01 22:16:53 as far as I remember, all chips with a "tps" prefix used on beaglebones range from "meh" to just "okay" for their purpose Mar 02 00:35:43 kenrestivo: if you mean the tps563200, it isn't actually used on any beaglebone Mar 02 00:40:09 Hey. Little bit of a newbish question, just want to verify my thinking on this. Would a serial cable like this https://elinux.org/Beagleboard:BeagleBone_Black_Serial be enough to give me serial console access to the bbb? Mar 02 00:41:31 yes? Mar 02 00:44:44 Would I need usb to serial convertor in that case? Mar 02 00:45:55 that's what those cables are Mar 02 00:46:23 Alright, great. Just making sure so I don't get frustrated later, thanks :) Mar 02 00:46:38 they're not just cables, they have an usb serial converter integrated into the usb plug Mar 02 00:46:52 that's why the usb plug is a bit oversized Mar 02 00:49:28 ah good, that should be a neat first go at serial for me then, not much of a hardware person.. just wanna put my SBC to good use :) Mar 02 00:50:18 note that typically there's not much reason to access the serial console (although it can be extremely useful to have if you need to debug boot issues) Mar 02 00:53:06 Yeah I'd prefer ssh or hdmi but the distro I want to try requires serial access for install Mar 02 00:53:20 ew Mar 02 00:53:53 I think it's one of those things they won't do the work to make it easier Mar 02 00:54:21 requiring serial console for install sounds like not even remotely caring about the bbb to me Mar 02 00:54:36 was it really that hard for them to modprobe g_serial or something? Mar 02 00:56:18 which distro? Mar 02 00:56:25 oh, nix I guess from your nick Mar 02 00:56:27 openbsd Mar 02 00:56:33 or not Mar 02 00:57:06 openbsd... ok. yeah I've on rare occasion seen other people here that use it Mar 02 00:57:26 like, one or two I think in the years I've been here ;) Mar 02 00:57:33 You won't go wrong having a uart cable around, regardless. Hopefully you won't be forced to use it often, but some of us prefer the console that way because it's very hard to get locked out of it by misconfiguration. Mar 02 00:57:49 haha, yeah.. I guess there's not that many and they do admit their port is not complete Mar 02 00:58:14 yeah console can be handy sometimes Mar 02 00:58:56 my other choice was going to be alpine linux.. but they do not have writeable images at all.. just a generic, so I'd need to learn *everything* about uboot in one sitting to use it Mar 02 00:59:21 though when I needed to use it for more than a few commands (when I was messing with some networking stuff) I did put in a little effort to get it configured at 460800 baud instead of 115200 baud Mar 02 00:59:44 since, you'd never guess, this makes the console 4x as fast! ;P Mar 02 01:00:40 I like the idea of working with serial so long as I don't have to do everything myself lol. I mean, I can learn something about it later once I've got the basics :) Mar 02 01:02:50 meh, 9600 is plenty until you try to run something that updates the screen constantly like 'top'... Mar 02 01:03:00 vim Mar 02 01:03:13 with syntax highlighting enabled :P Mar 02 01:03:39 fair enough, I'd only have to run an installer by serial.. and I guess it will be handy for me if I can't be bothered to plug in hdmi or ethernet Mar 02 01:03:47 (yeah yeah, "ed is the standard text editor" :P ) Mar 02 01:05:41 hah, I guess ed does make sense over serial.. the only place I can think of that it does though ;) Mar 02 01:05:49 even then it doesn't Mar 02 01:06:09 vim is tolerable over 115200 and perfectly fine over 460800 Mar 02 01:06:20 One line at a time, why not.. but it can be replaced by cat <<< EOF Mar 02 01:08:07 under dos, "copy con" is probably my most-used command outside of dir/cd/type Mar 02 01:08:18 uphill both ways in the snow! Mar 02 01:31:35 Is there a pinout for using the ftdi cable.. or just plug it in with all pins? Mar 02 01:32:20 if you have the 6-pin one, then just plug it in. just mind the orientation: the black wire is pin 1, marked with a dot on the pcb Mar 02 01:32:30 the bone may or may not have useful silkscreening near those pins, but they're in the same order as on arduino pro minis and stuff, it's pretty standard Mar 02 01:32:45 that's worth making a label for and sticking it on the middle of the board Mar 02 01:33:34 well if you have a cable with 6-pin connector then labeling is kinda superfluous Mar 02 01:33:55 if it's the cable with the discrete dangly wires, it's worth either picking the contacts out and putting them into a fixed housing, or gluing the housings together, or making an adapter with a fixed end and semipermanently affixing the loose contacts to the other end of the adapter Mar 02 01:38:36 or just plugging them into the board and never unplugging them, but be aware of the "never-ever-EVER apply voltage, even weak uart signals, to the AM335x's pins while it is not itself powered", which means you'll be unplugging the USB end whenever you power the 'bone off Mar 02 01:39:01 myself: actually the serial console is the only exception to that rule Mar 02 01:39:19 it has an isolation buffer which is even 5v-tolerant Mar 02 01:39:41 oh, whoah! That's.... super good to know. Mar 02 01:40:12 if you could only safely connect the serial console *after* powering on the bbb, that would be rather annoying :) Mar 02 01:40:50 So unplug USB first, then power it off? Mar 02 01:41:08 nope, I was wrong, disregard my warning when dealing with the serial console Mar 02 01:41:17 still applies to gpio though Mar 02 01:41:21 ok, and plug usb/serial in before turning the board on? Mar 02 01:41:34 gpio is a little beyond my needs for this, so should be ok for now :) Mar 02 01:42:27 zmatt, thank you for pointing that out, it means the back-to-back 'watchdog' setup with two bbb's able to reboot each other and act as consoles for each other, gets dramatically simpler Mar 02 01:42:50 that sounds like a weird setup Mar 02 01:44:04 and it only makes it simpler if they only have to receive output from the other, since the only safe interconnection would be cross-connecting their serial consoles Mar 02 01:45:02 but why such a setup instead of just enabling the watchdog? Mar 02 01:45:05 So, I have a mild interest (and like, no clue when it comes to software so I'm trying to do little exercises to teach myself) in resilient and remotely-maintainable systems, stuff I can't lock myself out of, etc. Mar 02 01:45:55 A-side/B-side and STONITH setups as found in telecom, designing around single points of failure.. Mar 02 01:46:10 redundancy in software is always a good idea too Mar 02 01:46:28 at least when you know which parts are redundancy are not just unwanted extras Mar 02 01:46:29 and yes, a single node with a read-only boot device is a good start, but it's still only a single device Mar 02 01:47:11 never heard of STONITH before... funny enough wikipedia mentions "Single node systems use a comparable mechanism called a watchdog timer." Mar 02 01:47:17 like I said, just enable the watchdog :) Mar 02 01:48:35 lol... http://ourobengr.com/wp-uploads/2012/05/ha-deathmatch.png Mar 02 01:48:56 see also: mexican standoff! Mar 02 01:49:52 plus your setup can actually make things worse: "Unfortunately, it’s possible to wind up in a situation where each node believes the other to be broken; the first node shoots the second, then when the second reboots, it shoots the first, and so on, ad infinitum, until you realise that perhaps a single non-HA node would have been both cheaper and more reliable." Mar 02 01:50:35 oh for sure, there are fault mechanisms in any system, the goal is to make them occupy ever smaller parts of the probability tree, not larger Mar 02 01:51:52 The grand maybe-someday goal is to improve the state of hobbyist-accessible redundant systems, such that things like on-orbit rad-induced damage is considered survivable, and amateur satellites can stop being so stupid. (I have a few friends and family who've worked on small-sat projects, with 1 in orbit and 3 more in the works, and they all lament the state of the art.) Mar 02 01:54:28 isn't using off-the-shelf hardware in such an environment a recipe for fails anyway? at the very least you'd want something like ECC memory Mar 02 01:57:00 Yes and no. Yes, you'd want ECC, but no, running RCA 1802's isn't always the best route. Mar 02 01:58:24 this is getting pretty far off-topic, but the central idea behind some recent research is this: Modern commodity chips are so much faster than the rad-hard stuff, they can accomplish more while spending most of the time powered off, and actually be less vulnerable to bit flips because the duty cycle is so low. Use something simple like an 1802 to power them up and have 'em do the processing. Mar 02 01:59:20 which is another way of saying: rad-hard stuff would need so much more silicon area to handle the same workload, it's a more susceptible target despite being rated for the environment Mar 02 01:59:54 that's not saying remotely the same thing though Mar 02 02:00:56 area might be an argument in terms of how big a target it is, although I'd imagine it would be severely offset by sensitivity to impacts. your previous argument was however about limited on-time, which makes more sense to me (provided transients are a bigger concern than lifetime reduction due to cumulative damage) Mar 02 02:01:20 Current small-sats and amateur sats tend to follow the decades-old bent-pipe strategy, with as little intelligence as possible on the bird itself, and that restricts their applicability to a lot of interesting challenges. They've got to get smarter, and budgetary constraints mean it's worth considering things like cellphone SoCs over the kilobuck-per-chip industry standards Mar 02 02:04:10 both area and duty cycle play a role, but if you plot out the likelihood of bit-flips-per-megaflop or whatever, you get an arched curve that suggests either very-stupid or very-fast. And if you do bit-flips-per-megaflop-per-watt, the whole thing tilts in the direction of fast-and-small. Mar 02 02:04:58 because sunlight is free, but PV panels are heavy, and payload mass is money Mar 02 02:05:09 interesting Mar 02 02:08:02 yup, stupid satellites only make sense if your workload is also stupid. And I think the ecosystem has already explored most of the things that can be done with dopefish satellites. It's time to evolve. Mar 02 02:09:45 D. Radiodurans isn't impervious to radiation by having DNA that resists mutation, after all. Rather, it has more redundant copies of its DNA and actively repairs the damage even though it happens. So, there's some precedent for having more copies of things. I'm trying to conceptualize the transcriptase. ;) Mar 02 02:10:23 First step: Either node able to act as a serial console for the other. Second step: Either node able to xmodem-boot the other. Mar 02 02:11:15 Also it's trivial to optoisolate uart traffic, which isn't needed here but might open it up to other applications like totally separate power domains. Mar 02 02:15:22 opto is generally overkill Mar 02 02:15:34 just make sure the boards are grounded together and use a level shifter Mar 02 02:39:04 opto is useful for cases where ground connections are problematic (e.g. due to risk of ground-loops) Mar 02 02:44:07 or as a prelude to playing with fiber ;) Mar 02 02:44:22 for things like chamber feedthroughs, ROV umbilicals, etc. **** ENDING LOGGING AT Fri Mar 02 03:00:02 2018