| 00:00.54 | *** join/#qi-hardware GNUtoo (~gnutoo@host171-91-dynamic.54-79-r.retail.telecomitalia.it) |
| 00:23.40 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 00:26.46 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 00:33.19 | *** join/#qi-hardware uwe_mobile__ (~uwe@static.88-198-8-117.clients.your-server.de) |
| 00:37.56 | *** join/#qi-hardware lg_quassel (~quassel@75-162-50-181.desm.qwest.net) |
| 00:37.56 | *** join/#qi-hardware Jay7x (jay@128-73-227-84.broadband.corbina.ru) |
| 00:38.21 | *** join/#qi-hardware rlifchitz (~rlifchitz@chp75-1-78-192-117-13.fbxo.proxad.net) |
| 00:42.50 | *** join/#qi-hardware DocScrutinizer51 (~lagrange@lagrange.cloud-7.de) |
| 00:42.50 | *** join/#qi-hardware lindi-_ (~quassel@tachyon.hut.fi) |
| 00:42.50 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 00:45.20 | *** join/#qi-hardware freespac1 (foobar@stark.pictorii.com) |
| 00:45.21 | *** join/#qi-hardware liuqi_ (~liuqi@li162-156.members.linode.com) |
| 00:45.21 | *** join/#qi-hardware zedstar_ (~john@zedstar.com) |
| 00:45.21 | *** join/#qi-hardware xwalk_ (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 00:45.21 | *** join/#qi-hardware methril (~methril@89.100.193.130) |
| 00:45.21 | *** join/#qi-hardware djbclark (~djbclark@fsf/member/djbclark) |
| 00:45.21 | *** join/#qi-hardware phirsch (~smuxi@xdsl-89-0-83-183.netcologne.de) |
| 00:45.21 | *** join/#qi-hardware paroneayea (~user@fsf/member/paroneayea) |
| 00:45.21 | *** join/#qi-hardware wpwrak (~werner@234-171-231-201.fibertel.com.ar) |
| 00:45.21 | *** join/#qi-hardware Martix (~martix@4.177.broadband3.iol.cz) |
| 00:45.21 | *** join/#qi-hardware pabs3 (~pabs@d122-111-252-61.per801.wa.optusnet.com.au) |
| 00:45.21 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.131) |
| 00:45.21 | *** join/#qi-hardware woakas (~woakas@186.28.180.143) |
| 00:45.21 | *** join/#qi-hardware kyak (~kyak@unaffiliated/kyak) |
| 00:45.21 | *** join/#qi-hardware roh (~roh@yamato.hyte.de) |
| 00:45.21 | *** join/#qi-hardware marcan (marcan@marcansoft.com) |
| 00:45.21 | *** join/#qi-hardware mth (srjqfitb@dhcp-089-098-069-120.chello.nl) |
| 00:45.21 | *** join/#qi-hardware _whitelogger (~whitelogg@kaunan.whitequark.org) |
| 00:45.21 | *** join/#qi-hardware jow_laptop (~jow@ffx.subsignal.org) |
| 00:45.21 | *** join/#qi-hardware qi-bot (~qi-bot@turandot.qi-hardware.com) |
| 00:45.21 | *** join/#qi-hardware hozer (~hozer@excalibur.hozed.org) |
| 00:45.21 | *** join/#qi-hardware Fallenou (~sionneau@yozora-irc.net) |
| 00:45.21 | *** join/#qi-hardware ChanServ (ChanServ@services.) |
| 00:45.21 | *** mode/#qi-hardware [+oo qi-bot ChanServ] by wolfe.freenode.net |
| 00:45.37 | *** join/#qi-hardware kristianpaul (~kristianp@cl-498.udi-01.br.sixxs.net) |
| 00:45.37 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 00:46.22 | *** join/#qi-hardware phirsch (~smuxi@xdsl-89-0-83-183.netcologne.de) |
| 00:46.41 | *** join/#qi-hardware GeorgeH (~George@c-69-141-105-145.hsd1.nj.comcast.net) |
| 00:50.56 | *** join/#qi-hardware DocScrutinizer51 (~lagrange@lagrange.cloud-7.de) |
| 00:50.56 | *** join/#qi-hardware lindi-_ (~quassel@tachyon.hut.fi) |
| 00:50.56 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 00:54.32 | *** join/#qi-hardware panda (~hzhang@221.230.23.74) |
| 01:08.21 | *** join/#qi-hardware zumbi (~zumbi@77.224.206.23) |
| 01:23.25 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 01:52.10 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 02:55.41 | *** join/#qi-hardware rejon (~rejon@li408-40.members.linode.com) |
| 03:24.10 | *** join/#qi-hardware Guest12542 (~hzhang@222.186.101.194) |
| 03:43.39 | *** part/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 03:47.45 | *** join/#qi-hardware xwalk (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 04:26.24 | *** join/#qi-hardware rejon (~rejon@114.244.46.101) |
| 04:43.33 | *** join/#qi-hardware xiangfu (~xiangfu@123.115.10.11) |
| 05:08.45 | *** join/#qi-hardware xwalk (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 05:10.51 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 05:26.41 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 05:30.45 | *** join/#qi-hardware kyak (~kyak@95-26-116-100.broadband.corbina.ru) |
| 05:30.45 | *** join/#qi-hardware kyak (~kyak@unaffiliated/kyak) |
| 05:32.47 | *** join/#qi-hardware phirs230 (~smuxi@xdsl-89-0-154-49.netcologne.de) |
| 06:25.00 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 06:42.22 | *** join/#qi-hardware jluis|work (~jpddb@83.247.136.72) |
| 07:18.47 | *** join/#qi-hardware rejon (~rejon@114.244.46.101) |
| 08:06.38 | *** join/#qi-hardware jurting (~jommpa90_@ip-52-215-241-92.dialup.ice.net) |
| 08:56.06 | *** join/#qi-hardware zedstar (~john@fsf/member/zedstar) |
| 09:15.10 | *** join/#qi-hardware jivs (~jivs@193.63.24.74) |
| 09:19.39 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 09:27.36 | kyak | reading about TI launchpad.. it has "touch-sense enabled I/Os" - wtf is that? |
| 09:28.42 | kyak | well, MSP430G* has it.. i'm confused by "touch sense" |
| 09:30.55 | wpwrak | kyak: it probably means that someone figured out a way to connect a capacitative sensor |
| 09:32.09 | wpwrak | kyak: the leanest solution i've seen so far comes from atmel: just the internal ADC and a series resistor. and i suspect you don't need that resistor. so it's not all *that* demanding in the hw side :) |
| 09:33.15 | kyak | wpwrak: ok, it's clear, thanks! so probably "touch sense I/O" is just a marketing word :) |
| 09:34.29 | kyak | i could resist ordering it.. damn, it's so cheap |
| 09:34.39 | kyak | shipping included |
| 09:35.15 | wpwrak | the real cost is in the development effort :) |
| 09:36.12 | wpwrak | at least, with a ben and ubb, you can easily make your own programmer (if they document the in-circuit programming protocol) |
| 09:36.34 | kyak | well, i could run mspdebug on Ben |
| 09:37.02 | kyak | and program launchpad easily without knowing the programming protocol, right? |
| 09:37.26 | wpwrak | whatever works, as long as it works :) |
| 09:47.55 | cladamw | wpwrak, http://dpaste.com/752070/ |
| 09:49.31 | cladamw | when I searched 'package drawing' and 'land pattern' for Analog Device, Wolfson, Maxim, SiLabs about QFP48, i got some info so that I recorded INFO there. |
| 09:50.09 | wpwrak | you should also mention the conclusion. e.g., if they agree |
| 09:51.10 | wpwrak | at the end of the day, a lot of those footprints correspond to some JEDEC standard. but there's a crazily large number of variants |
| 09:51.17 | cladamw | MAXIM has great completed lists about all package drawings and land patterns, AD has few but not completed. Micrel/Wolfson even has very poor on collecting land pattern. |
| 09:51.48 | wpwrak | wolfson also have some rather crazy variants ;-) |
| 09:54.43 | wpwrak | e.g., page 13 of http://www.wolfsonmicro.com/documents/uploads/misc/en/WAN0118.pdf |
| 09:55.22 | cladamw | to finish m1r4's total three QFP48 parts(WM9707, KS8001, ADV7125), i did almost 99.5% done roughly but i merged your qfp.fpd --> |
| 09:55.24 | cladamw | http://downloads.qi-hardware.com/people/adam/m1/tmp/kicad/qfp.fpd |
| 09:58.53 | cladamw | i now very feel uncomfortable to wolfson, even AD, i very like Maxim's data base. so we could change a little dimensions based on datasheet's package drawings, if chip vendor has less info on land pattern, then i recommend to refer to Maxim, then to meet footprint reasonably. |
| 09:59.56 | cladamw | i found our m1r4's WM9707 and KS8001 both has the same package drawing.(almost :-) ) |
| 10:00.08 | wpwrak | maxim's pas length seems to be a bit excessively long, while ad's seems a bit on the sort side. (maxim+AD)/2 would seem about right ;-)) |
| 10:00.23 | wpwrak | s/sort/short |
| 10:00.23 | qi-bot | wpwrak meant: "maxim's pas length seems to be a bit excessively long, while ad's seems a bit on the short side. (maxim+AD)/2 would seem about right ;-))" |
| 10:00.54 | wpwrak | s/ pas / pad |
| 10:00.55 | qi-bot | wpwrak meant: "maxim's pad length seems to be a bit excessively long, while ad's seems a bit on the short side. (maxim+AD)/2 would seem about right ;-))" |
| 10:01.29 | cladamw | yeah ... |
| 10:03.09 | cladamw | wpwrak, my qfp.fpd includes your SiLabs C8051F32x, but named "QFP$pins-$variant", do you think this naming is okay to you ? |
| 10:03.32 | wpwrak | the maxim is in truth a JEDEC MS-026 BBA or BBC |
| 10:05.09 | cladamw | BBA for 32pins, BBC for 48pins. |
| 10:05.51 | cladamw | yes, i think maxim did a great work on them(almost the whole package, else chip vendors may not) |
| 10:05.57 | wpwrak | yes, sounds good. without a proper reference, i'd consider the silabs thing a pseudo-vendor standard anyway |
| 10:06.43 | wpwrak | BBA/BBC ah, right. maybe we can even get rid of the silabs critter then ... but lemme first check the 48 pin packages |
| 10:07.43 | wpwrak | i find NXP very good. they have a weird naming scheme (they have a "SOT-xxxx" code for each package, which is not the same as what the rest of the world calls "SOT", but they adhere quite strictly to standards) |
| 10:08.13 | cladamw | if i didn't use your this Fped to edit correct land pattern, i'll never known how else famous chip vendors they are poor in such info collection referred to JEDEC or IPC. :-) |
| 10:08.50 | wpwrak | (NXP) even better, they often specify reflow and wave soldering footprints. than often explains apparently crazy variations in other vendor's footprints - they may use some ancient wave soldering footprint |
| 10:09.06 | wpwrak | ;-))) |
| 10:09.31 | cladamw | aha ... NXP, I've not digged into it now. since I started to build module one-by-one from wiki m1r4 bom. so maybe later I'll definitely run into NXP. :-) |
| 10:10.32 | wpwrak | NXP also have some helpful background information. e.g., i found their design rules for QFN quite helpful, which include the solder paste islands and such |
| 10:10.42 | cladamw | so if you don't mind, I'll commit my qfp.fpd, but you may need to update your project used qfp.fpd. |
| 10:11.26 | wpwrak | alright |
| 10:11.28 | *** join/#qi-hardware methril (~methril@89.100.193.130) |
| 10:11.29 | cladamw | mmm .... a more solder paste info is useful, nice news. I'll see it. |
| 10:12.52 | cladamw | man~ hehe ... i found i spent 2 days to work on this (qfp) but seems worthy and also learnt a lot that how your table v.s. vector works. :-) |
| 10:13.11 | wpwrak | QFP48 of maxim and AD have an identical package, only maxim have +/- 0.1 mm while AD have +/- 0.2 mm for D/E/D1/E1. L is the same. |
| 10:13.35 | wpwrak | so we should have only one footprint for maxim and AD |
| 10:14.11 | wpwrak | that is, there should be an MS-026-BBC footprint that applies to both |
| 10:14.25 | cladamw | AD's (ST-48) land pattern is horrible, must be no one their internal to double confirm. |
| 10:14.54 | wpwrak | my it was an "intern" who made it ;-) |
| 10:14.58 | wpwrak | s/my/maybe/ |
| 10:14.59 | qi-bot | wpwrak meant: "maybe it was an "intern" who made it ;-)" |
| 10:19.36 | wpwrak | yeah, the AD pattern looks like trouble. at least the chip would just fit if you have the minimum values for D/E ;-) |
| 10:20.11 | qi-bot | [commit] Adam Wang: qfp.fpd: added Maxim C48 and Analog Device ST-48 variant (master) http://qi-hw.com/p/kicad-libs/bd5c1c3 |
| 10:20.12 | qi-bot | [commit] Adam Wang: Merge branch 'master' of projects.qi-hardware.com:kicad-libs (master) http://qi-hw.com/p/kicad-libs/61fecbd |
| 10:21.02 | wpwrak | i'd get rid of the AD pattern. there's no point in keeping that footprint if it's obviously wrong |
| 10:21.06 | cladamw | wpwrak, i think later we fix AD variant, meanwhile I'll go for another, if you see any err, let me know. |
| 10:21.23 | cladamw | aha ... okay |
| 10:21.27 | cladamw | wait ... |
| 10:23.10 | wpwrak | i would just rename the Maxim_C48 to something like MS025BBC. or maybe just call it "QFP48" or "LQFP48" without variant, since this seems to be the "standard" size anyway |
| 10:23.32 | wpwrak | you can then put references to suitable chips / vendor packages and footprints in INFO |
| 10:24.38 | wolfspraul | I printed out a set of m1 schematics on paper for medidation |
| 10:24.55 | wpwrak | hehe :) |
| 10:25.19 | wpwrak | paper is great for reviewing. you see a log more than on the screen |
| 10:25.36 | wolfspraul | will put it under my pillow |
| 10:25.39 | wolfspraul | see whether that helps :-) |
| 10:25.49 | wolfspraul | but anyway, first thing that struck me again is lack of page numbers |
| 10:25.53 | wolfspraul | so I had to number them by hand |
| 10:25.54 | wpwrak | interesting approach for information acquisition :) |
| 10:26.14 | wolfspraul | the font is a little on the small side, but just readable |
| 10:26.20 | wolfspraul | unlike say the m1-gps-extension :-) |
| 10:26.21 | wpwrak | yeah, we should label the pages. maybe not with numbers but with short names |
| 10:26.35 | wolfspraul | but a bit bigger would be nice |
| 10:26.50 | wpwrak | (readable) that's A3 sheets for you :) |
| 10:26.51 | wolfspraul | but overall it's really nice already, given that many schematics don't print at all or with all sorts of issues |
| 10:27.01 | wolfspraul | nah it fits nicely on A4, all fine |
| 10:27.05 | wolfspraul | and there is space for the font to be bigger |
| 10:27.25 | wolfspraul | but the #1 issue is lack of page numbers, lack of license or any form of attribution |
| 10:27.48 | wpwrak | hmm. if you auto-scale the fonts, a lot of things will start to look weird |
| 10:28.20 | wpwrak | the fonts have some readability issues, though. they could look better at exactly the same size |
| 10:28.48 | wolfspraul | #1 issue is page numbers, license, attribution |
| 10:28.56 | wolfspraul | should we just write something manually on each page? |
| 10:29.36 | wpwrak | perhaps some bold individual could write a converter that takes each text field, calculates the exact size with the original font, then places a PS font scaled to just that size (aspect rate not necessarily 1:1) instead |
| 10:29.36 | wolfspraul | I also printed out the (quite simple) atben page, that one looks even better, I guess the fonts come out a bit bigger |
| 10:29.58 | wolfspraul | but the atben one is also missing any form of license, copyright or attribution |
| 10:30.03 | wpwrak | i use A4 sheets, so the font has the "natural" size |
| 10:30.05 | wolfspraul | that's sad |
| 10:30.09 | wolfspraul | the creators should be honored :-) |
| 10:31.32 | wpwrak | the author is in the little text box in the corner, if you have that one (schhist suppresses it to avoid cluttering things even more than they already are) |
| 10:31.41 | wolfspraul | yes, I know |
| 10:31.48 | wolfspraul | but that box is ugly and overloaded and we disable it for a reason in schhist |
| 10:32.00 | wolfspraul | but maybe we should write *something* manually instead? |
| 10:32.00 | wpwrak | yeah :) |
| 10:32.12 | wolfspraul | otherwise it's just totally blank, which is also not right |
| 10:32.35 | wpwrak | dunno. perhaps in the case of M1, since it has a big overview sheet already |
| 10:32.36 | wolfspraul | I wouldn't mind if schhist picked up a textual change, that would also be the case already now for notes |
| 10:32.44 | wolfspraul | overview yes, but again |
| 10:32.46 | wpwrak | for smaller projects, it would just add more clutter |
| 10:32.53 | wolfspraul | absolutely nothing about license, creators, copyright, attribution |
| 10:33.04 | wolfspraul | it's like something that fell from the sky |
| 10:33.11 | wolfspraul | one question about atben |
| 10:33.22 | wolfspraul | the RFP and RFN wires are swapped |
| 10:33.30 | wpwrak | the default is "no rights, no copying" so you have to look in the project (which you'll have to do if you're going to do anything interesting with the schematics anyway) |
| 10:33.49 | wolfspraul | is there a technical reason for that, or just a random effect of the drawing? |
| 10:34.32 | wolfspraul | maybe turning B1 upside down would be even uglier? don't know |
| 10:35.17 | wolfspraul | maybe you could just turn the right side of B1 upside down? |
| 10:35.26 | wolfspraul | those pin numbers don't look like on the device anyway |
| 10:35.26 | wpwrak | i did it this way to help with the layout |
| 10:35.39 | wolfspraul | layout? |
| 10:36.53 | wpwrak | the crossing. but yes, i could have flipped B1 and then uncrossed RFP/RFN |
| 10:37.19 | wolfspraul | what does the /RF in C1/C2 stand for? |
| 10:37.32 | wolfspraul | I mean what parameters are we watching for in those caps? |
| 10:38.05 | qi-bot | [commit] Adam Wang: qfp.fpd: get rid of the AD land patter and rename variant to name (master) http://qi-hw.com/p/kicad-libs/d4be1a4 |
| 10:38.10 | wpwrak | my schematics have the balun drawn like in atmel's reference design. (but atmel don't cross RFP/RFN) |
| 10:38.28 | wolfspraul | the R1 is 0R, and C12 is NC - is this left purely for tweaking & playing reasons? |
| 10:38.51 | wpwrak | C1/C2 good question ;-) the parameters we're "watching" for are somewhere three to four orders of magnitude beyond the parameters whet component makers actually specify |
| 10:38.52 | wolfspraul | on the RF path, I think at least I would feel better if there would be a note like "can safely be removed" if that is so |
| 10:39.00 | wpwrak | s/whet/the |
| 10:39.02 | qi-bot | wpwrak meant: "C1/C2 good question ;-) the parameters we're "watching" for are somewhere three to four orders of magnitude beyond the parameters the component makers actually specify" |
| 10:39.10 | wolfspraul | otherwise one might thing that whatever effect is meant to be achieved with those 0R or even the NC pads :-) |
| 10:39.17 | wolfspraul | might think |
| 10:39.51 | wpwrak | having a place for inductors and caps at the antenna side is a common arrangement for matching |
| 10:40.13 | wpwrak | and yes, if you make your own derivative design, you're free to omit them :) |
| 10:40.30 | wolfspraul | during design maybe, ok. but I think a note "can be removed" would clarify things, no? |
| 10:40.33 | wolfspraul | since this is on the RF path |
| 10:40.53 | wpwrak | there are always implementation details like this that creep into schematics. schematics aren't expositions of pure theory :) |
| 10:40.56 | wolfspraul | otherwise I can lookup 20 effects at least that one 'might' want to achieve with a 0R resistor, or the empty pads |
| 10:40.57 | qi-bot | [commit] Adam Wang: INFO: removed AD QFP info (master) http://qi-hw.com/p/kicad-libs/6c2655c |
| 10:41.15 | wolfspraul | my question is: should we add a note "can be removed"? |
| 10:41.29 | wpwrak | naw, i think it's just a question of recognizing that pattern. it's common in RF design |
| 10:41.35 | wolfspraul | I think that may be helpful, if that is what was last in the designers mind about R1 and C12 |
| 10:42.04 | wolfspraul | sure |
| 10:42.09 | wolfspraul | I think you don't understand my point :-) |
| 10:42.14 | wpwrak | you'll even find some that have something like four caps and such there. atben is very light on obscure RF critters :) |
| 10:42.25 | wolfspraul | not 'obscure' |
| 10:42.37 | wolfspraul | you design it, you have some state of your thinking about the design |
| 10:42.42 | wolfspraul | that is either conveyed through the schematics or not |
| 10:42.56 | wolfspraul | it seems that right now you are not aware of any effect of R1 or (the NC) C12 |
| 10:42.57 | wpwrak | yes, but that's basic RF design knowledge |
| 10:43.31 | wpwrak | if you don't know what these parts are not essential, then you probably shouldn't remove them anyway, because your circuit may need tuning ;-) |
| 10:43.33 | wolfspraul | alrigh then, I tried :-) |
| 10:44.40 | wolfspraul | so the /RF then? |
| 10:44.44 | wolfspraul | it stands for? |
| 10:45.07 | wpwrak | i know their effect (in general terms). it's for adding small inductances or small capacitances to adjust the properties of that signal path. there are incidental parameters we don't know. so if one goes off the scale, we may need too tweak things |
| 10:45.34 | wolfspraul | sure but your design is stable and works |
| 10:45.40 | wpwrak | the /RF means that the caps are specifically designated for RF applications |
| 10:45.56 | wpwrak | unfortunately, that's about as good as it gets, in terms of specifics |
| 10:46.05 | wolfspraul | you could put even more matching networks there and leave them all empty, but what would be the point? |
| 10:46.55 | wolfspraul | by leaving R1 and C12 there you want to remind people that the matching is not done properly? |
| 10:46.58 | wolfspraul | :-) |
| 10:47.05 | *** join/#qi-hardware Ayla (~paul@77.189.124.78.rev.sfr.net) |
| 10:47.24 | wpwrak | sure. i have a basic matching network there. if you have other means to accomplish the same or if you're certain you don't need one, then drop it by all means |
| 10:47.34 | wolfspraul | how do you source the caps then, with /RF in digikey? |
| 10:47.47 | wolfspraul | yes [matching] |
| 10:47.55 | wolfspraul | but it seems that R1 and C12 are not needed |
| 10:48.03 | wolfspraul | so leaving them there may add confusion |
| 10:48.24 | wolfspraul | someone with enough RF experience will easily know how and where to add matching networks anyway |
| 10:48.36 | wolfspraul | but leaving those seemingly unneeded R1 and C12 there conveys a strange message, at least to me |
| 10:48.54 | wpwrak | R1 and C12 remind people that RF is tricky. e.g., if you add some case, you may find that the device is detuned. then you need to make adjustments. |
| 10:49.02 | wolfspraul | he |
| 10:49.22 | wolfspraul | that I fully understand |
| 10:49.25 | wpwrak | of course, if you're able to make meaningful adjustments, it's rather likely that you understand what R1 and C12 mean :) |
| 10:49.36 | wolfspraul | but trying to get that across by leaving two unused parts there is strange :-) |
| 10:49.47 | wolfspraul | well that's the thing, they mean nothing |
| 10:49.48 | wolfspraul | I guess |
| 10:49.49 | wpwrak | it's pretty much standard practice |
| 10:49.51 | wolfspraul | from your answer |
| 10:50.10 | wolfspraul | standard practice is to leave one empty resistor and one empty/nc cap as a reminder for a matching network? |
| 10:50.22 | wolfspraul | I will pay attention to that |
| 10:50.50 | wpwrak | they're not only reminders. they have real-life footprints. |
| 10:51.22 | wpwrak | i need these components in the schematics for kicad to know what to do with the footprints. |
| 10:51.43 | wolfspraul | you think someone may want to put a part there if they add a case? |
| 10:52.00 | wolfspraul | and that's standard on an RF path to leave some slots for matching parts? |
| 10:52.09 | wolfspraul | doesn't sound very credible to me, but I will keep an eye on it |
| 10:53.01 | wolfspraul | you wouldn't be able to predict what parts are needed, and in fact the empty pads themselves may be the source of uncertainties |
| 10:53.15 | wpwrak | (case) yes, or if they want to optimize the circuit further. e.g., there may be RF leakage issues i'm not aware of. my lab isn't set up to do full FCC compliance testing. |
| 10:53.24 | wolfspraul | sure |
| 10:53.27 | wolfspraul | that I understand |
| 10:53.32 | wpwrak | hmm, i had typed "complicance". thank you, Freud :) |
| 10:53.52 | wolfspraul | but you cannot predict whether that one resistor and one cap is what you will need |
| 10:54.06 | wolfspraul | it looks a little helpless, unless this is really a common way to do it that I'm not aware of |
| 10:54.16 | wolfspraul | but I'm learning, and now I will pay attention to this |
| 10:54.22 | wpwrak | and yes, leaving slots is common, particularly in designs that may experience environmental variations or experiments |
| 10:54.37 | cladamw | wpwrak, do you have SOIC module ? i saw SSOP but seems no SOIC. if you have it, point me the link. tks. :-) |
| 10:54.53 | wolfspraul | back to the /RF cap - so how do you source it then? |
| 10:55.11 | wolfspraul | I should look into the sources, sorry haven't done that yet |
| 10:55.17 | wpwrak | if you need a more complex matching network, you'll need a redesign anyway. but L and C (the R is really a placeholder for an L) are your starting point |
| 10:55.19 | wolfspraul | just noticed the /RF and didn't know what it means |
| 10:55.29 | wolfspraul | yes, I know |
| 10:55.37 | wolfspraul | it seems half-baked to me |
| 10:56.11 | wpwrak | the /RF selects a part that has the X=RF field set. "X" is a field for "additional characteristics". so when building my characteristics database, i set that field for caps from an "RF" series |
| 10:56.32 | wolfspraul | hmm |
| 10:56.36 | wolfspraul | I see |
| 10:56.39 | wolfspraul | just from that series |
| 10:56.45 | wolfspraul | without going into the specifics of the parameters |
| 10:56.58 | *** join/#qi-hardware jivs (~jivs@nat-sta-slph1.tvu.ac.uk) |
| 10:57.04 | wpwrak | the quantitative parameters don't really help |
| 10:57.26 | wpwrak | they tell you how the part behaves at, say, 1 MHz. we're running it at 2.4 GHz. |
| 10:58.20 | wpwrak | but the vendor stating that it's for HF, microwave, RF, whatever, tells you that you're less likely to experience nasty surprises with that part than with one that's not rated for such uses |
| 10:58.38 | wpwrak | nasty surprises may including one batch working just fine and the next not |
| 10:58.57 | wpwrak | and yes, it looks very half-baked to me too :) |
| 10:59.02 | cladamw | wpwrak, if no SOIC module, i'll build it same likely SSOP. :-) |
| 10:59.31 | wpwrak | cladamw: (SOIC) lemme see if i have any of those fat pigs somewhere ... |
| 11:00.55 | wpwrak | nope, don't think so |
| 11:01.58 | cladamw | wpwrak, yeah ... i didn't find it after searching wernermisc and ben-wpan. tks. :-) |
| 11:12.13 | wpwrak | wolfspraul: (RF caps) here's a typical collection of such critters: http://www.johansontechnology.com/images/stories/catalog/JTI_CAT_2012_MLCC_HighQ.pdf |
| 11:12.51 | wpwrak | note the "DIELECTRIC" table on page 1. "ultra high Q", "high Q", ... |
| 11:14.07 | wpwrak | and then you go to page 10, to learn that all NP0 have Q >1,000 @ 1 MHz, Typical 10,000 |
| 11:15.56 | wpwrak | and that's all you get. you just have to trust them that they'll also behave in multi-GHz circuits :) |
| 11:22.31 | *** join/#qi-hardware rejon (~rejon@114.244.46.101) |
| 11:33.13 | wpwrak | some other descriptions read "ultra-high Q", "mid-high Q", and "excellent high Q". some engineering poetry, i guess :) |
| 11:38.00 | *** join/#qi-hardware rejon (~rejon@114.244.46.101) |
| 11:49.42 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 11:51.02 | wpwrak | interesting .. the silabs LQFP32 is 0.1 mm smaller than the maxim (JEDEC 95 MS-026 BBA) part |
| 11:51.49 | *** join/#qi-hardware rejon (~rejon@114.244.46.101) |
| 11:52.43 | wpwrak | yet silabs claim their is MS-026 BBA, too :) |
| 11:52.49 | wpwrak | s/their/theirs |
| 11:52.50 | qi-bot | wpwrak meant: "yet silabs claim theirs is MS-026 BBA, too :)" |
| 11:53.57 | wpwrak | ah, no. they're the same. confused the column of typical with maximal sizes. |
| 12:12.05 | wpwrak | heh. we could express all this in terms of the IPC-7351 formulas :) |
| 12:34.40 | *** join/#qi-hardware rejon (~rejon@li408-40.members.linode.com) |
| 12:42.10 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 13:10.42 | kristianpaul | they are tiny but i still can read on my screen |
| 13:11.11 | kristianpaul | btw i'll add license, already agreed one with Artyom, but just a license.txt file or also add in the sheet? |
| 13:15.09 | wolfspraul | start with license.txt that's great |
| 13:15.17 | wolfspraul | look how long it took you to even find out what it is :-) |
| 13:16.13 | kristianpaul | you like i separate the "blocks" in sheets? |
| 13:16.31 | kristianpaul | anyway after the cutoff just the half will remain.. |
| 13:18.23 | *** join/#qi-hardware erikkugel (~ekugel@216.183.91.254) |
| 13:18.42 | kristianpaul | wolfspraul: the license you mean? |
| 13:18.50 | kristianpaul | or the font? |
| 13:20.14 | kristianpaul | erghh i cant search in those pdf.. |
| 13:21.34 | wolfspraul | license |
| 13:21.47 | wolfspraul | obviously knowing the license is by far more important than size of font, no? :-) |
| 13:22.05 | wolfspraul | so one by one. seems the license and copyright info for m1-gps-extension is clear now? great! |
| 13:22.35 | kristianpaul | yes, share a like by license is |
| 13:22.39 | wolfspraul | what I was talking about in the m1 and ben-wpan was at another level, because as wpwrak already said the license and copyright is clear there, just the pdf is a little unspecific on those things |
| 13:22.55 | kristianpaul | i se |
| 13:22.57 | kristianpaul | e |
| 13:30.27 | kristianpaul | better write license as a schematic component, so that way is kept |
| 13:37.16 | *** join/#qi-hardware kristoffer (~kristoffe@c-c1d8e555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 14:02.53 | *** join/#qi-hardware antgreen (user@nat/redhat/x-aatrjtadkcasbrvk) |
| 14:05.08 | *** join/#qi-hardware paroneayea (~user@fsf/member/paroneayea) |
| 14:07.49 | *** join/#qi-hardware jivs (~jivs@nat-sta-slph1.tvu.ac.uk) |
| 14:20.14 | *** join/#qi-hardware Ayla (~paul@197.94.102.84.rev.sfr.net) |
| 14:23.46 | wpwrak | (license as component) that's an interesting idea :) lemme see if you can actually make it such that it doesn't end up on the BOM by default |
| 14:26.45 | *** join/#qi-hardware urandom__ (~user@p548A35F8.dip.t-dialin.net) |
| 14:28.27 | *** join/#qi-hardware jekhor (~jek@178.121.49.24) |
| 14:28.47 | wpwrak | yeah. make its component reference start with # and set the field (reference) to invisible. that should do the trick. |
| 14:50.44 | *** join/#qi-hardware jekhor (~jek@178.121.49.24) |
| 15:25.21 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 15:25.43 | *** join/#qi-hardware jurting (~jommpa90_@host-95-193-44-61.mobileonline.telia.com) |
| 16:13.07 | *** join/#qi-hardware jluis (~jluis@2001:c08:3700:ffff::665) |
| 16:13.28 | qi-bot | [commit] Jiva Nath Bagale: fixed guile2 Makefile to use guile from toolchain instead of host machine (master) http://qi-hw.com/p/openwrt-packages/e88e68e |
| 16:29.33 | kristianpaul | kyak: adc from launchpad plus a nice plotting app in the nanonote (i guess we already have) |
| 16:30.02 | kristianpaul | msp430 have adc/dac i read somwhere.. |
| 16:30.39 | kristianpaul | kyak: looks interesting idea for uses in the field.. |
| 16:30.47 | kristianpaul | s/field/wild? |
| 16:30.48 | qi-bot | kristianpaul meant: "kyak: looks interesting idea for uses in the wild?.." |
| 16:42.15 | kyak | kristianpaul: there already a python+gnuplot plotting script here: http://losinggeneration.homelinux.org/2010/07/02/msp430-launchpad-on-linux/. Both python and gnuplot are available on Ben, so it should work :) |
| 16:42.54 | kristianpaul | nice |
| 16:43.11 | kyak | it seems that the USB connection is not very reliable.. You have to replug every time, as mentioned here: http://dbindner.freeshell.org/msp430/index.html#Talking_to_MSP430 |
| 16:43.47 | kyak | also mspdebug only work via USB as i understand |
| 16:43.51 | losinggeneration | kyak: I can vouch for it being less than reliable :) |
| 16:44.16 | kristianpaul | it tought over uart as well.. shame |
| 16:44.29 | kyak | so probably there is a need for another software programmer, as werner mentioned |
| 16:45.56 | kyak | losinggeneration: do you have an idea what might be the problem? |
| 16:47.55 | losinggeneration | off the top of my head: no. It's actually been quite some time since I've last picked up the launchpad, so I can't recall the exact issue besides it not working well without unplugging it and plugging it back in |
| 16:49.11 | kyak | it will lead to loose usb connector and unusable board at the end |
| 16:49.18 | losinggeneration | IIRC it was acting as if the connection to the device was blocked |
| 16:51.35 | kristianpaul | pehaps is because uart is emulated in software? |
| 16:51.43 | kristianpaul | perhaps* |
| 16:52.13 | kristianpaul | first time i pluged the thing, my ubuntu freezed for about 10 seconds :-| |
| 16:52.57 | kristianpaul | perhaps is a cdc running in other TI MCU.? |
| 16:56.12 | qi-bot | [commit] Werner Almesberger: bacon/prog/: simple PIC 18F{2,4}xJxx programmer (for the Ben Nanonote) (master) http://qi-hw.com/p/wernermisc/6bdfea6 |
| 16:56.54 | kristianpaul | ah no |
| 16:56.59 | wpwrak | kyak: this may be useful as an example: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/bacon/prog/ |
| 16:57.10 | kristianpaul | it have its own Serial-to-USB chip |
| 17:04.15 | *** join/#qi-hardware qwebirc12081 (4766dbad@gateway/web/freenode/ip.71.102.219.173) |
| 17:05.46 | rjeffries | This program sounds interesting. Will it work on a Ben NN? http://www.kiwix.org/index.php/Main_Page |
| 17:08.47 | kristianpaul | there was a reader for kiwix on the ben |
| 17:08.55 | kristianpaul | actually need some loving.. |
| 17:09.50 | kristianpaul | but keep in mind the interesting and long process involve get those mediawifi offline files, they even require a server farm :) |
| 17:10.18 | kristianpaul | in the other side there is humane project, who developed what seems an easy/fast alternative |
| 17:10.29 | kristianpaul | zrafa from #jlime ported it |
| 17:10.48 | kristianpaul | to nanonote's muffiman, i think is on qi wiki if you wanna try |
| 17:12.02 | rjeffries | kristianpaul agree extraction the conent is a lot of work. but once done (maybe every 3 months or so) the value of access to wikipedia offline seems Most Excellent. OTOH the other offshoot of OM offers a purpose built off-like reader, and seems to not be thriving |
| 17:12.29 | kristianpaul | s/qi/jlime |
| 17:12.30 | qi-bot | kristianpaul meant: "to nanonote's muffiman, i think is on jlime wiki if you wanna try" |
| 17:13.00 | rjeffries | I guess this is not all that interesting. fair enough. |
| 17:13.31 | kristianpaul | rjeffries: no work, is already there, well not using zim files but it is |
| 17:13.33 | kristianpaul | check jlime.com |
| 17:14.59 | *** part/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 17:17.00 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 17:17.33 | *** join/#qi-hardware Guest12542 (~hzhang@2001:c08:3700:ffff::567) |
| 17:28.49 | kyak | wpwrak: thanks for sharing! |
| 17:37.28 | rjeffries | kristianpaul as you prolly know, I do not own a Ben. But thanks. I don't need an offline reader for myself, but it seems like a cool idea maybe for kids? |
| 17:40.50 | kristianpaul | yes i'm aware ;-) |
| 17:47.15 | *** join/#qi-hardware jekhor (~jek@86.57.254.166) |
| 18:02.50 | *** join/#qi-hardware phirsch_ (~smuxi@xdsl-89-0-65-57.netcologne.de) |
| 18:36.45 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host171-91-dynamic.54-79-r.retail.telecomitalia.it) |
| 18:50.51 | *** join/#qi-hardware methril (~methril@89.100.193.130) |
| 19:26.31 | viric | mth: what do you do with zram in the dingoo? Allocate 32MB of swap? |
| 19:30.03 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 19:52.22 | *** join/#qi-hardware Jay7 (jay@89.179.25.173) |
| 20:15.51 | *** join/#qi-hardware methril (~methril@89.100.193.130) |
| 20:30.23 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 20:32.51 | *** part/#qi-hardware erikkugel (~ekugel@216.183.91.254) |
| 21:24.30 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 21:25.44 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host171-91-dynamic.54-79-r.retail.telecomitalia.it) |
| 21:32.07 | *** join/#qi-hardware urandom__ (~user@p548A3C1D.dip.t-dialin.net) |
| 21:42.31 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 21:56.33 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-135.ozonline.com.au) |
| 22:05.51 | qi-bot | The build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.full_system-20120524-1615 |
| 22:18.40 | mth | viric: less than 32 MB, but we do use it as swap |
| 22:19.14 | viric | the dingoo also has 32MB of ram? |
| 22:19.38 | mth | yes |
| 22:19.54 | mth | we create a 20MB swap by default |
| 22:20.21 | viric | how much ram that takes? |
| 22:21.45 | mth | worst case 20MB of course, I don't know average case |
| 22:22.00 | mth | a lot of software doesn't swap at all |
| 22:22.15 | mth | Ayla was the one who introduced zram, maybe he knows more |
| 22:23.18 | viric | ok |
| 22:23.36 | viric | I remember I couldn't run 'g++' to build a simple program :) |
| 22:23.44 | viric | and I had to add some swap |
| 22:23.56 | viric | well, it was swapping with the read only pages of the images |
| 22:24.06 | viric | but I did not have any 'paging' for writeable pages |
| 22:43.26 | *** join/#qi-hardware methril (~methril@89.100.193.130) |
| 23:09.12 | *** join/#qi-hardware methril (~methril@89.100.193.130) |
| 23:32.38 | qi-bot | [commit] Werner Almesberger: change use of curly braces with "if-else" to kernel style (master) http://qi-hw.com/p/fped/424b74e |
| 23:32.39 | qi-bot | [commit] Werner Almesberger: inst.h (FOR_PKG_INSTS): protect against active_pkg == NULL (master) http://qi-hw.com/p/fped/b06ed92 |
| 23:32.40 | qi-bot | [commit] Werner Almesberger: make active package track active variables (for the GUI) (master) http://qi-hw.com/p/fped/e0351bd |
| 23:47.45 | *** join/#qi-hardware crosswalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 23:48.33 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 23:49.03 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |