Humpelstilzchen has joined #neo900
Defiant has quit [Ping timeout: 250 seconds]
herpderphurr has joined #neo900
luke-jr has quit [Ping timeout: 276 seconds]
luke-jr has joined #neo900
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
x29a has quit [Ping timeout: 240 seconds]
x29a has joined #neo900
wpwrak has quit [Ping timeout: 276 seconds]
arcean has joined #neo900
Satyricon has quit [Ping timeout: 276 seconds]
amatus has quit [Ping timeout: 276 seconds]
Satyricon has joined #neo900
freemangordon has quit [Remote host closed the connection]
amatus has joined #neo900
xman has quit [Ping timeout: 240 seconds]
wpwrak has joined #neo900
bredebid has joined #neo900
freemangordon_ has joined #neo900
bemyak has quit [Quit: Konversation terminated!]
xes has quit [Ping timeout: 240 seconds]
Xiaoman has quit [Read error: Connection reset by peer]
Xiaoman has joined #neo900
Guest_ has joined #neo900
Guest_ has quit [Quit: Page closed]
galiven has joined #neo900
galiven__ has quit [Ping timeout: 276 seconds]
arcean has quit [Read error: Connection reset by peer]
louisdk has joined #neo900
freemangordon_ has quit [Remote host closed the connection]
Pali has joined #neo900
louisdk has quit [Ping timeout: 276 seconds]
xman has joined #neo900
herpderphurr has quit [Ping timeout: 260 seconds]
<DocScrutinizer05> to whom it may concern: CONFIG_BUSYBOX_CONFIG_BOOTCHARTD=y http://i.imgur.com/aBayOwU.png <buZz> just init=/sbin/bootchartd , it starts /sbin/init itself
<DocScrutinizer05> oops ECHAN
louisdk has joined #neo900
<amatus> EWRONGCHAN?
<DocScrutinizer05> yep
louisdk has quit [Ping timeout: 276 seconds]
<ceene> hi
<ceene> we've been taking a look at the schematics
<ceene> but we can't see where's defined what components go on which board
<ceene> there are also a lot of things that are unconnected and notes talking about various alternatives
<ceene> so... there's still some design decisions that must be taken before routing?
<ceene> has there been a previous or some previous prototype, even of select modules, that are known to be working?
<ceene> is it interesting building prototypes of modules that can be tested isolated of the rest of the circuit or are we aiming for a full prototype of the neo900 just in a dina4 size?
<ceene> by the way, that would make a damn fine tablet
louisdk has joined #neo900
freemangordon has joined #neo900
bredebid has quit [Ping timeout: 276 seconds]
louisdk has quit [Ping timeout: 260 seconds]
louisdk has joined #neo900
bredebid has joined #neo900
paulk-collins has joined #neo900
louisdk has quit [Ping timeout: 276 seconds]
louisdk has joined #neo900
illwieckz has quit [Ping timeout: 240 seconds]
illwieckz has joined #neo900
illwieckz has joined #neo900
<DocScrutinizer05> ceene: :-)
<DocScrutinizer05> yep, full circuit (minus the - anyway missing in current schematics - core system, aka CPU PMU RAM storage etc) on a "A4" for UPPER, plus original shape like in proto_v1 for lower
<DocScrutinizer05> there's also an inproved shape made by Werner and me, lemme find it...
<DocScrutinizer05> wpwrak: did we publish the improved outline shape?
<DocScrutinizer05> ceene: UPPER vs LOWER possibly I only asked Nikolaus to add that to the schematics but it actually never been added, however I think the schematics are "sorted" as - like - first 13 sheets LOWER, then B2B, then the rest of sheets upper. Don't call me out on it yet please. And yes, there are some design decisions that are not yet visible in the schematics though they are already made, and we need some I2C-GPIO-extenders for all the
<DocScrutinizer05> unconnected stuff
<DocScrutinizer05> I'd love to have some sparring partner to complete that stuff, it's not really much
<DocScrutinizer05> most work is to integrate/complete the dual-SIM stuff as of http://neo900.org/stuff/papers/simsw.pdf -- a look at http://neo900.org/resources is always worthwhile
bredebid has quit [Ping timeout: 252 seconds]
<DocScrutinizer05> wpwrak: why do we use VSEL_2_3V_n1V8 instead VSEL_2V3_n1V8 in http://neo900.org/stuff/papers/simsw.pdf ?
louisdk has quit [Read error: Connection reset by peer]
<DocScrutinizer05> oooh nevermind
xes has joined #neo900
xman has quit [Ping timeout: 276 seconds]
<ceene> you're looking for more than simply a routing job, then
<DocScrutinizer05> well, nope, I will provide the schematics so you can do components placement and layout based on it
<DocScrutinizer05> any other topic is unrelated
<DocScrutinizer05> you're welcome to join the circuit design team :-)
<ceene> don't have enough time for that, sorry
<DocScrutinizer05> to avoid amiguity: we're looking for whatever help we can get, the layout job however is not bound to additional skills
<ceene> i understand
<ceene> if at least one of the boards schematic can be finished beforehand
<ceene> ahycka could start routing that half
<DocScrutinizer05> the schematics as recently provided are close enough to the final thing for proto_v2 to base estimations etc on them
<ceene> well, it's important to know which things go on which board, and also if this prototype should have component on both sides as to be more similar to the end product or just one sided
<ceene> if the schematic is split by the b2b connectors page that's great then
<DocScrutinizer05> for LOWER yes, for UPPER it's irrelevant
<ceene> why's that?
<DocScrutinizer05> UPPEr is "A4" and not mechanically resembling the final design
<ceene> ok
<DocScrutinizer05> if you *want* to already keep voids for the SoC and TPS65950 etc, and do the final shape already, all the better
<DocScrutinizer05> but that's not required for proto_v2 and probably will cause stuff to take longer to get accomplished
<DocScrutinizer05> we need a proto_v2 pretty soon now
<DocScrutinizer05> no matter which shape
<DocScrutinizer05> so I guess a singlesided design for UPPER makes sense
<ceene> i'm finding the requirements a bit chaotic, tbh, though maybe it's because i'm not familiar enough with the design
<DocScrutinizer05> please elaborate
<DocScrutinizer05> I'm not used to work with a layouter, actually I'm not used to work with anybody except Nikolaus so far. My former jobs had clearly defined descriptions of what to do and how to hand over results to "next stage"
<ceene> maybe a brief single page with a couple simple diagrams explaining what must be where and the current status of the design would help
<ceene> i'm not getting that about using mere placeholders for the cpu, for example
<DocScrutinizer05> yeah, therer's a rather long list with component placement requirements that never been coherently written down
<DocScrutinizer05> placeholders for SoC was meant when you want to do an exercise of already placing all the components on the finmal area of UPPER, not extending it to A4 like planned for proto_v2
<DocScrutinizer05> cramming in all the needed components on a PCB of N900 shape on UPPEr only makes sense when you keep voids to later place the yet missing components like SoC and TPS65950 there
Venemo_j has joined #neo900
<DocScrutinizer05> regarding the non-existent list with placement requirements I hoped we could do this interactively
<DocScrutinizer05> the simple rule that applies is: it must look and feel much like the original N900 PCB
<DocScrutinizer05> particularly for e.g. display connector, position of kbd meanders etc
<DocScrutinizer05> for LOWER there's a pretty good design from proto_v1 already, that has all the switches and contact pads and C-springs in place
<ceene> ok, it's just that i don't know which is the original n900 pcb...
<DocScrutinizer05> look at the prot_v1 design
<ceene> i saw that the main cause for two pcbs is modem chip size
<DocScrutinizer05> well, plus needed PCB real estate, yes
<ceene> so except for connectors and things needed up/down, whatever else doesn't matter
<ceene> is that it?
<DocScrutinizer05> with the sandwich solution we effectively double the real estate we got
<ceene> if there's already a lower design, all the other things just go on upper then
<DocScrutinizer05> yes, basically that's it
<DocScrutinizer05> hmm, no, the LOWER design was only "mech", it had not all components that need to go to LOWER yet
<DocScrutinizer05> it however had all the contact pads and switches etc
<DocScrutinizer05> everything that has a requirement for placement
<DocScrutinizer05> we have apertures, buttons, antenna contacts etc all defined by the case shell and interfacing to S1 aka lower sider of LOWER, resp for switches to the edge of the PCB
<DocScrutinizer05> all that stuff been ebvaluated in proto_v0&1
<ceene> ok, we'll have to see those first then
<DocScrutinizer05> so the SIM holder exactly fits into the apperture in battery bay steel, the contact pads for speakers and antenna and hs-jack are on right positions, and all the switches placed so they do work
<DocScrutinizer05> ((have to see)) available in "resources"
<ceene> great, maybe that helps here, we're still abit confused about the separation of components
<DocScrutinizer05> all that stuff got inmported into proto_v2 layout which already is there and is missing the component placement any routing
<DocScrutinizer05> s/any/and/
<ceene> when we open proto2 pcb there are components placed outside the board with some routing... it's all a bit strange
<DocScrutinizer05> you looked at the board of prot_v2?
<DocScrutinizer05> hmm I might havve done some autorouting experiments there
<ceene> lol, that explains it then
<ceene> i think we'll import that into altium so we know where to click to do things and will remove all routing
<ceene> so only components are there
<DocScrutinizer05> I didn't place any components and just thought "give it a try if autorouter could at least route a very relaxed placement"
_whitelogger has joined #neo900
<DocScrutinizer05> well, yes, as long as you can route the stuff and actually the components fit
<ceene> yes, of course
<ceene> so maybe for protov2 no distinction should be made
<DocScrutinizer05> there are a set of B2B connecting upper and lower, and those have only a certain number of pins, and you got other components on same PCB you want to connect to
<ceene> yeah, but maybe for protov2 simply routing it all in one pcb is an option?
<ceene> that would validate the complete design
<DocScrutinizer05> except for the components we already evaluated position in proto_v1, there are no restrictions generally for placement, except for a very few (2 or 3) components
<ceene> and would also help later on deciding which way things fit best
<DocScrutinizer05> we can't route it all in one PCB since we can't fir that one PCB into the case shell and thus we lack the connections to all the componets in there. like headset jack, antennas, battery, then the complete BOB (breakout board which holds the uSD tray and the IR sensor and hallswitch and flash LEDs...)
<DocScrutinizer05> also all the switches are on LOWER
<ceene> the idea of this prototype is to be able to place it onto a case?
<DocScrutinizer05> well, mate it to the case, yes
<DocScrutinizer05> thus LOWER needs correct shape
<ceene> you see, then i'm lost again
<ceene> i'm missing most requirements
<DocScrutinizer05> LOWER sits inside the case shell, while UPPER is hovering above and thus can be larger
<ceene> so in the end
<DocScrutinizer05> wpwrak to the rescue! maybe you can explain it better than me
<ceene> if done correctly
<ceene> lower would be the final product
<DocScrutinizer05> yes
<DocScrutinizer05> that's exactly the idea
<wpwrak> DocScrutinizer05: i don't think we "published" that outline. in any case, the script that generate the various outlines (in gnuplot or eagle format) are here: https://neo900.org/git/?p=misc;a=blob;f=pcbmod/Makefile
<ceene> ok, i'm understanding a bit better now
<wpwrak> (how i just wish that our git-to-web critter used nice paths, e.g., like gitlab)
<ceene> so in the end there's not much value on doing a bigger than needed upper, is it?
<DocScrutinizer05> LOWER is supposed to be "simple" compared to final UPPER which will be 8-layer
<ceene> as making lower the final size will impose the components that go each place
<ceene> so if that's defined because lower needs to be as-final-as-possible, why won't upper be too?
<DocScrutinizer05> wpwrak: could you take over for a while, I'm afk for a bit
<DocScrutinizer05> ceene: because upper has not even a SoC yet
<DocScrutinizer05> we use a BB-xM instead, with cables
<ceene> you're talking big words there...
<ceene> shouldn't that be like the first thing to decide?
<ceene> i'd place a zynq, that'd be fun as hell :P
<DocScrutinizer05> hmm? SoC *is* decided, but we don't want to introduce the mess of actually using that critter in proto_v2, bacause way more layers and complex layout
<ceene> ah, ok
<DocScrutinizer05> wpwrak: you're ready for handover?
<ceene> i'll be here for a while, go do your things if you need to, don't worry
* DocScrutinizer05 afk
<wpwrak> ceene: dno't worry about the confusion. DocScrutinizer05 is a strong believer in telepathy. i took me well over a year to figure out what all the things were roughly about, with major surprise requirements still popping up later ;-)
<ceene> :D
<ceene> let's see if i've understood fully
<wpwrak> ceene: the basic idea for v2 is that we don't have the CPU and memories, because they make the board difficult to design and produce. the idea is thus to use a beagleboard xm as the "brain" and connect as many things as possible to v2.
<wpwrak> LOWER is the board that goes into the existing case, mechanically compatible with the n900 pcb, so that it can connect to switches, battery, etc.
<wpwrak> UPPER goes on top of it and is actually above the case, so it has no size restrictions. (the only things it will have to mechanically connect to are display and keyboard)
<wpwrak> i actually started a while ago to extract some UPPER/LOWER assignments from DocScrutinizer05. that process isn't finished, though. lemme find the working draft ...
<DocScrutinizer05> lemme help you: sheet#1 buttons: lower
<DocScrutinizer05> #2 OTG lower
<wpwrak> wait wait :)
<DocScrutinizer05> #3 lower
<DocScrutinizer05> 4 lower
<wpwrak> i had most of the "obvious" ones. just where is it ....
<DocScrutinizer05> 5 6 7 8 9 lower
<DocScrutinizer05> sensors is undecided and up to implementation, except for humidity sensor that goes S4 upper right corner
<DocScrutinizer05> prolly upper though
<DocScrutinizer05> this was #10
<DocScrutinizer05> #11 audio codec prolly lower
<DocScrutinizer05> depends on optimization of B2B pin count
<DocScrutinizer05> #12 lower
<wpwrak> ceene: i'll look later. lemme proceed with design things: we may also need a number of IO extenders (I2C to GPIO chips). v2 may actually need more than the real device, since we won't have access to all the GPIOs of the CPU. details here are still undecided, along with the exact bb xm to v2 connection (nik was supposed to do that one)
<DocScrutinizer05> 13 14 15 16 17 18 19 LOWER
<DocScrutinizer05> then there's B2B sheet #20, then BOB which is neither UPPER nor LOWER but connects to LOWER
<DocScrutinizer05> #23 kbd UPPER
<DocScrutinizer05> a.s.o.
<DocScrutinizer05> 24 mics prolly LOWER though
<DocScrutinizer05> depending on CODEC
<ceene> isn't that almost everyhing?
<DocScrutinizer05> disregard 26 27 28 - they are not in proto_v2
<wpwrak> (gpio) i once did a tentative assignment of GPIO pins, mainly to see how bad things were, and it looked pretty reasonable. so the number of gpio extenders in the final design should be low. here is a graphical assignment: https://neo900.org/stuff/werner/tmp/omap-ball-map-wip.pdf
<DocScrutinizer05> so generally you can say everything up to sheet 20 is lower, everything after that is upper (except for the few things that are not :-D )
<wpwrak> and here is the list, with things that don't need to go to a specific function block (or that have a number of choices) just in the comment at the end: https://neo900.org/git/?p=misc;a=blob;f=pinmux/neo900.assign
<ceene> ok, lots of gpios there
<DocScrutinizer05> for the amount of components on LOWER we need to see if that's actually feasible. We will larn that during layouter's component placement and when it turns out there are problems, we need to reconsider
<DocScrutinizer05> learn*
<DocScrutinizer05> movinf the complete audio stuff to UPPER would considerably relax the crowded situation on LOWER, while adding pincount to the B2B-conns
<ceene> ok, so then we need to have a list of mandatory things that really really need to be on lower
<DocScrutinizer05> all RF stuff needs to be LOWER for obvious reasons, unless we want to use pogopins for the antennas, reaching from UPPER through holes in LOWER to the antennas
<ceene> and then a list of things that desirable to be there
<ceene> and after that a list of things that are mandatory to be on upper and a list of things desirably on upper
<DocScrutinizer05> mandatory on UPPER: SoC and all its companions and tightly related stuff like storage etc
<DocScrutinizer05> power
* DocScrutinizer05 is afk again, sorry
<wpwrak> this is what my tentative placement map looks like. purple/magenta for certainly/maybe UPPER. dark/light blue for cert/maybe LOWER. dark/light green for BOB. white for undecided. red for things that have something pending (and to make it look more confusing ;-) https://neo900.org/stuff/werner/tmp/v2-location-20160520.pdf
<wpwrak> i'll go over the assignments DocScrutinizer05 just made and update accordingly. (and change some bits that aren't really meant to make sense to anyone but myself.) then we should have something actually usable.
<ceene> ok, that would be really great
<ceene> i still have to see what ahycka thinks, but my idea would be to start off with lower, fitting there as much as possible
<ceene> since this will be basically the final design, everytihing that fits here will be finished job and release space for upper
<ceene> once that is done, upper is just the remainings
<wpwrak> regarding the schematics, what's there and should be there is mostly okay. but there are multiple choices that haven't been removed yet. also, DocScrutinizer05 had number of changes that nik never integrated. so these are still pending. last but not least, there are a few bits that still need to be drawn, such as the SIM switch.
<DocScrutinizer05> sounds great! start with component placement, not doing any routing yet. We'll see where we end, and will adjust schematics accordingly
<ceene> those things that are missing are a must beforehand starting
<wpwrak> so the schematics aren't "ready to go" just yet. with sim switch and such, i tried to prepare things as much as possible in the specification documents, so that it should be almost copy & paste.
<ceene> any little thing may fuck all up when we're talking about crowded boards
<wpwrak> totally agreed, yes. the schematics need the above changes and then a thorough review.
<DocScrutinizer05> first me need an idea where we are at all regarding placement
<DocScrutinizer05> if only ballpark
<DocScrutinizer05> I think we did that a long time ago, no?
<DocScrutinizer05> mathematically
<wpwrak> DocScrutinizer05: what information exactly are yuo looking for ? whether it will fit at all ? or only with UPPER the size of saarland ? ;-)
<DocScrutinizer05> s/me need/we need/
<DocScrutinizer05> I'm looking for LOWER and if we can actually place all the components there that we now plan to go to lower
<DocScrutinizer05> if that's not evaluated, odds are the schematics will change massively when we find out about not all components can fit there
<wpwrak> yeah, initial placement usually doesn't survive the first attempt actually make it fit and connected ;-)
<DocScrutinizer05> thus my suggestion to start with sloppy component placement
<DocScrutinizer05> when we see "*might* work", we start the detail refinements
<wpwrak> ceene is right, though: the schematics must be "clean" first. no point in having lots of ambiguities that then need to be resolved one by one on IRC
<DocScrutinizer05> ambiguities are bad, yes
<DocScrutinizer05> I kicked out the nonsensical triple WLAN et al long time ago
<DocScrutinizer05> as well as some other cruft
<DocScrutinizer05> for a ballpark component placement the schematics should be good in that latest version
<wpwrak> kewl ! that one was puzzling :)
<DocScrutinizer05> yeah, the problem always been that Nikolaus wouldn't import any changes I made to schematics, so I wasn't too diligent so far
<DocScrutinizer05> could we proceed with such ballpark estimation component placement?
<wpwrak> yes, a lot of changes have been piling up due to there not being a clear strategy as to what would happen with the things nik planned to do
<wpwrak> another big one is the bb xm connection
<DocScrutinizer05> I'm almost "away" for today
<wpwrak> i once tried to get a bit more meat on these bones, but it wasn't met with much enthusiasm, so i let it drop as well :(
<DocScrutinizer05> ceene: do you think ahycka could do a lazy component placement based on the above assignments?
<DocScrutinizer05> only placement, *lazy*, just to see where we are with real estate needed
<ceene> yeah, that can be done, just one important question
<ceene> double sided?
<DocScrutinizer05> ask!
<DocScrutinizer05> LOWER? yes, of course
<ceene> that'll be our guide to see what must be down there and see how much space it takes
<DocScrutinizer05> I hope wpwrak updated that one
<wpwrak> ceene: oh, and regarding placement in the current eagle layout: treat any information from there with the utmost suspicion. even the pcb outline is probably wrong. we have a "good" outline, but that's one more item sitting in the nik queue.
<wpwrak> ceene: (v2-location) would be best if you could wait until tomorrow, so that i can update it and clean up some things
<ceene> yeah, of course
<ceene> it's almost midnight here
<ceene> we won't do anything but sleep tonight
<ceene> take the time you need
<DocScrutinizer05> until then just try to place everything on sheet #1 to and incl sheet #20 to LOWER
<wpwrak> ceene: good. i was beginning to worry about your activity hours ;-)
<DocScrutinizer05> yeah, could we agree on some sort of mildly binding schedule for the "meetings" here?
cnj has joined #neo900
<DocScrutinizer05> I.E when to meet next, and when to generally try to meet
cnj is now known as Guest64730
<ceene> well, i'm at the computers most mornings at work :)
<DocScrutinizer05> just tell me when to be here next time
<DocScrutinizer05> I'll make an appointment in my schedule
<ceene> in 12 hours i can be here again unless i really really oversleep :D
<DocScrutinizer05> fine with me, that would be roughly Saturday noon CEST?
<ceene> yes, i think we two share same timezone
<DocScrutinizer05> ok
<DocScrutinizer05> will be here. wpwrak?
<ceene> although i don't know if there's much sense on a meeting tomorrow, at least until wpwrak updates what he'll be updating
<DocScrutinizer05> sounds like a lil late for you
<DocScrutinizer05> wpwrak will just change the representation of what we discussed above. Basically you can use sheet#1-#20 until he updated
<DocScrutinizer05> should be same
<ceene> ok, the list you told me before
<DocScrutinizer05> well, anyway I'm around in 12h
<ceene> i don't know if ahycka will be able to place that tomorrow though
<DocScrutinizer05> yes, what I told before. Sheet #1 through #20 are LOWER
<ceene> well, i'll be here debugging yappari
<DocScrutinizer05> :-)
<ceene> so in any case just ping me
<DocScrutinizer05> yep
<DocScrutinizer05> cya and many thanks
<ceene> i hate that piece of shit with a passion
<DocScrutinizer05> greets to ahycka
<ceene> :D
<ceene> to you too!
Venemo_ has joined #neo900
Venemo_j has quit [Ping timeout: 250 seconds]
tsuggs has joined #neo900
Venemo_ has quit [Quit: IRC for Sailfish 0.9]
Pali has quit [Remote host closed the connection]