**** BEGIN LOGGING AT Tue Jun 06 03:00:03 2017
Jun 06 16:09:27 <ds2> hmmm
Jun 06 16:15:39 <jic23b> Hmm?
Jun 06 16:15:54 <jic23b> Sorry, hmmm?
Jun 06 16:16:50 <jic23b> Quiet. Presumably no one has any problems!
Jun 06 16:19:25 <ds2> I find that highly doubtful
Jun 06 16:41:18 <ds2> thetransformerr[: how goes things?
Jun 06 16:56:11 <thetransformerr[> I have set-up environment with qemu for compilation, and compiled few hello world sort of programs for pru
Jun 06 16:57:05 <thetransformerr[> and created a pseudo code that I need to convert for reading values from ecap
Jun 06 16:57:52 <thetransformerr[> ds2: I assume you already have a cro and bbb, do you also got some sensors that we can test in cro for their waveform
Jun 06 16:57:58 <thetransformerr[> that if it is feasible with ecap alone
Jun 06 16:59:07 <thetransformerr[> I was assuming I would be the first to receive bbb as jkridner: , ordered it from india store, but it turns out
Jun 06 16:59:48 <thetransformerr[> I am going to be the last one :(
Jun 06 17:02:17 <ds2> I don't have any sensors
Jun 06 17:02:56 <ds2> thetransformer[[: would you mind throwing together a diagram of hw you understand things? I suspect there is a disconnect between all parties
Jun 06 17:03:27 <ds2> s/hw/how/
Jun 06 17:05:11 * thetransformerr[ uploaded an image: Screen Shot 2017-05-25 at 9.56.31 PM.png (111KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/nBfkCKJeZuiNtEFcBwlgratE>
Jun 06 17:05:15 <thetransformerr[> I also think so, have you seen this fig
Jun 06 17:07:27 <thetransformerr[> in this diagram, we can assume a trigger circuit and receiving amplifier circuit b/w ehrpwm and switch respectively
Jun 06 17:09:18 <thetransformerr[> since we have analog switch, to select input, I guess we do not have to worry about a blocking elemnt to stop curreent while the transducer is in transmission mode
Jun 06 17:14:32 <ds2> no I have not
Jun 06 17:15:25 <ds2> thetransformerr[: Unless  you have simplified it too much, how are you convertng between the analog signals of the sensors and the digital eCAP input?
Jun 06 17:19:31 <thetransformerr[> I guess ecap can take input of pulse waveform and can capture the change pretty much clearly, and I am assuming that transducer provide output without any phenomenon like ringing, retaining the characterstics
Jun 06 17:19:40 <thetransformerr[> of waveform transmistted
Jun 06 17:22:03 <thetransformerr[> and we may set some analog threshold, and all these assumptions are based on output from sensors, which none of us got,
Jun 06 17:22:46 <thetransformerr[> and considering online resources, I think output retains the waveform transmitted
Jun 06 17:49:24 <ds2> thetransformerr[: that is a bad assumption... when I suggested that board, it was assumed it would go into and ADC
Jun 06 17:49:33 <nerdboy> did the maxq boards get shipped?
Jun 06 17:49:35 <ds2> otherwise, you need signal shaping circuits
Jun 06 17:49:44 <ds2> i have 0 visibility into any HW
Jun 06 17:51:04 <ds2> the analog world is a harsh one completely unlike the idealized digital one
Jun 06 17:55:03 <thetransformerr[> well, I suggested for eCAP considering they could be tested for their feasiblity in intial period, because if they works, we would have a lot easier and cleaner interface
Jun 06 17:56:01 <thetransformerr[> in case eCAP fails we can use PRU-DAQ round robin method using threshold valur to detect pulse
Jun 06 17:56:48 <thetransformerr[> are signal shaping circuits more complex then adc arrangement??
Jun 06 17:56:56 <thetransformerr[> or less?
Jun 06 17:57:28 <ds2> could be more or less
Jun 06 17:57:45 <ds2> i would need to understand what the alg really wants to comment more
Jun 06 17:58:23 <ds2> with the ADC route, you have to do all the conditioning in SW...the HW just needs to make sure nothing frys so it can be (compartiviely) simple
Jun 06 17:58:50 <ds2> generally it is a bad idea to put analog signals into a digital pin w/o conditioning
Jun 06 17:59:44 <thetransformerr[> I want ecap to detect the pulse and store the time as timestamp in its one of capture register
Jun 06 18:00:46 <ds2> how does the "pulse" relate to the actual signal?
Jun 06 18:00:59 <ds2> these things are ultrasonic mics
Jun 06 18:02:02 <thetransformerr[> but they have narrower range of reception  than usual mics,
Jun 06 18:03:42 <ds2> freq response, yes... but the output is just as messy
Jun 06 18:05:17 <thetransformerr[> so we should go by adc route??
Jun 06 18:06:02 <ds2> I can't give you a peep hole guidence... need visibility into the alg side to give guidence on that (nerdboy?)
Jun 06 18:07:21 <thetransformerr[> the problem I am facing is lack of hardware to perform any basic test, it would have been more clear for us once we had got taste of sensors function
Jun 06 18:07:42 <ds2> *nod* I understand.... trying to help you get to the bottom of it
Jun 06 18:07:58 <ds2> thetransformerr[: how are you handling noise?
Jun 06 18:09:29 <thetransformerr[> algorithm isn't much complex, the main thing we have capture the time taken from tx to rx, t1, and then time taken from rx to tx, t2,
Jun 06 18:09:48 <ds2> yes but how do you do that?
Jun 06 18:10:02 <ds2> are you expecting the leading edge of the wave to be the "time markers"?
Jun 06 18:10:15 <ds2> or are you looking at relatively shifts in the phase?
Jun 06 18:10:41 <ds2> or (not with the proposed HW) are you mixing the RX and TX signals and processing the output?
Jun 06 18:10:43 <thetransformerr[> I am planning with leading edge
Jun 06 18:11:04 <ds2> okay... how do you tell the difference between the leading edge vs a pulse of noise?
Jun 06 18:11:52 <ds2> one simple way of going from analog to digital is to run it through a comparator.... if signal < THRES, out = 0; else out = 1
Jun 06 18:12:23 <ds2> problem is signal = n*TX (in simpliest case) where n < 1
Jun 06 18:12:46 <ds2> so the "edges" could be middle of the wave for the TX and the peak for RX
Jun 06 18:13:05 <ds2> by merely varying the losses in the path, you have induced a phase shift error
Jun 06 18:13:59 <ds2> another way of generating the signal is to apply something like d(RX)/dT * M where M is a large number
Jun 06 18:15:04 <ds2> I suspect you will have to get more complex...
Jun 06 18:15:13 <thetransformerr[> actually if we try to tackle to this problem in parts, then we may divide into these parts : 1 h/w 2 time detection 3 calculation and transfer to user space
Jun 06 18:16:04 <ds2> IMO - xfer to userspace can be done outside of GSoC (i.e. can be later) if you can printk numbers, _I_ will be good with it. this is assuming you can do it with integers
Jun 06 18:16:29 <ds2> (1) should not be in GSoC so that leaves time detect and calc...
Jun 06 18:16:53 <ds2> if you can figure out those, we can at worse do a simple char driver to dump out numbers
Jun 06 18:17:58 <thetransformerr[> most messy part here is time detection, so if we once keep it simple by slight compromising with results, than we may be able to create a barebone structure, that can be improved by reiteratation,
Jun 06 18:18:41 <ds2> indeed
Jun 06 18:18:47 <thetransformerr[> because if we keep planning and planning we might never reach a perfect solution during gsoc, in fact
Jun 06 18:18:56 <ds2> yes
Jun 06 18:19:11 <ds2> but time detection depends on the HW
Jun 06 18:19:28 <ds2> thetransformerr[: do you have the PRUDAQ (or is it coming)?
Jun 06 18:21:24 <thetransformerr[> I got PRUDAq
Jun 06 18:21:32 <thetransformerr[> but without bbb :(
Jun 06 18:21:44 <ds2> got it... so you can experiment with the PRUDAQ
Jun 06 18:22:00 <ds2> I wonder if you can mock up something with a speaker and a regular mic
Jun 06 18:23:24 <thetransformerr[> only when I receive BBB, because I have only arduino, which is not compatible with it
Jun 06 18:23:31 <thetransformerr[> however I may use arduino to create a pulse
Jun 06 18:24:01 <ds2> any mics
Jun 06 18:24:30 <ds2> that is still a digital thing... would be good to get a handle on a less contrived signal
Jun 06 18:29:15 <thetransformerr[> but no mics I guess, just asking are mobile/laptop mic able to receive ultrasonic waves ?
Jun 06 18:30:03 <thetransformerr[> and the waves that are shown while recording are actual ones??
Jun 06 18:30:07 <ds2> no... try it with non ultrasonic
Jun 06 18:30:12 <ds2> it shouldn't be THAT different
Jun 06 18:30:19 <ds2> something like 16KHz
Jun 06 18:30:27 <ds2> as long as you arne't hitting a resonance
Jun 06 18:30:46 <ds2> sorry, gotta run
Jun 06 18:31:09 <thetransformerr[> no problemo, thanks for discussion
Jun 06 18:31:21 <thetransformerr[> did you just received an email from me
Jun 06 18:32:34 <thetransformerr[> if not I would add my other id in thread...
Jun 06 19:25:50 <ravikp7[m]> jkridner: ping!
Jun 06 20:16:53 <ravikp7[m]> all: posted my first weekly report to google group
**** ENDING LOGGING AT Wed Jun 07 03:00:03 2017