<brantar> roh: ok, the schematic is done
<brantar> well, what do u guys think?
<roh> brantar looks fine
<brantar> roh: so its a go ahead to buy the converter?
<brantar> roh: what is the best way to connect the usb cable to the reader without getting a shot?
<brantar> roh: *short
<roh> solderin iron
<brantar> roh: ok, should i slide the convertor over the reader?  if not, how do i connect it to the reader?
<brantar> sorry for the seemingly mindless questions, ive never done any electronics before... im only experiencced in the prebuilt side of things :D
<roh> ?
<brantar> roh: should i nevermind, i think i just answered my previous question.
<brantar> Well thanks for the help everyone, its time for bed here.  If you want to follow along on my project ill be making the webpage for my progress @   brantar.com/rfid
<brantar> ill be sure to update with a few pictures/videos of how i made it and links to the stuff you need to make it yourself
<nitin_gupta> for how long a fully charged battery can make NN power on
<wolfspraul> emeb|mac: you there? we have the schematics histories stuff up live and running :-) http://projects.qi-hardware.com/schhist
<nitin_gupta> hi xiangfu
<nitin_gupta> can you tell me that hwo long fully charged battery can sustain NN power on ?
<kyak> nitin_gupta: it depends on tasks Ben is doing, but i can say that it definitely can idle through the night
<kyak> i also remember it ran out of battery after around 2.5 hours of mplayer, with few idling breaks
<nitin_gupta> if Ben is runnig a simple C based application then what will be the duration
<qi-bot> [commit] Wolfgang Spraul: Starting cleanup, first remove plotted schematics. http://qi-hw.com/p/mmone-jtag-serial-cable/edb1b9e
<nitin_gupta> any file browser aplication is there on NN ?
<emeb|mac> wolfspraul: yes, I'm here. Been following the schematic history developments - very nice!
<wolfspraul> emeb|mac: cool
<wolfspraul> another big thing I hope will develop over the next few months is boom, our bom to shopping list system :-)
<wolfspraul> it's all a big construction site right now but I think it will become a very important piece of technology for us
<wolfspraul> sourcing is a huge problem, very tedious, lots of pitfalls, and a smart system with good usage of online apis and databases can go wonders to go from a simple bom in KiCad to full shopping lists at multiple distributors/manufacturers
<kyak> wolfspraul: will it be open source? :)
<wolfspraul> kyak: of course. the sources are all werner's he is normally using gpl v2 or v3? don't know. actually the eda-tools project doesn't have AUTHORS or COPYING yet, but it will... big construction site right now. so: gpl of course.
<kyak> wolfspraul: good, sound like a very useful project
<kyak> how do you think guys, maybe we should disable RNDIS by default (CONFIG_USB_ETH_RNDIS=n in target/linux/xburst/qi_lb60/config-2.6.32). Windows users won't be able to connect to Ben with RNDIS enabled. With CONFIG_USB_ETH_RNDIS=n they at least get chance to use proprietary CDC/ECM driver for Windows
<kyak> yes, RNDIS from 2.6.32 is not working with Windows RNDIS driver
<kyak> not that i've seen a lot of Windows users here.. but, proprietary CDC/ECM is better than nothing (i.e., RNDIS)
<wolfspraul> what do you mean with proprietary driver? you mean on the Windows side?
<kyak> of course
<wolfspraul> if RNDIS is broken in 2.6.32, at some point we'll definitely uptick the kernel
<wolfspraul> but as a quick fix, sure why not. I have no problem with it.
<kyak> you see, the problem is that RNDIS might be fixed in some future kernel, but then it breaks again eventually
<kyak> i don't think someone is interested in fixing it
<kyak> so might be better to disable it now and for all?
<wolfspraul> I have no objections, if nobody has just do it :-)
<kyak> ok, i remember discussing it with xiangfu, i think he also had no objections
<kyak> hm,.. i remember i have to git push to openwrt-xburst in a weird way...
<kyak> now to search some logs :)
<qi-bot> [commit] kyak: Disable RNDIS for now, it's broken (give Windows users a chance to use CDC/ECM http://qi-hw.com/p/openwrt-xburst/3683618
<wolfspraul> kyak: cool. you just answered the question on how our branch should be named: 'master' :-)
<wolfspraul> tracking_backfire should be just a tracking branch, while master should also include anything local to qi, that is not upstreamed yet
<mth> the 2.6.34 kernel for Dingoo also had RNDIS problems
<mth> I don't know about 2.6.35; we've also turned off RNDIS
<mth> the problems have been present since at least 2.6.24.3, which was the first kernel used for the Dingoo
<kyak> wolfspraul: hm, ok. .how should i do now? "git push" doesn't work
<kyak> though i renamed local branch to tracking_backfire
<kyak> i think now i need to do "git push origin local_backfire:tracking_backfire"
<kyak> oh, renamed it to local_backfire
<kyak> should i rename it to tracking_backfire to be able to push easily?
<mth> note that drivers/usb/gadget/rndis.c says "The driver for your USB chip needs to support ep0 OUT to work with RNDIS, plus all three CDC Ethernet endpoints (interrupt not optional)."
<mth> does the USB device driver provide enough endpoints?
<wolfspraul> kyak: [git] he I don't know. I don't want to mess it up more. Mirko Vogt had some good ideas for clarification.
<wolfspraul> first step, we deleted tracking_trunk
<wolfspraul> gone already
<wolfspraul> second step, he said with a name 'tracking_backfire' that branch should do just that, there should never be a commit in that branch that is not in upstream
<wolfspraul> that leaves one more name in need of creation, and it should be just ... master! I think...
<wolfspraul> unless mirko or others have some good reasons why that is not a good idea again
<kyak> that's strange.. i think there are things in tracking_backfire that are not upstream
<wolfspraul> kyak: I suggest let me talk to Mirko about it tomorrow then we clean this up more.
<kyak> like data/*
<wolfspraul> kyak: yes, right now there are
<wolfspraul> but that was mirko's point, which I think is a good point
<wolfspraul> tracking_backfire should do just that
<wolfspraul> tracking
<kyak> wolfspraul: ok, please clarify with him
<nitin_gupta> hwo to knwo that how much abttery is charged ?
<qi-bot> [commit] kyak: ubi-utils is replaced by mtd-utils http://qi-hw.com/p/openwrt-xburst/0e77c74
<nitin_gupta> do we have some file browser/explorer in NN
<mth> nitin_gupta: cat /sys/class/power_supply/battery/capacity
<mth> for file management, I think mc is available, but not sure
<mth> there is also something built in to gmenu2x, but it probably doesn't work in the old version and might still not work in the newest version
<nitin_gupta> ya mc is there
<nitin_gupta> anyother explorer ?
<nitin_gupta> how to exit from mc ?
<wolfspraul> wpwrak: when I open atusd.pro in kicad, and then click on the schematic, the entire schematic is displayed correctly.
<wolfspraul> but when I run 'eeschema atusd.sch' directly, the component libraries are not setup and I get quite a few ?? parts
<wolfspraul> I run 2010-03-14 but it's the same as on the server and the 'All Sheets' is still correct there, so I don't quite get it right now
<wolfspraul> any idea why a direct call of eeschema atusd.sch will not pickup the correct libraries?
<xiangfu> kyak:the RNDIS work fine with Win 7,
<xiangfu> have anyone try RNDIS in Win 7.
<xiangfu> just ignore my message, sorry. I remember I have tried once. but now I am not sure if it works in win7
<kyak> xiangfu: doesn't work, i have tried
<xiangfu> kyak: ok.
<wolfspraul> wpwrak: strange. when I launch eeschema first, without parameters, and then open atusd.sch, it's fine
<wolfspraul> but when I run eeschema atusd.sch on the command line, the libraries are not opened correctly
<wolfspraul> also, when I run eeschema --plot atusd.sch, the components are also missing even though what I believe the same kicad runs fine on the server
<wolfspraul> I think I will uptick to bzr2448 first, or just ignore the problem for now
<wpwrak> wolfspraul: eeschema /absolute/path/to/schem/atusd.sch   perhaps ? (or "make sch" :)
<wolfspraul> absolute path works, relative path doesn't work
<wolfspraul> maybe the bug is already fixed, I will uptick to 2448 first, that's better anyway
<wpwrak> not sure if anything has been done about this lately. command-line use generally doesn't get much attention.
<wpwrak> i'm already happy for what little works today ;-)
<wolfspraul> wpwrak: do you know where the kicad-doc and kicad-library from svn went to in launchpad/bzr ?
<wolfspraul> I can't find it...
<wpwrak> hmm, don'thave them in my tree either. and no mention in my notes where to get them from.
<wpwrak> maybe we should just move away from the default libs anyway. there's relatively little in them that's useful. having our own libs in kicad-libs/ would eliminate environmental dependencies.
<wpwrak> (the infamous cache problems)
<wolfspraul> hmm
<wolfspraul> that sounds a bit radical
<wolfspraul> wouldn't we want to contribute to better libs over time?
<wpwrak> the issue isn't so much lib quality but change control. also, there are really very few things you want from there. (R, C, INDUCTOR, maybe FILTER, switch, and such). you can probably replace them in a day.
<wpwrak> maybe logic gates. but they're getting kinda unpopular already. at least in the traditional 4-in-1 or 6-in-1 packages.
<wpwrak> already transistors tend to run into problems. i think lots of "serious" kicad users simply have their own libs. that's perhaps also why the "upstream" libs get so little attention.
<wolfspraul> well you tell me
<wolfspraul> I can easily remove this and say our 'base' KiCad has no libs
<wolfspraul> but... :-) will the various schhist projects even still run through?
<wpwrak> (little attention) well, i haven't been following kicad-users for a long time, so maybe something revolutionary happened there since. but i always kept on reading about some grand central database schemes and then little else :)
<wpwrak> at the moment they wouldn't, because we kill their cache :)
<wpwrak> so we'd have to forcibly add the replacement lib in schhist (the mechanism is already there)
<wolfspraul> argh. the entire mail-archive.com is blocked in China and my vpn is down. can you look into that mail for me and tell me the links :-)
<wolfspraul> no technical person can work in China without a VPN
<wolfspraul> totally impossible
<wolfspraul> all high quality sources are blocked
<wpwrak> bzr branch lp:~kicad-lib-committers/kicad/library
<wpwrak> bzr branch lp:~kicad-developers/kicad/doc
<wolfspraul> great!
<wpwrak> (haven't verified them)
<wolfspraul> the revisions in those repos are probably not in sync with the main one
<wolfspraul> so it's not 2448
<wolfspraul> should I just take the latest one? maybe a bit risky with the libs if they introduce a new feature
<wpwrak> no idea :) you could compare dates if you want.
<wpwrak> but i'd also hope they're compatible.
<wolfspraul> wpwrak: can you clarify AUTHORS and COPYING in http://projects.qi-hardware.com/p/eda-tools/source/tree/master ?
<wolfspraul> I have a request from the German Linux Magazin and will send them the url, but want it to be properly annotated in terms of licensed
<wolfspraul> will cc you on the mail
<wpwrak> hmm,  there could be several independent sub-projects under eda-tools. so each needs its own rules.
<qbject> Morning, wpwrak
<qbject> Hi, wolfspraul
<qbject> Hi everyone!
<wolfspraul> hey
<wolfspraul> :-)
<wolfspraul> you seem happy, good!
<qbject> I am! I had ideas last night.
<qbject> Two things, primarily. Wanted to ask you about them.
<wolfspraul> go ahead, although I may be offline very soon, it was a very long day here...
<qbject> First, I assume it would require a kernel patch, but do you think the BNN's serial connection could be use to accept keyboard input?
<kristianpaul> qbject: (serial) it can, why not :)
<qbject> Heh heh. Thought so.
<qbject> Second,
<wolfspraul> long story, the 'official' RXD is shared, but there are other TPs where you can make it happen
<wolfspraul> yeah, was just saying kristianpaul was one of the pioneers there...
<qbject> Ahh. Slick. I'll bug him about it when I'm farther along, then.
<kristianpaul> indeed (you need some extra wires)
<qbject> Second, there are some portable word processors that can be hooked up to usb and will pretend to be keyboards, so they can dump text into a text editor on pretty much any host machine. Any chance that the USB thingie on BNN can pull a similar act of disguse?
<qbject> s/disguse/disguise/d
<kristianpaul> You need read in the Linux USB Gadget features for the last one
<qbject> kristianpaul: is that on the wiki?
<kristianpaul> dont think so
<wolfspraul> qbject: I'd say it's close, but I never heard any success report.
<wolfspraul> another (similar) idea is USB sound card :-)
<wolfspraul> even for USB storage I'm not sure anybody ever actually got this working
<kristianpaul> i think fail
<kristianpaul> is on the lists
<wolfspraul> the best would be if you could just switch on the Ben, and ideally if the Ben could even simulate a hub and a whole bunch of devices after the hub :-)
<qbject> Agreed.
<kristianpaul> :D
<wolfspraul> something like this needs a really dedicated person to dig in, and then also to bring it out in clean patches, openwrt, etc. for everybody
<kristianpaul> indeed :)
<wolfspraul> given how spread thin we are already over the hundreds of things we take on, it's not very likely this will happen unless some new person steps up and just does it
<kristianpaul> USB is not so hellish once you dominate it ;)
<qbject> Noted. Not positive I'm the man for the job, but I need it to work in order to reach my goals, so I'll give it a shot.
<wolfspraul> you should try. since that most likely means you will be building kernels, you might also want to start with more recent kernels right away, maybe larsc can suggest the best starting point
<qbject> Especially since, if I can do it, I can probably do it sooner than I'll have a Ya to play with. ;-P
<wolfspraul> not sure it's still 2.6.32, maybe for something like this it's better to start in .34 or higher
<kristianpaul> go ahead recompile the kenrel and bug in the lists (i think somebody was trying same..)
<kristianpaul> zear: are you aware of some experience in digux usign the USB client and Linux Gadget thing?
<zear> kristianpaul, unfortunately, no. Maybe mth will know something. I know we use gadget for usb networking. But i don't know if we were even able to use other gadget modes
<kristianpaul> same as Ben for now then..
<zear> mass storage device mode would be sweet
<kristianpaul> yeah
<kristianpaul> qbject: you can follow that thread and try test it again to see what happens
<qbject> Thanks, kristianpaul. Will do.
<kristianpaul> wolfspraul: btw i asked carlos about SIE and he said ben firmware should be okay ;)
<kristianpaul> and seems works so far :)
<kristianpaul> i think juan64bits know more about the topic, isnt?
<kristianpaul> (topic) SIE firmware particularities
<juan64bits> yes, the ben firmware is ok for SIE
<juan64bits> but the microsd don't work with ben firmware
<juan64bits> and the i2c doesn't work
<juan64bits> if you need this funtionalitis you must install the specific  kernel
<juan64bits> for SIE
<qbject> wolfspraul: thanks again. Rest well.
<mth> qbject: there is the "HID Gadget" driver, which should allow making the NN into a USB input device for a PC
<mth> I haven't tried it myself though
<qbject> mth: Ah hah. Sounds perfect.
<mth> see Documentation/usb/gadget_hid.txt in the kernel source for more info
<qbject> mth: Good deal. Thanks.
<wpwrak> mth: (gadget) looks pretty complete :)
<kristianpaul> complete?
<wpwrak> in terms of "every thing there to do something useful with it"
<kristianpaul> mass storage device why not?, when still a problem to copy something easilly to the ben not usigns scp
<kristianpaul> s/usigns/usign
<wpwrak> the problem with mass storage is that you'd have to have exclusive access to the ben's storage. and you need a suitable file system driver on the host. in the case of ubifs, i'm not even sure if you could carry all the nand properties through the protocol.
<kristianpaul> hmm
<kristianpaul> good point
<kristianpaul> some chiness device i'm aware off uses just uSD-like in fat32 for that job
<wpwrak> alternatively, you could write somethign that reads a file system, presents it as, say, fat or ext2/3, and then translates changes back into the file system. but that's probably quite tricky :)
<kristianpaul> web interface is an option
<kristianpaul> maybe html5 already solved that..
<wpwrak> if fat32 is your native file system on your nand, then this works. but fat32 isn't nice to have on "naked" nand. but maybe you can cook up something with the lower layer of the ubi stuff.
<wpwrak> (forgot the name)
<wpwrak> html5 ? that's more a job for nfs or samba
<qbject> wpwrak: dumb new guy question: when you fire up Gadget mode, the standard OS can remain active, right? It's not like booting a Ben in its native USB mode.
<viric> I think the people behind the nanonote project may like this book (and ideas behind): "Program or be programmed". http://www.youtube.com/watch?v=kgicuytCkoY
<wpwrak> qbject: the OS would still run, you just talk to a peripheral that then translates what you do to USB communication for the host.
<wpwrak> qbject: everything else you do remains the same. e.g., you could keep on playing Doom while pretending to be a USB disk :)
<qbject> wpwrak: That's what I thought. So, if we can have ubifs NAND, and ext2 or FAT32 microSD running on the same Ben, what stops us from (out of my depth now) creating a virtual FAT32 volume for Gadget to talk to which has access to the names files on the NAND?
<qbject> Well, maybe we wouldn't want to use FAT32, but ext2
<wpwrak> you mean present what you have in UBIFS as FAT32 ?
<wpwrak> or have a "container" file that's FTA32 inside and lives on UBIFS or such, but appears - unless you do something special - just as one big file ?
<wpwrak> (special) e.g., loopback mount or such
<kristianpaul> samba dont look so bad..
<kristianpaul> or ftp =)
<wpwrak> kristianpaul: how about scp ? ;-)
<kristianpaul> ok just we convince wolfgang about ship and usd card with every Ben and problem solved
<kristianpaul> s/and/an
<qbject> wpwrak: Either. Whichever works best, though the 'container' file would, I suppose, have to be an image file equal in size to the ubifs volume we wanted to share. My point is that we already mount volumes, which abstracts the files from the filesystem.
<wpwrak> kristianpaul: partially solved - you still have the issue that only one entity (host or ben) can access the block device at the same time
<kristianpaul> i also can upgrade it
<kristianpaul> and if wikireader use that method, wel... why not
<zear> we interrupt this broadcast to advertise jlime: We just ported Heroes of Might and Magic 2, works great :)
<wpwrak> qbject: translating UBIFS (or an arbitrary file system hierarchy) to FAT32 would be an interesting challenge. i don't know if anyone has taken it yet :-)
<kristianpaul> zear: :D
<tuxbrain> zear: where is it where is it!!!!
<kristianpaul> hehe
<wpwrak> qbject: the container file approach would be easier. but it means of course that this isn't a "live" file system.
<kristianpaul> opkg install ...
<kristianpaul> isnt?
<tuxbrain> wait joining jlime channel
<wpwrak> kristianpaul: wikireader probably becomes just a block device when connected ?
<qbject> What happens when one process attempts to access a file when another process is already in the middle of reading it? Does the kernel just make the second process wait it's turn?
<kristianpaul> wpwrak: i mean usd for two things carry updates and save music, or whatever you want work on the Ben
<kristianpaul> actually it like forgot it have internatl memory
<kristianpaul> uSD is the way :)
<kristianpaul> for intechanging data and updates
<zear> you'll need the original HOMM2 datafiles
<zear> and then you have to place the right files to:
<tuxbrain> I have all the original series!! form 1 to V
<zear> /usr/share/games/fheroes/data
<zear> and
<zear> /usr/share/games/fheroes/maps
<wpwrak> zear: vade retro satana
<zear> wpwrak, ;D
<zear> In other news: Commander Keen is next to port ;)
<tuxbrain> I woul like to know how did you solve the mouse use on this game?
<zear> tuxbrain, the game features a built-in mouse emulation
<zear> it's only in 4 directions (so no vertical movement), but it's fine to navigate most of the screens
<tuxbrain> yes I know we are all here for fredoom and such but damn it is HOMM, the game that has make an sleepless zombi since I was 15
<zear> honestly i haven't been able to test it on my nanonote yet (old version of jlime, gives me black screen when i run it), but B_Lizzard says it works on his unit
<zear> but i tested it on my dingoo, so a similar experience
<qbject> Zear: Keen 1-3 or 4-6?
<kristianpaul> ok forgot the old chat and lets play :)
<zear> qbject, 1-3 + experimental support of 4 (not playable yet)
<qbject> Ah.
<zear> doesn't 4-6 emulate with dosbox?
<tuxbrain> now port a working civilization and I can close whatever open project , divorce, live as a homeless meanwhile I can have access to a plug time to time.
<zear> tuxbrain, that won't work, freeciv requires at least 50MB of free memory
<qbject> zear: Haven't tried it. Monuments of Mars runs great in dosbox, albeit without sound.
<wpwrak> tuxbrain: so you still have to stay around to lobby 64 MB into the ya
<tuxbrain> damn it
<zear> wpwrak, well, tried to port freeciv to gp2x which has 64M, but despite running though the first few screens, once it gets to in-game, after the first move it crashes
<zear> freeciv is simply too huge for handheld devices
<zear> maybe pandora will be able to run it
<tuxbrain> well I have said a working civilization , doesn't mind if had to be rebuilded from scratch or port the original civilization I or II
<wpwrak> zear: did you add swap ?
<zear> wpwrak, no swap for gp2x
<zear> it has no usb gadget, so no way to really get into it to debug it, create swap, etc
<zear> plus it's 2.4 with some really ancient libs
<wpwrak> zear: maybe it would help. depends a bit on the working set size.
<wpwrak> eek
<zear> it's a 2005 device
<zear> tuxbrain, original Civilization is too slow on dosbox in nanonote
<zear> i have tried it already
<zear> i love civilization
<tuxbrain> damn it (again)
<tuxbrain> but HOMM needs dosbox to run? or is a native port?
<tuxbrain> could civ not improve if is ported?
<qbject> zear: is there a newer dosbox port than slaanesh's port from April?
<zear> qbject, no, because slaanesh didn't release his sources
<zear> and he used a mips dynrec
<zear> so there's no better version than his
<zear> even if someone ported a vanilla dosbox, it would be many times slower due to the lacking mips dynrec
<qbject> drag. dynarecs are why nobody ever ports KeGS. :(
<zear> :P
<qbject> Or was that SheepShaver?
<qbject> Oh! It was Basilisk.
<qbject> BTW, viric, I got a lot out of Rushkoff's previous book "Life, Inc." Looking forward to his new one.
<qwebirc30164> hi
<qwebirc30164> i just bought one nanonote, and i'm looking for a microsdio wlan card for it
<qwebirc30164> would you recommend any?
<qwebirc30164> it's very difficult to find the Spectec SDW-823 microSD (SDIO) Wi-Fi card
<wpwrak> not sure if there's much else. maybe check your local shops first, then see if there's any information about using whatever you find with linux.
<qwebirc30164> i found a solution: will use a SD card from spetec
<qwebirc30164> and then a sd to micro sd adaptor i found at dealextreme
<qwebirc30164> it's probably the cheapest solution: 35$ for the sd card and 5$ for the adaptor
<wpwrak> how is it mechanically ?
<wpwrak> not much fun if all the combined weight plus lever breaks something
<wpwrak> hmm, is the artwork of HoMM2 also freely distributable (or at least legally freely downloadable) ?
<qwebirc30164> it's a flexible adaptor
<qwebirc30164> i will document it when i got it up and running
<wpwrak> qwebirc30164: (flex) oh, great. (document) you're da man ! :)
<qwebirc30164> :-P
<vbnv> I have a dell XPS motherboard and read on dells web page that it takes 667 MHz SDRAM, Is it possible that it could take a faster speed ram? It is a foxcon LS-36 Motherboard.
<vbnv> I have also read the it may be possible to put in a qx6800 vs the x6800?
<qi-bot> [commit] Xiangfu Liu: some improvements to imgv http://qi-hw.com/p/imgv/16ccc7f
<qi-bot> [commit] Xiangfu Liu: [imgv] update to 0.3.0 http://qi-hw.com/p/openwrt-packages/37c649f
<kristianpaul> okay i'll stick on this openwrt branch and last commit d2f389bd2b56e0a8b4cee566560c97a01f0f3f83
<kristianpaul> as rafa_ did with oe ;)
<kristianpaul> now i winder why this init.d/start script dint worked after copied (i forgot ln -s before make..)