| wpwrak | wolfspraul: and there are analog domain differences in the transformer circuits that may or may not be real-life differences | 00:00 |
|---|---|---|
| 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. | 00:01 |
| wpwrak | hmm. this kind of page scares me: http://thedmxwiki.com/definitions/dmx_terminator | 00:06 |
| wpwrak | "If the addition of a terminator causes problems in your chain, it is likely down to poor quality DMX Cable." | 00:07 |
| wpwrak | does that mean devices aren't expected to already have termination ? or are they trying to say multiple termination is okay ? | 00:07 |
| lekernel | some devices have just the input connected directly to the output, and the RX circuit "tapped" on it (without termination) | 00:11 |
| lekernel | what we are doing is RX -> termination -> receiver (to 3.3V logic) -> transmitter (from 3.3V logic) | 00:12 |
| lekernel | there's no problem with that | 00:12 |
| wpwrak | oh, i see. i saw a termination switch mentioned. i guess that's not something we'd want to consider ? | 00:15 |
| wolfspraul | reading about power switch for mmc worries me :-) | 01:00 |
| 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 | 01:00 |
| wolfspraul | the will require some more detailed study and work later to analyze and optimize - not now | 01:00 |
| wolfspraul | maybe after the whole thing is boomified would be a good time | 01:01 |
| wpwrak | yeah, we added quite a bit of stuff in the end | 01:11 |
| wolfspraul | well. do you have any candidates that can be removed right away? :-) | 01:18 |
| 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. | 01:19 |
| wpwrak | i think it's more a question of removing functional groups than of tweaking components | 01:19 |
| wolfspraul | while our volumes are low we can afford a little over-engineered/crowded board | 01:20 |
| wolfspraul | but maybe here and there less is more :-) | 01:20 |
| wpwrak | i think it's best to start with many possibilities. then see what actually gets used. | 01:21 |
| 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 | 01:21 |
| 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 | 01:22 |
| 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. | 01:24 |
| wolfspraul | also large parts | 01:25 |
| GitHub25 | [flickernoise] xiangfu pushed 1 new commit to master: http://git.io/ht4hzg | 01:38 |
| GitHub25 | [flickernoise/master] Ctrl+H : display keyboard shortcut information - Xiangfu | 01:38 |
| wpwrak | nice :) | 01:40 |
| xiangfu | wpwrak, I even don't know those shortcuts before this patch. :-) | 01:41 |
| wpwrak | i think only sebastien knows them. maybe :) | 01:42 |
| wolfspraul | xiangfu: can cursor left and right go backward and forward in the patch list? | 01:47 |
| xiangfu | wolfspraul, no. | 01:49 |
| wolfspraul | no I mean, of course they cannot do that right now. but can we add it? :-) | 01:50 |
| xiangfu | wolfspraul, Ctrl+H . again and again. it will display message one by one. | 01:50 |
| wolfspraul | cursor-left: previous patch. cursor-right: next patch | 01:50 |
| xiangfu | wolfspraul, oh. yes of cause we can add it and it is easy :) | 01:50 |
| wolfspraul | great | 01:51 |
| wolfspraul | how about audio sensitivity? | 01:51 |
| xiangfu | the audio sensitivity bug? not working on that yet. | 01:52 |
| wolfspraul | no | 01:52 |
| wolfspraul | 2 keys so we can increase and decrease audio volume | 01:52 |
| xiangfu | no such shortcut yet. | 01:52 |
| wolfspraul | I say just start simple and put it on cursor-up and cursor-down | 01:53 |
| 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 | 01:53 |
| 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 | 01:55 |
| wpwrak | and you have F1 twice :) | 01:55 |
| xiangfu | F1. yes that is in different mode. | 01:56 |
| xiangfu | simple mode F1 means patch name | 01:56 |
| xiangfu | configured mdoe F1 means video-in | 01:57 |
| wpwrak | phew :) | 01:57 |
| wolfspraul | ouch | 01:57 |
| wolfspraul | I'd say focus on simple mode | 01:57 |
| wpwrak | at least you don't have to use morse code to express your wishes ;-) | 01:57 |
| wolfspraul | no help in configured mode | 01:57 |
| 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 :) | 01:58 |
| wpwrak | maybe disentangle the hotkeys while we're at it ? | 01:58 |
| xiangfu | wpwrak, improve later. :) | 01:58 |
| wolfspraul | xiangfu: focus on simple mode | 01:58 |
| wpwrak | NB: if you take one of those little rf keyboards, about half the of those hotkeys may not even be available | 01:58 |
| xiangfu | wolfspraul, yes. agree. :) | 01:58 |
| wolfspraul | wpwrak: that's next | 01:59 |
| xiangfu | wolfspraul, we should re-enable all midi / osc etc patches on simple mode. | 01:59 |
| wolfspraul | the shipment of 20 Riitek keyboards is on the way to Adam as we chat | 01:59 |
| wolfspraul | once they arrive, I will remove the silicone keyboard for good | 01:59 |
| wpwrak | heh ;-) | 01:59 |
| wolfspraul | I will leave the remotes in the box until they are out of stock, but then not refill. | 01:59 |
| wpwrak | which model did you choose in the end ? | 01:59 |
| wpwrak | will you keep the IR sensor ? | 02:00 |
| wolfspraul | I think we should keep it, yes. | 02:00 |
| wolfspraul | there could be interesting applications later and if it's about BoM cost, there is A LOT of other stuff we can optimize. | 02:00 |
| wolfspraul | this one http://www.riitek.com/product_Info.asp?id=56 | 02:00 |
| wpwrak | okay. let's revisit the quesiton when the time comes for M1rc5 or M2 ;-) | 02:01 |
| wpwrak | and you switch from acrylic walls to something else. then realize you now need an IR-transparent window. etc. :) | 02:01 |
| wolfspraul | I wouldn't even care making it dysfunctional without removing the ics. | 02:02 |
| wolfspraul | nobody uses it anyway | 02:02 |
| wolfspraul | I will strictly just go step by step to improve actual product usage. | 02:02 |
| wolfspraul | in users hands, not theoretically | 02:02 |
| wpwrak | then you may as well remove the chips :) well, in > M1r4 | 02:02 |
| 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. | 02:03 |
| wolfspraul | btw, the two ADI codecs for the r4 design-verification run are with Adam now, vga and video-in (adv7181c) | 02:07 |
| 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 | 02:07 |
| wpwrak | great ! | 02:07 |
| wpwrak | heh :) | 02:07 |
| wpwrak | let's hope they are what they claim they are :) | 02:07 |
| wolfspraul | sure, will be | 02:07 |
| wolfspraul | I replied to all questions from ADI, but even though my mails got friendlier and friendlier, zero replies | 02:08 |
| 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 | 02:08 |
| wolfspraul | I did get some "out of the office until xx-xx" auto-replies though | 02:09 |
| 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? :-) | 02:09 |
| wolfspraul | anyway, problem solved | 02:09 |
| 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 | 02:10 |
| wpwrak | hmm yes. a good objective for 2022 :) | 02:11 |
| xiangfu | wpwrak, we have a lot of 'shadows a global declaration' | 02:12 |
| wolfspraul | nah, if we can pickup some speed it can be much faster. but one by one, sure. the product must stay working. | 02:12 |
| wpwrak | yes :) | 02:12 |
| GitHub3 | [flickernoise] xiangfu pushed 1 new commit to master: http://git.io/rhheXA | 02:13 |
| GitHub3 | [flickernoise/master] disable mouse click exit rendering mode - Xiangfu | 02:13 |
| 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 ... | 02:13 |
| kristianpaul | finally! :) (commit) | 02:13 |
| wolfspraul | wpwrak: oh, not at all [cut off]. let's see how the codec situation evolves. | 02:14 |
| 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. | 02:37 |
| kristianpaul | wpwrak: btw where is that thread you made to catch user input from kbd?.. | 02:39 |
| cladamw | (Varistors) all their symbols I changed them being as likely diac. so can't be faced as coil or bead or choke. | 02:39 |
| kristianpaul | ah debug navre i guess | 02:40 |
| cladamw | Ah~ from werner's great reviews, there're more mistakes discovered while I had made before. :( No excuse though. | 03:15 |
| cladamw | it seems that was quite hard to find mistakes in details in 1 ~ 2 persons. but one Werner beats our manual works. | 03:17 |
| cladamw | i hope the sooner boom system can really avoid all of these. | 03:18 |
| cladamw | wpwrak, don't know how to say thanks to you. | 03:18 |
| qi-bot | The firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120314-0248/ | 03:28 |
| 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/ | 05:07 |
| qi-bot | The firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120314-0610/ | 06:50 |
| wolfspraul | maybe the bot should only announce failed builds? | 06:51 |
| 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) | 06:53 |
| xiangfu | the build host is doing like: | 06:53 |
| xiangfu | 1. check new commit compile milkymist-firmware --> check new commit compile a branch milkymist firmware --> check new commit compile ben Nanonote image. | 06:54 |
| xiangfu | the step_3 is usually needs ~40 hours. | 06:54 |
| 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. | 06:55 |
| xiangfu | wolfspraul, in fact I think those build success information is ok. even one message every 2 hours I can accept that :) | 06:58 |
| xiangfu | as lease I know build host is working :) | 06:58 |
| wolfspraul | hmm | 07:06 |
| wolfspraul | ok :-) | 07:06 |
| wpwrak | kristianpaul: https://github.com/milkymist/flickernoise/blob/master/src/shellext.c#L276 | 07:55 |
| wpwrak | cladamw: ah, there were more issues ? checking the mails ... :) | 08:06 |
| cladamw | wpwrak, hi no, i'm just still digest your mails, i only replied that what i knew or i can do. ;-) | 08:07 |
| 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 | 08:07 |
| cladamw | (TBD on my site) like 150uF with low ESR check, ... | 08:09 |
| 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. :( | 08:12 |
| 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 :( | 08:15 |
| wpwrak | yeah, participation is a bit disappointing | 08:21 |
| wpwrak | joerg has made a few small comments. maybe there will be more | 08:21 |
| 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 | 08:23 |
| cladamw | but one *ps file I may need your help to update. :-) | 08:24 |
| wolfspraul | there is no/very little culture of collaboration in hardware | 08:24 |
| wolfspraul | we try to jumpstart it but well, either we do something wrong or it's hard or just never will take off | 08:25 |
| 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. | 08:26 |
| wolfspraul | I think eventually it will | 08:26 |
| cladamw | oah..yeah..much thanks joerg too. | 08:26 |
| 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 | 08:27 |
| cladamw | wpwrak, i just saw your replied on C120. since from M1rc1 the U3 we always used SO5032 with 10nF. | 08:31 |
| wpwrak | cladamw: updated: http://downloads.qi-hardware.com/people/werner/tmp/xbrd-top.pdf | 08:32 |
| wpwrak | (note the name change. in the future, we'll also gave other views, hence the addition of "-top") | 08:32 |
| cladamw | wow...so fast ! thanks. | 08:33 |
| 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 | 08:33 |
| wpwrak | (fast) the joy of parametric cad ;-) | 08:33 |
| cladamw | so I should remove " In practice..." as well as no need those mentions, better ? | 08:36 |
| wpwrak | since we're using SO5032, why not change C120 to 100 nF ? | 08:40 |
| 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 ) | 08:46 |
| 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. :-) | 08:47 |
| wpwrak | you can always try and rework an existing board ;-) | 08:49 |
| 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 | 08:49 |
| wpwrak | the problem with "it works" is that we don't know where in the parameter space we are, also regarding component production tolerances | 08:51 |
| cladamw | mmm..okay, so I'll change C120 to 100nF for SO5032, thanks for explains. :) | 08:54 |
| cladamw | also change U3's name to SO5032. | 08:55 |
| wpwrak | kewl, thanks ! | 08:56 |
| GitHub109 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/5c0cc6292c440e19dab5594477452769ca37dd71 | 11:26 |
| GitHub109 | [migen/master] fhdl: export log2_int - Sebastien Bourdeauducq | 11:26 |
| wpwrak | hmm ... no comment on R54 today ? :) | 13:04 |
| lekernel | wpwrak: you can play with the value, but it does have impact on the signal levels | 13:16 |
| lekernel | and the opto can pull 60mA/dissipate 100mW so it should be ok, even if it's not power efficient | 13:17 |
| lekernel | max power you can get from that resistor is 23mW | 13:17 |
| kristianpaul | wpwrak: thanks ! | 13:46 |
| GitHub48 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/1665f293a619b6b989031fb5b293df9509f57600 | 15:26 |
| GitHub48 | [migen/master] bus/asmibus/hub: require finalization before get_slots - Sebastien Bourdeauducq | 15:26 |
| wpwrak | lekernel (60 mA) ah, right. i got the wrong side. | 15:26 |
| wpwrak | lekernel: still seems very low, though. did you experience problems with larger values ? | 15:27 |
| lekernel | can't exactly remember... but yes, there has been some tweaking to get a proper signal | 15:40 |
| lekernel | there's probably a large margin with the current value though | 15:40 |
| lekernel | but values in the kohm range do cause problems | 15:42 |
| wpwrak | it should be input leakage plus anything we lose due to parasitic capacitance, no ? | 15:42 |
| lekernel | there are problems with rise/fall times too | 15:43 |
| lekernel | optoisolators are slow devices | 15:43 |
| 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 | 15:43 |
| wpwrak | slow edges at the source should actually help, as far as moving parasitic capacitance is concerned | 15:45 |
| wpwrak | or at least not make things worse | 15:45 |
| wpwrak | do you remember what value you had trouble with > | 15:45 |
| lekernel | with the first optoisolator the problem was extreme | 15:46 |
| wpwrak | if it was 100 kOhm, that would make perfect sense. perhaps even 10 kOhm. | 15:46 |
| lekernel | (we changed it with that model later) | 15:46 |
| wpwrak | ah, i see | 15:46 |
| 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 | 15:46 |
| lekernel | this one has better characteristics | 15:48 |
| 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 :) | 15:48 |
| 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? :) | 15:50 |
| wpwrak | hmm, almost 3% of the entire power budget of the M1 ;-) (not counting USB, i.e., assuming 5 W = 1 A) | 15:52 |
| 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 ;-) | 15:53 |
| GitHub78 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/ByEWgA | 17:32 |
| GitHub78 | [milkymist-ng/master] asmicon: skeleton - Sebastien Bourdeauducq | 17:32 |
| lekernel | http://erf.desy.de/workshop | 23:31 |
| lekernel | larsc: you're in Hamburg right? | 23:35 |
| larsc | no longer | 23:37 |
| larsc | munich now | 23:37 |
| --- Thu Mar 15 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!