rofl_ has quit [Read error: Connection reset by peer]
rofl_ has joined #neo900
Pali has quit [Remote host closed the connection]
l_bratch has joined #neo900
knttl has quit [Ping timeout: 240 seconds]
knttl has joined #neo900
infobot has joined #neo900
<houkime>
U1902, C1903 are connected to 1v8 instead of 1v8_u
<Joerg-Neo900>
right, and R1904 is totally misplaced and dangling
pagurus` has joined #neo900
<Joerg-Neo900>
error
<Joerg-Neo900>
can you work around this for now without editing schematics?
pagurus has quit [Ping timeout: 240 seconds]
<houkime>
compared to changes there already were introduced by kicad5 remapping it doesn't really seems like much
<houkime>
my branch is already quite unmergeable
<Joerg-Neo900>
hmm
<houkime>
good thing it is really nothing to merge it into
<houkime>
it is latest and brightest and nobody have done anything in parallel
<Joerg-Neo900>
anyway discard R1904, change 1V9 to 1V8_U
<houkime>
what about grounds being messed up and audio ground connecting to a normal lower ground without any formal interface?
<Joerg-Neo900>
ph shit, there's more buggy in there
<houkime>
i believe some of them were fixed in my branch as i got things going into netlist nicely and have appropriate fps and pins
<houkime>
was a butthurt at the start
<Joerg-Neo900>
grounds messed up? wouldn't know how. And we have no separate audio ground, I elaborated on that a few days ago already
<houkime>
well if they are not meant to be separated then why there is an aground in audio sch?
<houkime>
which shorts to a normal ground only in one single place
<Joerg-Neo900>
we should use a star topology for grounds. with audio groind connecting to geberic ground exactly where it's noted, and running a audio GND in parallel to signal lines
<houkime>
ok. probably needs a comment in sch on that.
<houkime>
GND2 messed up like 1v8. Although it is a BoB ground, some semnsors on UPPER use ir
<houkime>
*it
<houkime>
U902
<houkime>
and U901
<Joerg-Neo900>
that sucks
<houkime>
Also both upper and LOWER have a common ground which is "hb_audio_ground"
<houkime>
well, netlist calls it that at least
<houkime>
do you have kicad5 now?
<Joerg-Neo900>
no, not yet, still about to update my system
<Joerg-Neo900>
was planned for yesterday but yesterday was day off from the disaster that was last week
<houkime>
Grounds on LOWER and UPPER got merged together because they both used just a GND to denote ground.
<houkime>
r1904 is not dangling
<houkime>
the "dangling" wire actually teleports to "cabc" which is a local wire connected to cabc pin 22 of display connector on the same sheet
<houkime>
ok, pushed 2 commits with point sch fixes for 1v8 and sensor grounds
<houkime>
separating ground of UPPER from ground of LOWER though will take some effort. Not critical right now.
<Joerg-Neo900>
not going to pester you with trivialities, but if you got spare capacity in your mind, please try to keep "loop area" (aka distance between forward and return traces) of high current paths for backlight LED as small as possible, to avoid magnetic error introduced to compass sensor
<houkime>
ok
<Joerg-Neo900>
we probably could calibrate out a lot of such error in software (compass driver) as long as we know the error amount aka LED brightness, but avoiding errors is better than compensating them
<Joerg-Neo900>
in the end our compass can't be worse than that of e.g. Cat S60 ;-)
<Joerg-Neo900>
that thing is unbearably pointless
<Joerg-Neo900>
you can calibrate it but that only holds for an hour or two
<Joerg-Neo900>
prolly until next charging where high currents nuke all calibration of magnetic properties
<Joerg-Neo900>
to give you an idea: a 10° rotation of device may make the map rotate all way top-down 180°
<houkime>
what should be the model of D2? It has a different model on your paste
<houkime>
*from D1
<Joerg-Neo900>
D2 is a zener, something generic
<Joerg-Neo900>
datasheet for example recomends OnSemi MMSZ4711
<houkime>
does it have some unique properties or sth? We don't use stuff like that enywhere else.
_Chris_ has joined #neo900
<houkime>
we don't have fp for SOD-123
<houkime>
should I make one or you find more viable part?
__Chris has quit [Ping timeout: 276 seconds]
<Joerg-Neo900>
it seems it has no special properties, so any small Zener with a convenient voltage range will do
<houkime>
right now i just copied the thing we used for D1. relatively small
illwieckz has quit [Read error: Connection reset by peer]
<Joerg-Neo900>
I first thought it needs to be quite some power part, but actually no, it only needs to provide enough current to drive the FB hig against the load of R2 and R1
<Joerg-Neo900>
good
<Joerg-Neo900>
with R2 in place, the Zener can't consume more than a few mA
<Joerg-Neo900>
the parasitic capacitance of trace on joint L1901 D1901 shall be as low as possible, and the "loop" forming a coil made from D1901 C1904 shall have minimum area, this results in all those components as close to chip as possible
<Joerg-Neo900>
C1904 needs to be a low-ESR high frequency high current and low loss type
<Joerg-Neo900>
D1901 needs to be a fast rectifier with low parasitic capacitance, so schottky
<Joerg-Neo900>
line capacitance 110pF (vs 7pF of the former) but in most places this doesn't matter at all
<Joerg-Neo900>
then it has 30kV (vs 15) and 110W/11A (vs 50?W/3A)
<Joerg-Neo900>
and WAAAY better (lower) clamp voltage
<Joerg-Neo900>
plus "new component, on stock" vs "factory lead time"
<Joerg-Neo900>
we'll pick the best we can get (0201) when it comes to production
<houkime>
what is bme-replacement you were talking about recently?
<Joerg-Neo900>
a FOSS driver for battery management in N900, not really needed at all in Neo900 since we got a way smarter charger chip
<Joerg-Neo900>
Neo900 charging sort of works without any driver
<Joerg-Neo900>
N900 can only do emergency bootstrap charging to bring up the CPU, then it needs a driver to charge batery to 100%
<Joerg-Neo900>
Neo900 charger is fully autonomous though still controllable via software
<Joerg-Neo900>
in N900 maemo fremantle, BME is a closed blob Nokia didn't dare to open-source due to liability reasons when devices / batteries would catch fire
<Joerg-Neo900>
and BME replacement is a FOSS driver replacing BME blobs, made by Pali based on my specs
<Joerg-Neo900>
though not 100%, which is a tad of a pity since it has issues where it deviates from my specs ;-)
<houkime>
and what is exactly the reason which makes N900 compatibility require outdated fuel gauge?
<houkime>
(which is a huge thing btw)
<Joerg-Neo900>
exactly this BME thing
<Joerg-Neo900>
BME is a closed blob and communicates with bq27200 directly via I2C
<Joerg-Neo900>
and bme-replacement needs a new kernel, so it won't work for 100% compatibility
<Joerg-Neo900>
there are alos a number of apps (all sorts of battery monitors) that rely on bq27200
<Joerg-Neo900>
also*
<houkime>
How much sensible to the placement are fuel gauges? They are not high current, right, so thin (and maybe long) probing trace is ok?
<Joerg-Neo900>
actually nobody can know for sure what in N900 depends on bq27200, we *hope* we found all dependencies but we can't guarantee that
<Joerg-Neo900>
totally uncritical
<Joerg-Neo900>
yesm long parallel /differential pair) traces from chip to 10mR shunt resistor are OK
<Joerg-Neo900>
except for those fule gauges that have internal shunt, of course
<Joerg-Neo900>
some do, I don't know if we already decided on a particular type and if it has internal shunt or not
<Joerg-Neo900>
aaah BQ27421YZFR-G1A (4V2)
<Joerg-Neo900>
>> Low-Value Integrated Sense Resistor The bq27421-G1 fuel gauge uses the patented (7 mΩ, Typical)<<
<Joerg-Neo900>
oops s/The bq27421-G1 fuel gauge uses the patented//
<Joerg-Neo900>
so the above comment about differential pair to shunt only applies to the bq27200
<houkime>
ok.
chomwitt has quit [Quit: WeeChat 1.0.1]
<Joerg-Neo900>
akso bq27200 probes low side (GND) while bq27421 is high side (Vbat)
<Joerg-Neo900>
R306 is DNP shunt for an alternative chip to bq27421
<houkime>
there's one more question i have about powertree.
<Joerg-Neo900>
shoot
<houkime>
v2.pdf says that 1v8 and 2v7 in v2 are formed from vsys with LDO
<Joerg-Neo900>
yes
<houkime>
however i couldn't find these
<Joerg-Neo900>
umm
<houkime>
check with eeshow (it has net tracking)
<Joerg-Neo900>
"Adaption (v2 only)"
<Joerg-Neo900>
U2201, U2202
<Joerg-Neo900>
obviously move those out of "inside case" area of UPPER
<houkime>
ok. So we move whole high-current VSYS to UPPER and then redistribute it from there?
<Joerg-Neo900>
also for cooling reasons
<Joerg-Neo900>
what is "whole high-current VSYS"?
<Joerg-Neo900>
in final device VSYS (and the orther volatges) will come from TPS65950 companion chip
<Joerg-Neo900>
also on UPPER
<Joerg-Neo900>
next to SoC
<Joerg-Neo900>
basically all sheet 22 is about simulating TPS65950
<houkime>
hm. ok.
<Joerg-Neo900>
not happy?
<Joerg-Neo900>
WAAAAH!!!! check C2202!
<Joerg-Neo900>
what eeshow woefully lacks is a generic search function
<Joerg-Neo900>
and a view history, so you could move back and forth in your own panning/jumping/zooming history
<Joerg-Neo900>
e.g. with cursor-left (back) and -right (fwd)
<Joerg-Neo900>
and a highlighted offsheet symbol shouldn't get instantly unhighlighted when you accidentally move cursor over another symbol
<Joerg-Neo900>
there's ESC for unhighlighting
<Joerg-Neo900>
wpwrak: ^^^
<houkime>
it just doesn't seem logical to move high current cross boards, split with LDO's and then reverse-transfer it back. maybe there were reasons though.
<Joerg-Neo900>
http://susepaste.org/37014761**BUG** C2202 must not go to U2204:3(OUT), instead must go to U2204:4(VDD)
<Joerg-Neo900>
the reason is: battery is on LOWER, SoC and TPS65950/TWL4030 is on UPPER
<Joerg-Neo900>
if we would place TWL on LOWER, we would have unacceptanly many and long wires to CPU/SoC. If we place SoC and TWL on LOWER (if there was even space for that) then we had display and whatnot on the B2B conns
<Joerg-Neo900>
we mused about component distribution between LOWER and UPPER quite a while, and this is what we came up with. I'm not saying it's the optimal solution, just the best we could find
<Joerg-Neo900>
suggestions welcome
<Joerg-Neo900>
in the end we need all voltage railes on LOWER *and* UPPER, so it doesn't make much of a difference
<Joerg-Neo900>
the only tail we could "save" would maybe VBAT
<Joerg-Neo900>
rail*
<Joerg-Neo900>
and it seems more uncritical to route VBAT from LOWER to UPPER than several of the other SoC supplies
<Joerg-Neo900>
actually VBAT is neither stanilized nor filtered or whatever, so a pretty uncritical "signal" to route to wherever it's most convenient to place the sink
<Joerg-Neo900>
it's just a pity that we have a large magnetic loop this way, for VBAT current to interfere with compass
<Joerg-Neo900>
we should take some care so GND return path is as parallel to VBAT as possible
<houkime>
what is a summary 1v8 current consumption per board?
<Joerg-Neo900>
sorry, can't tell offhand, prolly up to 2A
<houkime>
do you have docs on that for v2?
<Joerg-Neo900>
we did an estimation but I have no idea where that documet left
<Joerg-Neo900>
why do you need to know?
<houkime>
track widths and connnector pins/vias numbers rechecking
<Joerg-Neo900>
we did a proper evaluation to determine the number of pins we need on B2B conns for VBAT
<Joerg-Neo900>
etc
<Joerg-Neo900>
for tracj widths please use a safe approach and overdimension at least factor 3
<Joerg-Neo900>
we need low ripple on VBAT for modem anyway
<Joerg-Neo900>
and we don't want much loss on VBAT->TWL
<Joerg-Neo900>
I'd think we get a whole layer/plane for 1V8 anyway, no?
<Joerg-Neo900>
rather add a layer than fiddling with too narrow supply rail tracks
<Joerg-Neo900>
and 1V8 is needed virtually everywhere
<Joerg-Neo900>
sorry, afk
<Joerg-Neo900>
bbl
<houkime>
I'm just a little bit worried whether 1 1v8 pin on b2b is enough
<Joerg-Neo900>
no big consumers on LOWER
<Joerg-Neo900>
if you find a spare pin, add it
<houkime>
ok
<Joerg-Neo900>
one of the nicer parts in this design is: all huge consumers are supposed to run off VBAT_SW
<Joerg-Neo900>
well, except core digital system, like RAM etc
<Joerg-Neo900>
so: audio amp, vibrator etc pp
<Joerg-Neo900>
backlight
<Joerg-Neo900>
and removing battery should immediately shut down BAU_SW so all buffer capacitor energy is left for the core digital system to do emergency shutdown
<Joerg-Neo900>
s/BAU/BAT/
<Joerg-Neo900>
originally it was even planned to allow battery hotswap and run the system from buffer caps for almost a second during that. Doesn't fly and not needed anymore since we can do suspend2ram now
<Joerg-Neo900>
even suspend2disk
<Joerg-Neo900>
"doesn't fly" means we can't cram in the needed amount of buffer capacitors
<Joerg-Neo900>
we'd need at least a 50 to 100mJ, too much volume
<Joerg-Neo900>
unless we'd use a tiny battery, and then we can't draw sufficient current from that
<Joerg-Neo900>
capacitor would be like 50,000uF@3V
<Joerg-Neo900>
wait no, more like 10,000
chomwitt has joined #neo900
illwieckz has quit [Quit: Ça va couper chérie…]
illwieckz has joined #neo900
<houkime>
pushed a fix for C2202
<houkime>
i will probably open a quick repo on notabug or anywhere to keep track on layout issues and allow you and other not to scroll down chanlogs to assess everything.
<houkime>
no files, just a bare thing with issue tracker.
illwieckz has quit [Ping timeout: 248 seconds]
<houkime>
it also makes possible for people to subscribe to layout updates even if they can't have the files yet.
<Joerg-Neo900>
werber created a "pastebin" alike thing to simply upload stuff to temp there
<Joerg-Neo900>
werner*
illwieckz has joined #neo900
jonsger1 has joined #neo900
<Joerg-Neo900>
thanks for fixing C2202
jonsger has quit [Ping timeout: 255 seconds]
jonsger1 is now known as jonsger
<houkime>
If we're going to use goldelico issue tracker it should be sanitized first - so someone should look at each issue and update or close it.
<houkime>
btw neo900.org does not have any clear link to this issue tracker
<houkime>
subscription to issues is one of the easiest ways to get a pulse of a project, I use it pretty much to track any interesting stuff.
<houkime>
alsogoldelico issue tracker doesn't seem to allow subscription.
<houkime>
Too bad. Would be easier to a make a new one really.
<houkime>
And then make links for it and for Neo900-Planning repo right at the neo900.org frontpage
<houkime>
IRC link should be right after "Support the project and reserve a device for you now!"
<houkime>
together with "we need your help" catchphrase
<houkime>
and planning repo and issue tracker (which could be actually merged into one thing) should go to the top bar at the center
<houkime>
"resources" should be at least bold and probably renamed to "Sources&docs"
<houkime>
and even better "CAD sources&docs"
<houkime>
in whole, site now emphasizes money for some reason, even though money is not the thing we need the most right now.
illwieckz has quit [Ping timeout: 264 seconds]
<houkime>
I guess "site is not looking like a community page." is the right way to put it, altho open Phoenux poses itself like a community.
illwieckz has joined #neo900
<Joerg-Neo900>
you're welcome to improve all this
<atk>
houkime: if you want you can change the website and email me a PR
illwieckz has quit [Ping timeout: 255 seconds]
illwieckz_ has joined #neo900
illwieckz_ is now known as illwieckz
<atk>
And I'll have a look at the changes and maybe editorialise a bit, make sure nothing will break and make sure Joerg-Neo900 is fine with the changes and push them to the actual website
<houkime>
ok
paulk-gagarine-s has joined #neo900
paulk-gagarine has quit [Ping timeout: 260 seconds]
paulk-gagarine-s has quit [Remote host closed the connection]