**** BEGIN LOGGING AT Fri Mar 31 03:00:03 2017 Mar 31 03:05:21 Hi nerdboy:, you there Mar 31 03:06:03 I have described the data acquisition cycles, you can review them here Mar 31 03:06:19 http://elinux.org/GSoC2017_sonic_anemometer_proposal#Requirement_Analysis Mar 31 03:06:25 thanks!! Mar 31 14:32:12 ds2: ping :) Mar 31 15:30:01 hi everybody Mar 31 15:30:34 nerdboy: would you please review once again Requirement Analysis section Mar 31 15:30:47 http://elinux.org/GSoC2017_sonic_anemometer_proposal#Requirement_Analysis Mar 31 16:21:49 missed him again... Mar 31 16:52:59 would somebody please explain me why are we still using IRC, when slack is free for open source organisations and there is no doubt that slack is 10000 times better than IRC Mar 31 16:54:08 nerdboy: I m up again 😅 Mar 31 16:57:37 it's not very clear how the pulse trigger/data acq works Mar 31 16:58:22 i was hoping to see some data flow all the way out to userland U,V wind vectors Mar 31 17:05:30 this is the plan I have in mind, for 2d axis, since in PRUDAQ we have two channels, and two channels have four inputs, Mar 31 17:06:13 and for time of flight calculation, we need to send wave back and forth along a axis Mar 31 17:08:23 so let us assume axis 1 has trans 1 and trans2 and axis y has trans3 and trans4, so we start with triggering trans1 and trans3 and start sampling output of trans2 and trans4, and continue to do so for a time period Mar 31 17:09:49 of time taken by sound wave to travel distance and then after a break of microsecond we trigger trans2 and trans4 and this time we sample trans1 and trans3 Mar 31 17:10:05 this is the journey until PRU Mar 31 17:11:16 for userland I don't have concrete information, but reading the last year implementation I found he used a low level library zeromq Mar 31 17:14:04 so we can do something like that, and as I assumed device to have a sample rate of 20 Hz, we have time of 50 microsecond for triggering-and-sample-cycle-1, then wait and then triggering-and sample-cycle-2, and transferring tis information to User space Mar 31 17:22:31 jkridner: Please provide feedback on the proposal, any changes, additions? So that, I can make those improvements in time since only 3 days are left for submission. Mar 31 17:25:28 nerdboy: May be I have mixed up different informations in proposal, but now did you get some idea what I am planning to do??? Mar 31 17:27:04 Some waveforms depicting instruction cycle can be helpful...?? Mar 31 17:27:42 more like a boxes and arrows Mar 31 17:29:47 are the sensors set free-running or do you trigger a set of pulses? Mar 31 17:30:39 with the muratas you'd have 2 tx and 2 rx sensors but most others are combined i think Mar 31 17:31:54 nerdboy: would you please tell me if we trigger a set, do we need additional hardware or PRUDAQ handles it?? Mar 31 17:32:55 I can't find how to trigger a pulse, for analysis sake until now I have assumed trigger can be done easily by some sort of command with PRU or PRUDAQ Mar 31 17:34:37 in this casr it would be a sensor command Mar 31 17:34:45 *case even Mar 31 17:35:11 if sensors are set free running , we can easily monitor spikes for any event, but triggering seems to be much cleaner operation as we have fixed cases to worry about Mar 31 17:35:13 did you get the data sheets? Mar 31 17:35:58 yeah I got the data sheets and they used a massive massive circuits first to generate pulse and then receive them Mar 31 17:36:22 and then count the time of flight using some clock Mar 31 17:37:14 It is not that I can't find these information, but I just want to save our time by being honest with you, about what I know currently and what not Mar 31 17:40:14 i meant sensor specs Mar 31 17:40:53 i thought you listed some sensors besides the muratas but i don't see that now... Mar 31 17:41:54 you need to know what the interfaces are for control/data Mar 31 17:42:00 yeah I have compiled data but I didn't uploaded to avoid information burst in proposal Mar 31 17:42:50 but as I said above in their data sheet, they explained every thing in details but not DAQ Mar 31 17:43:43 the daq is one interface Mar 31 17:44:18 sensor sheet stuff on that is just their example Mar 31 17:44:46 all you care about is the sensor side specs Mar 31 17:46:31 just pick one for the analysis Mar 31 17:47:13 okk let me be naive for one time, are you talking about these specs like following Mar 31 17:47:28 Center frequency (f0): 40.0KHz ± 1.0KHz • Nominal impedance: 1,000Ω • Sound pressure level @ f0: 117dB • Sensitivity @ f0: -53dB (0dB = 1V/μ bar) • Echo sensitivity @ f0: -45dB (0dB re 50 bursts sine wave of 20 volts peak-peak; 100cm reflection target) • Bandwidth -6dB: 2KHz • Ringing: 1.2mS (max.) • Beam angle -6dB: 55° • Capacitance @ 1KHz: 2,400pF ± 20% Mar 31 17:48:06 either the murata setup or a more "typical" ping-y sensor with i2c/spi Mar 31 17:48:54 then pick free-running or triggered, etc Mar 31 17:49:41 for now you need to make some reasonable assumptions and use the spec sheets Mar 31 17:51:02 i mean the interface "specs" to control the sensor and receive some data Mar 31 17:51:27 okk now I got the point about triggered and free running Mar 31 17:52:40 so for now I have taken assumption for trigger controlled transducers Mar 31 17:54:49 ds2, jic23, nerdboy, m_w, jkridner: can you please give me some suggestions on this: http://elinux.org/BeagleBoard/beaglecv_stereo Mar 31 17:55:00 we can later experiment b/w trigger and free running after we get software up Mar 31 18:06:15 nerdboy: apart from technical details, what do you think about timeline and other aspects of proposal, is it good 😬 Mar 31 18:13:57 .. Mar 31 18:30:05 Kiran4399 looks pretty good. Demanding schedule plus surf on gles2 might be tricky. I don't have a good feel for what you can do. Mar 31 18:32:07 seems good, should be enough room for adjustments Mar 31 18:34:54 m_w: I made some brainstorming https://github.com/ordsen/gsoc-preparation/blob/master/sketches/Network_bus_brainstorming.jpg Mar 31 18:35:14 but it seems like there is already exactly the same thing available https://allseenalliance.org Mar 31 18:36:40 nerdboy:your quote please!! and till tomorrow I would add flowchart also, with boxes and arrows Mar 31 18:40:02 jic23: would you please provide your thoughts about this proposal Mar 31 18:40:15 http://elinux.org/GSoC2017_sonic_anemometer_proposal Mar 31 18:47:11 ordsen: iot is a crowded space Mar 31 18:50:47 thanks!! Mar 31 18:51:48 m_w: yeah.. I'll just leave it at one proposal Mar 31 18:52:06 okay Mar 31 18:52:37 m_w: speaking of that: I extended the test to write the I/O to a file synchronously. Still no issues Mar 31 18:53:48 good Mar 31 18:53:50 if any issues arise I think that we can get around those by making I/O and file writing async. Though it doesn't look like that will be necessary atm Mar 31 18:54:16 and the DMA thing is plan B of plan B Mar 31 18:54:25 so its plan C I guess Mar 31 18:57:07 The transformer nice proposal. Mar 31 18:59:25 I am not sure why the ADC on the am335x is no use though? Mar 31 19:04:03 It is very fast, has fifos and DMA plus can i think be triggered from the pru. Mar 31 19:04:24 Thetransformer^ Mar 31 19:04:55 there are only 6 proposals on the gsoc site and more than that on elinux Mar 31 19:05:11 everyone waiting until last minute? Mar 31 19:05:17 Fairly fast i should say. How quick do you need? Mar 31 19:08:46 Ah 400khz... Hmm can't remember off the top of my head what the max people are managing is... Mar 31 19:11:43 200khz is listed in original driver thread but iirc someone tweaked it to go faster. Mar 31 19:11:55 https://lists.gt.net/linux/kernel/2536607 Mar 31 19:15:24 Hmm looks like that is max that i can find reported. Might be enough... Easy early win for hardware testing perhaps! Mar 31 19:15:58 m_w: m_w: could you check my application? Mar 31 19:16:12 http://elinux.org/BeagleBoard/GSoC/BeagleWire_software_support Mar 31 19:16:41 then I will complete the registration process Mar 31 19:18:12 first bridge test using “/dev/mem/” Mar 31 19:18:32 why are you wanting to use /dev/mem? Mar 31 19:18:49 just for quick testing? Mar 31 19:19:26 yeah I think It's the quickest way without writing anything on the arm Mar 31 19:19:50 then create a real driver after that? Mar 31 19:20:05 fpga stuff is what I want to write first Mar 31 19:20:14 okay Mar 31 19:20:24 I think that is better Mar 31 19:20:47 the verilog glue logic? Mar 31 19:21:55 glue logic? I don't understand Mar 31 19:22:07 I don't see that Mar 31 19:22:13 in my application Mar 31 19:22:54 explain what you mean by stuff Mar 31 19:23:48 yes programing tools and fpga logic first Mar 31 19:23:59 bridge module would be the "glue logic" Mar 31 19:24:33 http://whatis.techtarget.com/definition/glue-logic Mar 31 19:25:29 yes exactly, The user will attach it Mar 31 19:25:41 yeah okay Mar 31 19:25:58 we can do simple examples with just SPI interface Mar 31 19:26:10 ok no problem Mar 31 19:26:14 jic23: we are still in planning mode, what changes do you suggest?? Mar 31 19:26:17 then more complicated with the bridge and mmio Mar 31 19:27:12 "the costs could be reduced by several times" Mar 31 19:27:12 and we currently are planning with prudaq and it uses Analog Devices AD9201 10-bit ADC Mar 31 19:28:03 Rather more than you need perhaps. Mar 31 19:28:22 may I know what you were referencing by this comment "I am not sure why the ADC on the am335x is no use though?" Mar 31 19:28:23 i mean when we use the board the costs could be reduced by several times Mar 31 19:28:59 The processor on the beagle bones has a non trivial ADC. In theory Mar 31 19:29:15 Very capable. Mar 31 19:29:47 oh sorry I thought you were referencing to prudaq Mar 31 19:29:52 m_w: We also want to add solutions that use spi communication instead of gpmc (other module version) Mar 31 19:30:16 12 bit 200khz Mar 31 19:30:21 pmezydlo: not a bad idea, time permitting Mar 31 19:31:10 Nothing to prudaq but there for free :) Mar 31 19:31:41 What do the transducer etc cost? Just curious as sounds fun to play with! Mar 31 19:39:14 transducers cost depends upon their frequency and type, waterproof 40kHz multicomp transducers cost about 5-10 euro Mar 31 19:39:15 http://uk.farnell.com/multicomp-ultrasonic-transducers Mar 31 19:41:55 m_w: can I add or change something else? Mar 31 19:41:58 jic23: please tell me more about am335x utilisation here, Mar 31 19:42:37 and please point out any discrepancy in the proposal Mar 31 19:48:37 As i understand it all you need is pulsing ultrasound then sample fast. Mar 31 19:48:52 Question is how fast. Mar 31 19:49:55 If 200khz is enough (100khz for dual channels) then there is inbuilt ADC that can do it directly in Linux without prior or controlled by pru. Mar 31 19:50:16 Pru not prior. Stupid autocorrect Mar 31 19:51:10 Need to show if speed of pru daq is needed. Mar 31 19:51:21 actually this project actually intends to be 3-d axis sonic anemometer, but we are trying to reach that state step by step Mar 31 19:52:00 Ok frequency getting worse so may not be doable on built in adv Mar 31 19:52:01 Cool. Mar 31 19:52:06 Adc. Mar 31 19:52:29 but to avoid throwing away code developed at every previous step we are trying to make it as scalable as possible Mar 31 19:52:36 Worth trying as prototype stage perhaps. Mar 31 19:53:16 Short of a bit of wiring time to get data with ADCs would be a few hours at worst. Mar 31 19:53:41 yeah thanks for this idea, we can use it for testing purposes while developing program in user space Mar 31 19:53:50 Yup. Mar 31 19:54:17 Might be an even lower cost less capable version Mar 31 19:55:56 Anyhow good proposal. Good luck! Mar 31 19:55:57 yeah it is perfectly suitable for 1d analysis of wind speed and can be combined with other utility like IMU, although I wonder how much overhead does it take do sampling at this rate Mar 31 19:56:32 See original post of driver 5% of CPU. Mar 31 19:58:01 the builtin adc isn't fast enough Mar 31 19:58:30 jic23:okk thanks any comment you would like to make that I can add in proposal as quote from community mentors ... Mar 31 19:58:52 also data samples up to 60 sps would be a good starting target Mar 31 20:00:08 *at least it doesn't scale up well Mar 31 20:00:53 pmezydlo: try updating to the latest I have posted on Github for beaglewire Mar 31 20:01:30 I just remove the library and it should pick up the component from the cache Mar 31 20:01:36 removed Mar 31 20:10:29 Nerdboy, fair enough but not currently obvious from proposal. Mar 31 20:13:01 The transformer best i can do is 'I'll be tempted to build one!' Mar 31 20:13:18 Thetransformer Mar 31 20:13:39 thanks 😅 Mar 31 20:44:32 m_w: Now everything works fine Mar 31 20:45:59 m_w: I see list of task, I will try to do it Mar 31 20:49:39 pmezydlo: you want to use LDOs or switchers for the power supplies Mar 31 20:50:06 please make sure that the supplies are rated for the load and aren't too big Mar 31 20:50:57 I tend to have a particular style I use for component so don't get discouraged if I end up changing your symbols :) Mar 31 20:51:03 brb Mar 31 20:56:49 yeah I know, I think that 800mA should be enough Mar 31 20:56:55 m_w: ^^ Mar 31 20:57:24 check the datasheet for the fpga for the requirements Mar 31 20:58:45 here are a few decent references for schematics: Mar 31 20:58:53 https://github.com/xesscorp/CAT-Board/blob/master/docs/Manual/pics/CAT_schematic.pdf Mar 31 21:00:05 https://github.com/OLIMEX/iCE40HX1K-EVB/blob/master/iCE40HX1K-EVB_Rev_B.pdf Mar 31 21:00:57 ok I see he used 1A regulator Mar 31 21:01:11 https://github.com/fpga-logi/logi-boards/blob/master/fpga-boards/logi-bone/PRJ-DOC/sch/sch-logi-bone-r1_5_1.PDF Mar 31 21:01:42 the logibone is xilinx but I like the layout and use of PMOD connectors Mar 31 21:02:11 do you prefer TI or Microchip regulator Mar 31 21:02:24 those are good Mar 31 21:04:00 do we want to have 2 PMOD and arduino or one e.g. 2x12 pins connectors? Mar 31 21:04:30 not sure we need arduino Mar 31 21:05:03 yeah I think so too Mar 31 21:05:47 grove connectors are pretty popular these days Mar 31 21:05:52 http://wiki.seeed.cc/Grove_System/ Mar 31 21:07:32 yeah this is good idea I have a few modules with grove connectors Mar 31 21:10:14 I hope iCE40HX4k be enough Mar 31 21:20:03 I am trying to understand the working of pru-software-support-package (git://git.ti.com/pru-software-support-package/pru-software-support-package.git) by starting from the toggle_led example given in the labs directory Mar 31 21:21:36 in the code they are just changing the value of one register (_R30) .... so how this register i actually linked to PRU pins? Apr 01 01:31:19 anyone active? need some help **** ENDING LOGGING AT Sat Apr 01 03:00:02 2017