#milkymist IRC log for Friday, 2011-05-06

CIA-48mtk: Xiangfu Liu master * r6d0bcdd / lib/keymap.c : make US layout keyboard full working - http://bit.ly/jG9Mcp08:19
CIA-48mtk: Xiangfu Liu master * r1fd2f71 / lib/keymap.c :08:19
CIA-48mtk: using '\' instead of 'ß', for don't break the current code08:19
CIA-48mtk: fix the Germany layout ASCII code - http://bit.ly/k64Gdw08:19
CIA-48flickernoise: Xiangfu Liu master * rf89125c / src/input.c : make US layout full working - http://bit.ly/l5Dc2808:21
xiangfulekernel: my French keyboard is on the way. I will finish the french layout when I got the keyboard. (a little bit hard to buy the french keyboard)08:31
xiangfulekernel: I think I will first make the french layout working in current mtk.git code structure.08:32
lekernelwhy?08:33
lekernelyou'll need to redo everything after08:33
xiangfulekernel: when you have time you can give me a little tips about how to finish all this 'input.c'08:33
lekernelwell easy08:33
xiangfulekernel: for now I don't look into the 'modifier' keys.08:33
lekernelstrip out most of the lib/kepmap.c, just turn it into a dumb get_ascii function that returns 'a' for MTK_KEY_A, etc.08:34
xiangfuthen using the 'keyb_translation_table' to get the MTK_KEY_A right?08:34
lekerneland define new keyb_translation_table arrays in flickernoise/src/input.c, one for each keymap, that turn the hardware keyboard scancodes into MTK_KEY_* values08:35
lekernelit doesn't make sense to add more stuff that depends on the semi-translated (i.e. keymap independent) MTK_KEY_* values, because those will go08:35
lekernelthere's a lot of stuff in input.c, most of which you do not need to understand to get the keymaps to work08:36
xiangfuwhat about the SHIFT and AltGr?08:37
lekernelthe only thing you need to understand is the handle_keybd_event() function08:37
lekernelstatic int handle_keybd_event(mtk_event *e, unsigned char *msg)08:37
lekernel1) e -> array of mtk_event structures, written by the function with the decoded events08:38
lekernel2) msg -> raw USB message from the keyboard, read by the function08:38
lekernel3) return value -> number of events written by the function in the 'e' array08:39
lekernelyou need to send MTK_KEY_* events when shift and altgr are pressed and released08:41
lekernelthe status of those keys is indicated by a bitmask in the first byte of the USB message08:41
lekernelit is handled with the calls to the check_modifier() function08:42
lekernelafaik all keymaps would send the same codes for those keys, but if not, just change the values passed to check_modifier() depending on the keymap08:43
xiangfuso we have to add the like : 'ä' --> MTD_KEY_AE to the keycode.h08:43
lekernel'normal' keys are handled with the keyb_translation_table lookup table08:43
lekernelin the next bytes of the USB message, the keyboard will send one or multiple codes between 0 and 255, each identifying a key being pressed08:45
lekernelthe handle_keybd_event() function goes through those bytes, and looks them up in keyb_translation_table (which has 256 entries)08:45
lekernelthe keyb_translation_table value is a MTK_KEY_* value - right now for the QWERTY keyboard, which gets later translated by MTK to another keymap08:46
lekernelwhat I want you to do, is remove the second translation by MTK08:46
lekerneland make keyb_translation_table return directly the correct MTK_KEY_* value for the correct keymap08:46
lekernelso you basically need one keyb_translation_table per keymap, and switch between them08:47
lekernelunderstood?08:47
xiangfuyes. for now we are like  Scancode --> MTK --(three keymap here) --> ASCII08:49
xiangfuafter, we want Scancode --(three keymap here) --> MTK --> ASCII08:49
xiangfulet me write my thinking. see if it correct.08:51
xiangfu1. I will re-write keycodes.h for easy convert MTK to ASCII. add all 256 ascii to the keycodes.h08:52
xiangfu2. add three 'keyb_translation_table' to input.c08:53
lekernelyes08:53
lekernelkeycodes.h already has all the ASCII keys08:53
scrts`hm.. are the rx_clk and tx_clk on ethernet phy are always working or just when the data is sent?08:55
xiangfulekernel: hmm... there is no 'ü' ...., in keycodes.h09:00
lekernelaw: "we got the protection goal with regression" what do you mean?09:00
awsorry that typed too fast ...should be "without"09:01
lekernelxiangfu: keycodes.h is inspired by the Linux keycodes... so09:01
lekerneleither 1) the ü is somewhere in it with some weird name but we didn't find it09:02
lekernel2) since keycodes.h contains a lot of cruft because of this Linux legacy (examples: MTK_KEY_TV2, MTK_KEY_VCR, ...) we can also break whatever little Linux compatibility it has, strip out this useless stuff, and add useful codes (ü, ö, ...) instead09:03
lekernelbtw, I'm not sure ü/ö/ä are in ASCII09:04
lekernelbut those aren't super important either09:04
lekernelso there's also 3) we don't care about those keys for now09:04
xiangfulekernel: ok.09:05
lekernelhaving those keys means we also need to support them in the fonts etc. so...09:05
xiangfumy last commit in mtk.git make those keys working. and it's display correct in 'patch editor'09:06
lekernelok, good09:06
lekernelbut the patch language doesn't need them :-)09:06
xiangfu(I don't know how MTK display them for now :(09:07
lekernelneither does URLs and most other user inputs09:07
xiangfusure.09:07
lekernelGenode fx (which MTK is a fork of) was written by German guys, so I'd bet they used some ASCII variant which has them09:07
lekernelhttp://en.wikipedia.org/wiki/ISO/IEC_8859-109:08
lekernelthey're in that ... probably what they used09:08
lekernelso maybe clean up keycodes.h: remove useless keys and add those we need09:09
lekerneland support ä/ö/ü09:09
xiangfuok09:10
xiangfudirect map MTK to ASCII :)09:10
xiangfus/MTK/MTK_KEY_*09:10
lekernelwell, MTK_KEY_* will have more than ASCII codes09:10
lekernelyou need to put F1, F2, ..., Alt Gr, Shift, ... in that09:10
xiangfuthen those should be bigger then 25609:11
lekernelyes but it's not a problem09:11
lekernelit's an int type09:11
lekernelbut yeah, for simplicity you can put the ASCII codes at the beginning09:12
lekernelso all MTK_KEY_* values which are less than 256 somewhat directly map to ASCII (but you'll have to handle modifiers as well)09:12
lekernelbtw modifiers will be a bit of a pain09:13
lekernelbecause it's not always the same characters (selected with a modifier) which are grouped together09:13
lekernelso I'd guess you'll need a MTK_KEY_* value for each group of characters... which in the end pretty much compromises this idea of direct ASCII map09:14
xiangfusorry what you mean about 'because it's not always the same characters ... grouped together' ?09:17
xiangfuwhat group?09:17
lekernelfor example the French keyboard has a key with @, à and 0 on it09:18
lekernelwhile the German one has Q and @09:19
lekernelso you need two MTK_KEY_Q_AROBASE and MTK_KEY_AROBARE_AGRAVE_ZERO09:19
xiangfulekernel: we have to move the SHIFT table and AltGr table to input.c right? if we have the SHIFT and AltGr working in input.c, we don't needs those group defines09:26
lekernelhow would you handle key combinations like Alt-F1, then?09:27
xiangfuhmm...  I will look into more detail. if I still question. I will ask you :)09:34
xiangfuone small question. is that easy to add 'REMOTE POWER ON' in standby bitstream? like IR remote controller turn on the TV09:35
lekernelyeah09:38
lekernelnot too hard09:38
lekernelbut not a very useful/high priority feature, as far as I can tell09:38
xiangfuok09:39
xiangfuback online later.09:40
lekernelhttp://pastebin.com/b8qa6at1 nice gems i'm digging out since yesterday ....12:42
lekernelwas this code fucking tested?12:43
rohlekernel: just dont read bsd code. hurts your brain and smells of the bad part of the 60s13:23
kristianpaulhttp://libagar.org/13:27
kristianpaulah C++ too..13:30
rohi stopped reading at 'cross platform'13:32
kristianpaulhe13:33
rohthe docs say 'ansi C' (89)13:33
rohThread safety (when enabled with --enable-threads) requires a POSIX threads implementation with support for recursive mutexes.13:34
rohdoes the current libc do that?13:34
lekernelroh: well, I need to get internet access to work fine on M1, and RTEMS uses the BSD network stack13:34
lekerneland tbh BSD code isn't always that bad13:34
rohits funny. learn how not do do stuff in 2010 and behind13:35
lekernelheh13:35
lekernelhave you read GNU code, in comparison?13:35
lekernelit's not brilliant either13:35
lekernelprobably worse than BSD, I would say13:36
rohsure.13:36
wpwraklekernel: at least the gnu indentation style serves as a clear early warning ;-)13:36
rohbut atleast its not the fucking 6s.13:36
roheh 60s.13:36
rohin my eyes we can drop the whole fucking socket config interface in linux. its shit. its broken. it may be posix, but it cannot do half the stuff.13:36
rohnetlink is the way (for years) to config an ipstack.13:37
lekernelcode being bad because written in the 60s doesn't look like a sound technical argument to me13:37
lekernelor, rather, I guess you mean in 60's style13:37
rohwell.. it also cannot handly things we learnt about ip later... e.g. ecn, ip aliasing, vlans.. proper routing... all the stuff which is a hack in the oldstyle ifconfig thinking.. which IS how the bsd stacks work afaik.13:38
lekernelwell, for the M1 it's going to be fine without that :)13:38
rohlekernel: sure. just dont wonder if stuff doesnt work.13:40
lekernelthat piece of code was from RTEMS btw. not BSD.13:41
rohe.g. ecn is actively used in the internet. bsd4.4 code doesnt handle it properly (former reserved bits in the ip header) and drops em.13:41
lekernelto give you more to rant about, there is no ipv6 on m1 :-)13:42
kristianpaul;)13:43
rohlekernel: as long as you can fix that later...13:45
wpwraklekernel: i suppose you have really nice cobol and fortran then ? ;-)13:45
lekerneloh sure... just sw upgrade13:45
lekernelactually, if (uC)Linux works someday, there will be ipv613:46
rohor somebody fixes rtems13:46
rohits not that hard. there is ipv6 stacks running on 8bit mcus13:46
wpwrakyeah. the tcp/ip stack is one of the reasons why it became difficult for proprietary unix variants to exist alongside the free ones.13:47
lekernelsome rtems people are discussing that, and they find it "hard". which I disagree with, but I don't feel motivated either to do it.13:47
rohbwhjahaha13:47
wpwraknetworking is tricker than you may think :)13:48
rohkids with their grannys metal-model-train discussing why the lego people are so much faster on development...13:48
lekernelipv4 is still going to be around for at least a decade or so, until then we have plenty of other stuff to do in milkymist13:48
lekerneleven major german isps don't have ipv613:48
rohlekernel: be around yes. majorly used. no13:48
wpwrak"let's call the smith to forge us that piece" ;-)13:48
rohlekernel: its over. this year. we will all have v6 addresses at our home dsl by end of the year.13:49
wpwraki kinda doubt this13:49
rohthe last olympic games already used v6 as major network.13:49
wolfspraulroh: we will leave the dmx push button as-is13:49
wolfspraulso that one is settled :-)13:49
rohwpwrak: nope. the only other possobility is nat. which doesnt work properly13:49
rohwolfspraul: ok.13:49
lekernelI was sure ipv6 was a hot subject with roh :-)13:50
wpwrakroh: has "not working properly" ever prevented something from being deployed in the real world ? ;-)13:50
rohwpwrak: yes. if working is making payment possible, it does.13:50
rohlekernel: dont get me wrong. i dont 'like' some things on v6 either. but there is no fsckin way around or ignoring it. its be compatible or bust this year.13:51
rohmy laserprinter speaks v6. just as an example.13:51
rohsome used lexmark office device13:51
wpwraki remember the ietf meeting in san jose 1994. my first. there, everybody seemed to agree that ipv6 was ready now and that wide deployment was imminent. people were also very excited about doing it.13:51
wpwrakthen they figured they needed a few little design changes. poof, the hype blew away.13:52
rohwpwrak: well.. we used it some years now and have native access in hosting centers too. this year is the one where we NEED to mass-deploy.13:52
rohthe last /8 blocks are gone. its 'till the tank is dry' now.13:52
wpwraknow we have an installed base that's several orders of magnitudes larger. everything that looked difficult back then is a nightmare nowadays.13:52
wpwrakroh: what's happening now is that people are selling unused ipv4 addresses. there's a lot of these. of course, this will mess up the routing horribly ...13:54
rohwpwrak: not a problem. most of the infrastructure is replaced periodically anyhow.13:54
rohe.g. the cores in amsix are usually 'the freshest shit alive' ... simply because they cannot use last years interfaces (they are using 100gbit fibre links now) the first ones on the planet in production use13:54
rohwpwrak: selling is bs.13:55
rohwpwrak: only pi is transferabble at all.. and also only in blocks >/23.13:55
roh /24 is already filtered at a lot of places to keep the tables small enough for ram13:55
wpwrakroh: eventually, everything gets replaced, true. yet there were places in the late 1980es that still used pdp-11 for critical tasks ... :)13:55
rohso yes.. there will be some grey market. but that will dry up, since you cannot sell a pa.13:56
rohwpwrak: these dont use ip usually.13:56
wpwrakdon't underestimate the pdp-11 ;-)13:56
rohwpwrak: there is x25 in missioncritivcal use also.. for banking...13:56
rohwpwrak: also its a bad argument to say 'there is old stuff belonging into a museum still being used' .. well.. yes.. do you want to belong to it?13:57
rohofcourse not.13:57
rohmy point is: selling something with no v6 will be hard in <1 year. every plastic applicance will be compatible13:58
rohbbl13:58
awlekernel, i think that now we are safe on 2A fuse and 5.6V Zener. :-)14:01
lekernelok, the only two points that I care about is 1. no current consumed between 4.75V and 5.25V 2. acceptable voltage drop14:02
lekernelreading your table #1 is OK14:02
lekernel#2 => what's the difference between "Zener Voltage" and "Voltage of symbol 5V marked on M1 RC2"? the two are supposed to be connected, no?14:03
awfirst "Zener Voltage" is measured by its two terminal by Agilent 34401A.14:06
aw"Voltage of symbol 5V marked on M1 RC2" is the measured results by probing C138's two pads.14:07
lekernelok well14:09
lekernelweird14:09
lekernelbut go ahead14:10
lekernelthe protection circuit won't be hard to rework out if we get problems with it14:10
awyour care about current consumed between 4.75 ~ 5.25V is okay on table 1(NO LOAD), there's only 0.74A when works on LOADs. :-)14:10
lekernelyes14:10
awyes14:10
wolfspraulbtw xiangfu mentioned to me today he thinks the ftdi 2232h gets very hot when being used14:10
lekernelare you done with the schematics?14:10
wolfspraulmaybe not too hot, don't know. but hot :-)14:11
lekernelwolfspraul: I don't have such a problem ...14:11
lekernelactually mine has been continuously connected on USB for a few days now and it still works and cold14:11
lekernelaw: how are the schematics going?14:12
awlekernel, yes, done. but I wait for house's reply. should next week I'll send to list and even started to route some.14:12
lekernelok, please send them now for review14:12
wolfspraulso our USB 5V is not actually 5V now? it's more like 4.7-4.8 or so?14:12
awlekernel, http://en.qi-hardware.com/wiki/Milkymist_One_Schematic_Change_History#2011050414:13
wolfspraulbut I guess that's OK?14:13
awhere's my all modifications on schematic.14:13
awlekernel, sorry that I've uploaded the schematic.14:13
awhave not uploaded...14:14
awwolfspraul, correct...a little bit lower.14:14
wolfspraul4.65 in the table14:15
wolfsprauland that is OK?14:15
awworks on my keyboard and two mousers.14:15
wolfspraulI'm a bit worried that you say you tested your 2-3 keyboards and mice and they work so we are fine :-)14:15
wolfspraulsounds like a small sample14:15
wolfspraulwell there are thousands of USB devices14:15
awyes, that's why I told you that send me some keyboards when you surveyed done.14:16
lekernelwolfspraul: the value does not make sense. at 0.73A, the voltage drop from the fuse should be only 0.73*0.07 = .0511V14:16
awyeah...very little now though.14:16
lekernelso how come you get 4.413V (i.e. 0.337V drop)?14:17
wolfspraulno wait. we cannot randomly plug in a few keyboards and then conclude that it's fine. I'm sure there is a USB spec.14:18
awwhen facing PTC fuse, you can not just deduct the drop voltage.14:18
wolfspraulwhat does the spec require?14:18
lekernelaw: it says 0.07 ohm, no?14:19
awlekernel, yes14:19
lekernelwolfspraul: 4.75 to 5.25V14:19
lekernelaw: so? when you multiply the current by 0.07, you get the dropped voltage14:19
kristianpaulhot yes14:19
lekernelno?14:19
awlekernel, you needs to read PTC curve firstly.14:20
kristianpauli tought it was heat coming from board been disipated..14:20
kristianpaulbut dint tested or measure further14:20
awwhen huge current goes through PTC fuse firstly, the material starts to get bigger resistance more gradually.14:20
awnot you only calculate always 0.07. :-)14:21
lekernelof course 0.07 is an approximation. now what matters is under what conditions it is valid.14:21
lekernelI was assuming that in a normal temperature range, say, under 50 degrees, the approximation was valid14:22
lekernelbut I might be wrong, in that case those PTC fuses are crap14:22
awwait....let me measured some chips's temparatures,, so everyone can imagine though :-)14:23
wolfspraulI think we need to get USB 5V up a little, 4.65 sounds not good14:24
lekernelaw: fuse datasheet says resistance is between 0.02 ohm and 0.07 ohm at 20 degrees, so it's a bit weird you get almost 10 times that14:24
lekerneleven at 30 degrees or so14:24
awlekernel, becuase we have Zener's body temperature with close to fuse's body. so its surrounding area temperature is a fewer high.14:26
awthat's the reasons that I got higher temperatures.14:26
awi always have two column temperatures. ( fuse and Zener )14:27
lekernelaw: reminder: between 4.75V and 5.25V the current through the zener is zero. therefore the dissipated power is zero as well, and the temperature increase also zero14:27
lekernelif the zener heats with those voltages, either the heat comes from somewhere else or you're doing something wrong14:28
awreasonable on your theoretically assumption14:29
awbut from table one, it indeeds.14:29
awtable two is the two parts I soldered them on board nearby U13 and L10. so this is practical.14:30
awso now my 2A DC power supply: PTC fuse (33.4), Zener (36.9), U13 (35.2), FPGA (35.2), U10 (39.6)14:32
lekernelaw: let's have a look at this _after_ the rc3, ok?14:33
lekernelI propose we don't implement the protection circuit now14:33
awwith this real DC adapter which won't be act as my laboratory power supply on strong output driven current out.14:34
lekernelaw: do you agree we should not implement the protection circuit in the rc3 boards and we have a calm look at it later?14:36
awlekernel, wolfspraul well  seems that you don't want this patch, actually me either. I'd rather to use NS LNZ12002.14:36
awbut this is really tough situation if we can determine now.14:37
lekernelhuh, what's NS LNZ12002?14:37
wolfspraulaw: why do you not want it?14:37
wolfspraulthe voltage drop that cannot be explained right now?14:37
awthe real reality is existed there that I did indeed really not test many keyboards, and mouser, although there's only 4.413 V on mine, but others I don't know and this's not meet USB spec.14:39
lekernel4.413 V is _WRONG_. period14:39
lekernelno matter if it works with your USB devices14:39
awlekernel, surely14:40
lekernelit's too much voltage drop, which is what wolfspraul was saying14:40
lekernelso, do you agree to leave that protection circuit for later?14:40
awif both of you said that can't accept this, I'd say 5.6V breakdown is also over USB spec.14:41
lekernel....14:42
awi don't think that I have time to do such things though, I agreed that not to do this in rc3.14:42
lekernelI told you already that we don't really care about what the board does when run with inappropriate voltage14:42
lekernelbut it's extremely important that it works well with the specified voltage14:43
lekernelok, so we don't do it. case closed.14:43
wolfspraul:-)14:43
wolfspraulwait too fast for me14:43
wolfspraulaw: what do you want to do now?14:43
awin h/w, there's too linear case not only logically think though.14:43
wolfspraulyou mean with the 5.6v zeners we have a (currently unexplained) voltage drop that brings the USB voltage out-of-spec14:44
wolfspraulI think we all agree USB voltage < 4.75 is not acceptable. that's easy.14:44
wolfspraulso like lekernel said - do we want to investigate the voltage drop, or just go back to rc2 altogether? :-)14:45
awI was thought that I'd like to use regulator to do all protections, if we WANT to only 5V +/-5% DC adapter, then NOW I decide that let don't implement protection in rc3.14:45
lekernelwolfspraul: keep in mind that adding this circuit also paves the way for layout nightmares14:45
lekernelif the layout gets this messy, the rc3 will be in duke nukem forever mode14:45
wpwrak(usb spec) there is ;-) usb_20_081810.zip, file usb_20.pdf, page 17514:46
awh/w tasks:  you guys thinking are also strange though.14:47
wpwrakah, they updated it. now it's http://www.usb.org/developers/docs/usb_20_021411.zip14:47
lekernelwolfspraul: aw: so, we don't do it?14:50
wolfsprauldifficult decision. I can only say USB spec is important.14:53
wolfspraulif the voltage drop cannot be explained now, and Adam feels good about his numbers, then sure maybe the best idea is to not do the new circuit at all14:53
wolfspraulI have no problem with that, we surely tried...14:53
awwait...14:54
wolfspraulmaybe Adam wants to sleep over it, confirm the numbers tomorrow or Monday, and if everything stays the same he makes the final call.14:54
awlet's see good stuffs on wpwrak 's link14:54
awwpwrak, thanks a lot, i am reading "usb_20.pdf" file,14:55
awlet's open it all together.14:55
lekernelaw: I sum up the important parts of that link for you: USB voltage has to be between 4.75 and 5.25 volts, and a USB device can draw up to 500mA current. all the rest you can skip for our purposes.14:55
awsee page 175,14:55
wpwraklekernel: correct (that is, for a "high-powered" port)15:00
awwpwrak, for a "high-powered" port15:00
wpwraklekernel: if all you care about are mice and keyboards, you need less15:00
awbut how about "worse case"15:00
wolfspraulno no. we want a full usb host ports here.15:01
wolfspraultwo rather15:01
wolfspraulthere is no need to talk ourselves into 'crappy usb is enough for us' mode15:01
wpwrakaw: figure 7-47 shows: highh-powered hub/port, then a bus-powered hub, and finally a low-powered device15:01
awwpwrak, yes, go on.15:02
wolfspraulthe voltages as measured in Adam's last round are too low15:02
wpwrakaw: e.g., pc -- cheap bus-powered hub -- mouse15:02
awwpwrak, listening..15:02
lekernelwe want full featured USB ports, which means a voltage between 4.75 and 5.25 and a capability for currents up to 500mA.15:03
lekernel</noise>15:03
wpwrakaw: so this shows what lekernel said: you need a minimum of 4.75 V for a high-powered port15:03
wolfspraulI'll read the backlog, hopefully it's not too long :-) n8 everybody...15:05
lekernelgn815:05
wpwrakthe real problem seems to be the reliance on a "perfect" external power supply and magically lossless conductors. would it be so hard to just add a regulator for 5 V and supply the system with a higher voltage ?15:05
lekernelyes15:06
awwpwrak, lekernel hm..okay..so then I can't gather even fine tune fuse with Zener to meet this 4.75V which if we want to use a DC adapter with minimum 4.75V out from adapter.15:06
wpwrak(and the protection circuit is just another "magically lossless" conductor :)15:06
lekernelwpwrak: it's not, but small voltage drops are acceptable15:06
awthere's quite hard to get there to have no drop and also take dissipation.15:07
lekernelno, it shouldn't be. if the fuse is only 0.02 ohm to 0.07 it should work without much fuss.15:07
lekernelbut let's have a look at this later15:07
awlekernel, yes...the fine tune is really needs time and need to have real soldering together on board to have that test.15:08
wpwrakhow many rc3 do you plan to make ? just a few ?15:08
lekernelaw: i'll reproduce your experiments on my side and then we talk15:08
awso now I agreed that we don't implement this protection on rc3.15:08
lekernelok, good15:08
lekernelwpwrak: 8015:08
lekernelaw: can you send me the schematics?15:09
lekerneli'll review the other stuff: audio, etc.15:09
wpwrakokay, not that many. won't kill anyone to deal with the ones that get fried15:09
awyes, i can send you now.15:10
lekernelwpwrak: exactly zero board has been fried in our run of 4015:10
awbut don't check their footprints then...15:10
wpwrakbtw, are the schematics still in some proprietary format ?15:10
lekernelyes15:10
lekernelaw: understood, I just want to verify the schematics now15:11
awlekernel, okay. :-)15:11
lekerneldo we have any footprint modification anyway?15:11
wpwraklekernel: (zero fried so far) yes, but as you said, something like 80% are safely in a drawer and the rest are in the hands of people who know enough about electronics to be careful. that luck won't last forever (i hope ;-)15:11
awlekernel, footprint have not all linked together though on added or modified parts.15:13
awlekernel, pre-rc3 sch sent. :-)15:18
lekernelok, thanks!15:19
awfirst forget about fuse & zener in power though.15:19
lekernelok I got something15:19
lekernel100mV voltage drop between input and USB port on RC2 but not on RC115:19
lekernelactually I only tested that on the RC1 before15:20
awat the "5V" net?15:20
lekernelyes15:20
lekerneldid you use a different source for ferrite beads between rc1 and rc2?15:21
awno, bead is the same I used in both.15:21
lekernelwtf ...15:21
awbut you can just to swap them to confirm that if this is for 100mV15:22
lekernelsure15:22
lekernelor just measure the voltage across. easier...15:22
awi'll also confirm here.15:22
awif really discover an extrusion of 100mV, it would be good news.15:24
lekernelthere is definitely such a voltage drop15:24
lekernelit's clearly measurable15:24
lekerneland increases with current consumption15:24
awyeah...constantly we needs at least 0.74A minimum.15:25
lekernelso there's a parasitic resistance somewhere in rc2 we don't have on rc115:25
awthe more use the more drops.15:25
awhmm...interesting.15:25
lekernelwhich fully explains your incorrect voltage measurements15:25
awwe have only two kinds bead on board15:26
aw1206 and 0402 footprints i remembered.15:27
lekernelyeah yeah we're talking about the 1206 ones here15:27
lekernelok it's those fucking beads15:28
lekernelaw: just measure the voltage across them. you'll see.15:28
awyeah...15:29
awlekernel, well...time to out now..night.15:30
lekernelaccording to http://www.yuden.co.jp/ut/product/inductor/FBMJ3216HM600-T.html they should be only 0.01 ohm, but they're more than that15:38
wpwraklekernel: i wonder how much the solder joints and traces add15:38
lekernelI measured the totality of the voltage drop at the _pads_ of the ferrite bead15:39
lekernelso they are clearly defective15:39
lekernelwe have thick PCB traces with negligible resistance15:40
wpwrakokay. how much did you measure ? and i suppose you made a 4-wire measurement ?15:40
lekernelhaha, that's unnecessary15:40
wpwrakeh ?15:40
lekerneljust multimeter on the pads of the ferrite bead. and whoa! more than 50mV each15:40
wpwrakokay, so you measured voltage drop under load, not directly the resistance15:41
lekernelyes15:41
wpwrakthat's what a 4-wire measurement does :)15:41
wpwrakwhat current ?15:42
lekernelnot measured, but around 0.7A15:42
lekernelthe order of magnitude of the drop is clearly wrong15:43
lekernelplus it's not present on rc115:43
wpwrakbut they use the same bead ?15:43
lekerneltheoretically... that's what I asked Adam15:44
lekernelbut we already had problems with crappy components in the past15:44
lekernelall the rc1 board were fitted with totally defective IR receivers15:44
wpwrakurgh15:44
lekernelfor rc2, we ordered exactly the same reference and they worked15:46
lekernelsame as rc1 after drop in replacement with receivers from another source15:46
wpwrakugly. now i understand why wolfgang is suddenly so concerned about input quality control15:50
lekernelwpwrak: can schhist take PDF files? or bitmap images?16:43
lekernelPCB with round traces http://blogs.elphel.com/wp-content/uploads/2009/07/10373a_31.png , "balancing register loads within a clock period", ... many interesting design choices at Elphel, really21:01
wpwraklekernel: (round traces) there are some layout programs that do this sort of shortest trace routing. looks weird but may actually be better than the usual 45 deg pattern21:08
wpwraklekernel: (schhist) there are many steps. it's kicad .sch -> ps -> ppm -> diff21:09
wpwraklekernel: plus there's all the version tracking and stuff21:09
wpwraklekernel: if you want just the graphical diff, you could take a ps or pdf, convert it with ghostscript to ppm, and then use eda-tools/schhist/ppmdiff/21:11
wpwraklekernel: eda-tools/schhist/schps2ppm would be an example for how to convert from ps to ppm21:11
CIA-48flickernoise: Sebastien Bourdeauducq master * r850889d / src/sysconfig.c : sysconfig: add missing network API bits - http://bit.ly/kixyDN23:10
--- Sat May 7 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!