**** BEGIN LOGGING AT Fri Mar 17 03:00:02 2017 Mar 17 03:00:59 that's jason's "remote" connection Mar 17 03:01:23 oh well... Mar 17 10:23:46 Hi guys. Mar 17 10:24:32 I'm wondering if its a little bit of late catching up with this... Mar 17 10:35:31 YorkHe: its never too late ;) Mar 17 10:37:30 It'll be nice hearing about that. : ) Mar 17 18:57:54 im loved the idea behind the the Quake Cather Network project, and would like to work on it. i have some doubts Mar 17 18:58:57 do you want the IMU sensor readings from PRU? i think using Bonescript will do the work much rasily.. Mar 17 19:13:29 prus might be used for data analysis Mar 17 19:14:01 it's up to you to determine the reqs Mar 17 19:14:42 bonus points for using PRUs, bonescript, beagle-y js web stack Mar 17 19:15:27 but don't force a square peg if it doesn't match the reqs Mar 17 19:16:21 ohkae.. :D Mar 17 19:16:48 the incoming seismic signal is a magnitude wiggle vs. time Mar 17 19:17:34 so converting to frequency domain would be a good pru task Mar 17 19:18:18 need to do some research on the detection part Mar 17 19:18:48 for the frequency domain change.. thats a great idea .. now i think PRU are working for which they are meant Mar 17 19:19:10 pretty sure quake catcher will validate signals between multiple instruments Mar 17 19:19:49 hard to tell a truck from a small tremor with a single measurement Mar 17 19:20:00 detection as in ? should i do something more than Kalman filter of the readings? Mar 17 19:20:34 that's part of the requirements analysis Mar 17 19:21:16 phase 1 would be sending data to qcn Mar 17 19:21:49 ohkae.. Mar 17 19:22:06 still need an answer on local processing, ie, what can you do with the time/freq-domain data and is it worth it? Mar 17 19:22:39 depending on scope that part could be a stretch goal Mar 17 19:23:23 then i think .. two IMUs working simultaneously with extendended kalman filter will do the job.. Mar 17 19:23:37 is it even possible to fit fft/dft algorithm in the prus? Mar 17 19:24:03 you'll have to show me why Mar 17 19:24:15 i think fft and dft on PRU will make a new gsoc project itself Mar 17 19:25:07 one accelerometer should do it i think Mar 17 19:25:46 have looked at the details of the qcn "detector" yet but it seemed pretty simple Mar 17 19:25:52 *haven't even Mar 17 19:26:07 but dft and fft local processing on main linux itself can be promising .. not on the PRU Mar 17 19:26:34 so that part needs some analysis to go into the proposal Mar 17 19:27:55 i would still look at whether any implementations might work/fit with pru processing Mar 17 19:27:59 two im thinking coz they are very cheap (MPU6050) are the catogory to errors caused by sensor fabrication errors gets removed.. Mar 17 19:28:07 *before i made that decison Mar 17 19:28:57 ill look at the qcn detector specs .. we will make a much better one :) Mar 17 19:29:11 well, if you have a good scheme for determining quality that way then describe it Mar 17 19:29:35 you have 2 prus and dma interface Mar 17 19:29:50 bonus points for using edma also Mar 17 19:31:56 that's probably more of a ds2/zeekhuge question Mar 17 19:32:23 1) as bonescript has realtime data aquisition issues.. so ill stick to using PRU for readings.. Mar 17 19:33:21 and i think to make a node.js websocket with many customisable features on graph plots online.. Mar 17 19:33:49 also the data to be stored in local file .. and also sending data to the QCN network .. Mar 17 19:34:03 will be my whole proposal .. Mar 17 19:34:13 should i explore something more.. Mar 17 19:36:10 ill see for the dft and fft transform using PRU .. thats a nice idea.. Mar 17 19:38:49 also web showing freq domain options will make it real cool.. and other options for changing IMU sensitivity and frequency of data reading will make it even better.. Mar 17 19:38:51 ?? Mar 17 19:39:34 ill dive into some hardware and will then ping you .. thanks :) Mar 17 20:01:58 you could look at using gpu for fft Mar 17 20:02:43 depending on pru usage, etc Mar 17 20:03:56 so the IMU would interface over I2C/SPI ? Mar 17 20:09:47 those would be "standard" interfaces Mar 17 20:10:18 I2C.. ill be using mpu6050 .. will that be okay? Mar 17 20:11:03 so PRU is going to bitbang or is it gping to get data from the on SoC i2c for analysis ? Mar 17 20:11:23 I guess its the 2nd option. Mar 17 20:11:53 unless we have the last year's i2c bitbanging project ready. Mar 17 20:12:24 yes i can use the last years GSOC project implemented on exposing pru as an i2c device Mar 17 20:12:28 s/gping/going Mar 17 20:13:11 last years i2c over pru project might need some work Mar 17 20:13:15 kartik_: I dont think thats even close to ready. Instead I was thinking if beagleScope could be used .. Mar 17 20:13:44 so , using beaglescope you can make the sensor available as an IIO device. Mar 17 20:14:21 then i think our simple linux implementation is also fast enough.. ill ignore the bonescript use for i2c coz its slow ..will that do? Mar 17 20:16:57 also, this year there "offload to PRUs" project too .... thats specifically for such applications where some processing needs to be done on the PRUs. Mar 17 20:18:23 yes i can go for tht.. but i think the alignment is very necessary and i/o device option will lack that.. also as the data will be used for research by QCN. Mar 17 20:18:34 i want to make the data accurate.. Mar 17 20:19:33 the spi interface should be fast enough for data aq Mar 17 20:19:46 plus the green comes with a 9250 anyway Mar 17 20:19:59 sure. Mar 17 20:20:11 kartik_: ^ Mar 17 20:20:26 i would test rtimulib with spi and see how good the performance is Mar 17 20:20:32 wow.. thats great.. Mar 17 20:20:52 that would be pretty quick/easy Mar 17 20:21:21 a smd soldered inbuilt ic will improve the reading accuracy a lot Mar 17 20:21:43 that might be the "best" way to get data and feed it to other stuff Mar 17 20:22:26 actually it will be.. but ill implement some filters on that too.. which i can on the PRU.. like Kalman ? Mar 17 20:22:42 the green has grove connectors for i2c/uart sensors on breakouts Mar 17 20:23:17 you'd need to patch it to the spi gpio connectors Mar 17 20:23:44 mavlink already does that too Mar 17 20:24:46 but kalman filtering is for sensor fusion with multiple sensor inputs Mar 17 20:25:03 mainly present position, etc Mar 17 20:25:18 i'm not sure this application calls for that Mar 17 20:25:41 you have a fixed location for the sensor Mar 17 20:26:15 and you only need to measure displacement Mar 17 20:26:20 yes ur right .. i was using it for the accelerometer shock errros and the gyro drift errors which are there all the time Mar 17 20:26:44 i'm not even sure you need the gryo Mar 17 20:27:58 fixed location *could* be measured automatically for instrument setup that would take something like differential gps Mar 17 20:28:03 thats not much needed.. was just making sure the final box can even sense the angular changes it had .. Mar 17 20:28:52 well, consider the beaglebone/sensor is "mounted" to the earth Mar 17 20:29:04 i can do that .. :) maybe fix a neo6m module to get gps values? Mar 17 20:29:34 accelerometer should be oriented with zyz (z alligned with gravity vector) Mar 17 20:29:42 *zyx even Mar 17 20:29:55 ohkay Mar 17 20:30:06 * nerdboy 's fingers are not cooperating Mar 17 20:31:17 gps would secondary/stretch goal i think Mar 17 20:31:44 :D .. so final is to have imu will regular data acquisition with gps values and creating a websocket along with data to the qcn server..? did i missed something on that? Mar 17 20:31:45 like i said, might not be accurate enough with differential measurements Mar 17 20:31:54 *without Mar 17 20:32:17 imu/accelerometer Mar 17 20:32:28 gps isn't very helpful Mar 17 20:33:06 that will be easy i think i have done that already in my last summer on BBB. also the gps module is cheap enough to fit the final budget Mar 17 20:33:21 one gps by itself is only so good Mar 17 20:33:49 even your phone has to fuse data in "high accuracy" mode Mar 17 20:33:59 wif/cell/gps Mar 17 20:34:06 *wifi even Mar 17 20:34:38 i would just put the location/elevation data in a config file Mar 17 20:35:22 +/- ~1 meter should be doable that way Mar 17 20:35:25 yes the error rate is 5 meters Mar 17 20:35:37 but thats fine i think .. ? Mar 17 20:36:04 forget about fused location Mar 17 20:36:23 config file first, later maybe change it Mar 17 20:36:41 im not quite clear by what you said - "might not be accurate enough with differential measurements" Mar 17 20:36:45 but changing it means a lot of work vs. what benefit? Mar 17 20:37:08 *without using differential gps Mar 17 20:37:47 which essentially means you have another (highly accurate) base location to "measure" against Mar 17 20:38:12 which you don't, or at least you can't assume a random user does Mar 17 20:38:23 the BBB will be idle .. so was thinking to give it some additional task todo like gps and this extra feature to the online page :) Mar 17 20:38:42 adding that later as an optional feature might be worth it Mar 17 20:38:50 but its not required .. no gps then Mar 17 20:39:16 well, remote wireless interface should be enough Mar 17 20:39:31 *for user display/configuration Mar 17 20:39:46 green has no hdmi display stuff Mar 17 20:39:55 u said green comes with a 9250 ? SMD soldered? cant find that written on site.. Mar 17 20:40:15 i's an extra breakout board with cable Mar 17 20:40:36 that's what we got last year Mar 17 20:41:23 oh ohkay.. Mar 17 20:41:26 so, as long as you're "idle" waiting for a jiggle you can measure temp/pressure/humidity Mar 17 20:42:04 possibly some of those things are correlated Mar 17 20:42:20 thats what .. ill use those cheap modules .. the final board will feature a lot of things then :) Mar 17 20:42:40 that's what we got last year Mar 17 20:42:43 and this also means new plots available on the site :) Mar 17 20:43:03 9250/bmp180 plus dht22 or something Mar 17 20:43:21 the moisture widget uses uart interface Mar 17 20:43:25 a lot of great cheap modules for temp humidity etc etc.. Mar 17 20:44:27 you can (and should) use the known elevation data for calculating some of that stuff Mar 17 20:44:56 ill compare and find the suitable ones .. Mar 17 20:47:11 elevation data .. im not clear.. what can it help to find out Mar 17 20:47:54 your fixed sensor position is in 3d space Mar 17 20:48:18 same as a drone, you need x y z Mar 17 20:48:56 you're making a 3-axis seismometer Mar 17 20:49:39 ohkay.. Mar 17 20:51:43 ill do some tinkering stuff and will then ping you .. thanks :) **** ENDING LOGGING AT Sat Mar 18 03:00:01 2017