**** BEGIN LOGGING AT Tue Jan 20 02:59:59 2015 Jan 20 03:00:10 I could do kernel-space i guess Jan 20 03:00:23 but I was exploring options and hoping that a simple irq handler would be easier Jan 20 03:03:00 oh, you need microsecond? that'll be harder Jan 20 03:03:04 why are you reading adcs in the PRU?! Jan 20 03:03:20 as opposed to? Jan 20 03:03:31 on the cortex Jan 20 03:03:45 interrupt handler latency is between 12.5us-21us - http://dan.drown.org/bbb/run11/interrupt-latency.png Jan 20 03:04:07 this is continuous capture, doing months at a time. in the PRU I can collect data without being interrupted Jan 20 03:04:14 BBB, 3.8 kernel Jan 20 03:04:30 if you need microsecond accuracy, you better check on the xtals Jan 20 03:04:49 you can do the same on the cortex Jan 20 03:04:58 i am sampling aduio from the adcs using just the cortex Jan 20 03:05:39 ddrown, thats fine - if I get an interrupt every 100 microseconds or even millisecond then the irq handler once it starts gets the time from the kernel and the current sample regardless of when it was called Jan 20 03:05:50 ds2, how? the examples I found online sampled using the PRU Jan 20 03:06:05 you cannot get good timing reading from the PRU Jan 20 03:06:12 just follow the TRM Jan 20 03:06:25 there is no reason to use the PRU; it only makes things worse Jan 20 03:07:39 any accesses outside of the PRU is subject to potential bus traffic delays. it is no longer realtime Jan 20 03:08:01 ds2, if you are in userspace on the cortex and sampling the adcs continuously, your thread will frequently be paused for arbitrary amounts of time during which you aren't capturing. how do you get around that? Jan 20 03:08:21 I do not work in userspace Jan 20 03:08:38 1) DO NOT ACCESS HW IN USERSPACE. EVER. Jan 20 03:08:55 2) You ask the HW to do all the timing for you. the HW knows best. Jan 20 03:09:11 using the HW gets you close to within the jitter of the xtal Jan 20 03:09:36 ds2, do you have example code I can look at? Jan 20 03:10:07 not really... all my code has 3248984329184094 #if's from experimenting with options Jan 20 03:10:20 not helpful to anyone that doesn't know the history of the code Jan 20 03:10:24 one day, I'll clean it up Jan 20 03:10:32 and get the alsa interface to work :( Jan 20 03:10:59 ds2, how severe is the downside of reading from the PRU into a ring buffer? Jan 20 03:11:24 donno, there are no published numbers for delays on the bus Jan 20 03:11:34 bbl, traffic is clear Jan 20 03:11:54 ds2, i found a source saying 5-8 cycles Jan 20 03:12:11 for what? Jan 20 03:12:28 do you know the priority for the ADC module? Jan 20 03:12:40 might be on later Jan 20 03:12:56 aight, thanks for the help. cya Jan 20 03:37:04 is there a new debian 7.7 non-flash console image for the bbb that supports ndis? Jan 20 03:37:53 i've tried bone-debian-7.7-console-armhf-2014-12-19-2gb.img but it doesn't work for me (won't even boot) Jan 20 04:02:42 ok, i just got bone-debian-7.7-console-armhf-2014-12-31-2gb.img to boot, but it doesn't seem to support ndis Jan 20 04:03:13 g_multi is absent from lsmod Jan 20 04:03:43 is g_multi normally loaded at boot time, or does some other event trigger it to load? Jan 20 04:04:42 and even though iface usb0 is defined in /etc/network/interfaces, issuing a "ifup usb0" gives "Cannot find device usb0. Failed to bring up usb0." Jan 20 04:06:11 what am i missing? Jan 20 04:06:37 the normal network i/f (eth0) starts fine Jan 20 05:02:36 can I use an sd card as extra memory? Jan 20 05:52:03 hmmm Jan 20 05:52:19 people really need to read the TRM Jan 20 06:00:27 people really need to get off the channel if they don't want to help. Jan 20 06:37:36 hii Jan 20 06:40:57 does anybody know what is the microcontroller in beagle board Jan 20 06:45:35 AM335x Jan 20 08:26:23 hi Jan 20 08:27:55 i have question about how can i instal lcd 7" on the bbb Jan 20 08:28:08 win ce Jan 20 08:28:45 need some source or program? Jan 20 08:29:49 or win ce automaticaly detect lcd? Jan 20 08:31:52 anybody here? Jan 20 08:32:09 ayub: i guess you should ask your win ce supplier Jan 20 08:32:40 * av500 winces Jan 20 08:32:49 in the forum? or? Jan 20 08:33:32 ayub: i have no idea who gave you win ce. Jan 20 08:33:57 ok Jan 20 08:34:19 where did u get wince for beaglebone? Jan 20 08:34:51 fell of a truck... Jan 20 08:34:57 off* Jan 20 08:35:06 LOL Jan 20 08:36:42 i've seens some demonstration version but none ful working, so I'm wondering who's supplying it Jan 20 08:36:57 LetoThe2nd :u think bbb best for linux or wince? Jan 20 08:40:16 good morning Jan 20 08:40:59 last night I hear about the CAN bus, why would anyone here hook up a BBB to their car? Jan 20 08:45:15 thought the cars today use the LIN bus... Jan 20 08:45:19 cityoflights2 : i have question about wince Jan 20 08:45:38 how can i install lcd 7" on the bbb Jan 20 08:46:39 ayub: i think using hdmi it should work out of the box. Jan 20 08:49:11 yes i know but i need lcd Jan 20 08:50:30 on the linux or android we need set source Jan 20 08:50:41 generally you need a driver for the lcd. perhaps ask the lcd manufacturer. but I think they will not have one. Jan 20 08:51:32 ok Jan 20 08:52:08 BennyB_: LIN is for stuff like all the buttons in your door Jan 20 08:52:08 for linux there is a lil cool framebuffer driver available for different lcds. maybe have a look on this? https://github.com/notro/fbtft/wiki Jan 20 08:52:19 BennyB_: low bandwidth stuff Jan 20 08:53:02 so your door has a CAN node that then uses the LIN bus for window motor and buttons Jan 20 08:53:06 sure, lin for short ways, long ways inside car use CAN Jan 20 08:53:13 yup Jan 20 08:53:33 but, thats all I (need) to know *g* Jan 20 08:53:44 it's not by business Jan 20 08:54:56 ayub: I thnk If you have the choice go for linux (debian) on the bbb Jan 20 08:56:22 tanx Jan 20 08:56:51 but my program writed on the windows Jan 20 08:57:33 too bad Jan 20 08:57:54 ayub: if you need wince on the BBB then you need to talk to companies that offer wince for BBB Jan 20 08:57:59 not to us, we know nothing about it Jan 20 09:31:31 ayub: sorry for the delay, In general most of us tend to mainly support linux here Jan 20 09:31:44 wince is really not used any more Jan 20 09:34:52 I just got a FLIR camera and it has WinCE in it :O Jan 20 09:36:04 there will always be exceptions .. Jan 20 09:36:37 sure, I was just a bit surprised by that. Jan 20 09:36:50 I'd go so far to say windows ce isn't Officially supported on the beaglebone black .. but .. I -could- be mistaken .. :p Jan 20 09:40:07 I'm sure the AM335x is supported on Windows Embedded Compact (which is the "new" CE) Jan 20 09:40:35 but of course not sure about any of the peripherals Jan 20 09:45:11 curiosity got the better of me .. https://github.com/zapta/linbus .. lin hacking :D Jan 20 10:00:47 hi everybody Jan 20 10:02:36 I think the booting of the beagleboard if you want to boot it from the MMC by pressing the USER button is finally dominated by the NAND boot at last Jan 20 10:02:49 what you guys have to say about it Jan 20 10:02:54 ????????????? Jan 20 10:04:51 hello Jan 20 10:05:30 hi piyush_ Jan 20 10:05:51 wow IRC is great Jan 20 10:05:58 yeah Jan 20 10:49:07 Piyush: have you RTFM? Jan 20 10:49:23 Piyush: the boot process has been described in many documents in great detail Jan 20 10:49:32 what is RTFM Jan 20 10:49:37 read the fucking manual Jan 20 10:49:39 ????? Jan 20 10:49:46 also, learn how to google Jan 20 10:49:56 sorry Jan 20 10:50:01 for stupid one Jan 20 10:50:08 :) Jan 20 10:50:11 ok Jan 20 10:50:12 ok Jan 20 10:50:31 koth I got the SD card bootable Jan 20 10:50:55 congratulations Jan 20 10:51:15 but the problem which I am facing is that my beagleboard stops at Jan 20 10:51:16 Loading u-boot.bin from nand Jan 20 10:51:26 and do not move ahead Jan 20 10:51:54 that's what is the problem I am facing right now from past two five days Jan 20 10:52:29 actually I browsed a lot and there is no definite solution to it Jan 20 10:52:42 one discussion is there Jan 20 10:52:57 but that guy also went for the serial boot Jan 20 10:53:14 after all his effort fall in vain Jan 20 10:54:09 anyway koth which country you are from Jan 20 10:54:11 ????? Jan 20 10:55:57 the use of multiple question marks is a sure sign of a diseased mind Jan 20 10:56:25 !!!!! Jan 20 10:57:05 Piyush: what board do you have? Jan 20 10:57:19 beagleboard Jan 20 10:57:23 if you have a serial connection, please use pastebin paste a boot log Jan 20 10:57:38 original beagleboard? Jan 20 10:57:43 yes Jan 20 10:57:43 with NAND? Jan 20 10:57:45 ah Jan 20 10:57:47 version c4 Jan 20 10:57:49 best is to erase the NAND Jan 20 10:57:52 yesh Jan 20 10:57:54 yeah Jan 20 10:57:58 then it will always boot from SD Jan 20 10:58:20 ok Jan 20 10:58:36 actually what I did av500 Jan 20 10:58:40 if you can get into uboot, the command is something like "nand erase" Jan 20 10:58:51 yes yes Jan 20 10:58:56 that's what I did Jan 20 10:59:18 so? Jan 20 10:59:25 now If I start my beagleboard without MMC than it shows up 40W Jan 20 10:59:37 yes Jan 20 10:59:42 it means the NAND is completely erased Jan 20 10:59:51 well, it cannot find MLO Jan 20 11:00:03 but yes, it should be erased Jan 20 11:00:12 and 40W means the beagleboard is acknowledging the power up of the board Jan 20 11:00:13 now make an sd card and boot from that Jan 20 11:00:27 that's what I am doing Jan 20 11:00:49 I followed the following instructions from the following link : Jan 20 11:00:55 let me give you the link Jan 20 11:01:03 https://linuxlink.timesys.com/docs/gsg/beagleboardxm Jan 20 11:01:13 thats for XM Jan 20 11:01:33 since you see the 40W, please collect a boot log and pastebin it Jan 20 11:01:59 yeah but I think the SD card formatting and making it bootable is same for every OMAP3 borad Jan 20 11:02:48 as said, pastebin a boot log Jan 20 11:02:53 am sorry to ask this it might be little awkward av500 but can you just hint me how to get the boot log Jan 20 11:03:14 well, I guess you run some terminal SW Jan 20 11:03:19 since you see the 40W Jan 20 11:03:27 yes Jan 20 11:03:29 teraterm Jan 20 11:03:33 on win7 machine Jan 20 11:03:37 so copy that output and go to pastebin.com Jan 20 11:03:42 ok Jan 20 11:03:47 I am pasting it Jan 20 11:03:52 thanks Jan 20 11:03:59 wait for few seconds Jan 20 11:05:21 here is the link where I pasted it Jan 20 11:05:23 http://pastebin.com/HbPG73Lm Jan 20 11:05:52 your MLO is ancient Jan 20 11:06:03 OK Jan 20 11:06:09 it seems to be one that only knows nand Jan 20 11:06:26 but I am using all the prebuilt images from the following link Jan 20 11:06:30 http://beagleboard.org/latest-images Jan 20 11:06:51 you use something from 2009 Jan 20 11:07:33 https://code.google.com/p/beagleboard/downloads/list Jan 20 11:07:40 I am using this one Jan 20 11:08:37 yes, see the dates Jan 20 11:08:41 5 ys ago Jan 20 11:08:48 please use what I linked to Jan 20 11:08:58 yes av500 Jan 20 11:09:07 I just started the download Jan 20 11:09:13 thanks for the latest link Jan 20 11:09:29 dont thank me Jan 20 11:09:34 have you used it for your beagleboard Jan 20 11:09:42 its on beagleboard.org Jan 20 11:10:04 well I am thanking you because you find it for me Jan 20 11:10:08 that's it Jan 20 11:11:57 I added you to my friend list of this IRC av500 Jan 20 11:12:02 ;) Jan 20 11:15:48 Hello to all. Where can I get the changelog for the BBB kernel releases? I've been using 3.14.22-ti-r31 but then I saw there's a more recent version of the same kernel, r43, and I'd like to know what has changed and if it's worth changing to it. I'm using ubuntu 14.04 as described in the page http://elinux.org/BeagleBoardUbuntu#eMMC:_BeagleBone_Black Jan 20 11:26:14 smells like a TI kernel Jan 20 11:27:20 nah Jan 20 11:27:22 rcn I guess Jan 20 11:27:46 https://github.com/beagleboard/linux/releases Jan 20 11:29:39 https://github.com/beagleboard/linux/commits/3.14 Jan 20 11:29:56 yeah, RCN stuff, based on a TI re-done kernel? Jan 20 12:16:10 guys I have a question to ask and that is since I have erased my NAND and there is nothing inside the NAND so how come the xloader comes into act if its been erased. Jan 20 12:16:49 you can always boot off a sd card. Jan 20 12:18:15 I thought the best bit about the BB-classic nand was that you could just erase it and forget about it. then live happily ever after. Jan 20 12:22:37 yeah you are right but in this case I am not able to boot from SD card Jan 20 12:22:52 meanwhile I ma waiting for the latesst source to get downloaded Jan 20 12:23:02 which av500 has provided me Jan 20 12:29:14 ah, yeah, get your MLO up to date, that will certainly help Jan 20 13:26:05 Hi everyone! Did someone managed to enable PWM with ubuntu (3.14.26) on Beaglebone Black? Jan 20 14:37:41 Hi all Jan 20 14:40:17 I have been using beagleboard black board (Model No : BBB-RevC-4GB) with ported and running on android. I have wriiten a usbhost APP in my motorola motog device and tried to detect the board. But the app is not detecting. can anyone shed a light on how to do. Jan 20 14:40:31 just the alogorithm to how things can be done Jan 20 14:41:23 you sure the motog supports usb host? Jan 20 14:42:20 yeahg Jan 20 14:42:50 its an android app to detect the device Jan 20 14:42:51 okg Jan 20 14:43:57 my suspicion is that vendorid and productid is wrong Jan 20 14:44:08 how to make it sure? Jan 20 14:49:37 connect BBB to linux machine and use lsusb ? Jan 20 14:50:43 yeah working on that Jan 20 14:50:58 or should I use dmesg? Jan 20 14:51:11 I will ping you after trying this Jan 20 14:51:14 :) Jan 20 15:03:14 Did someone already managed to enable PWM with ubuntu (3.14.26) on Beaglebone Black? We're quite stuck on that... Jan 20 15:03:52 why not use the stock debian? Jan 20 15:04:42 do you mean Angstorm? Jan 20 15:05:10 no Jan 20 15:05:11 It's for a company, they want us to use ubuntu Jan 20 15:05:12 debian Jan 20 15:05:24 is it easier on debian? Jan 20 15:05:46 debian is the stock distro that ships with the BBB Jan 20 15:06:32 though there seem to be issues with PWM too Jan 20 15:06:36 https://www.google.com/search?q=bbb+debian+pwm Jan 20 15:10:33 Hi all Jan 20 15:10:37 I can't get my BBB to boot Jan 20 15:11:04 I downloaded the image, I used Win32Image to put it on a sd card Jan 20 15:11:17 then it booted into a temporary desktop Jan 20 15:11:26 we had this problem too I guess Jan 20 15:11:31 did stuff for half an hour so Jan 20 15:12:22 now it boots, shows the login prompt for a few seconds, then tries to start the GUI, the shows a message about some library not found PHY Jan 20 15:12:31 and 'not found on slave 1' Jan 20 15:12:35 and it stuck there Jan 20 15:12:56 leds are blinking a lot Jan 20 15:12:56 We had that kind of issue and finally we flashed the EMMC from that SD card, maybe that's overkill but we can play with our BBB Jan 20 15:13:18 how did you do that ? Jan 20 15:13:20 But we can't use a screen directly on the BBB Jan 20 15:13:28 oh Jan 20 15:13:32 that sucks Jan 20 15:13:33 We're connected through ssh Jan 20 15:13:44 no, I need the screen Jan 20 15:14:08 yeah that's not pretty handy, but there is probably a solution Jan 20 15:15:40 about the flash, it could be found easily on google, but about the screen I really don't know Jan 20 15:16:38 so far my impression with the BBB has been poor Jan 20 15:16:58 It was working a few weeks ago, then it just stopped booting Jan 20 15:17:04 didn't touch it Jan 20 15:56:28 balrog: using pwm with ubuntu. half a year ago though; worked out of the box Jan 20 15:56:35 sry for the wrong hl Jan 20 15:56:40 didnt notice bartho disced Jan 20 17:04:35 BBB USB boot question: I need to flash a BBB, have no working SD interface, and eMMC is cleared. Will the AM355x be able to find the MLO on a USB flash drive? Jan 20 17:06:37 Rybok: check the am3XXX TRM, the buzzword you're looking for is "SYSBOOT" Jan 20 17:09:44 LetoThe2nd: All right! Checking! Thanks! Jan 20 17:27:51 LetoThe2nd: So, after reading the TRM I think it is very possible to boot a BBB with a total zeroed eMMC from USB, called peripherial boot. But does it work, has somebody tried it? Jan 20 17:30:57 LetoThe2nd: The peripheral boot can take 106k and MLO is 100K... Jan 20 18:56:58 hello - I have a PRU program that copies samples from the ADC's FIFO into the shared memory, then the cortex processes the samples and stores the results in a file. I need to timestamp the samples though (every 100th sample or so), and i'm running into the problem that the cortex knows the time of day but the PRU knows which sample was just captured. How do you suggest I go about this? Jan 20 18:57:31 ds2, you were helping me yesterday but perhaps with that more through description of my setup my goal will make more sense? Jan 20 18:58:33 <_av500_> dont you sample at equal intervals? Jan 20 18:58:40 <_av500_> then you need to know the time only once Jan 20 18:58:51 <_av500_> you can also have the arm write time into shared memory Jan 20 18:58:55 ds2, after I left yesterday I realized what you meant about bus delay - I am using continuous capture on the ADC and using its built in FIFO queue so they shouldn't matter Jan 20 18:59:07 <_av500_> then why do you need timestamps? Jan 20 18:59:39 av500, I need microsecond or better accuracy, and these captures will run for several months so I need to account for clock drift Jan 20 19:00:05 <_av500_> ic Jan 20 19:00:21 physics experiment? Jan 20 19:00:28 <_av500_> well, then have the ARM side write a timestamp to shared memory Jan 20 19:00:32 * tbr struggles to come up with a different use case Jan 20 19:00:44 <_av500_> the PRU reads that and applies to each sample Jan 20 19:01:01 <_av500_> can be once per second, the rest you get from your sample rate Jan 20 19:01:34 tbr, engineering (so, yea basically) - inspecting a power supply's output detect failures microseconds before they happen Jan 20 19:02:31 _av500_, that would make a lot of sense - I had also thought about using a IRQ handler on the cortex (hack uninterrupted execution of some code) or writing a kernel module. Jan 20 19:02:55 _av500_, but I like your solution Jan 20 19:03:02 *nod* sounds like an interesting challenge Jan 20 19:03:38 I'm suddenly grateful, that I get away with reading ADC values from sysfs using python. Jan 20 19:04:12 tbr, yeah - I found some of the pru-based drivers that do that and there sure is a lot of magic in the background :p Jan 20 19:04:13 then again running @IoToilets is also a much less demanding use case Jan 20 19:05:16 but I am sampling at 20+ KHz (ideally maybe even in the MHz range) and the cortex is pretty much pinned with my analysis algorithm Jan 20 19:05:33 but the PRUs save the day Jan 20 19:07:26 _av500_, ok, so lets say in c on the cortex I get a timestamp -- trouble is, immediately after doing so my thread may stop being executed and by the time the kernel awakens it again the timestamp is stale -- how do I get around that? Jan 20 19:08:05 <_av500_> ocamlman: I would write a kernel module Jan 20 19:08:41 <_av500_> you can also play with RT priority for your time thread Jan 20 19:09:02 _av500_, I guess the really gross solution is: ts = clock_gettime(); get_getsample(); if(clock_gettime > ts1 + 2micoseconds) throw out timestamp; Jan 20 19:09:34 <_av500_> hmm Jan 20 19:09:37 <_av500_> dont understand Jan 20 19:09:46 <_av500_> I understood you are sampling at regular intervals Jan 20 19:09:48 that way I can detect is the kernel stopped execution during the critical part of my thread and try again.... but again... gross Jan 20 19:09:55 <_av500_> so you basiclaly know the rough time by counting samples Jan 20 19:10:08 <_av500_> all you need is to aling that to the real wall clock time Jan 20 19:10:28 can the pru read the dmtimer peripherials? Jan 20 19:10:31 <_av500_> and your drift will be long term Jan 20 19:10:37 _av500_, I am sampling the ADC at regular intervals, but I need to account for drift (I am using a GPS with PPS signal to set the system clock on the cortex) Jan 20 19:10:45 <_av500_> yes Jan 20 19:11:01 <_av500_> ocamlman: why not feed that PPS to the PRU? Jan 20 19:11:06 <_av500_> there is your time already Jan 20 19:11:25 <_av500_> count PPS on the PRU and you have a long term accurate time Jan 20 19:11:29 <_av500_> no linux involved Jan 20 19:11:39 _av500_, PPS doesn't give me wall-clock time which I need. I could use PPS to PRU but then I need the starting time Jan 20 19:11:40 PPS isn't every second if you lose satelite coverage Jan 20 19:11:54 <_av500_> ddrown: does not matter Jan 20 19:11:57 <_av500_> it will come back Jan 20 19:12:06 _av500_: true Jan 20 19:12:07 <_av500_> and his drift wont make him lose one second easily Jan 20 19:12:23 <_av500_> so you can still divide by sample rate to get seconds from sample clock Jan 20 19:12:29 <_av500_> and compare that to PPS clock Jan 20 19:12:42 <_av500_> we only need long term alignment Jan 20 19:12:52 _av500_, so if I can accurately timestamp the first signal then PPS to the PRU is sufficeint -- but then we get to the sampe problem. how to get wall-clock time of the first sample Jan 20 19:12:57 <_av500_> but yes, PPS might be lost, so Linux writing 1s time stamp to PRU Jan 20 19:13:16 <_av500_> ocamlman: how accurate to real time do you need that? Jan 20 19:13:22 <_av500_> second? Jan 20 19:13:22 <_av500_> ms? Jan 20 19:13:25 microsecond Jan 20 19:13:27 <_av500_> 1/20khz? Jan 20 19:13:34 <_av500_> well Jan 20 19:13:44 <_av500_> your linux system is not us accurate to GPS time Jan 20 19:14:22 _av500_, i'm using the linux_PPS kernel module which sets system time with the PPS signal Jan 20 19:14:27 <_av500_> yes Jan 20 19:14:32 <_av500_> how accurate is that? Jan 20 19:14:37 (or, I plan to be -- am not yet, but internet says it can be done) Jan 20 19:14:56 <_av500_> well, then use that module to write a 1/s timestamp to the PRU Jan 20 19:15:19 pps-gpio has a ~10us offset due to interrupt latency if you're using that Jan 20 19:15:59 <_av500_> wont a GPS module create PPS from a PLL if signal is lost? Jan 20 19:16:01 so I actually have 15 of these devices and I need to sync their signals. So as long as the offset is roughly the same on all the devices I am OK Jan 20 19:16:11 _av500_: for a short while, but not forever Jan 20 19:16:25 <_av500_> well, forever you will have drift Jan 20 19:16:36 <_av500_> so if there is no GPS, the system is fucked anyway Jan 20 19:16:48 ocamlman: that should be true as long as their cpu frequencies are the same (cpufreq idle vs max) Jan 20 19:16:57 <_av500_> that can be handled Jan 20 19:17:33 cpu frequency changes how long it takes to run the interrupt handler :) Jan 20 19:17:34 <_av500_> but in this case, sanmpling PPS on the PRU is much better in fact Jan 20 19:17:42 <_av500_> no latency at all Jan 20 19:17:54 <_av500_> and you can use linux time to get rough aligment Jan 20 19:17:56 what sort of timer peripherals does the PRU have access to? Jan 20 19:18:03 <_av500_> and the PPS from the PRU for fine tuning Jan 20 19:18:11 yeah, linux can provide nearest 1s Jan 20 19:18:12 <_av500_> ddrown: no idea, but what for? Jan 20 19:18:23 <_av500_> it does not get more accurate than PPS Jan 20 19:18:32 _av500_: or I guess - how would you measure the PPS on the PRU? the dmtimer? Jan 20 19:18:37 <_av500_> why measure? Jan 20 19:18:43 <_av500_> just flip a bit on each PPS Jan 20 19:18:50 <_av500_> or increase a counter Jan 20 19:18:50 measuring time Jan 20 19:18:54 <_av500_> what for? Jan 20 19:18:59 <_av500_> yoiu know your ADC rate Jan 20 19:19:03 on each PPS I can log the current sample ID Jan 20 19:19:06 from the PRU Jan 20 19:19:24 <_av500_> or that Jan 20 19:19:30 oh ok, so # of sample after the PPS Jan 20 19:19:38 <_av500_> or you simply pair sample and PPS count Jan 20 19:19:49 <_av500_> so lets say you sample 10khz Jan 20 19:19:49 that precision will be limited by your sample rate Jan 20 19:19:57 <_av500_> every 10000 samples the PPS count increases Jan 20 19:20:20 <_av500_> and you can measure your sample rate this way too Jan 20 19:20:31 <_av500_> number of samples between PPS increases Jan 20 19:20:33 you'll know time within ~100us in that example Jan 20 19:21:10 <_av500_> if you assume the ADC clock jitters around that range Jan 20 19:21:22 <_av500_> if it does, you cant get better anyway Jan 20 19:21:47 <_av500_> but if you assume the adc lcock is stsble, but long term drifts Jan 20 19:21:52 <_av500_> you get get better than 100us Jan 20 19:22:21 <_av500_> but why not drive ADC clock from the PPS? Jan 20 19:22:29 <_av500_> get a GPS with 10mhz out Jan 20 19:22:33 <_av500_> from PPS Jan 20 19:22:36 <_av500_> temp controlled Jan 20 19:22:38 <_av500_> etc... Jan 20 19:22:42 can you do that? Jan 20 19:22:43 <_av500_> then use that as sample clock base Jan 20 19:22:45 <_av500_> sure Jan 20 19:22:52 Why do GPS? Just get a CDMA/Rb shelf. Jan 20 19:22:58 And use the 10MHz out on that., Jan 20 19:23:07 I mena, since it seems to really matter. Jan 20 19:23:09 <_av500_> html Jan 20 19:23:11 <_av500_> oops Jan 20 19:23:15 <_av500_> http://www.hanssummers.com/gpsref.html Jan 20 19:23:33 <_av500_> This homebrewed 10MHz frequency reference is locked by the GPS satellite system and achieves an estimated accuracy of 10,000,000.000 +/- 0.002Hz in normal operation. Jan 20 19:23:56 http://navspark.mybigcommerce.com/ns-t-precision-timing-mode-gps-receiver/ < another example Jan 20 19:24:02 Laureline. Jan 20 19:24:28 do I need to use the linux_PPS in order to expect second-resultion timing from linux? Jan 20 19:25:33 ocamlman: network based ntp will get you in the milliseconds level of accuracy Jan 20 19:25:43 depending on your network conditions Jan 20 19:25:56 probably more like tens of milliseconds Jan 20 19:26:02 excelent - thanks guys! Jan 20 19:26:36 <_av500_> it all depends on what timing accuracy you really need Jan 20 19:26:40 oh, one corner-case though Jan 20 19:27:01 <_av500_> if you need to sync remote stations within us, GPS and a GPS derived clock probybly the best Jan 20 19:27:08 if I get linux time, log time, cross second boundry, then get PPS I will be one second behind Jan 20 19:27:10 <_av500_> but I would leave linux out of that Jan 20 19:27:42 <_av500_> ocamlman: you get <1s accuracy in linux Jan 20 19:27:45 <_av500_> its not that bad Jan 20 19:28:11 <_av500_> do it every 100ms and you will sample the second jump for sure Jan 20 19:28:27 you should probably pass the milliseconds from linux, so you can tell if you're closer to the end or the start Jan 20 19:28:34 _av500_, but if I log that it is 1:22:23 999.9999999 then by the time I write that It will be 1:22:24 Jan 20 19:28:38 so when the PPS happens you can tell if its this second or the next Jan 20 19:29:01 your system clock would just need to be within 500ms Jan 20 19:29:12 Use PTP to synchnronize the Linux installations between modules. Jan 20 19:29:25 yeah, PTP is a decent option. the BBB has hardware for it Jan 20 19:29:42 Im not familiar with PTP. >googling Jan 20 19:29:46 doesn't solve the problem of ADC sampling timing, though Jan 20 19:30:03 <_av500_> if you really need ADC samples with 1us accuracy Jan 20 19:30:10 <_av500_> you need a clock that is that accurate Jan 20 19:30:12 No, but it does solve the issue of getting the timestamps down below ocamlman's requirements. Jan 20 19:30:17 PTP/IEEE1588 is pretty much hardware-assisted NTP Jan 20 19:30:24 Not really, no. Jan 20 19:30:34 ok, it doesn't use the same protocol Jan 20 19:30:40 but it has similar goals Jan 20 19:31:01 PTP gets you between ns and us without calendar time. NTP gets you calendar time, but only down to the us-10us level. Jan 20 19:31:06 THey are complementary protocols. Jan 20 19:32:17 PTP does things like let me guarantee that the images collected from a series of GigE cameras all were collected within a few ns of each other. Jan 20 19:32:32 Has anyone here used the am335x's PTP hardware timestamping? Jan 20 19:32:54 georgem: I've run a simple test with it Jan 20 19:32:55 NTP lets me ensure that the computers that process said images have clocks within a tolerable distance from each other. Jan 20 19:33:17 had to recompile the kernel to enable it Jan 20 19:36:03 ddrown: I remember seeing before in the kernel config (maybe it was 3.8 vendor kernel) but I'm not seeing upstream (3.19.0-rc4) Jan 20 19:38:06 in 3.8 it's CONFIG_TI_CPTS Jan 20 19:38:46 okay, there it is. Jan 20 19:44:57 someone called? Jan 20 19:46:09 what is the question? Jan 20 19:46:12 <_av500_> 42 Jan 20 19:46:20 26+26 Jan 20 19:47:02 54 Jan 20 19:48:25 yeah, looks like linuxptp works with the hardware timestamping drivers. I'll have to see if I can get my hands on a master clock to mess around with it. Jan 20 19:53:34 the BBB can be a master clock, although I assume actual master clock hardware is nicer Jan 20 19:55:43 georgem: build one yourself ;) Jan 20 19:57:08 georgem: easiest: use two BBBs, both clocked from an OCXO, record the phase differences of the two OCXO using a timepod, let the ptp software record the relative time drift, compare data :) Jan 20 19:59:17 Hello KotH, cheif Chocolate Troll Jan 20 19:59:27 greetings mrpackethead Jan 20 19:59:33 how are the LEDs? Jan 20 19:59:39 Crazy busy Jan 20 19:59:52 keeps us in vegetables at least Jan 20 20:00:31 KotH: don't have a timepod either. Jan 20 20:00:33 KotH, i was just wondering if you had ever used Vapour Phase Reflow Jan 20 20:00:38 georgem: hmm... Jan 20 20:01:04 georgem: i'm planing to build somethign similar. but it wont happen until next year :-/ Jan 20 20:01:24 mrpackethead: yes...well.. we used an assembly house that used vapor phase Jan 20 20:01:30 mrpackethead: why? Jan 20 20:01:38 i just considering getting one Jan 20 20:01:48 for your shack? Jan 20 20:01:53 yup Jan 20 20:01:57 that's pretty much a waste of money Jan 20 20:01:58 "cave" actually Jan 20 20:02:05 why do you say its a waste Jan 20 20:02:06 unless you need the better capabilities Jan 20 20:02:15 BGAS' Jan 20 20:02:39 because it's a lot harder and more expensive to keep a vapor phse oven running than a normal reflow oven Jan 20 20:02:48 they argue its not Jan 20 20:02:54 its considerably less energy Jan 20 20:03:06 Not looking at a inline system Jan 20 20:03:08 just a batch system Jan 20 20:03:21 i found this project online Jan 20 20:03:23 http://bubble.wservices.ch/index.php/DIY_Vapor_Phase_Reflow Jan 20 20:03:24 will you have it loaded at least 50% of the time? Jan 20 20:03:44 somones converted a deep fryer!! Jan 20 20:03:56 i guess we have toaster reflow Jan 20 20:04:04 now its Deep fryer reflow Jan 20 20:04:15 mrpackethead: What is it you are doing to send ^H at the beginning of some of your lines? Jan 20 20:04:54 agmlego|skynet: no idea. nobodys ever said anything about any ^H's before Jan 20 20:06:24 15:03 < mrpackethead> HNot looking at a inline system Jan 20 20:06:50 KotH: and these guys.. this is just really funny! https://www.youtube.com/watch?v=WhymoY3ZHjY Jan 20 20:06:56 Except on my terminal, that H is a Ctrl-H character (inverted text) Jan 20 20:07:04 agmlego|skynet: most likely a fuck up by the irc client. ^H is a backspace Jan 20 20:07:11 Yeah. Jan 20 20:07:23 My guess is mrpackethead is seeing relatively high lag to Freenode. Jan 20 20:07:52 Er, to his client, maybe? Not the Freenode; that would be different behavior. Jan 20 20:08:20 does it matter? just block me, from what you see if you dont' like it. Jan 20 20:08:51 I am deeply, truely, honestly and sincerly sorry for sending you ^H Jan 20 20:08:52 agmlego|skynet: LimeChat for Mac 2.42 Jan 20 20:08:56 mrpackethead: ...wow, OK, just trying to help you. Jan 20 20:08:58 agmlego|skynet: i think that says it all Jan 20 20:10:11 KotH: so, why did you think it woudl be wasteful to have a vapour phase Jan 20 20:10:36 mrpackethead: maintenance of the system is much higher than with reflow Jan 20 20:10:52 mrpackethead: if you dont use it regularly (like 50% of the time) it's not worth it Jan 20 20:10:52 yes, agree. oven, turn it on Jan 20 20:12:38 thats a bold statement Jan 20 20:14:00 i like to make bold statements Jan 20 20:14:18 *all the bold statements* Jan 20 20:14:42 i'm kind of seriously thinkng about trying to convert a Deep fryer Jan 20 20:14:47 if i fail, i learn somethign Jan 20 20:14:52 if i suceeed, well Jan 20 20:15:04 the expensive bit is the Galden 230 Jan 20 20:15:09 about $900 for a 4L Jan 20 20:23:53 Is there a good example of how to get a pulse generator attached to GPIO to trigger interrupts on the PRUSS? (including pin mapping on 3.8 kernel?) Jan 20 20:30:27 <_av500_> PRU has no IRQs Jan 20 20:30:29 <_av500_> no? Jan 20 20:31:16 PRU has fake interrupts. they call them interrupts: http://processors.wiki.ti.com/index.php/PRU_Interrupt_Controller Jan 20 20:32:00 _av500_, I'm just looking to set up the PPS on the gps to one of these so I can query at my convenience Jan 20 20:35:46 _av500_, the GPS outputs a 1ms pulse, but I just want to catch the rising edge Jan 20 20:41:38 ocamlman: what you can do instead is, timestamp the PPS using the capture/compare, then timestamp your samples using the same timer Jan 20 20:41:50 ocamlman: should give you sub-us accuracy Jan 20 20:43:40 KotH, i'm not familiar with capture/compare -- is this a SoC device? Jan 20 20:44:31 KotH: the PRU can access the dmtimers directly? Jan 20 20:46:04 if so, that's probably the best way Jan 20 20:46:35 ocamlman: yes Jan 20 20:46:45 ocamlman: look at the TRM, there is a section on timers Jan 20 20:47:04 eCAP capture mode? Can you use it from the PRU? Jan 20 20:47:04 ocamlman: also search for BBB and PPS, there is some stuff around Jan 20 20:47:29 georgem: i dont think you can use it directly, but you can at least read the register from the PRU Jan 20 20:47:37 ah ok Jan 20 20:47:44 georgem: it wont be hyper exact, but at least better than anything else Jan 20 20:49:20 KotH, should I be reading the eCAP documentation? Jan 20 20:49:57 ocamlman: maybe.. i dont know the TRM by heart Jan 20 20:50:26 KotH, but that is the subsystem I should use, ya? Jan 20 20:50:50 most likely Jan 20 20:51:01 i dont know how Ti calls all the parts of its SoC Jan 20 20:51:22 * KotH doesn't own a BB* after all Jan 20 21:26:49 hmmm Jan 20 21:36:47 why use ecap and not epoll() a gpio? Jan 20 21:39:17 cityLights, I'm dong this from a PRU Jan 20 22:21:11 on page 243 of the RTM ( http://elinux.org/images/6/65/Spruh73c.pdf ) is the PRU constants table. whats the difference between ecap (entry 3) and eCAP1 (entry 18)? Jan 20 22:26:23 looks like the PRU subsystem has a dedicated eCAP... perhaps thats it? Jan 21 01:16:16 the PRU has a "dedicated" eCAP - how do I connect it to one of the GPIO pins? Jan 21 01:23:54 hmmm? Jan 21 01:32:49 ds2, for eCAP in capture mode, do you know how many volts I should apply? Jan 21 01:33:03 check the datashet Jan 21 01:33:04 (sorry, didn't mean to address that at anyone in particular) Jan 21 01:33:06 sheet Jan 21 01:33:38 you do realize the PRUSS has its own pinmux, etc that in turn gets muxed, right? Jan 21 01:35:32 yea - I assume though that if i connect to ecap0 from the PRU that it is tied by default to p9_42 Jan 21 01:36:03 it appears that about thew newest non-flash, console version of debian i could find, bone-debian-7.7-console-armhf-2014-12-31-2gb.img, does not provide the ndis interface over usb. Jan 21 01:36:38 does anyone know how to install g_multi and get it running? Jan 21 01:41:18 what happened to rcn? i haven't seen him here in well over a week. Jan 21 01:43:22 or maybe it (g_multi) is on the system already and i have to run a script or somesuch? Jan 21 01:48:44 yates: have you tried finding out if the kernel module is present on the filesystem? Jan 21 01:49:06 jrfood: no, where are the kernel modules located? Jan 21 01:49:32 don't know myself wihtout looking them up Jan 21 01:50:28 also, can i start g_multi (assuming i locate it) with the usb drive capabiity disabled and just use the ndis interface function? **** ENDING LOGGING AT Wed Jan 21 02:59:58 2015