**** BEGIN LOGGING AT Thu Jul 30 02:59:58 2015 Jul 30 10:48:51 Hi! Anyone using am335x in networks with high broadcast load? Jul 30 12:03:22 Hello Jul 30 12:04:48 I'm trying to boot my BBB via SD card, it does not seem to boot. Jul 30 12:05:47 Yes, I am holding the S2 button, formatted my SDCARD to FAT but the Leds do not glow. Jul 30 12:05:59 I'm using a 5v 2a adapter to power the BBB as well. Jul 30 12:06:04 can anyone help me out? Jul 30 12:08:46 Ash__: what is on the card? Jul 30 12:10:28 http://beagleboard.org/latest-images Jul 30 12:10:34 last image flashed Jul 30 12:12:45 Sorry IRC noob here. Jul 30 12:12:53 SD card contains http://beagleboard.org/latest-images debian image Jul 30 12:13:01 properly flashed. Jul 30 12:13:13 ok, because you said you formatted the card Jul 30 12:14:15 even if I just insert the SD card and don't press the boot button, it should boot from the eMMC right? None of the LED's glow. However if I remove the SD card , it boots up normally. Jul 30 12:14:34 that just sounds like an old u-boot Jul 30 12:15:26 I'd recommend to prepare the card again and follow the #exactsteps given on the beagleboard.org page Jul 30 12:15:50 then hold down S2 and only after that connect the board to power Jul 30 12:15:52 It is running AngstromLinux version 3.8.13 (koen@rrMBP) (gcc version 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01) ) #1 SMP Wed Sep 4 09:09:32 CEST 2013 Jul 30 12:16:14 disconnecting and reconnecting power is important when you reboot Jul 30 12:16:27 I am disconnecting and reconnecting. Jul 30 12:16:36 'k just making sure Jul 30 12:16:39 I am sure I am following all the steps. Jul 30 12:16:49 Should the SD Card be FAT or FAT32? Jul 30 12:17:04 Should I format the card before I use? Jul 30 12:17:11 if you flash the image it will be the correct filesystem type Jul 30 12:17:26 as the image contains partitions and filesystems Jul 30 12:17:56 do you have a usb-to-serial cable that fits the debug port of the board? Jul 30 12:18:25 yes It is flashing ext4 and creating partitions by itself. Jul 30 12:18:33 I sadly do not. Jul 30 12:44:15 here is my solution to setting up a wireless client with out a screen: https://gitlab.com/nivwiz/cwvw/tree/master Jul 30 12:44:30 it runs on debian 8.0 on BBB Jul 30 12:44:39 tbr: any feedback? Jul 30 12:47:05 citylight2: on what? Jul 30 12:49:53 on this project Jul 30 12:50:11 I think you already saw it Jul 30 12:50:34 it allows to setup a wifi without connecting a keyboard and screen to the BBB Jul 30 12:50:58 it offer a hotspot , which you connect to using your phone and enter the SSID and password Jul 30 12:51:14 packages well to deb Jul 30 12:51:57 citylight2, checking it out now... Jul 30 12:52:07 thanks Jul 30 12:52:35 its just that I remember the handle tbr back from the days of my simpad Jul 30 12:52:44 but any feedback is welcome Jul 30 12:52:58 This is pretty nifty Jul 30 12:53:16 I should test this out with my BBB once I get home! Jul 30 12:53:18 I still need to check the usb0 subnet Jul 30 12:53:19 Looks cool Jul 30 12:53:25 to avoid colision Jul 30 12:53:49 its GPL-3 - so I want more ppl to use it Jul 30 12:53:51 citylight2: I don't use wifi on my bbb. Jul 30 12:53:57 o Jul 30 12:54:49 citylight2, to give this more visibility, you should post in BBB forums! Jul 30 12:55:48 I like IRC a lot Jul 30 12:55:50 more direct Jul 30 12:56:03 rcn-ee is also very responsive Jul 30 12:56:25 knob: and visibility is not always a thing you would want Jul 30 12:57:05 KotH, how come? Jul 30 12:57:37 knob: users mean work, they complain, they demand, they eat your time... for little or no gain Jul 30 12:58:04 or, you make a mistake and the crow slam you Jul 30 12:58:20 while you where just looking to help the public Jul 30 12:59:53 Well, you both are right in that account. Jul 30 13:01:18 the only advantage of having users is, that one in a thousand might end up contributing back Jul 30 13:04:24 true that Jul 30 13:44:35 Hi, I've just got my BBB. Connected via usb to get network over serial, web browsers eventually timeout when trying to connect to 192.168.2 Jul 30 13:44:56 my host laptop is running debian, and I've executed the provided shell script Jul 30 13:44:56 double and triple check that you are using the right ip address Jul 30 13:45:05 CTtpollard: Well, that is not a valid IP address. Try using the full 192.168.7.2. Jul 30 13:45:19 agmlego: yes sorry, a typo into irc Jul 30 13:45:20 agmlego : it is a valid ip address actually, but not the correct one Jul 30 13:45:43 CTtpolladr : so now you do network debugging, which has nothing to do with bbb but everything to do with linux networking. Jul 30 13:45:49 it has power, and the leds are flashing Jul 30 13:45:50 CTtpollard : ping the ip Jul 30 13:46:24 I cannot ping or ssh it Jul 30 13:46:45 then look at your network configuration Jul 30 13:46:48 CareBear\: Since when in an IPv4 address valid with only three octets? Jul 30 13:47:11 CTtpollard : what network interfaces do you have and what addresses are configured on them Jul 30 13:47:24 agmlego : try pinging 0 and 1 and 127.1 and 192.168.2 Jul 30 13:48:37 CareBear\: "Ping request could not find host 0." ;-P Jul 30 13:49:04 try the others too Jul 30 13:49:06 CareBear\: no shit, that's really amusing. Works on Win7. Jul 30 13:50:35 eth0 , eth1 , lo , vibr0 and vnet0 Jul 30 13:50:39 from ifconfig Jul 30 13:52:08 CTtpollard : doesn't look like usb0 is configured, so no wonder that you can't communicate with the system on the bone Jul 30 13:52:27 CareBear\: I ran ls Jul 30 13:52:33 ignore that sorry Jul 30 13:52:37 ls Jul 30 13:52:42 gahh gnome!! Jul 30 13:53:21 let me start that again, I ran mkudevrule.sh with sudo, and got no errors from it Jul 30 13:54:03 fine, but that doesn't sound like it would configure a network interface Jul 30 13:55:04 CareBear\: I was just going off the getting started guide which listed at for linux usb drivers Jul 30 13:55:30 dunno what that says Jul 30 13:55:48 http://beagleboard.org/getting-started Jul 30 13:56:00 the linux system on the bone appears as a USB network card. that network card must be configured in order to access the linux on the bone via USB. Jul 30 13:56:24 dhcp might or might not work - I don't know Jul 30 13:56:43 set some IP in the 7 network and have fun Jul 30 13:57:19 if you only want to follow instructions then the bone is probably not a good tool anyway Jul 30 13:57:28 tool or toy :) Jul 30 13:57:45 if you don't mind changing things around and finding what it can do then it's a great one! Jul 30 13:57:53 CareBear\: thanks Jul 30 14:17:57 after a host reboot, usb ethernet shows up in gnome, but won't let me activate whilst keep the hardware ethernet up Jul 30 14:34:26 I've got usb to ethernet ssh connection to it now, although I've lost the ability to use my actual hardware ethernet connection at the same time on the laptop Jul 30 14:35:51 CTtpollard: routing Jul 30 14:36:11 CTtpollard: CTtpollard do it manually from the commandline Jul 30 14:40:39 jacekowski: that's what I know I need to do, but not how to do :) Jul 30 14:41:38 read up on linux routing, iproute2 will probably be place to start Jul 30 14:59:46 route and 'ip route' are your friends .. I'd suggest the former for most tasks Jul 30 14:59:59 the latter is just the newer interface Jul 30 16:59:24 hi Jul 30 17:03:46 I'm working on a beaglebone black since the beginning of the year and i suddenly encounted a problem. it doesn't answer at all from any source of communication (ttl, ssh via usb or ethernet) The BBB still boots because the USR leds flashs (there is the heartbeat and activity flash). I have tried to update the distribution with an sd card and nothing happend (i stayed a loong time holding the S2 button but nothing happened). Jul 30 17:04:35 jack_: What does the debug serial output look like? Jul 30 17:05:37 nothing it doesn't detect the usb connected on the desktop linux Jul 30 17:06:15 what ttl-uart adapter are you using? Jul 30 17:06:48 jack_: Yeah, I mean the actual debug serial interface, the 6-pin header on the board. Jul 30 17:07:12 The thing you have your USB-BUB or FTDI adapter plugged into. Jul 30 17:07:39 I used the 3.3 ttl usb cable do you want the brand? Jul 30 17:07:55 No. Jul 30 17:08:10 Just, what does *that* serial output say? Jul 30 17:08:30 well, first step, is *that* adapter detected on usb? does it show up in lsusb, does it pass a loopback test in minicom? Jul 30 17:08:59 actually nothing because nothing leave the beaglebone so ubuntu doesn't event detect the connection between the desktop and the BBB Jul 30 17:09:10 no it doesn't Jul 30 17:09:38 I used minicom Jul 30 17:10:28 start by getting your serial adapter working .. then connect to the beaglebone :) Jul 30 17:10:44 jack_: Did you try removing the adapter from the bone and shorting RX and TX together with a wire, and trying a loopback test? Jul 30 17:10:48 yes thank you :) Jul 30 17:11:57 how do you launch a loopback test without any connection with the BBB? (sorry pehaps i seems to be a newbie but thank you to help) Jul 30 17:12:53 jack_: You unplug the adapter from the board, and short the RX and TX pins together. THen send data at the port, and see if it comes back. Jul 30 17:13:06 If it does, you passed the loopback test. Jul 30 17:16:56 <[Butch]> Quick question: Is there a good cape breakout for the BBB? Something like the Black Hat Hack3r for the Raspberry Pi? Jul 30 17:26:03 [Butch]: there's this thing - http://elinux.org/Beagleboard:BeagleBone_Breakout Jul 30 17:33:06 <[Butch]> ddrown: I saw that. Spendy. And frankly, not nearly as cool as http://shop.pimoroni.com/products/black-hat-hacker Jul 30 17:34:06 ok Jul 30 17:35:16 [Butch]: The wonderful thing about open-source hardware is you can always make your own. Jul 30 17:35:59 <[Butch]> agmlego: Yes, but if I did that every time I needed something, I'd never get anything done. :-) Jul 30 17:36:15 <[Butch]> I need to fly to Paris. Guess I'd better build a plane. :-) :-) Jul 30 17:36:59 I need a time machine .. Jul 30 17:37:15 <[Butch]> Anyway, I just thought I'd ask if someone knew of something. Thanks for the help! Jul 30 17:41:15 [Butch]: THe other wonderful thing about open-source hardware is that you can use the existing stuff if it works for your purpose. Since there are already planes going to Paris, no need to build one. ;-P Jul 30 17:41:59 <[Butch]> Agreed. Jul 30 20:33:00 hello Jul 30 20:33:50 i have a yocto sato build running on a bbone black. I also have the 4" lcd from 4d systems. Is there anyway I can see determine why the lcd is not working? Jul 30 20:48:33 hey!! Hallo Boners Jul 30 20:50:08 Q: whats the highest ampage I can safely use with a BBB? I'm using a plug-on screen cape with a backlit keyboard and it keeps cutting out at things like saving and exiting vim Jul 30 20:50:26 I'm currently (haha) on a 2.1A supply. Jul 30 20:51:38 Anyone? Jul 30 20:52:41 raindancing, amperage doesn't matter, as long as you meet the minimum... Jul 30 20:53:10 thanks, I had heard that, but I was worried about erm back-currents or jitters or something ?? Jul 30 20:53:32 I saw some 4A kit on amazon, looks good Jul 30 20:53:57 a crappy 5volt supply is still crappy at 2A or 4A.. ;) Jul 30 20:54:04 Anybody know where the 8-port networking cape is on sale? I can't seem to find it anywhere these days Jul 30 20:54:23 Well nothing I can do about a 5V supply, rcn-ee Jul 30 20:54:42 re networking...*oddly enough* Jul 30 20:54:57 as long as it meets the ripple ratings, but the bbb can take a noisy supply unlike the beagle classic.. Jul 30 20:55:53 I like noisy supplies...OK final question Jul 30 20:56:40 http://www.banana-pi.com/eacp_view.asp?id=64 Jul 30 20:57:34 although .. not sure whether there's a switch IC on there ... Jul 30 20:57:53 thanks veremit, but *on-board WiFi*, that looks like fun for networking Jul 30 20:57:55 ah yes Jul 30 20:58:00 bcm ditty Jul 30 20:58:15 <3 my b-pi Jul 30 20:58:23 did I mention sata? oops :D Jul 30 20:59:41 problem is, rcn-ee .. not many people gonna have a 'scope to test their psu with .. Jul 30 21:00:15 so it's mostly 60% lucj Jul 30 21:00:19 luck* too Jul 30 21:00:43 true, sometimes it's on the order page... but of course crappy ones aren't going to show it... or lie.. Jul 30 21:01:33 what's the tolerance on the pmic .. Jul 30 21:01:52 I mean .. 10% is quite typical for many psu's .. Jul 30 21:02:17 2.7 V - 5.8 V ;) Jul 30 21:02:37 ah, so long as it doesn't dip below 2.7 at startup ......... ;) Jul 30 21:02:48 its' not like the twl4030 on the beagle classic, it was 5v +- 5%. .;) Jul 30 21:03:10 I suppose it has to cope with the usb spec .. so that's 4.7 min. Jul 30 21:03:19 hmmm? Jul 30 21:03:29 the 4030 is not 5V tolerant Jul 30 21:04:05 giving it 5V would emphasize the "was" part Jul 30 21:04:20 it was ldo'ed to something, just remmeber blowing a couple few with 5.1v.. Jul 30 21:04:32 4.2-4.3ish Jul 30 21:04:47 the LDO drops it to that making it a pain to battery power it Jul 30 21:05:26 suppose I should prolly knock up something to monitor the voltage...siomething which doesn't take too much juice... Jul 30 21:07:51 OK thx for the help guys...v. useful Jul 30 21:07:54 adios amigos Jul 30 21:37:55 rcn-ee: 2.7 only if you reconfigure it Jul 30 21:38:33 absent a battery, you need 4.3 V to power on, and 3.5 V to stay on Jul 30 21:38:43 with default settings Jul 30 21:38:59 heh I know zmatt would know .. lol :P Jul 30 21:39:02 knew* Jul 30 21:39:47 if you use a battery, it is allowed to drop to 3.3 V (note that BAT -> SYS also has less voltage drop than the other two inputs) Jul 30 21:40:27 veremit: I also recently added it to http://elinux.org/BeagleBone_Power_Management Jul 30 21:40:43 ah excellent Jul 30 21:42:49 to anyone here who's got a screen attached to his/her BBB: can you check if everything is in fact shifted by one pixel (rightmost pixel ending up at start of next line, bottomright corner moved to topleft) Jul 30 21:46:33 o,o Jul 30 21:47:23 (if so, setting bit 6 of the byte at physical address 0x4830e036 should fix it) Jul 30 21:47:29 zmatt, i know it's randomly off on some older kernel's.. rmk spent lots of time fixing that up, as an armanda device use the same nxp chipset, it was all over the palce.. Jul 30 21:47:47 rcn-ee: default of the HDMI framer is to sample on rising edge of clock Jul 30 21:47:54 default of the LCDC is to change data on rising edge of clock Jul 30 21:47:59 both can be reconfigured Jul 30 21:48:31 bit 6 of aforementioned byte does so in the LCDC Jul 30 21:48:33 its bit 6 in the farmer or lcdc? Jul 30 21:48:46 the framer is not directly memory-mapped obviously Jul 30 21:49:11 yeah true... and the datasheet hides lots of stuff.. Jul 30 21:49:33 we should just set bit 6 by default... Jul 30 21:49:34 also its registers are strictly confidential (and also on github) Jul 30 21:49:37 rcn-ee: correct Jul 30 21:50:40 you're actually officially not allowed to change those settings while the LCDC output is enabled.... doing it anyway seems to work fine, but I can't exclude the possibility that doing it with lots of people might summon Cthulhu from its slumber or something Jul 30 21:51:54 almost at train station, afk for a while, will be back Jul 30 21:52:32 lol @ cthulhu Jul 30 21:58:23 zmatt, i like how you find the undocumented registers.. offset 36h is not listed in the lcd interface .;) Jul 30 22:04:39 can't even find the interface spec here :/ Jul 30 22:04:45 feckin soc manuals ;/ Jul 30 22:10:56 zmatt .. back yet/ Jul 30 22:48:09 yep Jul 30 22:48:48 ehh, then rcn-ee didn't look in the right place or I stated a wrong offset Jul 30 22:48:54 it's definitely documented Jul 30 22:49:36 yup, "ipc" bit of RASTER_TIMING_2 Jul 30 22:51:30 (as usual the TRM specs registers as if they're 32-bit, regardless of whether this is a sensible subdivision of the register space of the peripheral) Jul 30 23:14:31 I found some interesting snippets in uboot on clock polarity Jul 30 23:14:49 triggered by some post on the ti forums Jul 30 23:14:52 anything u-boot does will be overwritten anyway Jul 30 23:14:58 ah true Jul 30 23:15:08 but its the same driver iirc Jul 30 23:15:13 da8x something Jul 30 23:15:16 also, standard u-boot used by the BBB doesn't include the lcdc driver in the build Jul 30 23:15:33 well it wouldn't .. how old is the current build? Jul 30 23:15:37 2009 lol ? Jul 30 23:15:44 I think it just doesn't include it on purpose Jul 30 23:15:56 thats stupid, but classic Jul 30 23:16:06 it's not stupid. not everyone uses HDMI, the pins may be repurposed by a CAPE Jul 30 23:16:34 blindly enabling the LCDC could fry external hardware Jul 30 23:16:41 fair point I guess :p Jul 30 23:17:29 and yes, the lcdc is originally from Primus/Freon Jul 30 23:17:35 aka omap-L1xx Jul 30 23:18:16 aka am1xxx aka tms320c674x aka da830 Jul 30 23:18:20 ti article .. just re-found .. http://e2e.ti.com/support/arm/sitara_arm/f/791/p/249810/874650 Jul 30 23:19:41 has it been merged in later kernels .. I can't find the da8xx-fb referenced in anything recent .. or is that the guilty driver ... Jul 30 23:20:34 that's one weird question though Jul 30 23:20:47 there are invert_pixel_clock and invert_line_clock defines Jul 30 23:21:02 in the uboot source I Saw both were set to '1' ... Jul 30 23:21:29 you can individually invert: pclk, hsync, vsync, oe Jul 30 23:21:57 inverting pclk is effectively the same as selecting the edge on which the remaining signals change Jul 30 23:22:29 there's also an option to move the sync signals to the opposite pixel clock edge Jul 30 23:23:50 ah Jul 30 23:23:52 that is, have hsync+vsync change on the pclk edge that's opposite of oe+data Jul 30 23:24:07 I couldn't fine proper docs on the lcdc that I'd expect to exist .. >,< Jul 30 23:24:11 bloody chip vendors Jul 30 23:24:13 uhh Jul 30 23:24:18 the lcdc is reasonly well documented Jul 30 23:24:25 what do they call it? Jul 30 23:24:33 I probably missed it Jul 30 23:24:38 "LCD Controller" Jul 30 23:24:48 chapter 13 of the AM335x TRM Jul 30 23:24:49 for which family/target/etc ? Jul 30 23:24:53 ahits in the trm. Jul 30 23:24:57 ^ Jul 30 23:24:58 everything is in the TMR Jul 30 23:25:00 TMR Jul 30 23:25:01 TRM Jul 30 23:25:05 ick a one doc pony then .. Jul 30 23:25:12 fuckin TI Jul 30 23:25:13 well Jul 30 23:25:14 :D Jul 30 23:25:26 I'm used to about 10 different docs for one chip Jul 30 23:25:27 :D Jul 30 23:25:34 ah like the keystones do Jul 30 23:25:40 I'm not sure which I'd prefer Jul 30 23:25:45 like most modern chips ... Jul 30 23:25:54 they're botth bastards imho lol Jul 30 23:26:03 actually TI switched from split TRM to unified TRM Jul 30 23:26:39 my statement "everything is in the TRM" is false of course Jul 30 23:26:56 you also need the datasheet and (quite importantly) the errata Jul 30 23:27:17 for the LCDC, keeping the LCDC chapter of the omap-L1xx TRM handy is also recommended Jul 30 23:27:27 some things are explained better there Jul 30 23:28:20 also, it explains why the AM335x TRM sometimes claims color passive-matrix has at most 3375 colors Jul 30 23:28:54 the passive-matrix ditherer in Primus only supported 15 levels, hence 15^3 colors Jul 30 23:29:37 for the AM335x they upgraded the ditherer to support 16 levels, but failed to replace all occurrences of the number 3375 by 4096 Jul 30 23:31:29 lol Jul 30 23:31:47 had be puzzled for a bit until I figured that out Jul 30 23:32:23 ah was that how you found offset 36 lol Jul 30 23:33:36 eh, I found that offset by looking in my header file, which I made (as with most of my headers) by reading the register map in the TRMs while changing names to something sensible when needed :P Jul 30 23:34:01 note that the LCDC supports writes of any size and alignment Jul 30 23:34:49 if it weren't for a handful of annoying registers, you could map it as normal shared (uncacheable) memory Jul 30 23:37:26 in particular, accessing lidd apparently causes a bus lockup requiring system reset (probably because the clock to that submodule isn't enabled and hw doesn't bother checking that, stalls indefinitely) Jul 30 23:42:26 heh Jul 30 23:42:41 these things aren't "fault-tolerant" .. you cock up .. you lock up :P Jul 30 23:44:21 the overall effect of the collection bit/byte-reordering flags in both the raster and dma modules is still not 100% clear to me, my plan is to just test the relationship of memory bits -> output pins for the various combinations Jul 30 23:44:44 actually, it's extremely rare for a peripheral to be able to adversely affect the whole system Jul 30 23:44:51 and I'd consider that a chip erratum Jul 30 23:45:08 (and TI has in the past in fact done so too) Jul 30 23:48:15 it's one thing I dislike about OCP: it's not robust to disconnection. you can't tie off the slave-side in any way that prevents the master from locking up on attempted access Jul 30 23:48:33 you really need some combinatorial logic to generate an error response Jul 30 23:48:58 scrap combinatorial, probably needs to be stateful actually Jul 30 23:50:09 TI messed that up with the unused 32-bit initiator port of the Cortex-A8 subsystem (0x40100000 - 0x401fffff) Jul 30 23:50:33 on the DM81xx any access there causes lockup Jul 30 23:50:43 heh Jul 30 23:51:04 (they fixed it on the AM335x, perhaps by removing the port altogether) Jul 30 23:51:23 it was intended for ABE Jul 30 23:53:16 but no processor was ever released with cortex-A8 + ABE Jul 31 00:14:50 yikes Jul 31 00:17:11 what was the motivation behind those caps on lcd_data0-15 ? because I'm looking at the scope right now and the resulting slew is... uncomfortable Jul 31 00:23:09 well .. it works .. I've had it drive a lvds serializer successfully Jul 31 00:23:52 I didn't say it didn't work Jul 31 00:33:24 but... http://gerbil.xs4all.nl/lcdc-scope.png Jul 31 00:35:13 (toggle point for the digital probes set to 1.4V since that's the specified V_IH(min) of the HDMI framer and it samples on rising edge) Jul 31 00:47:11 could just be the framer loading too .. y'never know Jul 31 00:47:35 input capacitance: 4.5 pF Jul 31 00:47:40 4/5ns rise-time not bad really Jul 31 00:47:41 the added caps are 10x Jul 31 00:47:55 its a fairly slow signal by modern standards :p Jul 31 00:48:12 not like its 1080p60 ;D Jul 31 00:49:13 it still doesn't explain why they were added (and only to the data signals, not synchronization signals) Jul 31 00:50:27 gonna see if I can put a "01010101101010100101010110101010" pattern on Jul 31 00:51:34 hehe Jul 31 00:51:53 you need a "15min with Gerald" conversation lol Jul 31 00:52:01 ? Jul 31 00:52:52 of course the fact that the signals need to go to the framer *and* cape pins is pretty nightmareish... good thing it's parallel video hence, as you said, relatively slow Jul 31 00:53:33 you could just remove them Jul 31 00:54:09 mrpackethead: they're currently not causing trouble, so pointless effort. I'm just curious about the motivation Jul 31 00:57:09 hm, seems some parts of the kernel aren't good at talking to each other Jul 31 00:57:32 given that most claim my frame rate is 0 Jul 31 00:57:46 for which this animation runs remarkably smooth Jul 31 00:58:19 maybe if you remove tehm, you might see what happens Jul 31 00:58:27 they might be there, becuase somethign does happen. Jul 31 00:59:01 mrpackethead: well, given that by default the pixel clock polarity is configured wrong, anything can happen Jul 31 00:59:16 the caps might make the image stable (but 1 pixel shifted) Jul 31 01:00:06 (this scope pic is with the correct lcdc pixel clock polarity) Jul 31 01:00:10 *the Jul 31 01:03:34 stt_michael: lcdc can actually produce 1080p60 if the recipient tolerates less-than-standard amounts of blanking Jul 31 01:03:50 yeah not liking the "less-than-standard" bit lol Jul 31 01:04:11 well, the amount already varies depending on frame rate Jul 31 01:04:27 (1080p50 and 1080p60 use the same pixel clock) Jul 31 01:04:47 and I don't see any reason for a screen to give a shit Jul 31 01:04:52 as long as it's within spec.. although many peripherals are tolerant lol Jul 31 01:05:15 the large amount of blanking only exists for compatibility with analog signals Jul 31 01:28:11 Mmmmmm ABE Jul 31 01:32:51 ds2: is that a sound of approval? I never really looked into it Jul 31 01:34:07 it looked like it could maintain audio flows even when most of the SoC is powered off to conserve battery charge Jul 31 01:55:57 zmatt: I liked ABE Jul 31 01:56:13 it gives me an audio cross connect Jul 31 01:59:50 is it normal to measure 38V between the beaglebone's ground and earth ground? Jul 31 02:00:41 there's no measurable current when I switch my multimeter to mA or uA Jul 31 02:01:11 I assume this is because the supply is floating Jul 31 02:03:33 wtf. your meter broke ;P Jul 31 02:03:38 or your beagle is dead. Jul 31 02:03:48 neither seems to be true Jul 31 02:03:55 oh .. well .. ground is often floating Jul 31 02:04:06 there's probbaly no connection :P Jul 31 02:04:10 that's measuring AC voltage Jul 31 02:04:16 looking at the scope, it moves at 60Hz Jul 31 02:04:29 yeah it's picking up radiated mains :p Jul 31 02:06:52 is that a normal amount, or more than expected? Jul 31 02:07:14 I'm trying to track down noise, as it's interfering with my GPS receiver Jul 31 02:16:56 ds2: it's only on the omap4 and 5 right? Jul 31 02:17:47 ddrown: you can pick up pretty much anything Jul 31 02:18:59 zmatt: ok Jul 31 02:19:19 ddrown: even more fun is devices that were designed to be grounded, but aren't Jul 31 02:20:04 then it's normal to pick up roughly mains/2 (i.e. 55V if you have 110V mains, 115V if you have 230V) Jul 31 02:21:24 hopefully with very low impedance and not too much capacitance though Jul 31 02:21:26 eh Jul 31 02:21:29 very high impedance Jul 31 02:22:37 but I'd expect a typical 5V adapter to be isolated (and in fact lack a ground pin) Jul 31 02:22:49 yeah, no ground pin on this one Jul 31 02:23:03 I measure 79k ohms to earth ground, though Jul 31 02:23:17 not sure if that's right Jul 31 02:23:48 this rpi I have here measures 26M ohm to earth ground (from board ground) Jul 31 02:24:05 a typical multimeter cannot measure resistance of anything that's not a simple passive circuit Jul 31 02:24:16 good point Jul 31 02:24:29 38Vac on the rpi's ground Jul 31 02:25:36 no current at uA Jul 31 02:25:37 connect the rpi/bbb ground to earth if it bothers you Jul 31 02:26:03 yeah, I could see if that helps my noise issue Jul 31 02:26:09 I'm guessing it won't Jul 31 02:26:17 but, no current means the 38Vac or whatever is gone the moment you try to draw current from it Jul 31 02:26:29 yeah Jul 31 02:28:51 but, "as it's interfering with my GPS receiver" Jul 31 02:28:59 you mean in the sense of EMI ? Jul 31 02:29:07 noise from somewhere is Jul 31 02:29:16 I'd guess EMI Jul 31 02:29:31 but the GPS module is on a BBB cape Jul 31 02:29:41 ah that's what I was about to ask Jul 31 02:29:48 ok, that does make things more interesting Jul 31 02:30:11 if I put it directly on the cape, I get various issues Jul 31 02:30:26 if I put it on a breadboard with jumper wires, those issues mostly go away Jul 31 02:30:40 check Jul 31 02:30:48 plenty of potential noise sources Jul 31 02:31:14 yeah Jul 31 02:31:41 make sure stuff you don't use isn't enabled, especially HDMI Jul 31 02:32:03 hm, I think HDMI is disabled, I needed one of the pins... Jul 31 02:32:07 ok Jul 31 02:32:39 ok maybe not Jul 31 02:32:55 HDMI and HDMIN both show up on capemgr Jul 31 02:33:12 that doesn't mean they're enabled I think Jul 31 02:33:19 especially since those two conflict Jul 31 02:33:33 cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN Jul 31 02:33:38 that's in my uEnv.txt Jul 31 02:33:39 exactly Jul 31 02:33:47 that should disable them Jul 31 02:34:17 I'm not sure, I don't use capemgr on any BBB here Jul 31 02:34:34 [ 0.554722] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMI Jul 31 02:34:37 ... Jul 31 02:34:46 I think that's working Jul 31 02:35:56 you can also check /sys/class/drm/ Jul 31 02:36:31 has a single file, version Jul 31 02:36:52 i.e. no graphics devices, LCD controller has not been enabled in device tree Jul 31 02:37:22 no /dev/fb* either Jul 31 02:38:01 in a way this is bad news: the favorable outcome would be if the noise is somehow induced from expansion header pins Jul 31 02:38:19 yeah Jul 31 02:38:20 but there aren't that many candidate pins, which means direct EMI is more likely Jul 31 02:39:06 I think the system clock (the 24MHz) actually slightly changes frequency for on board vs farther away Jul 31 02:39:29 I can't be absolutely sure due to temperature effects and all that Jul 31 02:39:42 that sentence doesn't even make sense Jul 31 02:39:45