**** BEGIN LOGGING AT Tue Jul 30 03:01:12 2019 Jul 30 12:45:44 Are there any known problems with the ADC in the current versions? Jul 30 12:47:01 ben58: if you have a specific problem, ask about your specific problem Jul 30 12:47:24 I've been trying to read it from /sys/bus/iio/devices but it freezes and I can't find any error messages in dmesg or journalctl Jul 30 12:47:59 Not sure exactly what's happening, but I've tried it with 4.14 and 4.19 kernels on debian buster Jul 30 12:48:58 oh you're using some testing-release then, not the latest official image? Jul 30 12:49:26 I started with the latest image and updated it to buster, but yes Jul 30 12:50:17 that sounds even riskier :P Jul 30 12:50:33 update the iot image to buster? is there even enough free space for that? Jul 30 12:50:46 idk, it worked for me... Jul 30 12:51:07 I've had success with updating console images to buster, I'd be scared to try it with the iot image Jul 30 12:51:55 Just checked, 79M free, 98% used... Jul 30 12:53:12 I tried reading the ADC again with everything unplugged and it isn't hanging now, something must be wrong with the electronics then. Jul 30 12:53:51 I don't see how any external connections could cause it to freeze Jul 30 12:55:52 anyway, it definitely works normally here... https://pastebin.com/raw/gh9dKnj3 Jul 30 12:57:41 Should it be in /sys/bus/iio/devices or /sys/bus/platform like you did? Jul 30 12:57:48 Or are you just on a different version? Jul 30 12:59:04 there are many ways to arrive in the same place, but I did it like this because the iio:device number is assigned arbitrarily by the kernel and may depend on device tree configuration and/or kernel version Jul 30 13:00:09 so instead I used a path that's "the iio:device that's a child device of the platform device /sys/bus/platform/devices/44e0d000.tscadc:adc" Jul 30 13:00:34 an alternative would be to iterate over the devices in /sys/bus/iio/devices and somehow determine which one is the correct one Jul 30 13:00:56 for example by checking the "name" attribute Jul 30 13:01:19 I've only ever seen one device in there Jul 30 13:02:05 But thanks for the information, might have to switch to that to prevent future issues Jul 30 13:02:59 on beaglebones in default configuration with unmodified DT and current kernel versions, there is indeed only one iio device there Jul 30 13:04:05 but if you'd hardcode the path, then changing any of those aspects may break your stuff :) Jul 30 13:04:49 what I do myself is use udev rules to pattern-match for devices and then create convenient symlinks that I use in my applications Jul 30 13:06:31 I just checked again and the ADC works when powered by USB, but freezes as soon as I turn an external power supply on, so I probably have other issues. Thanks for your help! Jul 30 13:07:15 that sounds bizarre Jul 30 13:07:19 I'm using an external supply btw Jul 30 13:07:31 (via the 5V barrel jack) Jul 30 13:07:59 I still have great trouble imagining how this could *possibly* affect the adc Jul 30 13:08:16 at worst I'd expect some impact on noise levels, not on behaviour Jul 30 13:12:56 Would that happen if its connected to a voltage divider with too much resistance? Jul 30 13:27:15 if the adc is connected to a voltage source with relatively high resistance, measurement quality may be negatively affected. this can be compensated to some degree by using a larger sampling time Jul 30 13:27:47 basically, the ADC has internal capacitors that need to be charged to the voltage of the channel being measured, and a large series resistance increases the time it takes to charge that internal capacitance Jul 30 13:28:11 large resistance also increases the potential to pick up noise Jul 30 13:29:51 if the adc channel are sequentially sampled and the sample time is too short to let the internal capacitors settle (the minimum time for which will depend on the series resistance) then channel separation may suffer: the measurement may be affected by the previous channel Jul 30 13:34:38 so there is no buffer in front of the internal adc circuitry ? Jul 30 13:34:43 I would've thought that so Jul 30 13:34:55 to make appear the input as low impedance Jul 30 13:41:50 high impedance you mean Jul 30 13:42:34 ohh nm, I see what you mean Jul 30 13:42:42 you mean low impedance towards the internal ADC Jul 30 13:49:18 but correct, there's no internal buffer... the ADC has pretty high impedance though, about 15GΩHz/f, e.g. 15MΩ @ 1 kHz Jul 30 13:49:55 it was probably not viewed to be necessary Jul 30 13:56:08 interestingly, the am437x has two ADCs similar to the one in the am335x: adc0 is close to identical to the one in am335x and has identical input impedance. adc1 has differential preamplifiers on the inputs, yet has substantially worse impedance as a result (18 kΩ differential impedance), albeit lower capacitance (2 pF instead of 5.5 pF) Jul 30 13:56:44 eh, I guess whether that's worse or not will depend on the frequency Jul 30 13:57:05 but most people don't use the ADC for signals in the MHz range ;) Jul 30 13:58:39 oh never mind the specified bandwidth of those preamps are min 15 kHz typ 50 kHz Jul 30 14:08:54 hi all Jul 30 14:09:05 i have problem with bbb Jul 30 14:09:16 debugger listening on port 15454 Jul 30 14:09:35 could you plz help me Jul 30 14:10:13 my command is bbb S command Jul 30 14:10:30 ar b = require('bonescript'); Jul 30 14:14:53 so far you've typed 6 lines of text here, none of which ask a concrete question and none of which describe whatever problem you say you have (as far as I can decipher) Jul 30 14:16:51 i copy this 6 line(the example of bbb) and past in cloud 9 Jul 30 14:17:07 and it doesn't work Jul 30 14:17:46 var b = require('bonescript'); Jul 30 14:18:41 oh, you're trying to paste multiple lines in chat? that doesn't work, use a paste service like pastebin.com Jul 30 14:21:44 https://pastebin.com/TaNFY8XT Jul 30 14:22:11 thank you so much zmatt Jul 30 14:22:17 https://pastebin.com/TaNFY8XT Jul 30 14:22:23 is it okay? Jul 30 14:22:50 pasting it once suffices, please have patience. Jul 30 14:23:07 I'm at work and only occasionally have time to glance at this chat Jul 30 14:23:24 oh sorry Jul 30 14:24:03 thanks a million zmatt Jul 30 14:24:15 so what's the error? Jul 30 14:25:02 it doesn't work i cant see any change in leds Jul 30 14:25:17 i run the cloud9 Jul 30 14:25:33 not sure then... I don't use cloud9 myself, nor bonescript Jul 30 14:25:43 this is error Jul 30 14:25:44 debugger listening on port 15454 Jul 30 14:25:53 that's not an error, that's just a random log message Jul 30 14:26:33 what do you use in order to cloud9? Jul 30 14:27:03 leds are not normal gpios though. I do believe bonescript has some special-case logic that should allow controlling leds *as if* they are gpios, but like I said... I don't use bonescript so I have no idea whether it actually works ;) Jul 30 14:27:05 if it is not error , why the leds not chandeing Jul 30 14:27:24 I have no idea Jul 30 14:27:30 thx Jul 30 14:27:59 "what do you use in order to cloud9?" -> did you mean to ask what I use instead of cloud9? Jul 30 14:28:15 my preferred code editor is vim, but you can use whatever editor you like Jul 30 14:28:17 yes Jul 30 14:28:35 and just log in on the beaglebone (via ssh) and run your code there Jul 30 14:29:02 wich one is better? Jul 30 14:29:08 ? Jul 30 14:29:13 ssh or cloud9? Jul 30 14:29:21 that question makes no sense Jul 30 14:53:06 m **** ENDING LOGGING AT Wed Jul 31 02:59:56 2019