arcean has quit [Read error: Connection reset by peer]
enyc has joined #neo900
paulk-collins has joined #neo900
arcean has joined #neo900
freemangordon_ has quit [Excess Flood]
freemangordon_ has joined #neo900
Pangolin has quit [Ping timeout: 276 seconds]
Pangolin has joined #neo900
paulk-collins has quit [Ping timeout: 246 seconds]
SylvieLorxu has quit [Ping timeout: 252 seconds]
paulk-collins has joined #neo900
arcean has quit [Read error: Connection reset by peer]
arcean has joined #neo900
SylvieLorxu has joined #neo900
xman has joined #neo900
arcean has quit [Read error: Connection reset by peer]
stefek99_ has joined #neo900
silviof has quit [Ping timeout: 246 seconds]
silviof has joined #neo900
freemangordon_ has quit [Quit: Leaving.]
Pali has joined #neo900
<wpwrak>
ceene: heya ! so, how does ahycka like our crazy little plan ? eager to take kicad for a spin, i hope :)
<enyc>
wpwrak: you going to give it a go? is there a writeup of this plan?
<wpwrak>
enyc: i'd think of organizing it along the lines of gta02-core. but one step at a time. first we need to know if ahycka is happy with the idea. then we can go through the details.
<enyc>
wpwrak: will this help to make project 'completable' and look like it will actually finish, to potential investors ??
<wpwrak>
gta02-core was one of the offsprings of openmoko's telephony activity after openmoko changed course (and wound down). it was an attempt to redo the core design with open tools (i.e., kicad), and make a small number of units from spare components openmoko still had and had no further use for
<enyc>
is that workable for neo900?
<wpwrak>
in gta02-core, we made new schematics, replaced components we couldn't reuse (e.g., the very closed modem circuit), and started getting ready for the layout. the layout was admittedly one of our weakest spots (the other were the components), also since kicad back then was fairly primitive
<DocScrutinizer51>
this time we skip all the initial fun and go right to that weakest point
<wpwrak>
well, we still have to do the initial fun. but it'll be quicker. i also spent quite some time in gta02-core preparing tools and such. e.g., fped comes from there, too
<wpwrak>
enyc: ahycka is the layouter who offered to give neo900 a spin with altium. we don't know yet how she'd feel about kicad.
<DocScrutinizer51>
the hope been that at least altium<->kicad would work sufficiently reliable and accurate
<wpwrak>
enyc: and yes, it should definitely make it more completable :)
<wpwrak>
DocScrutinizer51: didn't we bury altium last week ? please don't touch that grave. we all know that disturbing the undead only brings trouble ;)
<DocScrutinizer51>
hehe
<enyc>
will this come back to hesign-decrisions about board-contents / exact chips used etc.?
<wpwrak>
enyc: regarding whether the play is workable, neo900 is considerably more complex than gta02-core was, but it's also quite thoroughly researched. so the schematics shouldn't be a bit deal. sure, it's a pile of work, but no unchartered territories.
<enyc>
wpwrak: right that about answers my quesiton
<wpwrak>
s/play/plan/
<enyc>
wpwrak: this plan / credibility is important to then get investments etc
<wpwrak>
enyc: no new design decisions or such. it's just a replacement of tools. kinda like choosing whether you take a volkswagen or a ford for your holiday trip. they're different, but both will get you there.
SylvieLorxu has joined #neo900
<wpwrak>
(and we won't take the hummer :)
<wpwrak>
the great unknown is whether kicad will somehow fail us with making this design. at least we don't know of anyone who has attempted making a smartphone with kicad. so there's a risk. but then, that happens every time you're doing something moderately pioneering.
<DocScrutinizer51>
and on the bright side we could fix any roadblocks in kicad (though that takes time)
<enyc>
how was the gta04 laid out ?
<wpwrak>
(car of choice if you're just starting a criminal career, get your hands at some money, but have to be careful to not attract too much attention)
trx has quit []
<wpwrak>
enyc: gta04 was done in eagle. from what i gather, nik added some functionality we have in kicad to eagle (probably without realizing he could have had this with just switching tools)
<wpwrak>
or, rather, he may have created personal tools that replace some of eagle's functionality. a bit like my fped, which replaces kicad's (very weak) footprint editor.
<DocScrutinizer51>
the project feasibility evaluation was based on Nik doing layout with eagle plus his very own tools
<enyc>
hrrm push additioons to upstream?
<DocScrutinizer51>
like GTA04
<wpwrak>
upstream, in eagle ? ;-)
<DocScrutinizer51>
I think kicad
<wpwrak>
ah, some kicad stuff did go upstream. fped was too alien for their taste (they love their c++), but integration isn't so critical there.
<DocScrutinizer51>
so it's kicad eval time. let the seasons begin
<enyc>
i can't remeber when Nik next available eitter
<DocScrutinizer51>
sorry
<wpwrak>
enyc: nik won't be available. he's still very busy with pyra, and this seems to be a very exhausting experience. so he doesn't want to have another monster of similar complexity wait for him when he's done there.
<enyc>
wpwrak: i see
<DocScrutinizer51>
IOW no layout by Nik
<enyc>
wpwrak: he may or may not help later
<enyc>
wpwrak: hopefully will pass any useful experience across i guess
<DocScrutinizer51>
not on layout
<wpwrak>
enyc: but he said he'll still help us with review, manufacturing and such
<wpwrak>
so his experience isn't lost completely. in fact, one could say that we get to keep the best bits :)
<DocScrutinizer51>
my duty now is to decide if project is dead due to key persons/resources became unavailable, or try a completely new approach
<DocScrutinizer51>
ith sufficient support from colleagues I think trying the kicad approach is worth a try
<DocScrutinizer51>
on the bright side the project would get considerably more open by that move
xman has quit [Ping timeout: 252 seconds]
<DocScrutinizer51>
plus we +should+ be able to find layouters more easily
<wpwrak>
yup, that should make roles more flexible. also in the sense of no everything coming to a screeching halt if someone has others things to do for a few days.
<enyc>
how much has kicad come on in meantime anyway?
<wpwrak>
enyc: there was one mayor leap: the addition of the interactive / "push" router. that work was contributed by people from a small garage lab called CERN.
<enyc>
=)
<wpwrak>
enyc: before, kicad only had continuous DRC checking but no automatic routing.
<enyc>
wpwrak: humm err whatis DRC in your view?
<DocScrutinizer51>
Design Rule Check
<DocScrutinizer51>
like min width of traces and gaps
<DocScrutinizer51>
etc
<enyc>
'aah ok
<enyc>
i have a completely different argument with a completely different "DRC" in a completely differet context =)
<DocScrutinizer51>
there's 3 essential capabilities in EDA: DRC, Electric RC, and router
<wpwrak>
DocScrutinizer51: just saw that azonenberg is on the kicad list, too. it's a small world :)
<DocScrutinizer51>
hey great
<DocScrutinizer51>
funny enough neither Openmoko nor Nik used ERC
<DocScrutinizer51>
OM hired me instead ;-)
<enyc>
where can you get sufficient kicad talent / hints from at least ?
<wpwrak>
btw, in kicad, ERC and DRC have very specific meanings: ERC is a connectivity test, done on the schematics. each pin can be input/output/bidir/power_in/passive/etc. ERC then checks that only allowed combinations exist. e.g., connecting two outputs produces an error or warning. so goes leaving an input unconnected. and so on.
<wpwrak>
DRC happens on the layout. basically ensuring that clearances are maintained.
<DocScrutinizer51>
*nod*
<wpwrak>
enyc: there are a lot of people who know kicad, myself included :)
<DocScrutinizer51>
can tou define own ERC rules in kicad?
<DocScrutinizer51>
you*
<wpwrak>
DocScrutinizer51: there's a matrix where you can pick what's allowed and what not. not too great, though. so what i do is to just use defaults, generate a report file, then let a bit of perl process that to show me what i really want.
<DocScrutinizer51>
hmmm
<wpwrak>
that bit of perl also gets all the exceptions.
<enyc>
wpwrak: so... are you going to try to do it ?
<wpwrak>
basically like this: run ERC, wade through the bugs and fix the problems, until you run out of real issues. then make the report and do through things one at a time. save the report and use as "whitelist" for future runs.
<wpwrak>
enyc: err, what's the question ? who, and do what ? :)
<DocScrutinizer51>
whitelist is xommon. yes
<wpwrak>
(everyone is doing something :)
<enyc>
wpwrak: are you going to try the layout in kicad now?
<wpwrak>
enyc: the proposal on the table is to migrate the project to kicad and then do the layout there. still needs some nods, though.
<enyc>
how long will that take to do to get to the point of seeing if that is achieveable? do you have the time to start that?
<wpwrak>
i guess testing the layout could start in earnest in a month or so. converting the schematics will take a bit of time. it's actually a number of smaller steps, e.g., could be:
<wpwrak>
1) convert the existing schematics, 2) check that the converted schems really do the same (i.e., compare netlists), 3) apply all the queued-up fixes and corrections, 4) add queued-up additions (i.e., stuff currently parked in whitepapers), 5) make sure it all fits together (also beaglebone integration), 6) review.
<wpwrak>
how much time all this takes also depends on how many people help. many of the tasks can be nicely parallelized :)
<enyc>
is this worth writing up to a request for assistance in neo900 log / pages ?
<DocScrutinizer05>
definitely
<DocScrutinizer05>
wpwrak: (ERC) I guess we could do a proof of concept resp rapid prototyping first approach based on netlists, where for each pin an associated rule (code) gets executed, with a list of properties of all other connected pins as parameter
stefek99_ has quit [Quit: Connection closed for inactivity]
<DocScrutinizer05>
while read property; do case $property in *INPUT* || *SIGNAL-IN*) ;; *) exit $ERROR;; esac; done
<DocScrutinizer05>
we could even define impedance matched lines as virtual components with special footprints (one trace) and no component, like this. Property "50OHM"
galiven has joined #neo900
<DocScrutinizer05>
on the bright side those rules don't need realtime check 50 times per second. You only run them once for the pin you just connected in schematics (obviously incl all all other pins on same network, unless that network is defined as "common" like GND or power rails)
<DocScrutinizer05>
well once in 'real time', plus of course on request for "Check ERC"
arcean has quit [Remote host closed the connection]
timclassic has joined #neo900
<DocScrutinizer05>
wpwrak: so... seems my local buld of kicad is quite a bit long in the teeth, and also doesn't work anymore thanks to unsatisfied .so dependencies. How would we start the kicad adventure?
<DocScrutinizer05>
if that's how kicad schem editor works (vs eagle) then... :-S
illwieckz has quit [Read error: Connection reset by peer]
illwieckz has joined #neo900
<DocScrutinizer05>
I honestly wonder who had the 'funny' idea to move both endpoints of a line when only one endpoint got selected. I don't see a single sane rationale in that
<DocScrutinizer05>
it might be useful for grouped object clusters like components, but pretty please not for wires
<atk>
DocScrutinizer05: It's possible you're missing some vital detail, I don't have a lot of experience with kicad but I don't remember it being that bad.
<DocScrutinizer05>
quite possibe, yes
<DocScrutinizer05>
my first 16 minutes with kicad
<DocScrutinizer05>
15
<atk>
Yeah, I don't entirely remember it being completely intuitive, but I've only ever used simpler tools before it.
* DocScrutinizer05
hopes for wpwrak to define a version to base our tests on, give instructions how to install and configure that critter, and then some lessons in how to use it
<DocScrutinizer05>
despite the .RPM I installed claims it's 4.02 version of like a month ago, kicad's 'about' says it's still the 2013 version - dunno if I even use a faintly up-to-date program
<DocScrutinizer05>
I guess Yast&konqueror didn't play nice together
<atk>
yeah, that looks like a discrepancy
<atk>
I have 4.0.2 so at least the changelog is talking about the right version
<atk>
Unfortunately I have no experience with suse
<DocScrutinizer05>
ta! already about to mess with >>The selected package 'kicad-4.0.2-2.1.x86_64' from repository 'Plain RPM files cache' has lower version than the installed one. Use 'zypper install --oldpackage kicad-4.0.2-2.1.x86_64' to force installation of the package<< and the ensuing fallout of lib dependencies not met. Just trying to figure what's wrong with the installed libgomp1
<wpwrak>
building from source may be difficult. i haven't tried to do that for some years. (and the number of build dependencies was staggering already back then. the C++ "let's use that library, too" disease)
<wpwrak>
yes, suse will certainly be harder. but you know that ;-)
* DocScrutinizer05
headdesks
<wpwrak>
to drag things, just control-select block the things you want to drag, then drag
<DocScrutinizer05>
err I have no problem with dragging things, just with broken wires from that
<wpwrak>
make sure the wire ends are also selected ?
<DocScrutinizer05>
hm?
<DocScrutinizer05>
to move the break from inmidst wire to end of wire?
<wpwrak>
naw, you don't need even that
<wpwrak>
dragging doesn't break wires. so you're probably moving, not dragging
<DocScrutinizer05>
aha
<wpwrak>
place mouse cursor at corner of rectangular area you want to drag, press and hold ctrl, press and hold left mouse button, you can release control now, move mouse to opposite corner, release left mouse button, move mouse to desired destination, left-click to place
<wpwrak>
Escape or right-click > Cancel cancels
<wpwrak>
if you don't like mice, use "G" to drag the thing under the cursor
<DocScrutinizer05>
and what the heck is the mode without pressing ctrl key for?
<wpwrak>
that's moving, not dragging. dragging preserves connections, moving doesn't.
<DocScrutinizer05>
I completely fail the purpose
<wpwrak>
if rearranging things, you sometimes want to break connections
<DocScrutinizer05>
yeah so better have that on the simpler UI method, makes so much sense ¡
<wpwrak>
but yes, i would have made dragging the "easier" option, not moving. call it historical :)
<wpwrak>
don't you have a machine with ubuntu or such ? keeping up with things on suse may be painful
<DocScrutinizer05>
no
<DocScrutinizer05>
ubuntu, really now?
<enyc>
DocScrutinizer05: i suspect you colud use the source package and use the build-dep system to build it on devuan =)
<DocScrutinizer05>
and then?
<enyc>
then use it =)
<DocScrutinizer05>
no devuan here either
<enyc>
hrm, can you get any deb based distro worknig?
<enyc>
also wonder how welly ou could just use a devuan chroot on opensuse/whatever box ..
<DocScrutinizer05>
*shrug*
<DocScrutinizer05>
if building kicad is not feasible, then we have to wonder whether we can use that tool
<enyc>
as its in debian it must be buildable
<enyc>
they rebuild things on buildd's routinely in conntrolled test using only the build-depndencies it declares etc
<DocScrutinizer05>
when we use kicad we must face the possibility that we need to build our own patched version
<enyc>
yes and that sholud' e a problem... change source, dpkg-source --commit -a makes yo a nice patched source diff for you etc
<DocScrutinizer05>
it seems we already anticipated to run into roadblocks we could only fix by patching that critter
<DocScrutinizer05>
wpwrak boggled, it seems
<enyc>
but i'd agree with wpwrak it can be rather more hpleful deb based distro or chroot available ''in practice'' in my expeinec... but no doubet somebody acan make it behave =)
<DocScrutinizer05>
I'd think a build job should run on any arch, no matter if RPM based or deb based
<DocScrutinizer05>
.configure, make, make install
<enyc>
yes if doing it all manually liketat
<enyc>
i usally (try) to do via dpkg tools and soforth
<enyc>
in any case using 'apt-get build-dep' to get all the right dependencies for the packaged verion can be very helpful ;p
<DocScrutinizer05>
wpwrak: please create a vagrant box!
<DocScrutinizer05>
>>Before diving into your first project, please install the latest version of Vagrant. And because we will be using VirtualBox as our provider for the getting started guide, please install that as well.<< vagrant up
<DocScrutinizer05>
done
<DocScrutinizer05>
well almost
<DocScrutinizer05>
you want to get or init a box
<wpwrak>
naw, kicad works fine here. no need to bring that sort of mess into my life ;-))
<DocScrutinizer05>
sorry, kicad does NOT run here
<wpwrak>
maybe report it to the suse package maintainer ?
<DocScrutinizer05>
to what purpose?
<DocScrutinizer05>
we want our own build anyway#
<wpwrak>
i look in the support forum, or however you solve such issues on suse
<DocScrutinizer05>
which issues? available kicad not being most recent version is no service ticket
<DocScrutinizer05>
and we need to run same version on all DEs
<wpwrak>
(own build) i'd hpe to be able to avoid that. it's just a lot of work, for little gain. for post-processing and such, i just use the file interfaces. much easier than wading through tons of C++
<DocScrutinizer05>
so installing kicad in a VM seems like the only reasonable approach
<wpwrak>
file formats are pretty stable, so some version differences shouldn't be an issue. since we're in an inhomogenous environment, we won't have identical installations anyway
<DocScrutinizer05>
actually it seems you already found a VM with kicad installed, but I doubt we want to depend on somebody else's possibly also outdated git repo for the VM
<DocScrutinizer05>
((inhomogenous environment)) the whole point of a VM
<wpwrak>
and i'm not sure adding a VM to slow things down will make for a nice experience. but you can try it, of course. put an ubuntu into virtualbox, see how it goes. if it's usable, you'll at least have a very "mainstream" version.
<DocScrutinizer05>
we need same tool version throughout project
<wpwrak>
(found a vm) i just googled for kicad and vagrant :)
<DocScrutinizer05>
I thought kicad would be a viable alternative since you are experienced with patching it, even writing tools like fped for it. If we can't even get identical *versions* on all devels' machines, we don't even need to think about starting to run a project of this complexity on kicad
<DocScrutinizer05>
VMs don't slow down stuff per se
<DocScrutinizer05>
a VM is no emulator
<enyc>
i suspect a chroot may be sufficient, even less voerhead to vm
<DocScrutinizer05>
a chroot is more complex to manage than a VM
<DocScrutinizer05>
particularly when you want to create a different OS environment inside the chroot
<DocScrutinizer05>
what's actually a slow emu in a VM is the graphics card
<DocScrutinizer05>
but then, even the worst VM graca emu is on par with my intel embedded video
<wpwrak>
graphics performance is fairly important for kicad (or any cad work of that sort). that's why i'm not sure if adding a VM is the right direction.
<DocScrutinizer05>
what the heck is graphics heavy on a EDA?
<DocScrutinizer05>
I mean drawing a few lines is prolly less workload to the GraCa than moving around a window on my desktop, even without compiz enabled
<wpwrak>
lots and lots of little things :) it doesn't need "gaming" graphics, of course, but you don't want to have an unusually slow gfx system either
<DocScrutinizer05>
VMs don't have an unusually slow gfx system, just no accelereated one
<enyc>
wpwrak: key thing is try it... see what happens.. at least learn something from experience
<DocScrutinizer05>
a true word
<wpwrak>
enyc: indeed
<DocScrutinizer05>
and since I never before used or installed kicad, I'd prefer when wpwrak would do it
<wpwrak>
i have it running without problems :)
<DocScrutinizer05>
if the VM actually turns out to be too slow, we still can dd the disk image to a boot hdd
<enyc>
=)
<enyc>
if you really want 'ubuntu' I reccomend either ubuntu-MATE variant *or* mint-cinnamon variants, not default ubuntu//unity mess