**** BEGIN LOGGING AT Thu Mar 20 02:59:59 2014 Mar 20 07:06:46 ds2: ping Mar 20 09:37:57 tridge: if possible, i'd appreciate if i could get some pointers on this code doubts https://groups.google.com/forum/#!topic/beaglepilot/apdfrT2fS-8 (according to kevinh_ comments we will try using a bit more the BeaglePilot mailing list so that everyone can follow). Thanks :)! Mar 20 09:38:39 sidbh_, anujdeshpande: everything fine guys? anuj, how's the timeline doing? let me know if need opinions on something Mar 20 09:39:46 vmayoral: i think so :) Mar 20 09:41:05 vmayoral: also jkridner made a suggestion that the title of the project should ellaborate the *part* of the beaglepilot project the proposal is covering Mar 20 09:41:23 so don't forget to change the title accordingly Mar 20 09:43:17 sidbh__: thanks for informing about that, i will change mine right away Mar 20 09:44:00 i quickly went through some of the comments in the last hours and i saw quite a lot of interest on BeaglePilot, i'm quite happy we inspired so many people Mar 20 09:46:48 +1 Mar 20 10:00:10 anujdeshpande, replied Mar 20 10:30:57 panto: thanks ! I'll try adding more details about the modules and how their architecture could be. Mar 20 10:31:08 vmayoral: pushed to the timeline. do take a look Mar 20 10:32:11 anujdeshpande, damn you, you'll make me make more stuff for the PRU Mar 20 10:35:34 haha Mar 20 10:36:29 seriously, some of the stuff you need I'll probably have to make them Mar 20 10:36:50 nothing related to your projects, more like infrastructure stuff Mar 20 10:39:19 panto: sidbh_ would be working on stuff for infrastructure. I won't mind helping too. wouldn't want to put a lot of workload on you. Mar 20 10:40:13 let's just some of the stuff is non-obvious Mar 20 10:40:15 *say Mar 20 10:44:39 panto: i see. i did realise that a lot of what we are proposing is a bit of a grey area. how could we (me and sidbh_) help out more ? I don't mind beginning work earlier so that I could contribute more. Mar 20 10:45:05 first of all I would appreciate it if you port the PRU changes to mainline Mar 20 10:45:14 lots of things have changed since then Mar 20 10:45:28 update the PRU example to work with it Mar 20 10:45:32 and with the new compiler Mar 20 10:45:38 and then I'll take it from there Mar 20 10:46:17 * vmayoral is really happy to have panto onboard Mar 20 10:46:26 panto: sounds like a plan :) I'll co-ordinate with sidbh_ and vmayoral on this then Mar 20 10:46:43 anujdeshpande: thanks for the push, the three proposals together look good on me Mar 20 10:46:54 you have no idea yet what you're signing up to do :) Mar 20 10:47:00 it's going to be fun Mar 20 10:47:03 vmayoral: yepp Mar 20 10:47:21 panto: hahaha looking forward too :D Mar 20 10:48:09 copy paste this line someplace and look at it after a few months :) Mar 20 10:51:36 panto: took a screenshot :D Mar 20 11:05:07 sidbh: ping Mar 20 11:06:33 anujdeshpande: pong Mar 20 11:07:17 sidbh: i guess you pinged out. did you follow my and pantos conversation about the prerequisites Mar 20 11:07:35 pls share Mar 20 11:08:11 sidbh: check mail Mar 20 11:11:12 yeah got it! Mar 20 11:12:53 sidbh: loads to do :) Mar 20 11:13:41 anujdeshpande: that is true... Mar 20 13:27:20 ds2: ping Mar 20 16:42:09 ds2: ping Mar 20 20:29:54 sidbh: you rang earlier? Mar 20 20:30:23 ds2: yepp Mar 20 20:30:32 I read your comment on my proposal, i do not understand what analysis/estimate do you expect, is it the size of the firmware binaries for PRU or the quantity of coding which will be required. Mar 20 20:30:47 size of the binaries for the PRU Mar 20 20:30:52 basically - will it fit in IRAM Mar 20 20:31:19 you sounded like you want to do a lot of things in the PRU Mar 20 20:31:46 yeah as per my understanding it should, because most part of the firmware will be writing and reading the registers Mar 20 20:32:05 and almost all of the initialisation will be done in userland Mar 20 20:32:13 thought you wanted to also do PWM on there? Mar 20 20:32:27 yeah there are 2 PRUs Mar 20 20:32:36 one will be handling PWM/PPm Mar 20 20:32:48 other the sensor data collection Mar 20 20:33:09 the PWM/PPM part is covered by anujdeshpande in his proposal Mar 20 20:33:16 your rational for doing PWM in the PRU is so it can locally react to things...doesn't that imply you will have to do number crunching there ? Mar 20 20:35:41 as stated by vmayoral after his discussion with tridge, the reason behind using PWM locally is " implementing PWM in the PRU might allow to have more PWM signals with 1) good timings and 2) configurable characteristics (e.g. different frequencies)" Mar 20 20:37:18 and you can do all of that with the ehrpwm Mar 20 20:37:49 it is a HW block, the timing ain't changing w/o the xtals drifing and if that happens, the PRUs are affected too Mar 20 20:38:53 ds2: please correct me if I'm wrong (often the case!), but my understanding is we would be limited to 8 outputs with ehrpwm, and we wouldn't have the flexibility of arbitrary speed on each output (ie. it would be in groups of speeds) ? Mar 20 20:39:16 tridge: 8 outputs? 4, IIRC Mar 20 20:39:34 the speed as in the base clock is configurable on a pairwise basis Mar 20 20:39:45 I think you might be confusing it with the ecap stuff Mar 20 20:39:55 that too can do pwm but resolution is a bit more limited Mar 20 20:41:12 yes - 8 in combination with ecap output. we'd like at least 12 outputs for the fire cape Mar 20 20:41:46 and we want arbitrary speed on each output to prevent having issues with output mapping between all our different boards Mar 20 20:42:09 we have 14 pwm outputs on the pixhawk, and users often use more than 8 Mar 20 20:42:14 what kind of thing on the receiving side needs different base clocks? Mar 20 20:42:16 (I use 9 on my plane) Mar 20 20:42:25 are these the RC gyros? Mar 20 20:42:35 not gyros Mar 20 20:42:39 the servos I mean Mar 20 20:43:06 its common (for example) to run 8 chanells at 450Hz for a octacopter (ESCs). Then 2 for digital servos at 200Hz, then 2 more at 50Hz for slower servos Mar 20 20:43:52 continuing on the tangent... do all the ESCs take PWM in? Mar 20 20:43:56 s/chanells/channels :-) Mar 20 20:44:16 we are also supporting I2C servos, and will soon add CAN Mar 20 20:44:22 err, I2C ESCs Mar 20 20:44:52 the big advantage of I2C and CAN is getting current feedback Mar 20 20:45:09 as current based control is more accurate for multi-copters than speed based control Mar 20 20:45:13 but getting back to the original thing, do you need local number crunching on the PRUs? or you just need them to be dumb PWMs? Mar 20 20:45:16 but nearly all users use PWM for now Mar 20 20:45:23 just dumb Mar 20 20:45:35 I think a shared ring buffer of timings is all that is needed Mar 20 20:45:46 got it... I was hearing a different story before Mar 20 20:45:56 the main CPU will fill the ring buffer, the PRU will generate the pulses Mar 20 20:46:27 the most complex thing will be the combination of S.BUS and PPM-SUM on an input pin Mar 20 20:46:29 I think panto saw some potential arbitration issues with live edits of shared memory so be warned Mar 20 20:46:59 I asume we can do atomic 16 bit updates? that is all we need Mar 20 20:47:51 yes but the unknown is - what if the ARM access and the PRU accesses collide Mar 20 20:47:57 does the HW handle that right Mar 20 20:48:25 PRU would only be reading, ARM only writing, there should be no memory that is being written by both Mar 20 20:48:39 I think the results of that discussion (correct me if I am off, pantos) is most firmware today run - halt - let the arm do its thing - resume Mar 20 20:49:02 hmm, we'd need the PRU to run continuously Mar 20 20:49:13 is there some reason why it can't? Mar 20 20:49:16 supposely it is on the access level...not an issue of write contention Mar 20 20:49:20 HW limitations :) Mar 20 20:49:31 that's why I sent out the message about needing to explore the PRU first Mar 20 20:49:35 anything more specific? :) Mar 20 20:49:42 otherwise, in your case, you can have birds falling out of the sky :( Mar 20 20:49:47 I wish... Mar 20 20:49:52 yes, I completely agree on exploring first Mar 20 20:50:01 but that exploring can take a lot of time Mar 20 20:50:04 and my first uses on a real vehicle will be a ground rover Mar 20 20:50:09 unfortunately, there were no takers to my mail :( Mar 20 20:50:17 and we are out of time for proposals Mar 20 20:50:28 ground rover on mars? ;) Mar 20 20:50:43 not quite .... my local oval :) Mar 20 20:51:09 if there are gaps the students can't work on I'll fill those gaps myself Mar 20 20:51:20 btw - you are aware there is also a eCap hw block on the PRUSS, right? Mar 20 20:51:39 there is a 2nd eCap? Mar 20 20:51:47 yes Mar 20 20:51:54 but no one has used it yet Mar 20 20:51:56 wow, I didn't know that, nice! Mar 20 20:52:01 hence the need to explore the PRUSS Mar 20 20:52:19 tridge, I've seen that arbitration on internal shared RAM doesn't work for concurrent accesses Mar 20 20:52:28 yeah and an UART too Mar 20 20:52:29 has anyone done an input driver for eCap on the ARM yet? Mar 20 20:52:35 tridge, yes Mar 20 20:52:38 mdp has Mar 20 20:53:06 panto: we could use a pin as a signalling system for switching between two banks of timings Mar 20 20:53:31 ie. ARM writes new timings to new chunk of shared ram, then changes a pin state to say which chunk is current Mar 20 20:53:42 ugh, probably it would work Mar 20 20:53:44 but I don't like it Mar 20 20:53:46 PRU switches to new chunk, and flips another pin to ack Mar 20 20:54:01 the PRU can access the whole memory map of the ARM (or almost all of it) Mar 20 20:54:14 but that can be painfully slow Mar 20 20:54:29 define painfully slow Mar 20 20:54:34 DRAM is plenty fast Mar 20 20:54:38 more then 2-3 cycles of PRU time Mar 20 20:54:40 we need very predictable timing to ensure pulses are consistent Mar 20 20:55:01 what do you want to share in the sram? Mar 20 20:55:01 it doesn't have to be all that fast though - 1us precision is fine Mar 20 20:55:12 there are mailboxes Mar 20 20:55:23 with small FIFOs Mar 20 20:55:23 a timing table for 12 PWMs Mar 20 20:55:28 I am wondering if a hw board is more appropriate - say a small FPGA or CPLD Mar 20 20:55:56 if the PRUs can do it without extra hw I'd like to use that to keep it simple Mar 20 20:55:56 panto: there are? what's a good keyword to search in the TRM? Mar 20 20:56:13 tridge, err, you don't keep the timing parameters in IRAM Mar 20 20:56:31 err, data ram Mar 20 20:56:37 ds2, wait Mar 20 20:56:39 looking Mar 20 20:57:45 chapter 17 Mar 20 20:57:49 interprocessor communication Mar 20 20:57:56 mailbox, spinlock Mar 20 20:58:12 that's outside of the PRUSS, right? Mar 20 20:58:16 yes Mar 20 20:58:28 but there are events directed to it Mar 20 20:58:32 but access to that is fast? Mar 20 20:58:35 4 interrupts (one per user: 1 to MPU Subsystem, 2 to PRU-ICSS, and 1 to WakeM3 Mar 20 20:58:41 i.e. no more then 1-2 cycle stalls Mar 20 20:58:43 could be a few cycles Mar 20 20:58:48 wait, you're doing it wrong Mar 20 20:59:04 you are not supposed to load the parameters for the PWM each time from the configuration memory block Mar 20 20:59:23 you only use it for communicating the updates Mar 20 20:59:55 you then store the parameters in data ram and load a whole block of registers at once Mar 20 21:00:02 but if reading hte update stalls the PRU beyond the edge of the PWM cycle, it would lead to jitter Mar 20 21:00:24 you can compensate, or use the other PRU for comms Mar 20 21:00:39 the jitter will be in the order of ns Mar 20 21:01:30 if you use the hardware pwm you'll get some jitter there too Mar 20 21:01:51 anytime you go out of the PRU domain you will suffer an amount of jitter Mar 20 21:02:02 that's why there are two PRUs Mar 20 21:02:07 ah.. so about 1-3 cycle stall Mar 20 21:03:05 ds2, it's a small amount, but I can't tell you the amount exactly Mar 20 21:03:11 someone from TI has to answer that Mar 20 21:03:29 panto: but it is definitely less then the worse case of reading/writing to the DDR, correct? Mar 20 21:03:34 yes Mar 20 21:03:35 ns is fine, we need usec precision Mar 20 21:04:14 tridge, fwiw my example PRU program that uses C, outputs on 20 PWM channels, with about 4usec precision Mar 20 21:04:43 panto: is your examples available somewhere? Mar 20 21:04:49 of course Mar 20 21:04:49 panto: do you know what is the limiting factor that leads to 4us precision? Mar 20 21:05:07 and it has been for a year or so (part of the standard angstrom release) Mar 20 21:05:15 guessing L3 traffic jams Mar 20 21:05:20 ah on Angstrom Mar 20 21:05:23 will look there Mar 20 21:05:26 https://github.com/pantoniou/testpru Mar 20 21:05:35 thanks! Mar 20 21:06:30 tridge, it's C Mar 20 21:06:51 not precise cycle counting possible, so you have to use the cyclecount registers Mar 20 21:07:10 cycle count? why not use the timer? Mar 20 21:07:14 plus, the whole point of it is to serve as an example Mar 20 21:07:25 and do wake ups on the capture registers Mar 20 21:07:29 ds2, it is same thing Mar 20 21:07:34 CPU cycle counter Mar 20 21:07:42 with some careful work, do you think better than 1us is possible? Mar 20 21:07:45 there's another counter that measures stalls Mar 20 21:07:51 no there is another counter Mar 20 21:07:53 tridge, yes Mar 20 21:07:53 let me find the docs Mar 20 21:07:57 I know Mar 20 21:08:21 I used it too Mar 20 21:08:49 my understanding/reading of it is, I can sleep and wakeup based on the capture Mar 20 21:09:17 so something like do FOO; access slow stuff; setup wakeup; sleep; and repeat Mar 20 21:09:34 you can do that Mar 20 21:09:38 it's what I do too Mar 20 21:09:44 capture = event Mar 20 21:09:49 ah Mar 20 21:09:59 look at this: https://github.com/pantoniou/testpru/blob/master/testpru1.c Mar 20 21:10:16 its using rustys vring, cute :) Mar 20 21:10:27 though that uses 64 bit addresses Mar 20 21:10:36 might be worth changing to 32 bit for this use Mar 20 21:10:57 rusty's vrings are unfortunately overly complex for the PRU Mar 20 21:11:12 they can be made to work, but it's a hard sell Mar 20 21:11:32 pru_signal() is an intristic? Mar 20 21:12:01 yes, it directly accesses the R31 register Mar 20 21:12:53 remember, even when you use assembly and you have to do comms, you will incur an amount of jitter Mar 20 21:13:07 you must have a way to compensate Mar 20 21:13:26 but the jitter will be in the nsec range Mar 20 21:13:29 indeed Mar 20 21:13:42 of course, some of us want to do nsec range comms ;) Mar 20 21:13:50 the core of pwm_loop() and pwm_loop2() is pretty simple - I'm sureprised there is 4us of slop there Mar 20 21:13:54 ds2, well yes Mar 20 21:14:10 tridge: the C compiler is amazingly dumb Mar 20 21:14:12 tridge, the compiler is not super smart Mar 20 21:14:32 its 5ns cycles, yes? Mar 20 21:14:37 looking at the assembly from it is very insightful Mar 20 21:14:37 yes Mar 20 21:14:47 800 cycles of slop .... wow Mar 20 21:14:50 the compiler seems to like to do things in 32bit chunks Mar 20 21:15:00 which makes loading constants a 10nS affair Mar 20 21:15:03 or more Mar 20 21:15:10 maybe its secretly computing Pi in the background :) Mar 20 21:15:35 tbh, I doubt the full amount of jitter is from the compiler Mar 20 21:15:54 how did you measure the 4us error? logic analyser? Mar 20 21:15:57 scope Mar 20 21:16:03 it's not a 4us error Mar 20 21:16:07 it is unfortunate the L3 is also at 200MHz Mar 20 21:16:16 maybe I didn't explain my self correctly Mar 20 21:16:32 the lower limit of resolution when driving all those PWMs in parallel is 4us Mar 20 21:16:55 the jitter is much lower, in the order of 300-600ns Mar 20 21:18:00 pwm_loop() is for just one PWM ? (I am guessing changing __R30 bit 13 is one pin?) Mar 20 21:18:41 is there a 'asm {....}' thing for the C compiler? Mar 20 21:18:50 pwm_loop is a testing leftover Mar 20 21:18:56 ds2: yes Mar 20 21:19:12 the real work is done in main Mar 20 21:19:19 ok, so SINGLE_PWM() is the real work Mar 20 21:19:19 ds2, no :( Mar 20 21:19:57 SINGLE_PWM is calculating transitions for a single PWM Mar 20 21:20:03 the C code is very nice but looking at the assembly output makes one not want to use it Mar 20 21:20:35 I can't do much about the compiler :) Mar 20 21:20:35 looks like PRU is doing the cycle calculations. Maybe the shared buffer provided by the ARM should be prescaled to PRU cycles? Mar 20 21:20:49 it would be best, yes Mar 20 21:21:06 ds2, the same logic can be converted to assembly Mar 20 21:21:37 wonder if anyone is making use of the MAC on the PRU Mar 20 21:21:47 some people do Mar 20 21:21:50 ie. a buffer of PRU cycle counts and channels. PRU continuously walks the table, delays the given number of cycles and then flips the channel. So all PWM pulse widths etc are calculated on ARM Mar 20 21:21:54 there was a guy hanging on #beagle Mar 20 21:21:59 core loop on PRU would be very simple Mar 20 21:22:12 tridge, you have to do that in parallel Mar 20 21:22:24 if you have more than one PWM Mar 20 21:22:31 why in parallel? the table could be interleaved Mar 20 21:22:49 I mean you calculate transition times for all the channels Mar 20 21:22:56 and wait the minimum found Mar 20 21:23:00 ie. table of 32 bit numbers. Bottom 8 bits is pin, top 24 bits is delay in cycles Mar 20 21:23:20 all hard work to create the table is on ARM Mar 20 21:23:22 if memory accesses was handled right, you could just do it as a giant DDS system Mar 20 21:24:50 anyway, I don't want to impose any implementation details Mar 20 21:24:52 so PRU just does while (1) { delay(cycle_delay); pin ^= 1; } // leaving out pin shift etc Mar 20 21:25:01 you're free to go about it as you like Mar 20 21:25:16 sure, but I really appreciate you sharing your example, thanks! Mar 20 21:25:29 helps me think about how to try Mar 20 21:25:44 tridge, more like: Mar 20 21:25:57 find out closest time of transition Mar 20 21:26:10 make a mask of pins that change state at that point in time Mar 20 21:26:28 wait for that time to be present Mar 20 21:26:44 for 12 channels, all the working numbers can be done in registers Mar 20 21:26:47 perform the transitions of the mask Mar 20 21:27:01 right Mar 20 21:27:07 we could avoid the mask by just allowing delays of 0 Mar 20 21:27:21 then you'd get jitter Mar 20 21:27:23 does the PRU really save power if you execute sleep? Mar 20 21:27:24 i suspect the final code will be in asm Mar 20 21:27:51 C will be great for prototyping though Mar 20 21:28:02 anyway, that piece of code was only for demo purposes Mar 20 21:28:07 and driving a few servos Mar 20 21:28:57 does PRU care about aligned accesses btw? faster aligned, or fault on misalgned? Mar 20 21:29:07 tridge: in a nutshell, how many non overlapping proposals are there for beaglepilot? Mar 20 21:29:19 it just masks out the bits Mar 20 21:29:27 I don't think they're possible Mar 20 21:30:04 ds2: there are 3 students that I have had real discussions with, victor, sidbh and anuj Mar 20 21:30:06 for a low amount of channels you could get by with C Mar 20 21:30:37 tridge: but are they non overlapping or are there 3 students competing for the same project? Mar 20 21:30:39 i expect the students will be collaborating a lot, they won't really be able to work in isolation from each other Mar 20 21:31:07 i see it more as a 3 person team, each will concentrate on a particular aspect of the project Mar 20 21:31:31 the hard bit is working out how much time each part will take Mar 20 21:31:43 as it depends so much on what roadblocks are hit Mar 20 21:31:54 we know there will be roadblocks, we just can't see them yet :) Mar 20 21:32:04 are you donating quadcopters to each student to test their code ? ;) Mar 20 21:32:33 ds2: no, but I think they have them already. Initial tests will be a ground vehicle anyway, then fixed wing, then quad Mar 20 21:32:40 quads are very unforgiving Mar 20 21:32:47 fixing wing you can take over in manual Mar 20 21:32:52 s/fixing/fixed Mar 20 21:33:02 but quads are cooler :D Mar 20 21:33:19 well, real initial tests will be flying a scope and logic analyser actually :) Mar 20 21:33:31 yeah, they are cool until they crash! Mar 20 21:33:33 do those fly well? :) Mar 20 21:33:57 depends if you set the triggers right :) Mar 20 21:34:22 i've given the students ssh access to a BBB on my lan Mar 20 21:34:31 so we can collaborate on a common board (running debian) Mar 20 21:34:45 cool...botnet ;) Mar 20 21:34:51 they will have their own boards too, but it will be easier to test/collaborate with a shared board Mar 20 21:35:05 and I'll install the fire cape on that board once the prototype is built Mar 20 21:35:35 apart from the PRU work the biggest lump of work will be getting all the sensors on the cape running Mar 20 21:35:44 sensors are easy Mar 20 21:36:00 sesnors are easy if you don't mind bad timing :) Mar 20 21:36:08 sensors are hard for a autopilot Mar 20 21:36:14 they are easy after doing it 100's of times :( Mar 20 21:36:17 I spend a lot of time on sensor driver coding Mar 20 21:36:36 the SPI bus is going to be very busy Mar 20 21:36:55 you got everything on SPI? Mar 20 21:37:05 all the fast sensors on SPI Mar 20 21:37:11 some slow ones on I2C Mar 20 21:37:17 fast? what you calling fast? Mar 20 21:37:37 1kHz sampling, 3 gyros, 3 accels, 3 baros, 2 mags Mar 20 21:37:53 plus 2xGPS, airspeed, sonar etc Mar 20 21:38:01 which mag are you using to get 1KHz? Mar 20 21:38:08 mag isn't at 1kHz :) Mar 20 21:38:16 mag will be 100Hz Mar 20 21:38:27 which one are you using that will do 100Hz reliably? Mar 20 21:38:29 (actually, might be 80 ... need to check) Mar 20 21:39:04 there are mags that will do 1KHz but there are other side effects Mar 20 21:39:15 hmc5883 does it, we'll have both hmc5883 and lsm303d, probably hmc5983 soon Mar 20 21:39:24 lsm303d is on SPI Mar 20 21:39:36 hmc* on I2C, though hmc5983 can do SPI Mar 20 21:39:53 next board will put hmc5983 on SPI instead of I2C Mar 20 21:40:11 (I'm waiting for my package of hmc5983 test boards now) Mar 20 21:40:37 LSM303D? mag/accel combo? Mar 20 21:40:41 yes Mar 20 21:40:55 is that thing better then the LSM303DLHC? Mar 20 21:41:09 i don't know, i've only used the 303D Mar 20 21:41:36 there are bugs on the DLHC version Mar 20 21:41:56 there are bugs in all sensors :-) we found a nasty bug in 303D Mar 20 21:42:06 cost us 3 months of delay getting Pixhawk to ship Mar 20 21:42:38 there was a secret handshake to tell it not to interpret SPI cmds to other sensors on the same bus as I2C Mar 20 21:42:43 undocumented Mar 20 21:43:25 thats why we have a MPU6k on the Pixhawk too - we were getting desperate and added a 2nd sensor to allow us to start shipping Mar 20 21:43:28 hahahaahah Mar 20 21:43:32 that sucks Mar 20 21:43:46 the MPU6K's are $$$$$$ :( Mar 20 21:44:05 turns out that was lucky, as MPU6k and LSM303D have different samping rates (1kHz and 800Hz), which is _great_ for aliasing detection Mar 20 21:44:23 the combination of the two has saved my nitro planes a few times :) Mar 20 21:44:43 what's the source of the aliasing? engine vibration? Mar 20 21:44:56 at each sample we weight the two sensors according to the consistency with other sensors Mar 20 21:45:21 yes, one of my nitro planes had a nasty harmonic at 1kHz at a very specific throttle setting Mar 20 21:45:36 flew perfectly, then suddenly got a pitch error of 90 degrees! Mar 20 21:45:41 the logs are quite amazing Mar 20 21:45:56 2nd accel was unaffected, so we now auto-switch accels Mar 20 21:46:30 Ohhh I see Mar 20 21:46:31 it is hard to know for sure, but I think the 1kHz vibration was caused by a XT60 connector vibrating against the case Mar 20 21:46:46 i deal with slower stuff... Mar 20 21:47:04 you need to put in a mechnical notch filter :D Mar 20 21:47:17 you can fly ok at 200Hz sampling, but 1kHz helps for good flight Mar 20 21:47:50 for my day job applications, sub 100Hz stuff Mar 20 21:47:58 we do have mechanical filtering too, but for my aircraft I try to maximise vibration so I can be sure I find the issues first Mar 20 21:48:26 so I fly petrol/nitro planes with the autopilot hard-mounted near the engine Mar 20 21:48:30 and don't balance props :) Mar 20 21:48:43 tridge: you're in the US, right? Mar 20 21:48:51 no, Australia Mar 20 21:48:59 ah...n/m Mar 20 21:49:18 was going to ask where can you fly nitro planes w/o irritating random people Mar 20 21:49:46 there are heaps of fields flying big nitro/petrol/turbine planes in the US Mar 20 21:49:51 I fly at MAAA fields here Mar 20 21:50:02 there are usually rules that basically amount to - you can't fly there Mar 20 21:50:12 electrics are a little more open Mar 20 21:50:32 back in a few mins, grabbing some breakfast Mar 20 21:52:11 munch, munch :) Mar 20 21:52:45 does the breakfast have the taste of nitro? Mar 20 21:54:39 http://uav.tridgell.net/BigStik/accel-aliasing.png Mar 20 21:54:52 no, I have learned to wash my hands :) Mar 20 21:55:08 the bit at 8:13:11 was testing the engine on the ground Mar 20 21:55:17 red is throttle, lower is higher throttle Mar 20 21:55:35 notice the two accels swparate, with 11m/s/s error in first accel Mar 20 21:55:49 so the plane thought it was in freefall Mar 20 21:56:08 DCM got a 90 degree pitch err, EKF thought the plane dropped 200m below ground level :) Mar 20 21:56:40 I wish I had the time RC planes Mar 20 21:57:11 its a lot of fun, but does take a lot of time (and expensive when you crash! I had a mid-air 2 wks ago) **** ENDING LOGGING AT Fri Mar 21 02:59:58 2014