2011-06-13 00:17 wpwrak: have you see the pictures of atben/atusb? http://en.qi-hardware.com/wiki/Ben_WPAN#First_Batch 2011-06-13 00:18 tuxbrain: yeah, great ! nice army of boards :) 2011-06-13 00:19 I have just finished to grind 135 atben and 120 atusb.... my thumb is aching like hel 2011-06-13 00:19 hell 2011-06-13 00:19 ;-)) 2011-06-13 00:19 tomorrow the testing ? 2011-06-13 00:19 tomorrow early morning I will flash all the atusb first 2011-06-13 00:19 and then round of testing 2011-06-13 00:20 perfect. note that the boot.hex i mentioned yesterday in irc wasn't correct (that file doesn't exist). so please get the version mentioned in my mail to the list. 2011-06-13 00:20 yes 2011-06-13 00:21 also,please pull the latest version of the scripts in ben-wpan/prod/. then there should be no more problems with the gpio test. unless i messed up something else ;-) 2011-06-13 00:21 :) , gostbuster!!!! 2011-06-13 00:22 yeah, sorry about the P_ON test. that's what i get for not reading the manual carefully enough :-( 2011-06-13 00:23 at least you're now ready for the turing test :) 2011-06-13 00:23 don't worry dude, that's is what test are for ,even to detect mistakes in the test :) 2011-06-13 00:23 or, in case the machines take over, the AI test ;-)) 2011-06-13 00:23 HmozHmmmmHhztaboluse 2011-06-13 00:24 (mistakes in the test) yeah,that's the hidden cost of not having a prototype run before "mass production" 2011-06-13 00:25 killer robot: "are you a carbon-based lifeform ?" 2011-06-13 00:25 tuxbrain: "HHHHoHxH.HxHxHxHh.ohzoHoHH" 2011-06-13 00:25 killer robot: "hail, brother !" (walks away, to kill your neighbours) 2011-06-13 00:25 common you and me know this is just a prototype run :) the mass prod will come when we pass the 10.000 units month :) 2011-06-13 00:26 hehe ;-) 2011-06-13 00:26 got any pre-orders yet ? 2011-06-13 00:27 killer robot: "are you a carbon-based lifeform ?" 02:25 2011-06-13 00:27 tuxbrain: "HHHHoHxH.HxHxHxHh.ohzoHoHHkiller robot: Motherfu..... GPIO error exit 1 2011-06-13 00:28 even better !now you can safe the world ;-)) 2011-06-13 00:29 Yes our fan of the Check republic (Jiri I love you) has order a two pair of each 2011-06-13 00:29 in fact, this one should be a "killer sequence": atrf-gpio HHHH1H0.HHHHHHHHZ.z1HHHHHH delay=1000 2011-06-13 00:30 (puts the transceiver into sleep mode. this means that it stops the clock. then the MCU is stopped too. power-cycle time ;-) 2011-06-13 00:30 but I have not anounce it any place yet, until at least I have a yield of 50 units of each I will not start annoy anyone but you 2011-06-13 00:30 (jiri) yeah !! :) 2011-06-13 00:30 hehe :) 2011-06-13 00:31 got atrf-xtal, you'll need your dual core. hope that works for your logistics. 2011-06-13 00:31 s/got/for/ 2011-06-13 00:32 I have come back home, I have  arrived an pair of hours ago (the time I have used to grind atusb) I will go to sleep now to have enough estamina to wake in a four hours or so to start flashing 2011-06-13 00:33 oh great. then you have everything you need at hand 2011-06-13 00:34 atusb were easy to grind than atben, but my (poor) thumb will hate me for a week, I think he is on strike of sms 2011-06-13 00:35 there must be a better non harming way to grind the boards .... 2011-06-13 00:36 yeah, atusb are comparably large and have a simple shape. atben has none of this ;-) 2011-06-13 00:37 I can't imagine me doing so for 500 units of each.... 2011-06-13 00:37 i think the proper process is to have a kind of "guillotine" 2011-06-13 00:37 ops my thumb has start running out of my hand on read the avobe sentence 2011-06-13 00:37 but maybe laser-cutting could be an option, too 2011-06-13 00:38 and a dremel? 2011-06-13 00:39 maybe too dangerouse due it can acidentally reshape the board , isn't it? 2011-06-13 00:39 uh sure, that'll work too 2011-06-13 00:39 you have a little bit of tolerance in case you cut into the board 2011-06-13 00:40 guillotine mabe ok with atusb, but totally no go for atben 2011-06-13 00:40 so laser cutting or dremel 2011-06-13 00:40 dunno. these guillotines may be shaped for the board they cut 2011-06-13 00:41 dremel should be quite okay for this sort of work, if you get the flexible axis, it's also easy to handle. 2011-06-13 00:42 but .. making a mould or so not sound too cheap,even laser cutting don't sound cheap either 2011-06-13 00:46 laser cutting should be cheap if you have the infrastructure. otherwise, you have to pay someone to convert things for their machine, s&h overhead, and so on. 2011-06-13 00:51 well dudes time to some sleep, enjoy the pics of the wireless revolution just a few steps away, you have asked for it, tuxbrain will bring it to you, small, beauty and above all this  tons of freedom, WPAN is here to stay, enjoy and happy hacking. Good night 2011-06-13 00:51 happy dreams ! ;-) 2011-06-13 00:51 nite 2011-06-13 00:51 xiangfu: hi 2011-06-13 00:55 xiangfu: the fix you did in rtems about the c heap or something, will now allow me to use the rtems fs as if were a ramdisk? 2011-06-13 00:55 i'll just create just one file 2011-06-13 00:55 so i dont need a full capable fs 2011-06-13 00:55 s/file/big file (90Mb) 2011-06-13 01:01 tuxbrain_away: nice documentation on your blog (arduino) 2011-06-13 01:11 kristianpaul:one thing I am not sure is do we really have a RAMDISK in flickernoise? 2011-06-13 01:11 kristianpaul: seems there is just IMFS, no ramdisk. 2011-06-13 01:12 wow. these efika seem nice. wannatry 2011-06-13 01:12 kristianpaul: but we do have >100MB in IMFS. 2011-06-13 01:18 xiangfu: (>100MB in IMFS) sounds great ! 2011-06-13 01:19 xiangfu: did you already tested? 2011-06-13 01:19 too lazy now to re-compile rtems again.. 2011-06-13 01:19 at least i have a good reason for :-) 2011-06-13 01:20 xiangfu: because as you may remenber last time i tried to save a file <4Mb in the IMFS rtems just crashed.. 2011-06-13 01:21 xiangfu: (real ramdisk) nope just the /ramdisk folder name ;) 2011-06-13 01:37 kristianpaul: just tried copy file by FTP, failed with "netout: Broken pipe" 2011-06-13 01:38 xiangfu: how big was the file? 2011-06-13 01:38 tested with 5MB and 40MB. all failed. 2011-06-13 01:38 now I am testing with memcards. 2011-06-13 01:38 but there is memcard write support already? 2011-06-13 01:39 but anyway, seems implement ramdisk is the way to go 2011-06-13 01:39 kristianpaul: "./4.6MB.AVI: No space left on device" 2011-06-13 01:40 kristianpaul: I am copy file from memcard to /ramdisk. 2011-06-13 01:40 i see 2011-06-13 01:41 after error, the target file size is 4325376 2011-06-13 01:41 4.125MB 2011-06-13 01:41 kristianpaul: (implement ramdisk is the way to go) yes. 2011-06-13 01:43 hi, how long the battery last in nanonote? 2011-06-13 01:48 antoni`: it may varie 2011-06-13 01:49 ie, i had listen to music upto 3 hours 2011-06-13 01:51 "I got a 10.8 hours of battery in a overnight idle run" <- http://en.qi-hardware.com/wiki/Battery_Monitoring 2011-06-13 01:57 Do you know this proyect, it is similar to nanonote but it has wifi integrated: 2011-06-13 01:57 http://www.uberspire.com/ 2011-06-13 01:58 and the estimated battery life is between 15-20 hours 2011-06-13 01:59 looks interesting 2011-06-13 01:59 yes, for now it is ot available to buy 2011-06-13 01:59 *not 2011-06-13 02:00 despite, some hw specs are different 2011-06-13 02:00 and surelly project goals 2011-06-13 02:00 but 2011-06-13 02:01 let me ask you antoni` , there are avaliable source code (in diferent forms) for this device you pointed? 2011-06-13 02:02 ah 2011-06-13 02:02 runs linux and is completely open source saids 2011-06-13 02:03 yes, it will be based in a custom Gnu/Linux distro 2011-06-13 02:04 antoni`: already pre-order yours? 2011-06-13 02:06 looks very focused on math, interesting 2011-06-13 02:09 kristianpaul: They are not accepting pre-orders for now 2011-06-13 02:13 antoni`: that's a good sign! :-) 2011-06-13 02:13 pre-order = fail, almost always 2011-06-13 02:13 I need to check out the site a bit more to understand what it is, thanks a lot for posting the link! 2011-06-13 02:17 I don't think it has much to do with copyleft hardware, but it's a cool little device. 2011-06-13 02:17 math and music are two areas where the Ben NanoNote is also quite nice already, and will get better. So I can definitely see their point. 2011-06-13 02:18 I hope they won't give up on manufacturing one day and end their life as an iPhone/iPad app :-) 2011-06-13 02:19 wolfspraul: what math packages are available in nanonote? 2011-06-13 02:20 a whole bunch, one sec I check if I can quickly find a list 2011-06-13 02:20 http://en.qi-hardware.com/wiki/Applications 2011-06-13 02:21 mathomatic 2011-06-13 02:21 GNU Octave 2011-06-13 02:21 gnuplot too 2011-06-13 02:21 lacks maxima 2011-06-13 02:21 yacas 2011-06-13 02:22 well, is a pretty decent math machine 2011-06-13 02:25 also it has Emacs Advanced Desk Calculator 2011-06-13 02:25 built in Gnu Emacs 2011-06-13 02:27 you mean the NanoNote? 2011-06-13 02:27 I don't even know, but yes, David did a lot of work to get emacs going well 2011-06-13 02:28 as and off-topic to this chat, we need an alarm clock feature that uses the build-n buzzer ! :-) 2011-06-13 02:28 s/feature/app 2011-06-13 02:30 definitely 2011-06-13 02:31 that's a big 'leap of faith' for me to trust a device to be my alarm clock :-) 2011-06-13 02:32 :D 2011-06-13 02:32 most of the time I sleep until I wake up, but if I do need an alarm it's typically serious, like an early morning flight or so 2011-06-13 02:32 right now I'm not sure whether I would trust my little Nano :-) 2011-06-13 02:32 maybe 2011-06-13 02:32 he he 2011-06-13 02:32 maybe not 2011-06-13 02:32 but it's a very worthy goal to go after 2011-06-13 02:34 wolfspraul: maybe it's time to get serious and stop selling unreliable crap then ;-)) 2011-06-13 02:36 nah I'm just very protective of the quality of my sleep 2011-06-13 02:37 you would probably want a rock-solid suspend too for this 2011-06-13 02:37 then wakeup from suspend on the alarm 2011-06-13 02:37 with wpan, we could make the ben send out a heartbeat. other stations could listen and raise an alarm in the ben stops sending. that ought the be bullet-proof ;-) 2011-06-13 02:37 last I heard there were still some issues being in suspend for hours, sometimes it wouldn't wake up anymore. Not sure whether that's fixed or not. 2011-06-13 02:37 s/the be/to be/ 2011-06-13 02:38 yeah, the mystery suspend failure. wonder what it is. seems that there's a work-around for it, though. 2011-06-13 04:01 hey, we had that on GTA02 as well 2011-06-13 04:02 bets on spurious IRQ that confuse things 2011-06-13 04:19 sigh. when will people ever learn how to do locking ... 2011-06-13 04:24 is cleaning up the at86rf230 kernel driver. it's quite competently done, but still ... 2011-06-13 04:57 locking? useless cruft! WFM without ;-P 2011-06-13 04:58 yeah. some under-do it some over-do it ... a spinlock plus a flag to protect a sequence that's already guaranteed by the general flow of execution ... 2011-06-13 04:59 hehe 2011-06-13 04:59 sppinlock the kernel, so you're on the safe side of fence :-> 2011-06-13 05:00 the  only problem with such things is that you can't help but wonder what demons the author did intend to banish. 2011-06-13 05:00 (spinlock = safe) well, sometimes ... ;-) 2011-06-13 05:00 :-x 2011-06-13 05:01 if ever devel would learn to handle IRQs correctly, they'd not need so many mutex and locks and semaphors and whatnot 2011-06-13 05:02 but for that you need to understand how your hw and CPU is handling IRQ 2011-06-13 05:03 still giggling about that "I changed it from edge to level and it caused kernel freezes" OWTTE 2011-06-13 05:04 the S3C24xx generic IRQ handler is abysmal 2011-06-13 05:04 a chimera of edge triggered and polling the GPIO - omfg :-O 2011-06-13 05:08 I really wonder what's so difficult to get this right 2011-06-13 05:10 level triggered is for "intelligent" and possibly IRQ-sharing peripherals, while you use edge (and only *one* of rising/falling edge) for dumb peripherals that mustn't share IRQ line and can't get told to reset their own IRQ output 2011-06-13 05:11 so for those dumb periph you don't have to wait until the IRQ goes down again, after you serviced the rising edge 2011-06-13 05:15 for smart periph you poll all those that share the IRQ line and tell the one (or two, or many) that admits to have triggered the IRQ that they may reset it now please. When you exit IRQ-handler you got either all periph serviced, or there's again a new one and you re-enter the irq-handler as soon as you leave it and enable level-triggered IRQ again on leaving 2011-06-13 05:16 there's definitely no use in triggering on both edges and then in handler poll the IRQ line to find out about the level 2011-06-13 05:17 nevertheless that's exactly what's done on GTA02 2011-06-13 05:17 The build has FAILED, \ 2011-06-13 05:31 and I bet it is like this to this very day 2011-06-13 05:33 qi-bot: say hi kyak 2011-06-13 05:34 oops 2011-06-13 05:36 heh :) 2011-06-13 05:45 ahh, just in case it wasn't clear: all this obviously doesn't need any locks as far as it goes, as the CPU will disable IRQ when they shoot (otherwise the IRQ handler never got beyond first opcode) and you usually got a proper IRQ hierarchy where it's clearly defined which higher-prio IRQ may interrupt the handler of lower-prio IRQs, so there's no issue with re-entrance or circle calls either 2011-06-13 05:49 depending on CPU architecture there's either a dedicated reti opcode that re-enables IRQ while same moment leaving the handler (pop pc), or you got clear advice how to use a sequence of opcodes to achive same purpose (as e.g the re-enabling of IRQ only takes effect 2 opcode fetches after execution) 2011-06-13 05:55 another theoretically possible architecture of CPU would set a "breakpoint" to the opcode addr following the one where the IRQ happened (i.E to the location which return addr pushed on stack points at), and would enable IRQ on execution of this addr&opcode. I'm not aware of such architecture though 2011-06-13 06:05 wpwrak: what's the mechanism that signals activatio from a handler to a worker thread, and how is it handled to get the reset of that semaphore(?) conflict-free from interference by the handler? do you block the IRQ-handler (or the IRQ itself) for that short moment? 2011-06-13 06:07 DocScrutinizer: within the irq handler, the infrastructure protects you. then you can disable the interrupt, schedule the worker, then re-enable when done in the worker. 2011-06-13 06:08 what? you re-enable the IRQ-handler in the worker-thread? 2011-06-13 06:08 yup. clean and easy 2011-06-13 06:08 ouch 2011-06-13 06:08 sloooooow 2011-06-13 06:09 if that's not fast enough, you have to process at least part of it in the irq handler. maybe not have a worker at all. 2011-06-13 06:10 nah, you have a disabled IRQ-handler for arbitrary eternities 2011-06-13 06:10 you also have tasklets as an intermediate solution. or bottom-half handlers, if you want. 2011-06-13 06:10 (but you need a pretty good reason for the latter :) 2011-06-13 06:11 NFC about that, always thought bottom-half == worker-thread 2011-06-13 06:12 for the semaphore thing: you probably get a clean problem-free interface with a fifo 2011-06-13 06:12 as the IRQ handler doesn't need to know about worker thread usually 2011-06-13 06:13 so if you get a ringbuffer (e.g. of timestamps) then you IRQ-handler can run ahead of worker-thead as many events as size of that ringbuffer 2011-06-13 06:14 BH are similar to tasklets. neither can sleep. workers can. 2011-06-13 06:14 aaah 2011-06-13 06:15 err, what semaphore thing ? i did't understand the issue 2011-06-13 06:15 that's what's my concern: your handler is deactivated to service next IRQ until worker is eventually awaking again and completing its thing 2011-06-13 06:16 (issue) probably there's been none first instance 2011-06-13 06:17 if there's anything the handler needs to know about from timeshare-land, then it probably better done that task itself instead of waiting fro worker to accomplish it 2011-06-13 06:18 the handler is disabled but you already know that you have to do some work. if you didn't do everything, then you get another interrupt when re-enabling, if level-triggered. if edge-triggered, you re-enable before checking the status. if you can't check the status, well ... to be honest, burn that hardware and its designer with it ;-) 2011-06-13 06:19 what is "check status"? 2011-06-13 06:20 if an interrupt handler/BH/tasklet needs to call anything that can sleep, it is in trouble. that's why we have workqueues. if the standard workqueue is too slow, you're free to create your own and tweak with scheduler settings. and yes, you can give it real-time priority. 2011-06-13 06:20 usually the "interrupts pending" register 2011-06-13 06:20 sure 2011-06-13 06:20 or whatever you have in your hardware 2011-06-13 06:21 hmm, you typically don't check that at all 2011-06-13 06:21 you also have atomic operations, which can help to avoid spinlocks 2011-06-13 06:21 yes 2011-06-13 06:21 that's my point 2011-06-13 06:21 most drivers to, because many devices have multiple internal interrupt sources 2011-06-13 06:22 RETI is such an atomic operation 2011-06-13 06:22 that's what I call servicing the smart peripheral 2011-06-13 06:22 i means atomic increment, decrement, increment if non-zero, etc. 2011-06-13 06:23 err. decrement if non-zero. don't think we have increment if NZ :) 2011-06-13 06:23 if multiple such smart periphs share an IRQ line, then you need to use level IRQ trigger, and service all periph that share this IRQ hw line 2011-06-13 06:23 hehe 2011-06-13 06:23 some of them also return a status. so you can have an atomic if (non-zero) decrement; else do something; 2011-06-13 06:24 that's even better than my suggested ringbuffer 2011-06-13 06:24 and basically exactly my "semaphore(?)" 2011-06-13 06:24 yes, if you have multiple peripherals sharing a single line, then too. but also many peripherals share the device's single external interrupt among many internal sources. 2011-06-13 06:25 sure, but the scheme is unaffected the same nevertheless 2011-06-13 06:26 and don't forget SMP. you don't only have preemption but real concurrency to worry about. for SMP, you get a bunch of additional concepts. e.g., per-cpu variables, etc. 2011-06-13 06:26 on a logical interrupt you need to service (check) all the possible sources 2011-06-13 06:26 correct 2011-06-13 06:26 you do this in the IRQ-handler 2011-06-13 06:26 at least the ones that can contribute to the interrupt. if you mask them, you may not need to check them :) 2011-06-13 06:27 that's optional 2011-06-13 06:27 for each detected periph asking for service the handler schedules some worker or similr 2011-06-13 06:27 that's why I said "possible" 2011-06-13 06:27 usually too complex. just gets you races. 2011-06-13 06:27 possible like in "enabled" 2011-06-13 06:28 do one thread and handle one after the other. try to do everything in that thread. voila - no sharing. 2011-06-13 06:29 aaah sure, you simply exit handler after first periph serviced, if there's another you'll catch it on re-IRQ 2011-06-13 06:29 you may even be faster than with a horde of concurrently scheduled threads fighting for shared resources :) 2011-06-13 06:29 you're also allowed to use a loop ;-) 2011-06-13 06:29 if you feel really bad about looping, yield() :) 2011-06-13 06:30 you're talking bout the workers 2011-06-13 06:30 yes 2011-06-13 06:30 yeah, that's baring topic right now for me 2011-06-13 06:30 boring 2011-06-13 06:30 ;-) 2011-06-13 06:30 yeah. it's all pretty basic :) 2011-06-13 06:30 I'm sparring the handlers ATM 2011-06-13 06:31 I don't get the weird stuff I seen for gta02 quite some time back 2011-06-13 06:32 I could imagine it all works on mere incidence there, just because timings are lucky etc 2011-06-13 06:33 that's why I was about to sort my own thoughts first 2011-06-13 06:35 and my own knowledge always been you git to re-enable the IRQ on leaving the IRQ handler 2011-06-13 06:35 got* 2011-06-13 06:36 as any worker might get delayed, stopped or even canceled for arbitrary reasons 2011-06-13 06:36 grmbl. ^W does not delete a word ... 2011-06-13 06:37 only in shell 2011-06-13 06:37 ;-) 2011-06-13 06:37 enable on return is what the hw usually does 2011-06-13 06:37 even only in some shells, with some particular configs 2011-06-13 06:37 what you can do is disable_irq_nosync in the irq handler, then enable_irq when you've handled it 2011-06-13 06:37 RETI, exactly 2011-06-13 06:37 if something kills your worker, you're in trouble anyway :) 2011-06-13 06:38 not always 2011-06-13 06:38 there might be cases 2011-06-13 06:39 well, if you insist of firing downward, move your feet away ;-) 2011-06-13 06:39 if you don't mess with re-enabling the IRQ in worker, you can restart it anyway 2011-06-13 06:39 the handler won't mind 2011-06-13 06:39 this disable/enable split is a common and simple arrangement. if you need something more complex, you have to figure out a logic that works for you. 2011-06-13 06:40 the logic is RETI, as you said a few lines up 2011-06-13 06:40 hint: whenever i see a complex synchronization/locking/etc. arrangement, there's usually a more simple and considerably more correct one that can replace it ;-) 2011-06-13 06:41 and it's not more complex but rather more clean and simple 2011-06-13 06:41 enable_irq != reti 2011-06-13 06:41 enable_irq enables a specific interrupt. not to be confused with disabling interrupts globally or on your core. 2011-06-13 06:41 well, the basic setup&enabling of the IRQ at large is sth usually only done once 2011-06-13 06:42 setup yes. enabling/disabling not necessarily. see above :) 2011-06-13 06:42 disabling IRQ-handling on a global scale is sth you better not even think about 2011-06-13 06:44 aah well, you mean I service the periph from worker. Yes then you probably might want to disable that particular IRQ on a sw level until your worker serviced the periph and git the hw line reset 2011-06-13 06:45 yup 2011-06-13 06:45 ok, now we're on same page again 2011-06-13 06:45 :-) 2011-06-13 06:47 all only applicable for level triggering though 2011-06-13 06:48 for edge you run into endless amount of trouble on several points of this scheme 2011-06-13 06:49 why ? 2011-06-13 06:49 that's another argument why I got goose pimples when reading the gta02 IRQ src 2011-06-13 06:49 (why?) because you can miss IRQs 2011-06-13 06:49 as long as you can find out what needs servicing, you can lose edges. you just need to re-enable _before_ checking what needs serviving 2011-06-13 06:50 you can miss handler calls on "expired" IRQs 2011-06-13 06:50 worst-case, you get an edge, schedule the worker again while the worker is still running and processing the event that was just signaled. usually not a problem. 2011-06-13 06:52 you only run into a problem if handling the event itself has a deadline you're missing. but that doesn't depend on edge vs. level. and in such cases, you probably don't want to use a worker. 2011-06-13 06:52 nope, worst case you service the periph, it triggers again, and only then you re-enable the IRQ, which will leave your IRQ unnoticed (as it's edge) and thus periph unserviced and you never again get a new IRQ 2011-06-13 06:52 again, your general design must be suitable for handling the problem. edge vs. level and all this is secondary. 2011-06-13 06:53 read what i wrote above: you re-enable before you check what needs handling 2011-06-13 06:54 but... wasn't there a reason we didn't want to do that and moved the enabling of IRQ to worker for this reason 2011-06-13 06:55 when you said "IRQ enabled in worker" then I got "at end of worker, after servicing periph" 2011-06-13 06:56 now you say you enable it prior to servicing periph 2011-06-13 06:56 NB servicing periph and resetting the IRQ in periph is usually atomic 2011-06-13 06:56 maybe not usually but often 2011-06-13 06:57 at end of worker for level-triggered. before checking what's pending for edge-triggered. 2011-06-13 06:58 I.E. often readin a register gives indication if IRQ been set and also resets it same time 2011-06-13 06:58 if you really want to, you can also enable before checking for level. it's just less efficient. 2011-06-13 06:58 yes, that makes sense, as for edge triggered you got no way to reset the periph 2011-06-13 06:59 if you enable before servicing the periph for level, you'll get the above quoted "kernel freeze" 2011-06-13 06:59 aka endless loop 2011-06-13 06:59 as usual, that depends :) besides, nowadays, i don't seem to see a lot of edge-triggered anyway 2011-06-13 07:00 edge is out since 1984 2011-06-13 07:00 only gta02 using it 2011-06-13 07:01 (enable before servicing) no, you would call the handler, the handler would schedule you again, but you wouldn't enter the handler yet another time, because you'll have serviced the interrupt eventually 2011-06-13 07:01 you're using edge *maybe* for dumb IRQ sources like clocks etc, that can not get reset. And even then mainly for efficiency/performance reasons 2011-06-13 07:02 (ena beore) yeah that's where devels stert to plaster their code with spinlocks/mutex/whatnot ;-D 2011-06-13 07:03 naw, they do this for many other wrong reasons already ;-) 2011-06-13 07:03 thanks for the nice chat, have to take a nap 2011-06-13 07:04 you just have to be careful that you enable as many times as you disable 2011-06-13 07:04 uninterrupted dreams ! :) 2011-06-13 07:04 :-D 2011-06-13 07:29 hmmm 2011-06-13 07:30 btw you can not share IRQ line for edge, for obvious reasons 2011-06-13 07:30 so there are no multiple sources for edge that would need time consuming talk to periph 2011-06-13 07:31 so handler can do the "check" - no need to do it in worker 2011-06-13 07:31 also you obvviously don't need and can not disabled IRQ for edge. At least in a sense we used that term above and for the purpose assumed 2011-06-13 07:32 so the whole discussion is moot when it comes to using edge with that complex scheme 2011-06-13 07:33 go for level and all ok, re-enable IRQ at end of perip-servicing demuxing worker 2011-06-13 07:33 use edge and you're doomed 2011-06-13 07:34 unless it's a 1000Hz clock generator that needs a handler to count up a longint and thus has a execution time <<< the IRQ period 2011-06-13 07:34 those typically don't need any workers at all 2011-06-13 07:35 also don't need IRQ disabling in sw then, RETI wil do to avoid reentrance when clock is faster than CPU 2011-06-13 07:36 back to bed 2011-06-13 10:31 Hi all ! 2011-06-13 10:43 hello everyone :) 2011-06-13 10:44 is it possible to install Milkymist's Flickernoise program on a usual Linux computer? 2011-06-13 10:44 With re-building of course :P 2011-06-13 10:47 vladkorotnev: i think yes, but you can ask in #milkymist too 2011-06-13 10:48 vladkorotnev: rtems is ported to i386, so thats no the problem 2011-06-13 10:48 kristianpaul: I asked @Milkymist on twitter and got a reply: @vladkorotnev yes, JFDI. 2011-06-13 10:48 What is JFDI? 2011-06-13 10:48 and btw, will it work on Debian without X? 2011-06-13 10:49 vladkorotnev: http://www.urbandictionary.com/define.php?term=JFDI 2011-06-13 10:49 but hey 2011-06-13 10:49 kristianpaul: lol, thanks, I thought it was some kind of software :) 2011-06-13 10:50 why you need all this trouble, if milkdrop can be run as an app inside your os 2011-06-13 10:50 he, mee too 2011-06-13 10:50 kristianpaul: milk drop is windows only AFAIK 2011-06-13 10:51 and I have two computers that are powerful enough for VJing 2011-06-13 10:51 one is a Acer half-laptop with Debian+Win7+MacOSX 2011-06-13 10:51 second is a Macbook pro 2011-06-13 10:51 but I hate Win7 2011-06-13 10:53 projectm.sourceforge.net ? 2011-06-13 10:55 kristianpaul: already know it and idk why, but i don't like it 2011-06-13 10:55 ah 2011-06-13 10:57 um, I found Flickernoise build instructions, but will they build for x86 or FPGA or such? 2011-06-13 10:59 for lm32 2011-06-13 10:59 lattice mico 32 is the cpu implemnted on the fpga plus other cores 2011-06-13 11:00 (will they build) i dont bet 2011-06-13 11:00 as i relly of custom cores for hw accelatarion not present in the rtmes for x86 2011-06-13 11:00 kristianpaul: then I need to find a way to build it on x86 for x86... 2011-06-13 11:00 s/i/they 2011-06-13 11:01 yes vladkorotnev 2011-06-13 11:03 um, if I have a pc that's powerful enough, will QEMU (with KVM) be sufficient? http://www.milkymist.org/wiki/index.php?title=Using_QEMU ;) 2011-06-13 11:04 thats another way indeed 2011-06-13 11:06 kristianpaul: this QEMU has Cocoa so it may be able to run on my Mac ;P 2011-06-13 11:11 ok, i have to reboot to my devenv os, see ya later guys 2011-06-13 11:15 hi qiots 2011-06-13 11:15 and qiotines ;) 2011-06-13 11:15 (not to compare with guillotines!) 2011-06-13 11:25 [commit] David Kühling: new package: ASE: allegro sprite editor, a generic drawing and animation program http://qi-hw.com/p/openwrt-packages/6829840 2011-06-13 11:26 dvdk: hi! have you noticed some pitfalls with liballegro in backfire and plplot in trunk? 2011-06-13 11:26 i.e. compilation issues 2011-06-13 11:27 kyak: no ? 2011-06-13 11:27 http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-06112011-0558/ 2011-06-13 11:27 kyak: wrt backfire: didn't touch this at all, it should be broken i guess.  too lazy backporting my changes 2011-06-13 11:27 http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.trunk-full_system-06122011-0217/ 2011-06-13 11:27 here and here :) 2011-06-13 11:27 plplot in trunk: fixd that yesterday!? 2011-06-13 11:28 dvdk: you shouldn't have commited liballegro to backfire then? 2011-06-13 11:28 kyka: it's just an ancient version in backfire.  don't know who put that in config.full_system.  not me (?) 2011-06-13 11:28 not config.full_system... but openwrt-packages/master 2011-06-13 11:29 regarding plplot, seems it isn't fixed 2011-06-13 11:29 ? 2011-06-13 11:29 hello everyone, I'm back 2011-06-13 11:30 got this problem when trying to run flickernoise in qemu: http://pastie.org/2060406 2011-06-13 11:30 kyak: first things first :) 2011-06-13 11:31 kyak: ok, so why is allegro built in trunk?  when it's not in config.full_system? 2011-06-13 11:31 s/trunk/master 2011-06-13 11:31 i.e. backfire 2011-06-13 11:34 if there are no future releases of nanonote sw for backfire, let's just kick out allegro from backfire, if it makes problem?? 2011-06-13 11:35 dvdk: liballegro builds in backfire (i.e. master) because there is CONFIG_ALL 2011-06-13 11:36 kyak: is there any need to continue building for backfire at all? 2011-06-13 11:36 to avoid this (because backfire not tested/not maintained anymore) you should commit to trunk only 2011-06-13 11:36 not to master 2011-06-13 11:36 kyak: i _am_ only committing to trunk anyway.  just bits of allegro are in backfire, because i started that port, a few days before the trunk transition 2011-06-13 11:36 as xiangfu said, that was the last backfire image, so i guess no 2011-06-13 11:37 ok 2011-06-13 11:37 wrt plplot, will have to look at the build log.  it builds fine here. 2011-06-13 11:38 kyak: you committed some 'keyboard mouse' stuff a while back.   2011-06-13 11:38 how much work is required to make this work? 2011-06-13 11:39 http://projects.qi-hardware.com/index.php/p/openwrt-packages/source/changes/master/ 2011-06-13 11:39 should we remove some commits from top of master? 2011-06-13 11:39 to keep it compilable when it is renamed to backfire? 2011-06-13 11:39 dvdk: 'opkg install keymouse', this much :) 2011-06-13 11:41 huh? 2011-06-13 11:41 that's a daemon?  which keys does it use? 2011-06-13 11:42 http://en.qi-hardware.com/wiki/Virtual_mouse 2011-06-13 11:42 it's pretty much outdated though 2011-06-13 11:43 /etc/init.d/keymouse start should be enough 2011-06-13 11:43 (it's not autostarted because most of the times i find it annoyying) 2011-06-13 11:43 kyak: not bad 2011-06-13 11:43 it does work for ASE (drawing program, just committed), HOWEVER: 2011-06-13 11:44 it does not remove the fn+keys from the keys that ASE sees, so i have duplicate key actions: mouse moves, still direction keys are pressed, so menu focus moves around.  hmm 2011-06-13 11:45 yes 2011-06-13 11:45 exactly the thing that annoys me 2011-06-13 11:46 looks like it always presses the button? 2011-06-13 11:46 uups, segmentation failt (ase). 2011-06-13 11:46 keyboard/mouse actions intersect 2011-06-13 11:46 hmm, then maybe just hack ase to implement its own kbd mouse  suppor-? 2011-06-13 11:46 always presses the button? what do you mean? 2011-06-13 11:47 how do i click? 2011-06-13 11:47 red+arrow -> move 2011-06-13 11:47 fn+voldown -> left click 2011-06-13 11:47 fn+volup -> right click 2011-06-13 11:47 how does red change the keycode of arrow keys, i.e. what keys does it generate? 2011-06-13 11:47 pgup/down? 2011-06-13 11:48 as far as i know, it doesn't change the code of arrow keys, it's a modifier 2011-06-13 11:49 you can see a keycode with "showkeys" 2011-06-13 11:49 maybe just make ase ignore these 2011-06-13 11:50 it does not seem to modify the arrow keys at all 2011-06-13 11:50 if ase has it's own bindings, maybe they can be altered 2011-06-13 11:51 kyak: but direction keys are so generic, we'd have to manually filter for !red 2011-06-13 11:51 or just ignore any key events if red? 2011-06-13 11:56 dvdk: i'm going to try it now :) and alex4, too 2011-06-13 11:58 could anyone please send me Flickernoise kernel? 2011-06-13 12:05 dvdk: any chance to disable sound in alex4? 2011-06-13 12:07 ase works unbelievably fast 2011-06-13 12:07 menus are much fast than in qt/gtk 2011-06-13 12:08 uh, segfault :) 2011-06-13 12:09 kyak: happy debugging :) 2011-06-13 12:09 kyak: yeah, using a game library as drawing backend definitely speeds things up 2011-06-13 12:11 kyak: what's the problem with sound?  think we can change the volume in alex4.cfg 2011-06-13 12:11 everything is find with the sound, i just want to disable it :) 2011-06-13 12:12 look for the config file 2011-06-13 12:12 may also try allegro-setup to change volume globally for allegro games, not sure though whether alex4 honours /etc/allegrorc 2011-06-13 12:13 usually plugs in headphones to shut up the sound 2011-06-13 12:25 dvdk: can't find alex4.conf 2011-06-13 12:29 dvdk: heh, it's a little bit problematic to move cursor while pressed with keymouse :) 2011-06-13 12:31 away 2011-06-13 13:17 question about debugging: what's the right .config flag to set to compile programs with debug information, but not keep that debug information on the target (i.e. for remote debugging) 2011-06-13 13:17 ? 2011-06-13 13:18 config_debug? 2011-06-13 13:19 I usually do that on a case-by-case basis 2011-06-13 13:20 adding  TARGET_CFLAGS += -ggdb3 2011-06-13 13:20 to the corresponding makefile 2011-06-13 13:20 xMff: set config_debug, now recompiling a single package, i now have -g3 set in cflags by default.  maybe that's going to do it. 2011-06-13 13:21 binaries are stripped shortly before they're put into the .ipk 2011-06-13 13:21 so they should be unstripped in both build_dir and staging_dir/target-*/ 2011-06-13 13:22 hmm, i also set config_gdb, however looks like that change isn't picked up (i.e. no gdb executable in the toolchain dir) 2011-06-13 13:22 do i have to to toolchain/{clean,compile}? 2011-06-13 13:22 ah, maybe make world is going to help 2011-06-13 13:22 toolchain/gdb/{compile,install} V=99 2011-06-13 13:34 wpwrak: are your there? 2011-06-13 13:35 all atusb flashed, just two present problems, ones was unable to flash, the other even reflashing several times fails on enumeration 2011-06-13 13:36 pretty good ! 2011-06-13 13:37 I was starting test with a fresh prod and tools installed but when generate the profiles the stucked black window issue starts again :( 2011-06-13 13:37 make spectrum 2011-06-13 13:37 hmm. that would be "no interrupt" 2011-06-13 13:39 it not shows nothing but a ben.profile has been created 2011-06-13 13:40 the window doesn't show nothing, the ben.profiles is filled up to 26 lines 2011-06-13 13:40 has the spectrum worked before ? 2011-06-13 13:41 no sorry my fauls was filled from channel 11 to 26 2011-06-13 13:41 grmbl. my last remaining prototype is acting up :-( just let off some smoke. that can't be good ... 2011-06-13 13:41 ouch 2011-06-13 13:43 cool tuxbrain is in the midst of the beauty of manufacturing 2011-06-13 13:43 is it worth to track down that problem or not? 2011-06-13 13:43 :-) 2011-06-13 13:44 that's the hardest decision to make, because behind something that looks small now, something much larger may lurk later 2011-06-13 13:44 on the other hand you need huge volumes to justify digging into any last weird thing that you see when you make something in the hundreds or more. it may be more economical to throw those beasts away and forget that you ever saw them :-) 2011-06-13 13:45 wpwrak: yes spectrum has worked on previous version of the tools/prod, but no I have redone all from scratch to be sure I'm using the lastest one 2011-06-13 13:45 tuxbrain: good. does this happen with multiple boards ? 2011-06-13 13:46 wolfspraul: for now just two of 120 :) I will go forward, I will send the faulty ones to werner to take a look 2011-06-13 13:46 yes but that is exactly my point 2011-06-13 13:46 you will have this all the time in manufacturing 2011-06-13 13:47 with every 200 nanos I make, I have one case that is just so off-chart it's mind boggling 2011-06-13 13:47 in most cases right now I decide to just discard them 2011-06-13 13:47 need to be very practical in manufacturing 2011-06-13 13:48 I'm sure there are some very interesting discoveries to make with those units, but who cares... the world keeps turning. 2011-06-13 13:48 the root cause will never be found, so what 2011-06-13 13:48 this work ok: 2011-06-13 13:48 as long as the other 199 work, seriously nobody will care much. that's just how it is, and it's only natural. perfect is the enemy of good. 2011-06-13 13:48 atrf-path -g net:ben usb 10 | \ 2011-06-13 13:48                                             ../tools/atrf-path/genpathprof +5 +5 >usb.profile 2011-06-13 13:49 but this not 2011-06-13 13:49 atrf-path -g usb net:ben 10 | \ 2011-06-13 13:49   ../tools/atrf-path/genpathprof +5 +5 >ben.profile 2011-06-13 13:52 hmm. that atusb board passed the gpio test, right ? 2011-06-13 13:52 wpwrak: yes 2011-06-13 13:53 and did you try another atusb as well, to see if it's just an unlucky board ? 2011-06-13 13:53 (meanwhile, i'm trying to salvage my last prototype. seems that i shorted VBUS to GND. but i don't quite see how.) 2011-06-13 13:54 it fails on show the spectrum on make ben , and make spectrum in the atben part, sure is the atusb that is annoying 2011-06-13 13:54 _ 2011-06-13 13:54 ? 2011-06-13 13:54 (that board was last reworked for current measurement, which didn't go very well (the rework, not the measurements). so it's been quite fragile since.) 2011-06-13 13:55 yes, i think it's atusb. the "ben" part has an atusb sender an an atben receiver. the receiver seems to be okay, the sender not. it's the sender that has the ability to hang (while waiting for an interrupt) 2011-06-13 13:56 maybe power-cycle the board before trying the "make spectrum". could be that the gpio test leaves some confusion behind. it shouldn't, but ... 2011-06-13 13:58 tested 5 more atusb all hangs make spectrum 2011-06-13 13:59 all pass the other tests 2011-06-13 14:00 if you comment out the spectrum test. do they pass ? (i.e., do they also pass receive/transmit ?) 2011-06-13 14:00 ok gonna try 2011-06-13 14:02 nop receive fail :( 2011-06-13 14:03 hep this one pass :) 2011-06-13 14:04 I gonna try if it was the powercicling thing 2011-06-13 14:05 no even pasing the send/recive test the spectrum fails the same. 2011-06-13 14:06 at least it's consistent :) 2011-06-13 14:06 what if you comment-out the gpio test and power-cycle ? 2011-06-13 14:07 I have run make spectrum , with the board just replugged, and it fails too 2011-06-13 14:08 but pass the send/recieve test 2011-06-13 14:10 that's after disabling the gpio test ? 2011-06-13 14:11 no with gpio test enabled 2011-06-13 14:12 I will disable the gpio test but "make spectrum" dont mess with gpios isn't? 2011-06-13 14:12 make spectum messes with darker things than gpios :-) 2011-06-13 14:13 but if receive/transmit is okay with the gpio test, that's encouraging 2011-06-13 14:14 my guess is something wrong with the make spectrum soft not with the hard (more than a guess is a hope :P) 2011-06-13 14:14 ok what exactly do you want I do 2011-06-13 14:14 yeah, both tests use more or less the same pins 2011-06-13 14:14 hmm, aseprite crashes with SIGUSR1 (according to gdb), and i cannot even backtrace once that signal was received.  what can cause such a result? 2011-06-13 14:15 first, let me try to salvage my board. then i can see if i can reproduce the problem here. 2011-06-13 14:17 ok sit down a wait, I can do that :) but please hurry , I want to sleep at least two hours this night , I have some mambo jambo with financial people tomorrow and what to be as less asleep as I can 2011-06-13 14:18 what-> want 2011-06-13 14:23 board is up again ;-) 2011-06-13 14:26 now it has a cute little loop crossing the area of destruction where a large capacitor and some traces used to be. the traces overheated and separated from the board (probably due to too much rework) and the capacitor may have produced short and smoke (not quite sure how. maybe there was a short underneath it and it just got cooked) 2011-06-13 14:27 ouch .... bye bye atusb prototipe RIP :( 2011-06-13 14:28 naw, it still kinda works. and it doesn't hang ! :) 2011-06-13 14:32 gdb `which atrf-path` 2011-06-13 14:32 run usb net:ben 10 2011-06-13 14:33 this will either spit out a series of numbers or it will hang. if it hands, interrupt with ^C and then "where" 2011-06-13 14:33 w 2011-06-13 14:34 mstevens: Ambiguous command "w": watch, wh, whatis, where, while, while-stepping, winheight, ws. 2011-06-13 14:34 hey! what's going on? this isn't my zsh window! 2011-06-13 14:35 #0  0x00007ffff7483197 in ioctl () from /lib/libc.so.6 2011-06-13 14:35 #1  0x00007ffff7bd75b0 in usb_control_msg () from /lib/libusb-0.1.so.4 2011-06-13 14:35 #2  0x000000000040689a in atusb_interrupt (handle=0x612b40) at atusb.c:300 2011-06-13 14:35 #3  0x0000000000404205 in atrf_interrupt (dsc=0x6128d0) at atrf.c:323 2011-06-13 14:35 #4  0x00000000004051c1 in wait_for_interrupt (dsc=0x6128d0, wait_for=1 '\001', ignore=1 '\001', sleep_us=10, timeout=0) 2011-06-13 14:35     at misctxrx.c:47 2011-06-13 14:35 #5  0x00000000004059ae in start_test_mode_231 (dsc=0x6128d0) at cwtest.c:95 2011-06-13 14:35 #6  0x0000000000405a7e in cw_test_resume (dsc=0x6128d0) at cwtest.c:125 2011-06-13 14:35 #7  0x0000000000402112 in sample (sweep=0x7fffffffe410, cont_tx=128, res=0x7fffffffe110, first=0) at atrf-path.c:89 2011-06-13 14:35 #8  0x00000000004022a6 in do_half_sweep (sweep=0x7fffffffe410, cont_tx=128, res=0x7fffffffe110) at atrf-path.c:128 2011-06-13 14:35 #9  0x000000000040234e in do_sweep (sweep=0x7fffffffe410, res=0x7fffffffe0e0) at atrf-path.c:145 2011-06-13 14:35 #10 0x00000000004024d2 in do_sweeps (sweep=0x7fffffffe410, sweeps=1) at atrf-path.c:190 2011-06-13 14:35 #11 0x0000000000402dcd in main (argc=4, argv=0x7fffffffe678) at atrf-path.c:407 2011-06-13 14:35 opps large than expected I will use pastebin next time 2011-06-13 14:36 hmm .. the PLL lock ... 2011-06-13 14:37 tuxbrain: ooh, you've got new stuff 2011-06-13 14:37 this is in fact a questionable part of the tool, because one can imagine that the PLL is already locked, in which case there would be no interrupt 2011-06-13 14:38 ths only odd thing is that it seems to work fine for me but not for you. but well, that's murphy's perogative :) 2011-06-13 14:39 mstevens: yep and more to come :) 2011-06-13 14:39 tuxbrain: what are those efika things like? 2011-06-13 14:41 tuxbrain: as a temporary work-around, you could change tools/lib/cwtest.c line 93 from  wait_for_interrupt(dsc, IRQ_PLL_LOCK, IRQ_PLL_LOCK, 10, 0); 2011-06-13 14:41 to ... 10, 20); 2011-06-13 14:42 then  cd tools; make clean install 2011-06-13 14:42 meanwhile, i'm thinking of a way to do this properly 2011-06-13 14:44 mstevens: I have some things to improve but the overall result is quite good, due the durantion of batt, and it's weight I have replaced my toshiba by one efika smartbook, I can navigate, use 3G dongle, read docs on the go (screen is quite readable on bright sun) and use some emergency gimp/openoffice/inkscape, so for me feets my need quite well, also the genesi team is very compromised with foss and his community is quite active... and are quite aff 2011-06-13 14:44 ordable , so the only thing they fail is that is not copyleft hardware :) 2011-06-13 14:45 wpwrak: so I can change this line and take the result of the tests as valids? 2011-06-13 14:45 tuxbrain: what's the OS support like? Can I use debian? 2011-06-13 14:45 and for this i shall withdraw to my hall of contemplation, and purge myself ... in other words, afk for a little while 2011-06-13 14:46 mstevens: I know a guy that was actively porting debian to it, I don't know the status, I'm confortable with the ubuntu it has by default. 2011-06-13 14:47 there seem to be lots of interesting little arm devices at the moment 2011-06-13 14:49 tuxbrain: probably. but let's first see if this solves the problem 2011-06-13 14:49 it doesn't hang now :) 2011-06-13 14:55 wpwrak: are you still there? 2011-06-13 14:55 running make spectrum 2011-06-13 14:55 and after it make ben 2011-06-13 14:56 still giving me the red arrow and I cannot give the test as passed, also there are not red lines to define the max min 2011-06-13 14:58 ok solved I forget to press D in spectrum now is ok :) 2011-06-13 14:58 time to test a lot of boards 2011-06-13 15:12 back 2011-06-13 15:12 hehe ;) 2011-06-13 15:13 21 test done (100% pased :) ) 2011-06-13 15:13 whee ! 2011-06-13 15:14 wolfspraul: what was our final score with gta02 MP ? 2011-06-13 15:15 bah, we defied basic math, impossible to tell 2011-06-13 15:16 archimedes would have cried hard 2011-06-13 15:16 I'm sure we passed at least 100%, if not more... 2011-06-13 15:19 ;-))) 2011-06-13 15:21 i still remember your return from the fab, with all the glorious plans for remote process monitoring ;-) 2011-06-13 15:21 thinking of it, evil me could sneak a little spy feature into tuxbrain's test script. then i'd have all the results ;-) 2011-06-13 15:23 wpwrak: do also an robotic arm and let me sleep motherf&%(r+ 2011-06-13 15:23 (((-:C 2011-06-13 15:24 i think you'll get that robotic arm when the natural one you currently use wears out. which should be around the time when you make the next batch ;-) 2011-06-13 15:25 a robotic left arm and a dremel in my right thumb , oh yeah all controlled by an interface made of arduino and a fpga with milkymist soc embedded in my brain , oh yeah 2011-06-13 15:26 btw, i contemplated that PLL lock situation for a bit. i haven't found the path that would make you end up with the PLL locked before it's supposed to (in which case you wouldn't get an interrupt), but there are a few candidates for this. 2011-06-13 15:27 in any case, the best we can do is just assume the PLL does indeed lock. the change i suggested does give it plenty of time - much more than it needs even under worst-case conditions. 2011-06-13 15:28 plus, there is no plausible failure mode where the PLL would never lock yet still pass all the tests. so i think it's safe to not insist on getting that interrupt. 2011-06-13 15:29 all the avobe means that I have to redo the test I have already done or not? (those enginers allways with his eternal xitxat about bits and .. things.... and so...) 2011-06-13 15:29 maybe i can tighten the test when i have the production boards. my sickish prototype with its broken reset line isn't the most reliable reference for all this 2011-06-13 15:30 nope. the tests you did after changing the , 0); to , 20); should be valid 2011-06-13 15:36 wpwrak: music to my ears :) 2011-06-13 15:39 [commit] Werner Almesberger: lib/cwtest.c (start_test_mode_231): don't insist on IRQ_PLL_LOCK http://qi-hw.com/p/ben-wpan/8c00833 2011-06-13 15:39 now it's official :) 2011-06-13 15:40 tuxbrain: ah, can you please mail/pastebin me the profiles you generated ? 2011-06-13 15:40 (prod/ben.profile and prod/usb.profile) 2011-06-13 15:42 emailed :) 2011-06-13 15:45 thanks ! 2011-06-13 15:48 hmm. ben.profile doesn't look very good. the signal is extremely weak. 2011-06-13 15:49 I have told you about the difference betwen atben and atusb line forms 2011-06-13 15:49 before pressing "D", did you move/rotate the devices a bit to make sure they weren't in a "blind" spot of each other ? 2011-06-13 15:49 gonna try 2011-06-13 15:53 usb.profile is good. there's definitely something wrong with ben.profile, though 2011-06-13 15:55 but it doesn't look like a problem of the board. more like a problem of the test. perhaps that missing PLL lock *does* tell us something ... 2011-06-13 15:56 wpwrak as background info FYI this is an especially good deal for PCBs in USA 2011-06-13 15:56 http://dorkbotpdx.org/wiki/pcb_order 2011-06-13 15:56 moving rotating doen't varies the line singificatly, it rise a little when they are next to each other but the line form is barelly the same, tested with difernte atusb 2011-06-13 15:56 this is what i get with that ben.profile: http://downloads.qi-hardware.com/people/werner/wpan/tmp/bad-ben-profile.png 2011-06-13 15:56 sorry with defferent atbens 2011-06-13 15:57 tuxbrain: yes. the first data point seems okay. all the others aren't 2011-06-13 15:57 let me test with one of your prototipes 2011-06-13 15:58 same form with your prototipes 2011-06-13 15:58 you are using openwrt or jlime 2011-06-13 15:59 just for discart things 2011-06-13 15:59 i gonna change nn 2011-06-13 15:59 rjeffries: hmm. no board thickness mentioned. presumably only 1.6 mm. but that's okay for many DIY projects. 2011-06-13 16:00 tuxbrain: that's with a ben running openwrt. but the distibution shouldn't matter. 2011-06-13 16:01 yes but I want to have the same scenario as you as possible 2011-06-13 16:03 ifconfig 2011-06-13 16:03 is it possible to use a wifi usb stick in nanonote? 2011-06-13 16:04 hmm, i have a hack that should make it work better. BUT ... it makes the whole test unstable. in the sense that you get spurious loss of USB, causing test failure. 2011-06-13 16:05 antoni' bo, nanonote only has USB device, nor USB host 2011-06-13 16:05 (what it does is that it briefly suspends the transceiver. unfortunately, this also stops the USB clock.) 2011-06-13 16:05 s/bo/no 2011-06-13 16:07 (and all this looks like another case of my reset problem masking a bug. grmbl, i should have kept more prototypes for myself ...) 2011-06-13 16:07 you thing that ben low signal is coused by usb bad reception? 2011-06-13 16:08 i think it's caused by the sending transceiver in an incorrect configuration 2011-06-13 16:10 on atben or on atusb? 2011-06-13 16:10 also more important those that mean are not sellable? 2011-06-13 16:11 make sense I also test another usb? 2011-06-13 16:11 sorry on another NN? 2011-06-13 16:12 the boards are probably fine. it's the test itself that has a problem. 2011-06-13 16:13 i need to rearrange the test a bit ... 2011-06-13 16:14 ok I will continue performing test as is , when you recieve the fab boards surelly we can definitive fine tune the whole thing 2011-06-13 16:16 better work on the sugru for now, while i ponder the spectrum test :) 2011-06-13 16:16 for sugru, it should be sufficient to use the ben->usb test (i.e., the one with a "straight" profile) 2011-06-13 16:26 tuxbrain: okay, i understand now where the test is wrong. will be a bit of work to fix it, though. 2011-06-13 16:27 tuxbrain here's an idea. go ahead and ship 2 ea of atben and atUSB to werner wpwrak TODAY so that we overlap shipping elapsed time with the obgoing testing and debugging 2011-06-13 16:30 the units for wpwrak are assured, just today is hollidays here, I will ship to him tommorow, that was decided once I got them in my hands 2011-06-13 16:30 rjeffries: he should have done that last week :) if he sends them now, i'll have them around friday or maybe even next tuesday (monday is a holiday). i don't think he'll have the patience to delay selling them so long ;-) 2011-06-13 16:31 wpwrak: get out of my mind :P 2011-06-13 16:33 but i think i can solve that little problem with the boards i have here, plus some remote verification by tuxbrain. in fact, i either have to find a way to make the USB connection survive briefly putting the transceiver to sleep, or treat the board like an at86rf230, which has a different test mode configuration. i have several at86rf230 boards and they all work beautifully. well, they'll probably start failing as soon as i actually ha 2011-06-13 16:33 ve a use for them ;-) 2011-06-13 16:42 so no big announce yet? :( 2011-06-13 16:45 i think you still have to do your sugru homework anyway, don't you ? :) 2011-06-13 16:45 meanwhile, i'll fix that test ... 2011-06-13 16:52 I will sell this first hundred without any cover 2011-06-13 16:52 I have to perform the sugru test but not for selling this ones 2011-06-13 16:52 oh :-( 2011-06-13 16:53 how come ? don't you have enough sugru ? 2011-06-13 16:53 kyak:  alex4 config file is /etc/alex4.ini 2011-06-13 16:55 that's one reason, but the main reason I have to recive reponse on the CE normative of what I have to translate of the sugru advices and how I have to stick on it 2011-06-13 16:56 is a chemical that has to follow some rules on advices, the sugru team advice me of that, and I'm on the path to be sure to not being cached in so silly thing of form defect 2011-06-13 16:56 oh, sound tricky 2011-06-13 16:56 soundS 2011-06-13 16:56 yeah, that's why I decide to not include it in that batch 2011-06-13 16:57 but I will perform the test and I will stop no body to buy sugru in the sugru shop :) 2011-06-13 16:57 don't they already come with all the necessary declarations ? afaik, they're in the UK, so they ought to have CE. 2011-06-13 16:58 (parallel channel) hehe ;-) 2011-06-13 16:58 maybe dvdk can act as your unofficial channel merger then ;-) 2011-06-13 16:58 yeah but in english , but due I will sell it in spain I have to have all that in spanish too 2011-06-13 16:58 dvdk: thanks! 2011-06-13 16:59 (spanish) gah 2011-06-13 17:01 yeah silly due I can sell all over the world but as my origin is spain I have to include it in spanish, the thing is how, his sached don't have enough clear space to put a sticker without covering the english advices , so I'm looking for if just including a leaftlet in spanish is eanough 2011-06-13 17:01 but I don't want to delay the atben/atusb launch for this 2011-06-13 17:02 yeah, i understand. but anyway, it would be good if you could do the technical verification, namely: 2011-06-13 17:02 - does it affect the signal significantly ? 2011-06-13 17:02 due almost the target of this first wave has also manifest their will to have it nude :) 2011-06-13 17:02 - which quantity is sufficient ? 2011-06-13 17:03 - can you still see the LED ? 2011-06-13 17:03 (this may affect the color choice. e.g., black sugru may be more of a problem than, say, white sugru) 2011-06-13 17:08 kyak: having a hard time with 'keymouse'  for me the volume keys are still mapped to the F14/F15 or something?  Given that 'red' maps to RALT, that's a no-go for use for clicking 2011-06-13 17:09 (and no wonder I see SIGUSR1 signal, maybe that's how a console-switch looks like) 2011-06-13 17:11 can you still remove it later? (suguru) 2011-06-13 17:14 kristianpaul: one more good question for tuxbrain :) 2011-06-13 17:15 dvdk: i can only advise to have a look at showkey (to see what are the keycodes) and dumpkeys (to see how they are mapped) 2011-06-13 17:15 not easyly... maybe is you do a some kind of "calcetin" ... that will be sure is that will not be reutilizable 2011-06-13 17:16 kyak: there were some changes recently with the volume keys.  is it right that they are mapped to F-keys?  because F+ALT is console-switch. 2011-06-13 17:17 and wrt keymouse: would be best if the keymouse modifiers were 'sticky', i.e. press red once -> arrow keys behave as mouse, press again -> arrow keys back to normal 2011-06-13 17:19 kyak: even better if we changed the kernel's key map to do the translation, i.e. red+arrow emits special key-codes that no app is going to use.  then applications would mostly ignore the mouse keys without duplicate actions. 2011-06-13 17:20 also i can't reproduce the segfault :( 2011-06-13 17:21 uh, asprite  consumes the Fn key itself, so we can't use it as mouse-click modifier :/ 2011-06-13 17:21 one sached of sugru is enough to cover an atusb, you will need to thin it with some roll but it's clear enough, due atben is a lot thiner and small than usb I think another with a sugru sached you can cover two atben. first cusstion solved 2011-06-13 17:23 led no way even with a thin amount doesnt see any bright 2011-06-13 17:24 wooow, totally no go the spectrum goes down a lot!!!! 2011-06-13 17:24 hehe 2011-06-13 17:25 isn't sugru quite expensive anyway? 2011-06-13 17:25 (spectrum) :-( 2011-06-13 17:26 lekernel: per kilo yes. per smallest available package it's not to bad 2011-06-13 17:26 it looked like tat result will happen 2011-06-13 17:26 silicon, pla, abs... hdpe, wood? 2011-06-13 17:27 kristianpaul: you seen murphy smile in anticipation all weekend long, haven't you ? ;-) 2011-06-13 17:27 wpwrak: :) 2011-06-13 17:27 tuxbrain: dont' scrape it off yet. maybe its characteristics change when it dries 2011-06-13 17:28 s/silicon/silicone 2011-06-13 17:29 it also start failing in the gpio test, don't they say it was a no conductor???? 2011-06-13 17:29 the magic and the mystery is in the "Si", which both have 2011-06-13 17:29 tuxbrain: let it cure 2011-06-13 17:29 (dries) hum i wonder if will boot after that :) 2011-06-13 17:29 hopefully it dint shirnk? 2011-06-13 17:30 tuxbrain: a lot of things are excellent conductors when wet 2011-06-13 17:30 thats true 2011-06-13 17:30 kristianpaul: (shrinkage) hmm, silicone vs. FR4 fiberglass ? i think i know the winner of that fight ;-) 2011-06-13 17:30 ok I will let it cure (24h) and retry again, but that will be sure is the no led 2011-06-13 17:30 tuxbrain: which color did you use ? 2011-06-13 17:31 tuxbrain: what shape it have? 2011-06-13 17:31 even in the most dark room doen't see any bright comming from the sugrued atusb 2011-06-13 17:31 we need deeper, darker caves 2011-06-13 17:31 kristianpaul: mmm usb green thing? 2011-06-13 17:32 :-) 2011-06-13 17:32 tuxbrain: ah, for labeling, you could just call it "desiccant". lots of electronics come with that. nobody gives it a second look ;-) 2011-06-13 17:34 yeah not even tageted costumers :P 2011-06-13 17:34 tuxbrain: if you have white sugru, you may want to give that one a try, that's probably the most likely to be at least somewhat translucent 2011-06-13 17:34 hihi ;-) 2011-06-13 17:38 sorry no white sugru, I has to be buyed apart, not part of the multicolor bag. 2011-06-13 17:38 picture of the sugrued atusb 2011-06-13 17:38 hmm yes, i suspected you didn't get that one 2011-06-13 17:38 http://en.qi-hardware.com/wiki/File:Sugrued_atusb_01.jpg 2011-06-13 17:39 well, let's see whether the spectrum still sucks in 24 hours. if it's alright, you may try the white one. if not, a few euros saved :) 2011-06-13 17:39 0_o 2011-06-13 17:39 tuxbrain needs masking tape ;-) 2011-06-13 17:40 okay, custom suguru cases :-) 2011-06-13 17:40 masking tape? 2011-06-13 17:40 you could probably imprint your name, a little face, or give it horns :) 2011-06-13 17:41 tuxbrain: (masking tape) to have clean edges. well, if it's very rubbery, a knife will do 2011-06-13 17:42 and yes, it seems you put a lot of it. no surprise the LED is invisible. 2011-06-13 17:42 wpwrak kristianpaul, this was my first atempt on sugru, and "the beauty" was not in mind 2011-06-13 17:43 sure. first see if it works at all. perfection later :) 2011-06-13 17:44 wpwrak: dont guet confused, I put a very thin layer, in the top, yes it has some in the "tail" due I have plege it , but avove the led there will be 0.2/0.3 mm 2011-06-13 17:45 i imagine that you could probably just push down on it over the led. or would it have ruptured ? 2011-06-13 17:47 I don't want to press a lot to try to recover it after the test if sugru mask the rf 2011-06-13 17:47 [commit] Werner Almesberger: tools/: rearranged cwtest/atrf-path to be more clear about reset and do re-init http://qi-hw.com/p/ben-wpan/9ef4478 2011-06-13 17:47 so that's why I have not pressed over the electronnics 2011-06-13 17:48 ah, but you have a LOT of board to experiment with ;-)) 2011-06-13 17:48 you want to see the closed by bankrupt in my web page isn't it? 2011-06-13 17:48 tuxbrain: new commit, new luck. cd ben-wpan/tools; make clean all install   (the ben side doesn't change) 2011-06-13 17:49 tuxbrain: let me find you a nice picture of a vulture ... :) 2011-06-13 17:49 for you or for me son of a ... 2011-06-13 17:49 to see how things are, atrf-path -g usb net:ben 2011-06-13 17:53 cd,.. 2011-06-13 17:54 the change of cwtest.c I did before doesn't allo to do git pull what I should do to force overwrite? 2011-06-13 17:56 git stash 2011-06-13 17:56 then proceed as usual 2011-06-13 17:58 hey this is the same as make ben? it looks pretty nicer now! 2011-06-13 17:59 very good :) 2011-06-13 17:59 now, you need to redo the profile. the one that was good before should look the same. the other one ... better ;-) 2011-06-13 18:00 (the two should look roughly the same) 2011-06-13 18:00 when you have them, please mail 2011-06-13 18:00 btw, it's enough if you mail to werner@almesberger.net 2011-06-13 18:01 ok :) 2011-06-13 18:02 sended 2011-06-13 18:03 examining ... 2011-06-13 18:06 both drop a bit towards higher frequencies. interesting. does this change if you rotate/move them a bit ? 2011-06-13 18:07 tuxbrain: hi, I see you are official Genesi distibutor now ;) 2011-06-13 18:07 (or if you remove metal objects from their vicinity. and/or move yourself away from them ;-) 2011-06-13 18:09 (if you're relatively close (<= 1 m) to the boards, you'll notice that your body has quite an influence on the signal) 2011-06-13 18:14 yes hehehe my head is causing some interference as you said my head is causing some distruption but not enough to afect +5 -5 db, and really man I can't setup things better, my head will reamain :P 2011-06-13 18:17 just don't move a lot during the tests ;-) 2011-06-13 18:18 does the line get horizontal when you rotate/move ben/pc/tuxbrain ? 2011-06-13 18:18 (that is, in some cases. you should also be able to create pretty weird patterns) 2011-06-13 18:20 yes if I move away (after shuttindown a lamp that seems also to affect when on) and in straight line at 1m with antenas pointing to each other, the line is barelly straight for moments, there is a little variance but mustly stright   2011-06-13 18:21 perfect 2011-06-13 18:22 i think you're all set to do the full test run now 2011-06-13 18:28 fine :) 2011-06-13 18:29 i thought you'd like that ;-) 2011-06-13 18:29 ok at least 10 of them has pased the new test, I quite confident the 50 atusb I have tested will also pass too 2011-06-13 18:29 yield >0% for sure wheeeeeee 2011-06-13 18:30 excellent :) the atben should be even easier. there's very little that can go wrong there. 2011-06-13 19:43 wpwrak: just one fails the test the spectrum was too low the rest seems pretty ok, after some ingest of food I will go with atben 2011-06-13 20:03 tuxbrain: excellent so far 2011-06-13 20:14 setup reordered for atben testing, re profiled and ready to burn after dinner 2011-06-13 21:25 congrats 2011-06-13 21:29 you also learned a lot about RF voodoo it seems ;-D 2011-06-13 21:30 http://www.edn.com/blog/Anablog/40313-Analog_Devices_DAC_soup_can_from_the_1970s.php 2011-06-13 21:35 DocScrutinizer: yeah I totally feel like playing with Necronomicon, I don't understand anything but a mistake can be fatal :P 2011-06-13 21:35 :-D 2011-06-13 21:36 welcome to the wonderful world of analog and UHF design 2011-06-13 21:36 whitequark, i wonder how many clicked on the picture of the can thinking it's a flash video ;) 2011-06-13 21:37 AD can - awesome! 2011-06-13 21:38 those guys been pretty good at what they do 30 years ago, and seems they are today still 2011-06-13 21:38 a bit like HP 2011-06-13 21:39 the test of atben is also a stress test of the 8:10 slot :P 2011-06-13 21:41 good, excellent 2011-06-13 21:41 stress tests are really necessary 2011-06-13 21:46 I never got it how ME can get away with next to zero testing 2011-06-13 21:46 :-) 2011-06-13 21:47 open/close screen at least 5000 times, then closely analyze. operate keys of kbd at least 100k times 2011-06-13 21:48 mate/unmate cycle all plugs at least 1000 times 2011-06-13 21:48 well, we got some drop tests, but that's been it usually 2011-06-13 21:49 even those are done once, and only a second time when first time they failed as DUT missed to drop in best angle 2011-06-13 21:50 (seems common practice on some cheap manufacturers) 2011-06-13 21:51 wpwrak: how's about production test sw to facilitate THOSE tests? ;-) 2011-06-13 21:53 I realy don't think we EE should ignore our colleagues from ME 2011-06-13 21:53 it's bad enough we usually get ignored by ID 2011-06-13 21:55 DocScrutinizer: all you need is a robotic arm with a few degrees of freedom. i've head tuxbrain is getting one soon. then he'll also be able to do ME stress testing ;-) 2011-06-13 21:59 yeah, alas it seems those robotized stress tests usually are all about how to build the test contraption in such a way it doesn't ruin the DUT, not about what a DUT encounters in RL 2011-06-13 22:01 e.g it's completely useless to operate a kbd key 100k times with a electromagnetic actor that applies always same force in same angle axectly to the center of the key cap 2011-06-13 22:02 mating connectors is even much worse in that respect 2011-06-13 22:02 well, you do what you can ;) you will certainly catch some kinds of material fatigue that way 2011-06-13 22:02 huh... ME? ID? RL? (DUT must me Device Under Test, probably.) 2011-06-13 22:03 you can easily tell robotic mating cycles are useless by the number of USB-comes-off fatalities on N900 2011-06-13 22:03 Mech Eng, IndustrialDesign (case) 2011-06-13 22:03 and Real Life ;-) 2011-06-13 22:04 ah yes. always thought the latter is a gamer-only acronym... 2011-06-13 22:04 well, it's for sure no accepted acronym in EE 2011-06-13 22:04 DocScrutinizer:  N900 were probably per-component mating cycles, not system cycles :) 2011-06-13 22:05 whitequark: (RL) for a broad sense of "gamer" ;) 2011-06-13 22:05 nah, they just didn't take into account the human shortcomings when trying to apply an exactly strictly axial pulling force 2011-06-13 22:06 wpwrak: so we're talking about that kind of people who think they live in a CAD system 2011-06-13 22:06 DocScrutinizer: well, i've heard that they fixed the problem now and removed all the faulty customers ;-) 2011-06-13 22:07 RL == Random Level (unsolicited deviation from what you planned things to be like) 2011-06-13 22:07 whitequark: not too different from the premise of "tron", if you think of it :) 2011-06-13 22:07 wpwrak: indeed 2011-06-13 22:08 wpwrak: they even did the complete step and removed their own maemo division 2011-06-13 22:10 DocScrutinizer: finally a company that pays attention to its customers ;-)) 2011-06-13 22:10 yo :-/ :-(( 2011-06-13 22:11 do you think they could've profited from showing a proto incl schem to me? ;-) 2011-06-13 22:12 DocScrutinizer: just curious, how are you related to maemo? I know you worked for openmoko, but not about nokia 2011-06-13 22:13 for their friggin N9(50)/RM-680 whatever I offered to do this *for free* and even sign their friggin NDA. Reaction: "I'm acting erratically on IRC sometimes" IDIOTS (<--- see, did it again :-P) 2011-06-13 22:13 whitequark: I'm strictly an educated user not shy to disassemble and analyze his own friggin expensive N900 2011-06-13 22:15 DocScrutinizer: have you found something horrific? 2011-06-13 22:15 I'm also the guy that made USB hostmode work despite Nokia telling "that's impossible" for ~100 times 2011-06-13 22:15 I pointed at some 2 .. 3 minor hw design flaws 2011-06-13 22:15 plus a few big ones 2011-06-13 22:16 but that's useless as N900 won't ever come in a N900-I JR edition 2011-06-13 22:19 there are some poor designs in kbd matrix that don't allow some 2-qualifier-key+CHAR 3key-combinations, for no good reason 2011-06-13 22:20 there's also an almost selfdistruct design around SoC I/O level vs LP5523 LED driver 2011-06-13 22:21 this could've been avoided by using a resistor. Other system immanent selfdistruct methods are designed to never vanish (e.g. CPU core voltage programmable), so I don't consider this particular one anything special or particularly concerning 2011-06-13 22:23 esp since it's rather hard to activate this operation mode in LP5523 and destructive effect is questionable, though it looks scary to feed 4.2V to a 1.8V GPIO 2011-06-13 22:26 tuxbrain: btw, if you still have counterweights left, you may offer to include then in any ben+wpan bundles people are ordering. a special goodie for those not afraid of using a screwdriver :) 2011-06-13 22:26 design of the USB receptacle has been discussed all over the place ad nauseum - not really anything more to add to this topic, except my very own favourite solution to use some solder free spring contacted component like they did for AV-receptacle (and 2mm barrel power on N8x0) 2011-06-13 22:26 should say more times that things are impossible on M1 as it seems to be a strong motivator 2011-06-13 22:26 wpwrak: good idea :) 2011-06-13 22:26 lekernel: HDTV ? :) 2011-06-13 22:27 HD?! impossible! 2011-06-13 22:27 fpga are too slows 2011-06-13 22:27 lekernel: i think you're doing it right ;-) 2011-06-13 22:28 lekernel: maybe add "it would take years of work from a team of top-notch engineers". usually, that will wake up that 12 year old kid who does it in an afternoon ;-) 2011-06-13 22:28 haha 2011-06-13 22:29 needs to google for that dude that made N900(?) output DVB signals :-) 2011-06-13 22:30 or was it ... ah now... the "transmit music from your CRT" 2011-06-13 22:30 DocScrutinizer: does N900 include an FM transmitter yet ? :) 2011-06-13 22:30 of course it got FMTX 2011-06-13 22:30 didn't you know? 2011-06-13 22:30 DocScrutinizer: by design or by freak ? 2011-06-13 22:31 by design and nicely integrated into maemo GUI 2011-06-13 22:31 pity. that doesn't count then. 2011-06-13 22:31 how about GPS sender ? that should be a worthy challenge 2011-06-13 22:32 FMRX OTOH been an "easter egg" 2011-06-13 22:33 nah, proper RDS to make cars leave the highway, that's a worthy goal for a hack ;-) 2011-06-13 22:33 FMTX knows to do basic RDS 2011-06-13 22:33 GPS jammers are hard to implement in sw ;-) 2011-06-13 22:34 RDS sender sounds useful, yes. of course it would be most useful for the cars ahead of you ... 2011-06-13 22:35 also there's a whole class of weapons that have highly evolved aiming gear to target you with an accuracy of +-3m as soon as you start to operate such a GPS jammer ;-P 2011-06-13 22:36 DocScrutinizer: so, if you depend on your GPS, always carry a few of these 2011-06-13 22:36 I've heard in Russia there's also a class of weapons that does same for WLAN freq that aren't allowed over there X-D 2011-06-13 22:36 GLONASS FTW! 2011-06-13 22:37 DocScrutinizer: friend-foe identification, version 2 ;-) 2011-06-13 22:37 (russia WLAN) you'd have to ask Paul about it 2011-06-13 22:38 GLONASS seems a bit useless, for reasons I can't recall right now 2011-06-13 22:38 I'm quite interested in future european positioning system, forgot the name 2011-06-13 22:39 (glonass) with the new underwater satellite group, you can navigate submarines quite precisely 2011-06-13 22:39 hehe 2011-06-13 22:39 it should have better accuracy and availability than US GPS 2011-06-13 22:39 DocScrutinizer: freqs about 5GHz iirc 2011-06-13 22:39 whitequark: had some bad luck with the rockets ? 2011-06-13 22:40 but looks like things are changing slowly 2011-06-13 22:40 Jay7: sounds about right, yeah. 802.11a 2011-06-13 22:41 wpwrak: I don't quite recall the details 2011-06-13 22:41 was working in ISP before 2005 2011-06-13 22:41 DocScrutinizer: I think you misunderstand the purpose of Galileo. it's not about building a navigation system. it's about having an excuse for putting large amounts of money into the pockets of needy large companies for a decade or two. 2011-06-13 22:41 we have tried to get that freqs 2011-06-13 22:41 switch on in Moscow and wait for miltary to send someone/something to visit you 2011-06-13 22:41 but declined 2011-06-13 22:41 DocScrutinizer: I'm sure they didn't note this even :) 2011-06-13 22:42 Jay7: sure, just kidding. But that's basically what they tell you, I guess 2011-06-13 22:42 they inspecting freqs only when something starting to bother their devices :) 2011-06-13 22:43 some sidewinder class rockets work at this 5GHz freq 2011-06-13 22:44 so a large number of 802.11a APs down there would mess up those rockets' radar, that's what I've been told 2011-06-13 22:44 and it's *theoretically* possible the sidewinder aims at you rather than the intended target ;-P 2011-06-13 22:45 ;) 2011-06-13 22:47 in fact it's rather simple to use a certain freq for your radar and simply aim at the strongest "echo" -quite effectively defeats all CM gear the opponent's aircraft might use 2011-06-13 22:48 but makes the missile prone to hit 802.11a APs instead of the opponent's aircraft 2011-06-13 22:50 I don't buy it, as the missile's radar needs to filter out ground reflections anyway 2011-06-13 22:53 funny detail though: you allegedly still can ground jetfighters by using a simple magnetron in a parabolic dish, to jamm all their electronic gear on board 2011-06-13 22:55 I prefer my MTHELs, also they look rather decorative out there in my garden. And the H3F exhaust fumes nicely kill off the neighbour's weed X-P 2011-06-13 22:56 http://www.youtube.com/watch?v=cCBwLJjzDJQ 2011-06-13 23:02 [commit] Werner Almesberger: tools/dirtpan/dirtpan.c: added missing #include "daemon.h", oops http://qi-hw.com/p/ben-wpan/a800eb8 2011-06-13 23:30 soo boooring almost 80% atben test done and all pass 2011-06-13 23:31 aaaw ;-) 2011-06-13 23:32 scp's some of the electronic gremlins from his zoo over to tuxbrain 2011-06-13 23:32 tuxbrain: still plan to do a range test with every single board ? 2011-06-13 23:32 no 2011-06-13 23:33 definitively no 2011-06-13 23:33 i didn't think so ;-)))) 2011-06-13 23:33 DocScrutinizer's gremlins also pass 2011-06-13 23:35 not after midnight in Aegypt 2011-06-13 23:36 midnight in Aegypt also pass 2011-06-13 23:37 midnight is not a problem as long as you don't feed them 2011-06-13 23:37 make gremlin 2011-06-13 23:37 PASS Midnight 2011-06-13 23:37 ;-) 2011-06-13 23:37 PASS GPIO Food 2011-06-13 23:37 always wondered when "after midnight" ends, because there has to be a time when it is ok to feed them or they'll starve 2011-06-13 23:38 PASS pass waterresistance 2011-06-13 23:38 PASS spectrum... gizmo song ok 2011-06-13 23:39 PASS bright light 2011-06-13 23:39 bah, another gremlin made by tuxbrain 2011-06-13 23:40 one failed ? 2011-06-13 23:40 100% pass would mean that i'd have to make nastier tests :) 2011-06-13 23:41 well they not pass the sugru test :P 2011-06-13 23:42 let's wait with that verdict until 24 hours have passed. curing may still make a difference. 2011-06-13 23:43 mth: I always claim to never drink before noon - it's always after noon somewhere. It's also per definition always and everywhere after last noon 2011-06-13 23:43 so another PASS? PASS sugru 2011-06-13 23:43 I don't know if I can resist 2011-06-13 23:44 indeed 100% yield is a bad sign 2011-06-13 23:44 DocScrutinizer: can you elaborate please? 2011-06-13 23:44 no kidding 2011-06-13 23:45 100% yield indicates the tests may be ineffective 2011-06-13 23:45 of course only applies to sufficiently large sample sizes 2011-06-13 23:45 now that's funny. the baluns have an operating temperature of -40 to +85 C, but a storage temperature of only 15-35 C. you don't see such a thing often :) presumably, this is to avoid accumulation of humidity before SMT. while afterwards, you don't care. 2011-06-13 23:46 exactly 2011-06-13 23:47 well I must say that some of the atbens has some tendency to have more signal making the spectrum make some yellow arrow for a moment , so the most mistake is that some (mabe a 5 or 6 works slightly better than the others 2011-06-13 23:47 also "storage" may mean "unlimited stashing without degradation" while "operation" means "works for the designed lifetime" 2011-06-13 23:48 tuxbrain: good enough to prove effectiveness of tests, I guess 2011-06-13 23:48 tuxbrain: maybe you picked a weak one as the reference 2011-06-13 23:48 that fits in the 95% of the rest? 2011-06-13 23:49 just in the middle of the red lines 2011-06-13 23:49 if the difference is small, that may still happen (and it's good that it's small) 2011-06-13 23:49 95% inside "standard deviation limits" is what you'd expect anyway 2011-06-13 23:49 how did my reference board perform ? or was that the one you used to generate the profile ? 2011-06-13 23:50 if one or some of the 5% are too bad to pass QA depends on size of sample, as mentioned above 2011-06-13 23:50 reference board you mean your prototipe? 2011-06-13 23:50 yes 2011-06-13 23:50 as well as some other parameters of the whole equation 2011-06-13 23:51 I have used fab one as ref 2011-06-13 23:51 do you want I perform the test with yours? wait 2011-06-13 23:52 100% inside standards would indicate your standards are poorly defined, or the testbed is yielding bogus results 2011-06-13 23:52 DocScrutinizer: the spectrum test isn't particularly tight. the goal is to find severe flaws, such as a component missing, one output grounded, or such. a few dB more or less is something we can't control with our amateurish setups anyway. 2011-06-13 23:53 I agree, but I'm sure you got my basic idea 2011-06-13 23:53 wpwrak: the prototipe,  inside the margins tending to the low band but green anyway 2011-06-13 23:53 tuxbrain: (test with mine) yup :) if it's way out, that would be a little worring. i may a bit out [...] 2011-06-13 23:53 gooood 2011-06-13 23:53 tuxbrain: perfect. that's exactly what should happen ;-) 2011-06-13 23:54 I'm confident the tests are effective and you did an awesome job at assembly 2011-06-13 23:54 tuxbrain: i expect the factory-made ones to be better overall than my DIY work. so it makes sense that the prototypes perform "low" when compared to an MP board. 2011-06-13 23:57 only 10 left 2011-06-13 23:57 yield is already > 92%, no matter what happens next ;-) 2011-06-13 23:59 5