<DocScrutinizer05>
I should ask that network admin friend to borrow me his 5kEUR cable tester. That thing can tell a discontinuity in a coax cable to the cm from the single probing point
<DocScrutinizer05>
cm distance
<DocScrutinizer05>
surface wave touch panels work faintly similar, though mechanical
<DocScrutinizer05>
the CRTOUCH can at best detect finger touching the uper plane of digitizer
<DocScrutinizer05>
maybe
<DocScrutinizer05>
the problem with SEW (surface electric wave - I just made that up this very minute) is that you need AD with several MSamples/s
<DocScrutinizer05>
and obviously in continuously eats energy to detect a touch - but we have other means to activate the SEW, by e.g. using the classic "push button contact" between upper and lower plane of r-ts
<Oksana>
Ok... SAW would need tiny transducers and reflectors attached to the edges of the touchscreen - is there enough width for that? What would the resolution be? It would not detect stylus? SEW would need electrically conductive surface, like glass for SAW? SEW would not detect stylus, either?
<DocScrutinizer05>
but all that is not for Neo900. Using the capacitive sensing capabilities of CRTOUCH however is sth that costs us at most one resistor to connect upper plane to the pin of chip
<Oksana>
:-) Would it be tested in prototype, or is theory enough to figure out its workability?
<DocScrutinizer05>
Oksana: your questions are assuming too much
<DocScrutinizer05>
we will test the CRTOUCH thing in prototype, yes
<Oksana>
That's why they are questions and not sentences :-) Great!
<DocScrutinizer05>
I cannot answer questions like >>would need tiny transducers and reflectors attached to the edges of the touchscreen - is there enough width for that?<< I dunno what you refer to
<DocScrutinizer05>
SAW cannot get done on N(eo)900, neither can SEW with the electrical design we got (flex cable for example)
modem has quit [Read error: Connection reset by peer]
<DocScrutinizer05>
(reflected wave) yeah, and should work similar on r-ts, no?
<wpwrak>
(rigol) ds1054z would be the most cost-effective choice: 50 MHz, and then you "hack" it to do 100 MHz (and a bunch of other things). of course, if you don't feel like being a little dishonest, then you'd buy the 1104Z, which comes with 100 MHz enabled from the factory, and maybe also buy some of the extra options (e.g., more memory)
<DocScrutinizer05>
what's the difference between the Z, B, E models?
<DocScrutinizer05>
(dishonest) I will go for 50MHz for now :-)
<wpwrak>
B has small memory, no intensity grading, not sure about connectivity, old design. E has reasonable memory, no intensity grading, old design, only two channels.
<wpwrak>
Z has 4 channels (like B), big memory, intensity grading, usb and ethernet, modern design.
<DocScrutinizer05>
good
<DocScrutinizer05>
any recommended seller?
<wpwrak>
i could tell you where i'd go in buenos aires ... ;-)
<DocScrutinizer05>
k, it's the cheapest shop then
<wpwrak>
you may also want to check for stock. some may order from an importer on demand and have long delays.
<DocScrutinizer05>
they all seem to be out of stock,
<wpwrak>
i guess they're rather popular :)
che1 has quit [Remote host closed the connection]
norly has quit [Remote host closed the connection]
norly has joined #neo900
illwieckz has quit [Ping timeout: 272 seconds]
norly has quit [Client Quit]
<DocScrutinizer05>
yeah, I however have the choice between "aprox 2 weeks", "2 weeks", "4 weeks"
<DocScrutinizer05>
you got an idea about the memory expansion? how it's implemented?
<DocScrutinizer05>
chip soldered and just enabled on request, soldered on request at purchase time, even plugged?
illwieckz has joined #neo900
<wpwrak>
you just enter a code :)
<wpwrak>
approx 2 weeks means that you'll have it under the x-mess tree :)
<DocScrutinizer05>
:-)
<DocScrutinizer05>
that's the idea :-)
<wpwrak>
(upgrade) google for ds1054z unlock then pick the media you prefer, video or text :)
<DocScrutinizer05>
ok
<wpwrak>
actually there's one option people recommend you shouldn't unlock. 50 mV mode or such. that seems to just make it work worse.
nicksydney has quit [Quit: No Ping reply in 180 seconds.]
nicksydney has joined #neo900
brolin_empey_ has joined #neo900
brolin_empey has quit [Ping timeout: 258 seconds]
<DocScrutinizer05>
yeah. particularly the rain at start of movie ;-)
<DocScrutinizer05>
ok, what's still missing now: microscope, ideally a video microscope with "tele" lens
<DocScrutinizer05>
a think where you can have a 0402 fill the screen when lens is 30cm away from the component
<DocScrutinizer05>
a thing*
<Oksana>
Heh, when you get such a microscope, do not forget to make a promotional video. Like, what's Neo900 made of (remember, Nokia's video about N900?) Maybe, something with software-on-screen and hardware-inside shown side-by-side.
<DocScrutinizer05>
hah!
<DocScrutinizer05>
I doubt santa will bring me such microscope though
<DocScrutinizer05>
I guess they cost an arm and a leg. If you're Beckham, my legs are worth nothing
<Oksana>
Seriously. Ten minutes of dead hardware may be boring, but ten minutes of software side-by-side with blinking LEDs and current running around inside the hardware, to explain what hardware actually does... That would be "cool" like scifi
<Oksana>
An arm and a leg? What about more exact numbers? 500EUR, or 5000EUR?
<DocScrutinizer05>
50000?
<DocScrutinizer05>
no idea
<DocScrutinizer05>
I know that the objective/lens of the kind I seen in such a microscope usually costs more than 500
<DocScrutinizer05>
this instantly brings us to "what's the *purpose* of hw rev?"
<freemangordon>
for example some of the older rx-51 boards have different wiring of audio, extra ethernet, etc
<freemangordon>
(audio) - iirc, it could be something else
<Pali>
if you want to flash bootloader from, you need to know HW revision
<freemangordon>
and it is not only the HW rev, but the machine itself is missing (or rather is some generic omap3) with DT boot
<Pali>
also flashing via Mk II protocol is from userspace (not nolo!)
<DocScrutinizer05>
I thought of a more thoroughgoing discussion of who and why needs hw rev. To start that discussion: I think that during kernel startup some modules (whether monolithic or modular) need info about differences in hw details. You probably safely can assume that the kernel (incl modules) knows about the platform ID implicitly, so a ARM platform kernel won't probe for x86 hardware - this probably needs to get handled in packaging and
<DocScrutinizer05>
configuring the system you flash to the target. But differences in hw between revisions of one particular platform need to get queried during runtime, via hw rev.
Pali has quit [Remote host closed the connection]
<DocScrutinizer05>
the root question is: who defined the semantics and purpose / mode of usage, of stuff like platform ID and hw rev? Did anybody? Where? And is this mandatory and commonly accepted and obeyed?
<DocScrutinizer05>
you probably know that I'm a fan of platform specific kernel, which would mean that all those problems get handled during build time of system and you get a lean and tailored-to-fit kernel and system. I know I'm not in line with the majority here
astr has quit [Quit: Ex-Chat]
<DocScrutinizer05>
BWAHAHA! Russel Hing: >> If we listened to this argument, then we wouldn't ever be able to change anything in procfs or sysfs.<< You'd better not change that anyway, unless absolutely unavoidable. >>And why do we care about closed source?<< Yeah sure!
<DocScrutinizer05>
King evem
<DocScrutinizer05>
muhahaha! >> Every other tag is ignored (as there's no place for it in DT.)<< And that's a problem of ATAGS or towhomitmayconcern then, of course NOT a problem of *DT* ;-P
<DocScrutinizer05>
hmm, actually LKML already started the discussion I asked for
<DocScrutinizer05>
https://lkml.org/lkml/2014/6/18/679 >> Except... that's not what it is. What that revision field was originally invented for was the Netwinder to indicate the _platform_ revision. [...] it /might/ have been a good idea if the creation of that also contained documentation for what was expected in each of the fields, rather than leaving it open...<<
ReqGame has quit [Remote host closed the connection]
<DocScrutinizer05>
hmmm, doesn't sound like "upstream devs seem positive on adding of all the info"
<freemangordon>
there is development, some ~10 more mails
<freemangordon>
but these are still not on lkml
<DocScrutinizer05>
SuSE dude asking for a usecase https://lkml.org/lkml/2014/9/6/66. You can give them LP5523 driver which swaps red and blue LED for a particular *board* revision, and that cannot get done in userland
<DocScrutinizer05>
board revision needs to be known by kernel at module init time
<DocScrutinizer05>
and that's NOT SoC revision!
<freemangordon>
sure
<DocScrutinizer05>
feel free to quote me
<freemangordon>
hopefully there'll be no need
<DocScrutinizer05>
that whole DT idea is based on assumption that you could store the DT on hw platform. It kinda completely loses it's purpose when you "compile in" the DT into your kernel. But I'm not opposing it since that's exactly my preferred way to build a kernel for embedded: kick out cruft and "patch" stuff to fit your particular platform at build time
<DocScrutinizer05>
I think it's delusional to hope for a kernel that compiles to functionally equivalent binaries for a OMAP and a mainframe, and configures itself during kernel init runtime
<DocScrutinizer05>
in my book it's absolutely natural that kernel "options" are configured at compile time and no cruft only needed for handling a mainframe architecture sneaks in to the 6.5MB you got for kernel on your particular embedded system
<DocScrutinizer05>
s/6.5/0.42/
<DocScrutinizer05>
those dudes still think everything is a PC
<DocScrutinizer05>
at least they try to build a PC kernel for everything
<DocScrutinizer05>
very Procrustes
<DocScrutinizer05>
actually LP5523 is a very good example why a kernel driver never can be platform independent, you never know what LEDs the chip drives, so any assignment of LED:[R|G|B] and even kbd:[1-6] is completely arbitrary and platform specific
<DocScrutinizer05>
in my book you'd need a N900-LP5523.ko, in addition / parallel to probably 6 dozen other *-LP5523.ko
louisdk has quit [Remote host closed the connection]
<DocScrutinizer05>
the complete idea of platform independent modules is just tailored to one class of platforms that per definition try to stay compatible in their class: x86 windows PC aka ISA
<DocScrutinizer05>
it hurts to say so, but somehow kernel devels/maintainers sound quite poettering in their "everything has to work everywhere like it does on PC workstation" approach
ReqGame has joined #neo900
<DocScrutinizer05>
DT resp ACPI got invented to describe the tiny differences between different models of that one ISA platform class. I don't see it ever will handle a range of platforms from true one-chip embedded systems up to beowulf clusters and IBM360 mainfraimes
<kerio>
i thought beowulf clusters ran *multiple* linux kernels
<DocScrutinizer05>
yes, they do
<DocScrutinizer05>
fun to "boot the cluster" ;-)
<kerio>
and they were just, you know
<kerio>
PCs
<DocScrutinizer05>
not really, a cluster has fast inter-node links usually
<kerio>
well yeah
<DocScrutinizer05>
but hey, replace "IBM360" by "DeepBlue" and "beowulf cluster" by "voyager space probe"
<kerio>
nothing stops you from installing a fibre channel pci card in your pc
<DocScrutinizer05>
but everything stops me from installing same card to me phone
<DocScrutinizer05>
which is exactly the point
<kerio>
well, with THIS attitude...
<kerio>
neo900 feature request: fibre channel
<DocScrutinizer05>
glue the fibre to the IR window!
<kerio>
brilliant
sparetire_ has joined #neo900
che1 has joined #neo900
<Oksana>
About fibre: if you have some part of Neo900 capable of Gigabit connection, then you might be able to connect fibre to it. Because "common" ways of connecting fibre to electrical device include interfaces between fiber and Gigabit Ethernet. However, the "usual" way of getting Ethernet on N900 was over USB, and USB does not provide high speed. What would you need fibre for, if speed is...
<Oksana>
...already limited by USB?
<DocScrutinizer05>
Oksana: your trolling detector needs service ;-)
<wpwrak>
Oksana: what ? USB quite explicitly provides "High-Speed" :)
<wpwrak>
we won't have Super-Speed, or Ludicrous-Speed, though. but then, the latter would be quirky anyway.
<Oksana>
480 Mbit/s is a bit slower than Gigabit Ethernet, I guess. If USB is fast enough, then sure, get microUSB-to-Ethernet adapter, and then hunt down fibre-Ethernet adapter. I can even try to search for fibre-Ethernet adapter :-)
<wpwrak>
if you use FDDI, the speed will be sufficient. and as an added bonus, it has "fiber" in the acronym already :)
jonwil has joined #neo900
norly has joined #neo900
<kerio>
DocScrutinizer05: people that don't know me take me seriously
<kerio>
i dunno
paulk-collins has quit [Quit: Quitte]
Pali has joined #neo900
mvaenskae has joined #neo900
ReqGame has quit [Quit: Leaving]
<Oksana>
Whom should I contact about bug related to the internal channel? ;-)
<DocScrutinizer51>
sorry?
<Oksana>
Okay, it may be bug in my IRC client ;-)
Oxyd76 has quit [Remote host closed the connection]