<wpwrak>
tuxbrain: (i'll just dump all the trivial 8:10 card projects in there)
<wpwrak>
tuxbrain: ... and the actual blinkenlights will move to a subdirectory at some point in time
<tuxbrain>
common , man UBB will be the second product to production made fully with KiCAD :P, some respect man,  at least don't call it "trivial" in public... poor UBB :P
<kristianpaul>
wolfspraul me either
<wpwrak>
;-)))
<kristianpaul>
wolfspraul well you can already manufacture that sige-like board, it will work and in parallel way the development can be made
<kristianpaul>
i think :-)
<tuxbrain>
page done, review and if you found something wrong or in accurate, fix it dam it ,is a wiki page
<tuxbrain>
of course geniouses like wolfspraul, wpwrak, kristianpaul .... uff ok any one , report and I will try to fix it ... when ... mmm ... well I will try.:P
<steve|m>
tuxbrain: Gerver files generated from KiCAD? ;)
<tuxbrain>
wpwrak: is not true? there is a proccess in the middle?
<tuxbrain>
any unaccurated info please let me know.
<wolfspraul>
kristianpaul: oh wow, that's a lot of data. NIIICE!
<kristianpaul>
yeah i found it time a go, just was too much data for me ;)
<wpwrak>
years later ... :)
<kristianpaul>
hehe
<kristianpaul>
wolfspraul: when you see lots of N/A things get interesting for us i think
<kristianpaul>
most of then are black boxes IC, not low level black box
<kristianpaul>
zarlink is not there, so wpwrak is right..
<steve|m>
ehrm, german google wtf? http://www.google.de/#hl=de&source=hp&q=SE4165T_Datasheet.pdf
<wolfspraul>
kristianpaul: wpwrak is right about what? (wrt zarlink)
<wpwrak>
steve|m: ;-))
<wolfspraul>
the overview doesn't have much data on ics though, just high-level features. and even those may just be copy/paste from datasheets/tech specs? (in other words sometimes the fine print may take some of it back :-))
<kristianpaul>
wolfspraul: some outdated info..
<kristianpaul>
steve|m: hehe
<steve|m>
"SE4165T Datasheet Rev1p6.pdf" would be the filename according to their naming scheme.. too bad
<qi-bot>
[commit] Werner Almesberger: cameo: allow comma between parameters of "drill" (makes use in scripts easier) http://qi-hw.com/p/cae-tools/0826d5b
<kyak>
xMff: $(TOPDIR)/$(FILES_DIR) is not expanded to what i want
<kyak>
i don't really understand why $(FILES_DIR) expands to ./files.. What's the point?
<kyak>
why not expand to the absolute path?
<kyak>
xMff: could be a misunderstnading. I would like to have an expansion to e.g. feeds/packages/utils/vim/files (i.e. the files dir of the package, not the files dir in the top dir of build root)
<rjeffries>
!seem wpwrak
<wpwrak>
i only disconnect if there's some network/computer problem :)
<kyak>
yeah.. turning off your computer is so Windows 98 :)_
<larsc>
running applications on you local machine is so windows xp ;)
<rjeffries>
how about letting your computer enter sleep mode?
<kyak>
having a PC at all is so... not iPad --)
<rjeffries>
wpwrak please keep this a TOTAL SECRET yomorrow I drive 80 miles to pick up a Ben Nanonote.
<wpwrak>
whee !
<rjeffries>
whatever you do PLEASE not tell: rejon, tuxbrain, lekernel and the rest of my HUGE fan club.
<rjeffries>
s/yomorrow/tomorrow
<rjeffries>
you can tell wolfspraul, but he will think it is just a PROOF OF CONCEPT
<kyak>
why do you have to drive so far?
<rjeffries>
I have other business in Santa Barbara where I used to work. I am picking up Nanonote as well as three or so other tasks
<rjeffries>
gas is expensive these days.
<kyak>
it seems that you have some logistics background :)
<rjeffries>
next I will face the nightmare I mean "challemge" of figuring out when it is worth reflashing
<rjeffries>
kyak not really. I am the kind who knows just enough to screw things up.
<kyak>
and why is that a nightmare? it is as easy as running reflash_ben.sh
<rjeffries>
kyak I will print that comment out and frame it on my wall.
<rjeffries>
the only reason I am borrowing this Ben is to be able to check if Tuxbrain UBB PCB have good mechanical fit. ;))
<kyak>
well, it had never been harder for me than that
<wpwrak>
kyak: does is also install usbboot on the host ? :)
<rjeffries>
do you use Jlime od the qi-haredware OpenWrt or Debian or Vista? just kidding about Vista
<kyak>
wpwrak: it doesn't but it gives a note to install it if it's not found
<rjeffries>
this Ben ha sbeen flashed but I do not know when
<rjeffries>
I figure it does not even have to be turned on to see how well
<rjeffries>
a UBB fits. ;)
<wpwrak>
kyak: that it does. so it's running the script, plus diligently executing the instructions of your electronic master ;-)
<wpwrak>
rjeffries: you'll almost certainly want to reflash. and i agree that it's not hard. the script is great.
<rjeffries>
I will be checking the wiki, approaching it as a virgin, seeing if this makes sense to someone with limited intelligence but a great sense if humor
<rjeffries>
I will not ask any questions on irc, that would be CHEATING
<kyak>
wpwrak: well, if a person runs reflash_ben.sh, sees the pretty explanatory message "can't boot device - xburst-tools setup correctly? device in boot-mode? device connected?" and he can't figure out what to do next, then he just doesn't deserve owning a Ben
<rjeffries>
kyak NOW you understand why rjeffries hAS NOT PURCHASED A bEN nANONOTE. hE DOESN'T deserve TO WON THIS MILITARY GRADE ELECTRONICS
<rjeffries>
sorry for caps lock
<rjeffries>
s/won/own/
<kyak>
it looks like your keyboard has deserved to be replaced :)
<rjeffries>
no this idiot lappie has a shift lock that can be hit too easily, and pronlem is worst when a monkey is typing
<rjeffries>
keyboard is great I can't type worth beans.
<wpwrak>
xmodmap tends to get rid of undesirable modifier keys quite efficiently :)
<rjeffries>
wpwrak let me take a wild as guess...
<wpwrak>
as in  remove Lock    = Caps_Lock    :)
<rjeffries>
that might be a LINUX program, no?
<rjeffries>
just a guess... lol
<wpwrak>
and maybe  keycode 0x42 =  Control_L
<rjeffries>
but seriously
<wpwrak>
well, of course ...
<rjeffries>
it will be fun, in a perverse way, to see how someone who has not taken the Copyleft Vows manages to get by with a Ben
<rjeffries>
can Ben read a FAT formatted microSD?
<rjeffries>
I assume no, or maybe HELL NO
<tuxbrain_away>
rjeffries: yes it can
<rjeffries>
tuxbrain_away is supposed to be away I am so totally confused. ;)
<tuxbrain_away>
ubiquity
<rjeffries>
that is A Good Thing because this cool Zoom H1 writes .wav files to FAT format ,icroSD
<wpwrak>
well, since 1992, the linux kernel can read FAT. before, there were mtools. MMC/SD card support came a little later ...
<rjeffries>
If ben can read, that is a start
<rjeffries>
it just seems that reading a disk format that Bill Gates invented is so, well, morally corrupt. ;)
<rjeffries>
I am kidding guys
<tuxbrain_away>
ben can read/write/format and surelly recover fat partitions
<rjeffries>
never ever take anything I say seriouly. My wife knows that, and so should you
<wpwrak>
yeah, i have to plead guilty there ...
<wpwrak>
tuxbrain_away: (recover) there too, i'm afraid
<rjeffries>
so if I transfer .wav files into Ben, what tool will play them? Is there a soud editor, or must they be converted to .OGG
<rjeffries>
s/soud/sound
<rjeffries>
I am getting worried that I may have found a possible use case for Ben. That can't be good.
<wpwrak>
hmm, i'm getting good at milling ubbs. got one that's 11.02 mm wide. 20 microns tolerance. beat this, industry ! ;-)
<wpwrak>
tuxbrain_away: btw, any reaction so far from pulster regarding ubb ?
<dvdk>
xiangfu: then i guess you had to remove plplot, since i didn't get around to fixing it?
<xiangfu>
dvdk: not include plplot .
<dvdk>
xiangfu: well, next time :)
<xiangfu>
also I this image not include gcc-mips.
<xiangfu>
the gcc-mips ~70M. so I remove it for saving place.
<dvdk>
xiangfu: btw plplot build for me fine.  looking at your log it looks like your pango stuff in staging_dir is a little broken (pkg-config wise).  will have to try again with all the pango stuff, maybe i will finally manage to break it, just like you :)
<dvdk>
(i.e. plplot only attempts to link pango if it finds it, with my minimal .config, there was no pango anyways)
<dvdk>
xiangfu: moving the image  to 'testing' stage for everyone to try it before release?  or again "direct" release  this time?
<kyak>
xiangfu: can you include the "supertux" in the image by any chance? :)
<kyak>
dvdk: btw, don't bother me seeking you :) i'm just randomly testing the seen feature of the bot. What did he tell you?
<dvdk>
told me 'kyak was looking for you via /msg at 9:00' or something
<dvdk>
was still sleeping at 9
<dvdk>
:)
<kyak>
cool :)
<kyak>
xiangfu: i agree to throw away the gcc-mips. Whoever needs it, can install it via opkg.. It's too huge
<dvdk>
kyak: if supertx didn't make it in time, what about hosting the ipk it peple.qi-hardware or something, and dropping a link on irc/ml
<dvdk>
s/it/at
<dvdk>
kyak: this way you get some exposition/testing already
<wolfspraul>
dvdk: no way - many more than 3 are following what you do. as for building, sure, it's just a few people and imo that's fine. I will not overly encourage (or beg) anyone to start building.
<wolfspraul>
we have a buildhost, if that helps, but I think only 3-4 people have accounts on the buildhost right now.
<wolfspraul>
I think as config.full_system grows, less people will build it from scratch, and I want to work towards upgrades via opkg, instead of full-image reflashing.
<dvdk>
wolfspraul: yeah, was takling about people who attempt to build.  always posting .ipks because i had the feeling the barrier to building was too high.
<dvdk>
wolfspraul: opkg-based updates will be great.  hopefully we have enough place on flash for .ipk download+install
<dvdk>
wolfspraul: the problem with building currently is, i have to remember doing a 'git pull && make world' the evening before i want to try building newly ported packages :)
<dvdk>
so compilation finishes in time :)
<wolfspraul>
xiangfu is also looking into werner's pivot_root suggestion to have multiple rootfs'es in one large (2 gb in our case) partition
<wolfspraul>
I saw your comments about the 512mb one getting full, and I also want to make progress on jlime dual-booting.
<dvdk>
wolfspraul: had a look at the qilb60 schematics+flash datasheet.  maybe one could improve the flash driver to cut down on UBI attach time
<dvdk>
UBI attach is pretty special in the read pattern that is required
<wolfspraul>
dvdk: interesting. you think significant speed improvements are possible?
<dvdk>
wolfspraul: maximum factor of 2, less if the kernel driver is already smartly implemented.  > factor of 2 only, if the kernel driver is much dumber than i expect.  need to take a closer look.
<wolfspraul>
hmm, very interesting - thanks a lot even just for the idea!
<wolfspraul>
bootup time is very important indeed
<wolfspraul>
imo
<wolfspraul>
and the big problem about bootup time is - once it's out of control you can never bring it down again
<wolfspraul>
I'm very happy that the openwrt images we have right now keep around 15 seconds, for 1 year already
<wolfspraul>
it oscillated between 11 and 18 I think :-)
<wolfspraul>
I am watching this number like an eagle...
<dvdk>
wolfspraul: more speed gain would be possible by artifically increasing the erase block size, since UBI attach is proportional to number of erase blocks.
<wolfspraul>
btw, xiangfu did a quick test with the linux kernel image inside ubifs, and it confirmed larsc suspicion - 4 seconds more!
<dvdk>
yeah, read that yesterday, that made me look into the flash datasheets.
<wolfspraul>
so if we increase the partition size from 512 mb to 2 gb, we may easily bump up even the openwrt boot time to 30 seconds or so - not good
<wolfspraul>
sure, if bigger erase blocks help and the downside is acceptable - why not
<dvdk>
in fact, this is not a problem with ubifs.  the problem is with the UBI layer that reads a short header of every erase block.
<dvdk>
one optimisation would be "dual plane reads" that can read two headers with one mmc command.  the other optimisation is to just pretend erase blocks are bigger by treating subsequent number of erase blocks as one.
<dvdk>
need to look into the details, so take everything w/ a grain of salt.
<xiangfu>
dvdk: not I am include the 'supertux' , generate the image again. include one package. compile rootfs. needs ~1 hours.
<xiangfu>
s/not/now
<dvdk>
btw and using ubi layer from boot loader looks like a bad idea.  twice the penalty, once in boot-loader, later in kernel.
<dvdk>
kyak^
<wolfspraul>
dvdk: I was hoping that the u-boot ubifs/ubi implementation would focus on just getting the binary out, without need for full scans
<wolfspraul>
either that is not the case because nobody optimized for that, or because it is technically impossible (I still cannot believe that but I won't dig into the sources...)
<wolfspraul>
are the blocks totally randomized with no map whatsoever?
<dvdk>
wolfspraul: maybe some optimization is possible, dunno.
<mth>
what about a separate small ubifs partition that contains only kernel images?
<wolfspraul>
sure, possible
<dvdk>
mth: that won't help, since the time is involved at the UBI attach, which is required to even know wher that "partition" resides.
<wolfspraul>
the problem is to keep changes as rare as possible, because it takes so much time to trickle into different distributions, openwrt, jlime, debian, etc.
<mth>
dvdk: I mean a NAND partition, not a partition on a block device
<wolfspraul>
dvdk: then 2 separate partitions, not 2 ubifs 'volumes' inside the same partition
<dvdk>
mth: you mean a mtd partition?  this is how it is done currently, isn't it (albeit without a file-system on top).
<dvdk>
wolfspraul (keep changes rare): i think any tuning could be (should be) done as part of the qilb60-specific kernel drivers.
<dvdk>
mth: wolfspraul: note that much of what i wrot is still wild guessing.  i'll know more by next week.
<kyak>
xiangfu: thanks!
<mth>
I'm surprised that building the map takes so long though
<wolfspraul>
mth: if the blocks are really anywhere (totally randomized), with zero maps or hints/guides/whatever, then what can you do
<wolfspraul>
I cannot believe that really, but who knows. ubifs is supposedly a fairly sophisticated nand file system.
<mth>
in OpenDingux we scan the file system on the NAND (non-ubi) and while I haven't benchmarked it I doubt it takes more than 1 second for 4GB
<dvdk>
wolfspraul: ubifs is sophisticated and mounts quickly.  the problemn is the ubi layer below that.
<dvdk>
mth: maybe you're lucky and your erase-blocks are just larger?
<mth>
erase size is 512K
<wolfspraul>
I can see how central maps/tables cause big problems with wear-leveling. so maybe they have no such thing at all and blocks are 100% random? :-)
<wolfspraul>
I don't know, just wildly guessing.
<mth>
so 8192 blocks
<wolfspraul>
if there is not a lot of write activity, larger erase sizes shouldn't matter much, right?
<mth>
we only read the first OOB area of each block though, I don't know if that's the same for UBI
<wolfspraul>
it only means that a write will cause a bigger amount of reshuffling to preserve the rest of the (larger) eraseblock
<dvdk>
mth: 8192*64 bytes to be transfaired, afair.  not even half a megabyte, but what about the latencies of the flash accesses?
<mth>
oobsize is 128 bytes for this flash
<mth>
I very naievely implemented an FTL driver for the native (eCOS/II based) OS of the Dingoo
<dvdk>
mth: do you use any kind of command queueing optimization for the 8192 transfers?
<mth>
since it was fast enough, I never benchmarked or optimized it
<mth>
no, just mtd->read_oob() inside a loop
<dvdk>
maybe the linux driver transfers full pages instead just the header?  i mean the full page is loaded to flash-internal buffers anyway, so we're suffering from a MMC bus bottleneck?
<dvdk>
btw for the NN erase blocks are also 512K iirc
<dvdk>
just looking at the timing, full page transfers would approximately explain the long ubi attach time (4096 blocks a 4096 bytes in 30 seconds)
<mth>
the UBI scan routine mentions it reads EC and VID headers, but I have no idea what those are
<wolfspraul>
dvdk: I think it takes about 8 seconds to attach the entire 2 gb
<wolfspraul>
not 30
<mth>
erase counter and volume ID?
<dvdk>
wolfspraul: didn't you write 30s yourself?
<dvdk>
"increase the partition size from 512 mb to 2
<dvdk>
                  gb, we may easily bump up even the openwrt boot time to
<dvdk>
                  30 seconds or so"
<mth>
note: the FTL driver was for Linux, but designed to be compatible with the native OS
<dvdk>
that's not purely the attach time?
<wolfspraul>
I meant if we move the Linux kernel into the ubifs, and increase the ubifs from 512mb to 2gb, I have a feeling without further improvements the total openwrt boottime will go up from 16 sec or so where it is now to > 30 sec.
<wolfspraul>
before your ideas, I didn't have genuine ubi/ubifs performance improvements on the radar
<wolfspraul>
I was just trying to measure how long it takes to mount a 2gb partition, and to move the Linux kernel inside a partition (if that is even a benefit, we can think about it...)
<dvdk>
I'll look into the datasheets and sources and do some math to see how much can be gained, then put the results into a wiki-page.  but not before saturday.
<wolfspraul>
no rush, this would be very valuable in the long run, so I'm very much looking forward to it
<kyak>
dvdk: i see you are pushing towards the 2Gb rootfs. But have you thought about having a safe place across between reflashes?
<dvdk>
kyak: mmc card :)
<dvdk>
kyak: but i only need 128MB of safe place :)
<kyak>
my mmc card is 256Mb and it has Jlime on it. moreover, the mmc card drops off easily and i don't like it
<kyak>
i need safe place for video/music/pictures
<dvdk>
hmm.
<xiangfu>
dvdk: quick question. when I run 'gforth' in new release. it give me "can't load library 'libffi.so.4'"
<dvdk>
scratches his had
<xiangfu>
dvdk: I found the 'package' libffi have update to '5'
<dvdk>
xiangfu: but it updated *after* you compiled gforth?  how's that possible?
<xiangfu>
dvdk: by make symlink: libffi.so.4 -> libffi.so.5.0.10 . gforth works fine.
<dvdk>
xiangfu: can we somehow push that change into the release image?
<kyak>
seems that libffi was recompiled after gforth has been built
<dvdk>
but libffi is referenced by gforth's dependency line, is it not (or not correctly?)
<xiangfu>
compile by crontab jobs. not manually re-compile .
<kyak>
in theory, make should've rebuilt gforth after its dependency (i.e. libffi had been rebuilt)
<kyak>
but who knows &
<dvdk>
hopefully the libffi problem doesn't break other script languages lua/python/octave etc.
<kyak>
dvdk: btw, i'm reflashing pretty often. Sometimes several times a day.. and i'm really happy with these 1730Mb of safe space
<dvdk>
kyak: 1500Mb nowadays, isn't it?
<kyak>
still 1730 for me.. i like 256 mb rootfs :)
<dvdk>
hasn't even formatted the unused part
<xiangfu>
lua, python, octave works fine. as least 'prompt is come up'
<dvdk>
xiangfu: ok, so what are you going to do about the problem?
<dvdk>
is going to check libffi dependency in gforth Makefile
<xiangfu>
there are two folder under build_dir/.../Â Â libffi-3.0.9/Â Â Â Â Â Â libffi-sable-3325/
<xiangfu>
for me. temporary work around. create a symlink when first boot. :)Â Â really don't want re-compile the whole openwrt.
<xiangfu>
it's needs ~30 hours.
<kyak>
you could just rebuild gforth, won't take that long..
<kyak>
after dvdk adds this dependency :)
<dvdk>
can we patch in the symlink without a rebuild, then just re-create the ubifs?
<dvdk>
kyak: afair, i added the dependency
<dvdk>
:/
<kyak>
  TITLE:=GForth
<kyak>
  DEPENDS:= +libltdl
<dvdk>
:(
<dvdk>
shakes his had in disbelief
<xiangfu>
dvdk: manually we can. by using openwrt command "make target/install" it needs 1 hours in buildhost.
<dvdk>
at least now i now how important this dependency stuff actually is:)
<xiangfu>
openwrt try to rebuild  a lot of package even there is no change. :(
<kyak>
hm, i never noticed such behaviour
<dvdk>
xiangfu: patching the symlink would be sufficient for now, since libffi isn't actively used in gforth currently.
<kyak>
dvdk: did you actually took it seriou swhen we discussed about injecting bugs in the morning? ;)
<xiangfu>
;-)
<dvdk>
xiangfu: but i'd like that patch to be part of the ubifs image, not everybody is going to understand how to patch it himself
<xiangfu>
dvdk: sure. easy add then to openwrt-package.git/nanonote-files/scripts-files/etc/ubi-default/
<dvdk>
xiangfu: thanks a lot.  now i can play "brainless" chess out-of-the-box.
<xiangfu>
dvdk: this folder "etc/uci-defaults" will only run once at first boot.
<kyak>
is ready to switch to 512 Mb rootfs just to test the image when it's released
<dvdk>
xiangfu: didn't know about that, adding it there is ok, sure.
<dvdk>
kyak: but where to but your safe data before reflashing? :)
<kyak>
dvdk: this time, i'm ready to spend the time and back it up
<rjeffries>
in smuxi irc timestamps are my local time. jsut sayin'
<rjeffries>
s/jsut/just
<zrafa>
(Xiangfu Liu: increase the data partition size to 1480MB) new layout? :)
<zrafa>
kyak: or was it already that size before and he forgot to commit?
<kyak>
zrafa: he's just adjusting the leftover size
<kyak>
i.e. boot and rootfs haven't changed
<zrafa>
kyak: ah.. okey, so only new size for data partition then
<wpwrak>
argh ! i just realized that i can probably make atben a lot smaller
<kristianpaul>
wpwrak: how come?
<Jay7>
hm.. seems there are some people anknowledged with UBIFS internals :)
<Jay7>
kexecboot need ubifs support
<Jay7>
at least for detection that there is ubi/ubifs on nand
<kristianpaul>
Jay7: detection, no more?
<Jay7>
kristianpaul: well.. this is start move :)
<Jay7>
first thing we need
<Jay7>
then it is possible to implement attaching and mounting
<Jay7>
seems I should do this for LVM as well
<wpwrak>
kristianpaul: i realized that, if i allow a minor length difference in a pair of RF traces, i can rotate the chip such that all the digital signals are directly on the ben side. then i don't need to run all the traces around that 90 degree corner. also the crystal ends up at better location.
<wpwrak>
kristianpaul: i'll get a phase difference of about 1 degree, which according to simulation, shouldn't have any noticeable effect
<kristianpaul>
signals directly is almost perfect !
<wpwrak>
kristianpaul: yeah. i expect that the much cleaner layout will make up for anything i get in terms of imperfections due to the mismatched RF traces
<tuxbrain>
wpwrak: (atben size) well better realize now than already in production :)
<wpwrak>
tuxbrain: yeah :) that's pretty much the last moment :)
<wpwrak>
tuxbrain: btw, regarding UBB, any reaction from pulster ? i would assume he'd be your largest buyer, no ?
<tuxbrain>
for the moment just a 10 units bag to analize the product (as I also do) but surelly he will become my best costumer...as allways :) well maybe ron will compete with him this time :P
<tuxbrain>
I think I will do preorders but I will not wait any amount to place the order I will place it anyway. UBB must be done
<dvdk>
xiangfu: btw looks like the image you're building will also miss the Brainless chess game?
<dvdk>
xiangfu: mind to still add it?  does not require any compilation, as it's just some bunch of forth source code.  gmenu2x icon&starter for Brainless is already in the image.
<kristianpaul>
"Increase the lifespan of Symbian to a minimum of 5 years." no pleasee noo !!
<wpwrak>
are there no pictures of elop with horns yet ? :)
<rjeffries>
@segphault: How many Elops does it take to screw in a lightbulb? None, he has Steve Ballmer do it because he's too busy screwing Nokia.
<mth>
sounds like they are not just shareholders, but developers at Nokia
<mth>
since one of the problems they name is lots of outsourcing and layers of management trying to make the outsourcing work
<wpwrak>
hmm, i'm getting good at this. redoing the atben layout only takes me 2-3 hours now. i can almost do it with eyes closed :)
<Jay7>
rjeffries: look at nokiaplans.com
<wpwrak>
mth: they also seem to quite strongly dislike R&D outside of helsinki. i mean, helsinki is a nice place in summer, but ...
<mth>
I was surprised that Nokia turned to Microsoft for help: while Nokia has been lagging behind their competitors, but Microsoft failed in a much bigger way in the mobile world
<mth>
wpwrak: maybe it's actually easier to have every single person at a different location than having teams at a few locations
<mth>
because if everyone is somewhere else, you are forced to communicate electronically and then you might as well broadcast it to everyone
<wpwrak>
mth: indeed. but it depends a lot on the people. some adapt naturally. others don't.
<wpwrak>
rjeffries: i already answered your mail yesterday ... you need to work on that read/write ratio ;-)
<rjeffries>
wpwrak I have a flood of email. I assume your reply went to Doug Bull then?
<rjeffries>
I guess I need to ask him for the next rev of fab document
<mth>
in open source, someone who doesn't communicate problably never gets to the point of being offered commit rights
<wpwrak>
rjeffries: to you and to him. "Ron K. Jeffries" <rjeffries@gmail.com>
<wpwrak>
rjeffries: subject  Re: WERNER: questions re UBB fab specs
<wpwrak>
mth: so their only choice is to start their own projects, then enjoy each day the complains from people who have sent patches and got ignored :)
<wpwrak>
rjeffries: did you find it ? Date: Mon, 14 Feb 2011 21:15:25 -0300
<rjeffries>
wpwrak you've got mail.
<rjeffries>
I want him to polish/finalize the spec, which I think is getting close
<wpwrak>
... waiting for mail to arrive ...
<rjeffries>
yesterday was Feb 14 in USA, a holiday we call Valentines Day. spent it (mainly) doing fun stuff away from computer with my wife
<wpwrak>
ah, valentine's day is an official holiday ? didn't know that
<rjeffries>
sent 14:36 my tme (PDT) to you and Doug
<rjeffries>
well I do not think it is OFFICIAL but someone married for many year like me has learned it is IMPORTANT holiday
<wpwrak>
;-)
<wpwrak>
mail arrived. took a while to make the first hop.
<rjeffries>
does Tux ok
<rjeffries>
did tuxbrain get firm UBB quote and schedule? just curious is all. I assume 800 Ben owners are screaming for your UBB
<wpwrak>
right now, they're quite silent. i think we'll need a few "ice breakers" who will do something cool. then the word will spread.
<wpwrak>
cool but simpel :)
<wpwrak>
rjeffries: regarding batch sizes, this depends on the pcb fab. what i've seen so far is you generally have a certain setup cost and a more-or-less constant per board cost. this then gets somehow translated into a price for you.
<wpwrak>
rjeffries: i.e., you may find that 100 and 500 units have almost the same total cost. the pricings i've seen in this context all make 500-1000 a reasonable order size, while 100 or lower makes no sense.
<rjeffries>
I think I'll ask for quotes for 500 and 1000
<rjeffries>
we will get a fisrt article to review I think.
<rjeffries>
s/fisrt/first  that is pretty stanadsrd
<rjeffries>
what is the ticjness tolerance you want to spcfy?
<rjeffries>
s/spcfy/specify
<rjeffries>
s/ticjness/thickness  sigh
<rjeffries>
I'll be back later have to go pick up a Ben Nanonote
<wpwrak>
(sample) hmm, maybe. the per board production cost (for the fab) is low. probably well below 50 cents. and just setting up the production run may cost them USD 50-100. they may prefer to just do the run, and split the risk - if they did something wrong, you get another one, if the bug is in your data, your bad luck
<bartbes>
kyak: hey, I just added 2 games to the repo
<rjeffries>
I think you are correct besides ther material cost approaches zero on this tiny job
<bartbes>
EarthDefenders and CartesianCardinalZap
<wpwrak>
(thickness) something like 0.7-0.95 mm.
<rjeffries>
is the rumor that Ben makes a really functional paperweight correct? or is that jsut talk? ;)
<wpwrak>
1.0 mm may be pushing it.
<wpwrak>
rjeffries: (paperwight) you need to install the counterweight for doing this properly
<rjeffries>
wpwrak we work in inches as you see from his spec. ;)
<rjeffries>
wpwrak maybe the counterwight can be my next MONSTER project
<wpwrak>
rjeffries: (in) "units" is your friend :)
<rjeffries>
is this total thickness or tolerence ? 14:58 <wpwrak> (thickness) something like 0.7-0.95 mm.
<wpwrak>
total thickness !!
<rjeffries>
wpwrak I only do this for you my friend LOL
<wpwrak>
in any case, there's little you can do about the thickness. it's a standard PCB thickness and then a few microns are added for copper, plating, etc.
<rjeffries>
so you would say 0.85 mm plus 0.10 minus 0.15 ????
<rjeffries>
well the big boys spec it so I will as well. the fab must work to a final dimension for our buy off
<wpwrak>
let me put it this way: if the fab output isn't what fits, then the board cannot be produced efficiently ;-)
<wpwrak>
so the main parameter is the thickness of the base board
<rjeffries>
ok back later
<wpwrak>
rjeffries: i don't know the right keywords for the other parameters, so i don't try to specify them. chances are that they'd only cause confusion or (if i don't guess the "normal range" right) may accidentally put the board into an unusual category with high production cost