lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: Something to do? https://github.com/milkymist/bugs/issues
<wpwrak> wolfspraul: and there are analog domain differences in the transformer circuits that may or may not be real-life differences
<wpwrak> if the circuit has subtle flaws, this could mean more bit errors, shorter maximum cable length, and so on. but i don't know if there's actually any issue. maybe all those things that look different aren't.
voidcoder has joined #milkymist
voidcoder has joined #milkymist
<wpwrak> hmm. this kind of page scares me: http://thedmxwiki.com/definitions/dmx_terminator
<wpwrak> "If the addition of a terminator causes problems in your chain, it is likely down to poor quality DMX Cable."
<wpwrak> does that mean devices aren't expected to already have termination ? or are they trying to say multiple termination is okay ?
<lekernel> some devices have just the input connected directly to the output, and the RX circuit "tapped" on it (without termination)
<lekernel> what we are doing is RX -> termination -> receiver (to 3.3V logic) -> transmitter (from 3.3V logic)
<lekernel> there's no problem with that
<wpwrak> oh, i see. i saw a termination switch mentioned. i guess that's not something we'd want to consider ?
cladamw has joined #milkymist
<wolfspraul> reading about power switch for mmc worries me :-)
<wolfspraul> at first glance the R4 bom cost went up about 30 USD from R3, and again at first glance I see a lot of quite expensive new switch/protection stuff
<wolfspraul> the will require some more detailed study and work later to analyze and optimize - not now
<wolfspraul> maybe after the whole thing is boomified would be a good time
hypermodern has joined #milkymist
<wpwrak> yeah, we added quite a bit of stuff in the end
xiangfu has joined #milkymist
cozyspell has joined #milkymist
<wolfspraul> well. do you have any candidates that can be removed right away? :-)
<wolfspraul> I think we leave everything as-is now, and wait until we have boom ready then we can do a really effective costing-down.
<wpwrak> i think it's more a question of removing functional groups than of tweaking components
<wolfspraul> while our volumes are low we can afford a little over-engineered/crowded board
<wolfspraul> but maybe here and there less is more :-)
<wpwrak> i think it's best to start with many possibilities. then see what actually gets used.
<wolfspraul> sure. I am also wondering whether there are unnecessary/overly conservative protection parts on the board now, electrical stuff that you wouldn't find in a normal consumer product
<wolfspraul> but like I said, I think we can leave everything as-is now, wait for boom, and then look at it effectively cost-wise
<wolfspraul> I care less about being overly protective electrically than I care about expensive parts, too many different vendors, too many parts, parts with EOL problems, etc.
<wolfspraul> also large parts
hypermodern has joined #milkymist
<GitHub25> [flickernoise] xiangfu pushed 1 new commit to master: http://git.io/ht4hzg
<GitHub25> [flickernoise/master] Ctrl+H : display keyboard shortcut information - Xiangfu
<wpwrak> nice :)
<xiangfu> wpwrak, I even don't know those shortcuts before this patch. :-)
<wpwrak> i think only sebastien knows them. maybe :)
<wolfspraul> xiangfu: can cursor left and right go backward and forward in the patch list?
<xiangfu> wolfspraul, no.
<wolfspraul> no I mean, of course they cannot do that right now. but can we add it? :-)
<xiangfu> wolfspraul, Ctrl+H . again and again. it will display message one by one.
<wolfspraul> cursor-left: previous patch. cursor-right: next patch
<xiangfu> wolfspraul, oh. yes of cause we can add it and it is easy :)
<wolfspraul> great
<wolfspraul> how about audio sensitivity?
<xiangfu> the audio sensitivity bug? not working on that yet.
<wolfspraul> no
<wolfspraul> 2 keys so we can increase and decrease audio volume
<xiangfu> no such shortcut yet.
<wolfspraul> I say just start simple and put it on cursor-up and cursor-down
<wpwrak> xiangfu: btw, you may want to add "static" and "const" to the "help" array. also, it's not a good idea to use the same name for a global and a local symbol. if we enabled -Wshadow, you'd get a warning
<wpwrak> if you only show one message at a time, you may wan to reduce the number of messages. e.g., combine increase/decrease in one. don't show Ctrl-H, because the user has found that one already
<wpwrak> and you have F1 twice :)
<xiangfu> F1. yes that is in different mode.
<xiangfu> simple mode F1 means patch name
<xiangfu> configured mdoe F1 means video-in
<wpwrak> phew :)
<wolfspraul> ouch
<wolfspraul> I'd say focus on simple mode
<wpwrak> at least you don't have to use morse code to express your wishes ;-)
<wolfspraul> no help in configured mode
<xiangfu> I try to combine to one line. but the OSD display font is not very good on format. so I just give up and commit first :)
<wpwrak> maybe disentangle the hotkeys while we're at it ?
<xiangfu> wpwrak, improve later. :)
<wolfspraul> xiangfu: focus on simple mode
<wpwrak> NB: if you take one of those little rf keyboards, about half the of those hotkeys may not even be available
<xiangfu> wolfspraul, yes. agree. :)
<wolfspraul> wpwrak: that's next
<xiangfu> wolfspraul, we should re-enable all midi / osc etc patches on simple mode.
<wolfspraul> the shipment of 20 Riitek keyboards is on the way to Adam as we chat
<wolfspraul> once they arrive, I will remove the silicone keyboard for good
<wpwrak> heh ;-)
<wolfspraul> I will leave the remotes in the box until they are out of stock, but then not refill.
<wpwrak> which model did you choose in the end ?
<wpwrak> will you keep the IR sensor ?
<wolfspraul> I think we should keep it, yes.
<wolfspraul> there could be interesting applications later and if it's about BoM cost, there is A LOT of other stuff we can optimize.
<wpwrak> okay. let's revisit the quesiton when the time comes for M1rc5 or M2 ;-)
<wpwrak> and you switch from acrylic walls to something else. then realize you now need an IR-transparent window. etc. :)
<wolfspraul> I wouldn't even care making it dysfunctional without removing the ics.
<wolfspraul> nobody uses it anyway
<wolfspraul> I will strictly just go step by step to improve actual product usage.
<wolfspraul> in users hands, not theoretically
<wpwrak> then you may as well remove the chips :) well, in > M1r4
<wolfspraul> and we have quite a few guys now who want to use their m1 more, but they are facing this or that real-life problem. I work on fixing them.
<wolfspraul> btw, the two ADI codecs for the r4 design-verification run are with Adam now, vga and video-in (adv7181c)
<wolfspraul> I just got fed up with ADI official channels and we bought in shenzhen grey, and 2 days later they are at Adam's
<wpwrak> great !
<wpwrak> heh :)
<wpwrak> let's hope they are what they claim they are :)
<wolfspraul> sure, will be
<wolfspraul> I replied to all questions from ADI, but even though my mails got friendlier and friendlier, zero replies
<wolfspraul> the last one was the friendliest with me telling them that the problem had gone away thanks to shenzhen, and thanking them for their generous help
<wolfspraul> I did get some "out of the office until xx-xx" auto-replies though
<wolfspraul> but of course I understand their problem, basically they cannot afford to write even a 1-line email to any customer odering less than.. what... 10k chips? 100k? :-)
<wolfspraul> anyway, problem solved
<wolfspraul> in the long run I am hoping we go all digital for video-in and out and can remove those codecs from our pcb
<wpwrak> hmm yes. a good objective for 2022 :)
<xiangfu> wpwrak, we have a lot of 'shadows a global declaration'
<wolfspraul> nah, if we can pickup some speed it can be much faster. but one by one, sure. the product must stay working.
<wpwrak> yes :)
<GitHub3> [flickernoise] xiangfu pushed 1 new commit to master: http://git.io/rhheXA
<GitHub3> [flickernoise/master] disable mouse click exit rendering mode - Xiangfu
<wpwrak> wolfspraul: i don't think the global obsolescence process isn't seriously affected by our speed :) of course, you can just cut off analog-using users ...
<kristianpaul> finally! :) (commit)
<wolfspraul> wpwrak: oh, not at all [cut off]. let's see how the codec situation evolves.
<cladamw> (C126) wpwrak thanks, Nice catch ! It can be 470nF which bom has it, see my replied. We didn't review carefully after changed from TSOP4838 to TSOP34838.
<kristianpaul> wpwrak: btw where is that thread you made to catch user input from kbd?..
<cladamw> (Varistors) all their symbols I changed them being as likely diac. so can't be faced as coil or bead or choke.
<kristianpaul> ah debug navre i guess
<cladamw> Ah~ from werner's great reviews, there're more mistakes discovered while I had made before. :( No excuse though.
<cladamw> it seems that was quite hard to find mistakes in details in 1 ~ 2 persons. but one Werner beats our manual works.
<cladamw> i hope the sooner boom system can really avoid all of these.
<cladamw> wpwrak, don't know how to say thanks to you.
<qi-bot> The firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120314-0248/
cladamw has joined #milkymist
rejon has joined #milkymist
xiangfu has joined #milkymist
rejon has joined #milkymist
rejon has joined #milkymist
radii has joined #milkymist
lekernel_ has joined #milkymist
<qi-bot> The firmware (using branch) build was successful, checkout the VERSIONS for detail, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120314-0428/
cladamw has joined #milkymist
rejon has joined #milkymist
<qi-bot> The firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120314-0610/
<wolfspraul> maybe the bot should only announce failed builds?
<wolfspraul> if we commit often and each commit triggers a build, then failure is far more important to be reported than success (which should be the norm)
<xiangfu> the build host is doing like:
<xiangfu> 1. check new commit compile milkymist-firmware --> check new commit compile a branch milkymist firmware --> check new commit compile ben Nanonote image.
<xiangfu> the step_3 is usually needs ~40 hours.
<xiangfu> since I am working on the nanonote. so I disable build nanonote today. then it's will only build milkymist stuff. each build about ~2 hours.
<xiangfu> wolfspraul, in fact I think those build success information is ok. even one message every 2 hours I can accept that :)
<xiangfu> as lease I know build host is working :)
elldekaa has joined #milkymist
<wolfspraul> hmm
<wolfspraul> ok :-)
azonenberg has joined #milkymist
xiangfu has joined #milkymist
<wpwrak> cladamw: ah, there were more issues ? checking the mails ... :)
<cladamw> wpwrak, hi no, i'm just still digest your mails, i only replied that what i knew or i can do. ;-)
<wpwrak> cladamw: btw, the "killer tool" for the reviews is "dsv". boom doesn't really enter the picture here. boom is more a "spend less time doing boring stuff like looking up 530 Ohm resistors" tool
<cladamw> (TBD on my site) like 150uF with low ESR check, ...
Martoni has joined #milkymist
<cladamw> "dsv" okay, since your discoveries that I knew how they went through before. U3/C126/C120 were the problems we fixed but didn't review carefully. :(
elldekaa has joined #milkymist
<cladamw> since you may continue to review other sch pages, I'll reply asap. then later i generate a whole pdf after go through all reviews. Much thanks for your reviews. But i am curious why still no else can join. hehe :(
<wpwrak> yeah, participation is a bit disappointing
<wpwrak> joerg has made a few small comments. maybe there will be more
<cladamw> wpwrak, i am editing a page which will house to know idea: http://en.qi-hardware.com/wiki/Milkymist_One_Layout_Criteria/zh_tw
<cladamw> but one *ps file I may need your help to update. :-)
<wolfspraul> there is no/very little culture of collaboration in hardware
<wolfspraul> we try to jumpstart it but well, either we do something wrong or it's hard or just never will take off
<cladamw> http://downloads.qi-hardware.com/people/werner/tmp/xbrd.ps could you update this file according to 10*2 female dimensions ? No need now, but later when you're available.
<wolfspraul> I think eventually it will
<cladamw> oah..yeah..much thanks joerg too.
<wpwrak> i guess we're either lacking critical mass or didn't announce the review properly. maybe people didn't understand that this is a "free for all", not just the usual suspect slugging each other in public
<cladamw> wpwrak, i just saw your replied on C120. since from M1rc1 the U3 we always used SO5032 with 10nF.
<wpwrak> (note the name change. in the future, we'll also gave other views, hence the addition of "-top")
<cladamw> wow...so fast ! thanks.
<wpwrak> also note that this isn't a specification (yet), just a draft for possible dimenstions. layout will determine what actually works and i'll update the specification from that
<wpwrak> (fast) the joy of parametric cad ;-)
<cladamw> so I should remove " In practice..." as well as no need those mentions, better ?
rejon has joined #milkymist
<wpwrak> since we're using SO5032, why not change C120 to 100 nF ?
<cladamw> since no experiments, and from rc1 to rc3, they works well, no ? of course we can change C120 to 100nF in M1r4( only 8pcs will be produced )
<cladamw> so if the results from those 8 pcs after m1r4, then we keep 100nF, or think that 10nF, 100nF won't influence much at all. sorry i don't know now. :-)
<wpwrak> you can always try and rework an existing board ;-)
<wpwrak> but i don't think we really need to test this. going from 10 nF to 100 nF seems to be a safe change, particularly since it's what the data sheet suggests anyway
<wpwrak> the problem with "it works" is that we don't know where in the parameter space we are, also regarding component production tolerances
<cladamw> mmm..okay, so I'll change C120 to 100nF for SO5032, thanks for explains. :)
<cladamw> also change U3's name to SO5032.
<wpwrak> kewl, thanks !
Scopeuk has joined #milkymist
<GitHub109> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/5c0cc6292c440e19dab5594477452769ca37dd71
<GitHub109> [migen/master] fhdl: export log2_int - Sebastien Bourdeauducq
cladamw has joined #milkymist
<wpwrak> hmm ... no comment on R54 today ? :)
VJTachyon has joined #milkymist
<lekernel> wpwrak: you can play with the value, but it does have impact on the signal levels
<lekernel> and the opto can pull 60mA/dissipate 100mW so it should be ok, even if it's not power efficient
<lekernel> max power you can get from that resistor is 23mW
elldekaa has joined #milkymist
<kristianpaul> wpwrak: thanks !
azonenberg has joined #milkymist
<GitHub48> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/1665f293a619b6b989031fb5b293df9509f57600
<GitHub48> [migen/master] bus/asmibus/hub: require finalization before get_slots - Sebastien Bourdeauducq
<wpwrak> lekernel (60 mA) ah, right. i got the wrong side.
<wpwrak> lekernel: still seems very low, though. did you experience problems with larger values ?
<lekernel> can't exactly remember... but yes, there has been some tweaking to get a proper signal
<lekernel> there's probably a large margin with the current value though
<lekernel> but values in the kohm range do cause problems
<wpwrak> it should be input leakage plus anything we lose due to parasitic capacitance, no ?
<lekernel> there are problems with rise/fall times too
<lekernel> optoisolators are slow devices
<wpwrak> with a cut-off frequency of 1 MHz (> 20x the bit rate) and a parasitic capacitance of 50 pF, i get .... 3.3 kOhm
<wpwrak> slow edges at the source should actually help, as far as moving parasitic capacitance is concerned
<wpwrak> or at least not make things worse
<wpwrak> do you remember what value you had trouble with >
<lekernel> with the first optoisolator the problem was extreme
<wpwrak> if it was 100 kOhm, that would make perfect sense. perhaps even 10 kOhm.
<lekernel> (we changed it with that model later)
<wpwrak> ah, i see
<lekernel> you could pass only up to a few kHz, all the rest was filtered out - unless you put a ridiculously low resistor, which would damage the opto
<lekernel> this one has better characteristics
<lekernel> you can experiment with it if you wish, but as far as I'm concerned I believe in the old saying - if it ain't broken, don't fix it :)
<lekernel> the opto is operating within specs, gives a good signal, and uses a relatively small amount of power. what more can we wish for? :)
<wpwrak> hmm, almost 3% of the entire power budget of the M1 ;-) (not counting USB, i.e., assuming 5 W = 1 A)
<wpwrak> it's good that we don't have dozens of MIDI interfaces. else, M1 would feature a cooling tower like you find on modern CPUs ;-)
LmAt has joined #milkymist
hypermodern has joined #milkymist
kilae has joined #milkymist
<GitHub78> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/ByEWgA
<GitHub78> [milkymist-ng/master] asmicon: skeleton - Sebastien Bourdeauducq
VJTachyon has joined #milkymist
LmtdAt has joined #milkymist
cozy has joined #milkymist
elldekaa has joined #milkymist
VJTachyon has joined #milkymist
voidcoder has joined #milkymist
pablojavier has joined #milkymist
pablojavier has quit [#milkymist]
proppy has joined #milkymist