Topic for #qi-hardware is now 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
<wolfspraul>
Martix: good morning :-) you still there?
<Martix>
wolfspraul: yep
cladamw has joined #qi-hardware
<wolfspraul>
kristianpaul: you probably saw that rtlsdr has made some more rounds, on slashdot, reddit, etc
<wolfspraul>
Martix: oh, hi, didn't see :-)
<kristianpaul>
wolfspraul: yup
<wolfspraul>
and people have trouble finding a good source :-)
<kristianpaul>
;-)
<wolfspraul>
since I bought from the factory, I am sure I can get the right thing, and they are definitely not 'out of stock'
<wolfspraul>
and won't be, no matter how many sales come in
<kristianpaul>
oh wow
<kristianpaul>
are you interesting in re-sell? ;)
<wolfspraul>
well of course. the factories produce as much and as long as there are orders.
<wolfspraul>
oh no, definitely not
<wolfspraul>
it's already there, just some layers of mostly language confusion
<wolfspraul>
some reseller will pop up
<kristianpaul>
sure, just confirming
<wolfspraul>
plus in no time, an even better option may appear
<wolfspraul>
hopefully people will really buy and start diving into sdr land, to learn about the details that really matter
<wolfspraul>
I focus on milkymist, I know we are on a good path there. no time for rtlsdr right now.
<kristianpaul>
i bet for it,afaik for that price lets hope is not a just a sold-out season
<wolfspraul>
no
<wolfspraul>
btw the reference design comes from Elonics, not Realtek
<kristianpaul>
for the whole package?
<wolfspraul>
all under NDA, industry-typical... Elonics is a UK company
<kristianpaul>
oh sure
<wolfspraul>
sure, the real work is typically just done in one place :-)
<wolfspraul>
so Elonics makes the reference design, one Chinese company buys it or gets it for free under NDA, then lots of other Chinese companies get access to the files in one way or another
<kristianpaul>
diving into sdr land, yup that should be the path
<wolfspraul>
the only people who don't have the reference design are law-abiding foss citizens :-)
rejon has joined #qi-hardware
<kristianpaul>
:-| ...
<wolfspraul>
I don't have it either and will not try to hunt it down, or sign the NDA. just fyi.
<wolfspraul>
and neither embark in a reversing process, again too much time and milkymist/qi focus
<kristianpaul>
i'm aware of people claiming already signing it..
<kristianpaul>
oh no, reverse no sense now
<wolfspraul>
there are not many secrets in the reference design anyway
<kristianpaul>
what matters is stack, i think osmocom have some sdr primitives already,
<wolfspraul>
just a lot of tweaking and tuning, which is the hard part and important if you want to make your own product
<kristianpaul>
thats when osmo-sdr came to life :)
<wolfspraul>
but seeing that the Elonics tuner is so closed, well, one day hopefully we can find more openly documented chips
<kristianpaul>
perhaps, indeed
<kristianpaul>
or at least more documented driver, wich is the value i see from osmo-sdr too
<kristianpaul>
s/wich/that
<qi-bot>
kristianpaul meant: "or at least more documented driver, that is the value i see from osmo-sdr too"
<wolfspraul>
Martix: I saw the CuBox on your conference program, is it interesting?
<Martix>
wolfspraul: it's alternative to Raspberry Pi and Beagle Bone, but speaker is still waiting when CuBox and Raspberry Pi arrive, but it should be week before conference
<wpwrak>
cladamw: i have some doubts about the scalability of the approach you've chosen for some of the schematics symbols
<wpwrak>
cladamw: there are those that refer to a unique component, e.g., the audio codec. there, it makes sense to have one specific symbol for that part
<wpwrak>
cladamw: but then there are those that are more or less generic. e.g., diodes. they may come in a number of different packages, but the number of pin variations is still quite small
<wpwrak>
cladamw: so there are a lot of parts that can all use the same symbol. and the symbol should have a generic name, not just a vendor part number
<cladamw>
currently I don't have common idea on using 'same' specific symbol for parts's usual goal. for the one of audio codec is the beginning one of this time first doing. which is worse idea of my latest using a vendor chip name to include them.
<wpwrak>
cladamw: now, i know that some people use a different approach and have basically one symbol per vendor part, with all the fields already set, and so on. but i'm very sceptical about the scalability of such an approach, since you'd have gazillions of duplicate symbols
<cladamw>
since there's few columns of 'properties' can fill up real p/n and description.
<wpwrak>
the audio codec is okay. it's probably the only part with that pinout anyway
<cladamw>
ha....i finally still using this idea is :
<cladamw>
1. when user try to edit schematic, which information he should look for ? actually the p/n is rather than a specific symbols.
<wpwrak>
the design should start with generic concepts. e.g., a p-FET instead of a specific diodes inc. part
<cladamw>
2. if we spend much time to find a 'specific' common smybol to corresponding to all same like AND /XOR gate then he doesn't need to find libraries/database to find 'good' AND gate symbol for his goal.
stratman2 has joined #qi-hardware
<cladamw>
3. your specific unique 'symbol' is good /convience to passive parts or non -active parts., for ic chips, you are hard to let people know which on is which one.
<wpwrak>
a universal AND gate wouldn't be possible with how kicad works, because each symbol needs to define all pins of the component. would be nice, though ;)
<cladamw>
4. for audio chip , i'm thinking even using wolfson.lib instead the p/n.lib
<wpwrak>
oh, sure. for complex chips, MCUs, codecs, FPGAs, and so on, you definitely want a specific part
<cladamw>
for examples now.
<wpwrak>
but there are more generic ones, e.g., diodes, diode arrays, transitors (BJT, FET, etc.), transistor arrays, gates, groups of gates, etc., where you have many packages with equivalent topology and also several vendors
<cladamw>
you collected many '74x1g***'.lib which user needs to scrolling and find what it looks like while placing parts or find it in Library Editor to see it.
<wpwrak>
and in many cases also different parameters. e.g., a 741G00 will look pretty much the same in HC, HCT, LV, ...
<cladamw>
but if we gave them a real p/n, yes, it will create a lot of database(symbols), but it's easy to get part in schematic editot. ;-)
<wpwrak>
and also a diode often doesn't look different in the schematics when it's 10 mA or 10 A :-)
<cladamw>
yes, i know, the real questions are we don't need to collect so much HC, HCT, LC, LVC now. :-)
<wpwrak>
yes, once you've found it among the millions of parts, then it's easy ;-)
<cladamw>
so you already collected much of them. :-)
<stratman2>
Has anybody got mac os/x to talk to Ben? USB port where Ben is connected to, is not being recognized on my PC when I load a CD boot of linux. The Mac sees the Ben, so I guess next step is to get CD boot of MAC os/x (don't want to install linux on the mac). Other thing to try is just bite the bullet and get another PC and install linux, but want to avoid that - I am trying to update Ben with latest version of linux..
<wpwrak>
sure. but we should pick a structure that will not require a full reset when the library grows
<cladamw>
when people edited parts, they may think if the part is COMMON, like HC, HCT, even etc...yes they are. :-)
<cladamw>
but for reset IC ? usb power switch ? do you think that all chip vendors they will share their own pins assignments to a "Unique" one, the answer is probably not. ;-)
<cladamw>
for now, I'm thinking to if adding spartan-6 into xilinx.lib?
<cladamw>
i don't have good idea now. since KiCad has included a same name library called "xilinx.lib" and there's one spartan-6 'XC6SLX25T-BG484' existed there already.
<wpwrak>
if you open Logic > Single >, then you have a number of 74x1g07_* parts. they differ by the number of pins.
<cladamw>
yeah....yes, I agreed on those very few older generation chip TTL, CMOS, etc for collecting ic symbols.
<cladamw>
i agreed your ideas on that, but you still can't deal with those usb power switches, reset ics, etc....
<wpwrak>
i think reset ICs are semi-generic. the question is if you have a specific symbol for them :)
<wpwrak>
usb power switches may be unique enough that it doens't make sense to try to generalize them
<cladamw>
for the audio codec, I think that I'll go back to create a wolfson.lib for WM9707...
<wpwrak>
(xilinx) i would not touch the kicad libs. we should get rid of them. they're full of inconsistencies anyway
<wpwrak>
(inconsistent font sizes and so on)
<cladamw>
KiCad does a real inconsistent symbols for spartan-6, it must not contributed by their community, since the best one is to follow current M1's 'bank' catagories to divide parts.
<wpwrak>
i'd rather have one library per symbol (more or less. sometimes that doesn't make sense, but it's usually possible)
<wpwrak>
(1 lib per sym) the reason is that it's easier to track revisions that way. and you have a lower risk of commit conflicts.
<cladamw>
yeah...so I just first created a name xc6slx45-2fgg484c.lib locally, not using a same name as 'xilinx.lib'
<cladamw>
(1 lib per sym) violates ( specific symbol per old TTL/CMOS. etc.)
<wpwrak>
does it ? how ?
<cladamw>
for our spartan-6 p/n, now it violates (symbols collected per vendor name)
<cladamw>
phew ~
<wpwrak>
look in kicad-libs/components/, there's 74x1g07_4.lib, 74x1g07_5.lib, ... :)
<wpwrak>
on lib per symbol. and three different symbols for the 74x1G07 family of gates (one for packages with 4 pins, one for 5, etc.)
<cladamw>
yes, you are with the same way to get roma to build a lot of symbols, a quite way same as mine to collect all p/n for one vendors.
<wpwrak>
i wish kicad would let us treat them as a generalized 74x1G07, but that may be a bit difficult. and it may be confusing
<wpwrak>
ah, but each of these applies to many vendor parts
<cladamw>
well. well...i won't touch your existing 74x***.... you can imagine that how we need to build own components.lib ?
<cladamw>
if I tried to find 'unique' symbol name into components for those parts in M1, then how much time i need to spend ?
<wpwrak>
i only need a new 74x1G07 when i find one that has a different pinout. e.g., in a package with a different number of pins or a different assignment of functions to pins. but further package details, the family, vendor part naming schemes, etc., don't affect the symbol
<wpwrak>
0.00001% of the time you'd spend later duplicating things indefinitely ? ;)
<cladamw>
we should have thought long term vs. short term way to go for it. I would say that specific / unique symbol is good but not suitable for every chip. :-)
<wpwrak>
agreed
<wpwrak>
it's mainly the simple things that have alternatives
<cladamw>
for example, when i met connector, i skipped and ignored to create new one.
<cladamw>
so i also agreed yours. ;-)
<wpwrak>
extreme example: resistors. you wouldn't want to have one symbol for each vendor part number. or would you ? :)
<cladamw>
sure.
<cladamw>
that's the same 'Relativity' both you and me created. :-)
<cladamw>
also for example, how big compatibilities that audio codecs can meet and drop to place with the same symbol or footprint together ? it's very few. so i created a real p/n for it.
<wpwrak>
things like reset chips are a bit borderline. there are lots of reset chips that all look very similar. but they may have different names for the same function, depending on the vendor
<cladamw>
but in the else fields, a SOT-23-3, it could be diode, led, reset ic, etc...they could be the same footprint but not same symbol name in each pin.
<wpwrak>
so for reset chips, i think either way is fine
<wpwrak>
yes, agreed with audio codecs. complex chips can't have a "generic" symbol
<wpwrak>
diode, led, transistor, etc., all have different circuit symbols
<cladamw>
so when we build footprint, the 'specific' or 'generic' will be much the same approach to this way.
<wpwrak>
let's not confuse circuit symbol and package
<wpwrak>
no, not at all. think of the resistors again :)
<cladamw>
yeah,,,so when i created these days , i was also confused myself a bit. but in the end i still created the same symbols as vendor chip's drawing. ;-)
rejon has joined #qi-hardware
<cladamw>
yeah... i think that we agreed on "not confuse" circuit symbol.
<cladamw>
i will always think a bit when creating a new symbol. Also find if KiCad has it already or not. ;-)
<wpwrak>
i think a good test is if you think what part you'd use for this function. if you first have to go to digi-key to find the most common one, then the symbol should probably be generic. e.g., DVI connectors may have very little variation
<wpwrak>
similar for USB. for USB < 3.0, the only thing that varies is the number of ground pads. so we should have one symbol for each ground configuration, and that's it. (if you look at the current library, it isn't structured like this yet for USB, because i didn't understand this pattern until recently)
<cladamw>
btw, do you know that why i didn't use your '74X1G08_6.lib' for M1's '74AUP1G08GW,125' ? since liked i said last week, i think that the best top view for chip pin name is to keep the same pin arrangement. ;-)
<wpwrak>
well, we can have two variants. sometimes, you want to put more emphasis on the function, sometimes more on the physical appearance
<cladamw>
i'd rather to try make a symbol now to keep visually same orientation/top viewing from now on. then when user debugging, don't need to open datasheet to find it. Just look it at schematic. :-)
<wpwrak>
you lose when it comes to big chips :)
<cladamw>
agreed. :-)
<wpwrak>
SoCs, FPGAs, ...
<cladamw>
agreed too.
<wpwrak>
(view) you could of course open the layout :)
<cladamw>
so when created SoCs etc, then we build them same as datasheet said. :)
<wpwrak>
for MCUs, i usually take the physical view. mainly because i assign functions according to where i expect things to go in the layout
<cladamw>
when build M1 symbols nowadays, i dislike them now. maybe the same feeling from you for mine. :-O
<wpwrak>
i haven't looked at the symbols yet :) so far, i'm only commenting on the general structure of the library
<cladamw>
M1's U2[ksz8001l] and U21[adv7181c] is good (same pin direction). :-)
<cladamw>
sure. the general structure i agreed. :-)
<cladamw>
M1's all others symbols[ bad and not easily to read] when debugging... as you know, for SoC, FPGA, the best to to seperate their functional pins as possible. :-)
<wpwrak>
this may be more a tool problem than a symbol design issue
<cladamw>
mmm... if there's one, it would be good.
<cladamw>
so i think when chips's total # is under 48 pins, or 64pins, the best rules for creating symbol is:
<cladamw>
1. to keep pins assignments as same as chip's outline layout top viewing.
<cladamw>
2. find a exiting already generic/specific frequent symbols, people know already, like TTL, COMS, etc...
<cladamw>
3. but 2) at best to follow 1) as possible. some how in current electronic symbol drawing violate rules we expect above. ;-)
<wpwrak>
i think it depends on what you want to show. also don't forget that symbols can be mirrored in the schematics. then it can't match the footprint even though it follows the physical layout.
<cladamw>
sure
<wpwrak>
btw, in kicad, you can launch eeschema and pcbnew on different screens. when you click on a pin in the schematics, the cursor in pcbnew will jump to it
<DocScrutinizer>
on component libs: it might be useful to just "steal" from standard libs but actually create a generic symbol for each part type in BOM and put all in one QI.lib
<DocScrutinizer>
this way you can have all the parameters of your component in the lib and use it as well for spice and whatnot
<DocScrutinizer>
and you have one pretty small lib to ship to user, instead of a plethora of vendor specific libs, plus your own tweaked versions of those when the original doesn't meet yout requirements
<DocScrutinizer>
creating BOM was a straightforward task then
<DocScrutinizer>
basically your lib with all the symbols *is* your BOM
<DocScrutinizer>
you could argue if you want to follow this approach even for plain vanilla 0402 resistors
<DocScrutinizer>
but then OTOH why not
<DocScrutinizer>
in the end it's just a copy from another (standard) lib to your QI.lib for each component you include to your schematic
<DocScrutinizer>
or a pick/edit/paste action, to add the particular component properties
<DocScrutinizer>
nothing terrible in doing that for 33R, 47R, nnnR. You have to do it *somewhere* anyway
<DocScrutinizer>
you could use 2 libs: an archive lib QI_we_had.lib plus a QI_we_recently_have.lib
<DocScrutinizer>
big advantage: all your components are of a uniform style. This usually isn't the case when you use vendor libs
<DocScrutinizer>
for the idea to match fotprints - it's a generally odd idea. You rather have symbols especially for huge components where you place all your pins in a way you get nice legible schematics. There's simply no use in somehow showing pinout in schematics
<DocScrutinizer>
e.g. when your MICP and MICN inputs of audio chip create a need to cross their lines in your schematic, then you simply swap them for that particular codec symbol so your lines don't cross anymore
cladamw has joined #qi-hardware
<DocScrutinizer>
so you usually would have a number of single named pins as entities for all chips with >16 pins, and you place those into arbitrary boxes in any way you like. For things like 7400 4 NAND gates, you'd have 4 entities of one gate for the component and you place each gate wherever you like
<DocScrutinizer>
(single pin entities) sometimes it makes sense to group pins even then, e.g. for buses
<DocScrutinizer>
as you definitely don't want "pinout" in schem like "d0 d3 d1 d2"
<DocScrutinizer>
same might go for interfaces like SPI, I2C etc
<DocScrutinizer>
if you could have "macro" components consisting of several layers of sub-components down to the individual pin, and you may group and ungroup at arbitrary levels of that hierarchy, that would be really nice
<DocScrutinizer>
even nicer though, if you can have alternative hierarchies (trees) on the same pins (as leaves) for the same component, and switch between them
Martix has joined #qi-hardware
<DocScrutinizer>
e.g some pins may have alternative primary function Addr17..32, secondary camera-IF
<DocScrutinizer>
you'd like to group these pins in two alternative predefined ways, so "user" can switch between the version of subtree he wants to use for that particular set of pins
<DocScrutinizer>
for simpler components like 7400 4*NAND you frequently find orphaned "spare" gates somewhere on a separate sheet or in a dark corner of schematic, when the EE used this approach. I always thought this is a very nice and clear way to document things
<DocScrutinizer>
and one more argument to do it this way: you definitely have best data to run design rule checks against your design
<DocScrutinizer>
no outputs of unused gates accidentally tied to GND or VDD, just because they were "forgotten" in schematics.
<DocScrutinizer>
ooh yes, and of course each 7400 also has a VDD and a GND pin entity. You usually place those next to the gates if all 4 gates are used on same sheet. You place them on a separate power sheet when there's no better place for them
<wpwrak>
DocScrutinizer: kicad lets you have multi-part symbols. it doesn't let you rearrange their pins, though.
<blogic>
morning
<DocScrutinizer>
hmm, also multi-multipart?
<wpwrak>
(vendor libs) you mean the default kicad lib ? there are problems with that one. so it's better if we replace it. it also has only very few parts, so it's not an insane amount of work
<wpwrak>
no, just one level. you're free to duplicate, though :)
<DocScrutinizer>
won't fly for my idea of implicit alternatives :-/
<DocScrutinizer>
and for rearranging pins/sub-parts - that's pretty bad restriction
<DocScrutinizer>
I don't get what you mean by vendor lib = kicad default lib
<wpwrak>
(one sym per part) i've heard of that approach. i think it's insane :) how long until you have all sorts of inconsistencies because something was changed without updating ancestors/children ?
<wpwrak>
i was asking what you call a "vendor lib"
<DocScrutinizer>
xilinx
<DocScrutinizer>
which children?
<wpwrak>
you mean a library where we group parts specific to a single vendor ? why would that cause inconsistencies ?
<DocScrutinizer>
if you're going to change all your resistors from 0402 to 0603, then of course you have quite some components symbols to change. You had to do exactly same amount of editing in BOM anyway, if you don't do it in CAD compnent lib
<wpwrak>
children = items derived from the parent item. e.g., BOM entry from sym. "derivative sym" from "master sym". etc.
<DocScrutinizer>
hell, I mean the VENDOR libs that come from vendor. I don't suggest we create a xilinx lib for the one chip we use from them
<DocScrutinizer>
wtf is a sym component?
<DocScrutinizer>
how would it change?
<wpwrak>
are you sure xilinx provides kicad symbols ? :)
<DocScrutinizer>
NO
<DocScrutinizer>
damn, I'm short in time, sorry. No spare time for fun talk
<wpwrak>
hurry to work ! :)
<DocScrutinizer>
there's no such thing like master sym and child sym. At least I don't see any
<DocScrutinizer>
we won't go change all R from US to EU symbol
<wpwrak>
well, that would be one such change :)
<DocScrutinizer>
if you wanna do this, you need a clever editor
<DocScrutinizer>
read: sed
<DocScrutinizer>
or even awk
<wpwrak>
but it can be something smaller. like adjusting a font size. or just a small correction in a symbol. or a global style adaptation.
<wpwrak>
so instead of having to edit a few dozen symbols you get to edit millions. not nice.
<DocScrutinizer>
if global styles are embedded in particular symbol definitions, then you already have a huge problem
<wpwrak>
that's precisely the lack of scalability that makes EE such a mess :)
<wpwrak>
"global style" can mean the grid you use. or how long you make pins.
<DocScrutinizer>
please don't exaggerate in such an extreme way
<wpwrak>
well, look at it :)
<DocScrutinizer>
we're not building big blue here, end even that one has no separate schematics for each of the NNNNN nodes
<DocScrutinizer>
so no way we get beyond 1000 or 2000 components *total*, many of those are same 100R
<wpwrak>
the goal is a shared library for everything in the qi-hw universe (and beyond, if anyone wants to reuse it)
<DocScrutinizer>
so what
<DocScrutinizer>
exactly what I suggested
<DocScrutinizer>
QI_what_we_currently_got.lib
<DocScrutinizer>
if that changes, you have to change all sorts of lists anyway
<DocScrutinizer>
so why not change the lib instead, and autogenerate the lists
<wpwrak>
it's not only what we currently have but also what we may want in the future
<DocScrutinizer>
sigh
<wpwrak>
naw, one symbol per part stands the workflow on its head
<wpwrak>
what you have is typically a set of characteristics
<DocScrutinizer>
per kind!!
<wpwrak>
sometimes, that's just one specific part (e.g., a specific SoC)
<DocScrutinizer>
maybe your workflow. evidently there are other workflows, in "professional" EE
<wpwrak>
sometimes, it's a gazillion of parts that all have the same symbol. e.g., resistors
<wpwrak>
i know that workflow you're describing exists
<DocScrutinizer>
where your design rule checks would warn you that this component isn't sourced yet, etc
<wpwrak>
but it's not the only one
<DocScrutinizer>
now it's even gazillions WTF°!
<wpwrak>
well, N(different types of resistors) :)
<DocScrutinizer>
I still can count all the component part entities of M1 in half an hour on schem
<wpwrak>
probably a few 100k at digi-key alone. maybe a few ten k in our database
<DocScrutinizer>
let alone the number of different ones
<DocScrutinizer>
BS
<wpwrak>
perhaps we should continue this when you don't have to run to work :)
<DocScrutinizer>
you need a 95.73kR. You check what you're using for R now, find the part at vendor in the series, and clone a symbol for it in your lib. Case B): no such part in vendor series, you find another vendor, andother R, you create a new symbol, where you borrow from whatveer you feel fit
<DocScrutinizer>
the overhead compared to editing your stock lists, your BOM, your whatnot, is marginal
<wpwrak>
why clone ? you use the common R symbol and fill in the parameters you want. done. no need to update the global (!) component library (or create a project-local clone, etc.)
<wpwrak>
the BOM is auto-generated from the parameters
<wpwrak>
that's what boom does :)
<DocScrutinizer>
the global(!) has an exclamation mark only because you like to put it there. No other sound reason
<wpwrak>
we can capitalize it ;-)
<DocScrutinizer>
meh, you don't like my concept, because your tools do it differently, and the tools define what can and should be done in which way. Fine with me
<DocScrutinizer>
OK, enough gfun talk eating my time
<DocScrutinizer>
a last quick remark: neither OM nor any of the "spinoffs" has ever wrapped their heads around two basic things: design rule checks, and JTAG boundary scan
<DocScrutinizer>
I suggest you try to find out why big companies use both methods
jluis|work has joined #qi-hardware
<wpwrak>
not sure what you mean by "Design Rule Check". the EDA tools we use have checking functions and we use them (of course)
<wpwrak>
you're right with JTAG, though. i did some boundary scans in ben-wpan, but with a non-JTAG approach (no JTAG available)
<wpwrak>
M1 has semi-automated functional test. but they're not at such a low level
<wpwrak>
and wolfgang doesn't even want automated current monitoring during tests :)
<wolfspraul>
I want to make small incremental improvements that help a user *now*
<wolfspraul>
as opposed to being in lab-mode the next 100 years or longer :-)
<blogic>
wpwrak: where can i find your collection of footprints again ?
<blogic>
i finsihed my bom and am now figuring out which footprints i need to draw
<blogic>
particularly i am looking for a bga84 ddr2 footprint
<blogic>
i found the link to your kicad patches
<blogic>
but i am failing to find the footprint store
<wpwrak>
blogic: no large BGAs or DDR there, though
<blogic>
ok
<blogic>
i tried to figure out how fped works last night
<blogic>
did not advance that much though ;)
<blogic>
will spend more cycles on it today
<wpwrak>
blogic: (more cycles) good :) people generally find it easy to learn. surprisingly easy, actually
<blogic>
actually i was wondering last night if it somehow does not work properly on my machine
<blogic>
have you tried it inside awesome WM ?
<blogic>
i had the impression that the WM was causing issues, as in mouse click seamed to be getting lost
<blogic>
will investigate more today
<wpwrak>
wolfspraul: hopefully < 100 years :) but one prerequisite for introducing such things rapidly would be a bit of a budget for buying instruments. else, we'd have to support the whole zoo that's the installed base
<wpwrak>
(awesome) first time i even hear of that :)
LunaVorax has joined #qi-hardware
<wpwrak>
there shouldn't really be any problem with the window manager. fped keeps things _very_ simple.
<blogic>
o i need to do anything magic to place a pad ?
<blogic>
i am only able to add vectors somehow
<blogic>
anything else i click on will always default back to the "select and move" tool
<wpwrak>
you need two vectors to form a square or rectangle. then you inscribe the pad.
<wpwrak>
e.g.,
<wpwrak>
1) vector (1mm, 1mm)
<wpwrak>
2) vector (-1mm, -1mm)
<wpwrak>
3) select pad, then go to the endpoint of the first vector, click and drag to the endpoint of the second vector. release and the pad is there
<wpwrak>
click on the pad to select. then you can edit the name or change the type
* blogic
tries
<blogic>
ahhhh
<wpwrak>
(type) normal = normal pad; bare = without solder paste; trace = covered by solder mask; etc.
<blogic>
kk
<wpwrak>
now you can change the vectors and the pad will adapt
<blogic>
and paste is with paste i assume
<blogic>
awesome
<blogic>
it was too simple ... i was looking for the magic ;)
<wpwrak>
paste is just solder paste. you can use it to construct things. e.g., a pad that's only partially covered by solder paste (like the center of QFNs)
<wpwrak>
hehe :)
nikescar has joined #qi-hardware
<blogic>
yes
<blogic>
wpwrak: i need a central pad on a lqfp128
<DocScrutinizer>
wpwrak: DRC I basically mean sth like spice integrated into CAD
<DocScrutinizer>
wpwrak: to do this level of design check you need better data of a component than only "33 Ohm"
<wpwrak>
DocScrutinizer: ah yes, that's something we're looking into just now
<wpwrak>
(better data) especially if using wire-wound resistors ;-)
<DocScrutinizer>
indeed, which brings you from your unified R component concept to a "one definition per component kind" concept
<DocScrutinizer>
I'm all for inheriting properties in a parent-child design, if it's versatile enough
<DocScrutinizer>
but in the end you want a definition entity for a class of identical components in your design
<DocScrutinizer>
and identical (again) doesn't mean "it's a resistor"
<wpwrak>
you mean "equivalent" parts ?
<DocScrutinizer>
it means "resistor wirewound 33R 1/4W"
<DocScrutinizer>
(plus a few other properties, for "spice")
<wpwrak>
that's basically what the parameters do. they restrict what components can be used. if any additional characteristics are known, they're then picked from the parts database
<wpwrak>
so you have all that information (that is, if it's generally available. not sure if inductance and such are readily available for, say, chip resistors), but it comes after the schematics
<DocScrutinizer>
well, I can continue discussion for next 30min, just with off times in between
<wpwrak>
and i should get a bit of sleep :)
<DocScrutinizer51>
ok, when your global lib has all the components like nn R n mW <type>
<DocScrutinizer51>
I just wonder how you're ding said change US-EU symbol *then*
<DocScrutinizer51>
doing*
<wpwrak>
the database has things like this: PANASONIC ERJ-6ENF16R9V FP=0805 P=1/8W R=16.9R T=R TC=100ppm/K TOL=1% V=150V
<DocScrutinizer51>
fine
<DocScrutinizer51>
and a link to a common symbol, or symbol directly attached?
<wpwrak>
(T=R is the key that identifies this as a resistor. i didn't distinguish resistor constructions yet. should eventually, though)
<wpwrak>
no no, this has nothing to do with symbols
<DocScrutinizer51>
:-/
<wpwrak>
this operates off the BOM generated by the schematics entry program
<wpwrak>
this BOM has component reference, footprint, and any parameters the user cares to specify
<DocScrutinizer51>
you'd want to unify BOM and schem
<wpwrak>
then boom looks for matching parts. of these, it picks the cheapest
<DocScrutinizer51>
I could come up with a dozen instances where footprint determines schematic symbol
<wpwrak>
(cheapest generally means "common". if you need something fancy, then you'd have to specify how it differs from what boom dug out)
<wpwrak>
oh, sure
<DocScrutinizer51>
ok, afk now, prolly til brunch break
<wpwrak>
but it's also often an 1:N mapping (often with corner cases making it N:M)
<DocScrutinizer51>
yep
<wpwrak>
frohes schaffen ! :)
<wpwrak>
(i don't think this has a good translation)
dvdk has joined #qi-hardware
Martix has joined #qi-hardware
jekhor has joined #qi-hardware
Martix has joined #qi-hardware
jekhor has joined #qi-hardware
wolfspraul has joined #qi-hardware
Ewan has joined #qi-hardware
panda|x201 has joined #qi-hardware
Aylax has joined #qi-hardware
MabYwen has joined #qi-hardware
antoniodariuh_ has joined #qi-hardware
GNUtoo has joined #qi-hardware
DocScrutinizer has joined #qi-hardware
wolfspra1l has joined #qi-hardware
stratman2 has joined #qi-hardware
Martix has joined #qi-hardware
<DocScrutinizer51>
danke
cladamw has joined #qi-hardware
antoniodariuh_ has joined #qi-hardware
<cladamw>
wpwrak, have you edited several parts in per parts in KiCad ? i.e. using "Parts are locked" to be checked. :-)
<cladamw>
i only did once in avt2 for jz4720.
<wpwrak>
you mean a multi-part component, like the FPGA ?
<cladamw>
wpwrak, yes! :-) Do you know how to create different graphic rectangle to the component body in different sub-part ?
<wpwrak>
you can basically draw completely different things for each sub-part
<wpwrak>
we used this extensively in gta02-core. lemme find it ...
<cladamw>
when i checked that icon "Parts are locked", f.g. I edited 'part A' with A size rectangle, but the graphic will still be placed in part-[B:F] which is not the right for the 'check' purpose. :(
<wpwrak>
i'm not sure what "parts are locked" does
<cladamw>
and I imported KiCad's original one multi-part components. But they are different size rectangle.
<cladamw>
with "parts are locked" being checked, means the changes in current sub-part will not influence to other sub-part sheet.
<wpwrak>
what you're looking for may be the "Edit pins per part or body" button, top button row, the last on the right
<cladamw>
yes, right, that's one. :-)
<wpwrak>
hmm. svn,openmoko.org seems to be down. no examples from gta02-core then :-(
<cladamw>
if it's locked, any changes on current sub-part won't change else sub-part.
<wpwrak>
if you select 'edit per part", yes
<pabs3>
wpwrak: hardware issues, hopefully back soon
<cladamw>
wow... :( that's bad news for gta02-core.
<wpwrak>
cladamw: almost all the good stuff has been salvaged into qi-hw by now anyway :)
<cladamw>
hopefully i can get find msg in KiCad-users email threads. :)
<cladamw>
wpwrak, qi-hw is qi existed here and there! Good! :-)
rektide has joined #qi-hardware
<wolfspra1l>
argh. next time it's up we really should copy anything from gta02-core that still has value
<cladamw>
wpwrak, i used the same rectangle size for sub-parts in avt2. this means I needed to arrange a suitable expected size for them. But for creating huge SoCs or FPGAs, it may hard to. It must be some settings steps or editing steps in Library Editor. :(
<DocScrutinizer51>
wpwrak: svn.om.org supposed to be up after move to new iron
<DocScrutinizer51>
agni was down, and Roh didn't bother to reboot some of the vservers after hetzner swapped the NIC (or whatever). He told me it's scheduled for after the 'big move'
Aylax has joined #qi-hardware
<DocScrutinizer51>
wpwrak: you could ping roh about it
<DocScrutinizer51>
roh: ^^^
<wpwrak>
wolfspra1l: well, i have a local copy of the svn ;)
<wpwrak>
t have to make them all the same size. they can have pretty much any shape
<DocScrutinizer51>
bbl
<wpwrak>
pabs3, DocScrutinizer: (svn.openmoko.org) so it's a self-healing problem then. good ;)
<wpwrak>
cladamw: ah yes, be VERY careful if not in "edit per part" mode ;-)
<cladamw>
wpwrak, oah...sure...i tried to make different shape firstly but failed. :( Since even changes are in sub-part will all copy to else sub-parts no matter i check it or not. phew ~
<wpwrak>
cladamw: i once submitted a patch that would prevent just this sort of collisions, but they considered it a feature to have them ...
<wpwrak>
cladamw: no, changes in the sub-part will not be propagated to the whole.
<cladamw>
wpwrak, yeah...i tried many times with success. I hope there's fix in maybe later version.
<wpwrak>
don't hold your breath. i did that patch more than a year ago ...
<cladamw>
wpwrak, you can try to edit a new rectangle in part-A, then you can see else sub-part to confirm. :)
<wpwrak>
actually no. that's when i checked it into eda-tools/kicad-patches
<wpwrak>
the original is from gta02-core and dates fro ...
<cladamw>
wow...okay.
<cladamw>
mine is Build: (2010-08-11 BZR 2448)-unstable
<cladamw>
so means i need to install patch ? :-)
<wpwrak>
... april 2010, i think
<wpwrak>
the patch probably doesn't work anymore. just keep things properly separated :)
<cladamw>
mmm...alright. later now. I'll surf more tomorrow or send message to KiCad-users list. phew~
<cladamw>
night
<wpwrak>
untroubled dreams ! :)
rejon_ has joined #qi-hardware
paroneayea has joined #qi-hardware
<wolfspra1l>
wpwrak: is this a serious issue?
<wolfspra1l>
I am just reading from the distance, but when I see Adam wanting to go to the kicad-users list to ask for bug fixes/improvements, I worry a little whether our m1-to-kicad conversion will ever finish...
GNUtoo has joined #qi-hardware
<wpwrak>
wolfspra1l: it's more a nasty surprise. once you've figured it out, you can work around it
<wolfspra1l>
I think first step I will uplevel the patches tomorrow, that's a good exercise anyway. plus then I can compare with the behavior Adam is running into.
<wolfspra1l>
ah ok
<wolfspra1l>
good :-)
<wolfspra1l>
what's a realistic timeline until the entire m1 schematics & bom is in kicad?
<wolfspra1l>
2 weeks?
<wolfspra1l>
more?
<wpwrak>
i'm a bit more worried about what they've done to block operations in eeschema. particularly dragging seems to be quite unusable. but may i just haven't figured out the right way to do it yet ...
<wolfspra1l>
have you tried the most recent trunk?
<wpwrak>
hmm, probably more. one week for the symbols, maybe two weeks for transferring the schematics proper (there may also be some iterations), and one more week for assorted cleanup
<wpwrak>
(latest trunk) yes. the same
<wolfspra1l>
ah ok, the timeline doesn't sound too bad
<wolfspra1l>
[latest trunk] oh well
<wpwrak>
(timeline) assuming there are no big gaps for other things. e.g., i don't know what workload the layout creates.
<wpwrak>
but yes, in general, this type of transfer isn't too nasty. we'll have to unify the style a bit soon. but i think it's best if adam familiarizes himself with kicad a bit more first. the style changes i have in mind aren't too hard to implement anyway. particularly if we avoid rampant redundancy ;-)
Aylax has joined #qi-hardware
Aylax has joined #qi-hardware
<Aylax>
mth: it's probably solvable, but I don't want to waste hours working on it
<Aylax>
OD has been delayed enough IMHO
rejon_ has joined #qi-hardware
wolfspraul has joined #qi-hardware
<Aylax>
mth: sorry for responding on the wrong channel...
<kyak>
Aylax: there is a problem somewhere between 1f955e523358796189db503e624788d5337c15a3 and 8da20f4ef36484a66e5d490f66c39c64e1d149ab commits to gmenu2x
<kyak>
1f955e523358796189db503e624788d5337c15a3 works just fine on Ben
<kyak>
while 8da20f4ef36484a66e5d490f66c39c64e1d149ab starts, but when i select an icon and press Enter, nothing happens
<MabYwen>
it's not a bug
<kyak>
i see there are some commits regarding a "Touchscreen"
<MabYwen>
it's a feature :-D
<kyak>
i think i need to solder a touchscreen to Ben immediately :)
<MabYwen>
omg
<kyak>
MabYwen: seriosly, do you have more information about that?
<MabYwen>
not really
<kyak>
or do you need more information from me?
<MabYwen>
my ben runs jlime atm
<kyak>
good..
<kyak>
xiangfu: if you happen to read the log, please read ten lines above :)
<Aylax>
kyak, I'm on my phone right now, I'll take a look at it tomorrow
<kyak>
Aylax: sure; if you need any additional information, just let me know.. Though i would be able to help only tomorrow in the evening
<Aylax>
kyak, anything has changed on the keymap file?
kilae has joined #qi-hardware
<kyak>
nope
<kyak>
Aylax: the keymaps are the same
<Aylax>
Ok
jekhor has joined #qi-hardware
<mth>
kyak: when you say "nothing happens", does that mean you can go on and select different icons? or does gmenu2x hang?
<kyak>
mth: let me double check
<kyak>
mth: it just hangs
<kyak>
i can't even go to terminal by pressing Ctrl-Alt-Fx
<kyak>
mth: when the screen goes blank after some time, i can't unblank it
<mth>
it should unblank as soon as a key is pressed
<kyak>
i know
<kyak>
but it doesn't
<kyak>
so the keys don't reach gmenu2x after i selected an icon
<mth>
ah, the unblank after selecting an icon, not unblank in general?
<mth>
can you log in with ssh and check if the selected process was started or not?
<mth>
it could be an issue with launching or it could be an issue with who is using the frame buffer
<kyak>
yeah, i press an icon, it hangs, then the screen goes blank, and i can't unblank it
<kyak>
and i can't use ssh atm, that's another issue :)
<kyak>
i'm working on it..
<kyak>
mth: this problem is 100% narrowed down between the two mentioend commits
<mth>
did the system get an SDL upgrade recently by any chance?
<kyak>
as soon as i revert that and build the package, it works as usual
<kyak>
no-no.. it's the same system.. just two different versions of gmenu2x
<mth>
ok, so the old commit works on exactly the same set of libs?
<kyak>
yep
<mth>
if you have the time, a git bisect would be really useful
<mth>
gmenu2x is still working as expected on the Dingoo, so this is not an obvious bug
<kyak>
what is git bisect?
<mth>
it's a way to do a binary search between two revisions
<mth>
it will pick a revision in the middle and let you tell it whether the problem is in that revision
<mth>
repeats that until the guilty revision is found
<mth>
there is a git command ("git bisect") that does all the administration
<kyak>
ok, but what do i search for?
<kyak>
there are just a couple of meaningful commits between the mentioned two
<kyak>
i think it is already narrowed down
<mth>
for the first revision that doesn't work
<mth>
it's somewhat narrowed down now, but there is still at least 3 commits that are likely to contain the problem plus the chance that an unlikely commit is responsible
<kyak>
ok, i'll tell you the exact commit then :)
<kyak>
just bring the ssh back../
<viric>
kyak: for git bisect, you run it between a revision A you know is good, and a B you know is bad.
<viric>
And git proposes a revision to test.
<viric>
You have to tell the outcome: works or not. Then it proposes another...
<viric>
until it tells you: the culprit is this checkin.
<kyak>
how does it (git) know what to proposed?
<kyak>
and how does it check that the problem exists?
<viric>
binary search between A and B, in the direction based on your answer
<viric>
You search, and you tell git if the proposed version works or not
<viric>
By proposed, it means it leaves your checkout in a state for you to test
<kyak>
ok, this would make sense perhaps in a branchy tree.. this is much easier to just change the git hash in openwrt Makefile, rebuild, and reinstall on Ben
<viric>
scrap 'you search' :)
<viric>
Ah ok, as you wish
<mth>
ah, if you don't have a gmenu2x checkout then it's a different case indeed
<viric>
Well, git will tell you the hashes to test.
<viric>
Whether you use the checked out files, or any other means, it does not matter. git only wants you to tell: hash X works or not
<viric>
kyak: its algorithm is meant for you to do the minimal amount of tests.
<viric>
(hence why it is nice)
<kyak>
viric: i got you..
<mth>
kyak: if you're going to test manually, the revisions I suspect are: 57ad81e3dfcead9c090bbe45bb7072a5c7d78415, 0043ea59094ed48cd444fd8564665286b76c8c89, 4ae4fc675e352148ba71f3be027c6c6a13d67468
<viric>
even mth can run the bisect, he tells you the hash to test, and you kyak tell him the outcome :)
<mth>
the last two are close together, so the a good split point would be just after those
<kyak>
ok
<kyak>
i got ssh working, thanks to jow
<viric>
what or who is jow?
<kyak>
this is my imaginary friend
<kyak>
just kidding :) the openwrt developer, jow_laptop
<viric>
jow_laptop is a person?
<mth>
so I would suggest 0043ea59094ed48cd444fd8564665286b76c8c89 as the first revision to check
<kyak>
i was missing shadow passwords support in busybox.
<viric>
do you use dropbear?
<kyak>
yep
<kyak>
mth: so it doesn't crash.. the process is there
<kyak>
let me check the 0043ea59094ed48cd444fd8564665286b76c8c89
pabs3 has joined #qi-hardware
<mth>
that's weird, since the fb related commits are before the first commit you mentioned and would need a new SDL to do something
<mth>
which SDL version do you have?
<kyak>
1.2.14
<kyak>
0043ea59094ed48cd444fd8564665286b76c8c89 works fine..
<kyak>
mth: 57ad81e3dfcead9c090bbe45bb7072a5c7d78415 is the commit causing problems
<kyak>
2d81b13459f092e7178d78d70922b2a743b3b534, being the previous commit, works fine
<viric>
DocScrutinizer51: the president of hungary left the charge?
<DocScrutinizer51>
heard sth like that
<DocScrutinizer51>
my colleagues all got andridiot phones with some newsfeeds
<wpwrak>
viric: apparently due to plagiarism
<DocScrutinizer51>
probably the completed all his dark plans
<DocScrutinizer51>
s/the/he/
<qi-bot>
DocScrutinizer51 meant: "probably he completed all his dark plans"
<viric>
wpwrak: It's amazing that a president leave the charge voluntarily for such a thing.
<viric>
Here it looks totally unbelievable
<DocScrutinizer51>
indeed
<DocScrutinizer51>
esp THIS president
<viric>
I can only imagine such a situation with the president laughing, and saying "haha yes, sometimes that's the best to do"
<viric>
(for Spain)
<DocScrutinizer51>
though I dunno if I even mean the president
<wpwrak>
viric: here, they would probably pretend not to notice
<viric>
either that, or even be proud of the achievement
<DocScrutinizer51>
I hope that totalitarian asshead is the president who let
<wpwrak>
viric: that's better, agreed
<DocScrutinizer51>
left
<wpwrak>
DocScrutinizer: to be replaced by a more totalitarian bastard ?
<DocScrutinizer51>
prolly
<viric>
well, italy and greece have presidents not elected
<viric>
it's the new european trend...
<viric>
voters and elections are sooooo old
<viric>
they make the coup d'etat, saying "it's urgent; we'll let you play democracy later"
<viric>
but it's amazing how neighbouring countries of that supposed 'union' make as if that was totally normal
<viric>
and these europeans then go to UN, and say: this american government is totalitarina, this african too, bla bla
<viric>
lessons of democracy.
<mth>
we don't have an elected president ever... the queen is the official head of state and the prime minister is selected by elected people but not directly elected
<wpwrak>
mth: better keep politics out of the dirty hands of the unwashed masses
<mth>
wpwrak: the thing is that most people here like the queen, even if they don't agree with having a monarchy
<mth>
if there will ever be an impopular king/queen, I think the system would be reformed very quickly
<mth>
but there is no urgency right now
losinggeneration has joined #qi-hardware
<wpwrak>
monarchs are useful. they can be decorative, give your country a touch of the splendor of a golden age long lost, their private lives provide endless material for the yellow press, and if things turn really sour, you can use them for quite spectacular beheadings.
uwe_ has joined #qi-hardware
uwe_ has joined #qi-hardware
Aylax- has joined #qi-hardware
Aylax- has joined #qi-hardware
Aylax has joined #qi-hardware
LunaVorax has joined #qi-hardware
<LunaVorax>
Hello everyone!
<Aylax>
Hi
<Aylax>
:)
<LunaVorax>
:P
<LunaVorax>
No wonder why you're on the two channels Aylax
<LunaVorax>
56 + 30 people in total only one person awake :D
<Aylax>
;)
freespace has joined #qi-hardware
wej has joined #qi-hardware
<GNUtoo>
many more people may be awake
bartbes has joined #qi-hardware
<viric>
ha. I just discovered Documentation/input/joystick-parport.txt
panda|x201 has joined #qi-hardware
LunaVorax_ has joined #qi-hardware
<DocScrutinizer>
there's a lot more to discover around there
<mth>
viric: I built a DB9 to partport cable once to use MSX joysticks under Linux
<mth>
it works fine
<viric>
I have quite enough of those old pads
<viric>
Now it's parports that get scarce :)
<kristianpaul>
viric: next partport is UBB :)
<kristianpaul>
parport*
<viric>
yes, we need gamecon for UBB!
<viric>
:)
<viric>
DocScrutinizer: today I added an option to NixOS to have memtest86+ at grub menu easily... and just discovered that linux has the "memtest=X" option