<wpwrak>
that's the only .cn data sheet i have at the moment. then a few semi-obscure .tw
<wolfspraul>
ok
<wolfspraul>
problem seems contained, good ;-)
<wolfspraul>
if we parameterize well and have multiple suppliers and just pick a chinese one because of price (assuming we think quality is ok), then that's fine
<wolfspraul>
but in general you have to visit chinese companies
<wolfspraul>
really
<wolfspraul>
:-)
<wpwrak>
we laso have a few farnell and one octopart "data sheet reference". haven't gotten to these yet. i'm sure they'll be entertaining :)
<wolfspraul>
that's the reason so many chinese prefer to buy imported/foreign managed products, because finding quality chinese is so time consuming
<roh>
i really hope octoparts adds 'location' soon.
<roh>
as in 'i am in asia/us/europe' and list local sellers first
<wolfspraul>
they exist of course, the problem is not 'china' but the fact that the market is essentially unregulated and chaotic, everybody tries whatever they want
<wolfspraul>
roh I am not following octopart closely but I do admire your passion for them :-)
<wolfspraul>
so if you tell me one day they are really good, I know I better listen
<wolfspraul>
for now I think they are in a hopeless position
<roh>
wolfspraul: ;) i know how hard comparing sources on electronic parts can be. so i can understand what giant maddening problems they went against
<roh>
i think octoparts should add a rating system for sellers. could make finding quality sources easier.
<roh>
in the end its a tradeoff between quality and money, but thats ok as long as its transparent
<wolfspraul>
yes but nobody will want to be rated 'fairly' :-)
<wolfspraul>
I want to get away with my little cheat on quality
<roh>
no worries. we do qc much more paranoid than what i'd like to 'out'
<wolfspraul>
it's amazing if you think about it in low margin products, how big the difference is between skipping some tests or not
<roh>
basically you only need to downvote sellers which sell broken/relabeled/fake parts
<wolfspraul>
anyway we all know the almost infinite details in this
<wolfspraul>
I like that boom starts with digikey
<wolfspraul>
and we later maybe add other 'quality' distributors
<wolfspraul>
one by one as we know them
<wolfspraul>
and then we parameterize as much as possible, making it easier to source parts from different manufacturers
<wolfspraul>
finally I would try to reduce the number of manufacturers we source from at all
<wolfspraul>
and yes, the holy grail is quality and price
<wolfspraul>
and documentation
<wolfspraul>
and availability
<wolfspraul>
and ... :-)
<roh>
i think currently we just chose digikey to get good quality without thinking/testing ourselves, right?
<wolfspraul>
oh, I'm also very open minded to giving small new manufacturers a chance. that's something we can do that the large guys cannot risk.
<wolfspraul>
but that needs to be a controlled thing then where we really trust that small/tiny manufacturer...
<wolfspraul>
roh: we are testing the entire assembled pcb, quite good nowadays
<roh>
true. but we have no incoming qc?
<wolfspraul>
case by case, you can imagine everybody checks a bit
<roh>
just asking.. i had weird screws in the bags etc.
<wolfspraul>
of course adam goes through, checks this or that
<wolfspraul>
everything? nah, impossible
<roh>
missing threads etc. i think one slipped through to adam even
<wolfspraul>
systematic, following a plan? I doubt it, and it's not worth to formalize it to that level right now
<wolfspraul>
oh yes, I can imagine [threads]
<roh>
everything only works when a machine does it
<wolfspraul>
then the SMT shop does checks before loading their machine
<wolfspraul>
but we also need to do things practically because of our small runs
<wolfspraul>
I think the balance is right
<wolfspraul>
and as I think you know we suffered a little from what were probably fake TI schmitt-triggers
<wolfspraul>
I say 'probably' because you never really know and we cannot start an investigation or hire detectives :-)
<roh>
yes
<wolfspraul>
there were also inexplicably high failure rates with the usb transceivers
<wolfspraul>
well u know how it is...
<wolfspraul>
but I am making 100% tested products, there has to be some work and risk in doing that
<wolfspraul>
it's fine
<wpwrak>
at low volume and high value per device, also some amount of rework is acceptable
<roh>
n8
<wolfspraul>
n8
cladamw has joined #milkymist
wolfspraul has joined #milkymist
xiangfu has joined #milkymist
<cladamw>
(J1/J2 datasheet) yes, i found that vendor changed their pin assignments number when I added/checked for insertion/removal, but the footprint in design files are correct to its real mechanical number. If i fix this, means that we also need to fix footprint library but will uncorresponding to previous rc3 version.
<cladamw>
(C2/C6) was kept to the same as previous codec lm4550b, since in rc3's design verification stage we agreed to the performance of audio noise after dropping wm9707 codec. If we'd like to follow wm9707's recommended parts which is also okay.
<cladamw>
(C6 polarized) This can be unpolarized if we follow wm9707.
<cladamw>
(R1) it's also came from previous codec.
<cladamw>
wpwrak, all those are messy and from that we tried to downgrade or upgrade with compatibility, so if we now ignore this, then we stick to all new codec recommendations. is okay to me, how about you ?
<cladamw>
although we already knew the new noise is less than older one.
<GitHub18>
[scripts] xiangfu pushed 1 new commit to master: http://git.io/NqUu2A
<GitHub18>
[scripts/master] update build with new softusb-input.h structure - Xiangfu Liu
<wpwrak>
(J1/J2) ah, good.
<wpwrak>
yes, i think we should update the design for the new codec. it's not a lot of things and those changes should be very safe.
<wpwrak>
and i think we're sure that we don't want to go back to the old codec ;-)
<wpwrak>
keeping too much old stuff around just makes it hard to make changes in the future, because at some point, nobody will remember why certain things are there
<kristianpaul>
migen and gtkterm ;D
<wpwrak>
cladamw: if you don't want to change J1/J2, then you should mention in the schematics that this is based on an older version of the vendor's design and that it's coordinated with the footprint.
<kristianpaul>
i dont see clogb2 support in iverlog..
<kristianpaul>
neither verilator..
<cladamw>
wpwrak, okay that we can directly change/follow new codec. To (J1/J2) I'll mention it.
<cladamw>
(TVS on MIDI TX ?) don't know if add it. ;-)
<wpwrak>
if there's no explicit reason not to have it, then it should probably be added. i mean, i think it's the only place left
<wpwrak>
where we don't have TVS ;-)
<cladamw>
(common minimum voltage) on first schematic sheet which is good idea, so it's being to the 6.3V i think for the common.
<cladamw>
wpwrak, to use the same TVS as DVI ? or the audio in/out loop we'd have ?
* kristianpaul
considers again use clog2 instead of clogb2
<kristianpaul>
now where is that test bench....
<wpwrak>
i think the ones for audio should be more than sufficient. the DVI ones seem quite sophisticated
qwebirc37594 has joined #milkymist
<cladamw>
wpwrak, okay.
rejon has joined #milkymist
<cladamw>
(J1/J2) wpwrak, for a better safe, yes. after thinking. I'll edit J1/J2 schematic library to coordinate its assigned number(pin4 and pin 5 swapped).
<cladamw>
wpwrak, what do you mean ? >> "could we find a less creative placement of the "1%" at R164 and R165 ? "