| 00:00.07 | wpwrak | Ayla: besides, unless you're really using 5.25" floppies and such, that choice isn't available anyway |
| 00:00.31 | whitequark | sigh |
| 00:00.45 | whitequark | just grab one of 1000s FAT access sample codes and declare it a day |
| 00:01.09 | mth | the standard sizes only works for floppies indeed, SD is a fake harddisk, which uses a single media ID code regardless of geometry |
| 00:01.17 | wpwrak | Ayla: you'd still need to read the boot sector to determine the FAT entry size. and maybe also the beginning of the data. not entirely sure about the latter |
| 00:02.01 | mth | afaik you get FAT location and root dir location from the boot sector and data location from the FAT |
| 00:02.02 | wpwrak | mth: pioneers of mobile computing :-) |
| 00:02.05 | Ayla | wpwrak: but why should I care about the entry size? |
| 00:02.08 | Ayla | I don't get it |
| 00:02.37 | wpwrak | Ayla: the FAT entries can be 12, 16, or 32 bits |
| 00:02.48 | Ayla | ah |
| 00:02.58 | wpwrak | Ayla: so unless your file is just one cluster short, you need to know the FAT entry size |
| 00:03.10 | Ayla | I do check it |
| 00:03.40 | Ayla | I simply exit the loading function when it's not FAT32 |
| 00:03.57 | wpwrak | mth: i meant the position of the data sector corresponding to FAT entry 0 (cluster 0). i think it's at a non-zero offset. |
| 00:05.01 | mth | hmm, my knowledge is a bit rusty I'm afraid |
| 00:06.32 | Ayla | here's (part of) my code: http://pastebin.com/ZEJYJ74B |
| 00:07.00 | mth | I used to do all kinds of nasty editing in the file system, like making a subdirectory point to its parent and watch PC-Tools crash when reading the disk |
| 00:07.28 | wpwrak | sbi->data_start = sbi->dir_start + rootdir_sectors; |
| 00:07.39 | wpwrak | and |
| 00:07.40 | wpwrak | sbi->dir_start = sbi->fat_start + sbi->fats * sbi->fat_length; |
| 00:08.03 | wpwrak | linux kernel, fs/fat/inode.c:fat_fill_super |
| 00:08.09 | mth | Ayla: you might need some attribute to tell the compiler not to pad the struct |
| 00:08.11 | wpwrak | still there after all these years :) |
| 00:08.27 | Ayla | mth, I did check that, only the last one is padded |
| 00:08.29 | DocScrutinizer | mth: haha, on early linux you could create that with standard tools |
| 00:08.36 | Ayla | the "fsdata" structure |
| 00:09.00 | Ayla | but it's like that on the original code too, so I'm not sure if I should alter that |
| 00:09.04 | whitequark | Ayla: note that some programs, e.g. mkfs.vfat, sometimes create FAT16 and FAT12 volumes depending on the size of media |
| 00:09.10 | Ayla | the structures are from u-boot btw |
| 00:09.23 | whitequark | e.g. if you will point mkfs.vfat to something 1.44MB in size, then chances it'll format it as FAT12 |
| 00:09.31 | *** join/#qi-hardware jekhor_ (~jek@c-83-233-149-204.cust.bredband2.com) |
| 00:09.48 | whitequark | there's an option for forcing the type |
| 00:10.29 | Ayla | whitequark: I'm not planning to put a floppy on my dingoo ;) |
| 00:10.48 | DocScrutinizer | also there's an option to deal with inode size which changed from 128 to 256 eventually in mkfs and uBoot barfed up on that |
| 00:11.06 | whitequark | Ayla: there's the problem |
| 00:11.22 | whitequark | if you will format a 2MB NAND partition with mkfs.vfat, it can _too_ format it as FAT12 |
| 00:11.31 | whitequark | so look out for that |
| 00:11.45 | Ayla | heh, come on |
| 00:11.47 | whitequark | (through using FAT on NAND partitions is an exceptionally bad idea anyway) |
| 00:11.56 | Ayla | I'm writing code to boot from SD only |
| 00:12.06 | whitequark | ok, on a 2MB SD partition ;) |
| 00:12.21 | whitequark | or it can be 10MB and FAT16 |
| 00:12.27 | whitequark | still a potential for a failure |
| 00:12.36 | DocScrutinizer | oops, of course the inode size wasn't for FAT |
| 00:12.37 | Ayla | whitequark: the main root file system won't even fit on that |
| 00:12.40 | DocScrutinizer | :-D |
| 00:12.43 | mth | up to 32MB can still be FAT12 |
| 00:13.13 | mth | FAT16 goes quite a bit further and could actually exists on SD |
| 00:13.31 | Ayla | I don't want to support something we're sure we'll never see |
| 00:13.45 | Ayla | the code is not meant to go inside an OS, but is specific to the dingoo |
| 00:13.45 | whitequark | mth: I don't remember exact details of FAT implementations. but I've been bitten by that quirk and so I'm saying |
| 00:14.06 | DocScrutinizer | dang, I never tested if FR uboot actually would boot from an ext2/3 with 128bit inode size |
| 00:14.37 | DocScrutinizer | I just seem to remember it been supposed to bot from ext in early days of gta01 |
| 00:14.49 | mth | in any case, let's first get it booting from FAT32 and later add FAT12/16 support if we might need it |
| 00:15.07 | whitequark | mth: Ayla: dump everything except FAT32. make a note in README. |
| 00:15.14 | whitequark | fat16 support isn't worth the time required for it |
| 00:15.29 | DocScrutinizer | yup |
| 00:15.37 | whitequark | support for users not caring to read README isn't, too |
| 00:18.14 | DocScrutinizer | esp if those users dare to repartition a SD that by default comes with VFAT |
| 00:21.00 | mth | Ayla: if you put filename and ext in one array, you can compare it to "VMLINUZ\0BIN" in one go |
| 00:21.26 | Ayla | mth: probably, I'm not there yet |
| 00:22.47 | whitequark | Ayla: seriously, why not take an existing FAT access code? |
| 00:22.54 | whitequark | it has been written way more times than it should be |
| 00:23.08 | Ayla | whitequark: I do have an existing FAT access code |
| 00:23.20 | whitequark | so what's wrong with it? |
| 00:23.21 | Ayla | I'm almost copying the u-boot code |
| 00:23.29 | Ayla | but there's so much stuff in there I don't need |
| 00:24.45 | Ayla | and I like to understand what I program |
| 00:25.12 | whitequark | yet another wheel reinvented out of pure curiosity |
| 00:25.34 | whitequark | has a collection of those |
| 00:26.28 | Ayla | that's called evolution |
| 00:26.36 | Ayla | wheels used to be in wood |
| 00:27.32 | Ayla | it has still the same function; but now each wheel is made accordingly to the system it composes |
| 00:27.50 | Ayla | a wheel from a bike is not the one from a car |
| 00:27.52 | whitequark | I'll just go and look at rabbits. Funny little rabbits with black twitching noses. |
| 00:39.31 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 00:46.19 | *** join/#qi-hardware zumbi (~zumbi@77.224.206.23) |
| 01:32.30 | *** join/#qi-hardware Ayla (~paul@186.132.123.78.rev.sfr.net) |
| 01:47.32 | mirko | kyak: are you trying to compile in directfb support? |
| 01:47.50 | mirko | building qt4 frequently and don't experience this issue |
| 01:52.07 | *** join/#qi-hardware wej (~j@m2.mullvad.net) |
| 01:53.55 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 01:55.42 | wolfspraul | mirko: hey nice to see you! |
| 01:56.02 | wolfspraul | and thanks a lot for continued care about those things, I am still super happy about OpenWrt in general :-) |
| 01:57.03 | wolfspraul | if we can do things better for smoother integration, never hesitate to post it so we can learn |
| 01:57.46 | mirko | will do, but have to figure out the actual problem before :) |
| 01:58.02 | mirko | wolfspraul: currently in greece, attending the wireless battle mesh meeting |
| 01:58.12 | wolfspraul | sure that was not in reference to this particular issue, just in general |
| 01:58.16 | wolfspraul | greece, nice |
| 01:58.26 | wolfspraul | wireles battle mesh? wow |
| 01:59.01 | wolfspraul | I recently bought some of these little thingies, and of course OpenWrt on them - really good! http://wiki.openwrt.org/toh/tp-link/tl-wr703n |
| 01:59.14 | mirko | hehe, yeah bought some as well |
| 01:59.18 | wolfspraul | 16 USD, 0.5W. finally a worthy successor of my aging nslu2 |
| 01:59.21 | mirko | very neat devices |
| 01:59.39 | mirko | they're not available in europe yet |
| 01:59.41 | wolfspraul | and openwrt really shines on them |
| 01:59.44 | mirko | had to import them from HK |
| 01:59.58 | wolfspraul | well. the reason is that EU+US markets are 'too small' :-) |
| 02:00.03 | wolfspraul | I just lump them both together |
| 02:00.23 | wolfspraul | and not price sensitive enough, that is a product that is so cheap is not pulled forcefully enouhg because none of the distributors are interested to work for such tiny margins |
| 02:00.44 | wolfspraul | but they take off in the world's largest computer markets, starting with China, and then other huge and growing markets |
| 02:01.21 | wolfspraul | they are everywhere here in China, at every corner shop |
| 02:01.40 | mirko | wolfspraul: there is also a different model - having a grey case instead of blue |
| 02:01.43 | wolfspraul | including low-cost variants (yes), like the 702n and even more lost-cost 'no-name' versions |
| 02:01.43 | mirko | and kind of a display |
| 02:01.49 | wolfspraul | low-cost meaning another 1 USD less... |
| 02:02.04 | mirko | the 702 has 2MB flash |
| 02:02.06 | wolfspraul | there are many variants |
| 02:02.22 | wolfspraul | it's hard to imagine that there is another 'no-name low-cost' white label essentially |
| 02:02.27 | wolfspraul | for a product that already retails at 16 USD |
| 02:02.28 | wolfspraul | but there is :-) |
| 02:02.34 | mirko | :) |
| 02:02.51 | wolfspraul | you can only understand this from the perspective of a huge market like china with 1.3 billion people, which is also extremely price sensitive |
| 02:02.53 | mirko | just for the record: http://battlemesh.org/BattleMeshV5 |
| 02:03.01 | wolfspraul | they will get to EU/US later, if anyone there cares... |
| 02:03.16 | wolfspraul | (it's the distributors that don't care, not the consumers, since it doesn't even reach them) |
| 02:04.01 | wolfspraul | battle mesh, yes, reading |
| 02:04.06 | wolfspraul | very interested in anything rf, mesh, p2p |
| 02:04.09 | wolfspraul | sdr |
| 02:05.25 | kristianpaul | 702, not be supported in OpenWRT !! oh |
| 02:05.37 | wolfspraul | yeah come on, stay away from those 'cost-down' versions |
| 02:05.47 | wolfspraul | like removing the USB connector to save, what, 10 cents? |
| 02:05.54 | wolfspraul | and then not having USB host because of that... |
| 02:06.05 | mirko | kristianpaul: 2MB flash - you can strip openwrt down to fit in 2MB but it's just not worth it and fun |
| 02:06.39 | kristianpaul | mirko: and poor usefullness later.. |
| 02:07.13 | wolfspraul | mirko: so you are a 'mesh networking enthusiast and community networking activist'? cool! :-) |
| 02:09.40 | kristianpaul | battle rf could be fun ;) |
| 02:10.06 | mirko | wolfspraul: well, it's all OpenWrt related as well |
| 02:10.20 | mirko | since most nodes are running OpenWrt |
| 02:11.06 | kristianpaul | removing the USB connector, remenbers me some of nanonote history about usb host :) |
| 02:11.28 | wolfspraul | mirko: I think OpenWrt is doing just fine |
| 02:11.54 | mirko | yeah, got most OpenWrt-devs to attend the event as well |
| 02:11.57 | wolfspraul | so I am serious when I worry about 'how can we integrate with upstream (owrt) better', 'how can we keep long-term maintenance costs down', etc. |
| 02:12.06 | wolfspraul | the future is bright :-) |
| 02:12.10 | mirko | yesterday we had quite a long and productive meeting dedicated to openwrt |
| 02:12.13 | kristianpaul | mirko: havent seems rtl-sdr? |
| 02:12.20 | kristianpaul | see* |
| 02:12.26 | wolfspraul | ah hey, we need really good milkymist soc support in openwrt one day :-) |
| 02:12.45 | wolfspraul | but some homework to do on our end first, ahem. say a year or so :-) |
| 02:13.02 | mirko | wolfspraul: well, i'm willing to assist but working full-time currently - bdesides my very own projects :) |
| 02:13.09 | mirko | hehe |
| 02:13.09 | wolfspraul | sure sure |
| 02:13.33 | wolfspraul | first priority is to keep ben nanonote image from falling apart |
| 02:13.52 | wolfspraul | on the milkymist side a lot of groundwork is missing and slowly being created |
| 02:14.16 | wolfspraul | mirko: from router manufacturers, which do you think are the most openwrt-friendly, or the best supported by openwrt? |
| 02:15.00 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 02:16.49 | wolfspraul | why do you need to bring ethernet cables, switches and hubs to a meeting that is all about wireless & mesh? :-) |
| 02:17.13 | wolfspraul | http://battlemesh.org/BattleMeshV5#What_to_bring |
| 02:28.21 | mirko | in first instance it's drinking, partying, having no sleep and talking and hacking ;) |
| 02:33.13 | mirko | wolfspraul: it's hard to tell which manufacturer is best currently.. - there's one great netgear router which however costs about 90 euros |
| 02:33.34 | mirko | suprisingly tp-link routers are usually getting supported quite fast as well |
| 02:33.42 | wolfspraul | yes, I didn't mean more or less 'random' products that were found to be 'good' in a reverse way |
| 02:33.45 | mirko | they even advertise currently with openwrt compatibility |
| 02:33.58 | wolfspraul | but I mean whether there are any manufacturers that have an active/proactive role wrt openwrt |
| 02:34.10 | wolfspraul | ah yes, that's interesting! [ads] |
| 02:34.21 | mirko | their role in getting patches upstream is non-existent still |
| 02:34.23 | wolfspraul | are the firmware on those routers built with openwrt? |
| 02:34.30 | mirko | depends on the models |
| 02:35.10 | wolfspraul | is there a manufacturer that realizes there is this thing openwrt and they should have a strategy to align their business with what is happening in openwrt? |
| 02:35.13 | wolfspraul | or not? |
| 02:35.18 | mirko | but the number of manufacturers using a firmware by default based on openwrt is inrceasing |
| 02:35.32 | mirko | wolfspraul: not that we know of currently |
| 02:35.34 | wolfspraul | yeah I would think so |
| 02:35.54 | wolfspraul | in my opinion thinks like the little 16 USD router is what is leading/most innovative economically |
| 02:35.59 | mirko | wolfspraul: usually they just do it without notifying us - and usually their env is heaviliy patched and not based on some recent version of openwrt |
| 02:36.04 | wolfspraul | and those economics are tough |
| 02:36.28 | wolfspraul | at those pricepoints even the smallest engineering effort becomes a large percentage of their margin |
| 02:36.37 | wolfspraul | which should make them more interested in a smooth strategy that includes upstream |
| 02:36.46 | pabs3 | mirko: are there any at all who commit their stuff upstream? |
| 02:37.05 | wolfspraul | but I hear you. thanks! just double-checking... |
| 02:37.09 | wolfspraul | all the same old story then :-) |
| 02:37.21 | wolfspraul | first we wait until the router costs 2 USD, then we see what we do :-) |
| 02:37.28 | mirko | pabs3: not really - not as in: they provide useful patches ;) |
| 02:37.36 | mirko | wolfspraul: got it - thanks :) |
| 02:37.39 | wolfspraul | they cannot afford the staff that would be able to do this |
| 02:38.09 | wolfspraul | 'cannot' not as in cash liquidity, but as in being compatible with their business model |
| 02:39.22 | wolfspraul | maybe some will slowly become just like a regular openwrt user. look up their hardware in the 'toh', then flash the image recommended there :-) |
| 02:39.35 | wolfspraul | that would create an interesting chicken & egg problem :-) |
| 02:40.27 | wolfspraul | mirko: ah, one last thing. do you have any thoughts on qualcomm acquiring atheros? |
| 02:41.34 | mirko | wolfspraul: i'm not that much into this wifi thing.. can't tell |
| 02:41.58 | wolfspraul | I'm asking because it seems there are 2 major makers of the SoCs inside a lot of routers: broadcom and atheros |
| 02:42.13 | wolfspraul | and atheros was acquired by qualcomm over a year ago, so I would think that tech is being integrated into future SoCs |
| 02:42.32 | wolfspraul | but I know too little there, just watching over time and trying to figure out where the interesting new things are happening |
| 02:43.02 | wolfspraul | look at a product like the tp-link TL-MR11U, a battery powered version of the 703n |
| 02:43.20 | wolfspraul | if it has gsm/lte built in? could be used for all sorts of things |
| 02:50.14 | mirko | i know that atheros is restructering in way which goes away from the opensource efforts |
| 02:50.40 | mirko | people are trying to hard to avoid this and try to convince them not giving up this path |
| 02:52.47 | wolfspraul | qualcomm has money to finance proprietary innovation, in fact the profitability of such investments in the past has made them what they are today |
| 02:53.12 | wolfspraul | I think you will have a hard time convincing them about anything open. they will only open the parts that have lost profitability for them. |
| 02:53.16 | wolfspraul | that's the theory |
| 02:53.32 | wolfspraul | but in reality the open routers we have today are cool, no? I only think about the value of the open part... |
| 02:55.38 | mirko | lantiq is great |
| 02:56.02 | mirko | they not producing routers but soc's and eval-boards |
| 02:56.17 | mirko | they are really openwrt-friendly |
| 02:56.28 | wolfspraul | ah interesting. thanks! I will definitely check that out. |
| 02:56.35 | mirko | and finance people writing opensource drivers for them |
| 02:56.38 | wolfspraul | that's what I meant :-) |
| 02:57.01 | mirko | they're one of the few provising an abstracted API for voip/dsl support |
| 02:57.09 | mirko | usually we just get *.ko-files |
| 02:57.19 | wolfspraul | I will read about them some more, very helpful thanks a lot! |
| 02:57.37 | mirko | they encapsulated it into a firmware blob but the API from the kernel and userspace is kept the sam |
| 02:57.41 | mirko | *same |
| 02:57.42 | wolfspraul | I'm trying to understand the companies and their business models, not just looking at products one by one. |
| 02:57.43 | mirko | welcome |
| 02:58.11 | mirko | need to get some sleep now :) |
| 02:58.14 | mirko | see ya |
| 05:28.30 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 05:38.13 | *** join/#qi-hardware wolfspraul (~wolfsprau@114.241.246.140) |
| 06:00.25 | *** join/#qi-hardware Jay7 (jay@128-73-4-95.broadband.corbina.ru) |
| 06:07.25 | *** join/#qi-hardware jurting (~jommpa90_@ip-234-208-230-46.dialup.ice.net) |
| 06:31.14 | *** join/#qi-hardware jluis (~jpddb@83.247.136.72) |
| 06:37.47 | *** join/#qi-hardware xiangfu (~xiangfu@123.123.35.205) |
| 08:43.53 | cladamw | wolfspraul, please add me as happy member under http://projects.qi-hardware.com/index.php/p/kicad-libs/ Thanks a lot ! |
| 08:46.28 | wolfspraul | cladamw: added |
| 08:46.34 | wolfspraul | excellent let's take that on! |
| 08:47.05 | cladamw | nice ! |
| 09:06.22 | *** join/#qi-hardware antoniodariush (~antonioda@nat-sta-slph1.tvu.ac.uk) |
| 09:12.55 | *** join/#qi-hardware xiangfu (~xiangfu@123.123.35.205) |
| 09:27.47 | *** join/#qi-hardware Ayla (~paul@84.155.26.93.rev.sfr.net) |
| 09:30.12 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 09:49.07 | qi-bot | [commit] Xiangfu: cgminer: increase the MAX_DEVICE to 64 (master) http://qi-hw.com/p/openwrt-packages/b96e10c |
| 09:49.08 | qi-bot | [commit] Xiangfu: Merge branch 'master' of projects.qi-hardware.com:openwrt-packages (master) http://qi-hw.com/p/openwrt-packages/617627f |
| 09:49.09 | qi-bot | [commit] Xiangfu: Merge branch 'master' of projects.qi-hardware.com:openwrt-packages (master) http://qi-hw.com/p/openwrt-packages/9a15361 |
| 10:04.33 | qi-bot | [commit] Adam Wang: Added WM9707SCFT/V symbol (master) http://qi-hw.com/p/kicad-libs/b4543b9 |
| 10:25.08 | *** join/#qi-hardware jluis_ (~jluis@2001:5c0:1000:a::248d) |
| 10:30.13 | cladamw | wpwrak, nice today I treated myself ! :-) |
| 10:30.23 | wpwrak | very good ! :) |
| 10:30.25 | cladamw | wpwrak, http://projects.qi-hardware.com/index.php/p/kicad-libs/source/commit/b4543b9/ |
| 10:30.53 | cladamw | yes, ours version are different surely. One question: |
| 10:31.33 | wpwrak | i'm looking at it right now ... |
| 10:32.11 | wpwrak | perhaps it's time to switch to using git add the_file(s)_you_really_want_to_commit |
| 10:32.16 | wpwrak | and only then git commit |
| 10:32.45 | cladamw | wpwrak, http://dpaste.com/721470/ |
| 10:33.09 | wpwrak | that way, you can leave out all the "noise" kicad produces. e.g., your commit also changed things you didn't modify, for example because of the (stupid) timestamps |
| 10:33.55 | wpwrak | (dpaste) yes, that far it was good. what went wrong after ? |
| 10:34.13 | cladamw | my question is why components.pro still has been committed ? |
| 10:34.50 | cladamw | it seems that I didn't use git add components.pro though |
| 10:36.13 | wpwrak | it's the commit -a |
| 10:36.23 | wpwrak | since you already did git add ... |
| 10:36.32 | wpwrak | you would have needed only git commit |
| 10:37.01 | wpwrak | git commit -a commits everything that has been added plus everything that already existed and that has changed |
| 10:37.09 | cladamw | so next time I don't need use '-a' just use git commit |
| 10:37.21 | wpwrak | that's why you also commited "changes" to c8051f320.* |
| 10:37.22 | cladamw | is that right ? |
| 10:37.26 | wpwrak | yes |
| 10:37.29 | cladamw | yeah...phew~ |
| 10:38.08 | cladamw | sorry that. that's why i felt wrong that why c8051f320.* still be modified. :( |
| 10:38.22 | wpwrak | btw, there is a useful script in wernermisc/bin/purge |
| 10:38.34 | wpwrak | it removes timestamp changes from .pro files :) |
| 10:38.54 | cladamw | phew~ so next time: I have to just use git add <FILE> and git commit, right ? |
| 10:39.07 | wpwrak | that is, if only the timestamp has changed, then it removes it. if anything else has changed, it leaves the change(s) there |
| 10:39.54 | cladamw | wow~ so could you change c8051f320.* back to previous ones ? |
| 10:40.00 | wpwrak | after the commit, you should check if there are no other changes you want to commit. (git status or, better, git diff and git diff --cached) |
| 10:40.21 | wpwrak | if there's nothing else, you can throw away unwanted changes with git stash |
| 10:41.03 | wpwrak | "git stash" means that the changes are still around, so if you made a mistake, you can still recover them. but they're out of your way. |
| 10:42.25 | cladamw | phew~ those are may hard a bit for me to understand now. |
| 10:42.50 | wpwrak | git is all about the workflow ;-) |
| 10:44.10 | cladamw | btw, when you use components.pro to add/modify symbols, will you always commit it ? or no need, since i think the components.pro is just for local laptop purpose. right ? |
| 10:45.09 | cladamw | i'll not commit it even I create new symbols. is it make sense to you ? |
| 10:45.26 | wpwrak | i commit it, because that way, anyone can access the new component with eeschema |
| 10:45.39 | wpwrak | otherwise, they'd have to add it manually |
| 10:45.52 | wpwrak | (access it) from kicad-libs/components/ |
| 10:45.52 | cladamw | hmm...okay. i see now. |
| 10:45.57 | wpwrak | you can make sch there |
| 10:46.03 | wpwrak | and then invoke the component viewer |
| 10:47.25 | cladamw | aha...nice that make sch there. |
| 10:49.11 | qi-bot | [commit] Werner Almesberger: a bit of meta-data cleanup after the wm9707scft commit (master) http://qi-hw.com/p/kicad-libs/6faf611 |
| 10:49.17 | cladamw | wpwrak, well... so i'll keep to add symbols for m1r4 these days once i'm available... phew~ soon, we'll have KiCad m1r4 sch. ;-) |
| 10:49.21 | wpwrak | you forgot to add yourself as author :) |
| 10:50.58 | wpwrak | pin 46 is an input ? |
| 10:51.07 | wpwrak | pin 12, too ? |
| 10:51.36 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 10:52.10 | cladamw | wpwrak, how can i edit "./wm9707scft" in the "Preference >> Library" ? |
| 10:52.40 | wpwrak | (don't forget to git pull after my commit, before making any new changes. else, you'll have a merge conflict, e.g., on *.pro) |
| 10:53.08 | wpwrak | (edit) you mean you want to rename it ? |
| 10:53.44 | cladamw | since I found that i tried to add "./" for it. yeah. |
| 10:53.55 | cladamw | but don't know how to use it |
| 10:54.08 | wpwrak | i added the ./ |
| 10:54.25 | cladamw | so you edited the file directly not by EESchema ? |
| 10:54.27 | wpwrak | i just edited the .pro file with a text editor :) |
| 10:54.38 | cladamw | oah.... got it. man |
| 10:54.43 | wpwrak | yes, of course. it's much quicker that way ;-) |
| 10:55.00 | wpwrak | also, kicad may try to change ./ back to nothing |
| 10:55.00 | cladamw | alright, i still have a lot of "git" to learn |
| 10:55.19 | cladamw | yeah...pin 46 is NC, no need an input, |
| 10:55.35 | wpwrak | btw, do you know this one ? http://people.openmoko.org/werner/gta02-core/gta02-core-expanded-all.pdf |
| 10:55.52 | wpwrak | that's still from gta02-core. an view of components with their pin types |
| 10:56.24 | wpwrak | i guess it'll be useful to add something like this to kicad-libs now, too |
| 10:57.40 | cladamw | yeah...so you want me to add symbols as gta02 as possible for m1r4 ? |
| 10:58.06 | wpwrak | not yet. let me set up the framework for it first ... |
| 10:58.37 | cladamw | hmm...yeah |
| 11:01.13 | cladamw | i think we need to set catagory for components, like different lib for like varistor, connector, etc. ? or after your framework. ;-) |
| 11:04.17 | wpwrak | yes. just populating Logic - Single :) |
| 11:04.36 | wpwrak | let's try two levels of category, and then 1, 2, 3... for now |
| 11:04.44 | *** join/#qi-hardware GNUtoo (~gnutoo@host155-102-dynamic.10-188-r.retail.telecomitalia.it) |
| 11:10.00 | cladamw | wpwrak, how to use git stash after my http://dpaste.com/721489/ |
| 11:10.55 | wpwrak | are there any changes you want to keep ? (git diff / git diff --cached ?) |
| 11:11.43 | cladamw | wpwrak, i don't want to commit *.pro. so just git checkout -- *.pro ? |
| 11:12.48 | wpwrak | not sure if this works. try it :) |
| 11:15.13 | *** join/#qi-hardware urandom__ (~user@ip-88-152-219-207.unitymediagroup.de) |
| 11:15.54 | cladamw | nice, just git pull origin master and pulled your new commit. thanks ! phew~ fires on git for me. |
| 11:48.54 | wpwrak | hmm, this calls for a new script ... |
| 11:52.37 | *** join/#qi-hardware wej (~j@m2.mullvad.net) |
| 11:58.38 | wpwrak | and adam will need scriptable kicad soon :) wolfspraul, the procrastination will be short-lived :) |
| 12:05.48 | *** join/#qi-hardware cladamw (~Adam@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 12:20.24 | *** join/#qi-hardware cladamw_ (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 12:32.32 | wolfspraul | wpwrak: oh I'm glad if we can step up, me included |
| 12:32.37 | wolfspraul | which procrastination? |
| 12:32.45 | wolfspraul | did you see the recent kicad-scripting patch on the kicad list? |
| 12:33.05 | wolfspraul | everybody seems to like that, and it will force the same way of code cleanup that will help cmdline processing |
| 12:40.57 | wolfspraul | I was thinking more specifically about kicad layout today |
| 12:41.05 | wolfspraul | so kicad has no autorouter, or semi-auto router |
| 12:41.12 | wolfspraul | but how bad is the manual one? |
| 12:41.25 | wolfspraul | how efficient or inefficient? |
| 12:41.27 | kyak | mirko: yes, i'm building qt4 for directfb support (as by default for nanonote) |
| 12:41.56 | wolfspraul | can you annotate layout or save layout rules together with the traces? |
| 12:42.15 | wolfspraul | how reusable is a kicad layout if someone wants to make an improved or different board? |
| 12:43.48 | wolfspraul | I was looking at a new Intel board I got (DN2800MT) and I was admiring the traces I saw even on top & bottom. could be a lot of layers too. pretty much all traces seemed to be following a number of rules, lots of pairs, lots of length-matching or other irregular shapes like serpentines, weird angles, etc. |
| 12:44.08 | wolfspraul | so I was wondering how good the 'auto-router' even in the best EDA tools might be |
| 12:44.25 | wolfspraul | maybe in the end you will always need to do a lot of manual intervention on anything high-performance? |
| 12:44.37 | wolfspraul | that Intel board certainly looked like that... |
| 12:44.47 | jonand | the autorouters of today are decent, but it's not trivial to set them up to do what you want to achieve |
| 12:44.55 | kyak | mirko: it's a pity it's working fine for you :) so i guess i'll just wait till it hits buildhost (i guess it already did - all qt4 packages magically failed to build in the last "release"). For now buildhost is stuck building some xfce stuff, which needs to be disabled at all (xiangfu?) |
| 12:45.44 | wolfspraul | jonand: do you know anything about how good/bad/usable/reusable kicad layout is? |
| 12:47.13 | jonand | I don't, I heard about kicad only a few weeks ago when I listened to theamphour podcast in my car. I use Cadence tools at work and I've done a few hobby projects in Eagle a few years ago, but I've never tried Kicad. |
| 12:48.09 | wolfspraul | kicad and geda seem to be the two most advanced free schematics and layout suites (geda is a collection that includes some other tools as well I believe) |
| 12:48.18 | wolfspraul | what is "theamphour podcast"? checking... |
| 12:49.24 | kyak | mirko: another thing: qt4 lacks librt as a dependency. How to reproduce: build a minimal image with qt4 only and some app. When launching the app, it complains for missing librt.so. |
| 12:49.39 | wpwrak | (scripting patch) lemme check ... |
| 12:52.37 | jonand | I'm not a layout professional, but the rumors are that the Mentor tools are a step up from Cadence. Here is an article on driving the autorouter on a 400 diff pair 16 layer board. http://www.techdesignforums.com/pcb/pcb-topics/constraint-driven-design/learning-the-value-of-preparation-and-simulation-by-osmosis/ |
| 12:53.00 | kyak | mirko: and the lastest thing: dejavu-fonts-ttf package been split into many packages (i think you did that). However, choosing the "dejavu-fonts-ttf" in menuconfig (or automatically via dependencies) doesn't select subpackages. Therefore, the package "dejavu-fonts-ttf" itself is an empty package and now i don't know how to make an application build with basic font support (unless i choose to depend on a specific font from dejavu-fonts-ttf-*) |
| 12:53.15 | kyak | (sorry guys for interrupting... ) |
| 12:53.19 | *** join/#qi-hardware Ayla (~paul@53.121.101.84.rev.sfr.net) |
| 12:53.45 | wolfspraul | jonand: excellent link, thanks a lot. I will *definitely* read this. |
| 12:54.47 | wolfspraul | one thing I noticed over the years that as much as people talk about how much they prefer this or that tool, or this or that feature in a tools, or how much superior this or that tool or company is, in reality that mostly speaks for the experience of the speaker more than for the tool |
| 12:55.19 | wolfspraul | in other words - the tools can pretty much all 'achieve' the same results, but over often many years, users of tools get totally intertwined with one particular tool or approach, and then find many reasons to explain why that is so |
| 12:55.25 | wpwrak | (scripting) sounds promising. let's hope it's not overly tied to having a window. |
| 12:56.47 | wolfspraul | I wouldn't look at anything past kicad or geda these days. |
| 12:57.48 | wolfspraul | (for those 2 pieces - schematic capture and layout) |
| 12:59.43 | wpwrak | (router) the manual routing is pretty decent. when drawing a trace, it helps you find where to go: DRC will only make points on the same net accessible, "magnetic" pads will draw the trace to the center of the pad, "magnetic traces" will give you drop points off-grid at intersections, and traces can "hug" each other (caution: using this feature, you may have to rip up a number of traces if you want to change anything, since they'll be |
| 12:59.44 | wpwrak | <PROTECTED> |
| 13:00.21 | wolfspraul | if werner had to layout such a board, he would write a small parametric tool just for that board :-) |
| 13:00.34 | wolfspraul | (talking about jonand's link, excellent read imho) |
| 13:00.50 | wpwrak | the parts that are not so good are: traces can't push other traces out of the way (that would be semi-atomatic routing or a "push router"). also, undoing and redoing things needs a lot of clicks |
| 13:01.12 | wolfspraul | and again if you look at 'lessons learned', they didn't use HDI because nobody had experience and they felt they didn't have the time to learn about that |
| 13:01.44 | wolfspraul | and had they known their tool better (I/O Designer), they would have used it differently from the beginning :-) |
| 13:01.51 | wpwrak | (board example) it does look quite parametric, doesn't it ? ;-)) |
| 13:02.14 | wolfspraul | yes, absolutely |
| 13:02.25 | wolfspraul | I think that would be the right approach to layout such a board |
| 13:02.54 | wolfspraul | actually that's what they are doing, just with tools they don't really know that much about (but learn as they try to throw the first problem at the tool) |
| 13:03.01 | jonand | when I started to work as an electronics designer I soon found out that designing anything that is more advanced than microcontrollers with everything built in requires some knowledge in how boards are built up and why. |
| 13:03.02 | wpwrak | (kicad routing) what's important is that i never ran into a situation where i felt kicad was abandoning me. you can always solve the problems, even if it's sometimes a bit circuitous |
| 13:03.20 | wolfspraul | jonand: absolutely |
| 13:03.44 | jonand | there are some excellent books on the subject, like Howard Johnson "high speed design - a handbook of black magic", written in the 90s |
| 13:03.50 | wolfspraul | wpwrak: kicad would probably be terribly bad fit for a board like in jonand's text |
| 13:03.58 | jonand | still very valid today - physics don't change... :) |
| 13:04.11 | wpwrak | yeah. everything manual |
| 13:04.22 | wolfspraul | but then I believe for such a board you might really be best off to write a small meta-tool on top of a simpler base like kicad |
| 13:04.32 | wpwrak | i mean, it does have autoroute and autoplace. but both are rather cruel jokes |
| 13:04.57 | jonand | that said, I'd really advice anyone designing anything with say an FPGA plus external DDR or a CPU with memory to do some IBIS simulations |
| 13:05.39 | wpwrak | last time i checked, you couldn't even stop the autoplace. it tightly packs the components right next to each other, without regard for routing, and at glacially slow speed. |
| 13:05.53 | jonand | running SI simulations really make you understand a lot more about how layer buildup, (lack of) ground return paths, and vias will destroy your signals |
| 13:06.20 | wolfspraul | do you have recommendations which free software to use for IBIS simulations? |
| 13:06.29 | jonand | I doubt there are any |
| 13:06.31 | wpwrak | hmm, we don't have such things for kicad yet |
| 13:07.29 | wpwrak | something that may be useful to add at some point in time would be a trace length comparison: tell pcbnew which traces should be length-matched, then let it show differences, if any are encountered. |
| 13:07.49 | wolfspraul | ok, one by one. First, you probably meant this book http://www.amazon.com/High-Speed-Digital-Design-Handbook/dp/0133957241/ |
| 13:07.50 | jonand | the most popular commercial ones are mentor hyperlynx and cadence sigxplorer |
| 13:07.56 | wpwrak | this would still be a manual aid, but i think it could help a lot |
| 13:08.06 | wolfspraul | we tend to blissfully ignore legacy software :-) |
| 13:08.27 | jonand | that's the book, yes |
| 13:08.55 | wolfspraul | (I am joking, no worries, but it's just so much more fun if you can take the tools apart and it's all free and open... don't understand why any serious engineer can accept to work with blackbox tools, oh well :-)) |
| 13:08.59 | wpwrak | (i firmly believe in automating the things that computers are good at while leaving the things that humans are good at to humans. so, in this example, let kicad do the boring trace length calculation, and let the human figure out what to do with that information) |
| 13:09.22 | wolfspraul | jonand: ok, thanks a lot for that link then, it may come in handy later |
| 13:09.48 | wolfspraul | now IBIS, let me see whether there is anything in FEL, just as a quick search |
| 13:10.22 | jonand | http://www.eda.org/ibis/home/faq/#_1 <-- The parser is freely available in object code format <-- Stallman would explode if he read that line.. :) |
| 13:11.06 | wpwrak | jonand: he must already have grown a meter of steel skin at that spot :) |
| 13:11.13 | wolfspraul | wait wait, let's see. and btw, the Milkymist One board has a spartan-6 fpga and ddr1 memory, and it's working nice and stable |
| 13:11.31 | wolfspraul | I'm not dismissing ibis, not at all, just happy that we got it this far already. |
| 13:12.37 | *** join/#qi-hardware woakas (~woakas@186.29.232.147) |
| 13:12.58 | wolfspraul | oh well, no mention of IBIS at all in http://chitlesh.fedorapeople.org/FEL/list.html |
| 13:13.18 | wolfspraul | so another thing to look at later :-) |
| 13:13.57 | wpwrak | (kicad routing) you can save certain design rules: you can categorize nets and assign a track width, clearance, and via parameters to them. all a but crude, though. |
| 13:15.07 | jonand | how is milkymist related to qi-hardware? |
| 13:15.17 | wolfspraul | thanks for asking |
| 13:15.29 | wolfspraul | Milkymist SoC first is an SoC project |
| 13:15.34 | wpwrak | (cure) e.g., if you have a high-current trace and the trace for a level probe going to it, then both would be the same net and you therefor would have the same trace width for the probe. that is, without switching off DRC or inventing a magic component that splits the trace |
| 13:15.44 | wpwrak | s/cure/crude |
| 13:15.45 | qi-bot | wpwrak meant: "(crude) e.g., if you have a high-current trace and the trace for a level probe going to it, then both would be the same net and you therefor would have the same trace width for the probe. that is, without switching off DRC or inventing a magic component that splits the trace" |
| 13:15.53 | wolfspraul | uses the open LM32 core from lattice (about 25% of the codebase), and then a lot of gpl-licensed peripherals around that |
| 13:16.19 | wolfspraul | then there's a lot of stuff on top of the SoC to actually make it work in a practical environment |
| 13:16.31 | wolfspraul | namely a BIOS, rtems kernel, flickernoise app |
| 13:16.50 | wolfspraul | all of this then comes out as the Milkymist One video synthesizer |
| 13:16.51 | jonand | I met sebastien at HAR2009 where he presented the milkymist, but I'm not up-to-date with what happened with the platform since then. |
| 13:16.56 | wolfspraul | a hardware product you can buy for 500 USD |
| 13:17.04 | wolfspraul | oh nice |
| 13:17.18 | wolfspraul | just checkout milkymist.org or https://sharism.cc/milkymist for the product |
| 13:18.58 | wolfspraul | I wish we can build more focus still, make the SoC stronger, get a really good Linux kernel to run on it, improve the toolchain, improve the Flickernoise app, improve the hardware, improve a lot of things |
| 13:19.02 | jonand | and... it's one thing to get a digital design to work, it's another to get through regulative testing (especially radio interference testing) and to have margins for variations in board impedance, operating temperature, component tolerances and so on. |
| 13:19.13 | wolfspraul | sure |
| 13:19.32 | wolfspraul | but it's also nothing to be afraid of |
| 13:19.47 | jonand | designing is fun, the rest is why they pay you the salary.. :) |
| 13:19.55 | wolfspraul | and from a lot of industry experience, I can tell you - not every company is run like Apple |
| 13:20.06 | wolfspraul | in other words - there is *lots* of junk out there selling in high volume, and nobody cares |
| 13:20.06 | jonand | run like Apple? |
| 13:20.58 | wolfspraul | I am pretty sure the engineering & build quality of the Milkymist One is already in the top 50% of consumer electronics quality that is typically selling in eu/us |
| 13:21.20 | jonand | well, if you are in the fire-and-forget business you can get away with a lousy design. If you have to deal with 20% returns you better have decent margins to be able to afford the bad quality products... |
| 13:22.07 | wolfspraul | I think it's not that easy |
| 13:22.25 | wolfspraul | most hardware manufacturers are under a lot of pressure, mostly cost pressure |
| 13:22.48 | wolfspraul | because that's what consumers care about the most, and it goes all the way through to the component makers |
| 13:23.13 | wpwrak | jonand: (fire and forget) or have an efficient business card printing service, for when you make the weekly change of the company name ;-) |
| 13:23.51 | wpwrak | i think you should get suspicious if a company has a day in its name :) |
| 13:24.07 | jonand | lol |
| 13:24.09 | wolfspraul | nah, I'm talking about something else |
| 13:24.17 | wolfspraul | say you buy a computer from "HP" |
| 13:24.24 | wolfspraul | you think anyone at HP knows anything about this computer? |
| 13:24.31 | wolfspraul | in the shiny TV ads they do |
| 13:24.34 | wolfspraul | but only there |
| 13:25.17 | wolfspraul | in reality it is designed at some company A, which maybe using one or several reference designs from companies B and C |
| 13:25.33 | wolfspraul | and which are again outsourcing certification issues to companies D E and F |
| 13:25.39 | wpwrak | "designed in america" ? :) perhaps some case parts ... |
| 13:25.44 | wolfspraul | then it's handed over to company G for manufacturing |
| 13:26.00 | wolfspraul | which is using subcontractors H I and J for parts of the volume |
| 13:26.08 | wolfspraul | and so on and so on |
| 13:26.42 | wolfspraul | and if you think that all of those really really care about operating temperaturs, board impedance variations, electromagnetic emissions, etc. oh well |
| 13:26.58 | wolfspraul | then you may not have seen all too much into the work of those companies :-) |
| 13:27.01 | *** join/#qi-hardware jow_laptop (~jow@ffx.subsignal.org) |
| 13:27.32 | wpwrak | it's about having someone to blame. if you order 1000 laptops for your company and 20% are DOA, then you'll have a hard time explaining why you bought them from Happy Shenzen Wednesday Ltd. on the other hand, if you bought them from HP, even if they were still made by Happy Shenzen Wednesday, your ass is safe |
| 13:27.40 | wolfspraul | it's funny how company A proudly makes "a" board that passes an EMI test, and then hands over that board to company B for the "volume production" |
| 13:27.54 | wolfspraul | which will after a few days remove the 'unnecessary' parts that made the board pass the EMI test earlier |
| 13:27.57 | wolfspraul | and so on |
| 13:28.23 | wolfspraul | it's not just about returns, doa, 20% |
| 13:28.32 | wpwrak | yeah, there's worse |
| 13:28.50 | *** join/#qi-hardware zenlunatic (~justin@c-68-48-40-231.hsd1.md.comcast.net) |
| 13:28.58 | wpwrak | failure in the field. unstable operation. incompatibilities. and so on |
| 13:28.58 | wolfspraul | jonand: I'm working in greater china for about 5 years now, and I think I've pretty much seen all the pieces now :-) |
| 13:29.30 | wpwrak | jonand: when wolfgang grows bored of computers, he'll become a successful writer of horror novels |
| 13:29.33 | wolfspraul | sure |
| 13:29.47 | wolfspraul | so some notebooks have an average life expectancy of 2 years, some more like 5 |
| 13:30.15 | wolfspraul | it's just super hard to pin it down to a specific company or missing quality check or unqualified staff somewhere in the chain |
| 13:30.22 | pabs3 | so how does Qi deal with these issues? |
| 13:30.45 | wolfspraul | don't understand |
| 13:30.49 | wolfspraul | what do you want to hear :-) |
| 13:31.10 | wolfspraul | marketing speak: Qi is making the absolute *best* hardware you can possibly, ever, find - in the WHOLE WORLD. |
| 13:31.36 | pabs3 | for example I assume Qi is vulnerable to stuff like what you said above: <wolfspraul> which will after a few days remove the 'unnecessary' parts that made the board pass the EMI test earlier |
| 13:31.38 | wolfspraul | meaningless blurb, but it's what you hear from everybody else as well |
| 13:31.49 | wolfspraul | no, not at all |
| 13:31.57 | wolfspraul | we are extremely vertically integrated |
| 13:32.00 | wpwrak | pabs3: qi doesn't have this sort of deep delegation |
| 13:32.11 | wolfspraul | as open hardware that's almost always included in the deal |
| 13:32.30 | wolfspraul | the only other company that vertically integrated I'm aware of is Apple |
| 13:32.33 | wpwrak | pabs3: and wolfgang can probably smell a deal that's too good to be true by now |
| 13:32.41 | wolfspraul | althouhg there may be other smaller ones too, of course. in vertical industries. |
| 13:32.53 | pabs3 | I see :) |
| 13:33.01 | wolfspraul | what deal? |
| 13:33.02 | wolfspraul | :-) |
| 13:33.10 | wolfspraul | hardware quality is difficult to explain |
| 13:33.36 | wolfspraul | and honestly I think most people don't care that much, they just want to hear some fluffy words that makes them believe that what they buy is "good quality" :-) |
| 13:33.43 | wpwrak | the usual "it's chine, so it must be cheap" meme. not sure if it has died out yet or if there are still lots of western companies that fall for it |
| 13:34.07 | wolfspraul | fair enough, since the actual situation is so complex and subtle, you don't want to hear about it |
| 13:34.20 | wolfspraul | so we also just say: Qi is making great quality hardware |
| 13:34.22 | wolfspraul | <1% returns |
| 13:34.24 | wolfspraul | done |
| 13:34.24 | wolfspraul | :-) |
| 13:34.34 | wolfspraul | passes "all" certs |
| 13:34.35 | wolfspraul | of course |
| 13:34.47 | wolfspraul | our hardware is perfect, the best |
| 13:34.48 | wolfspraul | always |
| 13:35.00 | wolfspraul | drop it from an airplane, and it will still work! |
| 13:35.49 | wpwrak | ... as long as it doesn't hit anything. but that's covered by a different clause in the warranty |
| 13:36.41 | wolfspraul | pabs3: btw, if you make Qi hardware, which of course you can, then you automatically fall under our quality guarantee |
| 13:36.44 | wolfspraul | how is that??? |
| 13:38.22 | wpwrak | i think his question was more about avoiding the practical pitfalls :) |
| 13:38.56 | wolfspraul | actually it may sound like a joke, but the quality 'handover' in reality is often not much different |
| 13:39.24 | wpwrak | i guess a lot is based on reputation and perhaps past experience |
| 13:39.29 | wolfspraul | people like werner who start to philosophize over ever last word and punctuation in a spec or standard are rare in the industry |
| 13:40.11 | jonand | it's one thing to have to pay for expensive ferrites and common mode chokes because you try to filter your way below the EMI limit. It's another to have the correct series termination from start because you spent an hour or two simulating your address bus. |
| 13:40.11 | wolfspraul | there are many cases where parts, standards, procedures are bouncing back and forth between a number of companies until "it fits" |
| 13:40.35 | jonand | I preach EMC compliance by design, not by filter/screening |
| 13:40.44 | wolfspraul | yep |
| 13:40.51 | wolfspraul | it won't survive the first day "on the line" |
| 13:40.54 | jonand | which is really just band-aid when you've produced thousands of PCBs already |
| 13:40.59 | wolfspraul | well, mabe if the EE has a day off, on the first day it will stay there |
| 13:41.09 | wolfspraul | but on the second when he's back it will be removed |
| 13:41.20 | wpwrak | US client to chinese engineer, in the telephone conference: "did you read the spec ?" "Yes." "does it comply ? "Yes." ... :) |
| 13:41.31 | jonand | thing is that IMMUNITY noncompliance is what will kill you |
| 13:41.47 | wolfspraul | don't worry we are all on the same page here |
| 13:41.52 | jonand | routers that hang when not resetted after a brownout will kill that router brand name |
| 13:41.57 | wolfspraul | I think one promise of open hardware is that we can go for *higher* quality than usual |
| 13:42.02 | wpwrak | (that's more or less this sort of real life conference calls i've experienced. oh, and that was of course a non-affirmative "yes". the person in question didn't understand a single word :) |
| 13:42.10 | wolfspraul | because open designs can be shared and reused and better understood among more people |
| 13:42.57 | wolfspraul | we are not just dreaming about this, but making functioning high-performance gear |
| 13:43.05 | wolfspraul | which we sell and service and take back on failure, etc. etc. |
| 13:43.14 | wolfspraul | and which passes fcc/ce emi compliance, and what not |
| 13:43.37 | jonand | higher quality and also actually explain what's needed and why. regulations are not made up of evil people, they are a compromise on what will work reliably out in the field. the sad thing is that they tend not to explain WHY they are needed, which make them appear like a penalty rather than a help |
| 13:43.53 | wolfspraul | I agree |
| 13:43.59 | wolfspraul | standards are important |
| 13:44.29 | wpwrak | tracking the background of things is often rather hard indeed |
| 13:44.51 | wpwrak | and once that chain is lost, you're in the merry land of cargo cult and voodoo engineering |
| 13:45.11 | wpwrak | or standards-as-a-penalty |
| 13:45.20 | wolfspraul | I don't think like that |
| 13:45.32 | wolfspraul | a standard is either good and thus followed, or ignored |
| 13:46.09 | wpwrak | naw you also get the bad ones you still have to follow. and some may actually be good, but they look bad |
| 13:46.24 | wpwrak | and if enforcement is nasty enough, everybody follows them, even if they're bad |
| 13:46.36 | wolfspraul | of course I say this with the liberty of looking from Beijing, which means that if the 20% of the world population really doesn't want product A because they actually enforce standards, then we sell it to the other 80% only :-) |
| 13:46.37 | wpwrak | no matter how much band aid you have to pour on that board |
| 13:46.55 | wolfspraul | and we make a version A+ with even higher margin for those 20% |
| 13:47.19 | wpwrak | the high cost of those non-fake certificates :) |
| 13:47.20 | jonand | those 80% can go reset their router every second day, I'm fine with that. |
| 13:47.42 | wolfspraul | sure, but that's how bad regulations are flushed out |
| 13:47.46 | wolfspraul | and I agree that most are good |
| 13:48.04 | wpwrak | jonand: that's one minimum wage job. not too bad :) |
| 13:48.09 | wolfspraul | because if a regulation is meaningless, the 80% will find out and decide with their wallets |
| 13:48.11 | jonand | so you are located in Beijing? |
| 13:48.13 | wolfspraul | don't underestimate those wallets |
| 13:48.24 | wolfspraul | yes |
| 13:48.43 | jonand | how's the electronics industry there compared to shanghai? |
| 13:48.54 | jonand | shanghai or suzhou? |
| 13:49.12 | wolfspraul | there's companies everywhere |
| 13:49.16 | wolfspraul | don't understand |
| 13:49.18 | wpwrak | wolfspraul: i think it's more complex. people also attach different values to longevity, cost of failure, cost of replacement, etc. |
| 13:50.00 | jonand | wolfspraul: as in "level of competence, level of wages" and so on |
| 13:50.18 | wolfspraul | sure, but I think we all agree on A) following regulations and going for good standards b) identifying the bad/meaningless/stupid standards as such and trying to at least advocate them as bad |
| 13:50.49 | wolfspraul | and I think for the most part the quality of standards is actually good |
| 13:50.58 | wpwrak | wolfspraul: so if jonand really hates to have to rest his router, he may find having to spend 50% more a very good deal. meanwhile, the room full of routers in the Great Chinese Firewall may very well just have a few sidekicks that do nothing but look for lights that are "stuck" and press the little red button under it |
| 13:51.44 | *** join/#qi-hardware panda|x201 (~hzhang@2001:5c0:1000:a::1fc9) |
| 13:52.09 | wolfspraul | yeah but I think we are all on the same page |
| 13:52.31 | wolfspraul | we all like quality products that we deeply understand and that we know we can trust and are reliable and follow the best standards, and and and |
| 13:52.53 | jonand | :) |
| 13:52.59 | wolfspraul | yet still at any moment we know any tiny resistor or cap on our super board may fail, for a variety of reasons |
| 13:53.02 | wolfspraul | and will we notice? |
| 13:53.16 | wpwrak | depends :) |
| 13:53.17 | wolfspraul | will one of our beloved standards now not be met anymore without us noticing? |
| 13:53.24 | wolfspraul | that is very possible |
| 13:53.57 | wolfspraul | or do you check your home regularly for electromagnetic offenders? |
| 13:54.13 | wolfspraul | (for example) |
| 13:54.15 | wolfspraul | probably not |
| 13:54.44 | wpwrak | i'm probably the biggest of them within some 50 m bubble ;-) |
| 13:54.44 | wolfspraul | so in reality complex hardware is always subtle, and may fail in subtle ways. no matter how well we design it, manufacture, test, etc. |
| 13:54.58 | jonand | Actually, my spectrum analyzer is powered on most of the time.. :) |
| 13:55.06 | wolfspraul | there you go :-) |
| 13:55.23 | jonand | typically not hooked up to any antenna though.. . |
| 13:55.38 | wpwrak | jonand: even better for finding offenders ;-) |
| 13:56.09 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host155-102-dynamic.10-188-r.retail.telecomitalia.it) |
| 13:56.18 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host155-102-dynamic.10-188-r.retail.telecomitalia.it) |
| 13:57.17 | jonand | but again, immunity is the important thing. if your device locks up just because someone is flipping the light switch, the fridge/ac compressor is starting or your neighbour is welding... you will get customer complains killing any margins/profit you thought you had on your design |
| 13:57.25 | wpwrak | wolfspraul: component failure is random. but you can still influence how often it happens and what consequences it has. if you just say "anything can fail anytime anyway", then that's like saying that it's okay to sleep with a piece of radium under your cushion because anyone can get cancer anyway |
| 13:57.46 | wolfspraul | I am clear about that |
| 13:58.04 | mirko | kyak: regarding librt and dejavu-font-package i'll take a look now |
| 13:58.09 | wolfspraul | but we speak in an open and logged channel, so it may be important to try to open up the minds of whatever unknown reader masses may read this one day |
| 13:58.21 | wolfspraul | and - every solder joint may fail at any time |
| 13:58.41 | wpwrak | jonand: i think the most important thing in our case is that the community can also help itself |
| 13:59.19 | jonand | and a device with bad signal integrity (lots of energy radiated as radio interference) is way more likely to be susceptible for say your cell phone transmitting at 1W peak |
| 13:59.55 | jonand | more likely than a design with a proper layout |
| 14:00.23 | jonand | so I see it the other way around. If a device is quiet (and not filled with screens and ferrites) I know it is solid |
| 14:00.37 | wolfspraul | modern computing hardware is just very subtle, and for the most part cannot self-analyze much if anything |
| 14:00.57 | wolfspraul | so there is always a huge variety coming off the production line, and from then on with every day that passes it only gets more diverse |
| 14:01.22 | wolfspraul | jonand: quiet? |
| 14:01.24 | wpwrak | jonand: continuously improving our design processes is certainly part of the concept |
| 14:01.40 | *** part/#qi-hardware jurting (~jommpa90_@ip-234-208-230-46.dialup.ice.net) |
| 14:01.51 | wolfspraul | I also think we have to go *way* beyond just thinking about the perfect design |
| 14:02.42 | wolfspraul | to testing software, during production and after a product is sold, testing under all sorts of stress, seeing how designs look like after some time of usage, etc. |
| 14:02.52 | wpwrak | jonand: even better, anyone can help. e.g., you know a lot about EMC. most people don't. we're not even sure how good the people to whom we outsource the M1 layout are in that regard. we believe they're good overall, but we might miss some weak spots. or a bad day, etc. |
| 14:04.00 | wpwrak | jonand: but the results are openly accessible. (the design files as well, but they use proprietary tools. that's why we want to move to kicad.) so you could review them, and tell us if you find anything suspicious. |
| 14:04.10 | jonand | a lot... well, I've learnt some the hard way by spending far too much time at regulatory test houses.. :) |
| 14:04.41 | jonand | wolfspraul: quiet as in "does not max out my spectrum analyzer when I approach it with a near field probe" |
| 14:04.52 | wpwrak | jonand: and once we learn some new rules, they can be shared with others who may not have much experience but still a good pair of eyes :) |
| 14:04.55 | wolfspraul | ah, quiet on the spectrum analyzer, got it |
| 14:05.16 | wolfspraul | jonand: what spectrum analyzer do you use if I may ask? |
| 14:06.24 | wpwrak | jonand: (filled with screens and ferrites) you would have loved one project i bumped into in a former life. it had GPS and lots of interference issues. so piles of EMI filters were added and so on. |
| 14:06.37 | jonand | I have an old hameg. Been thinking about upgrading but then again I'm not really an RF guy, more into the digital domain. Not that those are too wide apart these days though.. :) |
| 14:06.55 | wolfspraul | can you do us a favor and post the exact hameg model? |
| 14:07.01 | wolfspraul | we are a bit obsessed about learning here :-) |
| 14:07.36 | wpwrak | jonand: (evil project) it also had another issue: USB would inexplicably fail from time to time. they thought it was a kernel issue. so i searched for that. didn't find anything overly suspicious. then we poked around signal integrity and such. nothing. |
| 14:08.41 | wpwrak | jonand: (evil project) then we suspected power distribution: power entered at the top of the CPU and then went in a merry almost-circle around it. so we added beads, caps, etc., to fix that routing. still nothing. |
| 14:08.49 | jonand | wolfspraul: http://www.hameg.com/0.45.0.html?0= <-- HM5014 |
| 14:08.58 | wolfspraul | thanks! |
| 14:09.40 | jonand | If you are to buy anything I would suggest to get one which covers up to 2.6G |
| 14:09.59 | jonand | this one is intended for precompliance EMI tests and is limited to 1G |
| 14:10.12 | wpwrak | jonand: (evil project) finally, on the day the EEs would sign off the layout for the next (and probably last) try, i stumbled into their layout review meeting. there, i saw the following: |
| 14:10.31 | jonand | but then you miss out the 2.4g band and also the LNB downlink from your satellite dish |
| 14:10.35 | jonand | 950-2150 |
| 14:11.13 | wpwrak | jonand: (evil project) CPU had its XTAL connections in the 4 o'clock position. the crystal was located in the 10 o'clock position, with traces going all the way across the CPU, and even nicely to the other side of the PCB and back. |
| 14:12.07 | jonand | wpwrak: did you laugh or cry? :) |
| 14:12.09 | wpwrak | jonand: (evil project) to top this, right under the xtal traces, there were the DRAM signals. naturally, no ground in between or left or right. |
| 14:13.33 | wpwrak | jonand: i was actually quite happy :) we had spent something like two months on that problem, and all the band aids we had thrown at it seemed futile. when i saw that mess, i know we had found it :) |
| 14:13.38 | jonand | actually, routing clock traces across the board is not that bad, IF you 1. keep your signal return in a solid ground plane below the trace 2. stay on one layer 3. have proper termination |
| 14:14.19 | wolfspraul | jonand: here's a milkymikst one emi document, any feedback would be more than welcome http://en.qi-hardware.com/w/images/1/1a/Reichl_milkymist_one_tests_11000301.pdf |
| 14:14.28 | jonand | and 4. stay away from board edges |
| 14:15.04 | *** join/#qi-hardware jivs (~jivs@nat-sta-slph1.tvu.ac.uk) |
| 14:15.36 | wpwrak | jonand: we couldn't clean it up completely at that time, but we could at least remove the very worst offenses. like pushing the traces a few mm to the side. and that already was enough to make the thing work well enough to proceed. (the project died later for other reasons, so i think the design was never fully cleaned up, though) |
| 14:17.29 | wpwrak | jonand: (routing clock) yeah, there were none of these niceties. plus, this was to the "naked" crystal. not some nice differential digital signal or such. |
| 14:18.10 | wpwrak | jonand: that design was more or less a textbook example illustrating everything you should never do |
| 14:20.05 | wpwrak | jonand: one problem was that all the EDA things were behind proprietary tools. so already getting printable schematics was difficult. and i hardly saw the layout at all (before that fateful day). why the EEs who had had all this right in front of their noses the whole time didn't see it is a bit of a mystery to me, though. |
| 14:28.16 | jonand | wolfspraul: wow, pretty low emissions in that report! |
| 14:29.34 | jonand | so is this the current layout? http://milkymist.org/mmone/rc3_gerber.tar.bz2 |
| 14:33.53 | mirko | kyak: hmm.. the font stuff gets complicated - it was tried to get fixed by mb however i reverted that commit since it broke other stuff |
| 14:34.28 | jonand | the ksz8001 contains an ibis model... "let me download and have a look".. |
| 14:39.23 | kristianpaul | low enought to allow us easilly to add built-in antennas for GPS and posibly other RF aplicationsn? |
| 14:39.33 | kristianpaul | hi jonand :) |
| 14:39.53 | *** part/#qi-hardware rozzin (~rozzin@209-20-69-211.slicehost.net) |
| 14:46.07 | wolfspraul | jonand: yes from the name that looks like the current gerbers |
| 14:50.23 | jonand | kristianpaul: to know that you need to know what you have at GPS and the other RF bands you are considering.. therefore my advice on getting a spectrum analyzer covering the popular bands... |
| 14:50.51 | *** join/#qi-hardware urandom__ (~user@ip-88-152-216-239.unitymediagroup.de) |
| 15:09.31 | wpwrak | now, where to find a cheap one :) |
| 15:11.56 | kristianpaul | rtl-sdr wont work for that?.. |
| 15:16.33 | wpwrak | you mean something like USRP ? it does, but it has its limits |
| 15:19.41 | kyak | mirko: i see.. probably it makes sense to combine it back into a single package? Usually the fonts wouldn't be installed on routers, so... |
| 15:21.17 | kristianpaul | wpwrak: yes |
| 15:21.26 | wpwrak | e.g., lack of calibration, quite limited bandwidth, and you also need several RF frontends if you want to cover the whole spectrum to 2.x GHz (the latter aspect has gotten a bit better recently, though. now you only need two boards for most of the interesting frequencies) |
| 15:25.37 | mirko | kyak: hmm.. not sure yet |
| 15:26.17 | wpwrak | but yes, it's far better than nothing :) |
| 15:47.48 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 16:08.45 | *** join/#qi-hardware kuribas (~user@d54C43316.access.telenet.be) |
| 17:54.51 | *** join/#qi-hardware rozzin (~rozzin@209-20-69-211.slicehost.net) |
| 19:04.00 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-39-238.w109-223.abo.wanadoo.fr) |
| 19:55.02 | *** join/#qi-hardware infobot (~infobot@rikers.org) |
| 19:55.02 | *** topic/#qi-hardware is Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs |
| 19:55.02 | *** mode/#qi-hardware [+v infobot] by ChanServ |
| 19:58.46 | *** join/#qi-hardware uwe_ (~uwe_@dslb-088-066-186-052.pools.arcor-ip.net) |
| 20:07.30 | *** join/#qi-hardware antgreen (~user@70.50.65.29) |
| 20:28.48 | *** join/#qi-hardware viric_ (~viric@unaffiliated/viric) |
| 20:33.22 | kristianpaul | wonders if there are programable LNA's |
| 21:06.34 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-39-238.w109-223.abo.wanadoo.fr) |
| 21:08.15 | *** join/#qi-hardware LunaVorax_ (~LunaVorax@ABordeaux-651-1-41-219.w109-223.abo.wanadoo.fr) |
| 21:20.43 | *** join/#qi-hardware jekhor (~jek@77.215.97.60) |
| 21:22.54 | *** join/#qi-hardware Ayla (~paul@186.132.123.78.rev.sfr.net) |
| 21:54.59 | *** join/#qi-hardware frankblues (~alex@c-67-182-230-190.hsd1.ut.comcast.net) |
| 22:14.04 | *** join/#qi-hardware dvdk (~dvdkhlng@g225039107.adsl.alicedsl.de) |
| 22:32.47 | *** join/#qi-hardware aisa (~a@209.234.140.58) |
| 22:56.19 | *** join/#qi-hardware aisa (~a@209.234.140.58) |
| 23:11.13 | wolfspraul | wpwrak: with rtl-sdr kristianpaul meant this one http://sdr.osmocom.org/trac/wiki/rtl-sdr |
| 23:11.42 | wolfspraul | it's a 10 USD usb dongle, which although receive-only seems to give you a good starting point into gnuradio & sdr |
| 23:11.58 | wolfspraul | tuner goes from 64mhz to about 1700mhz |
| 23:12.09 | wolfspraul | demodulator can be configured to send raw samples to the host |
| 23:12.15 | wpwrak | oh dear :) |
| 23:12.37 | wpwrak | USRP looks rather powerful in comparison ;-) |
| 23:13.03 | wpwrak | but yes, the principle is the same. just that rtl-sdr doesn't cover some of the most interesting frequencies |
| 23:13.43 | wolfspraul | sure, but at 10 USD it allows people to first focus on the software side |
| 23:13.55 | wolfspraul | and then when they really understand the various subtleties, they can uptick their hardware as needed |
| 23:13.59 | wolfspraul | I do think that makes a lot of sense |
| 23:15.11 | wpwrak | the price in unbeatable, agreed. and it's sufficient to, say, listen into FM or some GSM |
| 23:15.17 | wpwrak | s/in/is |
| 23:15.18 | qi-bot | wpwrak meant: "the price is unbeatable, agreed. and it's sufficient to, say, listen isto FM or some GSM" |
| 23:15.31 | wolfspraul | or local TV, its original purpose |
| 23:15.42 | wolfspraul | or maybe taxi radio, police radio? satellite phones? |
| 23:16.09 | wolfspraul | it's 20 USD by the time someone with some english skills has put it on an international shopping site |
| 23:17.27 | wpwrak | :) |
| 23:19.30 | wpwrak | pity it doesn't go a little higher. 800 MHz more and there would be lots of ISM band fun |
| 23:19.46 | wpwrak | well, lots more ISM band fun |
| 23:19.46 | wolfspraul | maybe one or two ic gens later? :-) |
| 23:20.05 | wpwrak | if they don't pull the feature :) |
| 23:20.16 | wolfspraul | there are 2 chips left now, a realtek demodulator/soc, and an elonics tuner although that one seems replacable with alternatives from fitipower, noxon, etc. |
| 23:20.45 | wolfspraul | sure they can, it's a more or less typical "found a chance" reverse engineering effort |
| 23:21.01 | wolfspraul | but so what, it gets people started, they learn, and then become more agile and more independent later |
| 23:22.40 | wpwrak | when the products approach EOL, there may be an opportunity to buy up a lot of them and sell them with a nice margin once they get de facto unobtainable |
| 23:22.54 | wolfspraul | (they have another, I believe even s-6 fpga based osmosdr board in the making, including tx, but the discovery of this 10/20 USD dongle distracted them a little. so the alternatives are already in the making...) |
| 23:23.11 | wolfspraul | I'm not so pessimistic at all, no need to do that. |
| 23:23.16 | wpwrak | (distraction) i can imagine :) |
| 23:23.26 | wpwrak | it would be a service |
| 23:24.37 | wolfspraul | ics actually rarely go eol, most of the time the new chips are just better for everyone - and - a lot of ic companies are handing over old chips to specialized small companies that are making old chips 'from the archive' for as long as there are customers willing to pay the premium |
| 23:25.15 | wolfspraul | that's not always true, for example if a chip is closely tied to a particular manufacturing technology which is also being dismantled or upgraded as the new gen comes out |
| 23:25.33 | wpwrak | yes, but once the boards don't get made anymore, the overall cost jumps up. even if you can still get the chips. |
| 23:25.38 | wolfspraul | but in a lot of cases it's true, smaller more niche chips |
| 23:25.59 | wolfspraul | oh sure, costs go up and up if you step outside of the big stream |
| 23:26.08 | wpwrak | well, SDR is the future. good to see it get more accessible. |
| 23:26.19 | wolfspraul | yes |