**** BEGIN LOGGING AT Thu Jun 29 03:00:02 2017
Jun 29 11:56:35 <vicky> hello
Jun 29 11:58:30 <vicky> i am getting a " WRONG ELFCLASS : ELFCLASS64ERROR" error message
Jun 29 11:59:31 <metona> i all.
Jun 29 11:59:34 <metona> hi all
Jun 29 12:00:03 <metona> have a simple question about beaglebon eblack split video as side by side that is used same as vr head sets.
Jun 29 12:00:11 <metona> is it possible?
Jun 29 14:39:11 <carbon-cabron> hi
Jun 29 14:53:58 <carbon-cabron> hello, i am currently trying out the examples from the robotics cape installer that came preinstalled on my Beaglebone Blue. I can see see the binaries of the examples in /usr/bin/ directory. My question is if i run these binaries, do they get executed in the PRU, or do i have to load the compiled programs in the PRU smehow and how do i do that?
Jun 29 14:54:01 <carbon-cabron> many thanks
Jun 29 14:57:55 <tbr> there is a kernel interface to the PRU. If anything runs on it the software would be talking to that.
Jun 29 14:58:53 <zmatt> well, there are two kernel interfaces to PRU actually :P
Jun 29 15:00:11 <tbr> and then there's always /dev/mem
Jun 29 15:00:18 <carbon-cabron> yes
Jun 29 15:00:32 <carbon-cabron> i found out obout /dev/mem
Jun 29 15:01:04 <carbon-cabron> but where do i get the info of the shared adresses in the memory
Jun 29 15:01:07 <tbr> then you also found out that you should NOT use it?
Jun 29 15:01:17 <zmatt> using /dev/mem is typically last resort
Jun 29 15:01:30 <carbon-cabron> i am not usin anything
Jun 29 15:01:58 <carbon-cabron> i just saw that the initialization code gets a piece of memory with the mmap function
Jun 29 15:02:24 <zmatt> which initialization code?
Jun 29 15:03:10 <carbon-cabron> Robotics_Cape_Installer/libraries/mmap/rc_mmap_gpio_adc.c
Jun 29 15:03:18 <carbon-cabron> init_mmap() method
Jun 29 15:04:22 <carbon-cabron> it is in the StrawsonDesigns' Robotic_Cape_Installer repo on github
Jun 29 15:04:27 <zmatt> yeah found it, https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/libraries/mmap/rc_mmap_gpio_adc.c
Jun 29 15:04:31 <zmatt> ew
Jun 29 15:05:40 <zmatt> doing manual PRCM overrides via /dev/mem is really bad and wrong
Jun 29 15:05:53 <zmatt> and can result in confusing the kernel
Jun 29 15:06:00 <zmatt> they should have used sysfs for that
Jun 29 15:06:53 <carbon-cabron> dunno,  i am really confused about all this PRU and remoteproc stuff
Jun 29 15:07:02 <zmatt> none of this stuff is pru-related
Jun 29 15:07:13 <carbon-cabron> i just need a real time piece of hardware
Jun 29 15:07:28 <carbon-cabron> ok many thanks for that zmatt
Jun 29 15:07:44 <carbon-cabron> so this has nothing to do with the PRUs??
Jun 29 15:07:47 <zmatt> nope
Jun 29 15:07:57 <zmatt> they're just accessing gpio and the ADC from linux userspace
Jun 29 15:08:53 <zmatt> (and the way in which they're doing it should not be viewed as a good example)
Jun 29 15:11:33 <carbon-cabron> ok, so this is not deterministic
Jun 29 15:14:05 <zmatt> linux userspace code can be reasonably real-time if they're using an RT kernel and setup thread priorities right and are careful in which kernel facilities are used in the threads with real-time needs...
Jun 29 15:14:19 <zmatt> but nowhere near the sort of guarantees that pru provides
Jun 29 15:15:43 <carbon-cabron> i read some stuff regarding the PREEMPT_RT patch and xenoamai kernel but figured out that PRU would best fit my needs
Jun 29 15:16:27 <zmatt> although PRU isn't *fully* deterministic anymore if it accesses resources outside the PRU subsystem, such as the ADC
Jun 29 15:17:05 <zmatt> (but resulting jitter is probably still a small fraction of a microsecond)
Jun 29 15:17:33 <carbon-cabron> i wasnt able to find anything about the PRU programming so far. I tried out the hands on labs tutorials provided by Texas instruments, but the CCSv7 crashes on ubuntu 16.04
Jun 29 15:18:00 <zmatt> there's definitely a lack of good up-to-date resources
Jun 29 15:18:13 <carbon-cabron> do you know any methods perhaps on how to do the PRU programming
Jun 29 15:18:15 <carbon-cabron> ?
Jun 29 15:18:28 <carbon-cabron> any literatture or good examples
Jun 29 15:19:01 <carbon-cabron> i would really appreciate if u could point me in the right direction
Jun 29 15:19:25 <zmatt> I know how to do it, but I'm not sure where you can find good docs or examples... I've actually recently started looking into making some tools and examples myself, but I've only just started
Jun 29 15:20:04 <zmatt> first thing to know is that there are two quite different mechanisms to use pru: uio-pruss and remoteproc-pru
Jun 29 15:21:16 <zmatt> remoteproc-pru is more recent, but as far as I can tell more cumbersome and annoying to use. apparently it has its fans though. I don't know much details about using it
Jun 29 15:23:41 <zmatt> uio-pruss is a kernel mechanism that basically just lets userspace mmap() pruss and let it figure it out from there (similar to /dev/mem, except the kernel handles PRCM for you).  it also assists in delivering irqs from pruss to linux userspace, and it can allocate some shared piece of external (DDR3) memory if you need it
Jun 29 15:25:49 <zmatt> beware that reading DDR3 memory is quite slow and non-deterministic, and should only be used if the on-chip SRAM is insufficient.  it can be used however for example to get a large stream of data from pruss to linux (see e.g. BeagleLogic)
Jun 29 15:27:18 <zmatt> a (crappily written, but working) library for use with uio-pruss, along with examples, can be found at https://github.com/beagleboard/am335x_pru_package
Jun 29 15:28:12 <zmatt> there's also some docs there, partially overlapping with the PRUSS chapter of the AM335x Technical Reference Manual (although both contains bits of info not found in the other)
Jun 29 15:28:46 <zmatt> (this is hardware docs, not really docs on how to use uio_pruss)
Jun 29 15:29:09 <zmatt> afk for a bit
Jun 29 15:31:33 <zmatt> oh, one last bit of info you'll need: there should be two lines (one of them commented out) in /boot/uEnv.txt that decide whether uio-pruss or remoteproc-uio is enabled.  if you want to switch you'll need to comment one and uncomment the other and reboot
Jun 29 15:32:08 <zmatt> also be sure to use the latest 4.4-ti, 4.9-ti, or 4.9-bone kernel
Jun 29 15:32:16 <carbon-cabron> ok, i saw that in another repo
Jun 29 15:32:25 <carbon-cabron> how to use the remoteproc
Jun 29 15:32:31 <carbon-cabron> but again without luck
Jun 29 15:33:00 <zmatt> I can't really help you with remoteproc problems, I just don't know enough about it
Jun 29 15:33:13 <zmatt> I know uio-pruss works, I have it working
Jun 29 15:35:15 <carbon-cabron> found it, there is dinuxbg's pru-gcc-examples repo on github
Jun 29 15:35:27 <carbon-cabron> and he mentions two ways
Jun 29 15:35:31 <carbon-cabron> just like u said
Jun 29 15:37:49 <zmatt> and when using a recent system (such as one of the latest images available from http://elinux.org/Beagleboard:BeagleBoneBlack_Debian ), don't follow any instructions that involve overlays or bone_capemgr; those instructions are basically obsolete
Jun 29 15:38:11 <zmatt> afaik the aforementioned two lines in /boot/uEnv.txt should be all that's needed
Jun 29 15:38:17 <zmatt> really afk now
Jun 29 15:40:56 <carbon-cabron> thabjs zmatt
Jun 29 15:41:03 <carbon-cabron> thanks*
Jun 29 16:46:03 <minhui> hi
Jun 29 16:46:10 <minhui> hi everyone. I'm new to BBBW. Now I'm testing the power consuming of wifi module of BBBW. So I need to turn wifi off and on to see the power consuming difference. However, ifconfig wlan0 up/down doesn't really turn wifi on or off. Does anyone has any idea
Jun 29 16:48:34 <majuk> minhui: Typically, unloading the kernel module will turn off the peripheral.
Jun 29 16:48:56 <majuk> Or at least as 'off' as it's going to get without physically disconnecting it in some way.
Jun 29 16:52:54 <minhui> <majuk> I tried rmmod wl18xx and could see the WL led is off. But I can't see any power consuming difference.
Jun 29 16:55:03 <majuk> minhui: Yea... the difference may be pretty marginal. Or the thing module not be totally powered off. Hard to say, I don't know enough about the BB hardware to guess.
Jun 29 16:57:28 <minhui> I also tried uncomment #disable_uboot_overlay_wireless=1 in /boot/uEnv.txt. According to the site (http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays) the wifi module should not start next time I boot BBBW, but when I boot again, the wifi still started.
Jun 29 17:06:49 <minhui> Just reconnected. Does anyone know how to turn wl1835mod of the BBBW off?
Jun 29 19:22:46 <zmatt> hmm
Jun 29 19:23:06 <zmatt> sticking around long enough to wait for an answer would have been a fine start
Jun 29 19:23:57 <zmatt> majuk: the wl18xx module has a control signal to fully power it down, but I don't know off the top of my head what they connected it to on the BBBW
Jun 29 19:24:21 <majuk> Yea, minhui is gone I guess
Jun 29 19:26:11 <zmatt> oh right, that's why I'm not very familiar with the BBBW schematic... it's absolutely horrible ><
Jun 29 19:26:27 <zmatt> typical Eagle output
Jun 29 19:28:33 <zmatt> it goes to a gpio
Jun 29 19:28:45 <zmatt> so it's not actually hard to fully disable wifi
Jun 29 19:30:04 <zmatt> and is truthfully indicated by the led
Jun 29 19:30:43 * zmatt shrugs
Jun 29 19:39:23 * majuk hugs his wandboard schematics
Jun 29 19:41:11 <zmatt> the beaglebone black schematics are fine too, they used Orcad
Jun 29 19:41:28 <zmatt> but for some reason they used that awful Eagle for the black wireless
Jun 29 19:42:55 * veremit smh
Jun 29 19:43:09 <veremit> I cannnot understand how people cope with EAGLE
Jun 29 19:43:28 <zmatt> veremit: you were looking for me earlier?
Jun 29 19:43:33 <veremit> I was?
Jun 29 19:43:46 <zmatt> 00:19 < ver|laptop> zmatt: are you busy?
Jun 29 19:43:47 <veremit> I was hoping you might shed some light on gpios in Uboot I think ..
Jun 29 19:43:55 <veremit> iirc ^^
Jun 29 19:44:39 <veremit> zmatt: but since you're here and I have a related questino .. if you set a gpio as 'output' how easy is it to assign to the kernel 'heartbeat' ?
Jun 29 19:44:55 <veremit> or can you do that immediately on assignment in the DT presumably?
Jun 29 19:45:30 <zmatt> https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.9.26-bone4/arch/arm/boot/dts/am335x-bone-common.dtsi#L33-L38
Jun 29 19:45:47 <veremit> well shoot .. trust you to nail it in 30s :p
Jun 29 19:46:32 <zmatt> since you already guessed DT you should have grepped for it yourself :P
Jun 29 19:46:38 <veremit> wonder why he's labelled it 'green' -shrug-
Jun 29 19:47:00 <zmatt> because it was on the original beaglebone (white), and people hardcoded the sysfs path in their stuff
Jun 29 19:47:04 <veremit> ah I wouldn't have known where to look :p
Jun 29 19:48:20 <veremit> oh lovely and the pinmux's are underneath .. how convenient!
Jun 29 19:48:31 <zmatt> I recently also discovered that the userspace library for uio-pruss contains the hardcoded assumption that it's /dev/uio0
Jun 29 19:48:43 <veremit> oh.
Jun 29 20:15:27 <clockman> Hi there. My BBB, sometimes boots into initramfs because of unexpected inconsistencies "rootfs: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY." is there a way i can have it autorun this?
Jun 29 20:16:54 <zmatt> that sounds really really strange
Jun 29 20:17:18 <clockman> well I see it happen quite a bit. on more than one BBB
Jun 29 20:17:30 <clockman> I blame power interruptions
Jun 29 20:17:49 <zmatt> you're using ext4 ?
Jun 29 20:18:34 <clockman> # mount | grep mmc
Jun 29 20:18:34 <clockman> /dev/mmcblk1p1 on / type ext4 (rw,noatime,errors=remount-ro,data=ordered)
Jun 29 20:18:40 <clockman> yppers
Jun 29 20:19:15 <zmatt> if you're getting this I wouldn't be looking into running that fsck automatically, I'd be looking into how to prevent this from happening, since it sounds like serious filesystem corruption is happening
Jun 29 20:19:49 <zmatt> i.e. just sweeping it under the carpet will probably just end up in severe data loss/corruption or an unbootable system
Jun 29 20:22:25 <clockman> well, right now it ends up being an unbootable system, root
Jun 29 20:22:50 <clockman> unless i take the board out of my project and hook it up to my computer
Jun 29 20:22:51 <zmatt> I wonder what criterion initramfs uses to decide to not proceed
Jun 29 20:23:13 <zmatt> we don't use initramfs at all on our production beagles
Jun 29 20:28:20 <zmatt> what sort of problems does fsck report when running it manually?
Jun 29 20:35:32 <cyberguy> hi all, can i compile linux BBB with net-next linux kernel?
Jun 29 20:36:50 <zmatt> are you asking us to evaluate your abilities?
Jun 29 20:38:14 <zmatt> if you want to know whether those two linux branches merge cleanly, try to merge them and you'll know the answer
Jun 29 20:38:29 <zmatt> if you want to know how to merge two git branches, use google
Jun 29 20:40:09 <cyberguy> Okay i'll try that... thanks
Jun 29 21:05:04 <DrChad> Jason - I 3d printed the EduMIP but need the drivetrain and encoders, any hints on where I can find them?
Jun 29 21:11:26 <veremit> be that jkridner jason?! :)
Jun 30 01:08:07 <Set_> https://pastebin.com/0m8QEHr0
Jun 30 01:08:40 <Set_> This is a piece of software from "Programming the BeagleBone Black." I am using it to read the temp. from a TMP36 sensor.
Jun 30 01:08:47 <Set_> ...
Jun 30 01:09:14 <Set_> Why do I get the C and F reads similar instead of the true values?
Jun 30 01:21:07 <zmatt> ?
Jun 30 01:27:38 <Set_> Yep.
Jun 30 01:27:47 <Set_> I am missing something again.
Jun 30 01:28:15 <zmatt> what do you mean "reads similar" ?
Jun 30 01:28:28 <Set_> They are exactly the same, almost.
Jun 30 01:28:35 <zmatt> ... namely?
Jun 30 01:28:48 <Set_> Please hold and let me check my software reads.
Jun 30 01:28:51 <Set_> Can you hold?
Jun 30 01:29:09 <veremit> same in hex, octal, binary ...
Jun 30 01:29:13 <Set_> 39.58
Jun 30 01:29:48 <Set_> C = -39.58   F = -39.58
Jun 30 01:30:31 <zmatt> apart from the faulty reading, that's still a bit weird, since the fixpoint for that conversion formula is -40
Jun 30 01:31:04 <zmatt> -39.58 * 9/5 + 32 is -39.244
Jun 30 01:31:11 <veremit> aha
Jun 30 01:31:41 <zmatt> about 0.1 V
Jun 30 01:32:00 <zmatt> I'd say something is not quite right on the hardware side, or you're not measuring the right input :)
Jun 30 01:32:22 <Set_> So...
Jun 30 01:32:30 <Set_> I have the wrong hardware set up?
Jun 30 01:32:53 <Set_> I mean...I can turn the little TMP36 sensor around to utilize the other pins.
Jun 30 01:33:08 <zmatt> uhh
Jun 30 01:33:16 <Set_> What?
Jun 30 01:33:24 <zmatt> how did you connect it exactly?
Jun 30 01:35:42 <Set_> GND_ADC to left pin on the TMP36, P9_39 to the right pin, and center pin is on 33
Jun 30 01:35:58 <Set_> Everything is on P9.
Jun 30 01:37:16 <Set_> Sorry. 36 on P9.
Jun 30 01:38:34 <zmatt> I'm just very confused now, you connected its supply terminal to what?
Jun 30 01:38:54 * veremit imagines magic smoke ...
Jun 30 01:39:57 <zmatt> also I recommend against sticking pins of ICs directly into the P9/P8 connectors, they don't always make proper contact (due to being too thin)
Jun 30 01:40:34 <Set_> Okay. Left = P9_03
Jun 30 01:40:59 <Set_> Center = P9_36
Jun 30 01:41:08 <zmatt> ok that makes more sense (I'm assuming that by "left" you mean pin 1)
Jun 30 01:41:10 <veremit> breadboard + du_pont cables for prototyping
Jun 30 01:41:16 <Set_> Right Pin = P9_39
Jun 30 01:41:32 <zmatt> uhh what?
Jun 30 01:41:45 <Set_> Yep.
Jun 30 01:41:47 <zmatt> why are you sticking its ground terminal into an ADC input?
Jun 30 01:41:54 <veremit> lul
Jun 30 01:42:17 <Set_> Because it can read without running over 1.8v.
Jun 30 01:42:28 <zmatt> that sounds like an excellent way to blow up an adc input actually
Jun 30 01:42:35 <Set_> 1.8v = 266 degrees F.
Jun 30 01:42:51 <zmatt> what are you talking about?
Jun 30 01:42:53 <Set_> So, I thought.
Jun 30 01:42:54 <veremit> uhm
Jun 30 01:43:07 <veremit> GND is GND and evermore shall be so ..
Jun 30 01:43:08 <Set_> Hey man...it is from this book. I am just learning.
Jun 30 01:43:25 <zmatt> its ground terminal should go into ground
Jun 30 01:43:25 <Set_> Oh. But ADC_GND has less noise so it says.
Jun 30 01:43:35 <zmatt> ADC_GND is P9_34
Jun 30 01:43:44 <Set_> Okay. That is where it is located.
Jun 30 01:43:45 <Set_> Sorry.
Jun 30 01:43:48 <Set_> I counted wrong.
Jun 30 01:43:51 <veremit> d'oh!
Jun 30 01:43:54 <Set_> Yep.
Jun 30 01:44:01 * veremit hands zmatt a cold towel ..
Jun 30 01:44:08 <Set_> Whip?
Jun 30 01:44:26 <Set_> Okay...so. Where are we now?
Jun 30 01:44:48 <zmatt> wondering if you really stuck them in the right holes or just miscounted again
Jun 30 01:44:56 <veremit> ::)
Jun 30 01:45:05 <veremit> photo?
Jun 30 01:45:11 <Set_> Yep.
Jun 30 01:45:19 <zmatt> by which I mean connected them using a breadboard and jumper wires of course, since as I just said sticking the pins themselves in may not make proper contact
Jun 30 01:45:30 <Set_> I used a breadboard.
Jun 30 01:45:33 <Set_> and jumper wires.
Jun 30 01:45:34 <zmatt> ok good
Jun 30 01:45:51 <Set_> Phew!
Jun 30 01:46:01 <zmatt> also be sure to connect ground before connecting power to this thing
Jun 30 01:46:07 <Set_> Right!
Jun 30 01:46:10 <Set_> Got it.
Jun 30 01:52:18 <Set_> It could be a driver. I think this is an idea. I thought I could only access the P9 header as P9_39 if and only if I had that Adafruit_BBIO software. Now, if this is true, then .js files may not be able to accept it. I think only .py files are accepted.
Jun 30 01:52:23 <Set_> Does that sort of make sense?
Jun 30 01:53:10 <zmatt> not remotely
Jun 30 01:53:17 <Set_> Okay...just checking.
Jun 30 01:53:58 <zmatt> if the adc weren't enable you would get "File not found", not 0.1V
Jun 30 01:54:25 <zmatt> have you checked with a multimeter that the sensor is outputting a voltage closer to expectations?
Jun 30 01:55:05 <Set_> No.
Jun 30 01:55:14 <Set_> I am lazy.
Jun 30 01:55:34 <Set_> I will go and get the damn thing.
Jun 30 01:57:33 <Set_> It is reading 32.xxxx.
Jun 30 01:57:49 <veremit> huh?!
Jun 30 01:57:52 <Set_> So, I am not getting a temp. at all.
Jun 30 01:58:02 <Set_> I am getting a voltage.
Jun 30 01:58:06 <zmatt> maybe get one without a broken display?
Jun 30 01:58:19 <Set_> Hold please. I will check again
Jun 30 01:58:34 <Set_> Of course, the BBB is plugged in and powered on.
Jun 30 01:58:49 <Set_> What should it read?
Jun 30 01:58:52 <Set_> 0.1v?
Jun 30 01:59:37 <zmatt> what does "32.xxxx." even mean? 32 V ?  32 mv?  you have a multimeter with 6 digits of precision?
Jun 30 01:59:41 <veremit> if you don't know .. nows a good time to find out?
Jun 30 01:59:58 <Set_> Now...it was volts.
Jun 30 02:00:10 <Set_> Hold please.
Jun 30 02:00:21 <zmatt> you're getting 32V out of a temperature sensor powered at 3.3V ? that would be fascinating
Jun 30 02:00:30 <zmatt> (also lethal for the BBB, but that aside)
Jun 30 02:00:31 <Set_> Hhahahha. Sorry.
Jun 30 02:00:36 <ds2> must be some sort of piezo sensor
Jun 30 02:01:02 <Set_> Just because I am wrong does not mean I cannot figure out how to become correct.
Jun 30 02:01:07 <Set_> Please hold.
Jun 30 02:01:26 <zmatt> no but please next time, before pressing enter, look at what you typed and ponder a moment whether it actually makes sense
Jun 30 02:01:37 <zmatt> that way you're wasting less of other people's time
Jun 30 02:02:00 <Set_> Heh man.
Jun 30 02:02:10 <Set_> If I was wasting your time, let me know.
Jun 30 02:02:18 <Set_> Okay...back to work.
Jun 30 02:02:39 <Set_> The multimeter reads stuff back like 1.02 and 2.2 and so on.
Jun 30 02:02:49 <ds2> what kind of sensor is this?
Jun 30 02:02:56 <Set_> TMP36
Jun 30 02:03:06 <veremit> .. we hope ..
Jun 30 02:03:10 <Set_> It is.
Jun 30 02:03:16 <Set_> It is a TMP36 sensor.
Jun 30 02:03:26 <veremit> it could really be an NPN transistor .. or a blob of sand .. lol .. ok sorry .. thats bad .. :(
Jun 30 02:03:34 <zmatt> it should read 0.75V at room temperature
Jun 30 02:03:49 <Set_> My house is 80 to 85 regularly.
Jun 30 02:03:56 <veremit> phew!
Jun 30 02:03:57 <Set_> Hot, hot, hot!
Jun 30 02:04:02 <ds2>  /shdn is high, right?
Jun 30 02:04:28 <zmatt> I think he has the 3-pin version (no shutdown pin)
Jun 30 02:04:37 <Set_> Three pin, yes.
Jun 30 02:05:32 <ds2> ah
Jun 30 02:05:39 <ds2> try buffering it
Jun 30 02:05:53 <ds2> the 50uA max load current seems a bit low
Jun 30 02:06:02 <ds2> or try bumpping up the switch close time
Jun 30 02:06:33 <Set_> <<<<<<< on break.
Jun 30 02:06:40 <zmatt> I suspect he has no idea what to do with that last recommendation (although it sounds like a good idea indeed)
Jun 30 02:06:55 <ds2> RTFM
Jun 30 02:07:29 <zmatt> which FM will tell you *where* that is configured?
Jun 30 02:07:34 <veremit> what does ... <backspace<backspace
Jun 30 02:07:38 <ds2> the TRM
Jun 30 02:07:45 <ds2> it tells all.
Jun 30 02:07:51 <ds2> it is just a register
Jun 30 02:08:09 <zmatt> he's most likely using the kernel driver which configures this stuff from DT
Jun 30 02:08:15 <ds2> then fix the driver
Jun 30 02:09:04 <zmatt> :)
Jun 30 02:09:13 <veremit> not that awesome driver from 2.6.32 kernel?!
Jun 30 02:09:14 <veremit> lol
Jun 30 02:09:18 <veremit> jk...
Jun 30 02:09:23 <ds2> the 2.6.32 is a fine driver
Jun 30 02:09:31 <veremit> hehe
Jun 30 02:09:35 <ds2> simple and easy to rewrite
Jun 30 02:09:36 <veremit> I don't doubt it is...
Jun 30 02:09:40 <zmatt> did 2.6.32 have iio already?
Jun 30 02:09:47 <ds2> wrangled it into a nice 8KHz audio input
Jun 30 02:09:52 <veremit> kewl
Jun 30 02:09:57 <zmatt> why so low?
Jun 30 02:10:00 <veremit> perfect for VoIP
Jun 30 02:10:13 <ds2> zmatt: doing speech recogonition
Jun 30 02:10:18 <veremit> tada! lol
Jun 30 02:10:56 <ds2> it was a handle value for pocket sphinx
Jun 30 02:11:05 <ds2> besides, I had the PWM outputting 8KHz audio
Jun 30 02:12:15 <Set_> Okay. So, do you have any recommendations on the info. I gave?
Jun 30 02:12:36 <Set_> If not, it is okay.
Jun 30 02:12:50 <Set_> I will keep trying.
Jun 30 02:12:55 <ds2> yes, validate the EE side first
Jun 30 02:13:01 <zmatt> well to begin you still gave very confusing answers on the electrical side
Jun 30 02:13:10 <Set_> Okay. What is the EE?
Jun 30 02:13:11 <ds2> otherwise you get GIGO
Jun 30 02:13:19 <Set_> What is GIGO?
Jun 30 02:13:29 <ds2> Garbage In Garbage Out
Jun 30 02:13:31 <Set_> Oh.
Jun 30 02:13:34 <Set_> EE?
Jun 30 02:14:24 <zmatt> "The multimeter reads stuff back like 1.02 and 2.2 and so on" ... 1.02V is 52 deg C (125.6 deg F), 2.2V is 170 deg C (338 deg F)
Jun 30 02:14:40 <zmatt> I'm assuming your room temperature isn't fluctuating between those values
Jun 30 02:14:54 <ds2> also 2.2V will kill the BBB
Jun 30 02:14:55 <Set_> zmatt: Where do I put the red part of the multimeter?
Jun 30 02:15:00 <zmatt> also, 2.2V is outside the range the TMP36 should be able to output
Jun 30 02:15:07 <Set_> Okay.
Jun 30 02:15:17 <zmatt> and indeed outside the input range tolerated by the analog inputs
Jun 30 02:15:24 <ds2> I am very interested in a room temp that goes from 125F to 338F
Jun 30 02:15:26 <Set_> So...where should I put the neg. and pos. sides of the multimeter?
Jun 30 02:15:37 <ds2> need to test thermal cycling for other stuff
Jun 30 02:15:39 <zmatt> ground and the thing you're trying to measure
Jun 30 02:15:50 <Set_> Ground can be what?
Jun 30 02:15:52 <zmatt> ground
Jun 30 02:16:02 <Set_> like iron?
Jun 30 02:16:02 <zmatt> (no, don't stick it into your floor)
Jun 30 02:16:08 <Set_> Hhahaha.
Jun 30 02:16:15 <zmatt> like GROUND, GND
Jun 30 02:16:29 <Set_> My multimeter cannot fit in the GND.
Jun 30 02:16:40 <Set_> Maybe. Let me check.
Jun 30 02:16:58 <zmatt> the many many pins labeled "ground", including the ground pin of the TMP and the ground pin of the BBB you connected that to
Jun 30 02:16:59 <ds2> please refrain from burying instruments
Jun 30 02:17:01 <zmatt> you know, ground
Jun 30 02:17:39 <zmatt> (analog ground or digital ground doesn't matter here)
Jun 30 02:18:33 <Set_> Okay...please hold.
Jun 30 02:19:26 <Set_> 0.3!
Jun 30 02:20:01 <Set_> I put the pos. lead into gnd and the neg. on the sensor.
Jun 30 02:20:15 <Set_> Is that wrong?
Jun 30 02:20:18 * veremit facepalm
Jun 30 02:20:34 <Set_> Dude...I just do not have iron laying around.
Jun 30 02:20:34 <zmatt> other way around probably, otherwise you'll read a negative voltage
Jun 30 02:21:46 <Set_> DC?
Jun 30 02:21:54 <Set_> 0.3!
Jun 30 02:22:47 <Set_> 0 to 1.8v is what I can read with my TMP36 because of the analog pins I am using.
Jun 30 02:22:53 <zmatt> well, that voltage measurement only took half an hour...
Jun 30 02:22:58 <Set_> Sorry.
Jun 30 02:23:01 <veremit> \o/
Jun 30 02:23:30 <zmatt> if you were an ADC, your sampling frequency would be 0.5 milihertz apparently :P
Jun 30 02:24:33 <veremit> zmatt: how many samples-per-fortnight does that make?!
Jun 30 02:24:58 <Set_> Yea boy!
Jun 30 02:27:02 <Set_> So, do you think of any software that could manage a TMP36 sensor or I am just barking here.
Jun 30 02:27:31 <Set_> https://pastebin.com/0m8QEHr0
Jun 30 02:27:39 <Set_> That is the software.
Jun 30 02:28:07 <zmatt> it looks fine
Jun 30 02:28:20 <Set_> Okay. So, what did I miss?
Jun 30 02:28:44 <Set_> There is a combination of values that keep showing up after running the software.
Jun 30 02:29:02 <Set_> Farenheit and Celsius are both the same for some reason.
Jun 30 02:29:19 <zmatt> for one, 0.3V is still a garbage value unless it's freezing in your home
Jun 30 02:29:33 <zmatt> and I think ds2's hypothesis earlier sounds quite plausible
Jun 30 02:30:10 <Set_> So, the software is okay but I have some adjustment made to my BBB that is inadequate?
Jun 30 02:30:29 <zmatt> you could verify it by disconnecting the TMP output from the beaglebone (while still keeping it powered) and see if the measured voltage then rises to the right value
Jun 30 02:30:41 <veremit> zmatt: we're not talking about deploying an opamp or such I assume?
Jun 30 02:30:49 <Set_> for instance, my uEnv.txt file?
Jun 30 02:30:54 <Set_> Okay.
Jun 30 02:31:02 <zmatt> veremit: nah, adc configuration can fix this
Jun 30 02:31:07 <veremit> zmatt: cool
Jun 30 02:31:12 <Set_> Which one is the output?
Jun 30 02:31:31 <Set_> P9_39?
Jun 30 02:32:04 <zmatt> Set_: since you're trying to get a piece of hardware to work, I assume you have its datasheet already open (perhaps even printed out), and the answer is on page 1
Jun 30 02:32:19 <Set_> Okay...please hold.
Jun 30 02:32:37 <Set_> The datasheet on the TMP?
Jun 30 02:32:54 <Set_> I never found it. It did not come with a datasheet.
Jun 30 02:33:06 <zmatt> and what happened when you googled TMP36 ?
Jun 30 02:33:11 <zmatt> and clicked on the first link?
Jun 30 02:33:23 <Set_> Um...nothing yet. Please hold.
Jun 30 02:34:01 * zmatt sighs deeply
Jun 30 02:34:15 <Set_> I found it.
Jun 30 02:34:16 <Set_> Yea boy!
Jun 30 02:35:30 <Set_> So, I take the pin out of powering the TMP?
Jun 30 02:35:48 <Set_> 3.3v power from my BBB?
Jun 30 02:35:57 * zmatt sighs deeply
Jun 30 02:36:17 <zmatt> ok, I'm done with you for today
Jun 30 02:36:23 * zmatt afk
Jun 30 02:36:28 <Set_> Okay. Vout. I got it.
Jun 30 02:36:34 <Set_> Pin 2!
Jun 30 02:36:58 <Set_> I am severely undereducated in this field of understanding everyone.
Jun 30 02:37:01 <Set_> Sorry.
Jun 30 02:37:15 <Set_> But...thank you.
Jun 30 02:38:05 <Set_> What do I do once I take away my P9_34?
Jun 30 02:39:34 <Set_> Done, done? Or just not playing at all right now?
Jun 30 02:39:52 <Set_> C = 130 and F = 266 printed out.
Jun 30 02:44:22 <Set_> ...
**** ENDING LOGGING AT Fri Jun 30 03:00:03 2017