<DocScrutinizer05>
NeoNDOWN PAYMENT NeoN bare board-48
<DocScrutinizer05>
+1EURDown Payment top up-5079
<norly>
161, not bad. 1/3 there.
<norly>
keep up the good work!
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
ta
<DocScrutinizer05>
2/3 to go, ideally during next 4 weeks
<norly>
let's make the shop official and slashdot/hn it again...?
<DocScrutinizer05>
it *is* official :-)
<DocScrutinizer05>
feel free to "bump" it on /. - though I guess that doesn't bring many new customers, only many new rants
<norly>
oh it is now
<norly>
nah, i guess hn is a better audience
<DocScrutinizer05>
we survived first /. impact, we should survive a 2nd one too
<norly>
/. has become the internet's flaming hell
<DocScrutinizer05>
yep
<DocScrutinizer05>
troll's paradise
<norly>
why feed the trolls
<DocScrutinizer05>
anyway spread the word, ideally with a smart comment about the nature of this project, and that it's dedicatedly NOT for those who compare it to $crapPhone
<DocScrutinizer05>
"CHEEES-US! 30 kBucks for this 50 year old VW? Are you _serious_? It not even has a computer in the engine control!"
useretail has joined #neo900
<DocScrutinizer05>
"sucker. that's the whole point about it!"
<norly>
yep
<DocScrutinizer05>
this device is NOT about up-to-date specs
<DocScrutinizer05>
it's NOT about octo-core
<DocScrutinizer05>
and we *love* our rsistive touchscreen
<DocScrutinizer05>
heck, even my techopgobic GF loves the r-ts
<DocScrutinizer05>
she's pushing me to finish the Neo900 since she can't wait to get rid of her samsung galaxy
<DocScrutinizer05>
and she doesn't know shit about privacy issues or what's "Android"
<DocScrutinizer05>
she just loves the hw kbd
<DocScrutinizer05>
and the touchscreen
<Oksana>
;-)
<Oksana>
What's the resolution of resistive touchscreen? It's higher than resolution of LCD display, but I don't remember exact numbers...
* Oksana
is fairly sure that resolution of capacitive touchscreen lags behind resolution of LCD display, in modern phones...
<DocScrutinizer05>
Oksana: it depends on chip, the technology of the touchplabne is analog and thus the "resulution" is determined by the precision of the analog voltage it provides for a touch event
<DocScrutinizer05>
c-ts resolution is around 100*50, by principle of operation
<norly>
DocScrutinizer05: 2015 - the year of the N900 phone for everyone
<DocScrutinizer05>
in theory they could do better, but only with hard core calibration
<DocScrutinizer05>
lemme try to find that URL for you
<norly>
i just can't understand how those modern devices can't get simple things right, such as unified calls/texts for all protocols
<norly>
n900 was a really good ui experiment. far from done, but already way better than what i've seen e.g. on android
<Oksana>
Yes :-)
<norly>
i'm actually stuck with a phone with a numpad currently. a feature phone is that much better
<Oksana>
It still gets fairly confusing when I am experimenting with "let's jump between SIP and cellular phone", especially with SIP being used for telephone calls (both incoming and outcoming) to avoid International Roaming
* Oksana
sleepily complains that Firefox on desktop is sluggish even with text browsing... Without adding images or videos into the mix... To be fair, I don't know whether I have 1k tabs or 1 million tabs...
<norly>
yeah, the dialer defaults to cellular :/
<Oksana>
In dialer, you can choose SIP calling. That's already great :-)
<Oksana>
Though, I would like it if it didn't default to cellular when there is no SIM card inserted. But, I didn't test it - maybe, it's already smart enough.
<DocScrutinizer05>
Oksana: alas not. I pushed for a dbus hook to choose/switch the default service. to intercept calls in dialer and pipe them through a least cost router that decides according to a scriptable ruleset which service (SIP, cellular, jabber, younameit) to use
<ZetaR>
DocScrutinizer05: Is there any good way for me to submit a patch or something against the schematic on the BT so that it reduces the workload of the person incorporating approved changes?
<DocScrutinizer05>
the Nokia folks were not interested, the sofiasip folks mildly but they thought I violated their layering (always my problem)
<Oksana>
So, reverse-engineering the dialer would be "the best way"? ;-)
<DocScrutinizer05>
ZetaR: atm not, since the schematics publushed are vastly outdated and work in progress anyway
<DocScrutinizer05>
pkyes
<DocScrutinizer05>
Oksana: yes
<DocScrutinizer05>
I had a plan to break the dbus link to dialer and sneak in an interceptor dualheaded sevice that bridges between the dbus the dialer uses and the general system/session dbus, and filters/rewrites calls to/from dialer
<DocScrutinizer05>
should work but is very convoluted
<ZetaR>
((schematic)) When people say "its a work in progress", I am not sure what that means w.r.t. suggested changes. If part of the schematic indicates a certain chip is used, and it will probably be used in the final product, then isn't information on applying that chip incorporated at this point?
<DocScrutinizer05>
another very dirty method is to tear down a call *immediately* after user placed it, and then re-initiate it, possibly with a preselection for service to use
<DocScrutinizer05>
ZetaR: that depends. Some chips will not be used since we found better ones already
* Oksana
is currently wondering how to incorporate into Fremantle's "Internet Connections" a proxy-detecting-piece which, when user connects to unsecure WiFi, auto-checks if there is a portal page, and if there is one, auto-simplifies it into a GTK dialogue, asks user to fill it in, submits it, and only when portal page has "gone away", tells the whole system that Internet is here
<DocScrutinizer05>
so instead of posting a BT ticket you rather discuss it with me
<ZetaR>
Well, what about a more extensive block of information?
<DocScrutinizer05>
Oksana: sounds mad useful
<DocScrutinizer05>
ZetaR: sorry? please elaborate
<ZetaR>
I am in the process of doing a more extensive literature search on the application of capacitors, but I have a pretty good idea of determining cap needs and I can make a list of changes. I was wondering what the best way is to propose this without creating much work for the devs.
<ZetaR>
Also, you say that it is outdated, but I have not been able to find current schematics or Eagle files.
<DocScrutinizer05>
ZetaR: the buffer caps worked so far, and they are not deterimed yet for the final design. So I don't know how to add info that would simplify our work in that regard
<DocScrutinizer05>
we won't optimize capacitors in a way we would use a 47nF instead of a 100nF
<ZetaR>
With 10nF caps you can use 0201 packages.
<DocScrutinizer05>
we even will rather place 2 100nF in parallel rather than use one 220nF
<ZetaR>
It should make routing and frequency response a lot better.
<DocScrutinizer05>
we're not going to use 10nF for buffers when even the chip manuf in application note says "100nF or greater"
<ZetaR>
You need 10nF and something larger, but the larger one doesn't need to be right next to it.
<DocScrutinizer05>
we know thiose aspects
<ZetaR>
10nF is enough for the latching event, larger one takes care of the fundamental frequency.
<DocScrutinizer05>
I'm designing circuits since almost 40 years
<ZetaR>
Well, yes, I just thought that I could make things easier by doing this calculation.
<DocScrutinizer05>
no, it's comlicating things. It#s an optimization that's not really applicable/useful for a 500 units
<DocScrutinizer05>
you might calculate all particular power rail hot spots and point us to exceptionally critical ones. That would help for sure
<ZetaR>
Maybe I haven't explained what I am doing very well... I was going to propose standardizing decoupling around 2-3 values, and the calculation tells you when specific ones are appropriate for which IC.
Oksana has quit [Ping timeout: 246 seconds]
<DocScrutinizer05>
we are already doing this, and we simply err on the huge side
<ZetaR>
i.e. chip A can be served by 10nF within X distance and 100nF within Y distance, chip B requires more than 100nF.
<ZetaR>
I was as well, the calc I posted was just to give myself a rough idea of the values needed.
<ZetaR>
Those were for switching events under typical conditions.
Oksana has joined #neo900
<ZetaR>
I have also looked at what caps are availible: largest common 0201 is 10nF, largest common 0402 is 220nF, largest common 0603 is around 1 to 4.7 uF.
<DocScrutinizer05>
our fab has own sourcing and we tend to use what they offer
<ZetaR>
To see what sort of range of values you might end up using.
<DocScrutinizer05>
it's *way* cheaper
<ZetaR>
Oh, okay. But they should have similar constraints right?
<DocScrutinizer05>
we'll see
<ZetaR>
So, is it useful for me to calculate what chips can use a 10nF 0201? I was thinking that this would make routing easier (as well as frequency response better).
<DocScrutinizer05>
Nikloaus knows that, but he wouldn't want to elaborate it in epic length on public about it since that's not productive. Please don't take offense in that
<DocScrutinizer05>
no, I told you we won't use 10nF buffers
<ZetaR>
Okay, I thought that was in the context of thinking I was proposing using them without a more flexibly placed secondary buffer.
<DocScrutinizer05>
generally we got ground plane design that already provides a certain amount of low capacity high frequency low ESR buffering immanently by design
<DocScrutinizer05>
the whole PCB is one huge capacitor
<ZetaR>
So it is something like ~0.2 mm separation between ground and V+.
<DocScrutinizer05>
yes
<DocScrutinizer05>
rather less
norly has quit [Quit: Leaving.]
<DocScrutinizer05>
we got a 8-layer on 0.8mm
<DocScrutinizer05>
so separation/FR layers are <0.1
<ZetaR>
Awesome. I have read in several places about the EMI problems of <8 layers.
<DocScrutinizer05>
whatever you've read, we got GTA04 to work. Stable
<ZetaR>
Well, yes, but there are also security considerations to emmisions, not just stability.
<DocScrutinizer05>
I don't see the EMI problem with an 8-layer that has planes on the outside#
<ZetaR>
So, what would be helpful for me to do at this point?
<DocScrutinizer05>
maybe review our NFC whitepaper and check if the design in there has any bugs?
<DocScrutinizer05>
*that* would help a lot
<DocScrutinizer05>
it's all new and we have no prototypes of it yet
<ZetaR>
Okay. I meant specifically about the caps, since I have been working on that, and I guess most of it would not be used then.
<ZetaR>
I will put it on my todo list to look at next.
<DocScrutinizer05>
I told you the only useful thing I see is to spot hotspots and tell us about them so we can have a closer look
ccnnjj has left #neo900 [#neo900]
<ZetaR>
What about the issue of antiresonance from parallel caps?
<ZetaR>
Specifically, ones of different values.
ccnnjj has joined #neo900
<DocScrutinizer05>
I already told you we're trying to use one value only
<ZetaR>
Okay, so I guess the schematic is just not reflective of what you intend?
<ZetaR>
(I am not trying to make you repeat yourself, just trying to make sure I understand when getting conflicting information)
<DocScrutinizer05>
I already told you it's work in progress and especially the buffer caps depend on leyout and get chosen according to layout very late in design/routing/layout
Humpelst1lzchen has quit [Ping timeout: 264 seconds]
Humpelstilzchen has joined #neo900
<ZetaR>
Okay, so what should I do in general when seeing something on e.g. the schematic that looks like it would be problematic?
<ZetaR>
e.g. for the audio there is a split ground plane.
<DocScrutinizer05>
ask me about that paricular issue
<ZetaR>
Okay. I will do that then. Just trying to get an idea of how best to collaborate on these things.
<ZetaR>
Well, I mentioned the split ground plane. Is that something that is changed/will be changed? It is putting an impedance on the return path for I2C.
<DocScrutinizer05>
sorry, I don't understand
<ZetaR>
So on sheet 10 there is AGND, which is coupled to GND via an inductor.
<ZetaR>
And the headset IC and Mic switch IC are on AGND.
<ZetaR>
But these ICs receive digital signals. The return path is through that inductor, which is going to couple digital noise to the audio.
<DocScrutinizer05>
if they have no AGND and separate DGND, that's a bug
<ZetaR>
Yeah, its all to AGND.
<DocScrutinizer05>
noted
<ZetaR>
So you have a current WIP schematic? Could I get a copy of it so my comments are more current?
<ZetaR>
AFK for a bit. Thanks for explaining things to me Doc.
<DocScrutinizer05>
((current WIP schematic)) ^^^ is as good as it gets. We cannot integrate external reviews into primary workflow, for organizational reasons
<DocScrutinizer05>
there's only a limited amount of email traffic an EE can process per day when (s)he wants to get real work accomplished as well
<DocScrutinizer05>
so even we internally revert to spreadsheets like ^^^
<DocScrutinizer05>
s/revert/resort/
XDS2010 has quit [Ping timeout: 272 seconds]
PeperPots_ has quit [Read error: Connection reset by peer]
XDS2010 has joined #neo900
PeperPots_ has joined #neo900
arossdotme has quit [Ping timeout: 276 seconds]
arossdotme has joined #neo900
Oksana has quit [Read error: Connection reset by peer]
Oksana has joined #neo900
<wpwrak>
jake42: thanks :) (especially for praising the "concise" :)
<wpwrak>
the usage experience of our shop seems to be a bit like napoleon's march on moscow [1]. there's a lot of people at the beginning, but at each step of the way you lose a few
<wpwrak>
so there will be a bit of shepherding to do for all those who are wandering about somewhere in the middle, or whom we didn't even reach yet. the newsletter already produced a few interesting responses.
<ZetaR>
I really hope that trying to get orders for the Neo900 isn't going to end up like Napoleon in Russia.
<wpwrak>
hehe ;-) naw, we can try to learn from history :)
<ZetaR>
Lesson learned: Do not invade Russia. =)
<ZetaR>
Especially now that they have nuclear weapons. You will get both hot AND cold!
<wpwrak>
by the way, if you find a mismatch of components in block diagram and schematics, then the block diagram is usually right, and the changes just haven't been incorporated into the schematic yet
<ZetaR>
wpwrak: Most of what I was looking at was low-level stuff that wouldn't be on the block diagram.
<wpwrak>
why spend valuable nukes if you have winter for free every year ? :)
<wpwrak>
yes, just in case you bump into a mismatch of one of the bigger things
<ZetaR>
Well, its not like they have a shortage of them.
<ZetaR>
Whats a few nukes here and a few there, you might not even notice a difference in the stockpiles.
<ZetaR>
DocScrutinizer05: I have finished re-reading the NFC paper (with more attention to detail this time).
<ZetaR>
There is at least one major problem.
<wpwrak>
i guess differences in stockpile would not get noticed in most cases anyway ;-)
* wpwrak
is listening :)
<ZetaR>
On page 18 the meanings of Vih, Voh, Vil, and Vol have been misinterpreted.
<ZetaR>
And this has lead to flawed assumptions in the following sections.
<ZetaR>
Vih means the voltage where the receiver must register it as high. Voh means the voltage that the receiver must output as high.
<ZetaR>
This is in case there are voltage drops across the transmission line... which is exactly what the following pages puts on the transmission line.
<wpwrak>
did you notice the last paragraph of section 6.1 ? some of the interpretations should be overly conservative as a result
<ZetaR>
Also, I suspect that the absolute and relative voltages are referring to the kind of device you have. A device with a relative output voltage sounds like one that does not have an internal regulator, so its outputs are determined by the characteristics of the transistors. The ones with absolute output voltage probably have an internal regulator to guarantee a specific voltage (and this looks like it may be reflected in increased powe
<ZetaR>
Let me look at it.
<ZetaR>
I'm not sure what you mean. Let me give an example of a flawed equation.
<wpwrak>
(abs/rel) it's how the standards define the voltages. i some cases they say "XX V", in other cases they say "X times Vcc"
<ZetaR>
For example, on the bottom of page 21 those equations should be:
<ZetaR>
Rshunt << (Voh - Vih)/(1000uA - Icmp)
<ZetaR>
Rshunt << (Vil - Vol)/(20uA - Icmp)
<ZetaR>
I haven't looked at whether the equations given would actually fulfill those conditions though.
<ZetaR>
Lets see...
<wpwrak>
there does seem to be a typo, though: 1.53 vs. 1.57
<ZetaR>
Rshunt << 270 = (1.40-1.13)/0.001
<ZetaR>
Assuming Icmp is negligible.
<wpwrak>
(Vi vs. Vo) also, the standard specifically talks about the card there. not the other end of the interface (or anything in between)
<ZetaR>
As an example.
<wpwrak>
Icmp is on page 43. and yes, negligible in this case
<ZetaR>
I haven't read the standard document yet, but that is the usage of Vih Voh Vil Vol (haven't seen a different usage, though I am not an EE).
<wpwrak>
yes yes, i know how it is normally used. the thing is that the normal use doesn't make sense in this case :)
<ZetaR>
Okay, let me see if I can pull up that doc then.
<wpwrak>
i think they just copied that table from other parts of the card specification, where "normal" rules do apply
<wpwrak>
i.e., there's the regular SIM interface, used by the modem, and there's SWP, used for NFC (etc.)
<wpwrak>
and the regular SIM interface does everything in the usual way. so there it makes perfect sense to specify Vi and Vo that way
<wpwrak>
but SWP has that current signaling, so the concept of Vo gets weird, since we should be talking about current here, not voltage
<ZetaR>
Hmm, but one end signals a V1>Voh and one end receives it V2>Vih.
<ZetaR>
Then it sends back by modulating Voh current.
<ZetaR>
Right?
<ZetaR>
Or am I misunderstanding things.
<wpwrak>
the thing is that this specifies only the card end
<ZetaR>
That doesn't seem strange. The card expects the sender to output a voltage greater than Voh, but will treat anything greater than Vih as high.
<wpwrak>
one could read it as a recommendation for what the other end should do, but it's not really expressed as such
<wpwrak>
yes, but then it still doesn't have to specify a Voh value ;-)
<ZetaR>
But if you want to know the design constraints of the wire you need to know both Voh and Vih.
<wpwrak>
yes, but that's outside the scope of the specification
<ZetaR>
Vdrop << Voh - Vih preferably
<wpwrak>
the specification talks about the card interface. how you get there is not relevant (as far as the standard is concerned)
<ZetaR>
I see. I guess its a case of "specification should have clarified about Voh".
<wpwrak>
so yes, if this was the specification of the whole system (like sections 6 and 8 of our NFC document), _then_ you need both
<ZetaR>
But I don't see why that means that Voh is actually interpreted differently.
<ZetaR>
I mean for the NFC paper.
arossdotme has quit [Ping timeout: 276 seconds]
<ZetaR>
I also have concerns about the comparator being sensitive to outside conditions due to making reference only to one side of Rshunt.
<ZetaR>
Putting an op-amp first that compares each side of Rshunt may be more reliable w.r.t. noise and voltage fluctuations.
<ZetaR>
And ensuring a nonzero hysteresis would also add some noise immunity.
<wpwrak>
in the circuit on page 44, the internal DAC reference and the bias voltage (i.e., "high") come from the same source. so i'd hope they don't fluctuate too much with respect to each other
<ZetaR>
Digital noise created by the sender and receiver themselves may cause enough unpredictibility for it to be unreliable.
<ZetaR>
Common impedance noise.
<ZetaR>
At the V+/GND pins, that is.
<ZetaR>
It might be hard to predict how bad that noise could be.
<wpwrak>
and there is a hysteresis in the comparator. it's even configurable. but that if we're mainly interested in levels, not edges, that shouldn't actually matter. it's still not to not have unnecessary switching, of course
<ZetaR>
Well, I was commenting on the statement in the p21 table that Vh could be zero.
<ZetaR>
I guess it technically could be zero, but IDK if it would be a good idea.
<wpwrak>
(hysteresis) ah, i see
<wpwrak>
that's about data from the comparator's specification
<wpwrak>
so if it's specified with zero hysteresis, so be it :)
<ZetaR>
I guess so. I think it is because it is not clear whether the comment is recommending something or not.
<ZetaR>
I mean, I was commenting because it is not clear.
<wpwrak>
yes, lemme think of a better way to say this
arossdotme has joined #neo900
<wpwrak>
by the way, i fixed the 1.57 V typo. now Rshunt can be <= 220 Ohm (up from 180) :) thanks !
<ZetaR>
Okay, but I did say Rshunt << 220 Ohm (you probably don't want to get really close to the limit!)
<ZetaR>
And that was an example too.
<ZetaR>
I just picked a couple of voltages actually, to name an example value.
<ZetaR>
Should be Rshunt << (Voh - Vih)/(1000uA - Icmp)
<ZetaR>
and Rshunt << (Vil - Vol)/(20uA - Icmp)
<ZetaR>
Hmm, also there is another condition... Lets see.
<ZetaR>
Rshunt needs to be low enough that Voh can supply the required current.
<wpwrak>
(Rshunt) with the KL16/26, I get 36.2 Ohm <= Rshunt <= 220 Ohm. no a huge range, but that's what we have. i suggest using a 150 Ohm resistor.
<wpwrak>
(page 43, after fixing the 1.57 V)
<ZetaR>
Hmm, that just seems really big for a current sense resistor.
<wpwrak>
well, it's small currents :)
<ZetaR>
Lets see: Rshunt << Voh/1000uA
<ZetaR>
Though, this should already be met by Rshunt << (Voh - Vih)/(1000uA - Icmp)
<wpwrak>
(may be zero) how about "may be unspecified/zero" ?
<ZetaR>
(may be zero) Personally, I would say something like "set per noise immunity requirements".
<ZetaR>
Most of those equations should take into account implementation, and would then need to be looked at again when you actually have a schematic rather than a block diagram.
<wpwrak>
hmm, then i didn't convey the meaning. the idea is that, if you have a given comparator, that you can calculate the shunt
<wpwrak>
things like noise immunity and such would be part of the selection criteria you applied elsewhere
<wpwrak>
sure, but the goal here is to define Rshunt, not write a new edition of The Art of Electronics ;-))
<ZetaR>
Hm, I don't have anything that will open TeX.
<ZetaR>
Why doesn't LibreOffice handle this?
<wpwrak>
so yes, even if you get Rshunt right, the circuit may still fail to work :)
<wpwrak>
oh, just open it as text
<ZetaR>
Okay, but I don't really know the markup
<wpwrak>
okay, then it may be a bit confusing
<ZetaR>
I can figure it out, but I might not do it tonight since it is 1AM.
<wpwrak>
(especially since i used some of the fancier features there :)
<wpwrak>
LaTeX is quite worth learning. you'll never want to go back to libreoffice and such, at least not for reasonably demanding papers, once you figured it out ;-)
<ZetaR>
One of the advantages of an op-amp before the comparator would be that you can use a Rshunt in the 100 mOhm range, and then you don't have to worry very much about messing with signals.
<wpwrak>
mmh, but that would then also increase noise sensitivity
<ZetaR>
(LaTeX) I have heard that, and I will keep it in mind. If I have something more demanding I usually prefer paper, but then I am not really writing publications.
<wpwrak>
but yes, an external opamp could effectively remove the comparator
<ZetaR>
Not if it is done correctly. It wouldn't make reference to anything but one side of the resistor and the other.
<ZetaR>
That sort of circuit is used to measure e.g. photodiodes with really tiny currents.
freemangordon has joined #neo900
<ZetaR>
Hey, do you want to continue this tomorrow? It is 1AM here and I have forgotten to go to bed. =)
<wpwrak>
alright :) thanks, and sweet dreams ! :)
<ZetaR>
Thank you, goodnight. =)
Pali_ has quit [Ping timeout: 246 seconds]
* DocScrutinizer05
has a strong feeling of a deja vu
Pali has joined #neo900
<wpwrak>
DocScrutinizer05: you mean IR ? or do you want an opamp there, too ?
<DocScrutinizer05>
nah, I think we discussed exactly that a while ago
<DocScrutinizer05>
and I don't think we need an opamp
<DocScrutinizer05>
I vividly recall how we tried to make sense out of V(OH) and V(OL) for a card that doesn't output any voltage. Well, actually it's even more complex
<wpwrak>
yeah, i think the Vo* stuff is just copy & paste, because it matches exactly the same sort of table in the (different) document defining the regular SIM interface
<DocScrutinizer05>
anyway when we would want to design this "right", we wouldn't need an opamp, we would need an LDO (yep, exactly)
<DocScrutinizer05>
the ESR on output of a LDO is << any possibly high input ESR
<DocScrutinizer05>
I'd put a decent resistor in front of the LDO and test the voltage (drop) after resistor before LDO input
<DocScrutinizer05>
ideally downshifted by a Zener
<DocScrutinizer05>
on output of LDO you got e.g. 1.8V no matter if 1uA or 50mA. On *input* you have 2.3 or 3.6V, depending on current. after zener you have 0.3 or 1.6V, no more comparator or opamp needed
<DocScrutinizer05>
but we don't need to do things "right", it completely suffices when they work, reliably. For that this circuit with a shunt-R is absolutely OK
arossdotme has quit [Ping timeout: 276 seconds]
kolp has joined #neo900
kolp has quit [Remote host closed the connection]
arossdotme has joined #neo900
arossdotme has quit [Ping timeout: 276 seconds]
paulk-collins has joined #neo900
arossdotme has joined #neo900
arossdotme has quit [Ping timeout: 276 seconds]
arossdotme has joined #neo900
arossdotme has quit [Ping timeout: 246 seconds]
arossdotme has joined #neo900
sparetire_ has quit [Quit: sparetire_]
arossdotme has quit [Ping timeout: 265 seconds]
arossdotme has joined #neo900
enyc has quit [Ping timeout: 276 seconds]
enyc has joined #neo900
nicksydney has joined #neo900
Oxyd76 has quit [Ping timeout: 265 seconds]
nicksydney has quit [Ping timeout: 244 seconds]
nicksydney has joined #neo900
nicksydney_ has joined #neo900
nicksydney has quit [Ping timeout: 244 seconds]
nicksydney_ has quit [Read error: Connection reset by peer]
<wpwrak>
good. i was already afraid i had to do it myself :) would have gotten me free subway rides ...
nicksydney has quit [Ping timeout: 272 seconds]
<wpwrak>
(nb: the nfc design for neo900 passes all such operations through an MCU under our control, so it's very easy to not implement this sort of "features")
<bencoh>
wpwrak: \o/
nicksydney has joined #neo900
nicksydney_ has joined #neo900
nicksydney has quit [Ping timeout: 248 seconds]
nicksydney_ has quit [Ping timeout: 248 seconds]
Pali has quit [Remote host closed the connection]
<ccnnjj>
Since hearingabout the store last month, I've been in that "pre-Christmas" phase, and was reading through what I've missed on tmo (I'd stopped paying attention almost simultaneously with a massive WONTFIX bug closing, and out of Nokia-frustration).
<ccnnjj>
I'd been reading the thread on wireless charging recently.
<ccnnjj>
(the Qi hacks, the universtal charger on amazon). My understanding is the N900 requires two data lines to be shorted per-spec, but most chargers aren't doing that. Does the Neo900 play more leniently?
<ccnnjj>
(I feel a bit silly asking given how much schmeatics and information's been released about it.)
<DocScrutinizer05>
ccnnjj: answering isn't easy since there's a half a dozen options how to do it
<ZetaR>
wpwrak: I am awake now, if you wanted to continue our discussion.
<ccnnjj>
I see. (Or will see, IÂ guess.)Thanks, Doc.
jonsger has joined #neo900
<DocScrutinizer05>
ccnnjj: there's direct access to VBAT for charging via your own charger chip, as well as access to USB, to tell the built-in charger chip what to do. That built-in charger chip is also smarter than N900 charging is/was. All that available internally on HackerBus
<DocScrutinizer05>
I can't tell off top of my head what charging modes the new charger chip supports that don't involve any electrical charger identifying
<ZetaR>
I wonder if you can force enable charging via I2C.
<DocScrutinizer05>
yes, you can
<DocScrutinizer05>
the new charger chip is 100% I2C controllable
<ZetaR>
Awesome. So even if you have a weird charger, you can at least make a software kludge.
<DocScrutinizer05>
yes
<DocScrutinizer05>
as long as the software comes up (which is also way easier with new charger chip which is even able to power a device without battery inserted)
<ZetaR>
That is appreciated. I hated how I had to worry about flashing the N900 and bricking it because the software wouldn't be booted to charge the phone.
<DocScrutinizer05>
yeah, no more
<DocScrutinizer05>
~flatbatrecover
<infobot>
Remove battery for 1 minute. Insert battery. Plug powered ***NOKIA WALLCHARGER*** to device. Watch steady amber. Let sit and charge. Do NOT try to boot. After 30 min, you got either a) a booted up N900, b) flashing amber which means you can boot, c) steady amber shut off -> start over again with ~flatbatrecover while already searching for a new battery. CAVEAT! Only works when ~rootfs OK (no ~bootloop)
<DocScrutinizer05>
no more
<DocScrutinizer05>
~bootloop
<infobot>
from memory, bootloop is when your device has broken rootfilesystem, so during reboot it fails on some service startup or kernel module load and thus reboots. This *drains* battery! And you can't reflash to stop bootloop when battery is drained. Recharge your battery by other means before reflashing. E.g. using ~rescueOS. Or external charger or BL-5J compatible other device.
<ZetaR>
I wonder why the N900 devs did things that way.
<DocScrutinizer05>
because the charger was like that
<ZetaR>
But they could have just used a more sane charger that could at least charge the battery without an OS.
<DocScrutinizer05>
maybe not
<ZetaR>
I guess.
<DocScrutinizer05>
our charger probably never would pass the USB-cert
<ZetaR>
Ahh, I see.
<ZetaR>
That really only means you can't use the trademark IIRC.
<DocScrutinizer05>
Nokia even sacrificed OTG hostmode to get USB-cert
<DocScrutinizer05>
yes
<ZetaR>
OTG would make you lose certification?
<jurov>
will the charger allow for direct connection of 3 of 4 AA bats in emergency?
<DocScrutinizer05>
err, externally yes
<DocScrutinizer05>
iirc
<DocScrutinizer05>
it has no boost mode to charge up battery to 4.2V from a 3.6V VBUS applied
<DocScrutinizer05>
but I think it should work at 6V rather flawlessly
<DocScrutinizer05>
so 4*1.5V should be OK
<DocScrutinizer05>
3*1.2V might suffice to power the device, but not charge battery
<DocScrutinizer05>
and I guess the modem would have some objections to this 3.6V operation mode
<ZetaR>
Wouldn't the current be high for AAs?
<ZetaR>
BTW, I opened up my N900 charger to check for TVS. It has none.
<ZetaR>
It is unusual as chargers go though because it has screws rather than a sealed case.
<DocScrutinizer05>
(high for AA) that's a question you need to ask Varta/Daimon/Mallory/Ucar
<wpwrak>
ZetaR: i thought a bit about it and i think the current design should be good enough to give it a try (unless you find an error in the calculations or such)
xes has quit [Ping timeout: 272 seconds]
<ZetaR>
wprwrak: Thank you and good morning to you (or whatever time of day it is where you are).
<DocScrutinizer05>
noon
<ZetaR>
I was thinking about this too, and my thought was: why not connect each side of the comparator to each side of Rshunt and then provide a bias to one side of the comparator?
<DocScrutinizer05>
err, because the comparator is integrated into the MCU?
<wpwrak>
ZetaR: if it doesn't work, we can always change it. not having additional electronics between the data line and the MCU also has the benefit that we can tweak parameters in software. e.g., by adjusting the reference voltage of the comparator, or maybe even by using the ADC that's also on that pin. (though the ADC would be a bit trickier because it couldn't finish a conversion in such a short time)
<ZetaR>
Oh, it doesn't give you access to each side?
<wpwrak>
it could give us access to both sides, yes. in the current design it doesn't because we don't have enough free pins. but the idea is to use the kl16 instead of the kl26, which doesn't have USB and thus a few more pins available for general use
<ZetaR>
wpwrak: My main concern was that there might not be a threshold that work always work, but that probably only applies to poorly designed circuits.
<ZetaR>
So are you using the MCU just for NFC, or as a general embedded controller for the whole phone?
<DocScrutinizer05>
did you find the schematics at end of NFC whitepoaper?
<wpwrak>
it's mainly intended for NFC. we may find some other nearby control function it could also handle, but for now, nothing is assigned
<ZetaR>
Well, I saw some diagrams, but I wasn't sure if they were just showing the NFC stuff or if they were complete.
Pali has joined #neo900
<wpwrak>
they're more to illustrate the concept
<ZetaR>
That is what I thought.
<wpwrak>
we also have a ton of other control signals in the system that still need to find something to drive them. some will go to the OMAP, some will go to I2C-attached IO extender chips. but that's not assigned yet.
<DocScrutinizer05>
it is
<ZetaR>
Also, you are using I2C to communicate with the host, but I2C doesn't have the throughput for some of the modes in one of the early tables. It wasn't clear if they were just optional high-speed modes though.
<wpwrak>
i mean the pins aren't assigned. we know what chips we want, etc.
<DocScrutinizer05>
the MCU will get used for NFC exclusively
<DocScrutinizer05>
what I'm missing in the whitepaper is the muxing for dual-SIM
<ZetaR>
At the top of page 9, there is a table, and some of the entries for "ISO 14443" list data rates too fast for I2C, but it is not clear if they are the different types mentioned earlier.
<wpwrak>
yes, many of them are optional and with doubtful compatibility. i think it was TI that once did a test with common NFC-capable smartphones. let's just say that it didn't look pretty :)
<ZetaR>
Right, I think there was a footnote about that.
<ZetaR>
So the reason you aren't using SPI is because of this SS pulse at the end of every word thing, right?
<wpwrak>
also, even if the on-air data rate can be high, that doesn't mean that there has to be a continuous stream of user data
<ZetaR>
Ah, so the MCU would buffer and then send it out in bursts?
<wpwrak>
no, just to keep the number of signals between MCU and CPU low
<wpwrak>
the SS pulse would be a problem if we wanted to connect the NFC transceiver directly to the OMAP
<ZetaR>
I was just thinking that SPI would give you the data rates you needed.
<wpwrak>
naw, the data rates we probably don't need ;-)
<ZetaR>
I had an idea with that: If you could find a counter/divider that has the right characteristics, you could use that.
<ZetaR>
Idea with SS pulse that is.
<wpwrak>
urgh :)
<ZetaR>
Lets say the word size is 8 bits, and you were able to find an 8-bit counter with just Din, 8-th bit out, and reset, that would be perfect.
<wpwrak>
i like MCUs. simple yet powerful. and a LOT of problems can be fixed in software ;-)
<ZetaR>
That is true.
<wpwrak>
you'd still have very weird timing related to the SPI clock
<ZetaR>
Okay, I guess I don't really understand what it is using the SS for then.
<ZetaR>
AFAIK, it is usually the equivalent of an enable pin.
<wpwrak>
well, you would have to sneak the SS pulse between synchronous data bits. so your SS-generating clock would have to be faster than the SPI bus clock (SCLK).
<wpwrak>
for the OMAP, it's also some sort of strobe
<wpwrak>
don't ask me why ;-)
<ZetaR>
Hm, I guess it would be useful if you were driving shift registers or something.
<DocScrutinizer05>
wpwrak: what's the RAM size of kl16?
<wpwrak>
DocScrutinizer05: yes, the SIM switching still needs to be written down. we have the chip but not the spec. bottom-up design ;) but that's a separate document, not NFC.
<wpwrak>
DocScrutinizer05: up to 16 kB for 32-QFN
<ZetaR>
K26 is 32 kB.
<DocScrutinizer05>
I thought you planned to have basically NO mux but simply more GPIO for the MCU?
<wpwrak>
if that's not enough, we could also use KL17, with up to 32 kB
<ZetaR>
I didn't have the other one's PDF open.
<wpwrak>
ZetaR: 32 kB is for larger / more difficult packages
<DocScrutinizer05>
32kB should suffice. My uneducated guess. ZetaR's comment about I2C bw is valid
<ZetaR>
wpwrak: And for forward compatibility with unknown user applications.
<DocScrutinizer05>
we need an estimation about data chunk sizes to buffer
<DocScrutinizer05>
aiui NFC is usually very low data volume
<DocScrutinizer05>
at least per "message"
<wpwrak>
yeah. i'm so unworried about running out of space that i didn't even bother to look this up :)
<DocScrutinizer05>
;-)
<wpwrak>
i mean, i use that chip in anelok, and that's a heck of a lot more complex
<DocScrutinizer05>
with buffering, no
<wpwrak>
unavoidable, also a fair bit of buffering
<DocScrutinizer05>
but then we're one of the two peers of the NFC com, usually. So we can negotiate any speed we like
<wpwrak>
but yes, you have to pay attention to what you're doing. you can't just throw a few GB or GHz at any problem
<ZetaR>
"The payload size is limited to 30 bytes." ETSI TS 102 613 V11. 0.0 page 26
<DocScrutinizer05>
LOL
<wpwrak>
qed ;-)
<bencoh>
ohwell
<ZetaR>
However, please make sure I am reading that right. It is under the slave section for some reason, and the master section doesn't mention it.
<wpwrak>
the section covers both master and slave
<wpwrak>
however, that's not the document with the worst-case messages
<ZetaR>
The TS 102 221?
<wpwrak>
e.g., felica has 256 bytes. but i don't expect anything much larger. nfc isn't the sort of place for jumbo frames
<wpwrak>
naw, i'd look in the over-the-air protocol
<ZetaR>
Ah, okay. Right. 221 is physical (Doh).
<ZetaR>
I haven't really read the protocol references yet.
<wpwrak>
you can deduce it from first principles ;-) nfc is expected to work in a fairly hostile environment. so you want small payloads, in order to be able to not lose too much channel capacity in the presence of interferences/errors/etc.
<DocScrutinizer05>
yep, exactly
<ZetaR>
Yeah, that is what I assumed.
<wpwrak>
and nfc is also expected to be permissive on timing (to the delight of security researchers), which means that you won't have packet trains with tight hardware acks or such
<DocScrutinizer05>
wpwrak: does you kl16 low pincount still apply for the sw-mux you suggested?
<wpwrak>
DocScrutinizer05: kl16 is basically like kl26, just more flexible (for our scenario). so anything we can do with kl26, we can do as well or better with kl16
<wpwrak>
likewise for kl17
<DocScrutinizer05>
ok
<DocScrutinizer05>
so the pincount is sufficient for dual-SIM?
<DocScrutinizer05>
icl 2 ADC?
<ZetaR>
Eh, the main security worry about timing is if it varies based on the results of sensitive calculations.
<wpwrak>
ZetaR: that's a different can of worms :)
<wpwrak>
DocScrutinizer05: only one ADC and one comparator. but an input multiplexer.
<DocScrutinizer05>
and one that doesn't even touch us
<DocScrutinizer05>
wpwrak: fair enough :-9
<DocScrutinizer05>
:-)
<ZetaR>
wpwrak: What I meant was that a good security system wouldn't have any security implications from varied transmission timings.
<ZetaR>
You just need to make sure your crypto calculation doesn't leak information via timing.
<ZetaR>
So ideally it wouldn't be relevant at the physical level.
<wpwrak>
ZetaR: yes, i know what you mean. but that's more a concern for the designers and cryptosystems. screw it up there, and it's virtually impossible to fix this in an implementation
<ZetaR>
IMO, the main problem is mistakes in the standards, like with WEP, or BT, or cell encryption.
<ZetaR>
Only way to really fix it then is to rip out the whole infrastructure and replace it.
<wpwrak>
hmm. there's another one that was found with the pants down just a few days ago. something made by ETSI. you'd think they had figured out by now how to avoid such embarrassments .....
<wpwrak>
we'll get to it right after completing the switch from IPv4 to IPv6 ;-)
<ZetaR>
Just like IPSec was done right?
<DocScrutinizer05>
bencoh: ohwell?
<ZetaR>
"You have to do things this way." -NSA, "Why?" -international conferance, "We can't tell you with foreign nationals present" -NSA
<wpwrak>
"so everyone but Mr. Snowden, please leave the room" :)
<ZetaR>
Lol.
<bencoh>
DocScrutinizer05: 30bytes :-)
<ZetaR>
I can't believe they got away with crippling IPSec using that stunt.
<ZetaR>
AFK for a bit.
modem has quit [Ping timeout: 265 seconds]
<ilon>
walloftext(tm)
<DocScrutinizer05>
Design&Elekronik: "Embedded Computing: PCI Express as standard for internal and external peripheral connections?"
<ilon>
I'm not alien to lastlogs, but this....
<DocScrutinizer05>
ilon: yeah
paulk-collins has quit [Remote host closed the connection]
<ZetaR>
Back,
<ZetaR>
External PCIe has bad security implications (not to mention it wasn't originally designed for it, AFAIK).
<ZetaR>
IIRC unless the CPU has memory virtualization, PCIe gets DMA without oversight from the CPU.
<DocScrutinizer05>
ilon: summary: *) shop officially opened, minor temporary hickups fixed. *) is PXS8 worse or better than PHS8? A: should work same-same, just with CDMA2000 option and a few bucks more expensive *) Should we make a new /. bump? A: why not, though the audience there is not really our target *)
<ZetaR>
wpwrak: another minor concern that I had when reading the NFC paper is that there is no mention of rise and fall times. This should probably be included e.g. the figure at the top of page 20.
<ZetaR>
This will restrict permitted bus resitance/capacitance/inductance.
<DocScrutinizer05>
o.O
<DocScrutinizer05>
does the SWP specs define any particular rise/fall-time? Do they also specify the complex impedance of the card input? without those numbers I tend to rather ignore the whole topic since we can't do anything about it anyway
<ZetaR>
See ETSI TS 102 613 V11.0.0 p21.
<DocScrutinizer05>
why? you did
<DocScrutinizer05>
if you found a bug, please holler. Othwerwise why discuss it when it's supposed to work?
<ZetaR>
Oh, answer is yes. They are defined.
<ZetaR>
It depends on bus capacitance. Rshunt might need an equation to ensure the RC constant is good enough.
<DocScrutinizer05>
n o, you do the math with the given values. We won't provide every single Ohm law equation in our schematics
<ZetaR>
Not enough information. I could try guessing the bus capacitance of the implementation, I suppose.
<DocScrutinizer05>
a 50R series is good enough for termination to avoid ringing on RAM dta / address-lines
<DocScrutinizer05>
and those have higher frequencies and slew rates than such a NFC SWP critter
<ZetaR>
True.
<DocScrutinizer05>
so please don't try to calculate capacitive load of power traces or the like
<DocScrutinizer05>
we can't do design on such a theoretical level. There's a huge amount of "gut feeling" applied in every design, simply since we know "30bytes, 500bytes, whatever. We don't need to worry" or "50R, 150R, doesn't matter"
<DocScrutinizer05>
though we have no numbers, we "know" the capacitive load of a trace, from decades of experience
<DocScrutinizer05>
no need to ask layouter about the surface of trace and dielectrical constant of the isolator layer
<ZetaR>
Okay. I don't have that experience, so I substitute analysis.
<DocScrutinizer05>
that's a good approach, but please grant _us_ the privilege to cut corners here and do it by intuition
<ZetaR>
I wasn't trying to insist that you do a theoretical analysis. I was just mentioning that the information to do so wasn't at hand if you happened to need it.
<DocScrutinizer05>
you could ask "do you expect any problems with slew rate, rise/fall times etc?"
<ZetaR>
Calc. with reasonable conditions shows that it shouldn't be a problem with the max resistance.
<ZetaR>
Oh, sorry. That is effectively what I was trying to say, but I am a poor communicator.
<DocScrutinizer05>
it just takes too much time to explain why we didn't include rise/fall times etc there
<ZetaR>
Okay.
<DocScrutinizer05>
that's what I suggested already: when yiou suspect a falw/bug somewhere, do your calculations and analysis, or ask if we expect a problem there, or ask us if we can provide data for your calculations when your first ballpark analysis shon that we don't need e.g. 4m^2 of trace array before the slew rate becomes an issue
<DocScrutinizer05>
but please don't ask _us_ to do the calculation for you / with you publicly
Pali has quit [Ping timeout: 244 seconds]
<ZetaR>
I didn't.
<DocScrutinizer05>
when we don't mention rise/fall times, please assume they got considered and found to be irrelevant
Pali has joined #neo900
<DocScrutinizer05>
when still in doubt, ask us if we actually considered them
<ZetaR>
Okay, well I didn't know if that was a good assumption to make.
<ZetaR>
Okay, okay. I just assumed that the information would be included, whether it was considered or not, thats all.
rjeffries has joined #neo900
Pali has quit [Ping timeout: 276 seconds]
<DocScrutinizer05>
an info like "based on allowed rise/fall-times as of ETSI-blablabla (4711ns) and a series R of 150 Ohm, the allowed maximum capacitive load on SWP line would be 69pF" is highly welcome, it will help even when we later on maybe need to pick TVS to know if we need low-capacity type, or if we could place a capacitor on that line to eliminate some harmomics escaping and spiling e.g. our GPS.
Pali has joined #neo900
<ZetaR>
Oh, okay. I will do that calculation then.
<DocScrutinizer05>
the moment we need to base some decision on it (low-capacity TVS, size of filter C) we will include the complete info into whitepaper then. Otherwise we keep it in our private data pool as background info we can access any time we need it
Pali has quit [Remote host closed the connection]
norly has joined #neo900
<ilon>
DocScrutinizer05: Thanks :D I'll probably just read it any way tho >_<
<ZetaR>
DocScrutinizer05: The maximum capacitance values are: 25ohm=5.5nF, 50ohm=2.6nF, 75ohm=1.7nF, 100ohm=1.2nF, 125ohm=880pF, 150ohm=680pF, 200ohm=420pF, 225ohm=330pF, 250ohm=240pF, 275ohm not satisfiable.
<DocScrutinizer05>
ok, that's what I had expected anyway. Alas this is not enough info to calculate a filter capacitor, but we will do the math when we need such capacitor then
<ZetaR>
The normal 2.2*RC rule of thumb is invalidated by the presence of the current signalling.
<ZetaR>
It hits zero at 270 ohms.
<DocScrutinizer05>
sure
<ZetaR>
What info do you need to calculate the filter cap?
<DocScrutinizer05>
wpwrak already said so
<DocScrutinizer05>
we don't need a filter cap, so right now we need nothing
<DocScrutinizer05>
sorry< busy
<ZetaR>
Okay.
sparetire_ has joined #neo900
<ZetaR>
Max Rshunt vs margin of error (with zero capacitance): 0% = 270ohm, 5% = 204ohm, 10% = 130ohm, 15% = 48ohm, 16% = 30ohm, 17% = 12ohm
<DocScrutinizer05>
percent of what exactly?
<ZetaR>
That is the tolerance on violating Vih.
<ilon>
uhhh, sorry, this has probably been answered.. what are the 'UMTS "worldwide"' option in shop?
<DocScrutinizer05>
ilon: sorry? please elaborate
<ilon>
just found in faq
<ilon>
never mind
<ZetaR>
Fortunately the permitted capacitance value plunges sharply near those values, rather than approaches smoothly. I will look at the plots to see roughly where the knee in the curve is.
<ilon>
regarding the PLS8-US modem, what does "AWS" stands for in LTE? bd4
<DocScrutinizer05>
ZetaR: please, we try to keep noise in this channel a tad down, so people dropping in every 2 days still could read the backscroll
<DocScrutinizer05>
bdX yes, maybe 4
<DocScrutinizer05>
ilon: it means one of the 1700-uplink/2100-downlink bands. I actually don't know what AWS means
<DocScrutinizer05>
the bands all have some weird (acronym) names
<ilon>
DocScrutinizer05: I really disslike the frequency spread of the modems, but so does most of us i guess
<DocScrutinizer05>
yes
<ilon>
i.e: i would like a modem that would have atleast GSM coverage all over the world
<DocScrutinizer05>
yes, me too. That's why I'll prolly go for PHS or PXS
<DocScrutinizer05>
a 16Mb downlink (like with HSDPA) is fast enough even for my browser on this I5
<ZetaR>
Man, this shop software has been giving you continuous grief.
<DocScrutinizer05>
indeed
Humpelstilzchen has quit [Ping timeout: 250 seconds]
Humpelstilzchen has joined #neo900
<DocScrutinizer05>
of course it's sort of "funny" when suddenly "dress printed, size M: 39.-" shows up when you visit the shop from errr N900, or from a FF with German lang setting, or ... actually nobody knows exactly what's been the trigger. Now when stuff like ZIP or VOUCHER fileds vanish, it's not "funny" anymore
<DocScrutinizer05>
whatever, time for dinner
<ZetaR>
Eat well.
<DocScrutinizer05>
ta
<DocScrutinizer05>
ooh
<DocScrutinizer05>
dos1: could you have a short look at that "+"-in-URL issue when you got some time for it,please?
<ZetaR>
DocScrutinizer05: I just emailed a graphic of the bus attributes to the Neo900 contact address.
<jurov>
DocScrutinizer05: that chat scrollback should be piped to root shell?
<wpwrak>
sp tjat
<wpwrak>
argh
<wpwrak>
let's try this again ...
<wpwrak>
so that's a maximum of 300 pF for 150+50 Ohm, with a 5% error margin, and with zero engineering tolerances in the parts involved worked in our favour. sounds more than safe enough.
jonsger has quit [Quit: jonsger]
<ZetaR>
wpwrak: I am working on an improved version of that graph (I didn't multiply the margin by the timing, only by the voltage). Keep in mind that CMOS, for example, usually uses 10% margins (IIRC).
<ZetaR>
wprwak: Ok, sent. Should be complete this time.
<ZetaR>
I also sent the code used to create it.
<ZetaR>
Oh, and the bus resistance is the resistance between the sender and receiver (not sure what you meant by 150+50).
<ZetaR>
So it is basically = Rshunt.
<wpwrak>
50 Ohm is Ron of the FET in the MCU (pin 31). the basic model is that we have the V1_8 supply, through the FET with Ron = 50 Ohm, then the shunt, and then the SIM card
<wpwrak>
where the SIM card's behaviour is defined by the standard, so we don't need to model it in terms of an equivalent resistors
<wpwrak>
(new graph) yup, still looks good.
<ZetaR>
This uses Voh and Vih, not Ron, actually.
<ZetaR>
AFK for dinner.
<wpwrak>
naw, if we want to model the actual system, then we can just use the real Voh. so that's Voh(min) = V1_8 - 50 Ohm * 1 mA
<wpwrak>
i.e., by picking the worst-case interpretation of the SWP specification, i already added a very large safety margin
<wpwrak>
which is to say: the standard is almost certainly wrong. but we can squeeze it in even if we assume everything applies as stated.
<wpwrak>
by the way, if the critter gives us a LOT of trouble, we could even just short Rshunt and rely exclusively on Ron. that would give us a configurable total resistance of either ~50 Ohm or ~2000 Ohm.
<wpwrak>
drawback: this may need calibrating, since Ron may have some tolerances (i suspect - didn't measure it. but such things tend to reflect the assured minimum performance)
<DocScrutinizer05>
honestly what are you worrying about?. The comparator is adjustable, no? what's comparator adjust range? what's granularity?
<wpwrak>
so, you see, there's a plan A, a plan B (tweak the DAC settings), and a plan C (simple rework, then vary Ron, too)
<wpwrak>
the DAC is 6 bits. steps are ... 28.1 mV
<DocScrutinizer05>
ADC?
<wpwrak>
DAC, providing the reference voltage
<DocScrutinizer05>
~2**6
<infobot>
64
<DocScrutinizer05>
~2**6 * 0.0281
<infobot>
1.7984
<DocScrutinizer05>
just fine
<wpwrak>
if we want to use the ADC, then we have up to 16 bits. but ADC is trickier because it doesn't go that fast
<DocScrutinizer05>
aah, THAT DAC
<wpwrak>
yup. i don't expect this to give us problems. the design is already excessively conservative as it is
<DocScrutinizer05>
what been the max input current of SIM?
<wpwrak>
(due to taking that bogus Vo*/Vi* table at face value)
<DocScrutinizer05>
for "o"
<DocScrutinizer05>
"0" even
<wpwrak>
20 uA. for "1" it's 600-1000 uA
Wizzup has quit [Ping timeout: 245 seconds]
<DocScrutinizer05>
~0.0006*200
<infobot>
0.12
<DocScrutinizer05>
~0.0006*130
<infobot>
0.078
<wpwrak>
oh, and with the KL16, since we have more pins, we can also use the 12 bit DAC ;-)
<DocScrutinizer05>
worst case signal
<DocScrutinizer05>
~0.001*200
<infobot>
0.2
<DocScrutinizer05>
worst case voltage drop from VDD
<wpwrak>
(6 bit DAC is all-internal, 12 bit DAC needs an external connection)
<DocScrutinizer05>
irrelevant, we don't need more than 6 bit
<DocScrutinizer05>
we have a worst case signal of ~75mV
<wpwrak>
the range is actually narrow enough that 6 bit are a bit tight. still enough, but just
<DocScrutinizer05>
we should have at least 2 steps of DAC in signal swing
<DocScrutinizer05>
one of both will work
<wpwrak>
if you add all the parameters, including comparator inaccuracies, you just get one code point for the DAC that is "just right"
<DocScrutinizer05>
no
<wpwrak>
yes ;-) see page 43 :)
<DocScrutinizer05>
the worst case signal amplitude is like above
<wpwrak>
yes, but then you have DAC errors, comparator tolerances, etc.
<DocScrutinizer05>
so what?
<wpwrak>
they eat from your swing
<DocScrutinizer05>
that maybe shifts our whole range up/down a little, or changes step width by a few percent
<wpwrak>
at least if we assume they're random and not all biased in the same direction
<DocScrutinizer05>
no, the DAC doesn't eat from signal swing
<wpwrak>
if they all err in the same sense, yes
<wpwrak>
the DAC has an error of +/- 0.8 LSB
<DocScrutinizer05>
and my equation has a total shunt of 130 Ohm
paulk-collins has quit [Ping timeout: 265 seconds]
<DocScrutinizer05>
instead the nominal 150+50
<wpwrak>
that's still in the acceptable range. Rshunt can be 40-220 Ohm, plus Ron = 50 Ohm
<DocScrutinizer05>
honestly, when we discuss each design THREE times, we never will finish the device
<wpwrak>
however, i don't know if a DAC code point exists for 130 Ohm. i only calculated it for 200
<DocScrutinizer05>
take the bot from your /ignmore !!!
<DocScrutinizer05>
our worst case signal swing for 130 Ohm(!!!) is ~75mV
<DocScrutinizer05>
nominal step width of DAC according to you is 28.1mV
<wpwrak>
yes, but we can't measure it with infinite precision
<wpwrak>
out measurement is affected by the imperfections of comparator and reference voltage
<DocScrutinizer05>
28.1 * 2 < 75
<DocScrutinizer05>
we *almost* have THREE valid DAC points
<wpwrak>
you're not paying attention :)
<DocScrutinizer05>
I do
<DocScrutinizer05>
you don't
<wpwrak>
we would have 2-3 code points iff comparator and DAC were perfect
<wpwrak>
but they are not. they can be off, according to the manufacturer's specification
<DocScrutinizer05>
and I told you we see liners drift and a few percent noise. You say 0.8bit
<DocScrutinizer05>
which still doesn't rule out 2 valid points per se
<wpwrak>
it's what freescale specify
<wpwrak>
well, i found one :)
<DocScrutinizer05>
and honestly I'm fed up with this. The circuit got discussed ad nauseum, it works
<DocScrutinizer05>
period
<wpwrak>
indeed. that's by far the most likely outcome ;-)
* Oksana
is wondering how to install strace on N900... Good morning. Any news about testing of capacitive-touch on resistive-touchscreen, aka finger-vs-stylus detection?
<DocScrutinizer05>
it works even with one valid comparator point in signal swing range, we got 3 usually
* Oksana
thinks that it would have lots of uses... Such as, switching virtual keyboards between finger-friendly and stylus-friendly... Or, glove-friendly, if in winter-mode...
<DocScrutinizer05>
won't work since you first need to touch at random place before you know where you should have touched
<dos1>
to trigger virtual keyboard you usually have to touch something already :)
<DocScrutinizer05>
NB we already *have* a stylus/finger distinction, e.g. in microB
<Oksana>
How does it work?
<DocScrutinizer05>
sinple, it detects the touch area
<DocScrutinizer05>
stylus is pinpoint touch, finger is huge compared to that
<Oksana>
Oooh, then we can distinguish between finger-stylus-glove easily, with two different algorithms...
<DocScrutinizer05>
directly translates to the ill-named "pressure"
* Oksana
thinks that both stylus/finger distinction and zoom-spiral should be system-wide features, not responsibility of MicroB...
<DocScrutinizer05>
that would mean gesture detection in HID driver
<DocScrutinizer05>
which is breaking all development style rules
<DocScrutinizer05>
at least that's what the driver devels think. Until you come with a CrTouch12 which has gesture detection in hw ;-P
* Oksana
remembers pinch-zoom and also rotate detection in hardware...
comradekingu has quit [Ping timeout: 240 seconds]
<ZetaR>
wpwrak: There is one more minor question I had about the NFC paper. What is the meaning of the L/C/R values in section 7.1.6 (p31). They have no units.
<DocScrutinizer05>
(NFC, a quote for those who missed it)
<DocScrutinizer05>
[2015-06-02 Tue 08:58:51] <DocScrutinizer05> anyway when we would want to design this "right", we wouldn't need an opamp, we would need an LDO (yep, exactly)
<DocScrutinizer05>
[2015-06-02 Tue 09:00:02] <DocScrutinizer05> the ESR on output of a LDO is << any possibly high input ESR
<DocScrutinizer05>
[2015-06-02 Tue 09:01:01] <DocScrutinizer05> I'd put a decent resistor in front of the LDO and test the voltage (drop) after resistor before LDO input
<DocScrutinizer05>
[2015-06-02 Tue 09:01:19] <DocScrutinizer05> ideally downshifted by a Zener
<DocScrutinizer05>
[2015-06-02 Tue 09:04:51] <DocScrutinizer05> on output of LDO you got e.g. 1.8V no matter if 1uA or 50mA. On *input* you have 2.3 or 3.6V, depending on current. after zener you have 0.3 or 1.6V, no more comparator or opamp needed
<wpwrak>
ZetaR: these are component counts, i.e., the number of inductors, capacitors, resistors
<ZetaR>
Ohh, hm. I didn't get that at all when reading it.
<wpwrak>
lemme add a sentence
<ZetaR>
You could even just change it from "Example Circuit" to "Number of components" or something.
<ZetaR>
So, from the schematic... the antenna goes through the hackerbus and is in the battery compartment?
<DocScrutinizer05>
yes
<ZetaR>
Okay. Looping a trace around the outer edges of the PCB several times wouldn't do it then I guess.
<DocScrutinizer05>
I pondered that. No final decision on it yet
<DocScrutinizer05>
generally prolly won't fly
<ZetaR>
Okay.
<ZetaR>
Well, that is the end of my list of comments and questions on the NFC paper.
<wpwrak>
probably too much metal stuff getting in the way. pity. would be nice to be able to avoid that RF-to-HB path.
<wpwrak>
kewl. thanks !
<ZetaR>
Sure. =) I am glad that I could help.
<DocScrutinizer05>
NFC antenna is sort of tricky. we might need a ferrite-backed antenna which has the downside of being ~1mm thick
<DocScrutinizer05>
we also must not cover other antennas by that ferrite sheet
<DocScrutinizer05>
and other antennas must not cover the NFC antenna either
<ZetaR>
Aren't the other antennas primarily capacitive mode?
<DocScrutinizer05>
tbh we don't know since we didn't build them
<DocScrutinizer05>
only thing you can do is experiment
<ZetaR>
So are you going to have a NFC proto board then?
<DocScrutinizer05>
I'm trying to push wpwrak into building one ;-)
<ZetaR>
I can't wait till Christmas. =)
<ZetaR>
Fingers crossed about it being finished in time.