jonwil has quit [Quit: ChatZilla 0.9.91 [SeaMonkey 2.30/20141013232806]]
jonwil has joined #neo900
Kabouik has joined #neo900
nox- has quit [Quit: Leaving]
jonwil has quit [Read error: Connection reset by peer]
Kabouik has quit [Ping timeout: 244 seconds]
norly has quit [Ping timeout: 272 seconds]
obsed has quit [Ping timeout: 245 seconds]
<DocScrutinizer05>
((<wpwrak> SWP is also a treat. the ETSI standard specifies parameters that don't really seem to exist. e.g., output voltages on a pin that's current-operated (leeching power from the other side) )) Dunno if you talk about the only pin (pair) directly involved in SWP, but http://www.etsi.org/deliver/etsi_ts/102600_102699/102613/11.00.00_60/ts_102613v110000p.pdf p.10 is pretty clear on that: master (CLF) talks to slave (UUIC) in voltage
<DocScrutinizer05>
domain, slave talks to master in current domain
<DocScrutinizer05>
so master uses a "programmable" voltage regulator to supply energy to SWP line and send data, and checks (input) current of that regulator to receive. Slave (SIM) checks voltage on SWP to receive data, and consumes current from SWP via a programmable constant current sink the output of which may then get used to power the SIM, possibly stabilized by a simple Zener in parallel
<DocScrutinizer05>
actually they don't even go that far, they still require "normal" power to SIM via Vcc and GND pads
mvaenskae has joined #neo900
<DocScrutinizer05>
(bitbanging SWP) we have (pulse width encoded) bit durations of 0.59 < T < 10µs. So our bitbanging needs to do max two GPIO state changes (L->H; H->L) in 0.59µs. The granularity needed in this timeframe is 0.1T, iow for a 1-bit the signal needs to stay H for 0.7 .. 0.8T, for a 0-bit the signal stays high for 0.2 .. 0.3T
<DocScrutinizer05>
during each H period of S1 (master->slave) signal, the S2 (slave->master) channel transmits one bit by either drawing >0.6mA (=1) or <0.02mA (=0)
mvaenskae has quit [Ping timeout: 250 seconds]
NIN101_ has joined #neo900
NIN101 has quit [Ping timeout: 258 seconds]
Pali has joined #neo900
Pali has quit [Remote host closed the connection]
nicksydney has quit [Read error: Connection reset by peer]
sparetire_ has quit [Quit: sparetire_]
mvaenskae has joined #neo900
Kabouik has joined #neo900
<wpwrak>
DocScrutinizer51: the inconsistency i was referring to is that they specify input and output voltages, which doesn't really make sense. i mean, why specify the characteristics of an output AND the one and only input, if there's nothing else between the two, and the characteristics define the same physical parameter ?
<wpwrak>
if you look at ETSI TS 102 221, you'll see that all signals that are unidirectional in the voltage domain (none have any unusual characteristics in the current domain, and as far as i understand it, the effect of that current modulation is already contained in the voltage specification) are specified with only input or output characteristics
nicksydney has quit [Remote host closed the connection]
unclouded has quit [Ping timeout: 258 seconds]
unclouded has joined #neo900
arcean_ is now known as arcean
Pali has quit [Read error: Connection reset by peer]
freemangordon_ has quit [Quit: Leaving.]
louisdk has joined #neo900
arcean_ has joined #neo900
arcean has quit [Ping timeout: 245 seconds]
mvaenskae has joined #neo900
astr has quit [Ping timeout: 255 seconds]
louisdk has quit [Quit: Ex-Chat]
louisdk has joined #neo900
astr has joined #neo900
Kabouik_ has joined #neo900
Kabouik___ has joined #neo900
Kabouik__ has joined #neo900
Kabouik_ has quit [Ping timeout: 258 seconds]
Kabouik has quit [Ping timeout: 255 seconds]
<DocScrutinizer05>
((grnularity)) actually is 0.25T, not 0.1T
mvaenskae has quit [Quit: Lost terminal]
SylvieLorxu has joined #neo900
Oxyd76 has joined #neo900
louisdk has quit [Remote host closed the connection]
louisdk has joined #neo900
Kabouik___ has quit [Ping timeout: 252 seconds]
Kabouik__ has quit [Ping timeout: 252 seconds]
Kabouik has joined #neo900
<DocScrutinizer05>
>>Your current array shows the domes to be similar to our RK- series. We could probably make you an RK- series at .156 diameter like the P15150 if need be.<<
<DocScrutinizer05>
wpwrak: ETSI TS 102 221 is not about any bidir signal like SWP
<DocScrutinizer05>
ETSI TS 102 221 specifies the "classic" UICC interface between SIM and modem
<DocScrutinizer05>
(actually it's not comprehensive on that even. It refers to ISO/IEC 7816-3 for many details on power-on-sequence, reset, etc)
wazrus has joined #neo900
wazrus has quit [Quit: Lost terminal]
<wpwrak>
yes, SWIO is unique in that regard. but again, it's basically a unidirectional voltage with a variable load at the end. so how do, say, Voh and Vih relate ?
astr has quit [Ping timeout: 264 seconds]
chainsawbike has quit [Ping timeout: 252 seconds]
chainsawbike has joined #neo900
astr has joined #neo900
paulk-collins has joined #neo900
Pali has joined #neo900
<DocScrutinizer05>
please refer to a particular page/§ so I know what we're talking about
<wpwrak>
still tables 7.3 and 7.4 in section 7.1.3, page 19
<DocScrutinizer05>
7.1.3 actually is a bit weird, when you consider it a spec of SIM only. It seems it specifies the SWP/SWIO pin for both UUIC and terminal/CLF
<wpwrak>
yes, but it's still weird. if the CLF is required to produce >= Voh for "1", why even specify Vih ? the reason why we normally have those two doesn't exist in this case
<wpwrak>
exactly. normally we have two points. in this case, there's just one
<DocScrutinizer05>
no, the paper seems to cofer both UUIC and CLF
<DocScrutinizer05>
cover*
<DocScrutinizer05>
well, not according to the title
<wpwrak>
so if they're not the same point, what is between them ? and how does it behave ? :)
<DocScrutinizer05>
meh, ETSI
<DocScrutinizer05>
;-)
<wpwrak>
yeah. i think they just copy & pasted from ETSI TS 102 221, where they had bidirectional I/O (C7)
<DocScrutinizer05>
they have several such "flaws" in their specs
<wpwrak>
(table 5.4 in section 5.1.5 page 25 and table 5.8 in section 5.2.4 page 27) there it all makes sense, no complaints from me :)
sparetire_ has joined #neo900
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
on a related topic: any ideas how to interface SWIO to CPU?
<DocScrutinizer05>
seems we need a current detector?
<DocScrutinizer05>
of sorts
<wpwrak>
comparator and shunt should work. even if we use a worst-case interpretation of this ambiguous spec.
<DocScrutinizer05>
and two GPIO, one for out and one for in
<DocScrutinizer05>
yup
<DocScrutinizer05>
seems UUIC has an internal PLL to sync to the implicit clock of SWP
<wpwrak>
still need to check my calculations, though. quite a lot of formulas. also need to put them in a form that makes it easy to redo them, in case we relax our assumptions
<wpwrak>
(pll) i was wondering about that. i don't remember having seen any requirement on clock stability, but it's on my mental "to look for" list
<wpwrak>
else, it could just count the H and L times with some internal clock
<DocScrutinizer05>
since it's always master to provide that clock, we need some 4MHz resolution with a jitter of less than 10%
<wpwrak>
S1 = T(H) > T(L)
<DocScrutinizer05>
yeah, doesn't matter if it's a PLL or a counter that compares and discriminates for short and long T(H)
<wpwrak>
note that the host can't just stop for "bus idle". it has to do a proper sign-off. this means that there's always a rising edge at the end of a data bit
<wpwrak>
counter is more robust if the clock is bumpy ;-)
<DocScrutinizer05>
yes, bus idle means "long H"
<wpwrak>
but only after a specific suspend sequence
<DocScrutinizer05>
wpwrak: actually VCC and RSET are more tricky to interface than SWP
<DocScrutinizer05>
but since we're doing "APE assisted SWP", we could exploit the modem to power the SIM
<wpwrak>
i don't know if NFC actually should/has to connect to RSET of the SIM/UICC
<DocScrutinizer05>
no, NFC doesn't
<wpwrak>
alas, the crappy pre-rendered PDFs of the PN544 don't let me see quite clearly what NXP are doing there
<wpwrak>
good. one problem down ;-)
<DocScrutinizer05>
at least not explicitly. The power-up sequence however is not even described in ETSI TS 102 221
arcean_ is now known as arcean
<DocScrutinizer05>
it prolly involves RSET too
<DocScrutinizer05>
whole card activation/deactivation (aka power-up/down) sequence is still quite cloudy to me
<DocScrutinizer05>
only thing I know by now: VCC starts at class C (1.8V) and waits for card to send ACT which tells about which class the card really is. If that fails 3 times, the interface shall try next class (B) 3 times. Then A (which doesn't exist/apply for SWP anyway) so that's moot
<DocScrutinizer05>
I don't want to mess with that via CPU
<DocScrutinizer05>
I'd prefer modem doing this stuff for us
<DocScrutinizer05>
however we need to ponder what we do with SIM2
<DocScrutinizer05>
and seems we need a dedicated power supply for SIM(2) anyway
<DocScrutinizer05>
since we want to mux SWP between SIM1 and SIM2
<DocScrutinizer05>
told you it gets more tricky than SWP line ;-)
<DocScrutinizer05>
I'm just happy we don't need intra-USB :-D
<DocScrutinizer05>
(C4, C8)
<DocScrutinizer05>
err s/ACT/ATR/
<DocScrutinizer05>
which happens to mean Answer To Reset
<DocScrutinizer05>
wpwrak: re NFC/RFID I dound one sentence that sounds like the RFID-ZEN-wisdom to me: http://www.etsi.org/deliver/etsi_ts/102600_102699/102613/11.00.00_60/ts_102613v110000p.pdf "11 CLT LCC", ".2 OVERVIEW" >> The CLT LLC is used to exchange data based on SWP physical layer between the CLF and the UICC. The CLF acts as a bridge, which composes/removes the type specific RF-frame encapsulation, but keeps the type-specific error detection code,
<DocScrutinizer05>
which is managed by the UICC except where specified otherwise.<<
<DocScrutinizer05>
s/dount/found/
<DocScrutinizer05>
"type" here referes to the OTA protocol the CLF detected and is using
<DocScrutinizer05>
so if the host interface ot CLF also supports CLT LCC (and SHDLCP which I'm sure it does), I guess we're done for simulating SWP via host IF
<DocScrutinizer05>
of* CLF
<wpwrak>
(intra-USB) well, there's always the PN533 ... ;-)
<DocScrutinizer05>
hmm? it uses the C4/C8 SIM USB?
<wpwrak>
SIMs can do USB ? wow. no, the PN533 just has USB for its host interface
<DocScrutinizer05>
haha. Yes, SIM can do USB
<wpwrak>
have they no shame ? :-(
<DocScrutinizer05>
ETSI 102600 or sth
<wpwrak>
of course, then there's also the question which SIMs actually support which of these features ...
<DocScrutinizer05>
well ATR tells you
<DocScrutinizer05>
(not that you wouldn't know when you already received an ATR ;-P)
<DocScrutinizer05>
would be funny t receive an ATR via SWP that tells "I cannot SWP"
<wpwrak>
i'm more thinking of it in terms of "if i go to the shop of telco X, what features will the SIM i go home with have ?" :)
<wpwrak>
yeah, then you know something is fishy ;-)
<DocScrutinizer05>
hah, nobody will ever tell you what exactly the particular SIM can do
<DocScrutinizer05>
but maybe it's a tad too expensive when snaptron produces a custom dome series for us
<Oksana>
Ask them? :-)
<DocScrutinizer05>
sure
<DocScrutinizer05>
otoh maybe we don't need RK. Ellie also asked "Have you tested the SQ04200N dome?"
<DocScrutinizer05>
can do 10 million
<bencoh>
10 million neo900s weeee
<DocScrutinizer05>
lol
<DocScrutinizer05>
cycles
<bencoh>
aww :( ;p
<Oksana>
Can they send samples? So that you could test-and-compare SQ04200N vs RK-dome vs round-whatever, and choose the one that feels best?
<DocScrutinizer05>
I received my sample box :-)
<Oksana>
Or is there some kind of specification (like, plot of force-vs-distance travelled) which can be used for armchair-comparison of arbitrary domes of Snaptron against N900's original dome?
<DocScrutinizer05>
funny enough SQ04200M was one of the 3 cans they added as "special" and the one can tha wasn't tightly closed and the domes came out through the thread of the lid (YES!)
<Oksana>
How is it, with sample box? Interesting?
<DocScrutinizer05>
(plot) snaptron provides such plots for all their domes. Nokia obviously doesn't
<DocScrutinizer05>
(box) well, it's a nice presentation
<DocScrutinizer05>
wpwrak: we will need a 1V8 and a 3V for SIM VCC
<DocScrutinizer05>
and we need to "OR" the VCC from modem with that one we provide by ourselves
<wpwrak>
i guess we'll want some power routing. will we also want to support mixed voltage configurations, e.g., SIM1 = 1.8 V, SIM2 = 3.3 V ?
<DocScrutinizer05>
yes, we need that
<DocScrutinizer05>
we however won't power both SIMs concurrently
<wpwrak>
DocScrutinizer05: (domes) if it looks like an unusual failure mode, you may actually want to tell them, so they can try to fix it
<DocScrutinizer05>
the lid?
<DocScrutinizer05>
:nod:
<wpwrak>
so, so no scenarios like SIM1 for modem, SIM1 for NFC ?
<wpwrak>
(lid) yup
<DocScrutinizer05>
sure there's a scenario like "SIM1 used by modem and NFC concurrently"
<wpwrak>
err, sorry , s/, SIM1/, SIM2/
<DocScrutinizer05>
but none like "NFC provides power to both SIMs concurently"
<wpwrak>
would be modem powers one, NFC the other
<DocScrutinizer05>
there's also "SIM1 used by modem and SIM2 by NFC"
<wpwrak>
okay, so we may power both at the same time. just not from the same source.
<DocScrutinizer05>
and note that there's also "SIM1 'used' only by NFC, while modem has suspended SIM1"
<DocScrutinizer05>
and same for SIM2
<wpwrak>
yup, the full matrix of configurations
<DocScrutinizer05>
we got two independant muxes, one for modem (dual SIM) and one for NFC incl the 1V8/3V VCC
<DocScrutinizer05>
since from modem moni we already know if modem power SIM, we simply can switch from modem provided VCC to "our" VCC when SIM is already powered by modem
<wpwrak>
given the characteristics of SWIO, it may actually be easier to just let the host talk to both SIMs, instead of trying to build an analog multiplexer
<DocScrutinizer05>
when however modem didn't power the SIM, we need to do a cold reset
<DocScrutinizer05>
incl ramp-up of VCC
<DocScrutinizer05>
(easier) huh?
<DocScrutinizer05>
how that. A mux is a pretty simple 6 pin component
<DocScrutinizer05>
(for DPST)
<wpwrak>
got any example you like ?
<DocScrutinizer05>
for what? mux?
<wpwrak>
yes
<DocScrutinizer05>
well, we got some fine examples already, for video and for audio
<DocScrutinizer05>
the one has a "high" ESR but also high Ft, the other is pretty low ESR but has a "audio" class Ft
<DocScrutinizer05>
f(t)
<DocScrutinizer05>
transit frequency
<DocScrutinizer05>
we need a f(t) of 8MHz or better
<DocScrutinizer05>
seems we can live with a ESR of some few Ohms
<wpwrak>
if we use an MCU, the cost of having another SWP channel would may be a) use non-minimum package and b) one external resistor. but i still haven't looked into optimizing a).
<DocScrutinizer05>
we need 3V3 compliance though, can't recall what our muxes can do
<wpwrak>
for SWIO, no 3V3 is needed
<DocScrutinizer05>
I still don't see any advantage of using a MPU
<DocScrutinizer05>
but for VCC a 3V3 are needed
<DocScrutinizer05>
actually *maybe* even >5V
<DocScrutinizer05>
depemding on modem specs
<wpwrak>
and yes, an ESR of up to 30 Ohms would be fine in my example
<DocScrutinizer05>
but yeah, we could *maybe* find a way to have *one* comparator and one GPIO input, have tow just for the GPIO outputs, for SWP
<DocScrutinizer05>
but I still fail to see the advantage since we need to mux VCC as well
<DocScrutinizer05>
s/tow/2/
<DocScrutinizer05>
we can handle all mux and VCC_set_voltage via GPIO_extenders, only need genuine CPU GPIO for SWP out/in
<wpwrak>
sure
<wpwrak>
with MCU, it may be nice to be able to coordinate power from there, too, to avoid complicated command paths. but that would be an opportunistic optimization, not something we'd "need".
<DocScrutinizer05>
we need to sense modem_VCC_SIM whether it's 1V8, 3V or 5V (or off). We need outputs to control our own nfc_VCC_SIM_voltage, nfc_SIM_VCC_mux (sim1/2), and SWP_mux (sim1/2)
<DocScrutinizer05>
we might get away with asking modem for voltage of SIM_VCC
<wpwrak>
sounds complicated. wouldn't it be enough to take whatever the modem provides if it provides anything, else provide whatever want ? SWIO is basically the same in class B and C. so the only problem would be class A, if the modem does that. does it ?
<DocScrutinizer05>
depending whether modem supports that or not
<wpwrak>
and if it can supply both SIMs at once. (and class A is not part of the equation)
<DocScrutinizer05>
no, we cannot simply depend on modem for powering SIM. Modem may tear down / suspend /deactivate SIM any time
<wpwrak>
i guess that would depend on what level of control the modem lets us have over the SIM. has anyone checked the AT commands for that ?
<DocScrutinizer05>
not thoroughly
<DocScrutinizer05>
it still doesn't really help
<DocScrutinizer05>
we need power for SIM2 anyway
<wpwrak>
but i'd also expect that in the end NFC will be able to supply its SIM. anyway, i'm not worried about supplying power.
<DocScrutinizer05>
and no, modem cannot power two SIMs at once
<DocScrutinizer05>
please consider the voltage-ramp-up mess from class C to class B for NFC, when we access an unpowered NFC, and how we must not do same thing when we access a SIM that already has negotiated whatever power/voltage with modem
<DocScrutinizer05>
instead of "we need to sense modem_VCC_SIM whether it's 1V8, 3V or 5V" we might get away with asking modem for voltage of SIM_VCC - depending whether modem supports that or not
<DocScrutinizer05>
we got sensing of modem_SIM_VCC from monitoring anyway
<wpwrak>
we just went through that (asking modem), didn't we ?
<DocScrutinizer05>
I though we didn't agree
<wpwrak>
hmm. that sensing may be too far away (communication-wise) to do us any good
<DocScrutinizer05>
thought*
<DocScrutinizer05>
sorry?
<wpwrak>
(asking modem) we concluded that it probably doesn't solve the problem, didn't we ?
<DocScrutinizer05>
no
<DocScrutinizer05>
that's why I reposted the whole statement
<wpwrak>
(voltage sensing) hmm, we could use the interrupt output of the INA231 to disable NFC-to-SIM power
<DocScrutinizer05>
when we "enable" NFC for a SIM, we need to switch SIM_VCC from modem to "NFC"-provided (actually battery/regulator) anyway
<DocScrutinizer05>
we however don't want to start with 1V8 in that case
<DocScrutinizer05>
maybe
<DocScrutinizer05>
disabling NFC is simple: we simply switch SIM_VCC back to 2mode provided"
<DocScrutinizer05>
"modem provided"
<DocScrutinizer05>
unconditionally
<wpwrak>
yes, a 3-way power mux, one for each SIM, should do the trick: modem / 1V8 / 3V3, plus a cap to buffer when switching.
<wpwrak>
ah no, 4-way: off/modem/1v8/3v8
<DocScrutinizer05>
we only need a 2-way mux, and a second nux for 1V8/3V
<wpwrak>
cascading is an implementation detail :)
<DocScrutinizer05>
though I guess we are better off using a programmable LDO for VCC
<wpwrak>
i always cringe when you say that ;-)
<wpwrak>
do we have a lot of spare LDOs ?
<DocScrutinizer05>
well, then look at twl4030, there might be a few spare ones
<DocScrutinizer05>
one or two
<wpwrak>
i'm still a bit shell-shocked from my openmoko days when it comes to messing with LDOs and related PMU fun. i just hope the "gaia" is nicer. (haven't looked at that part yet)
<DocScrutinizer05>
though yet to be checked if one can do 1V8/3V
paulk-collins has quit [Quit: Quitte]
<DocScrutinizer05>
(nicer) well OMAP3 devices are legion, all use twl4030
<wpwrak>
seems that there isn't much of a choice, is there ? :) i.e., OMAP3 -> TWL4030, or perish
<ds2>
thought the N900 used a TWL5030?
<DocScrutinizer05>
4030 5030 all the same
<DocScrutinizer05>
like omap3430/3530
<ds2>
no
<ds2>
tps65950/twl4030 is more like that
<DocScrutinizer05>
ooh, that starts to be interesting :-)
<ds2>
there are simplier PMICs under the tps name
<ds2>
donno much about the twl5030
<DocScrutinizer05>
well, it seems to be TPS65950/TWL4030/TWL5030, while N9 is using TPs65951
<ds2>
isn't N9 a OMAP4?
<DocScrutinizer05>
no
<DocScrutinizer05>
OMAP3630 afaik
<DocScrutinizer05>
or 3730
<ds2>
ah
<DocScrutinizer05>
prolly 36
<ds2>
I suspect you really want the 5030
<ds2>
but this is guessing based on droppings of little birdies flying by :D
sixwheeledbeast has left #neo900 [#neo900]
<DocScrutinizer05>
I guess we can't have either
<DocScrutinizer05>
never seen a twlx030 sold anywhere
<DocScrutinizer05>
GTA04 is using the TPS65950 iirc
<DocScrutinizer05>
I'm not aware of some short comings of the 4030, but I know differences between tps65950 and 951
<wpwrak>
given all the horror stories i've heard about OMAP-based designs failing badly, i'd say that it's good that we're a bit conservative there. and that we have nik's experience in taming that critter.
<wpwrak>
(failing badly = unstable, and nobody knows why)
<DocScrutinizer05>
sure
<DocScrutinizer05>
anyway, kinda off topic ;)
<DocScrutinizer05>
we gonna use what GTA04 has
<DocScrutinizer05>
since that design works
sixwheeledbeast has joined #neo900
<Oksana>
Okay, about touch-screen (resistive, dual-touch): is it possible, theoretically, to have some kind of difference between left-hand and right-hand? Or between different fingers of the same hand? And yes, I know that even stylus-vs-finger is unreliable :-) Got to hunt down those datasheets...
<DocScrutinizer05>
sorry?
<DocScrutinizer05>
touchscreen won't know if you use your left hand or your right hand ow a wiener sausage
<bencoh>
(although we could tell if you fed sausage to your phone)
<DocScrutinizer05>
difference between stylus and finger is "pressure" aka (more precisely) the area of contact between the two planes
<bencoh>
DocScrutinizer05: is that accurate ?
<DocScrutinizer05>
well, for area*sqrt(pressure)*random(0.8) it's pretty accurate :-)
<bencoh>
meh
<Oksana>
That's a weird formulae... Okay, thank you!
sixwheeledbeast has left #neo900 [#neo900]
<DocScrutinizer05>
th resistance of plane-a to plane-b is kinda proportional to area and a tiny bit also to pressure
louisdk has quit [Remote host closed the connection]
<DocScrutinizer05>
consider each plane as a web of resistors
<DocScrutinizer05>
when you connect the two webs only in one point, you get higer resistance from one to the other than when connecting on multiple points
<DocScrutinizer05>
a single point only has 4 (depending on net geometry, assuming square here) resistors connected to it
<DocScrutinizer05>
so you have R/4 + R/4 for one-point connects
<DocScrutinizer05>
for a huge area, that reduces to several parallel such connects
<DocScrutinizer05>
that's the operation principle
<DocScrutinizer05>
a tiny bit the connect itself has some resistance too, and that goes down by increasing pressure
<DocScrutinizer05>
but actually I guess you can't really detect pressure of stylus
<Oksana>
Thank you! Resistive touchscreens typically have high resolution (4096 x 4096 DPI or higher)... When will LCD panels reach the same resolution? :-)
<ds2>
it all turns into one of those ugly exercises in algebra that first year EE students have to stare at
<DocScrutinizer05>
yep :-D
<ds2>
resistive displays are analog, there is no "resolution" in the normal sense!
<DocScrutinizer05>
well, there is noise and inaccuracy which might be in that range
<ds2>
it is 2 thin sheets of transparent resistive materials seperated by a spacer.
<DocScrutinizer05>
like there's no 0.00000000000001% carbon resistor
<DocScrutinizer05>
;-)
<ds2>
w/o backing out the definition of things in terms of coulombs, charge of a electron, etc... I have nothing to base a comment on ;)
<DocScrutinizer05>
~25.4 / 4096
<infobot>
0.006201171875
<DocScrutinizer05>
close enough to atom size ;-P
<DocScrutinizer05>
(just kidding, but really)
<DocScrutinizer05>
that's about the range of inaccuracy of the foils' thickness, aka surface roughness
<ds2>
I have always wondered if you can detect finger vs stylus using something other then 'pressure'
<DocScrutinizer05>
nope you basically cannot
<ds2>
why?
<DocScrutinizer05>
how? :)
<ds2>
this is what I have been thinking of but never got around to testing -
<ds2>
X/Y info is using resistive info
<DocScrutinizer05>
you could detect the electric capacitive properties of finger maybe
<ds2>
but since the film is conductive, why not excite the thing as if it was a single button cap sense device
<ds2>
precisely
<bencoh>
hmm
<ds2>
donno how noisy the LCD is nor do I know how long it will take the cap sense to converge/stablize
<bencoh>
wouldnt that change you resistivity reading ?
<ds2>
no, you read resistive; stop; read cap; stop; and repeat
<DocScrutinizer05>
LCDs are *very* noisy, you wouldn't believe until you check
<ds2>
I got the parts to build it but never got the time. the cypress psocs are ideal for this experiment
<bencoh>
not sure your (RC) cycle is short enough for that
<ds2>
*nod*
<bencoh>
(dunno actually, I have no info to compute it)
<DocScrutinizer05>
sure you could connect the upper plane to a capacitive input as well, and hope it gives a decent signal when "touched" (there's a isolating plastic layer between plane conductive and surface!) by a conductive object like finger
<bencoh>
that could replace the "screen protector" :]
<DocScrutinizer05>
CRTOUCH actually has 4 "electrodes" for capacitive
<DocScrutinizer05>
gives me ideas :-)
<ds2>
there might be analog filtering that can be done
<ds2>
I assume the LCD noise is related to the PCLK freq
<ds2>
along with VSYNC and HSYNC
<DocScrutinizer05>
the CR in CRTOUCH means Capacitive Resistive I'd guess
<bencoh>
ds2: between the adc and the resistors web ?
<DocScrutinizer05>
ds2: kinda, yes
<ds2>
bencoh: for resistive mode or cap mode?
<bencoh>
for both since that's what you're aiming for I guess
<ds2>
resistive mode is more or less the same as it is today
<DocScrutinizer05>
actually seems to me it's the refresh frequency of the LC "capacitors"
arcean has quit [Quit: Konversation terminated!]
<ds2>
in cap mode, you more or less treat the 2 films as a giant RC network
<DocScrutinizer05>
you can forget about lower plane film for capacitive
<ds2>
prehaps set it up so it resonates at a non harmonic of VSYNC/HSYNC/PCLK
<DocScrutinizer05>
it just protects your upper film from LCD noise, if anything
<ds2>
you can't ground that lower layer
<DocScrutinizer05>
and couples that noise to upper plane when you have a touch point
<ds2>
it would effectively short out the cap sense. it is like a ground plane on cap sense electrodes
<DocScrutinizer05>
yep, sort of
<ds2>
the PSoC5 has all the bits to experiment with this stuff (Capsense block, ADCs, analog filters, digital filters, I2C slaves, SPI slaves, and a M3)
<ds2>
this stuff has been brewing in my head for the last 3-4 years but no time :(
<DocScrutinizer05>
check the datasheet of CRTOUCH!
<ds2>
who make CRTOUCH?
<ds2>
or got a link to the DS?
<DocScrutinizer05>
err that MCU manuf
<DocScrutinizer05>
link? go to our very fine interactive block diagram! :-D
<wpwrak>
(cap-sensing resistive touch screen) fun idea ;-) that may have some novelty value
<ds2>
:)
<wpwrak>
use it for biometry: "sorry, you're not my owner. your fingers are too thin." :)
<DocScrutinizer05>
wpwrak: actually it doesn't have that much novelty in it, I did some tests with more sophisticated such approach back during my time at OM
<wpwrak>
ah, pity
<ds2>
DocScrutinizer05: did you do custom ITOs for that?
<DocScrutinizer05>
I also tried the approach of using the planes as transmission line / delay line, detecting the location of a discontinuity in medium from the impulse response
<DocScrutinizer05>
alas the available instrumentation been poor
<DocScrutinizer05>
and so where the results
<DocScrutinizer05>
ds2: ITO?
<Oksana>
(cap-sensing resistive touch screen) It would require having surface(s) of resistive touch screen connected as capacitive electrode(s)? What result would it provide, besides "touch is detected" (aka finger-or-stylus detection) ?
<DocScrutinizer05>
Oksana: it provides exactly that - if any. Touch Detected, which means "touch by conductive finger"
<ds2>
Indium Tin Oxide later
<ds2>
the magic conductive-transparent stuff
<DocScrutinizer05>
no, I used a touch panel scavenged from a GTA02
<DocScrutinizer05>
I wonder where's my patent anyway, for the Impulse-Response detection
<ds2>
how did you do the impulse response detection?
<ds2>
FFT?
<DocScrutinizer05>
nah, I tried some very poor / silly things
<DocScrutinizer05>
due to lack of even a decent scope
<ds2>
ignoring RFI for a moment, I wonder if you can do something crude like send a pulse on one plane and look at the coupling on the other
<DocScrutinizer05>
that's exactly what I tried to do
<DocScrutinizer05>
well, along that line at least
<DocScrutinizer05>
you actually need to apply the pulse between the two planes
<DocScrutinizer05>
like: apply to UpperLeft and LowerBottom, check for echo on same both lines, resp for output on UR+LT
<DocScrutinizer05>
consider the whole thing e.g. a coax 50R cable