sixwheeledbeast has quit [Quit: Let's beat it - This is turning into a bloodbath! [http://znc.in]]
DocScrutinizer51 has joined #neo900
sixwheeledbeast has joined #neo900
Kabouik_ has joined #neo900
Kabouik has quit [Ping timeout: 276 seconds]
merlin1991 has quit [Remote host closed the connection]
merlin1991 has joined #neo900
jefrite has quit [Quit: client exited: brb fixing connection problem]
arossdotme has joined #neo900
arossdotme-planb has quit [Ping timeout: 246 seconds]
Kabouik has joined #neo900
Kabouik__ has quit [Ping timeout: 260 seconds]
arossdotme-planb has joined #neo900
arossdotme has quit [Ping timeout: 250 seconds]
arossdotme has joined #neo900
arossdotme-planb has quit [Ping timeout: 264 seconds]
<wpwrak>
ceene: what i gather from the logs is that you did a test with a design your company/group/? had, but it's something you can't share
<wpwrak>
ceene: i'd like to be able to play a bit with it myself (the converted version, in kicad), to see if anything acts weird
arossdotme-planb has joined #neo900
arossdotme has quit [Ping timeout: 258 seconds]
<wpwrak>
ceene: (schematics) we're still resolving a bunch of details that need to go into the schematics. that "oh, that won't take more than a few minutes, so we do it last" kind of stuff that then ends up eating weeks :)
arossdotme has joined #neo900
arossdotme-planb has quit [Ping timeout: 276 seconds]
arossdotme-planb has joined #neo900
arossdotme has quit [Ping timeout: 240 seconds]
Kabouik_ has quit [Ping timeout: 260 seconds]
Kabouik_ has joined #neo900
jonsger has joined #neo900
<ceene>
lol
<ceene>
yeah, you're right, we did it with one of our designs
<ceene>
yep, we can't share that
<ceene>
maybe we can find some open source altium design and convert it to kicad
arossdotme-planb has quit [Ping timeout: 276 seconds]
<wpwrak>
that would be great
arossdotme-planb has joined #neo900
<ceene>
we have a simple design, that even though theoretically belongs to our company, there's no harm if it gets leaked at all
<ceene>
it's a series of DC/DC converters with the right sequencing needed to boot up a kintex fpga
<ceene>
it's little less than a bunch of datasheets copy pasted together
<wpwrak>
anything more complex than single layer is great :)
<DocScrutinizer05>
why not import a eagle design?
<DocScrutinizer05>
since in the end that's what we wanna do
<ceene>
well, we can always import neo900 from eagle, as we did, and export that to eagle
<ceene>
that's of course the final purpose of it all
<ceene>
so of course, we can do just that instead of fooling around
<DocScrutinizer05>
please check your last post
<DocScrutinizer05>
export to eagle?
<ceene>
->kicad
<ceene>
sorry
<ceene>
we already have one neo900 imported to altium, the one we used to place componentes and check used area
<DocScrutinizer05>
I wish we could export to eagle, and I think it can't be too difficult
<ceene>
so we can export that to *kicad*
<wpwrak>
translating hungarian to chinese to english. let's see what happens ;-)
<ceene>
i think we tried to export to eagle with no success
<ceene>
or maybe we just found that eagle was a horrible piece of s...oftware
<DocScrutinizer05>
yeah, maybe we have better success with doing something ourselves
<ceene>
i think kicad looks quite good
<DocScrutinizer05>
for export
<ceene>
it's just that we're used to altium and the learning curve may delay it a lot
<DocScrutinizer05>
I'm talking about export
<ceene>
ah
<ceene>
writing something to export to eagle?
<DocScrutinizer05>
yes
<DocScrutinizer05>
eagle could import raw 'drawing data' to act in pcb layout editor on an existing schematics
<DocScrutinizer05>
I think when we can export component placement coords to have all components in right locations in eagle, the trace drawing can get scripted from spmething as 'stupid' as gerber even
<DocScrutinizer05>
after all it's pretty much parameter passing, and simulated mouseclicks resp placing of basic drawinf elements like circle segments and lines and vias and pads
<ceene>
altium2kicad pcb converter is "just" 3000 lines of code
<wpwrak>
trivial ;-)
<DocScrutinizer05>
if altium could create whatever structured description of the layout, we probably could convert it into an eagle script to duplicate the layout in eagle and thus 'import' it
<ceene>
for certain values of "trivial", yeah :D
<wpwrak>
interesting comment in convertpcb.pl: "Novena had too many netclasses for KiCad". makes me wonder if they also used kicad for design work, or just a viewer
<wpwrak>
s/ a / as /
<DocScrutinizer05>
in the end altium also will just use elements like LINE_X1,Y1,X2,Y2
<DocScrutinizer05>
we won't need anything like netclasses for that
<wpwrak>
DocScrutinizer05: if all you want it a viewer, why not use kicad if that already works ?
<DocScrutinizer05>
because that's not all I want
<ceene>
it seems like novena was written on altium
<ceene>
s/written/designed/
<ceene>
and this guy thought: i can't have a computer which can't route itself, so let's convert our schematics to something we can run!
<DocScrutinizer05>
we want to be able to use our design later on, and do edits on it
<ceene>
like using a nonfree compiler to write a free compiler :)
<wpwrak>
ceene: yeah, that's the spirit ! :)
<DocScrutinizer05>
lockin to altium is a nogo
<ceene>
well, it seems that this altium2kicad is quite good
<DocScrutinizer05>
doesn't help when kicad falls apart on trying to edit the stuff
<ceene>
it breaks?
<DocScrutinizer05>
nobody tested yet
<DocScrutinizer05>
the project feasibility been evaluated with the assumption that eagle gets used, as it been used for GTA04
<DocScrutinizer05>
everything else may or may not work, and we would take a huge risk in going that route without a clear idea of what works and what doesn't
<ceene>
well, i can offer you this board of ours exported to kicad, since it's a complete design with both schematic and pcb layout
<ceene>
you can play with it as much as you want and test if everything is all right
<wpwrak>
ceene: yes,please :)
<DocScrutinizer05>
that sounds good but we need to see if we could edit it in kicad then
<ceene>
give a few minutes then
<DocScrutinizer05>
so that's what we want to evaluate now
<DocScrutinizer05>
I'm pretty sure import of *layout* into an existing and matching eagle project with all the components correctly placed is a quite feasible task, as long as the source is known and not to screwed format
<DocScrutinizer05>
worst that could happen was _all_ traces just being polygons
<DocScrutinizer05>
so we would need to convert a polygon segment consisting of two long parallel narrow lines into a trace line
<wpwrak>
if you want to edit it, there's a lot more, though: fill areas, no-fill areas, net classes (with trace parameters and such), even text is tricky
<DocScrutinizer05>
net classes? in layout?
<wpwrak>
and then you get to little details like what constitutes a "connection"
<DocScrutinizer05>
that's irrelevant since that is handled in eagle
<wpwrak>
net class = a set of nets with the same characteristics (track width, clearance, via type and properties, etc.)
<DocScrutinizer05>
there are no netclasses in the layout
<DocScrutinizer05>
maybe in editing the layout, yes
<wpwrak>
yes, just "viewing" is easy. but editing is much harder.
<DocScrutinizer05>
err how?
<wpwrak>
and there may be things that exist in one system that don't have a representation in the other
<DocScrutinizer05>
which ones?
<DocScrutinizer05>
both work on the same PCB
<wpwrak>
or hints that B uses that A doesn't provide
<DocScrutinizer05>
sorry?
<wpwrak>
things like additional trace parameters. e.g., impedance
<DocScrutinizer05>
ohmy
<DocScrutinizer05>
trace impedance is a parameter for schematics, not seen in any gerber file
<wpwrak>
so all such stuff would either have to be stripped in translation or it would have to be encapsulated somehow
<wpwrak>
not in gerber, but when we're talking about "editing", i guess you don't mean to draw line segments in gerber :)
<wpwrak>
i mean, i think there are gerber editors ...
<DocScrutinizer05>
you don't get my approach, which is: basically I could redo the layout on an existing schematics from a scan of the physical PCB
<DocScrutinizer05>
you never did any layout in eagle
<DocScrutinizer05>
otherwise you might understand what I'm thinking about
<DocScrutinizer05>
you already get ratsnest in eagle PCB editor, all you need to do is to transform each ratsnest line into a trace of a specific width and route
<wpwrak>
well, maybe eagle is really that primitive. in kicad, i have drc that ensures i maintain proper clearance and such
* DocScrutinizer05
headdesks
<DocScrutinizer05>
that's not neaded, given the altium layout is ok, no?
<DocScrutinizer05>
needed, even
<ceene>
i think what wpwrak is trying to say is that kicad looks like a more sensible alternative than eagle :)
<ceene>
i can't tell for sure since I haven't really used any of them
<DocScrutinizer05>
and what I'm trying to say is that wpwrak obviously never touched eagle editor, so he hardly can estimate that
<ceene>
although at first glance it seems that kicad is more capable, or less cumbersome to use
<ceene>
i can agree with that too
<wpwrak>
if you want to edit, you'd want DRC and such. or maybe you're thinking of a very narrow definition of "editing" ? like adding some text to a previously empty area ?
<DocScrutinizer05>
yes, exactly
<DocScrutinizer05>
when I want DRC, I define them, *in EAGLE*
<DocScrutinizer05>
I don't need to import them from Altium
<DocScrutinizer05>
mind you, the schematics are done in eagle anyway
<DocScrutinizer05>
also most of the footprints are already done in eagle
<DocScrutinizer05>
when I need an impedance matched trace, I can edit the property of that one or two traces, in eagle
<DocScrutinizer05>
so much for net classes
<DocScrutinizer05>
you have three or 4 primitives, like LINE, CIRCLE, POLYGON
<DocScrutinizer05>
via
<wpwrak>
well, as long as you have it all figured out and under control, i guess whatever workflow you're happy with is fine ;)
<DocScrutinizer05>
that's it. all we need exported from altium in a form so we can transform it into an eagle script
<DocScrutinizer05>
if worst case we get geber that only has polygons to define the borderlines between copper areas and no-copper areas, we would need a nifty little 'OCR' alike tool that detects what's a long thin trace with parallel border lines, to convert that into a WIDTH $W; TRACE $X1,$Y1 $X2,$Y2
<DocScrutinizer05>
gerber*
<DocScrutinizer05>
but I'm pretty sure altium is not that primitive and could actually provide WIDTH $W; TRACE $X1,$Y1 $X2,$Y2 in some form
<DocScrutinizer05>
maybe with a different syntax
<DocScrutinizer05>
((nifty little 'OCR' alike tool that detects what's a long thin trace with parallel border lines)) likewise for holes, where it needs to detect diameter and center, and for circles (segments) where it needs to detect center coords, radius, start and stop of segment
<DocScrutinizer05>
but I'm absolutely sure Altium internally also works with such primitives, and they probably have same parameters since ... well, a primitive is a primitive. And I'd guess Altium can export those primitives in a somewhat legible form
<DocScrutinizer05>
connecting hte primitives into a connected trace is something eagle does automatically when running the script to import them
<DocScrutinizer05>
importing schematics is magnitudes more involved
<DocScrutinizer05>
but layout should be pretty straight forward, given the source format isn't too wierd and obscure and undocumented
Kabouik_ has quit [Ping timeout: 276 seconds]
Kabouik_ has joined #neo900
<DocScrutinizer05>
eagle sucks big time with its programming features since the ULP language is nice and object oriented but can't do a single change/edit to the project data. And then there's eaglescript which is indeed nothing else but a literal script with a sequence of text commands (eagle originally obviously was 'CLI based' only, the GUI came only later)
<DocScrutinizer05>
so all eagle ULP create a script file [SIC!] which gets invoked as parameter in the ULP exit staement
<DocScrutinizer05>
you probably even could do that multiple times, since invoking an ULP also is just a (scriptable) text command
<DocScrutinizer05>
alas ULP has no notion of cmdlines and GOTO, otherwise you actually could create a little framwork that makes script invokations look like subroutine calls
<DocScrutinizer05>
the last line of a script invoked in ULP foo in line N with "exit bar.scr" would then be a "run foo returntoline=$N"
<DocScrutinizer05>
or rather run foo returntoline=$N+1
<DocScrutinizer05>
for import we don't need ULP, a simple script will suffice
<Kabouik_>
Thanks for the answer DocScrutinizer05! Unfortunately I already check TMO and IRC regularly, but felt sad that there was no real news (as in Pyra news forum section, for example, although they probably are closer to production than Neo900). But I get that the time spent on writing news is lost on something else, my question was not very serious, just wanted to say out loud that my hype status was high, and frustrated. :>
<DocScrutinizer05>
thanks :-)
<DocScrutinizer05>
I can feel with you
<DocScrutinizer05>
ceene: ((eagle IMport)) how about proto_v1?
<DocScrutinizer05>
it has a full layout in eagle
<DocScrutinizer05>
so we could compare the results in kicad (after export from altium) to the original layout in eagle
<ceene>
i need to some real work now, i'll be uploading a few of these things later on
<DocScrutinizer05>
thanks a lot
mrcaaattt has joined #neo900
<wpwrak>
ceene: the conversion preserves quite a lot of things. so far, so good. but ...
<wpwrak>
how does VCCINT-1.0 connect to all the pads in the C8/C9/L1/TP1 group ? some of this seems to be by magic :)
<ceene>
let me see
<wpwrak>
also, VCCAUX-1.8 ending at TP2 looks pretty far off. it still makes contact, but does it really look like this in the original ?
<ceene>
i'm gonna ask ahycka for a pdf of the original
<ceene>
so we can compare
<ceene>
i can't open it either on this PC :D
<wpwrak>
hehe :)
<ceene>
she's had to remove some logos and a couple of other things that would identify the project
<ceene>
so it's possible that something got mistakenly removed on its way
<ceene>
i see what you mean of TP2
<wpwrak>
a small oddity is that package outlines have become drawings. i.e., they're no longer part of the footprint.
<ceene>
it should certainly be better if it had fallen down right into the middle of the via
<ceene>
instead of touching on one side
<ceene>
but i don't know if that's in the original
<ceene>
it's possible that some outlines are placed on a different layer so it can be taken out of sight by hiding that layer
<wpwrak>
seems that all are separated. also, when moving a component, the pads move, the outline stays
<ceene>
uhm, i see that thing with vccint-1.0
<ceene>
it doesn't appear connected to L1
<ceene>
yep
<ceene>
i assume that's connected on the original, of course
xman has joined #neo900
<wpwrak>
also, i wonder if U1 really has a bunch of vias underneath, or if that's another footprint "reconstruction" that didn't happen
<wpwrak>
vccint-1.0 is the only issue i saw that would be serious for viewing
<wpwrak>
for editing, the rest would quickly become an issue, too
<ceene>
i think the whole lots of vias are intended to be there
<ceene>
those are some dc/dc converters and they're probably there to help with thermal disspation
<wpwrak>
i can rearrange traces and such without problems. the push router feels very happy :) so small fixes would be possible even with kicad.
<wpwrak>
(vias) what i mean: are they part of the footprint definition or are they part of the board ? i.e., if you move the component, do the vias move with it ?
<ceene>
that i don't know for sure, i know that ahycka sometimes places vias on the footprint itself, as they are pretty much obligated by the datasheet
<wpwrak>
it seems that the conversion did basically what joerg described: turn everything into simple graphical elements. but then you lose properties like components being components.
<ceene>
at least some of the design rules seem to be there
<ceene>
net class 2A
<DocScrutinizer05>
that's the reason why I said we shall use the existing footprints of eagle in eagle
<wpwrak>
ceene: (net classes) and they're identical ;-)
<ceene>
i've uploaded gerber.rar file in that directory
<ceene>
so you can check and compare with the real pcb
<wpwrak>
through-hole components move properly. so the "via" doesn't get separated in this case.
Kabouik__ has joined #neo900
Kabouik has quit [Ping timeout: 244 seconds]
<DocScrutinizer05>
it needs to be grouped into a COMPONENT bracket
<ceene>
ah, i see now what's happening with VCCINT-1.0 routing between capacitor C8 and L1
<ceene>
there's a plane definition
<ceene>
it can be seen both in the gerber and in the kicad file if you look closely
<DocScrutinizer05>
afk
<ceene>
that's the reason too why traces to TestPoints are not perfectly aligned with the via
<ceene>
because they just land in a big area of copper
<ceene>
so, what do you think?
<ceene>
it shouldn't bee too hard to improve altium2kicad if needed
SylvieLorxu has joined #neo900
<wpwrak>
(plane definition) ah yes, that's how it works. interesting that kicad actually handles this correctly, even if they don't seem to be connected :)
pagurus has quit [Remote host closed the connection]
<wpwrak>
and the isolation happens because it doesn't "see" that the bottom trace from VIN is connected. let's see if DRC can fix that for us ...
<ceene>
i see that via inside the plane
<ceene>
oh, i see
<wpwrak>
no such luck :(
<ceene>
it doesn't know the via is connected to vin
<ceene>
but it's been connected on the other circuit at its left, next to c2
<ceene>
it isn't either on the righter, C18
<ceene>
well, time to go now!
<ceene>
i'll be checking the irc later tonight
<ceene>
ahycka says it's possible she forgot on her altium version
<ceene>
doesn't think so
<ceene>
but could be
<ceene>
this board wasn't manufactured
<ceene>
nor did it pass the usual review process we follow with the boards that we build
<ceene>
so some little things could be off
<ceene>
but this design passed DRC on altium
<ceene>
so it's strange
<ceene>
well, gotta go now!
<ceene>
cya!
<wpwrak>
in the gerber, it looks okay. so the altium is probably fine.
<wpwrak>
i can fix the connection by going to the legacy canvas (= manual routing), turning off DRC, adding a trace between the two (guided by "magnetism"), then running a DRC check. that picks up the new connection and assigns the stray segment to the correct net.
<wpwrak>
meh. but when i clean it up it still won't let me connect it "properly" to the rest
Kabouik_ has quit [Ping timeout: 240 seconds]
<wpwrak>
DocScrutinizer05: this is exactly the sort of problems why i wouldn't expect too much from conversion. for viewing it's okay, since you can just dismiss such little bugs. but if you were to go from a converted version to actual manufacturing, you'd first have to sort out all these issues (DRC should find most problems, but there's stuff that may sneak through. especially if the design follows rules which are not completely declared to the C
<wpwrak>
AD system.). and you have to do it again if changes are made in the original.
<wpwrak>
for adding text in an empty area, or such, it may be safer to merge things at the gerber level
<wpwrak>
ceene: the design rules also don't seem to quite match. e.g., when running DRC, i get a bunch of "Too small via size"
<wpwrak>
i can't wait to see what they'll reveal in the season 12 finale of "pong" ...
<pigeons>
one reason Ms. Pac-Man got so many of my quarters was I wanted to see what would happen next in the cutscenes after completing a few levels
<DocScrutinizer05>
wpwrak: the original is eagle
<DocScrutinizer05>
if the suggested aproach turns out to not be feasibe, then we have to face that fact
<DocScrutinizer05>
we definitely won't edit at gerber level
<DocScrutinizer05>
that would be completely insane, we wouldn't even have a way to *check* the result
chainsawbike has quit [Ping timeout: 252 seconds]
<DocScrutinizer05>
we need to stay in control of the layout, it's worth little when we got a layout that we can't work with since we don't have the tools
<DocScrutinizer05>
I also obviously failed to explain my idea and the working principles of "layout import to eagle" - it works just like we would do manual layout in genuine eagle board editor, just the "mouse actions" are script controlled. This should largely defeat any inconsistencies like you experienced them in kicad now
<wpwrak>
i'm not quite sure what exactly you expect to edit. move components ? alter the connectivity ? add some non-circuit elements ?
<DocScrutinizer05>
I expect to reuse the layout later on
<DocScrutinizer05>
so basically I expect to be able to edit everything, from schematics to the last detail of layout
<wpwrak>
in eagle ?
<DocScrutinizer05>
yes, in eagle. unless we can prove it works in kicad, which seems to have failed
<DocScrutinizer05>
we hardly can do it in altium, no?
<DocScrutinizer05>
and we won't switch to editing gerbers for proto_v3
<wpwrak>
altium would seem to be the most logical choice. i don't think you can get anything you could edit meaningfully in eagle by essentially importing gerbers
<DocScrutinizer05>
ohmy
<DocScrutinizer05>
could you please elaborate WHY you don't think so?
<wpwrak>
all this assuming doing the schematics in eagle and the layout in altium does actually work. but since you have a relatively small interface there (i.e., the netlist and the footprints), that may be the case
<DocScrutinizer05>
err what?
<DocScrutinizer05>
I don't think any layouter could do a layout based on a netlist, without decent schematics
<wpwrak>
because you'd have even less information than we currently have in the altium2kicad-converted design. the one which you've declared a failure. and yes, i agree that this isn't good enough for actually working on the layout. (as in moving components, changing connections, etc.)
<DocScrutinizer05>
you simply don't listen or don't get it
<wpwrak>
the schematics don't have to be in the same EDA system
<DocScrutinizer05>
the info is already there, in eagle
<DocScrutinizer05>
aha!
<wpwrak>
the only a priori information eagle will have is what comes from the schematics, given that the layout "originates" from altium. so that's not all that much more than what kicad has, too. in fact, at least in the test we just did, kicad has access to the netlist as well.
<wpwrak>
lemme see what the conversion did to the schematics ...
<DocScrutinizer05>
no you're wrong
<wpwrak>
oh dear... they certainly look interesting
<DocScrutinizer05>
sorry I repeat myself a 5th time: place the footprints OF EAGLE in the exact locations IN EAGLE board editor, then simply import what you usually would do manually, in particular the routing of ratsnest lines
<wpwrak>
nothing quite where it should be. text over stuff. symbols that have duplicate content. interesting :)
<wpwrak>
(don't "import" components) yes, that would solve the problem of parts of footprints getting detached. (e.g., the silk screen such such i mentioned) so the other issues would still exist. of course, all that also depends on how good your converter is.
<DocScrutinizer05>
eagle will constantly apply basic ERC and DRC during the automated layout process driven by a script. So such nasty effects you seen in kicad could not even happen to start with
<DocScrutinizer05>
there will be no "other issues"
<wpwrak>
kicad also has drc. and it's more than happy to tell me about all the things the conversion did wrong. but either way, you have to fix that then somehow, or - if you can - ignore it.
<DocScrutinizer05>
*sigh*
<DocScrutinizer05>
please get it that eagle is doing the edits
<DocScrutinizer05>
it won't introduce bullshit
<wpwrak>
so what will it do when instructed to "introduce bullshit" ?
<DocScrutinizer05>
it will adjust the command according to DRC
<DocScrutinizer05>
and to grid
<xman>
:D how to you make a sign for head against the wall … j/k
<wpwrak>
aah, using the AI component :)
<DocScrutinizer05>
meh!
<xman>
I'm all for open software, but sometime you need to use the one that make your project easier. it seem like it's not kicad in this case.
<xman>
I will say I'm have not used any of these softwares, so take that for what it's worth ;)
<wpwrak>
xman: we're actually talking about eagle -> altium -> eagle at the moment :)
<Arch-TK>
18:24:37 AirPlanes2 | not
<Arch-TK>
whoops
<Arch-TK>
thinking about it, where did my selection buffer get that from
<Arch-TK>
ah, ##c
<xman>
wpwrak: Ah I thought you were talking about kicad -> eagle. I'll go back to shutting up :D
<Arch-TK>
continue, it's an interesting discussion, I have no idea what you're on about
<xman>
Arch-TK: Haha
<DocScrutinizer05>
we're talking about using Altium layout editor to augment eagle
<Arch-TK>
and where does kicad come into this?
<Arch-TK>
and as a second question: why?
<DocScrutinizer05>
it comes in when wpwrak claims kicad would be up to the task as well as eagle
<DocScrutinizer05>
I can't imagine checking a layout without proper forward/back-annotation between layout and schematics
<DocScrutinizer05>
no ERC will work without that
<wpwrak>
DocScrutinizer05: please let's be precise here: i say that a layout conversion altium -> eagle would face most of the same problems we've just seen in a conversion altium -> kicad
<ds2>
ewwwwwwwwwwwwwwwwwww altium
<DocScrutinizer05>
and I say you're defintely wrong in ignoring the completely different approach I suggested for scripted edit import to eagle layout, compared to the project data structure inport into kicad
<ds2>
orcad is cheaper :P
<wpwrak>
so our plan would be: 1) schematics in eagle, 2) draft layout in altium, 3) finishing in eagle ? (i.e., altium would be removed from the loop after the "re-"import to eagle)
<Arch-TK>
What does altium do that eagle can't?
<DocScrutinizer05>
yes
<DocScrutinizer05>
Arch-TK: decent router
<wpwrak>
Arch-TK: eagle can't do all that much ... especially for layout, it seems to be surprisingly primitive
<Arch-TK>
and what does eagle do that altium can't?
<DocScrutinizer05>
I wonder how you come to that conclusion
<Arch-TK>
It's like a couple fighting :P
<wpwrak>
DocScrutinizer05: "decent router" :)
<DocScrutinizer05>
and what does eagle do that altium can't? sell their software at an affordable price, keep the workflow already established since GTA04
<wpwrak>
Arch-TK: i guess it's mainly about legacy: our schematics are in eagle, and there are some footprints as well, also in eagle.
<wpwrak>
Arch-TK: plus, eagle is compatible with nikolaus. i think that's joerg's main reason why he wants to loop back to eagle.
<DocScrutinizer05>
no
<DocScrutinizer05>
I'm just not keen to run cheeringly into another lock in
<ds2>
run in Linux
<DocScrutinizer05>
with an even weaker single point of failure than ever before
<Arch-TK>
Just put a blindfold on, then you won't know when you run cheeringly into another lock in
<DocScrutinizer05>
bye fellas, I got a mood to have a break from this madness
<DocScrutinizer05>
we prolly rather should discuss such stuff in a closed channel
<wpwrak>
points 1) and 2) of the plan look feasible. i very much doubt 3) would be feasible, also considering the constraints of this project. but then, if the issue is just avoiding lock-in problems, it may actually never be necessary to implement step 3).
<Arch-TK>
I feel this transparency is cool.
<Arch-TK>
I think I'll spend more money on the neo900 while the GBP has stabilised at -10% and the EUR is starting to get more expensive
<Arch-TK>
oh, gbpusd is all the way up at 1.35 now
<Arch-TK>
there's a very very slight positive trend since the end of monday.
<wpwrak>
Arch-TK: toldya :)
<Arch-TK>
the trend on XBT is all over the shop
<Arch-TK>
nobody knows whether XBT will be 1000 USD tomorrow or 1 USD
<Arch-TK>
It's funny looking at how real currencies look over time and at how XBT does over time
<Arch-TK>
XBT is like someone crushed a year of trends into a day.
<Arch-TK>
any chance the neo900 store will accept BTC at any time?
<pigeons>
do you know a sane payment processer for them?
<Arch-TK>
I think coinbase does payment processing for BTC, no idea how sane it is
<Arch-TK>
I use it as an exchange
<Arch-TK>
they have a 1% exchange charge
arossdotme has joined #neo900
<pigeons>
well coinbase is the furthest thing from sane, but do they automatically convert and deposit to German bank accounts?
<wpwrak>
- that is also compatible with us (e.g., geographic reach and such), and
<wpwrak>
- that offers "exact" exchanges.
<wpwrak>
the latter is a requirement from joerg: he wants to be sure that the exact amount of EUR is received by neo900, no matter what happens with the BTC exchange rate.
xman has joined #neo900
<wpwrak>
Arch-TK: wildly fluctuating exchange rates do of course show that this isn't necessarily an excessive constraint :)
<wpwrak>
then,
arossdotme has quit [Quit: Ex-Chat]
arossdotme-planb has quit [Quit: Ex-Chat]
<wpwrak>
- someone would actually have to set this up (in a way that ensures full compliance),
arossdotme has joined #neo900
<wpwrak>
- and it would have to be operated. e.g., crediting of successful transfers to shop accounts, and also debugging of things that go wrong. the latter is probably 99% of the total work.
<wpwrak>
so even if it may seem simple, it does get a little heavy
<pigeons>
a good payment processor handles a lot of the other concerns. But I don't know of one that exists
<wpwrak>
it's that bank with the two unicorns ;-)
<Arch-TK>
alright, that's an extra 250EUR for the Neo900
<Arch-TK>
DocScrutinizer05: I also added a message to the order that I would like to upgrade my order to a Neo900 if possible (if it's not possible then oh well)
<Arch-TK>
Making SEPA payments is so much faster when you've already done it once and your bank saved the beneficiary details.
<Arch-TK>
Unfortunately, when the UK invokes (is that even the right word for this?) article 50, (in 100 years apparently) and then article 50 gets accepted (in another 100 years) and finally Britain's 2 years runs out, then unfortunately I won't be able to make SEPA payments.
<wpwrak>
Arch-TK: did your bank tell you this ?
<wpwrak>
Arch-TK: because it would be strange ... e.g., swiss banks seems to have no problem at all making SEPA payments
<Arch-TK>
No, but since SEPA stands for Single Euro Payments Area and is an EU invention I imagine that the no charge stuff doesn't work if you're not part of the EEA or EU
<Arch-TK>
hmm
<Arch-TK>
interesting
<Arch-TK>
Well, I guess it depends on what the UK negotiates with regards to this
<wpwrak>
Arch-TK: in the case of UBS, there is a small charge. but the payment process is just as streamlined as elsewhere.
<Arch-TK>
Switzerland is still part of the EFTA is it not?
<wpwrak>
i think so, yes
<Arch-TK>
Maybe that's why.
<Arch-TK>
oh, the payment streamlinyness (who knows) is still the same
<wpwrak>
but it's all really bilateral agreements. e.g., swiss companies and universities also participate in EU r&d programs, erasmus students get exchanged with the rest of europe, and so on
<Arch-TK>
I recently had to make a non SEPA wire transfer and the process was identical
<Arch-TK>
but the charge was higher (for some reason I was charged £4 for this SEPA payment.
<Arch-TK>
So what is the total expected charge for Neo900 as of now?
<Arch-TK>
1000EUR?
<wpwrak>
neo900 would be neon (board) + n900 (case) + assembly
<wpwrak>
the estimate is 990 + 130 + taxes
<Arch-TK>
are n900s really that expensive?
* Arch-TK
got his for £25
<wpwrak>
that's the n900 (in "mint" condition), broker fees, shipping, customs, and then the upgrade
<Arch-TK>
hmm
<Arch-TK>
but do I get a box of mints with it?
<Arch-TK>
Maybe I should just keep my current N900 and replace the screen for one without a slight annoying scratch.
<wpwrak>
i'll pass that on to our cross-border alimentary compliance office
edwin has quit [Ping timeout: 244 seconds]
edwin has joined #neo900
ceene has quit [Ping timeout: 244 seconds]
<Arch-TK>
Your what?
<Arch-TK>
ah I get it.
ceene has joined #neo900
<Arch-TK>
And who is your cross-border alimentary compliance officer?
<wpwrak>
hmm, where did i put that internal organization chart information disclosure request form again ?
<Arch-TK>
I need to file a disclosure request form to see your internal organisation chart?
<Arch-TK>
But isn't Neo900 UG like 2 or 3 people?
<Arch-TK>
heavy rain in the UK, as per usualk
<Arch-TK>
rain for a week, topped off with heavy rain
<Arch-TK>
we'll get a thunderstorm tonight if we're lucky
<Arch-TK>
and then one day of sun and finally the cycle repeats
<sixwheeledbeast>
Your in the wrong part of the UK then...
<edwin>
looks like someone is working on a verilog to greenpak compiler (I think greenpak was mentioned as something you might consider using in the neo900)
<wpwrak>
and i'm just about to add one for the IR TX logic :)
<wpwrak>
plus, we're switching from the GreenPAK4 to the GreenPAK5. the main difference is that the latter can be in-circuit programmed over I2C. that should make development much nicer.
<wpwrak>
the 4 and earlier are one-time programmable and if there's a problem that you only find in the circuit, you have to unsolder and try another chip. (or wire your board to the in-circuit emulator, but that's possibly even more scary)
<wpwrak>
edwin: great link, thanks ! and the problem he describes is something we experience, too :) drawing this sort of logic as schematics gets confusing very quickly
<edwin>
greenpak5 seems to have some interesting stuff, like that async state machine
<edwin>
nice that silego documented the format, apparently fpga vendors usually don't (but then you can hardly call greenpak a fpga) .... ice40 had to be reverse engineered
<wpwrak>
haven't looked at the ASM yet. but already the combinatory logic is a godsend :)
<edwin>
mind you it only supports greenpak4, if you plan to switch to greenpak5 not sure if you can load this tool's output into silego's ide?
<wpwrak>
oh, i think they're very similar. i'm sure he'll add GP5 support before too long. in-circuit programming makes so much better sense for development.
<wpwrak>
but in any case, we can do what we need with schematics entry. it's just a bit inconvenient.
<wpwrak>
edwin: "[Silego have] even offered me free hardware to help me add support for their latest product family, although I plan to get GreenPak4 support to a more stable state before taking them up on the offer."
<wpwrak>
edwin: so i guess it won't be too long until that happens :)
<wpwrak>
it's interesting that most of the complexity he's handling is due to the split connection matrix in that chip (something the chips we use don't have/need)