<wolfspraul> wpwrak_: ok I cleaned it up a bit... http://en.qi-hardware.com/wiki/Community_news_2010-12-01
<wolfspraul> xiangfu: there is an error report for fped at Debian, see http://qa.debian.org/developer.php?login=xiangfu%40sharism.cc
<xiangfu> wolfspraul: don't understand the error. will ask debian people. in #debian-mentor
<wolfspraul> good
<xiangfu> form the #debian-mentor:
<xiangfu> <pabs> since upstream doesn't do releases, just ignore it
<xiangfu> <pabs> or poke upstream to have proper software development practices
<wolfspraul> I'm sure Werner will love that...
<qi-bot> [commit] Xiangfu Liu: update the homepage to help webpage http://qi-hw.com/p/fped/5a5bc8c
<roh> but if you put the wan if into the right zone it should just work
<roh> irgh
<kyak> xiangfu: hey! i've made a small patch for reflash_ben.sh to show a progress bar - http://downloads.qi-hardware.com/people/kyak/tmp/reflash_ben.progress.patch
<kyak> xiangfu: would be great if you could test
<xiangfu> kyak: thanks. I will test it.
<xiangfu> kyak: great. works pretty good.
<kyak> good. i'll commit then?
<xiangfu> kyak: yes.
<qi-bot> [commit] kyak: reflash_ben.sh: add progress bar http://qi-hw.com/p/openwrt-xburst/5cb8088
<kyak> i thougth the next step could be to output the spent time/ left time, but i noticed that the transfer is somwhat not continous
<kyak> i.e. it transfer 16 times, then it waits for somethinfg
<kyak> so maybe better leave it like it is.. at least now we have an impression how much is left to reflash
<xiangfu> kyak: yes. sure.
<kyak> xiangfu: do you know why it works like this? i.e. transferring 16 times, then waits
<xiangfu> kyak: i am not sure.  it's PIPO issue.
<xiangfu> (guess) only the PIPO is full or EOF, then "tee" will send message out.
<kyak> PIPO,, have to google that
<xiangfu> sorry FIFO
<xiangfu> :)
<kyak> ah
<kyak> no, it's not tee
<kyak> it's really what happens
<kyak> you can start tail -f log.txt in once console and reflash_ben.sh (previous version) in another
<kyak> you'll see this thing
<kyak> you'll see that it really waits between these series of 16 blocks
<kyak> or whatever it is
<kyak> i never really noticed it before
<kyak> before i watched this process with a progress bar
<xiangfu> I know that. only when we use script file , the log.txt will like that.
<xiangfu> so 'shell' must cache the output.
<xiangfu> need someone really understand the 'shell' can answer this question. I am not sure.
<kyak> then the script itself has a problem?
<kyak> i'll try launching it without the script.. i.e. just the nprog 2048 ${WORKING_DIR}/${ROOTFS} 0 0 -n (from usbboot console)
<xiangfu> the script file it's like: "3>> "${LOG_FILE}" 2>&1 >&3"
<kyak> i wonder what i'll see nprog 2048 ${WORKING_DIR}/${ROOTFS} 0 0 -n
<kyak> i wonder what i'll see in this case
<kyak> if it will be a continous output
<kyak> which i doubt
<kyak> i know how it was before in script file.. i spend pretty much time trying to figure out that "3>> "${LOG_FILE}" 2>&1 >&3" thing
<xiangfu> kyak, direct run "usbboot ...". the output will continue.
<kyak> then the script has a bug
<kyak> it's ok that the script writes to the log file after some caching.. but things going to stdout must be instant
<xiangfu> kyak: there is some code "usleep(100);, sleep(1)" in usbboot.  is that the problem ??
<kyak> xiangfu: i'm not sure.. i can't test the usbboot right now -\
<kyak> but the delay is more than 1 second
<kyak> i suspect that usbboot might be delaying it's output
<kyak> or waiting for something
<kyak> but it is needed to be tested outside th escript
<xiangfu> when direct run "usbboot". the output just fine. no delay at all. ( I always direct run "usbboot")
<kyak> oh ok..
<kyak> it's hard to judge though, because the lines are the same all the time
<kyak> at some point it may appear that the screen is not changing at all
<kyak> in my test script, there is no delay
<kyak> that's why my assumption is that it is coming from usbboot
<kyak> basically the test script is the same, only there is another script that simualtes usbboot output
<xiangfu> can you send the test script files to me.
<kyak> one sec
<kyak> the reflash.sh simualtes usboot output
<kyak> you run progress.sh
<kyak> if there is not delay in reflash.sh output, there is no delay in progress.sh indication
<kyak> you can customize the delay and number of blocks to "write" in reflash.sh
<xiangfu> kyak: strange. don't know why. :(
<kyak> xiangfu: btw, the usbboot - is it written by qi, or is it from ingenic?
<kyak> oh, great.. at least we have a full control over all of those things
<kyak> (i still rememeber triggerhappy) :)
<wpwrak_> xiangfu, wolfspraul: (fped error) so .. no action required ? :)
<wpwrak_> wolfspraul: (wpan antenna) btw, here's a picture of my antenna farm: http://downloads.qi-hardware.com/people/werner/tmp/antfarm.jpg
<wpwrak_> wolfspraul, kristianpaul: (community news) the 150 MHz scope - is it the only one the university has ? if not or uncertain, maybe write "to a 150 MHz scope"
<wpwrak_> wolfspraul: (mm1) how about mentioning that the case parts were laser-cut ?
<wpwrak_> wolfspraul: (xue) maybe add more emphasis on xue looking for reviewers ? right now, it sounds a bit like something that'll happen anyway, without any reader needing to get involved. e.g., something like "Andr\'es Calder\'on has issued a call for reviewers."
<wolfspraul> ha :-)
<wpwrak_> wolfspraul: in fact, maybe put the CMOS sensor and the call for review as two items. the CMOS sensor also has the "choice" element, right ? or has this been covered before ? So "The Xue project has chosen the .... . In a leap of faith, ... a firm order of 30 sensors."
<wpwrak_> hmm, too bad that jlime didn't make it into this news batch
<wolfspraul> don't know what exactly the news is there, someone just needs to write it up
<wpwrak_> (jlime) i think it's "almost done", but with a few loose ends. not sure about rafa's schedule (or anyone else's for that matter)
<wpwrak_> ah ... maybe "upcoming events": the MM1 workshop at CCC !
<wpwrak_> now. the moment of truth. yesterday, after the thunderstorm, my antenna tests all of a sudden started to change. could be something in the test setup or could be just bad luck with all the antennas i tested at the end (three of them) having the same flaw causing an unusual profile.
<wpwrak_> the tree that drop to ~ -31.5 dB around 2440 MHz. that's not a normal curve.
<wpwrak_> grmbl. one the antennas that tested okay before now also acts weird :-(
<qi-bot> [commit] Xiangfu Liu: move ks7010 firmware to it's package http://qi-hw.com/p/openwrt-xburst/0403a6a
<qi-bot> [commit] Xiangfu Liu: move those example file to a new package: nanonote-example-files http://qi-hw.com/p/openwrt-xburst/4e3b2db
<qi-bot> [commit] Xiangfu Liu: new package, nanonote example files package http://qi-hw.com/p/openwrt-packages/ca85c07
<wpwrak_> intersting ... power-cycle all devices, reconnect antenna. voila, signal is some 15 dB stronger than before. WFT ?!? :-(
<wpwrak_> it does look a lot "cleaner", though. i wonder what happened before.
<qi-bot> [commit] Mirko Vogt: disable fbterm and lynx, since they do not compile... latter one should be easy to fix (missing iconv.h) http://qi-hw.com/p/openwrt-xburst/d170cb7
<kristianpaul> wpwrak_: (scope) no, i also used some multimeters, PSU
<kristianpaul> wpwrak_: they also had an spectrumanalizer but i dint used at last
<kyak> mirko: they DO compile
<kyak> they require locale to be enabled
<kyak> therefore patch for fbterm was removed
<kyak> you might be missing one of the commits to openwrt-xburst
<kyak> 1b577b72608d4cd16de089a5d8eee419cf9ab4b2 this one, to be specific
<kristianpaul> wpwrak_: (ants) weird changed indeed, your finding could be interesting for nokia ;)
<mirko> kyak: hmm, did i miss to update the qi-packages repo first? (thinking...)
<kristianpaul> actually it looks like more the oposite signal
<kristianpaul> "oposite" or english equivalent
<kyak> mirko: well, if both openwrt-packages and openwrt-xburst are updated to the latest master, they compile
<mirko> it is
<mirko> updated and started the full build yesterday
<mirko> updated both repos to latest HEAD, re-enabled them and will test again
<kyak> and your feeds.conf are using the latest version of qi-packages?
<mirko> yes
<kyak> ok then.. pretty strange though because xiangfu also didn't complain
<kyak> mirko: are you building from scratch?
<mirko> yes
<wpwrak_> kristianpaul: (nokia) hmm, i think they know RF a lot better than in could every hope to ;-)
<kristianpaul> wpwrak_: sure just kidding
<DocScrutinizer> hmm
<qi-bot> [commit] carlos: Adding PS2, capacitive keyboard examples http://qi-hw.com/p/nn-usb-fpga/62d0edf
<qi-bot> [commit] Werner Almesberger: atusb: use 0402 as the preferred component size and replace bad TVS http://qi-hw.com/p/ben-wpan/23c3726
<qi-bot> [commit] Werner Almesberger: usrp/README: change threshold to avoid making section reference look like a typo http://qi-hw.com/p/ben-wpan/fea4ee5
<qi-bot> [commit] Werner Almesberger: usrp: try to bring back sanity to pre- and post-processing of FFT data http://qi-hw.com/p/ben-wpan/40d1234
<qi-bot> [commit] Werner Almesberger: ants/cam: update for latest workpiece http://qi-hw.com/p/ben-wpan/04972bb
<qi-bot> [commit] Werner Almesberger: usrp: update filtering and display for uncorrupted measurement setup http://qi-hw.com/p/ben-wpan/b3c0b4b
<qi-bot> [commit] Werner Almesberger: usrp/doall: usage and allow passing of arguments to evscan as well http://qi-hw.com/p/ben-wpan/e52b92f
<qi-bot> [commit] Werner Almesberger: usrp/range: more useful diagnostic output and harden against underflows http://qi-hw.com/p/ben-wpan/8ea1715
<qi-bot> [commit] Werner Almesberger: atusb: updated footprint assignment http://qi-hw.com/p/ben-wpan/9ad0609
<qi-bot> [commit] Werner Almesberger: atusb/cam: modernize, and change setup for current workpiece http://qi-hw.com/p/ben-wpan/e137bc4
<qi-bot> [commit] Werner Almesberger: atusb: remove two unnecessary test points http://qi-hw.com/p/ben-wpan/521dab8
<wpwrak_> wolfspraul: you did it ! congratulations !!
<wolfspraul> the news? yeah
<wolfspraul> done
<wolfspraul> I could have mentioned the Milkymist One RC2 production, forgot... but also no tangible enough results yet
<wpwrak_> (mm1) you could have mentioned the upcoming workshop
<wpwrak_> (i wrote this before. not sure if you saw it.)
<wolfspraul> I don't like 'upcoming' stuff
<wolfspraul> so I don't add it :-) it's a wiki...
<wolfspraul> a few times I thought about adding a whole section at the bottom (or other place), called 'announcements', or 'plans', or 'upcoming' or whatever
<wolfspraul> but then I can never convince myself to actually write something there
<wpwrak_> yeah, but people many still want to know about the workshop :)
<wpwrak_> unlike the typical roadmap item, it's something with a pretty definite schedule :)
<wolfspraul> yes I understand, my total refusal to talk about upcoming things is also not good
<wolfspraul> otherwise you always find out about things too late
<wolfspraul> good point
<wolfspraul> maybe if it's a fixed date, it should be mentioned
<wpwrak_> more importantly, if you don't know it before, you'll miss it
<wolfspraul> sure
<wolfspraul> I'm not a news person, in general I am very reluctant about 'upcoming' stuff but of course we should have better criteria than that for what is 'good' upcoming stuff and what not.
<wolfspraul> maybe if it has a fixed date in the calendar, that's a very good indicator it should be mentioned
<wpwrak_> with a product announcement, it's okay if you learn about it after the fact. well, unless you plan on spending the night before the launch waiting in the line outside the shop :)
<wolfspraul> and if nobody is willing to put a date next to whatever is announced or upcoming, then maybe it shouldn't be in
<wpwrak_> hehe :)
<wolfspraul> yes I definitely understand the power of announcements, but that's why I am reluctant
<wolfspraul> it adds an extra burden
<wolfspraul> anyway, I like the 'fixed date' criteria
<wolfspraul> I'll keep it in mind... thanks!
<wpwrak_> i think there aren't that many events that need announcing. stuff like public talks and such.
<wpwrak_> hmm, let's make it "fixed date" plus "you have to know about it before to make the most out of it"
<wpwrak_> then you don't have to worry about more-or-less-fixed product launch dates and such (well, unless you want to :)
<wpwrak_> or perhaps two levels: the ones with a fixed expiration date, should always go in, the ones with a date that can be missed are optional
<wpwrak_> regarding the news, if you intend this as a channel also to keep the press updated, particularly events like the workshop are important. otherwise, they may miss it, and then it doesn't get covered in the probably widely read report on the CCC event.
<wpwrak_> hmm. seems that i need to power cycle the usrp every now and then, or it starts measuring junk :-(
<kristianpaul> hmm?
<wpwrak_> wow ! it's the bloody ground vias !
<kristianpaul> good, how do you find it?
<wpwrak_> kristianpaul: looked for texts on f-antennas to see if i had any flaws in my logic. then i found one where they said the vias had to be 50 mil apart. mine are 200 mil. reworked one of the antennas, measured it. lo and behold ...
<wpwrak_> now .. rework of the other nine boards ... i'll skip the three with a negative size change. they were just the control group.
<viric> Hep
<viric> hummm qucs does not build with gcc 4.5.1
<viric> spfile.cpp:405:21: error: call of overloaded 'conj(nr_complex_t)' is ambiguous
<viric> annoying
<kristianpaul> be carefull lekernel could heard you ;)
<viric> would that help? :)
<kristianpaul> no actually
<kristianpaul> try askign #gcc
<viric> kristianpaul: I imagine it's a qucs bug, not a gcc bug :)
<kristianpaul> ahh i tought
<kristianpaul> nv then
<wpwrak_> that sort of thing is actually quite common with c++. the language seems to have an incredibly fast bit-rot.
<kristianpaul> Now is the time to GMU
<kristianpaul> indeed font is TOO small
<qi-bot> [commit] Xiangfu Liu: automatic create /dev/rtc http://qi-hw.com/p/openwrt-xburst/f104603
<kristianpaul> tuxbrain: hi
<kristianpaul> tuxbrain: are you aware of skins and got setting for gmu?
<kristianpaul> ahh moc is not in owrt
<kristianpaul> mpd is there but i requires a fronted anyway
<kristianpaul> anyway..
<wolfspraul> what is moc?
<kristianpaul> and ncurses music player
<kristianpaul> i use it is fast and dint get freeze like others
<kristianpaul> btw in the meant time kexec can replace uboot, how hard is get a silent uboot boot, i wonder if all those prints are also tooo infomartives and delay some  bootime..
<kristianpaul> i a tought
<kristianpaul> is just*
<wpwrak_> uboot is fairly silent. are you sure you don't mean kernel messages ?
<wpwrak_> if i remember right, you can suppress them with the boot parameter "quiet"
<kristianpaul> ahh
<kristianpaul> no
<kristianpaul> before load kernel
<kristianpaul> when it is looking for /boot/uImage
<wpwrak_> ah, uSD. haven't tried that yet :)
<kristianpaul> no no
<kristianpaul> even from flash
<kristianpaul> is same tought
<wpwrak_> wolfspraul: btw, you once mentioned that you got some breakout cables made as a "street job". did this actually happen or was it just an idea that's still awaiting implementation ?
<kristianpaul> well long dat i'm off bed
<kristianpaul> bye
<kristianpaul> s/dat/day
<wolfspraul> kristianpaul: what is the source url for moc?
<wolfspraul> [cables] yes sure I made 10
<wolfspraul> will give them away here and there when there is an opportunity
<wolfspraul> fuse is there, inductor forgotten :-)
<kristianpaul> http://moc.daper.net/
<wpwrak_> wolfspraul: kewl ! you should post about them. even more news :-)
<kristianpaul> uSD to gpio cables?
<kristianpaul> already there!
<kristianpaul> xiangfu: http://pastebin.com/DTbgiJi0
<wpwrak_> wolfspraul: and maybe something distributors might be interested in as well ... at least tuxbrain sounded very excited about this back then
<kristianpaul> cached http://ur1.ca/
<kristianpaul> zzzZ
<wpwrak_> kristianpaul: let's see how long we can keep you awake ;-)