**** BEGIN LOGGING AT Tue Nov 24 03:00:53 2015 Nov 24 03:23:37 hello? Nov 24 03:34:54 hello. Does anyone have experience with the public/private keys used to authenticate users logging into their BBB remotely? Nov 24 03:34:58 I Nov 24 03:35:44 I've been connecting to my BBB using PuTTY using user name and password, but would like to add a public key to the BBB. Nov 24 03:36:43 I've understood that this involves appending the public key to a file called authorized_keys, but I can't find that file anywhere on the BBB. Nov 24 03:36:52 I am using a debian OS on the BBB. Nov 24 03:46:00 https://help.ubuntu.com/community/SSH/OpenSSH/Keys Nov 24 03:46:08 same applies to debian Nov 24 03:47:36 http://www.cyberciti.biz/faq/how-to-set-up-ssh-keys-on-linux-unix/ Nov 24 03:49:59 I ran the command find / -name ".ssh" as root on the BBB and nothing came up. ... seems like I'm missing something obvious, but I can't find any .ssh directory. Nov 24 03:51:26 MattF: you create it in the user's homedir Nov 24 03:51:51 MattF: mkdir -p ~/.ssh ; chmod og-rwx ~/.ssh Nov 24 03:52:09 MattF: or mkdir -p ~SOMEUSERNAME/.ssh ; chmod og-rwx ~SOMEUSERNAME/.ssh Nov 24 03:53:24 another option is to create it as part of the user template directory in /etc/ I can't remember where it was (it's been 10 years since I've messed with the template directory in /etc) Nov 24 03:53:52 unless the user exists already then well vagrantc suggestions pretty much is it. Nov 24 03:56:19 ... interesting. I had assumed that the SSH server on the BBB had many of these directories in place. ... not the case. Nov 24 03:56:21 Thanks. Nov 24 03:57:09 you can configure sshd to look for keys elsehwere, but by default it looks in ~/.ssh Nov 24 04:00:32 Has anyone encountered issues using the Beaglebone PWM and ADC simultaneously? I am attempting to use the PRU's to drive a motor system and measure the output voltage. Individually the PWM and ADC with the PRU's work fine. Together though the ADC reading freezes on a value. Nov 24 04:16:49 MountainMan: that sounds really weird, there's no reason why those functions would interact in any way Nov 24 04:17:02 we do use them at the same time (not from PRU) Nov 24 04:24:09 Seeed-Studio people can program but not speak English. I am sure of it. AWS has their own images/firmware. Nov 24 04:24:31 Those two categories makes it impossible to get my .js file. Nov 24 04:25:10 I have one file to get to make things work but I cannot get it because I will not update the image on my BBG from AWS. Nov 24 04:25:46 Now...is there a way to get a clone to GitHub on my BBG without updating firmware from AWS? Nov 24 04:28:03 I should not have to update firmware/images to get a clone from Github.com, right? Nov 24 04:29:21 Oh and yes...aw! Nov 24 04:34:44 Simple and impossible... Nov 24 04:36:48 Anyone here have experience dealing with DDR mapping issues between Linux and PRUs? Nov 24 05:11:53 The .js file from AWS cannot be cloned. I have no more questions revolving around AWS and BBG. Sorry for the questioning on the BBG. Nov 24 05:17:22 I mean...sorry for the questions on AWS. Nov 24 05:48:41 Does anyone use CentOS for their BBB/BBG? Nov 24 06:20:29 Has anyone ever cloned what is offerend at /bone101 on Github.com to their BBB/BBG? Nov 24 06:22:58 offerend = offered Nov 24 06:24:10 by the way...do not use CentOS for your board. Debian rules! Nov 24 12:17:08 hi i need to find out how to auto boot micro sd ratber tban internal memory beagle board black rev c Nov 24 12:17:23 thanks in advance Nov 24 12:17:36 delete MLO from emmc Nov 24 12:17:40 then it will boot from sd card Nov 24 12:17:56 what is mlo Nov 24 12:18:51 the 1st stage boot loader file Nov 24 12:19:39 so plug it in via usb and look for that file Nov 24 12:24:41 sorry im just confused Nov 24 12:25:08 any instruction Nov 24 12:25:45 for how to delete the mlo Nov 24 12:26:01 https://www.google.com/search?q=beaglebond+delete+mlo Nov 24 12:26:28 https://www.google.com/search?q=beaglebone+always+boot+from+sd Nov 24 13:04:22 \o Nov 24 13:44:02 Hey guys, I was just checking out the BBG schematic and noticed some added capacitors on page 9 (ethernet). Are those to help solve the phy address fluctuation issue? Nov 24 18:27:52 abferm: pretty annoying there's no diff between the BBB and BBG with motivation for the changes Nov 24 18:29:37 but the only added caps I see are actually labeled "EMI", so it seems pretty clear what their purpose is Nov 24 18:32:08 the BBG does not seem to make any attempt at fixing any of the known hardware issues of the BBB Nov 24 18:32:54 it basically just adds some different connectors? Nov 24 18:34:00 and removed hdmi and the 5V DC barrel jack, and made some changes apparently out of EMI concerns Nov 24 18:34:26 including replacing the main oscillator (which is the processor's only source for accurate timing) by a spread-spectrum clock generator Nov 24 18:34:29 -.- Nov 24 18:36:19 but it uses a more traditional circuitboard color scheme. Nov 24 18:36:42 yes, the pcb color is another major change ;P Nov 24 18:38:09 barrel jack seemed to be the only reliable source for power Nov 24 18:44:31 I wonder how well the PLLs are able to get rid of the frequency-spreading introduced by the spread-spectrum clock generator Nov 24 18:50:26 abferm: I don't think the PHY issues can be fixed with a cap, although it's hard to say since the problem has afaik never been fully determined Nov 24 18:50:44 but iirc some people who had the problem constantly managed to resolve it by *removing* caps Nov 24 18:53:05 but it's lose-lose either way, I think to fix it properly you'd either need a reset-extender (a real one, not an RC circuit acting as one), or use a GPIO to reset the PHY, or ditch a PHY in favor of one that's less fussy Nov 24 18:53:32 *ditch the PHY Nov 24 19:15:30 Can anyone point me in the direction of information on how to load information from the running device tree into a kernel module? I'm working on a module for a device and want the gpio used and several other things to be specified in the device tree to make the module itself more portable. Nov 24 19:21:00 use the openfirmware interface Nov 24 19:42:56 abferm: just look around for examples in existing drivers Nov 24 19:43:05 for example the spi core supports using gpios for chip selects Nov 24 19:44:57 of_gpio_named_count Nov 24 19:45:00 of_get_named_gpio Nov 24 19:45:15 that looks like what you're looking for Nov 24 22:17:38 Does anyone know why a running motor may interfere with the beaglebone's adc? Even if they are not connected? Nov 24 22:24:36 I asked a related question the other day with no results. I am trying to use the beaglebone to drive a motor system and the adc to read output voltage. For some reason the ADC lock up whenever the motors are actually running Nov 24 22:27:09 define lock up? Nov 24 22:27:21 attempts to access the ADC registers hangs forever? or? Nov 24 22:34:30 I am not sure. It will basically hold the first value it reads permanently and will not update. Closing and rerunning the program causes it to hand permanently requiring force quit and eventually a reboot. Nov 24 22:34:44 *hang Nov 24 22:37:48 your secondary problem is likely your program is blocking access to the aDC and running it a second time its waiting for the adc to be 'free' and it never gets it .. requiring a hard reset Nov 24 22:38:09 whether that relates to your primary problem I couldn't be sure Nov 24 22:38:51 Hello all. Nov 24 22:40:44 I think that is possible but it only seems to occur when the ADC has frozen. I.E. if I run the program without the motors running and attach the adc to a trim pot fed by VDD_ADC, i have no issue. When I re-run it I get a memory warning but it still runs. It is only one I try to run the motors that it happens. Nov 24 22:41:49 hmm and what does that memory warning say? Nov 24 22:41:51 hmm? Nov 24 22:41:56 are you not writing a proper driver? Nov 24 22:42:05 or you trying to screw with it in userland? Nov 24 22:42:51 initialisation failed (out of memory) Nov 24 22:43:21 but then it stil runs and the adc works fine. Nov 24 22:46:40 nice. Nov 24 22:46:45 that probably ain't 'good'. Nov 24 22:49:38 write a proper driver. Nov 24 22:49:58 I am using the tester image debian 8.2 using Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l GNU/Linux kernel. I have removed all device overlays so my slots are empty and then I am trying to enable specifically P9_18 into mode 0x22 but this always stays in 0x37, Nov 24 22:50:06 other then noise issues, the ADC works just fine. Nov 24 22:50:18 true. But what I cant figure out is why the adc breaks when the motors run. The memory issue I believe is because my exit and clean up doesnt clean up the PRU properly. Nov 24 22:50:22 I have it sampling at 8KHz without data drop. Nov 24 22:50:27 no PRU Nov 24 22:50:34 I am new to overlays but was curious if anyone saw something I was overlooking. Nov 24 22:51:55 I can use the ADC fine in every other application except when the motors are actually running. Nov 24 23:03:30 as a follow up all the pins are labeled UNCLAIMED as well. Nov 24 23:03:51 so I am not sure what might be prohibiting changing the gpio mode on this pin. Nov 24 23:16:30 ril3y .. permissions? Nov 24 23:20:16 ds2: only 8 kHz ? why so little? Nov 24 23:21:03 zmatt : shhh. :p Nov 24 23:21:18 apart from making aforementioned noise issues worse, it should not be a problem to run the ADC at its max speed if you use DMA Nov 24 23:21:51 (I know because I did do while "screwing from userspace" :P ) Nov 24 23:24:58 ril3y: the pinmux you mean, not "gpio mode" (gpio is one particular pinmux option) Nov 24 23:25:08 pfft Nov 24 23:28:42 veremit: btw, next time anyone has any pinmux-related question, don't forget to point to http://gerbil.xs4all.nl/show-pins-v2.pl.gz Nov 24 23:30:15 zmatt: ->elinux Nov 24 23:30:38 :) Nov 24 23:30:52 veremit: feel free :) I'm currently checking where rcn-ee put it (it should be included with the latest testing images) Nov 24 23:32:10 zmatt.. did he escape from here again?! lol Nov 24 23:32:29 ? Nov 24 23:32:37 RN .. nvm. Nov 24 23:33:08 bbiaf ..need to take a break Nov 24 23:35:35 zmatt: is that pinmux info different from : https://github.com/bradfa/beaglebone_pinmux_tables Nov 24 23:37:50 wmat: looks like a number of differences yes; the table in my script is based on my spreadsheet, includes all pins (though only pins on P8/P9 are shown by default, passing -v once shows more pins, twice shows all pins) Nov 24 23:38:08 wmat: I also hide unusable pin functions Nov 24 23:39:18 zmatt: thx Nov 24 23:40:14 and some naming/numbering differences (e.g. I use 0-based indexing for everything, while the TRM uses it for almost everything in this device except notably the (r/rg)mii interfaces (but it can be completely different on other devices, e.g. the am572x uses 1-based for many things but notably *not* the (r/rg)mii interfaces) Nov 24 23:40:19 ) Nov 24 23:41:37 I generally also omit prefixes/suffixes that stand for "enhanced" or some other such "omg this version is badass shit" decorations Nov 24 23:45:37 zmatt: voice recogonition app I was using wanted 8KHz audio Nov 24 23:45:57 8KHz is a telco standard for voice Nov 24 23:48:57 ds2: fair enough :) Nov 24 23:49:15 and yes, I have verified it for drops Nov 24 23:49:25 sine wave in, gnuplot on the data out :D Nov 24 23:49:43 there's also this "fifo overrun" bit/irq you now :P Nov 24 23:50:32 wmat: the spreadsheet I'm referring to is this one btw -> https://goo.gl/Jkcg0w Nov 24 23:52:45 nice Nov 24 23:53:13 orange tabs are the BBB-specific ones Nov 24 23:55:36 apologies for the eye-stabbing purple, I just wanted to make sure the special nature of certain pins would not be overlooked :P Nov 24 23:59:48 zmatt: this device supports mDDR? Nov 25 00:00:11 ds2: subarctic does yes Nov 25 00:01:11 * ds2 looks at docs Nov 25 00:01:22 mDDR/DDR2/DDR3 Nov 25 00:02:06 /DDR3L Nov 25 00:02:29 there was something not supported on am335 that was on the dm37x Nov 25 00:04:52 plenty of things, but w.r.t. memory that would be mSDR Nov 25 00:05:00 that and 32-bit wide memory Nov 25 00:06:37 ah 32 vs 16 must have been it Nov 25 00:12:26 yeah the 16-bit is a bit meh, then again it supports mDDR-400 / DDR2-533 / DDR3-800 versus the mDDR-266 of the dm37xx Nov 25 00:23:22 wonder if a 2 layer am335x design is doable at all Nov 25 00:35:44 2 signal layers you mean? Nov 25 00:36:50 no, 2L Nov 25 00:37:01 well, not without violating every layout rule in the datasheet Nov 25 00:37:08 sigh Nov 25 00:37:25 4L flex is a pain... a Beagle like board on flex would be useful Nov 25 00:37:50 a lot of those rules will have to be worked out again for flex... think a lot of them assume FR4 Nov 25 00:38:13 depend also on how many interfaces you're willing to sacrifice to make room I guess Nov 25 00:38:44 let's say something that can start up u-boot (min. serial out + ram) Nov 25 00:39:19 so you'd have a signal layer on top and a power/ground plane on bottom... Nov 25 00:39:37 or sacrafice a dedicated power/gnd layer Nov 25 00:39:45 that sounds like a very bad idea Nov 25 00:40:04 even for the lowest OPP? Nov 25 00:41:16 well tbh, if you're going to throw everything out the window you basically would need to do full simulation anyway, or be really good at guesswork and pray Nov 25 00:42:07 that would raise the question of how accurate are the models Nov 25 00:42:37 set all slews to "slow" instead of the datasheet-recommended "fast" since you wouldn't have a ground plane for return currents of sharp transients Nov 25 00:43:44 that's all fine once I get control... does the ROM cooperate? Nov 25 00:44:15 you could use a small NOR flash and "fast xip boot" Nov 25 00:44:24 that gets you control very very early Nov 25 00:44:34 ROM doesn't run in XIP mode? Nov 25 00:45:09 or are you implying that ROM is less likely to do something bad if XIP is selected Nov 25 00:45:38 high-speed transfers Nov 25 00:45:43 over external interfaces Nov 25 00:46:12 i was thinking UART boot is safer Nov 25 00:46:52 you're really not in a hurry to boot the system then are you? ;) but actually, "fast xip" mode transfers control before PLLs are setup iirc Nov 25 00:47:12 while uart boot will already have the PLLs setup at opp100 Nov 25 00:47:15 nope Nov 25 00:47:19 proof of concept Nov 25 00:48:12 the other half of it is flex doesn't really do that well with fine traces Nov 25 00:48:23 so breaking out a parallel bus for NOR can get troublesome Nov 25 00:49:34 I just realized that the thinness of flex probably also means a ground plane is troublesome anyway.... what kind of single-ended impedance are we looking at? Nov 25 00:49:55 a lot of those rules will have to be worked out again for flex... think Nov 25 00:49:55 +a lot of them assume FR4 Nov 25 00:50:01 :D Nov 25 00:50:24 i suspect it can vary quite a bit depending on thickness of the kapton Nov 25 00:51:37 yes, you'd need to know the thickness of kapton, width and thickness of the trace, and relevant constants of kapton instead of fr4 Nov 25 00:52:14 fill those in in one of the many online calculators for microstrip impedance Nov 25 00:52:19 *nod* was more of referring to a wider variation of available thicknesses then FR4 Nov 25 00:52:30 not just to the physical requirements that drive impedences Nov 25 01:02:44 ds2: http://pastebin.com/nm6jUMAV this illustrates what's special about fast external xip boot Nov 25 01:04:01 ah Nov 25 01:04:18 know off hand if it will work with an 8bit ROM? Nov 25 01:04:54 I think so, lemme check the disassembly (no I don't trust the TRM :P ) Nov 25 01:14:25 that's odd... http://pastebin.com/QZruZHhM Nov 25 01:15:34 Are you C-ifying dissassembled code? Nov 25 01:15:37 yes Nov 25 01:16:02 I said that right before I saw goto 0x80000000; XD Nov 25 01:16:08 Wouldn't have asked otherwise Nov 25 01:16:26 yeah I was too lazy to write a proper cast for that Nov 25 01:16:36 It's fine, the meaning is understood Nov 25 01:18:53 ohhhh wait a minute, that's why the gpmc config function is so tiny... various options are passed straight from sysboot pins to internal hw strapping options of the gpmc module that it uses to initialize its config regs during reset Nov 25 01:19:13 that means yes, you can use any of the modes supported by gpmc Nov 25 01:19:37 bootrom just programs the timing, which I'll check Nov 25 01:28:47 where are you disassembling it from? Nov 25 01:29:18 thought it is protected on exit from ROM Nov 25 01:33:01 lol, this is really nicely done... http://pastebin.com/jfTFM6vy Nov 25 01:33:12 no, public rom is readable Nov 25 01:33:58 I also have a full disassembly of dm814x secrom where they blocked access to only one of the two aliases in memory ;) Nov 25 01:35:01 anyhow, it's evidently using the reset defaults of gpmc Nov 25 01:35:03 heh "oops" Nov 25 01:35:31 it's a terrible mess though Nov 25 01:35:36 both pubrom and secrom Nov 25 01:35:50 so it boils down to breaking out about 30 traces or booting with a UART Nov 25 01:35:56 30 traces? Nov 25 01:36:50 hmm, I suppose an external flash wouldn't support A/A/D multiplexed mode? Nov 25 01:37:19 or 16-bit A/D ? Nov 25 01:38:08 I can also check to see where that other "goto" from fastext_init() is going to Nov 25 01:38:25 because it seems it might support fastext from NAND flash provided it supports internal ECC Nov 25 01:38:35 (or you lie and claim it does and hope for the best) Nov 25 01:39:35 I never got around to implementing ECC support in my dm814x codebase and haven't got a single read error yet, ever Nov 25 01:41:08 hmm, nm, sysboot9 seems to do something different in the context of fastext boot Nov 25 01:42:36 ah it seems to enable wait Nov 25 01:43:04 so you could even feed it data with a uC or something silly like that (then again, you probably could even without wait) Nov 25 01:44:26 16A, 8D Nov 25 01:44:28 + control Nov 25 01:44:48 non-multiplexed mode? is that really unavoidable? Nov 25 01:44:56 well, maybe just 2 control... no need for R Nov 25 01:45:24 is mux mode NOR's easily sourceable thesedays Nov 25 01:45:36 it would trade 8 lines for an ALE Nov 25 01:45:57 but if mux mode is available, 16bit roms look attractive :D Nov 25 01:51:44 So I am having trouble with the ADC. I am using PWM to drive a motor system and the ADC to get the output voltage. I am using the PRU's. When I run the program the ADC will freeze on the last value it read and lock up requiring reboot. It only occurs it seems when the motors are running. I though it was emi from the motors so I moved them as far away as I could and still the issue persists. Does anyone have any thoughts? Nov 25 02:00:32 back... laptop decided to randomly crash Nov 25 02:00:45 ds2: then again, maybe looking at fastext is premature Nov 25 02:04:48 ds2: having fewer wires (i.e. spi flash) would probably be preferred; the big question is whether you can hook up the power supplies and provide adequate decoupling Nov 25 02:05:27 and for all interfaces you'd need to look at what's going to happen w.r.t. return currents if you lack a ground plane Nov 25 02:06:51 if you keep enough distance in all directions you may even be able to retain a high impedance and avoid significant currents entirely (woo, power savings) Nov 25 02:07:14 assuming the energy isn't turned into EMI instead, dunno about that :P Nov 25 02:10:08 ds2: oh, flex doesn't allow components on both sides... so you're looking at rigid-flex anyway Nov 25 02:10:28 Would emi at different part of the board cause issues across the entire board? I.e. EMI from the motors closer to P9_01 causing issues along the header towards P9_36? Nov 25 02:10:36 Mountainman: that Nov 25 02:10:42 Mountainman: that's really hard to say I think Nov 25 02:10:46 in general statements Nov 25 02:12:18 what kind of protection do you have on the ADC inputs? Nov 25 02:12:42 I just have no idea what the issue is and its driving me crazy.... it even happens if just attach the adc pins to a trim pot on a separate board. But only when the motors are running. Nov 25 02:13:39 then it sounds more like a software issue Nov 25 02:14:01 Voltage divider and a diode. But the fact that it still happens even when the only source is VDD_ADC seems counter the idea of the adc getting messed up. Nov 25 02:14:35 And if it was purely software why would it work flawlessly so long as the motors arent running? Nov 25 02:14:58 Is loki just messing with me right now? Nov 25 02:15:03 probably Nov 25 02:15:05 :) Nov 25 02:15:24 the software does not have any different control flow if the motors are running? Nov 25 02:16:07 no. Literally all I do it pull the wire feeding Vcc to the motor controller and run the same program. Nov 25 02:17:01 Do you have Pololu Motor controllers? Nov 25 02:17:32 no just a custom setup with a lm298n Nov 25 02:17:39 Oh. Nov 25 02:18:07 I had to use software and additional battery support for my BBB when making my bot go and stop. Nov 25 02:18:09 Mountainman: if the program is unaware that the motors aren't running but the fact they're not running fixes the problem, then I would say we're back at electrical issues Nov 25 02:18:10 zmatt: I think I have seen flex with dual side load Nov 25 02:18:25 but I am more worried about getting thinenough traces to break things out Nov 25 02:18:54 hey Mountain, did you do the math on everything? Nov 25 02:19:28 ds2: what about rigid-flex? lol, look at the funky thing at topleft of page 7 -> http://www.minco.com/Flex-Circuits/~/media/WWW/Resource%20Library/Flex/Minco_FullFlexDesignGuide.ashx Nov 25 02:19:42 Set: yes, as much as I could. What in particular are you thinking Nov 25 02:20:23 I just know from my notes, oh and I am not a memory wiz on engineering, that particular math is needed to make everything add up. Nov 25 02:20:35 I am just saying that it may be a math conern. Nov 25 02:20:44 conern = cocern Nov 25 02:20:53 nevermind. Nov 25 02:21:14 Let me get my notes. Nov 25 02:21:21 Hold please. Nov 25 02:21:27 zmatt: that stuff is a bankruptcy inducing cost Nov 25 02:21:32 okay. Nov 25 02:21:35 ds2: hehehehe Nov 25 02:21:44 it looks really cool though Nov 25 02:21:48 and there are very irritating rules - feature size is worse of rigid and flex Nov 25 02:21:59 looked into that for another project Nov 25 02:22:32 yeah I see the "cost multiplier" thing Nov 25 02:22:44 I'd think getting proper decoupling caps in there is going to be painful Nov 25 02:22:52 yet essential Nov 25 02:23:16 maybe the experiment should be - boot MLO with a AM3359 setup deadbug style Nov 25 02:23:22 using the UART of course Nov 25 02:23:27 the book is called Circuits: 2nd Edition. Nov 25 02:24:01 ds2: "deadbug style" ? Nov 25 02:24:06 Now Mountain, please tell me what you believe is the problem. I am sure I have some notes on it. Nov 25 02:24:24 I will scroll through the pages and look it up. Nov 25 02:24:25 chip with balls facing up and 30G or smaller wires going to the balls Nov 25 02:24:39 Cool! Nov 25 02:25:17 Mountainman: have you put a scope probe on the lines to see whether horrible crud is perhaps being induced on the traces going to the motor circuit Nov 25 02:25:26 Now...is it amplification, analog to digital conversion, and etc... Nov 25 02:25:27 ? Nov 25 02:25:49 (never mind why crud on the motor lines might lock up the ADC, electrical noise works in mysterious ways) Nov 25 02:25:51 Set: I dont know what the problem is, hence the reason I am asking everyone and the mother about it lol, I think it has something to do with the emi of the motors as the issue only seems to occur when the motors are running. If knew what the problem was I could pretty easily do the engineering to fix it i think Nov 25 02:26:00 the ADC block is a sensitive block Nov 25 02:26:23 ds2: yeah but he has the probs apparently even if no connection is going from ADC to the motor circuit Nov 25 02:26:23 dump the error registers in the ADC block Nov 25 02:26:31 Okay...sorry. I will go back to the notes. Nov 25 02:26:39 the error was bus lockup I think Nov 25 02:26:43 Be back in a jiff. Nov 25 02:26:44 iirc Nov 25 02:26:46 ask the ADC what does it think it is doing. there has to eb a reason the state machine stopped iterating Nov 25 02:26:58 there is a bus lock up bit? Nov 25 02:27:13 yeah, it's called "watchdog reset" :P Nov 25 02:27:14 zmat: I dont have one unfortunately. Nov 25 02:27:21 :P Nov 25 02:27:29 Do you know Ohm's law and how to calculate resistance? Nov 25 02:27:41 * zmatt gags Set_ Nov 25 02:27:44 It could be simple math like that... Nov 25 02:27:46 What? Nov 25 02:28:17 Oops. Nov 25 02:28:19 Set: yes..... it isnt that. Unless the current tolerance of the pins is < 0.001nA Nov 25 02:28:21 I got my deal wrong. Nov 25 02:28:26 Okay. Nov 25 02:28:39 Mountain...I am going back to the book. Nov 25 02:29:12 How do I dump error registers of ADC, my knowledge of the BB subsystems is a little weak. I am using libpruio library and functions. Nov 25 02:29:48 Mountainman: so just to verify: if you leave the ADC unconnected (or better yet, tie its signals to ground or vdd_adc with short wires or resistors), and have the program running, it locks up on adc reads if the motor controller is actually powered but works fine if the motor controller is off (and the program is unaware of this fact) Nov 25 02:29:59 btw, is the motor controller okay with getting pwm signals if it's not powered? Nov 25 02:30:04 most chips aren't Nov 25 02:30:33 zmatt: yes Nov 25 02:30:45 to both. Nov 25 02:30:47 ok Nov 25 02:31:36 what is the ADC reporting? Nov 25 02:31:40 position or? Nov 25 02:31:43 I'd say try additional ESD/EMI protection on the motor control wires, close to the BBB Nov 25 02:31:53 ds2: well, if not connected then it's not reporting anything Nov 25 02:32:08 fair enough Nov 25 02:32:22 going with your reasoning, why not optically isolate the motor? Nov 25 02:32:32 easier then dealing with EMI stuff Nov 25 02:32:43 assuming Mountainman has the relevant components Nov 25 02:32:52 LDR + LED? :D Nov 25 02:32:57 optically isolate? Nov 25 02:33:06 look up "optoisolator" Nov 25 02:33:41 Mountainman: just checking... are the ground planes of the BBB and your motor controller thoroughly connected? Nov 25 02:34:48 zmatt: I mean they should be. All the pins ground pins are tied back together and tied to the ground on the beaglebone Nov 25 02:35:18 "all the ground pins" ... by any chance, would that be a ground pin per control signal? Nov 25 02:36:03 if so, just for fun, try running a twisted pair per signal (one wire for ground, one for the actual signal) Nov 25 02:36:36 basically to keep the BBB -> signal -> controller -> ground -> BBB loop as small as possible Nov 25 02:38:03 normally you'd run a signal trace over a ground plane for that, but when running a cable the alternative is to keep a ground wire close to the signal at all times Nov 25 02:38:08 just go optical Nov 25 02:38:13 or that Nov 25 02:38:30 except that's not gonna solve the problem once he attaches the ADC again Nov 25 02:38:36 why not? Nov 25 02:38:58 because it would probably pick up the same crap? Nov 25 02:39:16 why would it? Nov 25 02:39:26 depends on the overall design I guess Nov 25 02:39:32 when I say optical, I mean both PWM optical out and Optical back to the ADC Nov 25 02:39:46 So provide additional ground wires? I am not sure I understand. I have main power, a voltage regulator, the motor driver, and an amplifier whose grounds are all connected to the same pin which leads back to the beaglebones ground. Everything takes power from the same source. The BB provides PWM, 3.3V, 5V, Nov 25 02:40:07 Mountainman: it's not specifically about the amount of ground wires Nov 25 02:40:15 problem with keeping galvanic connections is all sorts of non ideal behaviors can appear Nov 25 02:40:17 but the distance between signal and ground wires Nov 25 02:40:29 ahhh Nov 25 02:40:33 you can into impedences of your connections and such Nov 25 02:40:37 ds2: optical back to the adc? care to elaborate? Nov 25 02:40:59 zmatt: simpliest - have the motor drive a LED and wire up the ADC to a LDR in a divider config. Nov 25 02:41:11 s/motor/motor signal/ Nov 25 02:42:27 * zmatt glares Nov 25 02:42:44 they make packaged optoisolators like those Nov 25 02:42:55 or a phototransistor inplace of the LDR Nov 25 02:43:07 I dont think I can reduce distance anymore than I already am. The only wires near the motor system are the motors +/- leads and the PWM signal. Nov 25 02:43:38 Mountainman: are you running wires directly from the motor to the BBB? Nov 25 02:43:44 You need a power source for the motor drivers and the bbb. Nov 25 02:43:50 separate. Nov 25 02:43:56 apart from the bias voltage you'll need to keep the led on at all, isn't this going to be wildly non-linear and need careful calibration (and sacrifice more of the already shitty resolution of the adc) Nov 25 02:44:01 Mountainman: wait what? Nov 25 02:44:14 Mountainman: you're not powering the motor from the BBB's 5V are you? Nov 25 02:44:19 if so, try putting a buffer (say a BJT) in between there Nov 25 02:44:46 zmatt: sure, with the LDR... a phototransistor isn't that bad over a reasonable range Nov 25 02:44:53 I had to use a power source for each motor controller and for the BBB. Nov 25 02:45:00 there are plenty of simple linear optoisolators Nov 25 02:45:19 even some non opto, "opto" isolators Nov 25 02:45:20 Mountainman: also, I would hope the motor's - signal is separate from the signal ground for the pwm signals Nov 25 02:45:45 No no. Motor driver requires 5v to turn it on. Motors and all peripherals are powered from a separate UPS system. Wires are run to a board where voltage dividers and diodes are used to lower voltage and current to acceptable levels and protect pins Nov 25 02:46:17 I had three power sources for the bot. The bot only had two wheels, two motor controllers, and one BBB. Nov 25 02:46:35 Mountainman: have any doc/spec of the motor controller? Nov 25 02:47:01 its an lm298N pretty common dual full bridge. Nov 25 02:47:24 http://www.st.com/web/en/resource/technical/document/datasheet/CD00000240.pdf Nov 25 02:48:35 "vss" for a supply pin, interesting terminology Nov 25 02:48:56 Also what do you mean by "the motors signal is separate from the signal ground for the pwm signals" Nov 25 02:49:14 - supply I mean, but never mind that Nov 25 02:49:47 actually do mind that Nov 25 02:50:01 but then don't, since you already mentioned the motors are supplied separately Nov 25 02:50:01 :P Nov 25 02:50:10 lol okay Nov 25 02:50:21 put it on a fast scope Nov 25 02:50:25 bbl Nov 25 02:50:27 ds2: no scope, he mentioned that Nov 25 02:51:25 is there a cheap at home scope I can buy? Most I see are pretty expensive.... Nov 25 02:52:33 Also i just ran the program for 20 minutes with no power and I had no issue. So I think it is definitely electrical. Nov 25 02:53:51 If someone was to check the voltage with a battery tester, could you connect alligator clips/wires to test the terminals and things? Nov 25 02:54:14 I ask because I have seen people rig those. Nov 25 02:54:29 yes? Nov 25 02:54:36 But there needs to be a power source. Nov 25 02:54:36 Mountainman: the BBB pwm signals are probably connected directly to the motor controller? Nov 25 02:55:34 yes? Nov 25 02:55:54 Should they not be? Nov 25 02:56:01 Mountainman: yes they probably should Nov 25 02:56:22 okay good. Nov 25 02:56:50 How many wheels do you have/motors? Nov 25 02:57:03 ok, my main concern would be that the example diagram happily conflates the ground for the motor outputs (connected to the series resistors) with the signal ground for the inputs Nov 25 02:57:16 that feels like a bad idea Nov 25 02:57:52 Mountainman: any idea how much peak current those motors are drawing? Nov 25 02:58:24 also, are you actually using the same ground, or are you using separate grounds ? Nov 25 02:59:28 this datasheet is confusing Nov 25 03:00:11 2 motors coupled at the shaft. So only one being driven. Peak current idk i can check in a minute though. A decent amount though I would imagine as it is the reason I bought the lm298n. I was originally just using a bjt and it was burning out.... **** ENDING LOGGING AT Wed Nov 25 03:00:53 2015