| kristianpaul | wpwrak: I'm going to give a small talk to the local dorkbot people about copyleft hardware | 01:20 |
|---|---|---|
| kristianpaul | I will talk about nanonote, milkymist and wpan (may be gps-sdr for get people interested on development too) | 01:21 |
| kristianpaul | I want talk about the part of the atena design in wpan | 01:21 |
| kristianpaul | Is okay said, it is a rev eng process coming for already similar products, and you developed the tools and integrated existent one as usrp2 in order to make that trial and error process easier? | 01:22 |
| wpwrak | kristianpaul: i didn't really reverse-engineer the antenna. i took this design: http://focus.ti.com/lit/an/swra117d/swra117d.pdf | 01:27 |
| wpwrak | kristianpaul: what i changed was the size. TI describe that the size depends on the PCB thickness, but don't explain how exactly it changes. (their design is for a 1.0 mm board, mine are 0.8 mm) | 01:28 |
| wpwrak | kristianpaul: finding the right size is what the experiments were for | 01:29 |
| kristianpaul | ah, okay ! | 01:29 |
| wpwrak | kristianpaul: i used the usrp2 basically as a spectrum analyzer. i didn't complete any software that talks directly to the USRP2 (there's that partial spectrum analyzer i did, but that doesn't produce correct results yet) | 01:31 |
| kristianpaul | ah... | 01:31 |
| wpwrak | kristianpaul: instead, i used the gnuradio tool usrp2_rx_cfile.py to capture a transmission and then perform FFT (and some other filtering) on it | 01:32 |
| wpwrak | kristianpaul: so i integrated the USRP2 and an existing gnuradio tool into my test/experiment setup | 01:32 |
| kristianpaul | wpwrak: what about RF consideratios for board design, is it also documented on the aplication note you pointed to me? | 01:34 |
| wpwrak | kristianpaul: see also ben-wpan/usrp/sps/collect for collecting the traces, and ben-wpan/usrp/fft.c for the FFT. ben-wpan/usrp/sps/ has more scripts for visualization and such. they are what i used to generate http://downloads.qi-hardware.com/people/werner/wpan/20110303/ | 01:36 |
| wpwrak | kristianpaul: (RF) a little. but most comes from http://www.atmel.com/dyn/resources/prod_documents/doc8092.pdf | 01:37 |
| kristianpaul | yes, i'm aware of FFT part | 01:38 |
| wpwrak | kristianpaul: plus a bit of googling around. see also ben-wpan/ecn/ecn0007.txt | 01:38 |
| kristianpaul | okay, software part is the implementation of MAC by bit banging RF CHip registers? | 01:38 |
| kristianpaul | one of the functions of software part* | 01:39 |
| kristianpaul | I just like to make clear how a "Wifi" chip differ from yours 802.15.4 one | 01:40 |
| wpwrak | kristianpaul: there are two sets of software: the tools in ben-wpan/tools/ and the linux stack. the linux stack uses the ieee 802.15.4 drivers and mac of the linux-zigbee project. i just made a few small corrections and added the platform-specific initialization (gpio setup and such) | 01:40 |
| kristianpaul | And the benefist in software | 01:40 |
| kristianpaul | ok | 01:40 |
| wpwrak | kristianpaul: the tools under ben-wpan/tools/ don't implement a proper mac - they just send "naked" frames without address fields or such | 01:41 |
| wpwrak | kristianpaul: well atrf-txrx, which is the most complex of the tools. the others have other roles, e.g., atrf-id just identifies the chip, atrf-rssi shows the signal strength (without actually receiving any data), and so on | 01:42 |
| kristianpaul | ACK | 01:52 |
| kristianpaul | wpwrak: any wishlist for wpan thay you feel missed now, and wanted for future versions? | 01:57 |
| wpwrak | kristianpaul: better RF design testing. more compact (use a four-layer board with microvias). maybe better testability for atben (lacks an easy way to test the crystal). maybe antenna diversity. maybe an RF amplifier for range extension. find out if a dedicated MCU can be useful and act accordingly (or not). | 02:03 |
| wpwrak | kristianpaul: also, some real-life experience with wpan may add more items :) | 02:04 |
| kristianpaul | (real-life experience) agreed :-) | 02:08 |
| qi-bot | [commit] Ayla: The method FileLister::browse() now takes an optional boolean argument. http://qi-hw.com/p/gmenu2x/d820470 | 10:03 |
| qi-bot | [commit] Ayla: If the "sections/" directory is missing, we create it as well as some default sections (settings, applications...). http://qi-hw.com/p/gmenu2x/8336c83 | 10:03 |
| qi-bot | [commit] Ayla: The sections directories shall now be found under the user-specific directory. http://qi-hw.com/p/gmenu2x/114fe59 | 10:03 |
| qi-bot | [commit] Ayla: The skin images will now be loaded using SurfaceCollection::getSkinFilePath(). http://qi-hw.com/p/gmenu2x/fe25cf3 | 10:03 |
| qi-bot | [commit] Ayla: Define a default wallpaper path, that will be chosen if no wallpaper is defined on the config. http://qi-hw.com/p/gmenu2x/301e16e | 10:03 |
| Ayla | hello | 10:20 |
| Ayla | I'm looking for a picture I could use as the default wallpaper for gmenu2x for the nanonote | 10:21 |
| wpwrak | wolfspraul: so now the community news feature deep inside jokes ;-)) | 10:36 |
| wpwrak | wolfspraul: not sure it you saw these: | 10:37 |
| wpwrak | | potential entries for the 04-04: 1) the ben-wpan samples http://lists.en.qi-hardware.com/pipermail/discussion/2011-March/007457.html | 10:37 |
| wpwrak | | the decision that tuxbrain will lead the production (and which may potentially have started already) | 10:37 |
| wpwrak | oops, let's try this again ... | 10:37 |
| wpwrak | | 2) the decision that tuxbrain will lead the production (order already issued) | 10:38 |
| wpwrak | | 3) that we have a kernel that allows atben to communicate via ieee 802.15.4 | 10:38 |
| wpwrak | | not sure if 3) is newsworthy yet. there are still a few more things missing before it's actually useful | 10:38 |
| wpwrak | | regarding 2), there's also the integrated process for producing fab files, but i haven't documented it yet. at its core is ben-wpan/makefiles/Makefile.kicad, which is semi-generic | 10:38 |
| wolfspraul | yes sure I saw it, thanks a lot | 10:43 |
| wolfspraul | no worries | 10:43 |
| wolfspraul | wpwrak: what is the deep inside joke? | 10:43 |
| wolfspraul | I just try to collect a few nice things... | 10:44 |
| wpwrak | wolfspraul: the money falling from the sky :) | 10:44 |
| Action: kristianpaul at medellin | 11:01 | |
| wolfspraul | wpwrak: ah. that may be subconsciousness :-) | 11:02 |
| wolfspraul | I just flipped through the mimi&eunice comics and liked that one... | 11:02 |
| wpwrak | it resonates rather strongly with current events ;-) | 11:03 |
| kristianpaul | I liked that comic too :-) | 11:10 |
| wolfspraul | ok I think all sections except NanoNote are finished | 11:34 |
| wolfspraul | this is what I'm talking about http://en.qi-hardware.com/wiki/Community_news_2011-04-04 | 11:34 |
| wpwrak | wolfspraul: do the new visual patches have any images ? | 11:41 |
| wolfspraul | he | 11:45 |
| wolfspraul | fbgrab (screenshot) is also just being added | 11:45 |
| wolfspraul | so there are few screenshots of m1 still | 11:45 |
| wolfspraul | but that should soon improve :-) | 11:45 |
| wolfspraul | ctrl-f12, done | 11:46 |
| wpwrak | aah, fbgrab. very important indeed ! | 11:46 |
| wolfspraul | so I don't know whether we have screenshots, I didn't see any otherwise I would have included them | 11:46 |
| wolfspraul | one by one | 11:46 |
| wolfspraul | we also have 05-01 news | 11:46 |
| wolfspraul | the old way to take screenshots was only in qemu, afaik | 11:47 |
| wolfspraul | Sebastien uploaded the 2 shots of his new color theme, not sure whether he took them in qemu or already with fbgrab | 11:48 |
| wpwrak | should be easy to find out ;-) | 11:49 |
| wpwrak | hmm. maybe. | 11:54 |
| wpwrak | larsc: i just read about zram ... could this be something useful for our ben's poor little memory ? | 11:57 |
| larsc | maybe | 12:02 |
| Ayla | yes, it works quite good | 12:04 |
| wpwrak | Ayla: you've tried it on the ben ? | 12:07 |
| kristianpaul | where do you tested or saw it working Ayla ? | 12:07 |
| Action: kristianpaul at hostel | 12:07 | |
| Ayla | it's enabled by default on opendingux | 12:07 |
| Ayla | the new linux kernel for dingoo a320 | 12:07 |
| Ayla | so it should work quite good on ben too | 12:07 |
| wpwrak | Ayla: how does the system's performance differ with/without it ? | 12:14 |
| Ayla | well, if it's not used, it does not eat any memory or processing power | 12:15 |
| Ayla | in use, it uses some processing power to compress/decompress the data. However, it's still faster than swap on a flash device like SD | 12:16 |
| wpwrak | Ayla: do you did notice a performance improvement ? i mean, not only on paper | 12:18 |
| Ayla | yes, eduke32 is less laggy when using swap | 12:18 |
| Ayla | I mean, zram swap over SD swa | 12:18 |
| Ayla | swap* | 12:18 |
| wpwrak | great. that's a useful data point, thanks | 12:19 |
| wpwrak | i wonder what it does for systems that don't use swap. may have an even more dramatic effect | 12:20 |
| wpwrak | wolfspraul: so sebastien's screenshots were taken to fbgrab | 13:24 |
| wolfspraul | saw it | 13:24 |
| wolfspraul | PROGRESS | 13:24 |
| wolfspraul | :-) | 13:24 |
| wpwrak | yay ! :) | 13:24 |
| whitequark | is xiangfu very busy now? | 13:58 |
| wolfspraul | ok I will do more NanoNote editing (in the news) tomorrow | 14:16 |
| wolfspraul | slowly getting there | 14:17 |
| rjeffries | wpwrak assuming Nanonote 8:10 SPI --> UBB --> ribbon cable --> [some flavor Arduino] | 16:14 |
| rjeffries | what would one look for so the target Arduino can exchange data with Nanonote "master" | 16:15 |
| rjeffries | for now we ignore whether the Arduino can or can not be programmed from this lash up. | 16:15 |
| kristianpaul | rjeffries: i think long time ago that questions you made is answered as posible | 16:21 |
| kristianpaul | but maybe i lost the point.. :/ | 16:21 |
| roh | there are spi serial converters | 16:32 |
| roh | in the end only a programmed avr, but possible | 16:32 |
| roh | one could programm another ardiuino via that | 16:32 |
| rjeffries | thanks roh maybe I am unclear myself. I know tuxbrain connected Aeduinno to Ben Nanonote long ago using Ben's serial port | 17:02 |
| rjeffries | that would work with any Arduino or clone model | 17:02 |
| rjeffries | when using SPI to talk to Arduino, I am not sure if ont certain Arduinos can do that, or | 17:03 |
| rjeffries | maybe a "shield" with an extra SPI to serial chip is needed? | 17:03 |
| rjeffries | where i am headed is thinking of an Arduino of some ilk connected to Nanonote over | 17:05 |
| rjeffries | a reasonably high speed connection. then (just a matter of software...;) it would be possible | 17:05 |
| rjeffries | to connect Nanonote to Ethernet | 17:06 |
| rjeffries | or interface (via arduino) to I2C periferals | 17:06 |
| rjeffries | the major smarts are Linux Ben Nanonote, the Arduino is a semi smart semi independent slave pod | 17:07 |
| rjeffries | the Arduino ecosystem offers so many cool and cheap modules but suffers from being quite low level | 17:08 |
| rjeffries | new topic: this seems mildly interesting and very open: | 17:09 |
| rjeffries | http://diydrones.com/profiles/blogs/announcing-openfhss-project | 17:09 |
| whitequark | rjeffries: the problem with ethernet is, you don't have any external interface with sufficiently high speed and host capability | 17:30 |
| whitequark | maybe you'll be able to find SDIO ethernet card, but it won't work with SPI | 17:31 |
| rjeffries | whitequark well, if goal is connectivity, I think it can work. wpwrak measures (if I recall right...) | 17:34 |
| rjeffries | well over a megatbit per second over the 8:10 spi interface. | 17:34 |
| rjeffries | most access to internet does not require very high speed. | 17:35 |
| rjeffries | I am so old i remember using dial modems to connect to internet at various speeds | 17:35 |
| rjeffries | at 56Kbps, the internet is useable. works great for email or irc and ok for light casual browsing with a text browser | 17:36 |
| whitequark | rjeffries: there are two points | 18:06 |
| whitequark | first, not everyone uses ethernet for internet. it's sometimes useful to transfer a file to internal media | 18:06 |
| whitequark | well, that may be not very useful as there's usb-device and sd-card anyway. | 18:07 |
| whitequark | second, pages were loading at acceptable speed then in 56k days. now average homepage may be around a megabyte of rounded corners and transparent PNGs | 18:07 |
| whitequark | hm, third is that it'd be hard to fit a good browser in ben's 32M | 18:08 |
| Ayla | that's fine using zram swap ;) | 18:10 |
| kyak | whitequark: is "links -g" a good enough browser for you? It fits well into Ben's 32Mb :) | 18:15 |
| tuxbrain | whitequark: sure and ethernet module with spi interface will not work? I have been reported with diferent opinions about this | 18:19 |
| whitequark | kyak: please, try using it for, maybe, a day or two, and you'll answer your question yourself | 18:29 |
| kyak | whitequark: i don't get your point | 18:31 |
| whitequark | kyak: it isn't really usable with modern sites | 18:32 |
| whitequark | at least it wasn't last time I've checked it | 18:32 |
| kyak | "modern sites"? what is it? | 18:32 |
| whitequark | tuxbrain: of course it will work. somehow. looking at PM, SD pins are not multiplexed with SPI, and so you'll need to use bitbang driver in kernel | 18:33 |
| whitequark | that isn't very fast and is very cpu-hungry | 18:33 |
| whitequark | kyak: try opening qi-hardware.com, or maybe google.com, or github.com | 18:34 |
| kyak | whitequark: http://en.qi-hardware.com/wiki/Applications#links | 18:34 |
| kyak | this is "opening qi-hardware.com" :) | 18:34 |
| wpwrak | rjeffries: (comm with avr) SPI with the ben the master and the avr the slave should be convenient | 18:44 |
| wpwrak | rjeffries: (from yesterday, SIE with jz4760) not a bad idea. if someone was to redesign the SIE, that would certainly be a better starting point than the aging 4720 | 18:48 |
| whitequark | kyak: links cannot be used for day-to-day tasks | 18:55 |
| whitequark | it is only good to say "hey, our device can load web-pages", but hardly more | 18:57 |
| kyak | it depends on which tasks you do day-to-day | 18:59 |
| kyak | i use elinks regularly to access gmail without any problems | 18:59 |
| kyak | have to go now | 19:00 |
| rjeffries | wpwrak how much new Ben software is needed to achieve bi-direcetional data transfer between Ben NN and AVR (read Arduino) | 19:39 |
| wpwrak | rjeffries: just to communicate ? not a lot. you could just reuse my spi code for ben-wpan. the harder bit is the avr side, plus some meaningful protocol that rides on top of spi. | 19:41 |
| rjeffries | wpwrak ubderstood regards need for a Ben to AVR protocol | 19:42 |
| rjeffries | if objective is using AVR to handle real time data collection via say I2C or whatever, with AVR/Arduino as a smart beffer or even some data reduction before handoff to ben that could be feasible | 19:43 |
| rjeffries | but to get real, why not use a cheap netbook as master and simply communicate to Arduino via USB. | 19:44 |
| rjeffries | a low end netbook running linux is prolly $200 new oe slightly used | 19:45 |
| wpwrak | sure, you can do that. i would try to cut out the man in the middle, i.e., the avr :) | 19:48 |
| Action: wpwrak hates statistical distributions that don't make sense | 20:28 | |
| tuxbrain | wpwrak: what distribution are you talking about? | 20:32 |
| wpwrak | tuxbrain: the transmit timing, measured by the ben. i'm trying to determine the atben's clock frequency without direct access to the clock signal. | 20:37 |
| tuxbrain | wpwrak: really, don't use my name followed by black magic power words like frequency , direct access or signal... it really scares me. | 20:39 |
| wpwrak | tuxbrain: the method is to load a packet, then initiate transmission with a pulse (there's a dedicated gpio for this). then measure how long it takes until the tx complete interrupt arrives | 20:40 |
| wpwrak | ah wait .. lemme check the chip-internal interrupt latency ... | 20:40 |
| tuxbrain | wpwrak: Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn | 20:41 |
| tuxbrain | wpwrak: biboca garagem favela fubanga maloca bocada Maloca bocada fubanga Favela garagem biboca, porra !!! Ze do caixao zumbi lampiao | 20:44 |
| wpwrak | grmbl. two set of values, an unexplainable 150 us apart | 20:47 |
| wpwrak | i understood the first and the second, but you threw me with the catalan ;-) | 20:48 |
| tuxbrain | I think is portugues , is a the Rattamahatta lyrics from sepultura, I don't know what it really means but the song looks like a vudu conjure :P | 20:51 |
| tuxbrain | or maybe a recieipt to do some cake but well , it sounds like vudu cake | 20:52 |
| tuxbrain | 150us seems a lot of time on transmision scale, isn't it? (OMG I'm starting to intuit your tech mambo jambo nonsense) | 20:54 |
| wpwrak | the drugs are starting to work ;-) | 20:55 |
| tuxbrain | drugs+lack of sleep+a lot of qt programing readed is causing me to feel sick.... I think I'm gonna remedy at least one of the three, good night | 20:57 |
| wpwrak | tuxbrain: here's some sample data: http://downloads.qi-hardware.com/people/werner/wpan/tmp/tx-100-counts.gz | 20:57 |
| wpwrak | tuxbrain: a good way to look at it is, after gunzip'ing, with gnuplot plot "<sort -n tx-100-counts" with lines | 21:00 |
| wpwrak | to zoom in, set yrange [30000:33000] (or zoom manually) | 21:00 |
| wpwrak | yaxis is the number of counts between send trigger and interrupt. one count is about 100 ns | 21:01 |
| tuxbrain | well no need to see that it seems that it tends to be stable at 31300 aprox but with random jumps of 400 to 1000 units .... whatever it means | 21:02 |
| wpwrak | x axis is the cumulative number of samples. e.g., we have about 7000 samples with ~31300 counts, ~2000 samples between ~31300 and ~32800, and then another ~1000 around 32800 | 21:03 |
| wpwrak | this is a ben with everything that could get in the way dead. including interrupts. actually, let me verify that ... | 21:04 |
| wpwrak | yeah. everything switched off | 21:05 |
| tuxbrain | well if the input is the same something should be altering the values.... in theory same input sould give you output ... extrange... | 21:06 |
| wpwrak | it gets worse: plot "tx-100-counts" with dots | 21:06 |
| wpwrak | now you can see that there are a lot of samples at the ~31300 baseline. but there's a pattern over time with the ones that don't quite fit. they're also very systematic. | 21:07 |
| tuxbrain | yes I even saw that with the numbers directly.... I think something is happen on the ben on x period | 21:08 |
| tuxbrain | something is not off | 21:08 |
| wpwrak | yet i do set ICMSR to 0xffffffff | 21:09 |
| tuxbrain | or the sistem or the CPU is doing something we don't know on that moment cyclic | 21:10 |
| wpwrak | hmm. maybe the frame buffer. switching it off, too ... | 21:11 |
| tuxbrain | I suppose this will complicate the creation of software on the ben side for communications isn't it? | 21:11 |
| wpwrak | in the end, my program will look worse than gmenu2x ;-) | 21:11 |
| tuxbrain | ha! | 21:12 |
| wpwrak | (complicate) no, not at all. this is only for production testing. | 21:12 |
| tuxbrain | also with an advert before the screen shut down... don't move, don't breath, you may alter the values stay froze for a seconds please.... | 21:13 |
| wpwrak | naw, the system is only unresponsive for about 3-4 ms | 21:17 |
| wpwrak | of course, 10000 times in a row ;) | 21:17 |
| tuxbrain | wow how long is the test? | 21:18 |
| wpwrak | 4 ms * 10k = ~40 s. of course, 10000 is a bit excessive. once things work properly, a lot less should do. | 21:21 |
| wpwrak | yes ! that did the trick ;-) | 21:24 |
| tuxbrain | was the frambuffer? | 21:24 |
| wpwrak | yup. tuned the lcd clock off and now i get ... | 21:27 |
| wpwrak | (tuRned) | 21:28 |
| wpwrak | http://downloads.qi-hardware.com/people/werner/wpan/tmp/tx-counts-trim.png | 21:28 |
| wpwrak | that's with different trim values. t0 is the lowest extra capacitance -> clock runs fastest, t15 the highest -> slowest | 21:29 |
| wpwrak | and this is indeed what we see :-) | 21:30 |
| wpwrak | distribution looks vaguely gaussian, which is also good | 21:30 |
| tuxbrain | ok again im lost in translation from wpwrakish to tuxbrainian, but if you are happy and you said is good , I'm happy too :) | 21:40 |
| tuxbrain | gn8 | 21:41 |
| wpwrak | (trim) the load capacitors of the crystal are programmable | 21:44 |
| wpwrak | so changing the trim is an easy test for whether i can accurately measure the clock frequency. the objective is to detect SMT problems. so a whole capacitor would be missing. that would cause a greater divergence than these trim changes. | 21:46 |
| wpwrak | hmm. something in the ben doesn't like it if i turn off the lcd clock. hangs after a while :-( | 22:06 |
| wpwrak | tuxbrain: you may get your wish for a "don't touch while testing" mode after all :) | 22:18 |
| --- Mon Apr 4 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!
