<chomwitt>
funny , i started reading about pokemon-go and ended reading about cia... (In-Q-Tel funded Keyhole.inc which made the google-map stuff and the founder of Keyhole.Inc is a founder of Niantic how made pokemon go).
<chomwitt>
should u guys put a 'watcher' to gps subsystem also to catch those pokemonster ? ;-)
<R0b0t1`>
just submitted a proposal to IDARPA
<wpwrak>
iDARPA = modernized DARPA, with the zeitgeist-i ?
<R0b0t1`>
lol
<R0b0t1`>
I suppose
dal has joined #neo900
Defiant has quit [Ping timeout: 272 seconds]
Defiant has joined #neo900
dal has quit [Read error: Connection reset by peer]
dal has joined #neo900
<wpwrak>
DocScrutinizer05: little "in-line antennas" on the keypad, cols 3 (lots), 4, 5, 8 (one), 9. plus visible little antennas and bogus joints
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
pagurus has quit [Ping timeout: 276 seconds]
pagurus has joined #neo900
pagurus has quit [Remote host closed the connection]
pagurus has joined #neo900
ashneo76 has quit [Ping timeout: 276 seconds]
ashneo76 has joined #neo900
louisdk has joined #neo900
rjeffries has quit [Ping timeout: 252 seconds]
rjeffries has joined #neo900
<ceene>
DocScrutinizer51: about ahycka & kicad, she's never used it
<ceene>
so... she'd have to learn
<ceene>
not that it's an impossible task, of course
<ceene>
the basis are the same, i guess
arcean has joined #neo900
herpderphurr has quit [Quit: Leaving]
paulk-collins has joined #neo900
Oksana has quit [Ping timeout: 240 seconds]
Oksana has joined #neo900
useretail has quit [Quit: Living in realtime. Thinking in binary. Talking in IP.]
trx has quit []
useretail has joined #neo900
trx has joined #neo900
trx has quit [Changing host]
trx has joined #neo900
arcean has quit [Remote host closed the connection]
arcean has joined #neo900
SylvieLorxu has joined #neo900
rootman has left #neo900 [#neo900]
louisdk has quit [Ping timeout: 250 seconds]
raoulzecat has quit [Ping timeout: 240 seconds]
<wpwrak>
ceene: how does he feel about the idea ? a bit of learning is unavoidable, that's clear. but does she like the idea of doing that ? or not so much ?
<wpwrak>
er yes, typo. i'm in that phaser of transitioning out of bed, which doesn't happen for the whole body at once. clearly, the spell checker is still enjoying a good rest ...
ecloud has joined #neo900
<atk>
that phaser
<atk>
You don't want to fire a phaser when getting out of bed
<atk>
you might light something on fire
<DocScrutinizer05>
krhrhrhr
<wpwrak>
atk: you mean: "don't start a flame war before the first coffee" ? :)
raoulzecat has joined #neo900
DocScrutinizer05 is now known as slartibartfas
slartibartfas is now known as DocScrutinizer05
xman has joined #neo900
<ceene>
wpwrak: i think she'd be willing to use kicad :)
<ceene>
but i don't think she could start before september
<ceene>
we're hurrying up to finish the job this month
<ceene>
and we'll be out on vacation for all august
<wpwrak>
(willing) excellent !! :)
<wpwrak>
september ... oh dear, that's just in a few weeks anyway. how time flies.
<ceene>
yes...
<wpwrak>
in any case, cleaning up the design to a point where it's actually routable will take some time anyway. we're now converting the schematics. that alone will probable take most of this week.
<wpwrak>
then there are a number of issues in the schematics. and many things that are unfinished or that diverged from the specifications or where the specs diverged. so that needs updating/completing, too.
<ceene>
so, maybe the schematics aren't even ready much time before september anyway
<wpwrak>
well, i hope they will be :) i'm rather happy that they have finally become unblocked. so we can fix them, instead of describing what should be done.
<ceene>
so what are you doing now? converting frome eagle to kicad manually, or using some converter?
<wpwrak>
one major thing that still seems to need considerable design work is the bb-xm interface. and the lower-upper connection also needs defining (hopefully just signal assignments, but still). for the rest, we ought to have the design more or less in a usable state. just some thing need translation from white paper to schematics.
<wpwrak>
ceene: it's surprisingly good, better than i had expected. of course, there's still a ton of manual cleanup needed. so now i'm going through everything and cleaning things up.
<wpwrak>
yeah, he must have spend quite some time on getting the geometry right. sometimes, when the converter screws up, and you see very interesting results. results that suggest that the script actually tried to coordinate locations of things.
<DocScrutinizer05>
the first commits date back to 2002 iirc
<wpwrak>
of the converter ? naw, first commit was Sat Jul 26 10:25:04 2014 -0700
<wpwrak>
the converter also tried to convert footprint and layout. layout is of course a disaster area, given that it differs rather wildly from the "clean and tested design" the converter expects.
<wpwrak>
will have to see about the footprints. schematics symbols were converted pretty nicely. only found the first case where it messed up the geometry now, more than halfway through.
<wpwrak>
there are issues with fields, though. e.g., we get a lot of >SIZE fields that shouldn't be there. and maybe some information was lost in the process. we'll see.
<wpwrak>
in any case, it's an improvement over having to do everything from scratch. and the resulting schematics can be edited as if they had been done natively. that's the most important aspect.
<ceene>
great!
<DocScrutinizer05>
ooh right
<DocScrutinizer05>
first commit
<DocScrutinizer05>
lachlan audas committed on 26 Jul 2014
<DocScrutinizer05>
dunno, git still puzzles hell outa me
<DocScrutinizer05>
anyway installing kicad 4.x native is a PITA and won't lead anywhere
<DocScrutinizer05>
for me
<DocScrutinizer05>
on this old system
<DocScrutinizer05>
in the end when you satisfied all other crap (after days of work) you run into stuff like:
<DocScrutinizer05>
jr@saturn:~> kicad
<DocScrutinizer05>
kicad: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by kicad)
<DocScrutinizer05>
kicad: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by kicad)
<DocScrutinizer05>
kicad: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by kicad)
<DocScrutinizer05>
or you try to cheat and get a plain SEGV, which honestly you deserve then
<DocScrutinizer05>
I don't even want to try and figure how building locally would look like
<wpwrak>
trying to build complex modern software on an old system is often an uphill battle
arcean has quit [Read error: Connection reset by peer]
<DocScrutinizer05>
not uphill battle, Sisyphus
<DocScrutinizer05>
you *never* get there, no matter how hard you try
<wpwrak>
the easiest way forward would be to find some place to install ubuntu. then you can just use packages and don't have to worry about all that. and with daily build, also new features are available quickly.
<wpwrak>
yeah :)
<DocScrutinizer05>
"find some place" pretty much has it to the point, in so many aspects of the meaning
<wpwrak>
hehe :)
<DocScrutinizer05>
find a chair, a desk, a monitor, a kbd, a space in a room for all that
<wpwrak>
time to build that new floor :)
<DocScrutinizer05>
alas won't happen
<DocScrutinizer05>
I also can't afford it, even when it eventually does happen (large scale building improvement pending since 3 years now)
<DocScrutinizer05>
and then... I got a fine new shiny kicad on a system that has... zilch. No connectivity, no email, no IRC, no *archives*, no nuttin
<wpwrak>
plan b: tent on the balcony ? :)
<DocScrutinizer05>
good old fallacy of "throw more $resource at it, and it will go faster"
<DocScrutinizer05>
it's not just about getting a working kicad, it's also about *using* it in a productive environment
<DocScrutinizer05>
integration
<wpwrak>
might be a good time to document your system setup.
<DocScrutinizer05>
well, running between rooms to switch between e.g. KiCAD screen and IRC a 300 times a day for sure would benefit my lack of sports
<DocScrutinizer05>
what is the use of documenting stuff like system setup?
<wpwrak>
hehe :)
<DocScrutinizer05>
I got the live setup so I can look up anything I wanna know
<DocScrutinizer05>
and migrating this whole convolution of interacting and mutually depending things to a completely new desktop is exactly what I try to avoid like black plague
<wpwrak>
well, eventually there comes a time when avoiding it becomes more painful that making the change. this time may be now.
<DocScrutinizer05>
to give you a landmark: trying to just migrate email from kmail to thunderbird (and then back again) caused a ca. 3 weeks of mostly downtime on email and loss of a lot of mails, during early stage of this project
<DocScrutinizer05>
err nope, during early stage of maemo infra migration project
<wpwrak>
ah, i just use mutt, fetchmail, and ssmtp. solid as a rock.
<wpwrak>
but yes, you're quite gui-centric. this ought to complicate things.
<DocScrutinizer05>
(migrating to a completely new desktop) with a tiny bit of bad luck you find out that the intended target config doesn't live up to expectations and you have to roll back averything and start anew
<wpwrak>
well, gui-centric but also deeply invested. many people just stay at the surface. then migrations also get easier.
<wpwrak>
(desktop) yeah, that's why i keep things simple :) basically didn't have to change my setup in the last ~20 years
<DocScrutinizer05>
I know from silly "simple" thinhs like a distro upgrade (suse12.4 to 13.1 for example) that even those can take 4 weeks or more until you're up to pace again
<wpwrak>
okay, once exception: the web browser. been clinging to konqueror for a long time. but eventually went to chromium.
<DocScrutinizer05>
well, when I take that approach to the extreme, I'd still work on console and wouldn't know how to run kicad or a simple browser ;-)
<DocScrutinizer05>
maybe lynx ;-P
<wpwrak>
gopher :)
<DocScrutinizer05>
while "LinkedIn: Do you know ... Laszlo Papp ... Andy Green ..." dang they are good, for whatever metrics of 'good'
<DocScrutinizer05>
hint: Laszlo Papp is "father of Aegis"
<DocScrutinizer05>
Richard Purdie sounds also familiar
<DocScrutinizer05>
Jollen Chen
maddagaska has joined #neo900
<DocScrutinizer05>
>> Andy Green Fujitsu Landing Team Lead at Linaro<<
louisdk has joined #neo900
raoulzecat has quit [Quit: byebye]
<DocScrutinizer05>
~ping
<infobot>
~pong
<DocScrutinizer05>
wow, still online
* chomwitt
powering up $ vagrant init Neo900-KiCAD kicad-xfce-devuan.box ; vagrant up (being curious!!!)
* chomwitt
ok. it took less than 3-4minutes to see the login. i had the box file already downloaded though
opa-ben has joined #neo900
louisdk has quit [Ping timeout: 244 seconds]
Pali has joined #neo900
Xiaoman has quit [Read error: Connection reset by peer]
Xiaoman has joined #neo900
announ has joined #neo900
dl2s4 has quit [Ping timeout: 272 seconds]
Arch-TK has joined #neo900
luke-jr has quit [Ping timeout: 272 seconds]
XDS2010 has quit [Ping timeout: 272 seconds]
atk has quit [Ping timeout: 272 seconds]
dl2s4 has joined #neo900
luke-jr has joined #neo900
<wpwrak>
interesting ... sheet 33 (Connector to BB): the two GND3 on P2301 and P2302 are somehow not connected to the nets drawn near them. i.e., the nets are N$xxx while, if connected, they should be GND3.
<DocScrutinizer05>
GND3 sucks anyway
<DocScrutinizer05>
nfc where it came from
<wpwrak>
i guess it's GND-of-UPPER or such
<DocScrutinizer05>
hickup from merger of sub-projects
XDS2010 has joined #neo900
<DocScrutinizer05>
it particularly sucks because of gnd symbol has no clue which ground you meant when placing it (in eagle)
<wpwrak>
dunno. the nets of the various boards are generally fairly cleanly separated
<DocScrutinizer05>
or user has no clue which of the identical symbols GND(|2|3) he looks at
<DocScrutinizer05>
subject to major cleanup
<wpwrak>
yeah, if GND3 == GND_UPPER, it should at least say to
<wpwrak>
or we just make everything one big ground :) given that there is no autorouter anyway, this wouldn't cause overly weird results
<wpwrak>
oh, have any of the BBs mouser have been scheduling to send for about a hundred times by now shown up ?
<DocScrutinizer05>
no
<DocScrutinizer05>
of course not
<DocScrutinizer05>
funny you mention it, I had a unrealted mouser "spam" today and thought semtimentally about BB-vM
<DocScrutinizer05>
x
<wpwrak>
heh :)
<DocScrutinizer05>
maybe we're better off already throwing a DM3730 and a TPS65950 on proto_v2
<DocScrutinizer05>
we still might provision connecotrs to link to an external "brainboard" after removing those core components when the system doesn't come up
opa-ben has quit [Ping timeout: 276 seconds]
<DocScrutinizer05>
(yellow|red) yeah, 'smart¡'
<DocScrutinizer05>
BBL 40min
<wpwrak>
(omap) an alternative would be a "simple brain". most of the interesting things are on i2c anyway, so just with that (and io expanders) we could test a lot of subsystems
<wpwrak>
call it "v2 light" :)
<DocScrutinizer05>
yes, but a few other things are highly important: ausio for example, and USB (also/particularly to modem)
<DocScrutinizer05>
audio*
<DocScrutinizer05>
WLAN
<DocScrutinizer05>
BT
<DocScrutinizer05>
I2C we could test with breadboard ;-)
<DocScrutinizer05>
bbl
<wpwrak>
well, we kinda have the modem. v0 or v1, wasn't it ?
<wpwrak>
DocScrutinizer05: would we have enough bb-xms for a reasonable v2 ? or would we have to switch to something else anyway ?
<DocScrutinizer05>
what we don't have is modem USB PHY and ASC
<DocScrutinizer05>
the purpose of v2 is to validate peripherals, but also to possibly already bring up a fully working system talking to those peripherals - on whatever (preferably OMAP/ARMv7) platform
<DocScrutinizer05>
so we have something to show off
<wpwrak>
USB PHY pretty much needs the OMAP. so that's only possible in a "v2 heavy" scenario.
<DocScrutinizer05>
indeed
<DocScrutinizer05>
sorry, was in a hurry
<wpwrak>
no sweat :)
<DocScrutinizer05>
nah, finsihed shopping, a new record time
<wpwrak>
oh, that was quick indeed :)
<DocScrutinizer05>
19 min, for $home->CONRAD->$home incl a LED E14 bulb booty
<wpwrak>
sh, e-shopping ;)
<DocScrutinizer05>
(couldn't find the milk in fridge anymore, at night ;-P )
<wpwrak>
s/sh/ah/
<DocScrutinizer05>
scooter is a wonderful thing
<wpwrak>
in any case, even if designing for "v2 heavy", we'd want to prepare a plan B in case the omap doesn't run
<wpwrak>
so i guess the "v2" or "v2 light" idea would remain valid
<DocScrutinizer05>
great¡ when I tighten the bulb, it doesn't shine. Needs loosening a 0.75 to 1.5 turns to have a shaky light
<DocScrutinizer05>
o.O
<wpwrak>
for "v2 light", i'd get rid of cam and display, though. they add relatively little value and need tricky signals
<wpwrak>
quality work :)
<DocScrutinizer05>
I don't like the "light" idea much
<DocScrutinizer05>
postponing tricky signals doesn't earn us a thing
<DocScrutinizer05>
for Plan B see what I mused about, above
<wpwrak>
tricky i nthe sense that moving them over a large distance could be an issue
<DocScrutinizer05>
Plan B of "heavy" is "normal" and resort to the 3 BB-xM we got
<DocScrutinizer05>
when that becomes an issue, we ignore them despite them being implemented, and we're no worse off than with ignoring them from beginning
<DocScrutinizer05>
:-)
<wpwrak>
how do you neutralize the omap ?
<DocScrutinizer05>
unsolder?
<wpwrak>
urgh :)
<DocScrutinizer05>
0:-)
<DocScrutinizer05>
it's just an idea so far
<DocScrutinizer05>
up to sparring
<DocScrutinizer05>
I'd even guess we could cut the PCB off
<DocScrutinizer05>
I guess I've seen exactly that elsewhere, let me think where ;-)
fling has quit [Ping timeout: 252 seconds]
<wpwrak>
pdp-4 prototype ? :)
<DocScrutinizer05>
some tiny debug board?
pagurus has quit [Remote host closed the connection]
<wpwrak>
yeah, if you keep it simple,why not. however, 8 layer omap board ... :)
<DocScrutinizer05>
:nod: I know
<DocScrutinizer05>
needs a good saw ;-)
<DocScrutinizer05>
actually nothing you couldn't do with a dirt cheap saw as well, when you dip the edge of the PCB into a foot bath made of HCl and peroxide for a while
<DocScrutinizer05>
;-D
<wpwrak>
or a precisely timed supernova :)
<DocScrutinizer05>
hmm, that's a tad difficult to handle in lab
<DocScrutinizer05>
if you want the huge calibers, I'd rather suggest a decent CO2 laser
<DocScrutinizer05>
but I'd go for dremel buzzsaw and etching every day
<DocScrutinizer05>
I dunno if I made my point clear: you only dip the cut edge of the PCB into the etching bath
<DocScrutinizer05>
to remove any possible shorts between cut traces created by saw smearing copper across the cut
<wpwrak>
yeah, that would help. still ...
<wpwrak>
also, good luck with not getting any hcl on anything else :)
<DocScrutinizer05>
plus given the fact we got 'infinite' space on UPPER, we can single out traces sufficiently along a cut line, to make that procedure absolutely safe
sn0wmonster has quit [Ping timeout: 264 seconds]
<wpwrak>
phew. first pass complete. now, let's pick something easy for the next pass ... ah yes, check for left-over tiny labels
<DocScrutinizer05>
tiny labels seems a feature of kicad you can opt-out from
<DocScrutinizer05>
I've been thoroughly puzzled by those critters
<DocScrutinizer05>
pretty pointless feature
<wpwrak>
they come from the conversion
<wpwrak>
and they'll get in the way if i don't remove them. e.g., by changing net names in unexpected ways
sn0wmonster has joined #neo900
<wpwrak>
fortunately, the remaining few are easily greppable
<DocScrutinizer05>
yeah. But I seem to recall I've seen an option "show labels on traces/signals" OWTTE, and now I wonder if kicad would autoclean all of them when you toggle that option
<wpwrak>
in eeschema ? naw. you normally want such labels very much. just not the ones the converter generated.
<DocScrutinizer05>
I don't want any autogenerated labels
<wpwrak>
yeah. the converter doesn't distinguish between manually generated (useful) and autogenerated (vile junk) labels
<DocScrutinizer05>
if the schematics get so complex/twisted that you need labels on wires to understand what signel they are carrying, then the schematics need a major refactoring
<DocScrutinizer05>
the converter clearly shouldn't have created those crappy labels, to start with. please provide the project file source text so I can patch the converter
<DocScrutinizer05>
NB there are no such labels in eagle
<wpwrak>
(refactoring) so you wouldn't name your signals ? besides, it really helps if you have proper names when doing the layout
<wpwrak>
(source) you know where all the sources live :)
<DocScrutinizer05>
naming signals and placing permanent labels on signals are two different things
<wpwrak>
(no labels in eagle) yes, that's something the converter does because eagle and kicad handle net names in very different ways
<DocScrutinizer05>
a simple estimation gives me: time for removing the label generation in converter + time needed to run converter anew < time needed to clean out labels manually
<wpwrak>
yes, but sometimes they contain useful information. e.g., if a net has been "internally" named (seems to be some weird eagle feature), without placing a label on it. so you need to filter that.
<wpwrak>
also, sometimes they point to potential connectivity issues. i.e., when a net suddenly changes names.
<DocScrutinizer05>
yes, now that you have finished >50% of manual edits, you don't want to run converter anew. But maybe somebody else eventually wants to, and we might have saved time already for first take, when we had removed the code to start with
<DocScrutinizer05>
I don't see how the "internal naming" would be a weird eagle feature. every net needs a name, at least in eagle. When there's no obvious way to derive the name from some pin name or off sheet symbol or whatever, eagle will assign a "$net4711" (or similar) name, which user is free to change any time and to any name she likes
louisdk has joined #neo900
<wpwrak>
yes, but what's odd is that you can change the name without this showing in the schematics, only in the schematics editor, when you examine that net
<DocScrutinizer05>
please elaborate
<wpwrak>
e.g., in eagle, sheet 30, the signal that comes out of U3002 pin B1
<DocScrutinizer05>
actually I forgot what we're discussing
<wpwrak>
do you see a label that would be visible in a PDF or print ?
<DocScrutinizer05>
you say you want a tiny visible label on that signal? why?
<wpwrak>
no, i want a big visible label on that signal
<DocScrutinizer05>
please no
<wpwrak>
but no name "hidden" in the design file, a name that i won't see when reviewing schematics
<wpwrak>
and i guess it's thanks to that feature that the converter produces all these tiny labels
<DocScrutinizer05>
I think when we want a label somewhere, we should place it there explicitly
<DocScrutinizer05>
not auto-generate labels for all signals and then manually remove 99% of them
<DocScrutinizer05>
I could even see some rationale arguing for aut-producing labels in converter for all nets that are not named regex "net\$[[:num:]]*"
<wpwrak>
yeah, the converter simply seems to assume that the eagle design relies heavily on such hidden names. and it tries to make them fit with how kicad does things, with mixed success
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
so fixing the converter is a (globally) good thing to do, I'd say
<DocScrutinizer05>
and it's easy too
<DocScrutinizer05>
or we write job scripts to do that on project file level, which is probably a tad more annoying and less useful
<DocScrutinizer05>
(though implementing / porting the complete converter from ULP to eagle XML project file format would be a good thing too, not too difficult since you got the blueprints in ULP, and you could use C)
<wpwrak>
hmm. now there's a tricky one: sheet 2, VBUS. on its way to VBUS-MODEM, it secretly changes to VBUS-MODEM-CPU ("invisible" net name)
<wpwrak>
now, the fun bit is that VBUS-MODEM-CPU exists elsewhere ...
<wpwrak>
(converting the converter) i guess it would also be a bit faster in C :)
<DocScrutinizer05>
in eagle that's a bug, since aiui networks and even netlists are based solely on net names
<DocScrutinizer05>
yes, waaay faster
<wpwrak>
yeah, i'm trying to figure out what nik really meant to do there. ~-CPU usually seems to just indicate "UPPER"
<DocScrutinizer05>
plus in C ist's (unlike ULP) probably quite feasible to already design the conversion twoway
<DocScrutinizer05>
(even though spreedsheet involved ;-D )
<DocScrutinizer05>
spreadsheet
<Arch-TK>
I'll load up the vm next weekend and investigate for you (if it's not solved by then)
<ds2>
DocScrutinizer05: are you giving up on eagle?
<DocScrutinizer05>
you could get away with creating the csv straight in an editor
<DocScrutinizer05>
ds2: sort of, yes
<ds2>
Oh :(
<DocScrutinizer05>
ds2: well, eagle can't compete to KiCAD's push&shove router
* Arch-TK
pushes and shoves DocScrutinizer05
<ds2>
I usually hand optimize things so... *shrug*
<Arch-TK>
maybe I could do this routing thing
* Arch-TK
pushes and shoves everyone
<ds2>
was really looking forward to a DM3730 design in Eagle
<DocScrutinizer05>
check out GDC's GTA04, done in eagle but with proprietary router... for a reason
<DocScrutinizer05>
alas I think Nik never even pondered publishing the project files
<ds2>
the eagle files for the GTA04 is available? is it GPLed?
<DocScrutinizer05>
ds2: what's wrong with a DM3730 design in KiCAD?
<DocScrutinizer05>
[2016-07-19 Tue 01:39:35] <DocScrutinizer05> alas I think Nik never even pondered publishing the project files
<ds2>
CAD fragmentation
<ds2>
now if KiCAD did a 2 way bridge with Eagle....
<DocScrutinizer05>
for now we have a halfway solid one-way bridge
<ds2>
got too many designs in eagle
<ds2>
one way bridges away from eagle would be $$$$$ to revalidate
<DocScrutinizer05>
actually seems we converted >75% in just 2 days
<Arch-TK>
That sounds promising
<ds2>
<--- does not trust any CAD package til the output is verified with an assembled and tested board
<DocScrutinizer05>
of course
<DocScrutinizer05>
and I lost all confidence in eagle today
<ds2>
it is the same thing with Diptrace...one way conversion
<ds2>
what happened today with you and eagle?
<DocScrutinizer05>
[2016-07-18 Mon 22:34:01] <DocScrutinizer05> something like http://wstaw.org/m/2016/07/18/plasma-desktopfW2277.png should be merely impossible to create, to start with [2016-07-18 Mon 22:32:43] <DocScrutinizer05> actually I should get my money back from cadsoft ;-)
<Arch-TK>
DocScrutinizer05: so you're liking kicad?
<DocScrutinizer05>
[2016-07-19 Tue 00:47:27] <DocScrutinizer05> https://www.youtube.com/watch?v=CCG4daPvuVI makes me want this, alas *none* of it works in the kicad version in VM
<Arch-TK>
I'll have a look into the crashing for you... might be some bizarre version of opengl or some misconfiguration somewhere
<DocScrutinizer05>
lack of forward/back annotation schem<->layout sucks, but....
<DocScrutinizer05>
I blame the VM, not KiCAD
<DocScrutinizer05>
it has a VESA graca emu
<Arch-TK>
possibly neither are to blame
<DocScrutinizer05>
VBox
<DocScrutinizer05>
guest additions
<Arch-TK>
Does it have to be vbox?
<DocScrutinizer05>
not mandatory
<Arch-TK>
can't it be qemu with kvm?
<Arch-TK>
(good networking can be a bit of a pain with qemu)
<DocScrutinizer05>
networking is of minor importance for KiCAD
<DocScrutinizer05>
though those new part libs seem to be online
<DocScrutinizer05>
we won't use them anyway aiui
<Arch-TK>
this KiPart looks awesome
<Arch-TK>
the furthest I ever got in kicad is trying to make a part for a chip I had
<DocScrutinizer05>
also aiui a .vmdk could run under (or get converted to) a qemu image, no?
<Arch-TK>
Possibly...
<DocScrutinizer05>
yup, KiPart looks awesome
<DocScrutinizer05>
mad useful
<Arch-TK>
yes, vmdk is supported by qemu
<DocScrutinizer05>
over at #kicad they recommended errr VMware?
<DocScrutinizer05>
still have to verify [2016-07-18 Mon 14:15:33] <xzcvczx> DocScrutinizer05: btw apart from its speed or lack there of cairo is 99% the same as opengl for those incapable systems
<DocScrutinizer05>
I tried and found I don't find any of those routing options
<Arch-TK>
DocScrutinizer05: track mode - press e
<DocScrutinizer05>
[2016-07-18 Mon 14:18:42] <xzcvczx> but i *think* that vbox is early in the hardware accelerated graphics thing whereas vmware actually got their asses into gear a while ago and sorted it out
<ds2>
what's the problem in the eagle screen shot? (not sure if it is lost in the german)
<DocScrutinizer05>
ds2: an unconnected net (VBUS-MODEM-CPU) *looks* like connected to net VBUS