**** BEGIN LOGGING AT Wed Jun 28 03:00:05 2017
Jun 28 03:12:27 <nerdboy> mpflm
Jun 28 03:12:40 * nerdboy eating pizza...
Jun 28 09:45:46 <zeekhuge> maciejjo: hey ! can you please push your latest commits ? that is what you should actually do on daily basis .. as of now, please do it ASAP
Jun 28 12:32:18 <maciejjo> zeekhuge: pushed code to gh
Jun 28 15:50:45 <tlwoerner> weekly meeting in 10 minutes
Jun 28 15:53:06 <_av500_> indeed
Jun 28 15:59:12 <henrix_> hi everyone
Jun 28 15:59:30 <thetransformerr[> hey
Jun 28 15:59:35 <maciejjo> hello
Jun 28 15:59:35 <pmezydlo> hi
Jun 28 15:59:37 <ee> hello
Jun 28 15:59:44 <ravikp7> hi
Jun 28 15:59:48 <pmezydlo> now 00
Jun 28 16:00:21 <zeekhuge> Hello :)
Jun 28 16:00:25 <_av500_> hi
Jun 28 16:00:25 <indu> hello everyone
Jun 28 16:00:29 <Abhishek_> Hi
Jun 28 16:00:29 <m_w> all systems are a go
Jun 28 16:00:37 <_av500_> this year is weird
Jun 28 16:00:44 <_av500_> students are all on time
Jun 28 16:00:45 <_av500_> :)
Jun 28 16:00:50 <ds2> me0w
Jun 28 16:00:57 * _av500_ check them for being bots
Jun 28 16:01:05 <zeekhuge> :)
Jun 28 16:01:15 * nerdboy sends ds2 a couple of cats
Jun 28 16:01:29 <m_w> quickly the turing test
Jun 28 16:01:42 <_av500_> voight kampf
Jun 28 16:02:01 <_av500_> +f
Jun 28 16:02:13 <m_w> are you a robot? (yes/no/maybe)
Jun 28 16:02:23 <_av500_> yes/no/recharge
Jun 28 16:02:26 <thetransformerr[> sorry I cant understand :)
Jun 28 16:02:40 <thetransformerr[> please say again
Jun 28 16:02:41 <indu> human here
Jun 28 16:03:35 <_av500_> 1) Welcome
Jun 28 16:03:38 <_av500_> everybody here?
Jun 28 16:03:53 <ee> yep
Jun 28 16:03:55 <ravikp7> yes :)
Jun 28 16:04:07 <thetransformerr[> yes
Jun 28 16:04:13 <pmezydlo> yes
Jun 28 16:04:16 <indu> here
Jun 28 16:04:41 <_av500_> maciejjo: ?
Jun 28 16:05:07 <_av500_> maciejjo: you need to complete your eval
Jun 28 16:05:33 <_av500_> maciejjo: ?
Jun 28 16:05:38 <zeekhuge> bot ? ;)
Jun 28 16:05:42 <maciejjo> no
Jun 28 16:05:48 <maciejjo> I am here
Jun 28 16:06:01 <_av500_> good
Jun 28 16:06:03 <_av500_> maciejjo: you need to complete your eval
Jun 28 16:06:04 <maciejjo> it is on gsoc page?
Jun 28 16:06:23 <_av500_> yes
Jun 28 16:06:29 <_av500_> well, it says yours is not done
Jun 28 16:06:41 <thetransformerr[> on your dashboard
Jun 28 16:06:48 <maciejjo> ok, I see
Jun 28 16:06:52 <maciejjo> I will do it
Jun 28 16:06:59 <_av500_> thanks
Jun 28 16:07:19 <_av500_> I mean, its in your interest :)
Jun 28 16:07:48 <ds2> recharge please.
Jun 28 16:08:11 <_av500_> ok, so 6 students here, 5 evals in
Jun 28 16:08:17 <_av500_> 2) reports
Jun 28 16:09:24 <nerdboy> who's on first?
Jun 28 16:09:27 <_av500_> ravikp7: did you get help on that USB issue?
Jun 28 16:09:36 <_av500_> nerdboy: sorry, I meant weekklies
Jun 28 16:09:39 <_av500_> weeklies
Jun 28 16:10:12 <_av500_> ravikp7: ?
Jun 28 16:10:15 <ravikp7> av500 : yes, now stuck on uboot
Jun 28 16:10:56 <_av500_> so you need uboot changed?
Jun 28 16:10:58 <_av500_> fixed?
Jun 28 16:11:06 <m_w> I spent quite a bit of time doing bisects to locate the start of the u-boot bootp/tftp failures
Jun 28 16:11:18 <_av500_> ah ic the mails
Jun 28 16:12:41 <_av500_> apart from ravikp7 and uboot, anybody blocked on something?
Jun 28 16:13:56 <_av500_> hello
Jun 28 16:14:03 <_av500_> everybody fell asleep
Jun 28 16:14:08 <_av500_> apart from ravikp7 and uboot, anybody blocked on something?
Jun 28 16:14:18 <thetransformerr[> I wont say blocked, but challenging
Jun 28 16:14:25 <nerdboy> hardware still missing but there should be code...
Jun 28 16:14:41 <ds2> is hw enroute to thetransformerr[?
Jun 28 16:14:47 <indu> no blocker issues as of now
Jun 28 16:14:49 <thetransformerr[> yeah i am talking abt code,
Jun 28 16:14:57 <ds2> nerdboy: did you and wormo get your hw working?
Jun 28 16:14:58 <nerdboy> should be, i thought it all shipped
Jun 28 16:15:30 <nerdboy> we haven't soldered that tiny lead yet
Jun 28 16:15:49 <nerdboy> need to go to the hackerspace i think
Jun 28 16:15:56 <ds2> 'k
Jun 28 16:16:13 <_av500_> thetransformerr[: and you are getting help for the code?
Jun 28 16:16:15 <ds2> nerdboy: did you out in the reset jumper?
Jun 28 16:16:27 <nerdboy> the jumper is easy, the other one not so much
Jun 28 16:16:51 <thetransformerr[> I have intiated epwm from host and now figuring out the ways that how to trigger sensor and input trigger to adc at same time
Jun 28 16:17:37 <nerdboy> are you using the round-robin thing?
Jun 28 16:18:06 <thetransformerr[> means how to store the tx waveform, rx waveform is read by prudaq
Jun 28 16:19:16 <thetransformerr[> so for now I was planning to activate two epwm modules, from first output goes to tx and from second module output goes to prudaq
Jun 28 16:20:10 <nerdboy> you shouldn't need to actually capture the input signal, you already have the parameters
Jun 28 16:20:53 <ds2> we should probally talk after to note bore everyone else with the details
Jun 28 16:21:12 <_av500_> ok
Jun 28 16:21:15 <thetransformerr[> as you wish
Jun 28 16:21:15 <_av500_> lets move on
Jun 28 16:21:24 <nerdboy> yeah, is that your report more or less?
Jun 28 16:21:36 <_av500_> 3) standup reports
Jun 28 16:21:55 <_av500_> yes, thetransformerr[ is scheduled today
Jun 28 16:21:58 <thetransformerr[> my turn for today
Jun 28 16:22:11 <_av500_> ok. go
Jun 28 16:23:05 <thetransformerr[> as I sent in weekly reports, we worked out a way to find delay between two waveforms
Jun 28 16:23:44 <thetransformerr[> and it can handle noise in signal also, at fair level
Jun 28 16:24:50 <thetransformerr[> and now I am working upon making a working code that can generate 40khz wave, and then trigger a tx sonic transducer and dump data of received waveform from receiver transducer
Jun 28 16:25:58 <thetransformerr[> for code, there are many approaches, currently , I have decided to build a setup script ttaht epwm module and sets another req like dto etc
Jun 28 16:26:46 <thetransformerr[> and then using code from prudaq git, we are sampling the rx waveform and then find delay between tx and rx waveform
Jun 28 16:27:02 <thetransformerr[> that should provide us speed of wind in one direction]
Jun 28 16:27:36 <thetransformerr[> any suggestions or advices??
Jun 28 16:28:19 <nerdboy> you should only need to precalculate your input signal once
Jun 28 16:28:48 <thetransformerr[> pls explain a bit more
Jun 28 16:30:20 <thetransformerr[> because I guess we need tx and rx samples at same time for this method to work
Jun 28 16:30:30 <nerdboy> the "data" you need for x-correlation
Jun 28 16:31:17 <nerdboy> yes, the pwm and capture should probably fire off the same interrupt
Jun 28 16:32:11 <nerdboy> did you push the code you're working on?
Jun 28 16:32:36 <thetransformerr[> nope just give me few more hours
Jun 28 16:33:03 <thetransformerr[> i will do it by 1-2 am in my time zone
Jun 28 16:33:04 <_av500_> push early, push often! :)
Jun 28 16:33:28 <_av500_> thetransformerr[: thanks
Jun 28 16:33:40 <_av500_> indu: your turn now
Jun 28 16:33:50 <indu> yes
Jun 28 16:34:18 <indu> My project is to develop a AVB stack for beagle board
Jun 28 16:35:09 <indu> It contains 2 parts. 1. Clock synchronization. 2. Streaming synchronized audio using the synchronized clock
Jun 28 16:36:35 <pmezydlo>  sorry I have to go bye
Jun 28 16:36:45 <indu> The clock sync part is implemented as a daemon. This  uses commands via raw ethernet packets to synchronize the clocks
Jun 28 16:37:19 <indu> the socket timestamping option in the linux kernel is used for this
Jun 28 16:37:46 <indu> The ehternet module in the TI sitara processor provides the hw timestamps required.
Jun 28 16:38:42 <indu> with last week i have completed the clock sync part and able to achieve sync error of 10s of us to 100s of ns
Jun 28 16:39:11 <indu> For example to stream a 48khz audio we need clock sync of atleast 20us
Jun 28 16:39:49 <indu> the next part is to implement  ALSA audio driver which uses the synchronized clock to stream audio via ethernet
Jun 28 16:40:16 <indu> which i assume will be the hardest part
Jun 28 16:40:35 <indu> the clock sync daemon is here -> https://github.com/induarun9086/gPTPd
Jun 28 16:41:13 <_av500_> nice
Jun 28 16:41:15 <indu> any questions suggestions ?
Jun 28 16:41:20 <tlwoerner> it could use a better README :-)
Jun 28 16:41:29 <indu> Will do
Jun 28 16:41:38 <indu> along with the usage information for the daemon
Jun 28 16:41:48 <tlwoerner> great, thanks!
Jun 28 16:42:05 <henrix_> *thumbs up*
Jun 28 16:42:29 <_av500_> ok, so for next week, we keep the original order?
Jun 28 16:42:35 <_av500_> ee and ravikp7 ?
Jun 28 16:42:55 <ravikp7> yeah :)
Jun 28 16:44:26 <_av500_> ee: you too?
Jun 28 16:44:36 * _av500_ rattles his tin cup
Jun 28 16:44:51 <_av500_> indu: thanks for the report
Jun 28 16:45:33 <indu> *thumbs up*
Jun 28 16:46:05 <tlwoerner> i'll ping ee to make sure he's ready for next week :-)
Jun 28 16:46:15 <_av500_> tlwoerner: thx
Jun 28 16:46:16 <ee> Sounds good, sorry I was afk for a minute there
Jun 28 16:46:23 <_av500_> ee: ok
Jun 28 16:46:30 <_av500_> 4) anything else?
Jun 28 16:46:31 <tlwoerner> :-)
Jun 28 16:48:18 <_av500_> guess everybody is happy or tired :)
Jun 28 16:48:19 <_av500_> or both
Jun 28 16:48:23 <_av500_> so
Jun 28 16:48:29 <_av500_> 5) thanks and see you next week
Jun 28 16:48:36 <thetransformerr[> thanks
Jun 28 16:48:40 <_av500_> feel free to stay and engage with mentors
Jun 28 16:48:52 <_av500_> thetransformerr[: -> nerdboy
Jun 28 16:48:55 <_av500_> ravikp7: -> m_w
Jun 28 16:49:31 <ravikp7> sure :)
Jun 28 16:50:02 <_av500_> ok
Jun 28 16:50:08 <_av500_> see you all next week
Jun 28 16:50:47 <ds2> thetransformerr[: if you need to look at the epwm clock on the PRUDAQ, watch the signal levels to makes sure it doesn't overdrive. you may need a divider
Jun 28 16:51:15 <henrix_> see you
Jun 28 16:52:22 <thetransformerr[> okk i would chk it out
Jun 28 16:52:57 <ds2> thetransformerr[: the other thing to prepare for is the rx side may come in weak
Jun 28 16:53:33 <thetransformerr[> that we can amplify with op-amp or something hardware
Jun 28 16:54:25 <zeekhuge> maciejjo: you working on param-transfer to the PRUs ? how you planning to do that ?
Jun 28 16:55:03 <ds2> thetransformerr[: yes but getting that to you within the timeframe is tricky
Jun 28 16:56:05 <thetransformerr[> I can handle s/w at any cost within timeframe
Jun 28 16:57:51 <ds2> nerdboy: wonder if it makes sense for you to setup a test jig and provide remote access?
Jun 28 16:58:11 <thetransformerr[> the peculiar thing in our project is I guess may be the huge number of possiblities that can go with h/w connections
Jun 28 16:59:41 <nerdboy> once we get that thing soldered that might be an option...
Jun 28 17:01:17 <ds2> *nod*
Jun 28 17:01:32 <ds2> nerdboy: when will you get access to a maker space?
Jun 28 17:01:54 <ds2> nerdboy: and are you just missing the wire for TX?
Jun 28 17:02:22 <nerdboy> friend of ours goes to the goleta one, he's supposed to ask
Jun 28 17:03:00 <nerdboy> we need the lead tacked onto R11
Jun 28 17:03:32 <ds2> nerdboy: ping me if it will take a while. we can swap boards over the mail...might be quicker :D
Jun 28 17:03:34 <nerdboy> thetransformerr[: what huge number of possibilities?
Jun 28 17:05:33 <thetransformerr[> like analog switches, timers, gpio/ pwm module, pair of rx/tx or transreceivers or etc everytime
Jun 28 17:07:51 <nerdboy> well, yeah, but we've pretty much narrowed that down
Jun 28 17:28:45 <nerdboy> thetransformerr[: the sooner push your prudaq code the sooner you can get specific feedback
Jun 28 17:29:16 <nerdboy> maybe m_w can help with the timer part
Jun 28 17:31:26 <nerdboy> thetransformerr[: as far as the pwm output part, you already know the parameters for the pulse(s) so you just need the time of the first one
Jun 28 17:31:50 <nerdboy> (assuming you make it look like the board does on its own)
Jun 28 17:33:58 <thetransformerr[> it can be done like this we store a tx waveform for a specific time period and then with prudaq we sample rx channel for that period and then apply x-correlation
Jun 28 17:34:10 <thetransformerr[> and we let pwm run free
Jun 28 17:41:57 <ds2> thetransformerr[: I wonder if we can just capture a GPIO pin connected to the TX and have the PRU note the TX state in every PRUDAQ sample... i think the ADC is 12 bits so if we stash the TX in say bit 15....
Jun 28 17:42:13 <ds2> seems silly to digitize a square wave
Jun 28 17:42:52 <ds2> the drawback is you will probally have a 3-4 sample skew as the ADC has a pipeline + you have the mux
Jun 28 17:43:05 <thetransformerr[> prudaq is 10 bits
Jun 28 17:43:44 <ds2> even better
Jun 28 17:44:24 <ds2> the argument for stashing it in a bit is this keeps the timing info and should simplify the PRU -> Userspace stuff
Jun 28 17:44:27 <thetransformerr[> and i cant understand how we can capture pin connected to tx because it would be in use by pwm
Jun 28 17:44:50 <ds2> thetransformerr[: connect a wire from the PWM out pin to a PRU input pin
Jun 28 17:44:52 <ds2> :D
Jun 28 17:45:12 <ds2> in reality, use a resistor, say 10-22 ohm
Jun 28 17:45:18 <ds2> so if you screw up some SW, things don't fry
Jun 28 17:45:32 <thetransformerr[> yeah but how would then sensor transmit the waves
Jun 28 17:46:05 <ds2> the PWM pin goes to the resistor feeding the PRU AND the sensor
Jun 28 17:46:26 <ds2> the sensor input (at least the MAXQ board) is relatively high impedence (it is an input to a MOSFET)
Jun 28 17:46:32 <thetransformerr[> if that can happen, then it is very good
Jun 28 17:47:00 <thetransformerr[> then we can just put the other end to prudaq
Jun 28 17:47:17 <thetransformerr[> and then we sample tx and rx channel simultaneously
Jun 28 17:47:29 <ds2> yes...well, close to it
Jun 28 17:47:37 <ds2> the ADC has a pipeline, IIRC
Jun 28 17:47:55 <thetransformerr[> I thought it might not be possible to feed one pin to more than one input
Jun 28 17:48:05 <thetransformerr[> 3 cycle
Jun 28 17:48:18 <ds2> well... 2 should be okay, esp. if they are high-Z loads
Jun 28 17:48:32 <ds2> and you signal is relatively slow
Jun 28 17:49:06 <ds2> if you look at the LCD interface, the Pixel clock goes to both the HDMI chip AND the expansion connector for a LCD panel
Jun 28 17:49:30 <thetransformerr[> can 3 cycle skew be handled by taking three extra samples for rx at last and reject those samples for tx
Jun 28 17:49:54 <ds2> in the LCD case, they have a resistor but that is for reflection control; in our case, we want a resistor to prevent us from screwing up in SW (i.e. setting PRU's pin to out put)
Jun 28 17:51:14 <ds2> thetransformerr[: you can buffer it and skew it in SW... i.e. read TX0, read RX0, save(TX0-4, RX0), read TX1, read RX1, save(TX1-4, RX1)....
Jun 28 17:51:30 <ds2> but I suspect it is easier to deskew in your userland piece
Jun 28 17:51:32 <thetransformerr[> ds2: how can I access pwm module sys fs files from pru0, I guess that is possible from ocp, so if you have any idea
Jun 28 17:51:54 <ds2> that way if you change things around, the PRU code can be untouched
Jun 28 17:52:04 <ds2> thetransformerr[:no no no
Jun 28 17:52:23 <thetransformerr[> yeah in userspace now I come to know everything is whole lot much easy
Jun 28 17:52:52 <ds2> thetransformerr[: connect the PWM output pin (physical, i.e. at the expansion connector J8/J9) to the PRU0 in (pick an unused one) with a low value resistor (10-22 is good, anything under 100ohm should be fine)
Jun 28 17:54:30 <ds2> btw - this isn't as a big of a hack as it may seem... similar trick is used to keep the McASP/McBSP clocking stuff happy
Jun 28 17:54:48 <thetransformerr[> :)
Jun 28 17:55:25 <thetransformerr[> but pins are limited as we move towards increasing dimensions
Jun 28 17:55:42 <thetransformerr[> but as of now lets focus on first dimn
Jun 28 17:55:57 <ds2> you just need 2
Jun 28 17:56:16 <ds2> worse case - make X and Y use the same clock
Jun 28 17:56:23 <ds2> so all you need is 1 input pin
Jun 28 17:58:02 * nerdboy had to make more coffee
Jun 28 18:04:34 <nerdboy> the round-robin code has most of what you need
Jun 28 18:05:11 <nerdboy> there should hopefully be enough "headroom" to add your bits
Jun 28 18:06:14 <nerdboy> and like ds2 mentioned you can use the wiring "tricks" for some stuff
Jun 28 18:11:13 <ds2> haven't looked at the PRUDAQ code but you may need to encode the channel it came in on in the upper bits too
Jun 28 18:11:56 <ds2> sub 1MHz sampling should give you about 200cycles to process each sample
Jun 28 18:12:41 <nerdboy> the round-robin code already switches between the two input sources
Jun 28 18:14:40 <thetransformerr[> nerdboy: it switches the channel input using its inbuilt switch, but I guess ds2: is asking to read gpio pin directly with pru
Jun 28 18:15:38 <nerdboy> right now you just need one channel to test
Jun 28 18:16:04 <nerdboy> unless you want to split the filter output to 2 channels
Jun 28 18:17:36 <nerdboy> if you get even one channel working it will be easier to see where you need to modify
Jun 28 18:18:34 <nerdboy> later you can refactor/rewrite as needed
Jun 28 18:19:33 <nerdboy> just stub the second channel for now
Jun 28 18:20:21 <nerdboy> should probably focus on getting the data out for one channel
Jun 28 18:24:23 * nerdboy needs to make another u-boot patch
Jun 28 18:24:47 <ds2> thetransformerr[: yes I am suggesting that
Jun 28 18:24:58 <ds2> nerdboy: OT - why patch U-boot?
Jun 28 18:26:45 <nerdboy> for another piece of hardware
Jun 28 18:37:25 <maciejjo> zeekhuge: sorry, had to leave after the mtg. I plan either to write to PRU DRAM from kernel or use rpmsg to send data to PRU
Jun 28 18:39:45 <maciejjo> zeekhuge: I didn't use rpmsg yet, but it seems convinient
Jun 28 21:24:28 <nerdboy> ds2: looks like the other people are flaking
Jun 28 21:24:50 <nerdboy> board swap is probably best option i guess...
Jun 28 22:42:59 <ds2> nerdboy: 'k can you shoot me a email with mailling address? You just need 1 for the TX side, right?
Jun 28 22:43:31 <nerdboy> somebody just unflaked so i'm taking the boards back to wormo's
Jun 28 22:43:40 <nerdboy> so, nm...
Jun 28 22:56:12 <ds2> 'k... send me the mail if that falls through
Jun 28 23:12:46 <nerdboy> ka6sox promised to do it tomorrow
Jun 28 23:13:11 <nerdboy> so i'm off to wormo's house shortly
**** ENDING LOGGING AT Thu Jun 29 03:00:01 2017