<wpwrak>
(except for the renamed columns. haven't done these yet.)
<wolfspraul>
he, now your scripts also need to deal with the splits! :-)
<wolfspraul>
so we support A4 and A3, but not A2?
<wpwrak>
it supports a2, but they don't look too good
<wolfspraul>
ah OK
<wpwrak>
i think the difference heuristics are now reasonably stable with a2. they may still miss some detail, i suppose, but they now find more than they used to.
<wpwrak>
the price to pay for this is more demand on disk space. there are now three different pixmaps: the ones for the difference views, the ones for the thumbnails, and then another set for the calculating the differences. the latter used thinner lines than the rest and disables anti-aliasing.
<wolfspraul>
so now you basically have a 3rd level, the PDF
<wolfspraul>
which has the two sheets separately
<wpwrak>
yup
<wolfspraul>
maybe should be labeled 'before commit' and 'after commit' or so?
<wolfspraul>
on the second level, the large png, I still find it too small to be readable
<wpwrak>
the two sheets, or one in case of addition/deletion. in the top bar of the front page, you also have the latest file and the while collection right of it
<wpwrak>
(label) what pdf viewer do you use ?
<wolfspraul>
maybe the browser scales the large png? I use firefox 3.6.x
<wolfspraul>
probably xpdf
<wpwrak>
xpdf should show BEFORE/AFTER in the sidebar
<wpwrak>
(hard to read) yes, that's generally a problem with things like schematics vs. non-zoomable images. the idea is that, if you're already familiar with the schematics, this image will tell you where the change is
<wpwrak>
to see all the details, the PDF is just one click away
<wolfspraul>
ok, my firefox uses evince, I don't see before/after there. in xpdf I do see it, but it's not clear which page you are on visually (maybe my xpdf)
<wpwrak>
hmm, thinking of it .. i could make a zoom view. precalculate a magnified version of the change area and use an image map on the large view.
<wpwrak>
(xpdf) no, that's unfortunately how xpdf does it
<wolfspraul>
I understand your point about the large PNG
<wpwrak>
the problem with labeling is that i don't quite know where it's safe to do so.
<wolfspraul>
for me it's more psychological. in the small png (overview), it's clear you cannot read anything. just get a very rough idea of the location/magnitude of the changes.
<wolfspraul>
but then you load the next larger png, and it is _almost_ readable. the almost is the frustrating part imo :-)
<wpwrak>
yeah, i know. it's very very close to being readable ;-))
<wpwrak>
(zoom) i think a precomputed magnified view could work nicely. needs to connect things from a lot of places, though, so it's not entirely easy. i'd say that's a version 2.0 feature :)
<wpwrak>
also storage demands will go up.  the baby is getting a bit fat :)
<wolfspraul>
I think that should be OK.
<wpwrak>
rsync of xue output now takes me ~45 minutes
<wolfspraul>
50GB partition right now, 33 GB are free. and the 50 GB is totally arbitrary, I could easily increase it to 100, 200, etc.
<wolfspraul>
I am probably a bit more worried about server load.
<wolfspraul>
the cache will stay, then it should be OK from what you said
<wpwrak>
lemme check how much disk space it needs ...
<wpwrak>
1.4 GB (cache and output of Xue)
<wpwrak>
cache rebuild is now ~19 min
<wpwrak>
output rebuild from cache is ... waiting ...
<wpwrak>
2 minutes
<wpwrak>
if i don't regenerate the PNGs it would be even faster. kinda 2 cache levels
<wpwrak>
that's a on a Q6600, basically without parallelizing
<wolfspraul>
I have to see how it performs on the server. if we need more power it's also OK at least we have a good reason.
<wpwrak>
hehe :) you;ll need to take some precautions that you don't start a job before the previous one has finished
<wpwrak>
right now, that's even more or less global. if you run two in, say, ~qihw/xue and ~qihw/ben-wpan, they would clash on some temporary files
<wolfspraul>
hmm
<wpwrak>
that's more feature than bug. i have to go up the hierarchy to make sure relative paths crossing projects still work. so the only choice would be to use a fixed name for the temporary directory or a variable one (based on PID or such)
<wpwrak>
in the latter case, you'd of course get some directory with junk when the process fails for some reason
<wolfspraul>
paths crossing projects?
<wpwrak>
but then, you may actually now want to have more than one run at the same time
<wpwrak>
e.g., ben-wpan uses things from f32xbase
<wpwrak>
so it assumed they're both at the same point in the hierarchy and accesses them with ../f32xbase/foo
<wpwrak>
assumeS
<wolfspraul>
what 'things' for example?
<wpwrak>
code
<wpwrak>
f32xbase has firmware components. boot loader, USB stack, DFU, etc.
<wpwrak>
all my little usb devices share that code. ben-wpan, cntr, in theory also idbg (the code comes from there, but idbg doesn't live in the qi-hw hierarchy)
<wpwrak>
once we have a kicad symbols and footprint library, also kicad could use things in this way
<wpwrak>
relative paths avoid the problem of having to find a global install location on the system and all that entails
<wpwrak>
well, there are three choices: relative paths to files, absolute paths to files, and names that get combined with a search path
<wpwrak>
search paths only move the issue elsewhere, because you then have to put the right relative or absolute path there
<wpwrak>
or use a default path, which means installing in /usr/local/share or such (in the case of kicad files), or /usr/include, /usr/local/include, etc., in the case of code
<wpwrak>
but now you need admin rights. not a nice general requirement.
<wolfspraul>
wait I cannot follow
<wolfspraul>
we are talking about the scripts to generate the schematics diffs now, right?
<wpwrak>
relative paths avoid all this. svn has another way, links into other repositories. not sure if git could do something like this, and at least in the case of svn it's a bit of a pain anyway
<wpwrak>
err, of the effect the organization of projects sharing files with other projects have on the scripts
<wolfspraul>
what files do they share?
<wolfspraul>
.lib files?
<wpwrak>
ben-wpan right now shares .c and .h files with f32xbase, plus a few special things like makefile templates
<wolfspraul>
and those dependencies need to be followed for the schematics diff generation?
<wpwrak>
if/when we make a "common kicad libraries" project (symbols, footprints, not scripts), then also .lib, .mod, and .fpd would be shared
<wpwrak>
it just assumes they are being satisfied
<wpwrak>
e.g., assuming ben-wpan lives in /home/qi/ben-wpan
<wpwrak>
my schematics are in /home/qi/ben-wpan/atrf/*.sch
<wolfspraul>
hmm, OK. so the scripts have some flexibility in following a ../ link outside of a project top-dir so in the future, links could be constructed between projects
<wpwrak>
if we had a kicad-libs project, and it would live in /home/qi/kicad-libs/
<wpwrak>
then ben-wpan could access, say, at86rf230.lib as ../../kicad-libs/components/at86rf230.lib
<wolfspraul>
I got it. I guess my concern comes from trying to avoid making a qi-specific closed system.
<wpwrak>
now, the schematics diff generate needs to check out the repository such that these paths still work
<wpwrak>
ok
<wolfspraul>
URLs would be better, but the kicad files need to be functional also locally for editing, so I guess for now the ../ thing works nicely both locally and on the server
<wpwrak>
there's nothing qi-specific about it. if you share stuff across projects, you need some policy. if you install everything globally instead, that will work too
<wolfspraul>
no projects is nice
<wpwrak>
kicad won't follow urls :)
<wolfspraul>
yes :-)
<wolfspraul>
no it's all good, I got it already.
<wpwrak>
so when you tell my eeschems diff system that you wish to diff the project at /home/qi/ben-wpan and the schematics rooted at artf/ben-wpan.sch, then it will make a temporary directory /home/qi/_something and check out the /home/qi/ben-wpan/.git/ repository there
<wpwrak>
in the checkouts, it steps through the revisions
<wpwrak>
ah yes, there could be conflicts when the shared projects have changes that aren't compatible
<wpwrak>
well, let's worry about this when it happens :) ideally, the project you share with should be conservative anyway. or else this will be the least of everyone's worries
<wolfspraul>
there is no such sharing yet anyway, right?
<wpwrak>
"conservative" = introduce item, debug it, then keep it stable. others would only access it after the debugging.
<wpwrak>
not yet. but that could change quickly :)
<wpwrak>
we already have files shared among projects by means of duplication. e.g., stdpass.fpd (small chip component footprints, 0402, 0603, etc.)
<wpwrak>
also idbg and ben-wpan "share" a lot this way. and ben-wpan "shares" with gta02-core in the same manner.
<wpwrak>
(a lot) well, the c8051f326, symbol and footprint. ben-wpan generalizes the footprint. and code from idbg went into f32xbase. i just need to connect idbg to all this again, and things will be sane :)
<wolfspraul>
got it
<wpwrak>
okay. now all that's missing is the rename tracking and the migration of the scripts in a new project. eda-tools or such.
<wpwrak>
project could be more specific (schwebdiff or such), but then we may have sharing issues when the time comes to do the same with the layout. at least i hope that much can be shared :)
<kyak>
wpwrak: what is the target of ben-wpan project? is it to enable ZigBee communication in Ben?
<wpwrak>
i'd aim for 6LoWPAN. we would get ZigBee on the way, too, but its IP status isn't quite clear yet
<wpwrak>
so it may not be good to "advertize" this as ZigBee. besides, 6lowpan may be more interesting anyway.
<kyak>
never heard of 6LoWPAN.. "IPv6 over Low power Wireless Personal Area Networks" - IPv6 is clear, what does it mean "Low power Wireless Personal Area Networks"?
<wpwrak>
"on the way" = there's the linux-zigbee project that aims to implement support for things on ieee 802.15.4, including 6lowpan and zigbee
<wpwrak>
WPAN is the type of network ieee 802.15.4 is designed for. basically for a "bubble" surrounding the user with a 10 m radius
<kyak>
ok, say, i have a wireless router. To support 6LoWPAN there is just a matter of SW upgrade?
<wpwrak>
once i get the rf side right, it should be a little more than 10 m, though. the chip is quite a bit better than what the specs require.
<wpwrak>
naw, you also need an ieee 802.15.4 transceiver
<kyak>
ah ok
<wpwrak>
but you could put a usb-to-ieee802.15.4 dongle into your pc and let that one act as a router
<wpwrak>
by sheer coincidence, the current ben-wpan prototype has a usb interface :)
<kyak>
i see! what is the real operating range you are getting mnow?
<kyak>
do you mean, the ben-wpan prototype that you connect to your Ben or your PC?
<wpwrak>
oh, now it's even less. maybe 3-4 m with a thin wall in the path. but that's crappy rf design on my side.
<wpwrak>
yup. for now, it only connects to the pc. once that works well, i'll branch off a ben-only version that doesn't have usb and crystal.
<kyak>
and you are right, they all combine ZigBee / 802.15.4
<wpwrak>
nice margin :)
<kyak>
hey, whats the need of "120V AC Adapter (ZR154-AC-USA)"? if there's no Host, there is no sense in this connection
<wpwrak>
the board that goes into the ben will be quite cheap. but not really user-installable.
<wpwrak>
i think you can load standalone programs into these dongles
<kyak>
hm, can't think of possible application
<kyak>
so this means, ben-wpan will probably go to Ya?
<wpwrak>
(standalone) maybe you can hook up a sensor in some way
<wpwrak>
(ya) that would be nice, yes
<wpwrak>
depends on a number of things, though. e.g., me getting this beast to work properly, and nobody else coming up with something better
<kyak>
why not a fully functional Wi-Fi chip?
<wpwrak>
so if you find a USD 5 Free software friendly WiFi module, ben-wpan will be pretty dead ;-)
<kyak>
ah, so it's the price
<wpwrak>
see above, note the "if" ;-)
<wolfspraul>
kyak: more than that. ben-wpan is the kind of feature that makes Ya possible.
<wpwrak>
price and freedom. there's almost no public technical documentation on most of the wifi chips
<wolfspraul>
we don't know what it will be, but Ya needs to have some major progress on the freedom side, otherwise what's the point of this project, and when do we reach the free smartphone :-)
<wolfspraul>
so the Ya process could be entirely in kicad, with visualizations like the stuff werner just did
<wolfspraul>
and/or it could have some really open RF solution, like ben-wpan
<wpwrak>
that would be nice :)
<wpwrak>
that too :)
<kyak>
yeah, finding affordable and free Wi-Fi chip may be impossible
<kyak>
wolfspraul: i think, there are actually two features that make Ya possible: wireless connectivity and a better LCD
<wolfspraul>
hold your expectations down on the better LCD
<wolfspraul>
at least coming from me that is, maybe someone else picks up the stuff and makes a different product out of it. that can always happen of course.
<wpwrak>
wolfspraul: did you look if there's some WQVGA you could use ? that wouldn't affect the form factor (well, except rearranging the display shell)
<wolfspraul>
for the LCD, I will just go with the flow, get whatever is the cheapest and easily available module. Plus something that protects the software we've done so far, for example with Ilitek drive IC.
<wolfspraul>
no didn't look, that has time until much closer to an actual Ya production
<wpwrak>
WQVGA would just provide those 80 extra pixels everyone craves ;-)
<wpwrak>
is the drive ic such a big issue ?
<wolfspraul>
I am not against better LCM, but you know my priorities. In the end these are all things we can 'just' buy.
<wolfspraul>
no, not very big. But since it's a 100% community effort I am very careful about "it's just a few lines" comments.
<wpwrak>
;-)
<kyak>
ok, not very encouraging but pretty fair
<wpwrak>
(just buy) the thing with the narrow display is that it makes the ben look weak. even people who completely "get" then openness message like to have products that look good.
<wolfspraul>
kyak: don't misunderstand me. I want the best LCM I can get. But it's not an area of active work, because we will not make any headway in terms of opening up that component anyway.
<wpwrak>
of course, the narrow display leaves room for rf. so there's also something good in this :)
<kyak>
wolfspraul: is the LCM closed currently?
<wolfspraul>
well there is little to open, from a free software perspective
<kyak>
then we can "Just buy" a better LCM, which is the same closed
<kyak>
or not?
<wpwrak>
the right side of the display could even host a capacitative sensor (keys or some slider). that way, one could have "functions keys" where they make sense
<wolfspraul>
the drive IC maybe, and that could lead to interesting optimizations, but there are many more juicy low hanging fruits.
<kyak>
wpwrak: great idea, at least it would make scrolling easier :)
<wpwrak>
wolfspraul: so no inauguration of the Sharism Panel Fab anytime soon ? :)
<wolfspraul>
nope
<wpwrak>
kyak: now, how to implement this cheaply, without adding a microcontroller ? :)
<wolfspraul>
kyak: basically if you look at the current LCM module, you can start to think of it as 4 parts: drive IC, FPC, glass, enclosure (called 'module' here)
<kyak>
i don't know, are there free inputs left on Ben's CPU?
<wolfspraul>
if you have lots of money, you can customize and optimize everything
<wolfspraul>
most really high-end products have customized glass dimensions, customized drive ICs, customized filters, customized FPCs
<wpwrak>
kyak: there are. and you could have more in a new design. even without changing the cpu much.
<kyak>
wolfspraul: i see.. is the "enclosure" part the one responsible for resolution, right?
<wolfspraul>
but for our volumes, oh well... :-) I rather spend the tiny money we have on where it matters from a freedom perspective. we have to grow it that way.
<wolfspraul>
no I mean the metal enclosure
<wolfspraul>
if you break open the LCM (I doubt you can disassemble it without breaking it), you will see many more parts inside :-)
<wolfspraul>
so the LCM is also called an 'LCM module'
<wolfspraul>
same as the 'RF modules' Werner doesn't like
<wolfspraul>
fiddling with any of this costs a lot of money. and may not net much on the freedom side.
<wolfspraul>
so first, let's see what really new/innovative things we can get going on the freedom side. Then we find the most cost-effective way to build a nice case around it.
<wolfspraul>
when you work in that order of things, you look at the LCM size later (or maybe together with mechanical), because you don't assume you can customize that part anyway
<kyak>
ok, you have the plan and as long as i see you stick to it.. this will lead to success eventually
<wolfspraul>
he :-) does it sound like that.
<wolfspraul>
well then, good!
<wolfspraul>
yes I need to stay away from things that just cost money and create no free innovations
<wolfspraul>
we first have to create free innovations, they need to generate money, and that money can then be spent to buy whatever shiny box
<kyak>
yes, this is what i'm talking about - you have a strategy :)
<wolfspraul>
it's amazing to see though how smartphone lcm resolutions are going up
<wolfspraul>
seems like a cold war arms race
<wolfspraul>
I don't even follow in detail anymore, it's all just going up up up it seems
<wolfspraul>
our 320x240 does look decidedly 80'ish, I agree
<kyak>
wolfspraul: it's not just the resolution.. my Nokia N73, having the same 320x240 can display much smaller, cleaner and nicer fonts. In fact, putty can display 80x24 terminal just fine
<kyak>
but ok, no more moaning :")
<wolfspraul>
kyak: oh we have much nicer fonts now, are those included in your critique already?
<kyak>
yeah, i have the setfont2 installed, and now the terminal is 50x24 if i remember correctly
<wolfspraul>
that's another thing - I totally want to max out everything our current Ben hardware can do.
<wolfspraul>
but it's still not good enough?
<kyak>
no :)
<kyak>
we need 80x24 - most console apps are working like this
<wolfspraul>
that's the default font now because we felt it's the best compromise between readability and amount of characters on screen
<kyak>
i mean, they are designed to work with at least 80x24
<wolfspraul>
there are smaller fonts too you can enable with setfont2 I think
<kyak>
yeah, i know..
<kyak>
can't work for a long time with 4x8 font :0
<rafa>
kyak: we have added xorg fonts so ou can run a terminal with the font you wish
<kyak>
rafa: looks good, but as i remember keymap is broken in rxvt
<rafa>
that would let you test
<rafa>
kyak: rxvt keyboard broken?
<rafa>
where?
<kyak>
like function keys, or "Red arrow" ?
<kyak>
in Jlime
<rafa>
nop
<rafa>
beta 3
<kyak>
oh!
<rafa>
has rxvt with keyboard working
<rafa>
fn key
<rafa>
red arrow
<kyak>
need to have a look then, thanks :)
<rafa>
all is okey
<rafa>
kyak: when you run terminal in beta3 it will use a bigger font
<rafa>
if you want to change that just edit /usr/bin/rxvt.sh
<rafa>
with the font you wish to test
<kyak>
ok, thanks for the hint
<rafa>
kyak: the pic shows the 5x7 font
<kyak>
ok!
<viric>
wpwrak: Have you tried printing schematics in kicad?
<viric>
wpwrak: they look quite bad
<rafa>
kyak: okey, if you do some tests with different fonts tell us which is useful for you so we can use the same :) (there are several fonts in xorg fonts installed)
<kyak>
mkey :)
<kyak>
that also gives a chance to have full support of utf-8 in rxvt
<kyak>
might be less painfull than linux console
<wpwrak>
viric: hmm, maybe try "plotting" them ?
<viric>
wpwrak: I'll try
<viric>
wpwrak: right, much better! Thank you!
<wpwrak>
(sending schematics) oh yes. you need to know which files to send, though. well, kicad has a "send everything you need" command. not sure if it works well. i generally don't trust such things much :)
<viric>
I don't need to send something editable by now
<wpwrak>
ah, postscripts or pdfs are easy
<wpwrak>
wolfspraul: hmm, what's actually the reason for not even considering small layout changes for the next bens ? fear of introducing a stupid bug ? lack of control of the process ? (so a small change would be expensive to implement, e.g., because you'd have to go via the layout house)
<wolfspraul>
it creates too much work, too much cost
<wpwrak>
wolfspraul: (just read carlos' comment. and i very much agree with the "USB as soon as humanly possible" point)
<wpwrak>
hmm, if you changes, say, a label in the silk screen, would that already create this sort of work ?
<wpwrak>
i understand that risky changes are costly. but there's a certain amount of things you can usually change at minimum risk. particularly if you get it reviewed. not sure if routing usb to test points would be among the "easy" changes.
<wolfspraul>
yes sure. too many people and vendors involved. it will not happen.
<wolfspraul>
what is Carlos point? and where?
<wpwrak>
ah, so you don't just send a new set of gebers to the pcb fab
<wpwrak>
on the list, latest mail "IMO we must provide the USB host lines as Test points in the next run." (unclear whether he means "Ben" or "Ben II"/"Ya", though)
<wpwrak>
wolfspraul: i think the frustration everyone feels with USB host is the same you have with my almost readable schematics. so close yet so far :)
<wolfspraul>
yes agreed _but_ ... it has been discussed many times. we have tried to explain how we got to where we are, and what the priorities are.
<wolfspraul>
I can send some letters to Santa Claus too...
<wpwrak>
;-) i understand perfectly well that you don't want to make expensive/risky changes now. what i don't understand is why this means "no change at all".
<wolfspraul>
so on the Ben, it will not happen
<wolfspraul>
the Ben production process still uses proprietary software. otherwise we couldn't produce at all.
<wolfspraul>
with SIE we are just starting to build up more testing software now, which will be helpful for future NanoNote runs as well
<wpwrak>
and that's proprietary software you don't have ?
<wolfspraul>
yes but the vendors we are working with, that are making the PCB, SMT, assembly and testing, cannot make changes unless the volumes are much higher
<wolfspraul>
it's just uneconomical
<wolfspraul>
we are going in circles with this. The Ben is a starting point. We knew some of its deficiencies before starting (such as the lack of USB host). Others we found out later.
<wolfspraul>
with the help of the Ben, we get enough momentum into this to be ready for an economical Ya production of a product that (hopefully, if we worked well), has less deficiencies than the Ben
<wpwrak>
sure, sure. but where exactly *is* the cost of the change ? we're not talking about tearing the ben another hole ;-)
<wolfspraul>
don't know I never asked or even thought about it. Maybe once you work with all these people and vendors for so long at some point some numbers are just so obviously off it's not worth to talk about...
<wolfspraul>
a normal OEM has a MOQ of 10K
<wolfspraul>
let's just start there
<wolfspraul>
because we started Qi hardware in the middle of a massive recession, we negotiated it down to 3k
<wolfspraul>
from there we negotiated further down to 3 'shipments' of 1k each
<wpwrak>
;-))
<wolfspraul>
now, if you zoom into the prices, you will realize really everybody is working with zero margins. literally.
<wolfspraul>
the entire SMT + assembly/testing costs ca. 3.50 USD
<wolfspraul>
that's about 300 people working together there to make this happen
<wolfspraul>
so 1 cent / NanoNote for each one
<wpwrak>
so your concern is that they would be upset if you made a change in a deal where you're already stretching things. even if the change is perfectly safe and no extra work for them, they may still bark at the sheer concept. is it that ?
<wolfspraul>
can you please give them a break at some point. they also need to eat and sleep once in a while. and cannot 'skip' eating for a few days or weeks because some customers couldn't do the math right :-)
<wolfspraul>
it's just impossible
<wolfspraul>
there are even no people to communicate these 'perfectly safe' changes to
<wolfspraul>
every new lot in every storage causes administrative overhead
<wolfspraul>
the only reason we can make 900 Ben is that we are massively sharing stuff with much larger runs
<wolfspraul>
our 1k order every 6 months is just a blip on the screen
<wpwrak>
so when you want to make 1000 more units, you don't send an order to a pcb house that makes the boards for you but you go to some one-stop-shopping house that already has the gerbers, case design, etc., and will then make the bens for you, with the actual ordering of pcbs and the like invisible to you ?
<wolfspraul>
not invisible, we know all the people, all the way to the vendors
<wolfspraul>
but you cannot strangle your business partners to death
<wolfspraul>
just look at the numbers, it's scary
<wpwrak>
is it them who order/make the pcbs ? or do you send them the pcbs and they do the rest ?
<wolfspraul>
they shouldn't even pickup the phone once - no margin for that :-)
<wolfspraul>
no we buy the entire product
<wolfspraul>
we work with an ODM essentially
<wpwrak>
okay. i think that's the point that wasn't clear enough.
<wolfspraul>
changes are possible, but uneconomical
<wpwrak>
and since this is a "3kU in 1kU installments" deal, for all you know, they may already sit on those remaining 2000 PCBs, waiting for your next cheque.
<wpwrak>
(at least conceptually)
<wolfspraul>
nobody has margins, so sourcing is very careful
<wolfspraul>
remember how many people need to be fed in all this
<wpwrak>
yeah, all the things USD 100 can buy you, it's scary :)
<wolfspraul>
yes, and how many people work together on this
<wpwrak>
i'm not arguing that you should squeeze your business partners more. what i'm after is understanding where exactly such changes would even be a problem for them. e.g., it wasn't clear that the administrative process also included the pcb design, probably with approvals and related paperwork.
<wolfspraul>
wpwrak: keyboard factory as an example (I know, it's not silk/pcb, but to illustrate my point)
<wolfspraul>
keyboard factory employs 6000 people
<wolfspraul>
razor thin margins on everything
<wolfspraul>
that means every day they have to crank out keyboards
<wolfspraul>
if they dont : no money to buy dinner
<wolfspraul>
literally
<wpwrak>
so it's not order PCBs from X, SMT from Y, cases from Z, send everything to W who then put it into the case
<wolfspraul>
so they need to make 150k / day
<wolfspraul>
now imagine when the early shift comes in and looks at the plan of the day, and they see 150 tiny 1k orders each
<wolfspraul>
WHAT A SHITTY DAY THAT WILL BE! :-)
<wolfspraul>
and they have to finish all this, time has no mercy
<wolfspraul>
next day the next 150k need to be produced already
<wpwrak>
the early shift has it good. there will still be money for lunch ;-)
<wolfspraul>
so those orders, and all their messy little differences and little start/stop problems and what not will be a nightmare
<wolfspraul>
compare that so a nice day with 3 big orders of 50k each
<wolfspraul>
s/compare that so/compare that to/
<wolfspraul>
see my point?
<wolfspraul>
so when our 1k order comes in, it's already painful for them
<wolfspraul>
this was only possible because we started in the middle of the worst recession in a while
<wolfspraul>
so that's keyboards
<wolfspraul>
but it's the same principle everywhere
<wpwrak>
yes, what wasn't clear is why a 1 k order without changes would be any less painful than a 1 k order with changes.
<wolfspraul>
I think the SMT place needs to make about 4-5k / day to pay the bills
<wolfspraul>
every minute is work, ah minute. it's optimized to the last second.
<wpwrak>
what you're basically saying is that all this is a pipeline and the next 1-2 k are already further down the pipeline.
<wolfspraul>
you could say it that way
<wolfspraul>
you can reach into this pipeline and fiddle around
<wolfspraul>
but it's painful
<wpwrak>
thanks. that was the explanation that was missing :)
<wolfspraul>
and we are already stretching the rules everywhere
<wolfspraul>
well they are flexible
<wolfspraul>
but you need to understand their pressure. it's the downside from the low margins and endless optimizations over years.
<wolfspraul>
these processes are basically continuously being optimized
<wolfspraul>
but the optimization has negative side-effects of course
<wpwrak>
yes, that's okay. nobody's arguing (so far ;-) about the quantitative side. what was missing was the qualitative side. i.e., why this would be a problem in the first place.
<mstevens>
How is Qi world these days? Is there a good status update somewhere?
<kyak>
wolfspraul: does it also mean that you would have to order 10k pieces of Ya?
<wolfspraul>
because I know the people I work with and I cannot ask them for more favors.
<wolfspraul>
Ya will have many interesting challenges.
<wolfspraul>
again it's not so much 'have to'
<wpwrak>
e.g., if you'd order your PCBs yourself and ship them do a "does all the rest" house, then there would be no penalty for making changes (as long as the changes don't introduce bugs, naturally), since it would be just a package with pcbs anyway.
<wolfspraul>
you can order 1 Ya from me, if you pay 1 million USD I may still produce 'some more' in my backyard and ship you the one you ordered.
<wolfspraul>
so we will see what smart way we find to reuse some Ben stuff, and introduce some new Ya stuff
<wpwrak>
but since you have a pipeline and you've essentally handed the design over to production, there _is_ a barrier, no matter how small.
<wolfspraul>
that's why we work with all the Ben vendors one by one
<wolfspraul>
mstevens: no status update, sorry. need to become more active again on the PR side after the summer break :-)
<mstevens>
wolfspraul: alternative question, any cool stuff happening?
<wolfspraul>
mstevens: things are moving in many places, if anything we are spread very thin. Werner has been doing awesome stuff the last 2 months, case scans, 802.15.4 RF work, kicad revision visualizations, counterweights, etc.
<wolfspraul>
Milkymist One, Xue
<wolfspraul>
Lars managed to upstream most of the Ben NanoNote kernel in 2.6.36
<wolfspraul>
Jlime has much improved software.
<mstevens>
I kinda bought my nanonote on general principles of supporting free gadgets, I look back now and again to see if there's anything fun I can actually do with it :)
<wolfspraul>
try jlime
<mstevens>
I did have it setup as very difficult to use ogg p0layer
<wolfspraul>
wpwrak: I think in the future we should be in a better position wrt smaller runs. At least we are working towards that.
<wolfspraul>
but I think mostly because we do the smaller runs ourselves. I think once you work with companies that do very complex work steps for ridiculous little money, you will always pay the price in some way, for example in their inability to process too many changes, if any.
<wolfspraul>
and if you still ask for those changes, you are just going to kill them, which also will not help (they will just refuse your business)
<wolfspraul>
think about it this way: SMT + assembly/testing = 3.50 USD
<wolfspraul>
so for 3K, that's about 10,000 USD
<wolfspraul>
for a company that needs to feed 300 people
<wolfspraul>
and then you want to break down even those 10k USD into smaller chunks, and have some special request after the first 2K, and then after the next 4K, and another one after another 2K.
<wolfspraul>
It's just impossible.
<wpwrak>
(organize small runs yourself) yes, i think that's the key. so you can pick whatever suits your needs best.
<wolfspraul>
the machine is already so crazy optimized it just cannot do this.
<wolfspraul>
do you know how much work has to get done for those 10K USD? how much can go wrong? how hard they work for that money? it's insane. It's optimized to the last penny.
<wpwrak>
right now, the volume alone probably doesn't justify going to highly efficient places. even less efficient places would only raise the cost a little. (of course it's nice if you can spare some bucks)
<wolfspraul>
ah no
<wolfspraul>
he he
<wolfspraul>
costs go up a lot
<wolfspraul>
a lot as in A LOT
<wpwrak>
however, since you don't have all the pieces of the process under your control, you cannot cherry-pick. so it is all or nothing.
<wolfspraul>
correct
<wolfspraul>
it should get fun later
<wolfspraul>
we only must resist to make all sorts of changes in components that reduce our ability to cherry-pick later
<wpwrak>
yup. that's one important thing
<wpwrak>
e.g., no case parts that require production techniques that haven't been invented yet ;-))
<wpwrak>
(inside joke)
<wolfspraul>
isn't it amazing that 300 people work together and make 1 cent each on the finished product they are collectively working on?
<wolfspraul>
I continue to be amazed by this and thinking about it...
<wpwrak>
bah, in qi-hw we have scores of people who make even 0 cents on the product they're collectively working on. heck, they even pay for it ;-)
<wolfspraul>
and these are very complex processes, with a lot of testing going on, a lot of 'return 2 stations, repair this', rinse and repeat...
<wpwrak>
wolfspraul: so you've out-optimized the chinese :)
<wpwrak>
wolfspraul: i think it would be good to post an explanation why such small changes are more difficult that one would expect to the list. until now, that point wan't clear even to people who try to have reasonable expectations.
<wolfspraul>
what clarified it for you now? the pipeline?
<wolfspraul>
I like that word, fits with reality :-)
<wolfspraul>
yes there is a pipeline, definitely. deep into the vendors.
<wpwrak>
pipeline and that the deal is for more than those 1k units.
<wpwrak>
"deal" or perhaps "understanding"
<wolfspraul>
oh sure. much more. the steel tool, for example, will be maxed out to 250k, no matter what :-)
<wolfspraul>
no matter how many products have to share the same look
<wolfspraul>
well actually it will be worn out until the tolerances become too big, but they try to manage it well and produce as much as possible
<wpwrak>
and the reason for needing such an arrangement is of course that there are many things you can't go cherry-picking for yet
<wpwrak>
(steel tool) sure, but that only matters if you want to make a case change or when you're not able to get the case parts from another source
<wpwrak>
we can exclude the case change but the sourcing issue would continue to exist
<wpwrak>
(another source) or without the rest of the package attached to it
<wpwrak>
i.e., if you went to the same guys and asked them to make nanonotes with a board you supply, smt and tested, this would be a different kind of deal, with different prices, and maybe they wouldn't even want to do it.
<wolfspraul>
that's probably what we will do with Ya
<wolfspraul>
in fact we are talking with them already now, to prepare, see who is interested in what, etc.
<wpwrak>
and, most of it, it would be a radical change to what you've negotiated with them for now. nobody likes customers who pay poorly and ask for crazy changes all the time :)
<wolfspraul>
YES!
<wpwrak>
(ya) that sounds good
<wolfspraul>
and 'pay poorly and ask for changes all the time' unfortunately is a common habit among electronics industry customers
<wolfspraul>
so everybody is on the lookout
<wolfspraul>
you want to work with people that make 5 USD a day, no, you not only 'want to' work with them, you absolutely insist to _only_ work with such people
<wpwrak>
right now, you need those "one stop shopping" houses because you can't so the individual steps in a useful way. be it because you lack contacts, expertise, just time to set them up, because they're not available at reasonable cost, whatever.
<wpwrak>
s/so the/do the/
<wolfspraul>
and then on top, your orders don't come in as a regular stream, and then on top of that you want these people to understand all sorts of great new ideas you had along the way
<wpwrak>
oh yes. no only ask them crazy stuff, ask them to be _enthusistic_ about it, too ;-))
<wolfspraul>
mostly for Ya we are lacking production testing software, a solid SOP document (IKEA style) that someone can walk through
<wolfspraul>
for the vendors we have established contacts and connections everywhere, continue a bit here and there, second source etc.
<wpwrak>
make sure you look suitable disappointed in them if they don't follow your presentation of radical changes with standing ovations ;-))
<wolfspraul>
for example I will try to find a smaller keyboard factory, not just that scary one with 6000 employees
<kristianpaul>
08:17 < wolfspraul> so we will see what smart way we find to reuse some Ben stuff, and introduce some new Ya stuff
<kristianpaul>
nice
<wolfspraul>
ah no, it's all just simple math. and if they don't have enough money to eat, well, they will simply not do the work. big surprise :-)
<wpwrak>
(keyboard) as an aside, i'd love to see that get customizable. that could be a key [no pun intended] for OEM applications.
<wolfspraul>
yes so I want to find smaller and more flexible (he he) keyboard makers
<wolfspraul>
of course I still only want to pay 3.50 USD / keyboard
<wolfspraul>
:-)
<wolfspraul>
just kidding. Like I said I am able to follow simple math. And if the work needs so and so many minutes, and so and so many people are involved, then the price will be such and such or no keyboard.
<wpwrak>
as long as everyone's an asshole, if you just treat them a little less nasty than the rest, they'll think you're mother theresa ;-))
<wolfspraul>
I try to be very open upfront about our volumes.
<wolfspraul>
and so far I think everybody appreciates that and actually is very supportive of the project.
<wolfspraul>
in the meantime, I do not expect impossible things like workers paying 1 USD / hour for the privilege of working on my product :-)
<wpwrak>
well, low cost is good for the baseline. i don't care much about it for customizations. so, ideally, you'd have both paths - a design that can be produced efficiently in medium to large quantities, and that still allows small-volume customized runs.
<wolfspraul>
yes correct!
<wolfspraul>
exactly my thinking, hopefully we slowly get there - as we get better to make small runs.
<wpwrak>
the key for the latter being modularity, absence of crazily difficult elements, open design, and a resonably open/documented production process.
<wolfspraul>
all agree
<wolfspraul>
so the most interesting decisions from Ben to Ya will be what we change, what we don't change. the criteria.
<wolfspraul>
on the mechanical side, I do not like some of the glued stuff.
<kristianpaul>
wolfspraul: what is a small for you in numbers?
<wolfspraul>
I do not like the plastic clips around the frame.
<wolfspraul>
kristianpaul: you mean small run?
<wolfspraul>
anything < 1000
<kristianpaul>
ok
<wolfspraul>
500 is maybe in the middle
<wpwrak>
(mech) i'd go for screws, just to keep things simple
<wolfspraul>
but < 500 is definitely typically called 'small run'
<wpwrak>
(mech) not sure about glue. seems to be unavoidable for some things. but agreed, the less the better
<wolfspraul>
in other words the normal production SMT/assembly places cannot process such small orders. or don't want to, because they are over-optimized as I explained above.
<wpwrak>
(mech) if you can get control of the case making process, then some of these things will happen just naturally, because you'll be forced to keep things simple ;-)
<wolfspraul>
yes, that would be great
<kristianpaul>
wolfspraul: you may end building a small SMY/assembly factotry some how
<kristianpaul>
well not build as the sense of make
<kristianpaul>
s/build/arrange
<wolfspraul>
oh no. just the knowledge. documentation, software, etc.
<kristianpaul>
ok
<wolfspraul>
all freely documented and licensed of course.
<wolfspraul>
anybody can use this to manufacture.
<wolfspraul>
I will absolutely 100% not start to buy my own pick and place machines etc.
<kristianpaul>
ok
<wpwrak>
now, if just someone who knows about mechanical stuff would take the lead there. you can of course wait until i get around do doing that, because it does bother me to not have control over this type of things, but someone with the right experience and the right tools should be able to beat me by a decade or two ...
<kristianpaul>
but is soo hard get small runs on china?
<kristianpaul>
i guess there is market for everthing..
<wolfspraul>
yes sure but then it gets expensive
<kristianpaul>
ahh true the expensive balance..
<wpwrak>
not sure if a basic smt line is really that expensive. it would have its benefits for prototype runs.
<kristianpaul>
why not just got cheap SMT and document more assembly
<wpwrak>
and an automated line that can do tens of prototypes can also do 1000 units. shifts the point where you need to go to the bigger houses.
<kristianpaul>
well i must leave (real life work)
<kristianpaul>
bbl
<wpwrak>
but let's talk about this when your main worry is where to invest all the money ;-)
<wolfspraul>
wpwrak: it's not just the machines, it's the entire company and their people you need to think about.
<wolfspraul>
companies are targeting different customers, and have the appropriate staff and technical equipment for whatever they are targeting
<wolfspraul>
there is a lot of diversity in PCB and SMT houses
<wolfspraul>
so it's not about what they 'can' (theoretically) do, based on outside speculation. it's about what they have been optimized for, and are competitive at.
<wolfspraul>
some of them are upgrading their equipment, because it's part of their strategy and how they operate.
<wolfspraul>
some don't. they will just be setup with equipment X, and then they will run down that equipment, and produce whatever that equipment is best suited for, at the lowest possible prices.
<wpwrak>
(company and people) sure. if you have an smt line, you'd need someone in charge of maintaining and operating it. "operating" also in the sense of making incoming designs match
<wolfspraul>
and those places don't even need anyone to think about what 'else' would be possible, if they only added this or that 'little' thing. It wasn't setup like this. The point was to produce ABC at rock bottom prices.
<wolfspraul>
others can try other strategies, but that place may be using this strategy. end of story.
<wpwrak>
so that's something useful if you do many small runs
<wpwrak>
yup, that's MP again
<wpwrak>
i'm thinking more of R&D and customization
<wolfspraul>
sure, I just try to explain why sometimes seemingly simple/little things turn out to be so hard.
<wolfspraul>
it depends on whom you are presenting your 'little' things to, and how they have been setup
<wpwrak>
"little" changes also need to be in relation to the money they can make with it ;-)
<wolfspraul>
this problem only exists because of an almost insane optimization down to the last penny
<wpwrak>
smt fab != university of manfacturing ;-)
<wolfspraul>
so even some common sense things cannot be done sometimes, the people are just not there that would understand _anything_ :-)
<wolfspraul>
so while an SMT place like Minbo that we used for the Milymist One RC1 run (6 pieces) can make larger runs, it's unusual for them to get such orders, or at least not for too long, because they will be too expensive
<wolfspraul>
they have all these expensive people walking around the floor...
<wolfspraul>
so the brains of these people are under-utilized if a 5k run is being processed. and at some point even their choice of equipment may not be ideal for larger runs, or it may not be configured well for larger runs, etc.
<wolfspraul>
there is too much optimization going on for 1 super-automated machine to be able to scale from 1 to 1 million and always be competitive with companies (and real people) that have specialized
<wpwrak>
wow, 6 pieces is tiny indeed. how do you even feed pick and place efficiently for that ? :)
<wolfspraul>
in SMT you basically pay for time
<wolfspraul>
is like you rent the floor, by the hour (roughly)
<wpwrak>
yeah, there are different classes of machines
<wpwrak>
so you do R&D runs in .cn or in .tw ?
<wolfspraul>
Taiwan
<wolfspraul>
we are also cherry-picking between Taiwan and China :-)
<wpwrak>
lekernel: i think it's some ubuntu depedency problem. never had this kind of trouble until after the last major upgrade. i should probably reinstall from scratch. it's probably using some old incompatible driver/library.
<wpwrak>
lekernel: the holy grail analogy is nice ;)
<kyak>
i don't understand.. trying to install latest Jlime from within Ben, it hangs at mkfs.ext2 (i.e. mkfs.ext2 is doing nothing). It's strange, because I've done this several times before..
<kyak>
i'm going to install the latest image from 26th of August instead of the image i just built myself
<rafa>
kyak: me here for a wil
<rafa>
while
<kyak>
rafa: the prob is, i don't have the microSD card reader, so always have to install Jlime from within openwrt
<kyak>
and for some reason it fails this time./.
<rafa>
kyak: ah... and now mkfs.ext2 freezes? :(
<kyak>
yeap
<rafa>
weird
<kyak>
indeed!
<rafa>
are the partitions okey? i mean.. i would not know what to check anyway
<rafa>
have you had patience? :)
<rafa>
i mean. if it run for a long time
<kyak>
partition is ok, i just unmounted it
<kyak>
and i was patient, though it usually only takes seconds
<kyak>
flashin rootfs now, let's see if it'll help
<rafa>
are you flashing openwrt ?
<kyak>
yes
<rafa>
have you used the same kernel and openwrt last time that mkfs.ext2 worked okey?
<kyak>
no, definitely not.. i reflashed since that
<rafa>
ah... okey.. so there are a lot things to check maybe.. kernel version, kernel support for sd, ext2, etc. mkfs.ext2 versions, if there was swap last time..
<kyak>
these things are pretty much the same.. could be some mess with libraries during build
<rafa>
you can try jlime on nand as wellif you know how to reflash easily
<Ornotermes>
had my flashlight behind it to see the progress better
<wpwrak>
did you change the track on the right edge ?
<Ornotermes>
no not yet
<wpwrak>
(flashlight) ;-))
<Ornotermes>
i will change that and a couple of other things later
<Ornotermes>
and thanks wpwrak :)
<wpwrak>
have you used kicad yet ? would be nice to have all this accessible with a Free tool.
<Ornotermes>
maybe it could be an idea to add another uSD slot to NN in the future, but as an expansion port with SPI/I2C/GPIO instead of sd(even if could be bit banged)
<wpwrak>
yes. maybe the next cpu will even have two sd interfaces, so each could get its own.
<wpwrak>
make the second slot face towards an open internal space (battery) and voila
<wpwrak>
also, make it a friction lock, not the push-to-lock/unlock type, so the card can be flush with the edge'
<wpwrak>
also, there's nothing preventing anyone from routing sd and spi to the slot. maybe with an NC resistor in the part so that one can choose whether to join them or not
<Ornotermes>
wpwrak: but for hardware expansion i think SPI and I2C is most interesting
<wpwrak>
yup, agreed
<Ornotermes>
also, i have an idea of a special conecor for the usb
<Ornotermes>
so when nothing is connected the usb goes staight to external, but if one connects a internal board (like 2port hub + bluetooth) usb goes to the hub and one goes to external and the rest can be used by devices on the internal expansion board
<Ornotermes>
but it would probably require more space
<wpwrak>
hmm, sounds complicated. could also cause problems with signal integrity
<Ornotermes>
maybe, but it would make it possible to add internal usb devices, and still have the port avaliable
<wpwrak>
the whole usb setup may change with the next cpu anyway. so there's a chance that there will be an extra port we could use for such things
<wpwrak>
but details on that cpu are still scarce
<wpwrak>
Ornotermes: do you have the coordinates/sizes for the uSD card in mm ?
<wpwrak>
Ornotermes: i'd like to make a footprint with fped (for kicad)
<Ornotermes>
wpwrak: not really, but most pads are 3x2 mm (i think)
<wpwrak>
they must be something like 3x0.9, with a 0.2 mm gap. some are a bit longer, maybe 3.3x0.9
<wpwrak>
but i was thinking more of the package outline
<Ornotermes>
i'm not sure of my measures yet, but you can take a look at the high res version of my board layout
<Ornotermes>
especially when you live in a apertment ;)
<Ornotermes>
but now good night
<wpwrak>
yeah :) make sure your neighbours don't forget you :)
<wpwrak>
sweet dreams ! :)
<unclouded>
how would software on the Ben control the uSD lines?
<wpwrak>
unclouded: it could write directly to the port registers
<wpwrak>
or you can make a kernel driver that does all this properly :)
<unclouded>
would it interfere with the part of the kernel that interfaces with uSD cards?
<wpwrak>
you just override it ;-)
<unclouded>
is it built as a module and I can simply unload the module and then write to the port registers?
<wpwrak>
you can check: lsmod
<unclouded>
ok.  what would the module be called?
<wpwrak>
something mmc, mci, maybe sd
<unclouded>
doesn't seem so then.  With OpenWRT 2010-06-15 there are a lot of ALSA modules ( snd_*), "tun" and "ks7010".  nothing else
<wpwrak>
doesn't sound like it then. you can also disable things via sysfs to some extent, but i don't think this really helps in this case
<unclouded>
would it be silly to insert a uSD breakout board wired to a project while the MMC driver is still active?
<wpwrak>
hmm. good question :) depends a lot on what the board does
<wpwrak>
generally, nothing untoward should happen
<wpwrak>
even if you short things
<unclouded>
does uSD do current limiting like EIA-232?
<unclouded>
is that why it's OK to accidentally short things?
<wpwrak>
some SD do current limiting. but i kinda doubt the TM2301N is good at it (Q4, on the MEMORY sheet)
<wpwrak>
it's okay because you shouldn't be able to short power directly. and I/Os usually have a high internal resistance. 100 Ohm or so. enough that nothing bad happens.
<unclouded>
ah, ok.  just don't short Vcc to GND ;)
<wpwrak>
fortunately, these two are at fixed positions :)
<unclouded>
Qi Hardware is the number one search result for "TM2301N" with Yahoo
<wpwrak>
also useful for checking how things are set up without having to wade through half of the kernel sources
<kristianpaul>
great
<kristianpaul>
heh i just discover UML exists few minutes ago :p
<wpwrak>
wolfspraul: seems that we have found our extension card connector ;)
<kristianpaul>
wpwrak: the tiny PCB on the lists?
<wpwrak>
kristianpaul: User-Mode-Linux ? Ugly Modelling Language ?
<wpwrak>
yup. or rather the uSD card holder
<kristianpaul>
wpwrak: linux thing :)
<wpwrak>
uml is kewl. are they still maintaining it ? i once wrote a little simulator on top of it (umlsim). didn't keep maintaining it, though.
<kristianpaul>
ah
<kristianpaul>
well
<kristianpaul>
erase UML from his mind
<kristianpaul>
qemu is our ffriend :)
<wpwrak>
naw, the simulator knew about kernel internals. it could affect time as well. so you could simulate, say, a wget over a link with a certain delay.
<kristianpaul>
hm...
<kristianpaul>
well i have a nanonote whos needs a sofware simulator ;)
<wolfspraul>
wpwrak: yes I saw it. sounds good, let's see what comes out of it. Too many things going on for me right now :-)
<wpwrak>
*grin*
<kristianpaul>
re-use, look look, more free pins more free pinds, i think i will love this ben board :D
<wpwrak>
it's a pretty cool idea. i could kick myself for not having had it myself :)
<kristianpaul>
lol
<kristianpaul>
thats why micro-sd exists...
<kristianpaul>
but some how is not so wide spread as we wish
<kristianpaul>
damm usb !
<kristianpaul>
;)
<wpwrak>
yeah, in my mind i had it permanently assigned to storage. so it wasn't really "available" for anything.
<kristianpaul>
thats happens
<kristianpaul>
as me for usb :)
<kristianpaul>
well about ethernet with this SPI chip i dint sugguest use that port bacuase i relly need run debian from sd
<kristianpaul>
so i cant kill the port
<kristianpaul>
evertully i'll try the SPI  bit-bang slowness (1Mps is enought for me  )
<kristianpaul>
eventually*
<wpwrak>
the jz4760 might have up to three mmc controllers. so we could have plenty of slots
<kristianpaul>
but thats will no be considered posible until the other 1K ben run, no?
<kristianpaul>
our SoC now is jz4740 or do i'm confused,( again?...)
<wpwrak>
jz4720. jz4740 has the same core but different bond-out. (more signals)
<wpwrak>
jz4760 may be a possible future.
<kristianpaul>
:)
<wpwrak>
wolfspraul: one more project for the commit reporter: kicad-libs
<wolfspraul>
wpwrak: kicad-libs should be hooked up