lindi- has quit [Quit: No Ping reply in 180 seconds.]
lindi- has joined #qi-hardware
lindi- has quit [Changing host]
lindi- has joined #qi-hardware
xiangfu has quit [*.net *.split]
rodgort has quit [*.net *.split]
roh has quit [*.net *.split]
roh has joined #qi-hardware
xiangfu has joined #qi-hardware
rodgort has joined #qi-hardware
panda|x201 has quit [Quit: Leaving]
larsc has quit [Ping timeout: 272 seconds]
larsc has joined #qi-hardware
panda|x201 has joined #qi-hardware
panda|x201 has quit [Ping timeout: 240 seconds]
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #qi-hardware
xiangfu has quit [Ping timeout: 245 seconds]
panda|x201 has joined #qi-hardware
viric has quit [Remote host closed the connection]
viric has joined #qi-hardware
xiangfu has joined #qi-hardware
wolfspraul has joined #qi-hardware
panda|x201 has quit [Ping timeout: 245 seconds]
panda|x201 has joined #qi-hardware
wolfspraul has quit [Ping timeout: 268 seconds]
xiangfu has quit [Read error: Connection reset by peer]
lekernel has joined #qi-hardware
jekhor has joined #qi-hardware
rz2k has joined #qi-hardware
rz2k has quit [Read error: Connection reset by peer]
wolfspraul has joined #qi-hardware
mth has quit []
xiangfu has joined #qi-hardware
panda|x201 has quit [Ping timeout: 252 seconds]
wolfspraul has quit [Ping timeout: 240 seconds]
panda|x201 has joined #qi-hardware
porchao has quit [Ping timeout: 240 seconds]
freespace has quit [Ping timeout: 240 seconds]
freespace has joined #qi-hardware
porchao has joined #qi-hardware
eintopf has quit [Remote host closed the connection]
eintopf has joined #qi-hardware
eintopf has quit [Remote host closed the connection]
mth has joined #qi-hardware
panda|x201 has quit [Ping timeout: 268 seconds]
<DocScrutinizer05>
wpwrak: the uSD slot IS externally available, and we even change from detecting card-presence (aka umount) via hall switch and magnet in battery lid to a true switch integrated into uSD tray
<DocScrutinizer05>
we're not considering 6lowPan a common enough feature to integrate it into Neo900
<whitequark>
DocScrutinizer05: 30k \o/
<DocScrutinizer05>
DocScrutinizer05: you bet we err *I* personally will take care to expose a damn wealth of "testpoints" to the battery bay
<whitequark>
talking to yourself?
<DocScrutinizer05>
ooh, already? A started worrying snce no donations for 4h
<DocScrutinizer05>
dang
<whitequark>
well, almost
<DocScrutinizer05>
wpwrak: you bet we err *I* personally will take care to expose a damn wealth of "testpoints" to the battery bay
<whitequark>
29810
<DocScrutinizer05>
mhm, so still 29830?
<DocScrutinizer05>
or 810
<DocScrutinizer05>
that's like this since 4h already
<DocScrutinizer05>
:-/
<DocScrutinizer05>
and Dos not around to finally install a new more encouraging progess bar and send out a newletter that doesn't sound like "thanks folks, we reached our goal"
<whitequark>
yeah I was surprised about it. can't you just get more money? since you don't have any fixed production run planned anyway
<DocScrutinizer05>
but it's pretty poorly communicated
<wpwrak>
you could overlay the progress bar with a growing arrow, for then next 25k :)
<wpwrak>
or just keep the bar size fixed and scale the marks
<DocScrutinizer05>
we're more interested in number of donors now
<DocScrutinizer05>
I already suggested to replace the amount€ progress bar by a number-donors one, with a intermediat goal of 200 and a preliminary final goal of 1000
<whitequark>
and you really should post on /., HN, etc again
<whitequark>
"we've got this much people, let's get twice more!"
<DocScrutinizer05>
we don't *need* more funds actually, we need more customers documenting they're willing to buy a device once we go MP
<wpwrak>
number of donors is a somewhat obscure metric. some may say that fewer would be better. also, donors are a subset of potential buyers.
<wpwrak>
and you don't know how big/small a subset they are. especially now, since you've reached your goal and there's no incentive to put more money at the moment.
<wpwrak>
i guess the question is: what are the parts where you need large numbers ?
<wpwrak>
also, 1000 seems pretty small for custom parts. at least if they're have a relatively low unic cost, like connectors
<DocScrutinizer05>
well, do you think I should write a 3pages whitepaper on that to explain the idea to customers?
<DocScrutinizer05>
for fab line it makes a damn difference if we run a batch of 200 or a batch of 1000
<DocScrutinizer05>
both for fixed costs of line setup as well as for component cost since we might not need to retape components when we use significantly >>200
xiangfu has quit [Remote host closed the connection]
<DocScrutinizer05>
for real custom made stuff the situation is even more obvious, think the spacer frame we need to get built
<DocScrutinizer05>
for 2k PCB we might start to consider going the original icky integrated-FPC-to-doughterboard approach that Nokia opted for
<DocScrutinizer05>
we even might consider going PCB with embedded components, which is the new hype and has quite some advantages
<wpwrak>
yes, for SMT you need about 1000 units, minimum. but that's for later.
<wpwrak>
embedded components, how does that work ?
<whitequark>
DocScrutinizer05: pcb with embedded components?!
<DocScrutinizer05>
no, that's for now, since we need to plan out path ahead
<wpwrak>
ah, you're not sure yet about the future volume. i see. i would have thought you assumed you'd be able to sell > 1000 units when done anyway. (that is, unless you run into debilitating problems, which we all hope you won't)
<DocScrutinizer05>
how that works? exactly like you think it would. PCB manuf placing chips and discrete components between the PCB layers
<DocScrutinizer05>
no, we will produce to order
<wpwrak>
hmm. goodbye rework.
<DocScrutinizer05>
hello density and reliability
<wpwrak>
(produce to order) you'll have to make batches. so it would seem to be a separate step. well, doens't matter. a bit of overplanning can't hurt :)
<DocScrutinizer05>
it not only hurts, it might kill us
<wpwrak>
(reliability) is the process already well-established ? it's the first time i hear of it
<DocScrutinizer05>
we can't afford to buy 1000 N900 for spare parts, just to find we can stash 800 of them to the attic
<wpwrak>
have you tried to reach the makers of replacement parts ?
<DocScrutinizer05>
we gonna produce strictly to order (+ spare for warranty)
<DocScrutinizer05>
we haven't tried anything like that yet
<wpwrak>
and 1000 small donations won't help you with buying 1000 N900 either. so i think whether you have 1000 or 100 wouldn't change your strategy at that point.
<DocScrutinizer05>
since we don't even know about which volumes we talk
<DocScrutinizer05>
1000 donations of 100EUR make 1000 customes who already paid for their N900
<wpwrak>
i'd say "think openmoko". likely more, since now a lot more people know smartphones and frustration with the established players is increasing
<DocScrutinizer05>
uh?
<DocScrutinizer05>
sorry you lost me
<wpwrak>
for volume. expect to be able to sell at least about as many units as openmoko sold
<DocScrutinizer05>
HAH that would be nice
<wpwrak>
(N900) oh,they're that cheap. i see.
<DocScrutinizer05>
but pretty utopistic
<wpwrak>
your project has a number of advantages: 1) safer hardware choices, 2) proven software package, 3) tending to a larger market
<DocScrutinizer05>
I'm, not gambling. I have no capital to gamble with
<wpwrak>
now you do :) and it's not gambling. it's just working with the right expectations. if you expect to handle the first 1000 units by recycling old N900, fine. there you have a data point you can work with.
<DocScrutinizer05>
we're going thru development phase now, which will look different for many aspects, depending on whether we plan for 200 or for 2k devices to manufacture. Once we are MP ready and open true preorder site where people pay in advance to receive their device 6 weeks later, we might even have to close down the order page once we exceed the amount of orders we anticipated and calculated with
<wpwrak>
how about the next 10k ? would that still work or would supplies dry up ? that's why you'd want to talk to the replacement parts suppliers. maybe they can also help you with parts you didn't find. depends a bit on how they operate.
<DocScrutinizer05>
a few icky nasty little shitty things get in our way maybe: SMIA95 camera socket
<DocScrutinizer05>
no issues with getting 100k N900 spare cases
<wpwrak>
kewl :)
<DocScrutinizer05>
but we might not be able to source a single SMIA95 socket
<DocScrutinizer05>
ok, we might completely swap camera design then
<DocScrutinizer05>
go for a 12MP module with a more usual socket
<DocScrutinizer05>
but that's *risk* again
<DocScrutinizer05>
and who knows how good the manuf support for firmware is with such a solution
<wpwrak>
yeah. well, we know the drill :)
<DocScrutinizer05>
you know all cam modules/chips need rather proprietary custom made to fit postprocessing to gain a certain level of quality
<DocScrutinizer05>
for N900 5MP cam we got that, in Fremantle
<DocScrutinizer05>
for any other cam we are probably back to cam quality of fremantle PR1.0 which been *erhem* *cough*
<wpwrak>
i guess there must be some common sets of algorithms. researchers may have some libraries you could steal from.
<DocScrutinizer05>
sure, but in the end only the chip manuf knows all the idiosyncrasies of their cmos chip
<wpwrak>
as long as they cause visible results you can fix them :)
<DocScrutinizer05>
or we start a research project that analyzes the chip's pictures for artifacts and other unwanted stuff and develops/adapts the needed algo
<wpwrak>
your main risk would be to apply an algorithm in the wrong situation. that happens. you can always have a "raw" option to bypass that.
<DocScrutinizer05>
first pictures of N900 had terrible color noise, false colors, whatnot else
<DocScrutinizer05>
the flash is "green"
<DocScrutinizer05>
dunno what else
<wpwrak>
;-))
<wpwrak>
that's what you get for stealing martian technology :)
<DocScrutinizer05>
s/of N900/taken with N900/
<wpwrak>
anyway, if all that can be fixed in sw, then you may not have to worry all that much about it. and you already know what to expect, so you won't panic if it looks evil.
<DocScrutinizer05>
then a whole university and Nokia joint task force worked on the cam drivers (google fcam) and with PR1.1 or PR1.2 finally N900 pic quality became usable
<wpwrak>
nasty martians. one extra tooth and they're pointier, too
<larsc>
DocScrutinizer05: are you going to be at the ohsw?
<roh>
nice
<whitequark>
dude
<whitequark>
where's cde when you need him.
viric has quit [Ping timeout: 240 seconds]
viric has joined #qi-hardware
bzb has joined #qi-hardware
valhalla has joined #qi-hardware
valhalla_ has quit [Ping timeout: 245 seconds]
<whitequark>
!seen cde
<qi-bot>
whitequark, cde (~cde@fsf/member/cde) was last seen quitting #milkymist 1 day 23 hours 38 minutes ago (03.11. 19:59) stating "Quit: Lost terminal" after spending some time there.
<whitequark>
sigh
bzb has quit [Read error: Connection reset by peer]
bzb has joined #qi-hardware
<wpwrak>
ooh, now that you're among the righ and famous, something like EUR 2000 per day is "zilch" now ! :)
<dos1>
:D
bzb has quit [Ping timeout: 245 seconds]
_whitelogger has joined #qi-hardware
rzk has joined #qi-hardware
rz2k has quit [Ping timeout: 252 seconds]
<apelete>
larsc mth: Hello
<larsc>
hi apelete
<apelete>
what's up ? felt like it's been a while since we talked
<larsc>
yea, been busy
<apelete>
because of ELCE ?
<larsc>
and work
<larsc>
and life
<apelete>
ha ha :)
<apelete>
anyway, I'm having a hard time trying to figure out why the musb driver fails to detect endpoints for jz4740
<apelete>
I'm guessind it may be because the udc is not powered on, but I can't figure out how to power on the damn thing
<larsc>
the only thing that needs to be done is to enable the clocks
<apelete>
larsc: so, I'm going to try something, and how would like you to tell me how reckless/foolish this is :-)
<larsc>
Don't plug the USB cable into mains, if that's what you wanted to do
<dos1>
:)
<apelete>
:)
<apelete>
larsc: clocks seems to be enabled already, but I saw the jzA749_udc driver was "powering on" the device by writing to the power reg:
<apelete>
/* Let host detect UDC:
<apelete>
* transistor on and pull the USBDP pin HIGH.
<apelete>
* Software must write a 1 to the PMR:USB_POWER_SOFTCONN bit to turn this
<apelete>
larsc: so, I would like to try the same by calling musb_pullup() from within the glue code. how stupid/dangerous do you think that is ?
<larsc>
shouldn't cause any problems
<larsc>
but I don't think it will help reading the descs either
jekhor has quit [Ping timeout: 264 seconds]
<apelete>
larsc: hmmm, shouldn't cause any problem even with the usb cable plugged into mains ? (using battery is not convenient because of serial line, so I'm using usb cable as power source for the device)
<apelete>
I looked into the clock gate register before, with mth's help, and the clock seems to be running already, so that's my best clue right now
<larsc>
there are two clocks
<apelete>
ha
<larsc>
or well the bit in the gate register only enables/disables autosuspend
<larsc>
but the real udc clock is enabled/disabled by bit 6 in the SLEEP_CTRL register
<larsc>
in the clock core
<wpwrak>
apelete: if you're in a device role, maybe there's also a way to detect SOF reception. many usb blocks have an SOF interrupt, counter, or frame number register. seeing an SOF will tell you that the low-level stuff is working.
<apelete>
larsc: clock activation in glue layer is as follow:
<apelete>
clk = devm_clk_get(&pdev->dev, "udc");
<apelete>
dev_err(&pdev->dev, "failed to get clock\n");
<apelete>
if (IS_ERR(clk)) {
<apelete>
ret = PTR_ERR(clk);
<apelete>
goto err2;
<apelete>
}
<apelete>
<apelete>
ret = clk_prepare_enable(clk);
<apelete>
if (ret) {
<apelete>
dev_err(&pdev->dev, "failed to enable clock\n");
<apelete>
goto err3;
<apelete>
}
<apelete>
wpwrak: what does SOF stand for ?
<larsc>
apelete: you can check the clock state in debugfs /sys/kernel/debug/jz4740-clock/
<wpwrak>
Start Of Frame
<wpwrak>
e.g., a full-speed usb host generates one every 1 ms.
<wpwrak>
too lazy to look what rate high-speed uses. i think low-speed is also 1 ms, but without sending a frame number. (on low-speed SOF is not a full token)
<larsc>
but that comes much later
<larsc>
apelete: It might be that the hardware simply does not report any endpoint information
<apelete>
larsc: I'm rebuilding a kernel image to look at clock state in debugfs but, what do I do if hardware is not reporting endpoint information ?
<apelete>
hardcode it in the glue code ?
<larsc>
hardcode them
<apelete>
wow :-)
<larsc>
the musb code seems to have support for this