**** BEGIN LOGGING AT Tue Jan 22 02:59:56 2019 Jan 22 05:45:21 set_: & zmatt the slow catching up of yaw can be 'fixed' by setting compass_time_constant in rc_mpu_config_t to a lower value (2.0 in my case) Jan 22 07:39:35 Sorry for asking again, lost connection: Jan 22 07:41:28 I have to plot a graph on lcd7 like an oscilloscope/spectrum analyzer, X and Y values are numeric data coming from UART , I don't know where to start from ....I was thinking something like gnuplot , any idea to apply to beaglebone ? Jan 22 07:42:10 certainly not gnuplot, as it is not interactive, respectively suited for live data Jan 22 07:43:10 where to start: split task in chunks. 1) read the data and output it on the console 2) make the display work, with a test picture 3) make the display content dynamic 4) use the data to feed the dynamic drawing Jan 22 07:43:23 (thats at least my opinion, others are valid too= **** BEGIN LOGGING AT Tue Jan 22 07:44:59 2019 Jan 22 07:50:41 Probably I would be stuck after 1)...... Jan 22 07:51:16 Millenial? Jan 22 07:51:41 lots of opportunity to learn, then! Jan 22 07:52:10 sure ! :-(( Jan 22 08:08:30 LetoThe2nd: what do you mean gnuplot is not interactive ? It cannot refresh the displayed image ? Jan 22 08:09:36 fred__tv: technically you can. just like you can use a printer as a display Jan 22 08:09:43 practically... not so much. Jan 22 08:10:38 I don't really need a "live" display like an oscilloscope , I have to collect some values coming from an impedance analyzer and put them graphically on a display... Jan 22 08:10:59 A refresh every X seconds would be enough... Jan 22 08:11:20 you said scope or specturm analyzer, and those are usually highly responsive by design :-) Jan 22 08:11:34 in that case, gnuplot could be ok Jan 22 08:11:51 I was thinking to gnuplot because it is the easiest way found by now.... Jan 22 08:12:11 something like gnuplot -p -e 'plot "/dev/stdin"' Jan 22 08:12:40 maybe instead of thinking about bits and pieces you "think you could use", you should think about "what do i need and what are the requirements" Jan 22 08:12:56 because once those are clear, one can see what does the job. Jan 22 08:13:19 otherwise you end up in "when the only tool you know is a hammmer, every problem looks like a nail" Jan 22 08:13:29 :-)) Jan 22 08:14:35 and i intentionally suggested reading the values first. making sure the connection works, and maybe log them to a file or DB Jan 22 08:15:20 step-by-step.... Jan 22 08:15:35 eeeexactly Jan 22 09:14:48 also, making a line plot from a list of x/y values is not exactly hard... pretty much any graphics library will do Jan 22 09:15:27 interfacing with an external program, feeding it the data in the format it wants, and getting its output displayed would probably be more work Jan 22 09:16:40 I keep trying to find a convenient plotter application and there are sevral, but they all seem to require vast amounts of setup, or use incompatible bits of python that won't work for me, or some other problem that's just a bit more effort to fix than I find worthwhile. Jan 22 09:16:53 zmatt: basically completely agreed, but assuming a students standpoint each of the steps in itself can be a major learning effort, including just cross-building or whatever Jan 22 09:17:19 sure, but the hurdle of getting graphics displayed needs to be overcome regardless Jan 22 09:17:26 I end up using the plotter built into the arduino IDE for many jobs. it has some flaws but it's very straightforward if you can get your data into a serial stream, Jan 22 09:17:38 zmatt: totally agreed. Jan 22 09:28:29 zmatt you're right , but I'm well under the student level..... Jan 22 09:29:07 I'm quite experienced in hardware but a wood in SW Jan 22 09:30:01 Meanwhile...I'm trying this old article... https://www.logicsupply.com/explore/io-hub/inspire-tutorial-data-plotting-beaglebone-black/ Jan 22 09:31:10 It needs a graphical environment however thus more unused resources wasted Jan 22 09:54:11 I was just curious whether cairo's drm backend would be usable on the bbb, but nope... it looks like it only supports complicated devices that require a ton of custom code, not simple devices that can be supported generically through the "dumb buffer" api -.- Jan 22 10:02:38 one wonders why... Jan 22 10:57:05 Question: I'm running debian9.1 console , My LCD7 clone works but not its touchscreen (not listed in /proc/bus/input/devices), what to check ? Jan 22 13:58:10 just tried, same thing with 9.6 rcn Jan 22 13:58:28 any issue with cape ? Jan 22 14:29:40 Can I know to use CAN on beaglebone black Jan 22 14:30:33 Is someone`s there ?? Jan 22 14:30:40 sang re dada Jan 22 14:45:01 it sems there is lack of ti_tscadc on latest Debian9 any info/suggestion ? Jan 22 14:45:08 *seems Jan 22 15:44:50 fred__tv: what makes you think that? Jan 22 15:44:57 I'm pretty sure the adc is enabled by default Jan 22 15:45:11 oh, touchscreen Jan 22 15:45:17 yes Jan 22 15:45:31 well it's the overlay's responsibility to enable that Jan 22 15:46:09 are you using a custom overlay for this thing? Jan 22 15:47:47 just burned a fresh rcn.ee debian 9.1 console (same thing with 9.6) Jan 22 15:48:16 okay so you're using a standard overlay then I assume? which one is it? (there are three LCD7 revisions) Jan 22 15:48:57 why are you using an old console image instead of the latest? Jan 22 15:50:00 where can I find it ? (no more bone_capemgr/slots here , things changing too quickly...) Jan 22 15:51:17 I remember we were discussing this thing once, but was about LCD7 not recognized, here it works but not its touch Jan 22 15:52:30 I'm checking if rcn has a convenient script maybe to check the identification of all attached eeproms Jan 22 15:53:35 but I guess you can also check it manually... Jan 22 15:53:55 for i in /sys/bus/nvmem/devices/2-*/nvmem; do echo $i; head -c 64 $i | hexdump -C; done Jan 22 15:53:58 or something Jan 22 15:55:56 https://ibin.co/4UP3blweJqMk.jpg Jan 22 15:55:56 it would be nice if u-boot create a DT property listing the files it loaded Jan 22 15:56:21 oh, 64 bytes was not enough Jan 22 15:56:53 head -c 128 /sys/bus/nvmem/devices/2-00540/nvmem | hexdump -C Jan 22 15:57:19 also please don't use screenshots for text, use a paste service like pastebin.com Jan 22 15:58:42 https://pastebin.com/4zA7fbfW Jan 22 15:59:01 V.01 ?? Jan 22 16:00:01 BB-BONE-LCD7-01-00A2 Jan 22 16:00:46 did you check the kernel log for errors related to adc/tsc ? Jan 22 16:01:52 oh! disable adc in /boot/uEnv.txt Jan 22 16:01:58 I'm side by side with a debian 7.7 working ok : Jan 22 16:02:00 0: 54:P---L BeagleBone LCD7 CAPE,00A2,Beagleboardtoys,BB-BONE-LCD7-01 Jan 22 16:02:18 it's possible it doesn't detect that the generic adc overlay conflicts with the adc use of this cape Jan 22 16:03:03 uncomment the disable_uboot_overlay_adc=1 in /boot/uEnv.txt and reboot Jan 22 16:03:32 if that works, it deserves a bug report Jan 22 16:04:46 done, rebooting Jan 22 16:05:01 fyi boards are old white ones Jan 22 16:05:24 that might make things more interesting due to lack of testing, but in theory shouldn't matter Jan 22 16:08:20 AHA !!! Jan 22 16:08:22 https://pastebin.com/mVFwUcP7 Jan 22 16:09:35 you know I had never before heard of /proc/bus/input/ Jan 22 16:09:39 or /proc/bus even Jan 22 16:10:15 hi Jan 22 16:10:44 it's some legacy thing I presume? Jan 22 16:11:05 ? Jan 22 16:11:19 anyway, might want to report to rcn that the adc overlay doesn't get automatically disabled for this cape, resulting in a non-functioning touchscreen Jan 22 16:11:58 \/ /proc/bus/input/devices ... I've never before seen it mentioned Jan 22 16:15:45 yeah mostly looks like a subset of info you'd normally get from sysfs Jan 22 16:15:59 I've seen today, me too looking on the net for such a problem.... Jan 22 16:19:16 just another perhaps easy question , how do I resize monitor resolution in X ? this clone is really a 5,7" with 640x480 instead of classic 800x480 , once I used to add /usr/share/X11/xorg.conf.d/10-monitor.conf Jan 22 16:20:21 but it was for ancient omapfb Jan 22 16:21:14 that sounds weird, x11 should not be able to override the resolution of the lcd panel since it is configured in DT Jan 22 16:21:55 in other words, your cape claims to be an LCD7-01-00A2 but isn't actually Jan 22 16:22:24 yes it is like this Jan 22 16:22:27 which is a really obnoxious thing to do, since that breaks autodetection. the cape should have used a different identifier Jan 22 16:23:11 it is a custom product not for sale.... Jan 22 16:23:30 then it shouldn't have an eeprom claiming to be an LCD7 Jan 22 16:24:19 for a custom product you don't really need an eeprom at all, since instead of autodetection you can just explicitly specify an overlay in /boot/uEnv.txt Jan 22 16:24:38 but if it does have a cape identification eeprom, it should use a unique identifier instead of claiming to be a cape that it isn't Jan 22 16:25:05 right ! Jan 22 16:25:17 and it'll need an overlay that correctly describes the hardware Jan 22 16:25:39 anyway I used to fool it with 10-monitor like this https://pastebin.com/jM8fkGBR Jan 22 16:26:19 probably changing driver and option would work, any idea ? Jan 22 16:26:36 I just explained that it won't and also why Jan 22 16:26:46 the display timings are configured in DT Jan 22 16:28:09 I don't think x11 can override that nowadays... though regardless of whether it can, it shouldn't Jan 22 16:28:18 ahhhhh Jan 22 16:28:19 the correct place to fix this is in the overlay Jan 22 16:28:40 I remember something now.... Jan 22 16:29:09 https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD7-01-00A2.dts#L307-L325 see, the LCD7 overlay has a node with timings for the lcd panel Jan 22 16:29:27 exactly that !! Jan 22 16:29:31 the overlay for your custom cape will need a similar thing, but with correct timings for the panel you're using Jan 22 16:29:54 yes already done that way some times ago ! Jan 22 16:30:05 memory is going.... Jan 22 16:30:05 I was having a deja vu feeling too yes Jan 22 16:33:41 something like modify dts , compile a new dtb , place into /boot/dtbs etc etc isn't it ? Jan 22 16:33:55 uhh, an overlay probably suffices? Jan 22 16:34:47 I remember I've done that way.... something easier ? Jan 22 16:34:52 customizing the main dts is certainly an option too, but it might be a bit more hassle, especially since you wouldn't be able to easily switch kernel versions Jan 22 16:35:12 yes, use an overlay, just like most capes Jan 22 16:35:59 e.g. based on the LCD7 overlay, but with contents that correctly describes your hardware instead of just pretending to be a random other cape that vaguely resembles yours Jan 22 16:37:57 compile it, place it in /lib/firmware/ with a suitable name that matches whatever identification you program into the cape's eeprom (which must be different from any existing capes) Jan 22 16:38:33 which way ? I can modify original LCD7 with right timing , resolution, info, etc, then how to recall instead the actual one ? Jan 22 16:39:32 no, no way to modify cape eprom ! Jan 22 16:39:57 what do you mean "no way" ? it was programmed in the first place Jan 22 16:40:08 but it was programmed with wrong values Jan 22 16:40:18 so (for my personal use) I let beagle thinking it has the original LCD7 Jan 22 16:40:42 it claims to be an LCD7 cape, which is a major complication Jan 22 16:40:59 it isn't the original LCD7 cape Jan 22 16:41:04 it shouldn't claim to be Jan 22 16:41:13 I have not built the cape Jan 22 16:41:55 is the cape's eeprom even write-protected? maybe you can simply modify it via syfs Jan 22 16:42:19 even a blank eeprom would be better than its current contents Jan 22 16:43:30 if the eeprom is write-protected, usually that's easy to lift by connecting some pad or testpoint to ground Jan 22 16:45:56 Here it is... https://imagebin.ca/v/4UPIZ3m9ycVy I don't even think to re-program something like this !!! (my ignorance about) Jan 22 16:48:59 so, that nvmem file in sysfs I had you dump earlier? Jan 22 16:49:19 as long as the eeprom isn't write-protected, you can also just write to it (just like a file) to reprogram the eeprom Jan 22 16:49:34 you're killing me !! Jan 22 16:49:44 :-) Jan 22 16:50:33 You mean it could be fully writable/readable from beagle itself ? Jan 22 16:50:49 yes Jan 22 16:50:59 that's interesting Jan 22 16:51:15 read-modify-write ? Jan 22 16:51:54 not sure what you mean by that in this context Jan 22 16:52:18 you can write to any byte of it Jan 22 16:52:28 can I dump its content , modify it and re-write ? Jan 22 16:52:32 it basically behaves like a file, but fixed-size Jan 22 16:53:41 hmm, your photo is a bit unclear... the silvery dot below the two resistors on the left side of the eeprom, is that a testpoint? a via? Jan 22 16:54:21 seems a bit small for a testpoint, so I'm guessing a via Jan 22 16:54:38 it could be.... Jan 22 16:54:47 what's your local time ? Jan 22 16:55:25 well does it show up on the other side of the pcb? Jan 22 16:55:35 since that pin controls the write-protection Jan 22 16:55:43 so I wonder where it's going Jan 22 16:56:01 ground ? Jan 22 16:56:27 if true then it has no write-protection Jan 22 16:56:44 and yeah I guess it probably is, since otherwise why would they fill that net Jan 22 16:57:00 okay, well then you can freely modify the eeprom contents via sysfs Jan 22 16:58:16 maybe there's some script or tool to generate suitable eeprom contents for a cape... never dug into it really Jan 22 16:58:22 almost 6:00 PM here , grocery then home, (then bed) from tomorrow 8:00 AM I'm ready to give it a try :-) Jan 22 16:58:34 ok Jan 22 16:59:08 thanks Jan 22 18:58:54 e Jan 22 22:12:51 zmatt: ? Jan 22 22:38:24 I am firing up a new BBGW with the HDMI cape. The instructions say to download a new firmware set to allow it to work. I downloaded the latest (which is not the one it links to from that page), but am not getting any video output. Should the latest work with this cape? I can hit it via SSH. Jan 22 22:57:37 odd, the beagle bone black I have putty's into root, no issue but the beagle blue won't, only debian/temppwd Jan 22 22:57:48 then I have to sudo Jan 22 22:57:59 what changed and why? Jan 22 23:00:03 Don't know if it is the case here, but some dists disable root login via ssh. There isa setting in sshd.conf to control this Jan 22 23:03:57 in sshd_conf, yes there is. Jan 22 23:04:25 PermitRootLogon = no or yes Jan 22 23:06:50 vdr plus you have to give the root account a password. No password = logins disabled for root. Jan 22 23:11:22 thanks... cloud9 brought me in as root, seems again odd Jan 22 23:15:31 unless you can sucessfully ssh in as root you have not circumvented the 2 things that are done to disable root logins. Jan 22 23:16:15 cloud9 may be doing it's own thing though. I dunno I don't use it. Jan 23 00:11:50 Snert_: sshd's default nowadays is actually PermitRootLogin prohibit-password i.e. you're allowed to log in as root, but not using password authentication. you have to use e.g. public-key authentication instead Jan 23 00:12:17 vdr: this was changed quite a while ago, for security reasons Jan 23 00:13:06 Guest43884: you have a BBGW with a hdmi cape... that sounds rather bizarre, why not use a BBBW instead then? Jan 23 00:17:04 thanks, got it working Jan 23 00:17:17 no security needed at this time Jan 23 00:18:53 vdr: also, normally you don't need to log in as root, the debian account has sufficient privileges for most purposes Jan 23 00:21:18 Guest43884: are you talking about this cape => http://wiki.seeedstudio.com/BeagleBone_Green_HDMI_Cape/ ? Jan 23 00:21:29 it is not really compatible with the Green Wireless Jan 23 00:21:43 you'd need to disable wifi and bluetooth Jan 23 00:22:44 since the Green Wireless is a braindead design that sacrifices a whole bunch of expansion header pins for the wifi/bluetooth chipset (instead of reusing the pins that were formerly used for ethernet, which is what the Black Wireless does) Jan 23 00:23:00 and some of those pins are used by the hdmi cape Jan 23 00:33:10 if my SPI communication randomly glitches, what's the first thing I should check ? cables ? Jan 23 00:34:26 I'd use a different PSU. Jan 23 00:35:02 the PSU is some ± expensive configurable power brick Jan 23 00:35:09 and wiggle breadboard wires during operation. Jan 23 00:35:11 you turn a knob and it goes from 2V to 12V or something Jan 23 00:40:11 it's a rare event so I'm having trouble diagnosing, but it seems to be the cable Jan 23 00:40:18 I was twisting the cables when it did it Jan 23 00:40:21 Thanks (re HDMI) - that is the one I got (based on the 'related product' link on their site). Jan 23 00:44:49 when I quickly approach a magnet from the SPI wires it makes it glitch Jan 23 00:44:51 that's so cool Jan 23 01:30:50 Snert_, so because it doesn't have hdmi out, nor a hard network jack the only way I can conceive of initially getting into this blue is via USB Jan 23 01:31:44 that being said cloud9 was in the instructions. but something kind of counterintuitive to the whole root/debian change was that cloud9 opened giving me root@beaglebone: Jan 23 01:32:19 ip over usb is fine. Jan 23 01:32:28 at least at first. Jan 23 01:33:03 log in as debian....set a root password. Enable root logins in sshd_config - voila. Jan 23 01:33:09 i had putty'd in over IP using the 192.168.7.2 but it wouldn't take root Jan 23 01:33:15 I think the wireless beaglebones also set up an access point by default? not 100% sure Jan 23 01:33:54 zmatt, supposed to but hadn't tried yet Jan 23 01:34:00 yeah, that's what the getting-started guide says Jan 23 01:34:04 if it were an access point by default you would see an ssid in your wireless neighborhood I'd think. Jan 23 01:34:24 but at any rate it's beer oclock Jan 23 01:34:25 named BeagleBone-XXXX where XXXX varies Jan 23 01:34:28 Snert_, that's what I did but using cloud9 as root to set root password Jan 23 01:34:56 i'll check, this computer is on an old bridge... where's my phone Jan 23 01:35:09 note that you don't need cloud9 to get root access, the debian account can simply use sudo Jan 23 01:35:35 it does sound weird the cloud9 ide gives a root shell in the first place Jan 23 01:35:50 zmatt, that's my point Jan 23 01:36:21 I had gotten past it until I thought about why cloud9 came in as root... Jan 23 01:37:52 I guess the cloud9 ide simply gives a shell under the account that the cloud9 service runs, and that's probably root for historical reasons (i.e. they hadn't gotten permissions right initially) Jan 23 01:38:10 yep, the access point is alive Jan 23 01:38:12 which is gross, but *shrug* .. I've never used the cloud9 ide anyway Jan 23 01:39:17 well I was coloring by numbers per startup so go figure, follow the instructions they will always expose something erroneous Jan 23 01:39:35 ? Jan 23 01:43:42 start.htm Jan 23 01:47:48 * zmatt -> zZ **** ENDING LOGGING AT Wed Jan 23 02:59:57 2019