<wpwrak>
ceene: please make sure to read the README - there's also a submodule you need to update, and scripted symbols you need to generate. actually, as a shortcut, git clone http://neo900.org/git/ee.git && cd ee && make pull ought to work
<wpwrak>
yup, just checked it
qws-user-1228 has quit [Read error: Connection reset by peer]
qws-user-1228 has joined #neo900
<wpwrak>
(schematics status) still deep in the trenches. current prediction is that we should be able to start schematics review in 1.5-2 weeks, plan a week for review, then another for final cleanup.
<DocScrutinizer51>
yet layout doesn't need to waiy yil schematics are finished
<DocScrutinizer51>
all footprints need checking
<wpwrak>
depends also a bit on how many surprises we encounter. e.g., just yesterday i found out that the HUGE number of subcomponents used in the eagle original doesn't fly with kicad. so we have three components we can't even properly edit in kicad (and they do need some cleaning/fixing). meanwhile, i've restored one to sanity, two more to go ...
<wpwrak>
yes, after the schematics, it's the footprint's turn
<DocScrutinizer51>
why after???
<wpwrak>
well, some components aren't even defined, or have the wrong footprint. so it's best to do that once the set of footprints we actually use has settled.
<wpwrak>
there are a few you can check before, though. things we're 100% sure of already
<DocScrutinizer51>
sorry nope, that's not how development works
<wpwrak>
like the major chips and modules
<DocScrutinizer51>
all footprints of the 90+ percent of components we know we will need can already get checked
<DocScrutinizer51>
I'd even think thats more like 99 percent
<wpwrak>
maybe start with the major ones, modem, wlan, nfc transceiver, display connector, 0402, 0603, 0805, switches, all these are very safe. make a list of what exactly you've checked.
<wpwrak>
there are many others that are "almost certainly" safe, but then, unexpected changes are known to happen :)
<DocScrutinizer51>
so what? worst case we checked a footprint we don't use
<DocScrutinizer51>
this *will* happen. no matter what
<ceene>
by the way, just yesterday we thought of something we don't remember from the schematics
<ceene>
the antennas will be routed in the pcb itself, or are they external components?
<DocScrutinizer51>
ext
<wpwrak>
ceene: they're external, connecting through contact pads on the pcb
<DocScrutinizer51>
or C springs
<ceene>
ok, good
<wpwrak>
ah yes, those C springs. almost forgot about them. did we actually ever select parts for them ? i remember bringing them up a while ago, but i don't think there was ever a clear resolution
<DocScrutinizer51>
there are the original Nokia ones and possibly a half a dozen equivalent types
<DocScrutinizer51>
Nokia cost literally more than gold
<DocScrutinizer51>
but hey it's a sprinh C shaped
<wpwrak>
okay, so you've already selected the equivalent ones ?
<wpwrak>
or will they be custom-made ?
<DocScrutinizer51>
no
<wpwrak>
alright, something to keep in mind then
<DocScrutinizer51>
yes, we need < shaped steel springs of defined size and height and gold plated
<wpwrak>
at digi-key, i found a number of shapes, not all <-shaped (and most of the <-shaped clearly unsuitable)
<wpwrak>
(back when we talked about this, was a few months ago)
<DocScrutinizer51>
the springs are exactly defined by their mechanical properties, we search for a matching type the moment we source them
<wpwrak>
so you expect to be able to exactly predict their footprint ?
<DocScrutinizer51>
yes
<wpwrak>
wow :)
<DocScrutinizer51>
a rectangular single pad of sufficient size, possibly embedded in a eveb alrger arbitrary shape copper fill
<DocScrutinizer51>
even larger*
<DocScrutinizer51>
please keep in mind we plan for proto'v2 now and the springs for sure get manually soldered
<DocScrutinizer51>
on protoV1 we eveb tested a thruhole pad that allows alternative use of very short pogopins
<DocScrutinizer51>
with such pogopins we even could have RF chips on UPPER and pogos protrude through holes in LOWER
<DocScrutinizer51>
in the end, since the electrical properties of a spring are 'wire', the 'command chain' is reversed here, sourcing to layout to schematics
<wpwrak>
so if the sourcing happens in time, no prediction will be needed
<DocScrutinizer51>
tes, the sourcing needs to happen before layout of *final* PCB
<DocScrutinizer51>
until then we will go with original parts and footprints, which are already verified in protoV1
<DocScrutinizer51>
it's exactly same like any arbitrary other chip/component
<wpwrak>
(any other chip) well, not really. we already try to select parts with good availability, which we hope we won't have to change later.
<DocScrutinizer05>
only for those components we pick anew
<DocScrutinizer05>
it doesn't make sense to RE-select componets now, just for their predicted availability
<DocScrutinizer05>
as long as the component we have is still available and not clearly EOL
<DocScrutinizer05>
which isn't the case for those springs. there possibly are 5 dozen alternative compatible types and sources
<wpwrak>
sure, but the springs will be new, no ? you said "Nokia cost literally more than gold". so just using the originals seems undesirable
<wpwrak>
okay, so you already researched that. didn't know this.
<DocScrutinizer05>
[2016-10-01 Sat 18:02:02] <DocScrutinizer51> please keep in mind we plan for proto'v2 now and the springs for sure get manually soldered
<wpwrak>
how about sharing what you found, so we can record this in "ee" ? even if we don't add it to the schematics right now
<DocScrutinizer05>
it's totally irrelevant what I might have found since we got the original Bokia C springs verified, and we won't select alternatives any earlier than proto_v3
<DocScrutinizer05>
untuil then abailability of parts may have changed from whatever I found last week
<DocScrutinizer05>
please note that springs are in the set of mechanically *verified* footprints from proto_v1
<wpwrak>
but you verified the nokia ones, not the one we'll actually use, no ? so the verification is kinda meaningsless. i mean, nokias's originals obviously work
<DocScrutinizer05>
we won't touch that now for proto_v2, for some anticipated pricing and availability we may find when we finally layout production design
<DocScrutinizer05>
exactly!!! Nokias originals obviously work and get used for proto_v2. NO POINT in discussing this now
paulk-collins has joined #neo900
<DocScrutinizer05>
proto_v2 is *not* PV
<DocScrutinizer05>
doing PV optimizations now is wasted effort
<DocScrutinizer05>
that's a very important thing to understand
<DocScrutinizer05>
it doesn't matter if we waste real estate on 8 alternative circuit designs and a 30 DNP 0R, it doesn't matter if we use C-springs that cost more than gold, we check the electrical design and test alternatives for their properties, in proto_v2
<DocScrutinizer05>
optimizations come later, since odds are they will be moot and get discarded anyway, during evalaution process of proto_v2 circuit
<DocScrutinizer05>
we start to worry about sourcing when we know we can't possibly find a matching part lazer on. For the springs I don't see that
<DocScrutinizer05>
later on*
<DocScrutinizer05>
Nokia's C-springs are still widely available (at high but irrelevant pricing), and then there will possibly be other compatible alternatives too
<DocScrutinizer05>
so deciding on the springs is a subject for pre-production PV optimizations, driven by sourcing
<wpwrak>
so the plan is to look for 3rd party spares (a bit like how we're sourcing n900 refurbs these days), not for something that's an active part of a major manufacturer ?
<DocScrutinizer05>
the plan is to not worry about this now
<wpwrak>
;-)
<DocScrutinizer05>
we got other stuff to take care about
<wpwrak>
that we certainly have :)
<DocScrutinizer05>
when you happen to run into a spring that looks compatible to Nokia's C-spring, fine!! otherwise never mind
<DocScrutinizer05>
the goal is to build 10 proto_v2, nothing else so far
<DocScrutinizer05>
and FAST!!
<DocScrutinizer05>
please don't spend percious time on subjects that are not highly relevant for that particular goal
<wpwrak>
my search back then produced the opposite: no C-springs that looked like a reasonable choice, only different shapes that might fit (pending evaluation)
<DocScrutinizer05>
please don't spend percious time on subjects that are not highly relevant for that particular goal
<DocScrutinizer05>
for proto_v2 I'd rather unsolder C-springs from N900 than spending a 30 min searching for alternatives
<DocScrutinizer05>
please keep this in mind *always*! it's really very important for the way to work towards proto_v2
<DocScrutinizer05>
we're running out of time
<DocScrutinizer05>
when we delay start of layout until we decided about stuff like springs, we're walking dead
<DocScrutinizer05>
*no optimizations* until proto_v2 got done
<DocScrutinizer05>
as a general rule of thumb
<DocScrutinizer05>
ceene: I think the project already can undergo complete footprint evaluation and schematics lack only one thing: an estimated number of 2 I2C-IO-extender chips on LOWER. Once those are added (you might do yourself, based on the IO-extender whitepaper), the schematics are fine to start component placing and layout with support by interactive clarification of any questions that may arise - like usual R&D development. Any schematics changes
<DocScrutinizer05>
are not worse than the usual R&D changes that always happen during prototype spins
<DocScrutinizer05>
to elaborate more on the "*no optimizations*" aspect: as long as we can build proto_v2 this way, we won't invest time into considerations related to later prototypes or production
<DocScrutinizer05>
we had that sort of considerations during design already
ob-sed has joined #neo900
galiven__ has joined #neo900
galiven_ has quit [Ping timeout: 244 seconds]
pigeons has quit [Ping timeout: 272 seconds]
pigeons has joined #neo900
pigeons is now known as Guest38420
ravelo has quit [Disconnected by services]
liteIRC_ has joined #neo900
liteIRC_ is now known as ravelo
ravelo is now known as liteIRC___
ravelo has joined #neo900
ravelo has quit [Changing host]
ravelo has joined #neo900
Kabouik has quit [Ping timeout: 244 seconds]
liteIRC___ has quit [Ping timeout: 244 seconds]
liteIRC__ has joined #neo900
ravelo has quit [Disconnected by services]
liteIRC__ is now known as liteIRC___
liteIRC___ is now known as ravelo
Kabouik has joined #neo900
liteIRC_ has joined #neo900
ravelo has quit [Disconnected by services]
liteIRC_ is now known as liteIRC__
liteIRC__ is now known as ravelo
ravelo has quit [Disconnected by services]
liteIRC_ has joined #neo900
liteIRC_ is now known as liteIRC__
liteIRC__ is now known as ravelo
Guest38420 is now known as pigeons
Bratch has quit [Quit: Leaving]
l_bratch has joined #neo900
ashneo76 has joined #neo900
chomwitt has joined #neo900
lolcat^ has left #neo900 [#neo900]
Pali has quit [Remote host closed the connection]
<wpwrak>
DocScrutinizer05: hmm, in antenna connections, on GSM, does it really make sense to have the antenna tuning network before and not after the tap ?
<DocScrutinizer51>
no
<DocScrutinizer51>
well, depends
<DocScrutinizer51>
for cert it's mandatory to hjave the jack close to antenna iirc
<DocScrutinizer51>
you however might define Pi as immanent part of antenna ;)
luke-jr has quit [Excess Flood]
luke-jr has joined #neo900
pagurus` has quit [Ping timeout: 276 seconds]
<DocScrutinizer51>
we want the jack ideally between modem and Pi so we can tune Pi
<DocScrutinizer51>
for cert (and user) you want the jack connect to modem
<wpwrak>
would seem the most natural arrangement. antenna + tuner = generic 50 Ohm. so the 50 Ohm tap should be there. unless you do weird things, which, with RF, is never quite impossible :)
<wpwrak>
so i schedule a swap ?
<DocScrutinizer51>
yep
<wpwrak>
perfect
<DocScrutinizer51>
good finding
<DocScrutinizer51>
Pi is mandatory in closest distance to antenna anyway
jonsger has quit [Ping timeout: 252 seconds]
<wpwrak>
it's been bothering me for a while. but since it's been like this for a long time, i didn't want to upset it. but then, with wlan we have the same situation, and there it really started to trouble me :)
<wpwrak>
besides, TI do it like this (tap near module), too
<wpwrak>
a contribution from the practical joke department of TI: a 1 pF cap. that's a 0R with very low parasitic capacitance, right ? :)
<DocScrutinizer05>
the tap shall be as close as possible to the RF emitting structure, to take into account any loss from feeding impedance matched lines etc
<DocScrutinizer05>
the Pi however is actually part of the antenna
<DocScrutinizer05>
and has to be even closer to the aerial than any tap
<DocScrutinizer05>
simply because you can't design a impedance matched line for the connection between Pi and aerial
<DocScrutinizer05>
you simply don't know the impedance there, it depends on the dimensioning of Pi
<DocScrutinizer05>
so the allowable trace length between Pi and foot point of aerial is virtually zero
<wpwrak>
i guess you still use 50 Ohm parameters, though. at least that's what i did in atben/atusb, and nobody complained (not even eagle-eyed harald :)
<wpwrak>
and yes, the closer the better
<wpwrak>
(at*) well, actually i have the L pretty much on the antenna, too.
<DocScrutinizer05>
nokia has no Pi between FEM/diplexer and antenna
<DocScrutinizer05>
the huge closed can is FEM and friemds
<DocScrutinizer05>
>>For type approval purposes, the use of a 50ï coaxial antenna connector (U.FL-R-SMT) might be necessary. In this case the U.FL-R-SMT connector should be placed as close as possible to PHS8-P/PHS8-Kâs antenna pad.<<
<DocScrutinizer05>
a smert ferrite core and winding design might create a transductor alike variable transformer
<DocScrutinizer05>
smart*
<DocScrutinizer05>
RF amp and antenna coils coupled magnetically via a ferite core that can get gradually locally saturated (increasing volume/area of saturated material) and thus the more saturation, the less antenna winds are coupled to a constant wind number of amp
<DocScrutinizer05>
maybe time to unsolder a can ;-) Just curious