**** BEGIN LOGGING AT Mon Apr 20 02:59:58 2015 Apr 20 07:05:58 anujdeshpande: Hi, available? Apr 20 07:06:18 hi neemo Apr 20 07:06:43 anujdeshpande: hey, I'd like to ping you on some stuff related to the PRUs and SPI, if you have time Apr 20 07:07:20 I've seen on the beaglepilot summary that you did SPI with the PRUs during last years GSoC Apr 20 07:08:03 How did that work out? Have any link I could oggle, I'm having a hard time finding the files on the github repos Apr 20 07:08:05 neemo: i was supposed to, but someone else implemented it eventually. Apr 20 07:08:26 checkout sitl on ardupilot/ardupilot on github Apr 20 07:08:49 rather diydrones/ardupilot Apr 20 07:09:24 neemo https://github.com/diydrones/ardupilot/tree/master/libraries/AP_HAL_Linux Apr 20 07:09:52 this is where you’ll find the libraries/abstractions for Linux boards supported by ardupilot Apr 20 07:11:50 anujdeshpande: Ok, I'll look into those SPI drivers Apr 20 07:12:46 Did you end up using those drivers to read SPI devices to the PRU last year? or did you do it some other way? Apr 20 07:16:54 anujdeshpande: Since I've been reading up a lot on the PRUs and it seems the SPI device reads have to go through DMA and then be read with the PRU from external memory Apr 20 07:17:37 neemo: https://wiki.dronecode.org/_media/elc01.dronecode_and_ardupilot_-_andrew_tridgell.pdf this is probably a neat summary of what goes under the hood with BBB+ardupilot Apr 20 07:18:07 where the PRUs will eat a non insignificant amount of cycles fatching that data. Do you have any experience with this? How much cycles does it take to fetch such reads from a SPI device? Apr 20 07:19:11 SPI isn’t done using the PRU. SBUS and PWM using the PRU Apr 20 07:20:22 Also, the way it’s done right now, SPI doesn’t go through dma Apr 20 07:20:22 anujdeshpande: ok, gotcha Apr 20 07:20:37 anujdeshpande: where does it go atm Apr 20 07:20:55 check page 19 of the pdf i linked above Apr 20 07:21:01 elaborated in detail Apr 20 07:21:41 more precisely how do you route data from an SPI device to the PRUs Apr 20 07:21:46 anujdeshpande: ok, just got there Apr 20 07:22:10 so using userspace drivers for spidev to read SPI Apr 20 07:22:23 then send data to PRUs as memory mapped reads? Apr 20 07:22:46 data to pru ? you mean PWM? Apr 20 07:23:08 anujdeshpande: well, you have to send something to the PRUs to do PWM, right? Apr 20 07:23:12 I'm asking specifically for data Apr 20 07:23:28 shared ring buffer if i remember correctly Apr 20 07:23:54 beacause I'd be working on the cubesat project (if I get accepted ofc) and one of the points is to offload as much of the processing to the prus as possible Apr 20 07:24:20 the PRUs will be working with fixed point arthmetic, matrix manipulations and the sort Apr 20 07:25:22 and while the PRUs can work with about 200MHz speed, and the sensor (MPU9250) can do only about 1MHz data, I'm not sure how much time would be spent routing the data from the SPI to the PRU Apr 20 07:25:48 so trying to get a feel for how much time would be spent on that part Apr 20 07:26:13 brb /lunch Apr 20 07:26:57 the data isnt big btw, should be around 9 16bit numbers Apr 20 07:27:34 anujdeshpande: ok, cool, I'll be going on to soldering some of the sensors to a lab nearby, ping back when you have time :) Apr 20 11:46:01 alexanderhiam: ping :D Apr 20 12:52:59 av500: ping :D Apr 20 12:57:53 yo Apr 20 13:05:50 av500: Can we know about the slots ? :D Apr 20 13:41:11 packt publishers are a bunch of confused people :p Apr 20 15:04:39 krian4399: pong Apr 20 15:16:35 alexanderhiam: Any queries related to pruduino ? Apr 20 15:31:18 kiran4399: We'll let you know if we have any questions, but at this point we've mostly got what we need from the proposlas Apr 20 15:32:34 alexanderhiam: can I know the number of slots ? Apr 20 15:33:24 I'm not sure... Apr 20 15:34:18 alexanderhiam: It's OK !! :D Apr 20 15:34:41 the number of slots has not been disclosed by the organization admins... Apr 20 15:34:45 please be patient :) Apr 20 15:35:09 all will be clear "soon" Apr 20 16:04:43 anyone seen victor around ? looks like his crowdfunding campaign is not going to make it through :( Apr 20 16:10:06 :( Apr 20 16:12:56 20% done with just 5 days to go Apr 20 16:17:04 that's sad to hear, I thought enthusiast and unversities would be all over the thing Apr 20 16:18:49 although, when I mentioned it to the people at Uni I attended, you get the old, has to be finished, packed, and billed ASAP to get funding from Uni - problem Apr 20 16:20:31 Will they be making PixHawks even without the indiegogo? Apr 20 16:20:47 can i have the link ?? Apr 20 16:20:54 https://www.indiegogo.com/projects/beagleuav-linux-drones-with-the-beaglebone-black#home Apr 20 16:21:02 geekswine: ^ Apr 20 16:21:15 kk Apr 20 16:28:18 alexanderhiam, nerdboy: chattable? Apr 20 16:28:44 * alexanderhiam is half here Apr 20 16:29:27 alexanderhiam: gonna be full here soon? Should I wait, or should I dump stuff from my mind? :) Apr 20 16:29:50 alexanderhiam: Wanna try and clear out the details from the proposal, so to edit it properly Apr 20 16:31:55 alexanderhiam: _av500_ Hey , How many proposals were this time ? Apr 20 16:33:12 Also how many slots did we get this time Apr 20 16:34:02 tejas: have patience -_- Apr 20 16:35:41 geekswine: I am just curious :p Apr 20 16:36:32 neemo: go for it Apr 20 16:37:57 * nerdboy updating chromebook rootfs Apr 20 16:39:46 nerdboy, alexanderhiam: So I've been missing out the last week because school stuff (sorry for that), but I managed to read most of the documentation on the PRUs, interfaces and the sensors and play around a bit with it Apr 20 16:40:35 I've managed to get the SPI test running on the debian BBB I've got (elinux wiki is waaay out of date, but I've fixed it with a lot od googling) Apr 20 16:41:17 Next step is reading from the MPU9250 sensors I've got last week, and getting some data via SPI from them to the beagle Apr 20 16:41:45 what kernel version are you using? Apr 20 16:41:47 and hopefully doing something with the data and the PRUs before the weekend Apr 20 16:42:17 alexanderhiam: default that arrived with it Apr 20 16:42:20 alexanderhiam: specifically, Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux Apr 20 16:42:49 I have the update ready on the sdcard, but was in a rush and didnt feel like waiting the hour for the flash (will do it soon though) Apr 20 16:43:10 neemo, should only take 5mins/gig ;) Apr 20 16:43:28 but besides the point, the elinux wiki is written for the angstrom distro (or so i figured) Apr 20 16:43:35 * neemo digging link, justa sec Apr 20 16:43:58 feel free to update it, otherwise it'll stay wrong. ;) Apr 20 16:44:01 this one, for spidev: http://elinux.org/BeagleBone_Black_Enable_SPIDEV Apr 20 16:44:12 latest debian flash has newer kernel, no? Apr 20 16:44:45 nerdboy: yes it has, didnt update yet Apr 20 16:45:17 nerdboy: this one is running, BeagleBoard.org BeagleBone Debian Image 2014-04-23 Apr 20 16:45:19 yeap, that the angstrom spidev, (mar 2014 last edit) so the debian image was only in 'beta' mode, so we didn't have wide spread usage back then.. Apr 20 16:45:25 so old, but spi works Apr 20 16:45:32 "official" debian sdcard image is still 3.8 ? Apr 20 16:45:57 nerdboy, correct, just (bone71 <-> bone47 maintaince fixes..) Apr 20 16:46:47 Linux genblack 4.0.0-bone0 #1 PREEMPT Sat Apr 18 15:09:43 PDT 2015 armv7l Generic AM33XX (Flattened Device Tree) GNU/Linux Apr 20 16:46:49 rcn-ee: yeah, the thing is it's easier to set up with debian (or so i think), but the difference (capemngr sh, or what's it called) is mentioned in just one place (just a sec will dig it out) Apr 20 16:47:18 yeah, we pulled in the spidev*.dtbo's... so you wouldn't have to even create them in the first place. ;) Apr 20 16:47:35 rcn-ee: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC here Apr 20 16:47:44 rcn-ee: yup, btw thanks for that! :) Apr 20 16:48:12 rcn-ee: when I sad the dtbo's I was relieved I wasn't going crazy, but was reading the wrong tut Apr 20 16:48:19 shouldn't need 3.8 cape stuff for this Apr 20 16:48:19 rcn-ee: sad = saw Apr 20 16:48:54 i2c/spi should work fine on newer kernels Apr 20 16:49:20 it does, you just need to manually enable it.. (capemgr still makes it 1-2 steps easier. ;) ) Apr 20 16:49:22 nerdboy: I needed to edit the capemgr just to load the proper spidev devices on boot, eg /dev/spi* was non exsistant before editing that file Apr 20 16:49:33 rcn-ee: yup Apr 20 16:49:53 * nerdboy says that without having really poked at bbb gpio interfaces Apr 20 16:50:04 rcn-ee, nerdboy probably should edit the elinux tutorial, I'll write up my experience on the blog anyway though Apr 20 16:50:12 nerdboy, a back street driver... ;) Apr 20 16:51:10 nerdboy: rcn-ee hiii How many proposals were this time ? Apr 20 16:51:37 nerdboy: How many proposals were this time ? Apr 20 16:52:47 tejas: didn't they say already that the proposals/slots are being kept private until selection? It's gonna be done in 5 days either way Apr 20 16:53:39 neemo: I thought ony number of slots are kept confidential Apr 20 16:53:55 atleast you can tell number of student applications Apr 20 16:53:59 tejas: dunno, but it's out soon anyway Apr 20 16:54:15 who can tell me about it Apr 20 16:54:28 rcn-ee: should I edit the elinux wiki later with the debian specifics? Apr 20 16:54:45 rcn-ee: later when I write up stuff on my blog and get more time obviously :) Apr 20 16:55:02 neemo: Do you know about any legality whether to tell number of students or not Apr 20 16:56:37 I think tejas disappeared Apr 20 16:56:44 tejas: back? Apr 20 16:56:44 neemo, it's over a year old, i'd just re-write assuming debian... angstrom doesn't have a bb.org maintainer, so it doesn't get much love anymore.. Apr 20 16:57:12 neemo: I am back :) Connection problem Apr 20 16:57:20 rcn-ee: Ah, ok. Do I have permissions to edit it? Apr 20 16:58:04 neemo, go for it, elinux is pretty free-form... Usually as users find something, they just post it up their.. Apr 20 16:58:26 rcn-ee: I'll play with that next week probs, gonna switch to never image, and eventually to Arch (cuz I'm a fanboy I guess) in the meantime Apr 20 16:58:32 rcn-ee: cool, thanks Apr 20 16:59:06 rcn-ee, nerdboy alexanderhiam: Aaaanyway, I got the spidev_test working (needed and older version of that source though, more trickery) Apr 20 17:00:04 Now I'm working on using the most out of the MPU9250 SPI driver the good people at ardupilot/beaglepilot did, so gonna try to reuse that as much as possible Apr 20 17:00:50 anujdeshpande: any insight on this ^ maybe? would appreciate it Apr 20 17:03:14 write a proper kernel driver! Apr 20 17:03:20 stop using spidev for stuff Apr 20 17:03:43 ds2: that's the plan, or I hope it is Apr 20 17:04:21 neemo: you do know there is a probally more variants of drivers for that chip (or its relatives) out there then you have fingers and toes, right? Apr 20 17:04:30 ds2: there's a coded SPI userspace driver for the MPU9250 sensor in the ardupilot source Apr 20 17:04:47 I am just talking about kernel drivers Apr 20 17:06:05 ds2: understand, and while I'm far from a kernel hacker, I hope to get there at some point Apr 20 17:06:45 ds2: was using spidev just to get my feet wet and figure out how the pinouts work and if it works at all on my little BBB Apr 20 17:08:18 what pin outs? this is straight forward - MISO, MOSI, CLK, CS Apr 20 17:09:26 It does (after a lot of head scratching), and now I'll try fiddling with the userspace drivers that are available, kernel driver hopefully in the GSoC period Apr 20 17:09:44 ask questions if you get stuck Apr 20 17:10:06 and read the datasheet Apr 20 17:10:17 ds2: it is straight forward, I was fiddling with the BBB GPIO for the first time though, so it took me awhile Apr 20 17:10:42 also the mentioned tutorial for angstrom didn't help leading me the opposite direction, but a bunch of googling fixed that Apr 20 17:11:20 what tutorial? Apr 20 17:11:22 ds2: I try to read up as much as possible before asking questions, trying to avoid boring people with stupid ones Apr 20 17:11:23 looks like just the MPU6050 kernel driver Apr 20 17:11:40 nerdboy: it is a 6050 + AKM Apr 20 17:11:59 ds2: http://elinux.org/BeagleBone_Black_Enable_SPIDEV, this one for the spidev Apr 20 17:12:07 ds2: gonna fix it up when this week ends Apr 20 17:13:20 sigh...more DT crap Apr 20 17:14:16 nerdboy ds2: this is what the progress says on the various device drivers used in the beaglepilot https://github.com/BeaglePilot/beaglepilot#Status Apr 20 17:14:53 nerdboy ds2: gonna use that as a starting point, I guess. or should I go a different route? Apr 20 17:15:01 ds2: DT? Apr 20 17:18:22 device tree Apr 20 17:18:45 anujdeshpande: thx Apr 20 17:18:55 vvu, ping Apr 20 17:19:23 anujdeshpande: any ideas on the driver status for these devices, as mentioned above? Apr 20 17:19:36 no not really Apr 20 17:20:18 anujdeshpande: who should I ask? if you have a name to point Apr 20 17:21:01 anujdeshpande: vmayoral (if that's his nick) ? Apr 20 17:21:12 victor isn’t around today Apr 20 17:21:15 try gitter Apr 20 17:24:01 anujdeshpande: kk, I'll try and wait for vmayoral to pop up as well Apr 20 17:24:09 anyway Apr 20 17:29:27 device tree Apr 20 17:30:09 nerdboy alexanderhiam (any anyone else who'd like to help out): more questions so I can fix up the proposal, feel free to respond when ever you see them Apr 20 17:30:56 ds2: thanks, anujdeshpande cleared it out as well Apr 20 17:31:52 So I have to get the data from the MPU9250 to the PRU for processing Apr 20 17:31:53 sorry about the delay... I am in and out Apr 20 17:32:20 ds2: nps, thanks for the chipping in on my way to figuring out how to do this GSoC project Apr 20 17:34:16 Q1) I can do the data reading as is done now, SPI driver (convert it from a userspace one to a kernel one for good measure) gets the data from the sensor to the ARM core Apr 20 17:34:59 ARM core writes the data to the shared memory segment of the PRU and makes it run the processing algorithms needed to fix the offsets in the data points Apr 20 17:35:54 There is (presumably) an alternative way, by getting the PRU to read the SPI data directly from the SPI interface and into the PRU (I think via dma?) Apr 20 17:36:08 It's mentioned in this discussion for example: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/252437 Apr 20 17:37:22 Am i reading something wrong? Can this work and should I think of doing something like this, or should I stick to the first method of getting data into the PRU? Apr 20 17:39:59 the other option is to bit-bang the SPI in the PRU, which would be the most real-time way because you're not waiting for any data to be transferred over the ARM interconnect Apr 20 17:40:36 Q2) If using the SPI kernel driver (which I would have to write probably), alexanderhiam you mention the advantage of having a kernel driver with sysfs entries for easy access (language agnostic) to the processed data from the PRUs. I'm guessing that means writing a second kernel driver for the PRU, to be able to load the algs and give data out in a file system entry? Apr 20 17:41:07 alexanderhiam: I was thinking of bitbanging, but the more I though about it, the more it seemed like a supreme waste of resources on the PRU Apr 20 17:41:21 neemo: which project is this for?? Apr 20 17:41:28 * apaar is just curious :) Apr 20 17:41:46 alexanderhiam: since the PRU is running on 200Mhz, and the max clock for the MPU9250 SPI is 1Mhz Apr 20 17:41:53 neemo: what do you mean by load the algs? Apr 20 17:42:12 at least that's what I've found in the datasheet for the MPU Apr 20 17:42:29 alexanderhiam: I meant loading the algorithms for the processing needed to fix the offsets into the PRUs Apr 20 17:42:59 alexanderhiam: the smallish matrix manipulations, done ine fixedpoint math on the PRUs Apr 20 17:43:16 you mean tuning them? Apr 20 17:44:48 alexanderhiam: yeah, correcting the data read from the sensors by the computed correction factors, also getting the correction factors Apr 20 17:46:07 I would say you don't want any repeating critical parts of the algorithm in userspace. If it's tuning specific to the user application than it makes sense to have an API for it Apr 20 17:46:39 the user in this case being someone making a cubesat with this Apr 20 17:47:06 alexanderhiam: what do you mean by tuning specific to userspace? Apr 20 17:48:00 alexanderhiam: the reapeating parts, eg the PRU algorithms for correction of time variant and time invariant sources of error, should be loaded by the kernel driver into the PRU Apr 20 17:48:33 the user can choose what algorithms to run or not run from the API, but they will be there and available for use. at least that's the idea Apr 20 17:48:55 first of all, what's the desired output? Is it just raw sensor data? Is it rotational and orbital position? Apr 20 17:51:56 I would hope that a user wouldn't need to understand exactly how a bunch of different algorithms work to use this. IMO it should be more of a black box Apr 20 17:52:03 the PRU algorithm should give the corrected sensor data, the API can process that further, eg. store it or use it for position tracking etc Apr 20 17:52:20 the user should just call from the API what he wants to get Apr 20 17:52:31 rawdata, directly from the sensor Apr 20 17:52:53 processed with static error correction, with dynamic, or with both Apr 20 17:53:05 so what's the benefit of this system? Who' the user? Apr 20 17:53:16 he should never see the algorithms themselves Apr 20 17:54:15 someone who's building a cubesat based on the BBB and wants to do something useful with it Apr 20 17:55:13 and what challenging parts of that process does this abstract away for them? Apr 20 17:55:45 the and goal being something like, keep camera position focused on a fixed spot, or angled correctly to some line towards the earth (once all the other systems are in place) Apr 20 17:56:52 it should enable someone with no idea that there's a PRU on the beaglebone to offload processing of the sensors data with the proper correcting factors Apr 20 17:57:01 to the PRu Apr 20 17:57:33 and get a much better 9DOF readout than without this black box he's using Apr 20 17:57:47 magnetometer data correction being the main benefit Apr 20 17:59:03 So, show someone to connect the sensor properly, run the algorithms (via the API), and do something useful with the data later on (via the API) Apr 20 18:00:51 so will there be sysfs entries like /sys/devices/cubesat/x_rotation, /sys/devices/cubesat/y_rotation and /sys/devices/cubesat/z_rotation? Apr 20 18:01:27 alexanderhiam: Am I missing something? I thought the whole point is to make the BBB as friendly to Cubesat builders as possible (overall project), and get magnetometer data corrected with NASA's latest stuff to enhance trajectory tracking and a lot of other stuff with it (phase I) Apr 20 18:01:49 how much space do you think it will take code wise? Apr 20 18:01:54 right, which is why the API design is really important Apr 20 18:03:03 alexanderhiam: well, if that makes it easier to use, I'm all for it! as I said, im kinda new to the kernel stuff and API design, but that's why I'm asking hopefully not stupid questions to get the proposal and the project in best shape Apr 20 18:04:00 alexanderhiam: eg. if we're talking about just the user perspective, he should never leave the API, unless he wants to expand it in some new way (which should happen, since cubasats are research after all) Apr 20 18:05:05 right, and ideally the user shouldn't /need/ to touch any tuning coefficients Apr 20 18:07:03 webglider: pong Apr 20 18:07:20 of course not, I mean, someone will probably make better algorithms at some point in time and improve on the stuff available, but these two which are proposed, will be code written for the PRU Apr 20 18:07:47 and they should be called from the api in some very straightforward manner Apr 20 18:08:48 sensor1.magnetometer.get_corrected_data() Apr 20 18:10:35 or even better, eg. sensor1.magnetometer.store_corrected_data("/../../file") Apr 20 18:11:39 alexanderhiam: those my reasoning make sense? Apr 20 18:11:46 those = does Apr 20 18:13:02 yeah, though I think you need to simplify your idea of the API. Everything would likely go through sysfs entries, and wouuld just be things like getting data and maybe setting the sample rate Apr 20 18:14:46 Ok, the API is the last thing to get standardized though, since it depends on a lot of the other subsystems on the Cubesat, so it probably should be done in later phases of the project Apr 20 18:15:20 not to mention, it needs a lot of input from the community on what the proper design is Apr 20 18:15:31 no, I'm talking about the API to this specific kernel driver. That would theoretically then be used in later libraries Apr 20 18:15:54 when I say API here I'm referring to the sysfs entries Apr 20 18:15:57 a yeah, I'm talking about the later libraries Apr 20 18:16:04 ok, understood now Apr 20 18:17:10 I'm thinking of pushing the later libraries (for the overall project, what I called an API) out of the scope of this GSoC project Apr 20 18:17:22 beacause of the reasons above Apr 20 18:17:28 so later on there could be a kernel driver that controls reaction wheels, and then the cubesat library could have a routine for getting the current rotation and routines for setting a new rotation, each using the sysfs entries for their corresponding drivers Apr 20 18:18:01 yeah that would be reasonable. Starting them could be a stretch goal Apr 20 18:18:30 I'm planning on making test examples for the magnetometer and PRU stuff anyway, and from there will tie it to other systems at some later point Apr 20 18:18:46 yeah, stretch goal then Apr 20 18:19:01 test examples stay in the timetable though Apr 20 18:19:43 or just do a quick mock-up in a language like Python that's just a wrapper for the sysfs entries Apr 20 18:19:55 alexanderhiam: yeah, sounds good Apr 20 18:20:35 So coming back, there should be a sysfs entry for each device (and a correspoding kernel driver for each of them) Apr 20 18:21:06 define device Apr 20 18:21:17 correct? Apr 20 18:21:39 well if I want the processed data be available as a sysfs entry Apr 20 18:22:00 I have to write a kernel driver for the PRU, no? Apr 20 18:28:22 alexanderhiam: am I missing something? Apr 20 18:29:17 hold on, on call Apr 20 18:40:35 neemo: the kernel driver would load the firmware into the PRU and would forward the data from it to the sysfs entries. The project your proposing would have one kernel driver, which would provide multiple sysfs entries for reading the data, e.g. one entry per axis Apr 20 18:46:02 makes sense Apr 20 18:47:35 but depending on how I get the data, eg. from the SPI (or I2C) interface, I'd need a kernel driver for the MPU9250 and a corresponding sysfs entry for the raw data as well. correct? Apr 20 18:48:02 alexanderhiam: ^ Apr 20 18:51:09 If I bitbang the SPI interface on the PRU I woudln't need one, also no nemory overhead, but I feel it's a poor use of the PRUs, which will be useful for camera and other subsystems in later phases Apr 20 18:55:47 alternatively, the PRUs should have access to the full memory map and should be able to acces the SPI interface directly, but that brings some memory penalties with it. It's kinda mentioned here http://e2e.ti.com/support/arm/sitara_arm/f/791/t/252437, but I didn't see any examples of this and I'm not sure how good of an idea it is Apr 20 19:07:32 neemo: there's no real need to do a separate driver, you wouldn't be using sysfs entries to get the data to the PRU Apr 20 19:13:42 alexanderhiam: fair enough, makes more sense Apr 20 19:14:57 but the raw data should be available as well (at least I think it should be) ? Apr 20 19:15:47 there could be something like x_raw and x_corrected Apr 20 19:16:08 yeah, that's what I was thinking Apr 20 19:16:21 depending on what you mean by raw Apr 20 19:16:41 which way of getting data to the PRU should I pursue Apr 20 19:16:48 from the three above? Apr 20 19:17:28 there wouldn't be much point in providing raw ADC conversions, but maybe uncorrected values after converting them to their units Apr 20 19:18:03 alexanderhiam: ok Apr 20 19:18:55 but for example, if the user wants to store the data streams in a file somewhere (for further processing or nitpicking for odd reads to be transmitted back to earth at some point) Apr 20 19:20:11 I can see a case where he wants to do something like storing the raw (unprocessed data), data processed with static correction, data processed with time variant correction, data processed with both in a single file Apr 20 19:20:48 that would also depend on the sample rate, as that would mean passing around more data Apr 20 19:20:56 does that mean we would have 4 sysfs entries for each data variable (eg. x) Apr 20 19:21:20 y Apr 20 19:21:42 a separate enry for each is one way to do it Apr 20 19:21:47 entry* Apr 20 19:23:07 is that the way we want do to it? I mean, if we get better algorithms in the future, we'll just be adding more sysfs entries Apr 20 19:23:39 I'm guessing thats not a bad thing as long as it's organized, but just asking to make sure Apr 20 19:24:24 seems reasonably. There could be a subdirectory for each axis Apr 20 19:24:49 i.e. /sys/devices/cubesat/rotation/x/raw, ... Apr 20 19:26:45 or /rotation/raw/x, y, .... Apr 20 19:27:08 ok, gotcha, one kernel driver for the PRU to do the proper things Apr 20 19:28:12 sysfs design details can come later Apr 20 19:28:48 also the MPU9250 seems to use 16 bit ADCs Apr 20 19:29:51 so it's seem fixed point should work on the 32bit PRUs Apr 20 19:30:39 well fixed point will always work, it's just a matter of whether or not you lose too much resolution Apr 20 19:30:53 y Apr 20 19:32:02 I'm going through the algorithms now to figure out how much would they crunch on the PRUs Apr 20 19:35:40 * neemo looking though a pile of pdfs for the proper equations Apr 20 19:47:35 alexanderhiam: yeah, so error correction once you have the correction parameters should be an issue, since its a couple of sums and multiplications Apr 20 19:47:48 shouldn't be an issue Apr 20 19:51:47 the time invariant correction parameters though, are computed using a batch method minimizing a cost function Apr 20 19:59:30 gm Apr 20 20:15:50 alexanderhiam nerdboy: Since the dynamic error correction algorithm is a bit computing intensive, I'll look into how it could be ported to the PRU, or how much time it would eat on it Apr 20 20:17:05 there is still the option of computing the parameters on the ARM and bundling them for the data processing algorithm on the PRU Apr 20 20:22:51 alexanderhiam nerdboy: I'll be updating the proposal with the things we discussed tomorrow night (in about 16ish hours) and probably once more before the end of the week. Is that OK timewise? Should I hurry for the mentioned deadline in nerdboy 's comment? Apr 20 20:31:43 the sooner the better Apr 20 20:36:50 yesterday even better... Apr 20 20:37:34 so the usual :) Apr 20 20:40:01 I'll go get some shut eye now to keep myself from writing stupid stuff in the proposal at 4:30 am Apr 20 20:41:42 nerdboy alexanderhiam :I'll be sure to ping you both, when I edit it first thing in the morning Apr 20 20:42:37 (and probably again later when it'll be sane hours in the US) Apr 20 20:43:24 in either case, thank you all for the feedback and explanations Apr 20 20:44:07 and good night o7 Apr 20 20:55:23 neemo: From what I am seeing being discussed, I have a very serious concern that the resource limits on the PRUSS is not being considered **** ENDING LOGGING AT Tue Apr 21 02:59:58 2015