**** BEGIN LOGGING AT Thu Jun 29 03:00:02 2017
Jun 29 04:01:34 <thetransformerr[> ds2:, nerdboy:
Jun 29 04:02:11 <thetransformerr[> I Have added code on github, here https://github.com/thetransformerr/beagle-sonic/tree/thetransformerr-method-1/method_1-PRUDAQ%20and%20PWM
Jun 29 04:05:01 <thetransformerr[> I have done the following, I edited the prudaq src file: prudaq_capture.c to disable and enable again the pwm module after every 4000 samples
Jun 29 04:06:25 <thetransformerr[> and the pwm rate is 400 kHz with 50% duty cycle we may customize it later to make some improvements in x-correlation results
Jun 29 04:07:19 <thetransformerr[> to enable and disable pwm, I wrote directly to pwm file present under system/devices, using fopen anf fprintf method
Jun 29 04:08:31 <thetransformerr[> the operation is like, we execute the program, it enable pwm and start collecting samples from pru1 and writes to a file, whuch is currently stdout
Jun 29 04:08:54 <thetransformerr[> once it collects 4000 samples it stops and then again start pwm
Jun 29 04:09:55 <thetransformerr[> now next I would do is to use sampled data to find x-correlation and try ds2 suggestion of connecting pwm output to pru
Jun 29 04:17:37 <nerdboy> yay that kooks like something you can postprocess
Jun 29 04:24:37 <nerdboy> is the pwm frequency really 400kH?
Jun 29 04:48:25 <thetransformerr[> pwm is 40000 I guess
Jun 29 04:48:44 <thetransformerr[> maybe an extra zero slipped
Jun 29 04:51:04 <thetransformerr[> pwm is 40 khz but sampling is at 400 k that is what, might have created confusion
Jun 29 04:51:18 <thetransformerr[> we supply sampling while starting program
Jun 29 04:53:23 <nerdboy> did you make the loopback?
Jun 29 04:53:46 <nerdboy> i can test it tomorrow but i need to get a cap first
Jun 29 04:55:28 <thetransformerr[> loopback is controlled by signal command, which I would customise today
Jun 29 04:55:57 * thetransformerr[ sent a long message: thetransformerr[_2017-06-29_04:55:56.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/dWEaYlMXwtVoLvQRiFZYKrzR>
Jun 29 04:56:33 <thetransformerr[> bCont is the variable that controls the while loop of reading samples
Jun 29 05:02:25 <nerdboy> i mean the RC circuit
Jun 29 05:53:25 <thetransformerr[> nope, do you mean the the filter that you suggested in the mail
Jun 29 15:16:18 <thetransformerr[> hii
Jun 29 16:39:13 <jkridner> ravikp7: wanted to mention... should have earlier... that your strategy for making things asynchronous with Promises looks difficult to read to me.
Jun 29 16:39:26 <jkridner> ravikp7: the old synchronous code was easier to read.
Jun 29 16:39:40 <jkridner> making it asynchronous shouldn't be as hard or as confusing as what you did.
Jun 29 16:39:50 <jkridner> it just means thinking about the code a bit different.
Jun 29 16:42:49 <jkridner> it really should be designed as an event-based *server*, not as a series of things that need to happen, but rather a number of configurable handlers that service events. the triggering event would be the insertion of a board able to reach the USB bootloader.
Jun 29 16:44:21 <maciejjo> ffkfkfkkfkfkf
Jun 29 16:44:33 <maciejjo> sorry :) ssh session got stuck
Jun 29 16:50:13 <thetransformerr[> ds2:, nerdboy: I was thinking, if we could use a epwm module for each dimension and just enable and disable it from code
Jun 29 16:51:07 <thetransformerr[> then the only difficulty would be to change output of pwm from tx to rx because we need tof from each side
Jun 29 16:52:36 <thetransformerr[> for that can we use some line selector sort of thing or a switch in case if we use tx and rx sensor rather than using transducer
Jun 29 16:52:56 <thetransformerr[> *transreceiver
Jun 29 17:26:18 <ravikp7> jkridner: I've pushed some changes today, implemented all using await now, would be much easier to read now, please have a look
Jun 29 17:26:32 <ravikp7> https://github.com/ravikp7/node-beagle-boot/tree/dev
Jun 29 17:33:42 <nerdboy> thetransformerr[: i'm not clear on what you're asking
Jun 29 17:34:15 <nerdboy> can we gewt one axis working first?
Jun 30 00:18:12 <nerdboy> can you have ecap and epwm listen for the same interrupt?
Jun 30 00:18:45 * nerdboy plays dumb *really* well lately...
Jun 30 00:24:47 <ds2> is it pinned out so you can use both parts?
Jun 30 00:50:33 <nerdboy> wormo and ka6sox finished it up, i can pick it up tomorrow morning
Jun 30 00:50:54 <nerdboy> except it's j3 i think, not j5
Jun 30 00:57:02 <thetransformerr[> hi nerdboy:, ds2:
Jun 30 00:58:57 <thetransformerr[> what I was asking that if we could use pwm as trigger,
Jun 30 00:59:33 <thetransformerr[> that we start pwm for some time period and then stop it
Jun 30 01:02:09 <thetransformerr[> and for single axis, apart from the code I pushed yesterday, I have to find out a way to transmit and receive pulse from other side also
Jun 30 01:03:11 <thetransformerr[> because we needed t1 and t2 for calcultion of wind velocity independently without the factor of temp
Jun 30 01:03:58 <thetransformerr[> however with current method if we get temp, we can find velocity, to very close value
Jun 30 01:09:14 <nerdboy> t1 and t2 for x and y?
Jun 30 01:09:36 <nerdboy> this is what i mean about making a diagram...
Jun 30 01:09:49 <thetransformerr[> no t1 for north to south and t2 for south to north
Jun 30 01:09:59 <thetransformerr[> I am making one right now
Jun 30 01:10:09 <thetransformerr[> I read your email just now
Jun 30 01:13:39 <nerdboy> i don't think you need both directions for one axis
Jun 30 01:14:06 <nerdboy> in theory they should +/- versions of each other
Jun 30 01:15:07 <thetransformerr[> actually there are two ways- please refer to this page http://elinux.org/GSoC2017_sonic_anemometer_proposal
Jun 30 01:15:32 <thetransformerr[> http://elinux.org/GSoC2017_sonic_anemometer_proposal#Principle_of_Sonic_Anemometer:
Jun 30 01:17:47 * thetransformerr[ uploaded an image: 600px-Time.png (19KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/nqnciMhotlLTdBQEDowngNTf>
Jun 30 01:17:48 <thetransformerr[> the difference between tof for both directions for one axis is in this fig
Jun 30 01:29:51 <thetransformerr[> however if we dont go by this way, then we can measure temp from other source and use other formula
Jun 30 01:30:01 * thetransformerr[ uploaded an image: Screen Shot 2017-06-30 at 6.59.33 AM.png (75KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/OzmAHKOOcfOrhUVcbcNKRocP>
Jun 30 01:30:44 <nerdboy> well, the cheap way is only measure little-v once
Jun 30 01:30:45 <thetransformerr[> this the current code that I have pushed to github
Jun 30 01:31:37 <nerdboy> doing it both ways isn't bad if you have the cycles/ram space
Jun 30 01:32:47 <nerdboy> so if you want to switch modes on the maxq boards then we need a diode on each one
Jun 30 01:33:04 <thetransformerr[> if we do both ways we get accurate results and if we do just one direction then we get approx result
Jun 30 01:33:31 <nerdboy> what's the magnitude of the difference?
Jun 30 01:34:13 <nerdboy> and did you get your boards yet? or at least a tracking number?
Jun 30 01:34:17 <thetransformerr[> that depends upon the accuracy of temp we measure from other source like thermistor
Jun 30 01:34:35 <thetransformerr[> I have got bbb and prudaq and sensors until now
Jun 30 01:34:49 <thetransformerr[> maxq no :(
Jun 30 01:35:10 <nerdboy> no notification or anything?
Jun 30 01:35:23 <thetransformerr[> nope
Jun 30 01:35:31 <thetransformerr[> but for now I can pull off with these hardware,
Jun 30 01:35:56 <thetransformerr[> I would visit agin lab possibly tommrow and would update you
Jun 30 01:37:43 <nerdboy> does your signal generator have trigger input?
Jun 30 01:38:39 <thetransformerr[> I guess it have, last time faculty was not in lab and I didnt knew how to use it
Jun 30 01:38:41 <nerdboy> or were you going to use pwm and filter?
Jun 30 01:39:08 <thetransformerr[> this time I would first ask him before visiting lab
Jun 30 01:39:29 <thetransformerr[> i would first check out our code for pwm
Jun 30 01:39:39 <thetransformerr[> and then with signal generator
Jun 30 01:39:41 <nerdboy> that RC example is the right order of delay for 20 cm distance
Jun 30 01:42:15 <thetransformerr[> may be we can skip rc filter for now if the noise does not varies much, because if I am right we use rc filter for suppressing frequency outside of our desired bandwidth
Jun 30 01:42:52 <thetransformerr[> did you saw the diagram I shared for current code
Jun 30 01:44:01 <thetransformerr[> I would update with more detailed diagram after a while and a detailed analysis of what we can do epwm and ecaps
Jun 30 01:45:42 <thetransformerr[> for comparison between measuring just one side north to south and measuring both side N to S and S to N, I guess I covered it in my proposal, however if you like we can switch to approx method also
Jun 30 01:45:46 <nerdboy> which diagram is new?
Jun 30 01:46:23 <thetransformerr[> I have also sent mail, check it out in reply of mail you sent me a hour ago
Jun 30 01:46:43 <nerdboy> do you have a temp sensor available?
Jun 30 01:47:44 <thetransformerr[> nope but they must be available locally, I guess with their wide spread applications
Jun 30 01:48:09 <thetransformerr[> can we use thermistor??
Jun 30 01:48:23 <ds2> you trust the ADC to read it accurately? :D
Jun 30 01:49:17 <thetransformerr[> nope ;)
Jun 30 01:50:27 <thetransformerr[> was confirming my belief
Jun 30 01:57:23 <ds2> thetransformerr[: how accurate do you need the temp sensor?
Jun 30 01:57:32 <ds2> +/-1C? +/-5C? etc
Jun 30 02:05:01 <nerdboy> hopefully less than 1 deg C
Jun 30 02:05:23 <nerdboy> .5 is kindof a useful minmum
Jun 30 02:06:23 <nerdboy> "normal" observation reqs are 0.1 iirc, research grade would be .01 deg C
Jun 30 02:07:24 <ds2> hmmmm 0.1... might have to put that a few inches away
Jun 30 02:07:33 <ds2> otherwise the BBB may heat it too much
Jun 30 02:08:34 <ds2> nerdboy: I suspect there will be delays to calibrate out if you loop to the eCAP
Jun 30 02:09:15 <ds2> and in addition, that would require mapping to actual recv time (i.e. there is the eCAP clock and there is the ADC clock)
Jun 30 02:10:08 <nerdboy> doesn't the round-robin example use pru for a clock?
Jun 30 02:10:34 <ds2> yes so you got that clock and the capture clock... now figure how to correlate them
Jun 30 02:10:41 <ds2> j #beagle
Jun 30 02:11:53 <nerdboy> interrupt?
Jun 30 02:12:17 <ds2> interrupt is variable latency
Jun 30 02:12:24 <ds2> eCAP is suppose to latch a counter on the event
Jun 30 02:12:35 <ds2> that counter needs to be correlated to the RX clock
Jun 30 02:13:10 <nerdboy> well, if ecap gets pru int events doesn't that do it?
Jun 30 02:14:00 <nerdboy> we have two ecap modules
Jun 30 02:14:18 <ds2> and use the 2nd one for rx?
Jun 30 02:14:21 <ds2> or??
Jun 30 02:15:55 <nerdboy> idk, i guess it depends on how that code works
Jun 30 02:16:23 <nerdboy> the pru clock is the input clock to the prudaq?
Jun 30 02:16:32 <ds2> i personally like the correlation method
Jun 30 02:16:50 <nerdboy> meaning what exactly?
Jun 30 02:17:21 <ds2> meaning you have 2 inputs and you run the fancy math on it
Jun 30 02:17:30 <ds2> that math is pretty noise resistant
Jun 30 02:18:53 <ds2> i have seen to do miracles on some pretty noise signals (other projects)
Jun 30 02:19:21 <nerdboy> 2 inputs as in one axis/both directions?
Jun 30 02:20:12 <nerdboy> or 2 inputs as in tx-pulse/rx-signal?
Jun 30 02:22:44 <ds2> yes
Jun 30 02:22:57 <ds2> I can't explain it too well as signal processing isn't my area
Jun 30 02:28:57 <nerdboy> that's what he did with the "sample" data
Jun 30 02:29:29 <nerdboy> the cross-correlation part
Jun 30 02:31:18 <nerdboy> getting those inputs in a reasonably optimal way is what i'm not clear about...
Jun 30 02:31:45 <nerdboy> (just the part right after "now here's the plan)
Jun 30 02:32:20 <nerdboy> ^^ 2nd max quote of the day
**** ENDING LOGGING AT Fri Jun 30 03:00:03 2017