<kristianpaul>
wpwrak: I'm going to give a small talk to the local dorkbot people about copyleft hardware
<kristianpaul>
I will talk about nanonote, milkymist and wpan  (may be gps-sdr for get people interested on development too)
<kristianpaul>
I want talk about the part of the atena design in wpan
<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?
<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)
<wpwrak>
kristianpaul: finding the right size is what the experiments were for
<kristianpaul>
ah, okay !
<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)
<kristianpaul>
ah...
<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
<wpwrak>
kristianpaul: so i integrated the USRP2 and an existing gnuradio tool into my test/experiment setup
<kristianpaul>
wpwrak: what about RF consideratios for board design, is it also documented on the aplication note you pointed to me?
<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/
<wpwrak>
kristianpaul: plus a bit of googling around. see also ben-wpan/ecn/ecn0007.txt
<kristianpaul>
okay, software part is the implementation of MAC by bit banging RF CHip registers?
<kristianpaul>
one of the functions of software part*
<kristianpaul>
I just like to make clear how a "Wifi" chip differ from yours 802.15.4 one
<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)
<kristianpaul>
And the benefist in software
<kristianpaul>
ok
<wpwrak>
kristianpaul: the tools under ben-wpan/tools/ don't implement a proper mac - they just send "naked" frames without address fields or such
<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
<kristianpaul>
ACK
<kristianpaul>
wpwrak: any wishlist for wpan thay you feel missed now, and wanted for future versions?
<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).
<wpwrak>
kristianpaul: also, some real-life experience with wpan may add more items :)
<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
<qi-bot>
[commit] Ayla: The sections directories shall now be found under the user-specific directory. http://qi-hw.com/p/gmenu2x/114fe59
<qi-bot>
[commit] Ayla: The skin images will now be loaded using SurfaceCollection::getSkinFilePath(). http://qi-hw.com/p/gmenu2x/fe25cf3
<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
<Ayla>
hello
<Ayla>
I'm looking for a picture I could use as the default wallpaper for gmenu2x for the nanonote
<wpwrak>
wolfspraul: so now the community news feature deep inside jokes ;-))
<wpwrak>
| the decision that tuxbrain will lead the production (and which may potentially have started already)
<wpwrak>
oops, let's try this again ...
<wpwrak>
| 2) the decision that tuxbrain will lead the production (order already issued)
<wpwrak>
| 3) that we have a kernel that allows atben to communicate via ieee 802.15.4
<wpwrak>
| not sure if 3) is newsworthy yet. there are still a few more things missing before it's actually useful
<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
<wolfspraul>
yes sure I saw it, thanks a lot
<wolfspraul>
no worries
<wolfspraul>
wpwrak: what is the deep inside joke?
<wolfspraul>
I just try to collect a few nice things...
<wpwrak>
wolfspraul: the money falling from the sky :)
<kristianpaul>
at medellin
<wolfspraul>
wpwrak: ah. that may be subconsciousness :-)
<wolfspraul>
I just flipped through the mimi&eunice comics and liked that one...
<wpwrak>
it resonates rather strongly with current events ;-)
<kristianpaul>
I liked that comic too :-)
<wolfspraul>
ok I think all sections except NanoNote are finished
<whitequark>
rjeffries: the problem with ethernet is, you don't have any external interface with sufficiently high speed and host capability
<whitequark>
maybe you'll be able to find SDIO ethernet card, but it won't work with SPI
<rjeffries>
whitequark well, if goal is connectivity, I think it can work. wpwrak measures (if I recall right...)
<rjeffries>
well over a megatbit per second over the 8:10 spi interface.
<rjeffries>
most access to internet does not require very high speed.
<rjeffries>
I am so old i remember using dial modems to connect to internet at various speeds
<rjeffries>
at 56Kbps, the internet is useable. works great for email or irc and ok for light casual browsing with a text browser
<whitequark>
rjeffries: there are two points
<whitequark>
first, not everyone uses ethernet for internet. it's sometimes useful to transfer a file to internal media
<whitequark>
well, that may be not very useful as there's usb-device and sd-card anyway.
<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
<whitequark>
hm, third is that it'd be hard to fit a good browser in ben's 32M
<Ayla>
that's fine using zram swap ;)
<kyak>
whitequark: is "links -g" a good enough browser for you? It fits well into Ben's 32Mb :)
<tuxbrain>
whitequark: sure and ethernet module with spi interface will not work? I have been reported with diferent opinions about this
<whitequark>
kyak: please, try using it for, maybe, a day or two, and you'll answer your question yourself
<kyak>
whitequark: i don't get your point
<whitequark>
kyak: it isn't really usable with modern sites
<whitequark>
at least it wasn't last time I've checked it
<kyak>
"modern sites"? what is it?
<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
<whitequark>
that isn't very fast and is very cpu-hungry
<whitequark>
kyak: try opening qi-hardware.com, or maybe google.com, or github.com
<wpwrak>
rjeffries: (comm with avr) SPI with the ben the master and the avr the slave should be convenient
<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
<whitequark>
kyak: links cannot be used for day-to-day tasks
<whitequark>
it is only good to say "hey, our device can load web-pages", but hardly more
<kyak>
it depends on which tasks you do day-to-day
<kyak>
i use elinks regularly to access gmail without any problems
<kyak>
have to go now
<rjeffries>
wpwrak how much new Ben software is needed to achieve bi-direcetional data transfer between Ben NN and AVR (read Arduino)
<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.
<rjeffries>
wpwrak ubderstood regards need for a Ben to AVR protocol
<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
<rjeffries>
but to get real, why not use a cheap netbook as master and simply communicate to Arduino via USB.
<rjeffries>
a low end netbook running linux is prolly $200 new oe slightly used
<wpwrak>
sure, you can do that. i would try to cut out the man in the middle, i.e., the avr :)
<wpwrak>
hates statistical distributions that don't make sense
<tuxbrain>
wpwrak: what distribution are you talking about?
<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.
<tuxbrain>
wpwrak: really, don't use my name followed by black magic power words like frequency , direct access or signal... it really scares me.
<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
<wpwrak>
grmbl. two set of values, an unexplainable 150 us apart
<wpwrak>
i understood the first and the second, but you threw me with the catalan ;-)
<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
<tuxbrain>
or maybe a recieipt to do some cake but well , it sounds like vudu cake
<tuxbrain>
150us seems a lot of time on transmision scale, isn't it? (OMG I'm starting to intuit your tech mambo jambo nonsense)
<wpwrak>
the drugs are starting to work ;-)
<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
<wpwrak>
tuxbrain: a good way to look at it is, after gunzip'ing, with gnuplot  plot "<sort -n tx-100-counts" with lines
<wpwrak>
to zoom in,  set yrange [30000:33000]  (or zoom manually)
<wpwrak>
yaxis is the number of counts between send trigger and interrupt. one count is about 100 ns
<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
<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
<wpwrak>
this is a ben with everything that could get in the way dead. including interrupts. actually, let me verify that ...
<wpwrak>
yeah. everything switched off
<tuxbrain>
well if the input is the same something should be altering the values.... in theory same input sould give you output ... extrange...
<wpwrak>
it gets worse: plot "tx-100-counts" with dots
<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.
<tuxbrain>
yes I even saw that with the numbers directly.... I think something is happen on the ben on x period
<tuxbrain>
something is not off
<wpwrak>
yet i do set ICMSR to 0xffffffff
<tuxbrain>
or the sistem or the CPU is doing something we don't know on that moment cyclic
<wpwrak>
hmm. maybe the frame buffer. switching it off, too ...
<tuxbrain>
I suppose this will complicate the creation of software on the ben side for communications isn't it?
<wpwrak>
in the end, my program will look worse than gmenu2x ;-)
<tuxbrain>
ha!
<wpwrak>
(complicate) no, not at all. this is only for production testing.
<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....
<wpwrak>
naw, the system is only unresponsive for about 3-4 ms
<wpwrak>
of course, 10000 times in a row ;)
<tuxbrain>
wow how long is the test?
<wpwrak>
4 ms * 10k = ~40 s. of course, 10000 is a bit excessive. once things work properly, a lot less should do.
<wpwrak>
yes ! that did the trick ;-)
<tuxbrain>
was the frambuffer?
<wpwrak>
yup. tuned the lcd clock off and now i get ...
<wpwrak>
that's with different trim values. t0 is the lowest extra capacitance -> clock runs fastest, t15 the highest -> slowest
<wpwrak>
and this is indeed what we see :-)
<wpwrak>
distribution looks vaguely gaussian, which is also good
<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 :)
<tuxbrain>
gn8
<wpwrak>
(trim) the load capacitors of the crystal are programmable
<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.
<wpwrak>
hmm. something in the ben doesn't like it if i turn off the lcd clock. hangs after a while :-(
<wpwrak>
tuxbrain: you may get your wish for a "don't touch while testing" mode after all :)