<pabs3>
DocScrutinizer05: wrt phone calls and Debian, we have both oFono and FSO in Debian, probably need some front-ends for that from SHR or MeeGo or something
<DocScrutinizer05>
DSS_DATA6 not listed as used in schematics
<DocScrutinizer05>
pabs3: yes, for systems other than maemo, such diealer will be needed
<pabs3>
some Debian folks use emacs for this on gta02 :) (front-end to FSO, IIRC)
<DocScrutinizer05>
yes, e.g Paul Fertser
<DocScrutinizer05>
[2015-02-13 Fri 14:32:47] <DocScrutinizer05> paulfertser known to use GTA02 with a dialer based on emacs(!!!) since years
xes has quit [Quit: Going offline...]
<DocScrutinizer05>
wpwrak: ((8bit)) depending on representation of our current framebuffer which afaik has 3*8bit per pixel, and the output modes the OMAP video contrller can do, it might actually be possible to use the framebuffer content we got now and simply stream it out at triple pixel rate with only 8 bit per pixel
<DocScrutinizer05>
what would need careful evaluation are side effects this frankenstein video controller config has on other hw supported functions like bitblit and dunno what
<kerio>
how do you do 8 bits per pixel?
<DocScrutinizer05>
effectively our framebuffer wouldn't operate in 800*480*24 but in 2400*480*8
<kerio>
oh, i see what you mean
<wpwrak>
DocScrutinizer05: mmh, don't we already have time-division multiplexing there ? after all LCD_CDP is 8 bits wide
<wpwrak>
(sounds like what you're describing)
<DocScrutinizer05>
it's 3 differential serial data lines plus one clock line
<wpwrak>
ah, i see
<DocScrutinizer05>
I dunno if those serial lines/lanes are actually R, G, B or this is some completely different weird format
<DocScrutinizer05>
the whitepaper you found suggests it's something we don't even want to start trying to decode
<wpwrak>
yeah, i was just about to say that this would then be similar to that RBI critter. so that's what it is
<wpwrak>
or DSI
<DocScrutinizer05>
I'd use those 8 lines as parallel 8 bit, freeing up the needed clock and hysnc/vsync on 3 other pins
<wpwrak>
and then three latches and a 24 bit DAC ?
<DocScrutinizer05>
given the OMAP supports such mode at all
<DocScrutinizer05>
yes, exactly
<DocScrutinizer05>
IF thsi was actually R, G, B serial one color per lane, we could decode it
<DocScrutinizer05>
but I massively doubt it is
<wpwrak>
seems that there are commands in the mix as well. hence the FPGA to fish them out :)
<DocScrutinizer05>
yes
<DocScrutinizer05>
that's where I bail out
<DocScrutinizer05>
not going to build a FPGA (!!! already) for decoding a protocil and command set I gotzilch specs for
<wpwrak>
just reading the feature list of DSI (in the TRM) looks scary
<DocScrutinizer05>
more than
<wpwrak>
ah, where's the pioneet spirit ? to boldly go where no sane man has gone before :)
<wpwrak>
but i really wonder if VGA out is really worth all that trouble. i mean if we already have CVBS (S-Video ?), the "external screen" use case seems to be covered for most cases. nobody would want to use the neo900 for movies (and we don't have the resolution anyway)
<DocScrutinizer05>
err, I *do*
<DocScrutinizer05>
:-)
<wpwrak>
at such a pitiful resolution ?
<DocScrutinizer05>
and CVBS is just fine for that. What's not ok over CVBS is workstation
<wpwrak>
VNC over SSH ? :)
<DocScrutinizer05>
errr, the resolution is PAL, like any TV program
<DocScrutinizer05>
wpwrak: where's the monitor with "VNC" input?
<wpwrak>
ah, it's the time tunnel again. here, we have 2015 and PAL is kinda obsolete :)
<DocScrutinizer05>
and you can't have better than PAL via CVBS
<wpwrak>
any truly "smart" tv (i.e., with external linux box, not built-in spy- and adware)
<DocScrutinizer05>
we're not talking TV with smartboix here
<wpwrak>
yup. that's what i mean. for video, the neo900 just doesn't seem to be the right device.
<DocScrutinizer05>
the usecase is to hook the thing up to a monitor, mause and kbd and do office jobs
<DocScrutinizer05>
nobody even thinks about playback of HD videos
<DocScrutinizer05>
the OMAP can't do that anyway
<DocScrutinizer05>
and tbh I don't gibe a * about HD video
<DocScrutinizer05>
give*
<wpwrak>
oh, they're nice to look at
<DocScrutinizer05>
for videos I'm absolutely happy with PAL on a decent TV
<DocScrutinizer05>
but I'm not going to write letters on a 480*512 screen
<DocScrutinizer05>
or what been the horizontal resolution of PAL? 600?
<wpwrak>
wasn't it 640-ish ?
<DocScrutinizer05>
possibly
<ds2>
horizontal res. for PAL and NTSC is about 640-720
<wpwrak>
ah no, even 704/720, according to wikipedia
<DocScrutinizer05>
if it woukd be, on the crappy CVBS out of N900. Anyway DM3730 allegedly has better CVBS signal quality
<ds2>
depending on overscan
<ds2>
and writing letters on 320x200 isn't that hard. the old atari/commodores/etc are in that range
<DocScrutinizer05>
yeah, you also can write books on Braille terminal
<DocScrutinizer05>
but I won't wase money and time on designing a output that's even worse than CVBS
<DocScrutinizer05>
the purpose of that auxiliary video output is to deliver at least the original 800*480, possibly higher
<kerio>
DocScrutinizer05: fwiw, the n900 can decode 720p video, when overclocked a bit
<wpwrak>
it seems that we can't do a lot better anyway. i mean, even 1024x768 feels small once you're used to a modern monitor
<kerio>
and tbh, anything other than 800x480 is somewhat useless
<DocScrutinizer05>
kerio: so what? it can't display them
<wpwrak>
not sure what kind of stuff you have. some CRT, i guess ? or a 10" lcd ?
<kerio>
programs you've got installed won't use other resolutions properly, i feel
<kerio>
like
<DocScrutinizer05>
wpwrak: sorry, you completely lost me
<kerio>
it's not a system meant for multi-monitor support anyway, so mirroring is the only good option
<kerio>
question: is 800x480 letterboxed to 800x600 an option?
<DocScrutinizer05>
why do you ask?
<kerio>
idk how many monitors will support 800x480
<wpwrak>
kerio: would be interesting if 800x480 could be output as CVBS (with suitable horizontal lossy compression)
<kerio>
cvbs is pretty awful for text
<DocScrutinizer05>
the N900 CVBS can't do 480 horizontal
<kerio>
really? :O
<wpwrak>
CGA, all is forgiven :)
<wpwrak>
oh, and for people who REALLY want to use the neo900 as a workstation, there are some USB-to-<video> dongles. they probably also have a much better resolution. you already have a bunch of external devices to make all this work, kbd, mouse, possibly a hub, the TV, some adapter cable, so one more dongle hardly matters
<DocScrutinizer05>
don't argue with me about customer requests
<wpwrak>
as an added benefit, that dongle would be on a "nice" interface, avoiding extra capacitive loading of high-speed lines
<ds2>
so you can scale the 800x480 to the analog video output
<DocScrutinizer05>
which is done
<DocScrutinizer05>
this doesn't solve the problem that CVBS is crap and doesn't allow more than 500 vertical and "filters" anything above 400-500 horizontal thanks to bandwith
<DocScrutinizer05>
and on N900 even color bleeding like mad. In xchat active/higlighted tabs in red on black simply are not readable
<DocScrutinizer05>
users requested a way to attach a decent monitor to the device, so you get some semi-usable resolution and quality for word processor etc
<DocScrutinizer05>
and they said they would pay twice as much for the device when it comes with such feature
<DocScrutinizer05>
so much for requirement specs
<DocScrutinizer05>
we probably could get away with 565, bit not with resolutions < 800*600 or frame rates < 20/s
<DocScrutinizer05>
but*
<DocScrutinizer05>
these are the requirements, and you seen the circuit limitations which most likely forbid using 24 bit wide video out from OMAP
<DocScrutinizer05>
ideally we'd find a chip that converts 3lane MIPI DSI to VGA or HDMI or whatever
<DocScrutinizer05>
which would allow using the already needed and existing video bus from OMAP to LCD
<DocScrutinizer05>
without muxing
<DocScrutinizer05>
and LCD would even work in mirror mode when output is 800*480
<DocScrutinizer05>
for higher (and lower) resolutions we simply shut down LCD
arcean has quit [Quit: Application terminated!]
<DocScrutinizer05>
when we can't do 800*600 or better, it's not worth it
<DocScrutinizer05>
complete calibration cycle, using calibrate-bq27k.sh. Output of a parallel bq27200.sh: http://privatepaste.com/a095c4d47e
<DocScrutinizer05>
alas LMD is still off since it afjusts a max 8% (iirc) per learing cycle. So I start a new lerning cycle right away
<DocScrutinizer05>
kerio: ((n900 can decode 720p video, when overclocked a bit)) Neo900 doesn't need overclocking for that. And it even less needs it when we don't need to scale it down to 800*480 but could actually output it
<DocScrutinizer05>
so yes, I'd actually be happy when this battery had (100 - 40 +7)% of 2052 mAh
<DocScrutinizer05>
but actually those 2052 mAh are from first learning cycle where it switched from 55% to 7%
<DocScrutinizer05>
meanwhile LMD is down to some 1600someting
<DocScrutinizer05>
NB LMD only ajusts a 8% mac per learning cycle
<DocScrutinizer05>
max*
<DocScrutinizer05>
ok, after this learning cycle it already looks honest
<DocScrutinizer05>
0x13 - 0x12: 7683 LMD Last Measured Discharge High - Low Byte 3.57 µVh (1) R
<DocScrutinizer05>
*3.57 / 20 = 1375 mAh
<DocScrutinizer05>
but maybe this battery actually isn't _that_ fresh anymore. It's a Polarcell of unknown history
<DocScrutinizer05>
so I might end at 800mAh when continuing calibration until LMD stabilizes
* Sicelo
no longer knows the state of his batteries because of external charger
<DocScrutinizer05>
bfore this last learning cycle battery had LMD of 1571 mAh
<DocScrutinizer05>
~(100 - 40 +7)/100 * 1571
<infobot>
1052.57
<DocScrutinizer05>
this sounds absolutely correct
<DocScrutinizer05>
~1375 / 1571
<infobot>
0.875238701464
<DocScrutinizer05>
~1571 /1375
<infobot>
1.142545454545
<DocScrutinizer05>
hmm, if my math doesn't suck, it seems to adjust a 13 or 14% per learning cycle
<DocScrutinizer05>
ShadowJK: au secours!
<DocScrutinizer05>
ShadowJK: wasn't that 6.25% or 8% max?
<ShadowJK>
i think it was 12?
<DocScrutinizer05>
aaah ok
<ShadowJK>
6.25 is edv1
<ShadowJK>
ish
<DocScrutinizer05>
aaah yes
paulk-collins has quit [Remote host closed the connection]
<ShadowJK>
when switching to a new N900 I usually estimate capacity of battery, write it to AR register, then execute the transfer AR to NAC command
<ShadowJK>
which speeds up things.
<DocScrutinizer05>
oooh, this actually works? I thought about exactly that ~2h ago and came to the conclusion that it probably failed when I tried it or otherwise I had made a script of ot ;-)
<DocScrutinizer05>
it*
<DocScrutinizer05>
the equation ala "~(100 - 40 +7)/100 * 1571" seems to yield a good estimation of true battery capacity
<ShadowJK>
especially measuring ir from full to empty
<DocScrutinizer05>
yes, probing for delta-V/delta-I in short window is very informative
<DocScrutinizer05>
even better was recording of impulse response
<ShadowJK>
.oh, i have that write to ar and stuff in DANGEROUS on enivax.net/jk/n900/
<DocScrutinizer05>
cool, thanks!
<DocScrutinizer05>
ugh sorry, still "booting brain". Now that's NAC, not LMD which can get set
<freemangordon>
hmm, 1799 mAh :D
<DocScrutinizer05>
2054mAh (ILMD) - 12% ?
<freemangordon>
whatever it is, that can't be real
<ShadowJK>
yes, but if i remember right, if you start with 2000 mAh it takes 4 or so cycles, if you guess capacity right abd write it ti ar, transfer ar to nac, it takes one cycle
<DocScrutinizer05>
see last 15h of chanlog, A learning cycle can't adjust LMD by more than 12%
<freemangordon>
oh, I see
<freemangordon>
that makes sense, thanks
<DocScrutinizer05>
that's why I just completed 4th learning cycle in sequence
<DocScrutinizer05>
and seems I'm still off
<DocScrutinizer05>
ShadowJK: sounds good but I can't follow
<ShadowJK>
Basically it bypasses the 12% limit
<DocScrutinizer05>
NAC is the currently available capacity. AIUI the chip will adjust LMD by no more than LMD(last)+/-12%
<ShadowJK>
but you're already there after 4 cycles so no point
* DocScrutinizer05
feels like reading bq27xxx docs a 140th time
<DocScrutinizer05>
;-)
<DocScrutinizer05>
very easy to forget all the details in as short as 24 months
<ShadowJK>
IIRC, in practice what happens seems to be that when VDQ is raised, present NAC is copied to a temporary register. Normally, this happens when full charge is detected, and that copies LMD to NAC. AR to NAC transfer also raises VDQ, and NAC is copied to temp register. On reaching EDV1, the LMD adjustment is done from the temp register
<ShadowJK>
Maybe it's nit implemented exactly lime that, but iirc in practice it behaves like that
<ShadowJK>
losing connectivity, bbiab
<DocScrutinizer05>
ShadowJK: makes sense
<DocScrutinizer05>
>> WRTNAC is used to transfer data from the AR registers to NAC. Other registers are updated as appropriate. This command is useful during the pack manufacture and test to initialize the gauge to match the estimated battery capacity.<<
<DocScrutinizer05>
the datasheet is basically crap
<Wizzup>
02:07 <+DocScrutinizer05> the usecase is to hook the thing up to a monitor, mause and kbd and do office jobs
<Wizzup>
I have that use case too
<Wizzup>
usb to display is possible, I guess (I have one at home that works)
<DocScrutinizer05>
Wizzup: yes, but alas it seems OMAP3 and N900 compatibility (enforced by display and other details to adhere to) forbids a decent video out
<Wizzup>
okay
<Wizzup>
well, I guess the usb displaylink option is doable
<DocScrutinizer05>
USB->display *sounds* good, but the tests some community menbers (javispedro?) did in N900 were not really promising. No driver, no refresh rate, poor resolution, and trouble with drivers
<Wizzup>
I have one. It's DisplayLink stuff
<Wizzup>
Can do quite high resolutions
<Wizzup>
But yes, it's somewhat slow.
<Wizzup>
Don't expect to watch full hd videos on it, but it definitely works
<Sicelo>
with N900?
<DocScrutinizer05>
on Linux? on OMAP?
<Wizzup>
no, I have not tried that.
<Wizzup>
but yes, on Linux.
<Wizzup>
in my case, on one of the early arm chromebooks
<DocScrutinizer05>
fair enough
<Wizzup>
so not specifically on omap
<DocScrutinizer05>
well ARM at least
<Wizzup>
yes
<DocScrutinizer05>
and linux
<Wizzup>
(yep)
<DocScrutinizer05>
which suggests there must be drivers that somewhat work
<Wizzup>
so their usb 3.0 uses new 'compression' and some other stuff that no one has been able to RE
<Wizzup>
iirc
<DocScrutinizer05>
sure, and we have no USB3 so not relevant :-9
<Wizzup>
yep
<Wizzup>
just saying - perhaps one of the 'latest' usb 2 devices does something similar
<DocScrutinizer05>
I think they are supposed to be backward compatible to DL2+
<DocScrutinizer05>
anyway the driver detects "changes on display" means frame diff means at least two buffers in RAM, and it constantly searches fro sweetspot between available CPU load and USB bandwidth, which means we will be happy to have a 1GHz CPU and a 1GB RAM
<DocScrutinizer05>
with notorious RAM shortage and the abysmal bandwidth on USB host hack of N900, I can see why javispedro wasn't excited when he tested that stuff back when
<DocScrutinizer05>
also drivers for sure were not exactly mature a 3 or 4 yeras ago
<DocScrutinizer05>
yes, it's USB3 but claims to be back comp to 2
<DocScrutinizer05>
alas no audio
<Wizzup>
(but perhaps the dl implementation is not like that)
<Wizzup>
well, if you're going to power it externally, a usb hub should work
<Wizzup>
(or even an externally-powered usb hub)
<Wizzup>
then you can also plug in those 2$ usb-ethernet thingies
<Wizzup>
otoh, at some point you'll just be carrying too many cables ;-)
<DocScrutinizer05>
it has a downlink USB, so i'd rather hack this device to provide reverse uplink power to charge neo900 and power downlink USB to power up any hub there
<DocScrutinizer05>
let's see what else we can find
<kerio>
i thought uplink power was out of specs for usb
<DocScrutinizer05>
wtf?! "ports: 2 USB 3.0 charging ports and 1 USB 2.0 charging port; HDMI; VGA; Combo Headphone/Microphone" WHERE'S THE !GB ETHERNET YOU ADVERTISED?
<DocScrutinizer05>
ok, seems they forgot to list a few, check out the photos
<Wizzup>
it's in the picture at least
<DocScrutinizer05>
I just notice a feeling creeping up that makes me want to say "video connection on Neo900 dropped in specs. Obsoleted by new spec 'support for displaylink'"
<DocScrutinizer05>
(this is *video*, not CVBS which will stay of course)
<Wizzup>
just make sure you mention only for their earlier/older versions specifically
<DocScrutinizer05>
let's see what further tests will yield
<Wizzup>
because displaylink otherwise is not a nice company to be associated with (gpl violations, stating linux support for newer gens when they don't offer it, etc)
<DocScrutinizer05>
Wizzup: (test with some arm) much appreciated
<Wizzup>
I can test the dx.com one I linked - I have it in front of me
<DocScrutinizer05>
:-)
<Wizzup>
will try it later today
<DocScrutinizer05>
no hurries
<DocScrutinizer05>
freemangordon: Pali: how difficult is it generally to reassign a (named) GPIO to a different physical pin? can that get done in DT, or in /sys or what's the deal?
<DocScrutinizer05>
is it hardcoded into our closed blobs?
<Pali>
what do you mean with reassing gpio?
<Pali>
changing gpio number in kernel?
<DocScrutinizer05>
example: let's say I move kbd_slider from GPIO_71, Slide_SW to some other physical pin of SoC
<DocScrutinizer05>
i.e. I connect the slider Hall switch to anothrer physical GPIO. What's the impact, what's the fix?
<Pali>
basically, modern userspace does not see or touch gpios... kernel exports some high level interface (button, switch, etc) to userspace
<Pali>
also maemo kernel has for it own "interface" for userspace
<Pali>
userspace does not see gpio number, it see switch, input event, button, ...
<DocScrutinizer05>
so kernel API would hide any such changes?
<Pali>
and now all these definitions are done in DT
<Pali>
yes, kernel api hides it... but if some userspace application (under root) want raw access to gpio, kernel give it
<Pali>
I do not know if there are some maemo application which use it...
<DocScrutinizer05>
iow MCE would still access some virtual GPIO_71 just it got remapped to another physical pin by DT?
<Pali>
mce is using also interface via /sys/ something gpio_switch/<name_of_switch>/
<DocScrutinizer05>
yes
<Pali>
it is not using gpio nums
<Pali>
so it just needs correct mapping number <--> name in kernel
<DocScrutinizer05>
so you think userland wouldn't even notice, and kernel handles/abstracts it on DT level?=
<DocScrutinizer05>
what about GPIO that are used by kernel drivers, like "card detect" (battery lid magnet) for MMC1 driver?
<DocScrutinizer05>
which makes me wonder: did *anybody* ever use the debug::sleep right and left kbd backlight LEDs? The ones that signal master-clock-enable (SYS_CLKREQ) and SYS_OFF_MODE (CPU stopped?)
<DocScrutinizer05>
seems they are clearly debug tools only needed during kernel development times where no zzztop and similar tools are available yet
<DocScrutinizer05>
it enables the debug LEDs in kbd backlight
<DocScrutinizer05>
you may have seen them in R&D mode
<Pali>
that keyboard blinking in R&D mode?
<DocScrutinizer05>
yes
<DocScrutinizer05>
one side lights up when master system clock is enabled (by whatever subsystem), the other side aiui only lights up when CPU isn't in idle state
<DocScrutinizer05>
they're pretty much in sync most of the time, and show a general "system busy"
<DocScrutinizer05>
I wonder if any devel will need them on Neo900
<DocScrutinizer05>
and if yes, in which usecase
<DocScrutinizer05>
since they most likely will see change in hw design anyway
<DocScrutinizer05>
maybe simply drop them, maybe replace them by some ultralow-power permanently enabled red LEDs in a engineering area of board
<DocScrutinizer05>
my tests suggest you can operate such LEDs with as low as 50uA and still they are clearly visible in dim light
<DocScrutinizer05>
makes no sense to disbale them then, since they signal "system using dozens of MILLI-amperes" anyway
<DocScrutinizer05>
of course such red lowpower led must get placed in plain sight, not behind a kbd keymat
<DocScrutinizer05>
I got some more of this critters on my todo list, for modem activity, several power supplies and genrally subsystems you might want to know *for good* when they are active
<DocScrutinizer05>
e.g IR LED comes to mind
<DocScrutinizer05>
VBUS voltage
<DocScrutinizer05>
NFC
<DocScrutinizer05>
WLAN?
<DocScrutinizer05>
modem for sure - status led
paulk-aldrin has joined #neo900
MonkeyofDoom has joined #neo900
mvaenskae has joined #neo900
arcean has quit [Quit: Application terminated!]
arcean has joined #neo900
<DocScrutinizer05>
wpwrak: ((PAL resol H)) >>Die Video-Bandbreite, d. h. die Bildschärfe in horizontaler Richtung verändert sich aus historischen Gründen jedoch nicht: es bleibt bei 5 MHz, was ca. 560 Pixeln entspricht<< (PALplus: http://de.wikipedia.org/wiki/PALplus)
<DocScrutinizer05>
N900 is worse, it can do maybe 480
<DocScrutinizer05>
historically TV display H resol is metered in visible lines which is not exactly pixel/2
mvaenskae has quit [Ping timeout: 264 seconds]
<wpwrak>
how about s-video ? according to the trm, the omap can do that, too. and it may be a little better than composite. seems that it would still be constrained to legacy tv quality, but at least better at that
<DocScrutinizer05>
yes, OMAP can do S-video
<DocScrutinizer05>
it#s supposed to be slightly better due to separation between color and brightness, but is not compatibel to AV jack
<DocScrutinizer05>
and quality for sure is not worth pondering how to add a S-video jack
<DocScrutinizer05>
OK >>...Aufgrund des separat übertragenen Chrominanzsignals erlaubt S-Video gegenüber Composite Video eine höhere Bandbreite für die Helligkeitsinformation<<
<DocScrutinizer05>
but I doubt the OMAP will do better on luminance just because we use S-video. I already said it seems that at least OMAP3430 is worse than 5MHz bandwidth
<DocScrutinizer05>
translates to "rather <480 than >550 H"
<DocScrutinizer05>
maybe some amps and EQ could do wonders
<kerio>
how do you equalize video? :o
<DocScrutinizer05>
would also help for parasitary capacitance of cable
<DocScrutinizer05>
kerio: simple, emphasize the range between maybe 4 and 5MHz
<DocScrutinizer05>
where original N900 CVBs sucks
<DocScrutinizer05>
even better would be a decent low impedance buffer amp I guess
Humpelstilzchen has quit [Remote host closed the connection]
<DocScrutinizer05>
but ll that doesn't make CVBS a candidate for workstation display
<DocScrutinizer05>
it stays at ~600*600
<DocScrutinizer05>
max
<DocScrutinizer05>
and that's already with *massive* vertical overscan which most TV/moni can't do
<DocScrutinizer05>
wpwrak: ((and quality for sure is not worth pondering how to add a S-video jack)) we *might* design in a few DNP 0R to change AV jack from audio-L,audio-R,CVBS to audio-Mono,Y,C. But such change, aside from needing a very special adapter cable, will defeat use of AV jack for standard headphones, due to no mux for one of the two S-Video signals
<wpwrak>
okay, sounds like a dead end then. just thought to mention it since i saw the s-video in the trm. i don't know much about all that video stuff ...
<DocScrutinizer05>
I don't feel like adding a set of mux that change stereo to mono and Right audio to S-Video
<DocScrutinizer05>
wpwrak: much appreciated. Thanks
<DocScrutinizer05>
actually it moves focus onto that resistor-capacitor network that creates CVBS from the few pins on OMAP. we should review that stuff
<DocScrutinizer05>
and, as already mentioned, allegedly DM3730 has better signal on those pins, according to TI
<DocScrutinizer05>
won't hurt either :-)
<wpwrak>
seems that you'll find a good use for that video trigger on your scope ;)
<DocScrutinizer05>
hmm, I wonder if it actually has video trigger
<wpwrak>
yeah, that's what engineering was like before everything had to be copyrightable and patentable ;)
<wpwrak>
i checked, it still does :)
<DocScrutinizer05>
wow. But lemme tell ya, decent metering of video signals is a b*tch sincefirst of all you need decent source signal aka test pattern aka picture
<DocScrutinizer05>
or you'll just see the "noise" between the sync signals
<DocScrutinizer05>
wouldn't want to read a syslog on that
<wpwrak>
DMA may not make a big difference. the core is probably fast enough to bang GPIOs as fast as they will go.
<DocScrutinizer05>
ohwell, that displaylink stuff looks promising, on a second thought
<wpwrak>
;-)
<DocScrutinizer05>
just we can help the CVBS a lil bit too
<DocScrutinizer05>
so it's not at the edge to unusability like on N900
<DocScrutinizer05>
I however wonder if *anybody* would be interested in a at least theoretical S-video option
<DocScrutinizer05>
guess no
<DocScrutinizer05>
but dang, that 1024*768 looks pretty
<DocScrutinizer05>
given it's done by "bitbanging" a SD card interface
<DocScrutinizer05>
hmmmm, maybe we should send DVB_T signals from a 3cm wire attached to a R-2R ladder attached to display data lines? ;-)
<DocScrutinizer05>
the encoder this mad guy wrote would need some steamlining though
<DocScrutinizer05>
and he never released the source for the DVB encoding, only for the "modulation" done on graca framebuffer content
<DocScrutinizer05>
maybe he simply recorded some baseband digital data from a TV station and encoded it to his "transmitting monitor" approach
<DocScrutinizer05>
s/encoded/modulated/
<wpwrak>
(1024x768) yeah, i'm quite proud of it :) however, what's happening under the hood is not quite as nice. it preloads cpu caches, disables all background DMA (e.g., for LCD refresh), interrupts too, of course, and so on. so the SoC is really dedicated 100% to generating this image.
<wpwrak>
could perhaps be optimized a bit to let at least some background activity happen, but it would still be rather intrusive
<DocScrutinizer05>
(100% dedicated) well, in the Z80 days we created and decoded audio signals this way, to store data on cassette recorder: SuperTape
<bencoh>
hmm btw, isnt it a digital oscilloscope ?
<DocScrutinizer05>
well, yes
<DocScrutinizer05>
why?
<bencoh>
funny they kept 525l/625l
<DocScrutinizer05>
err? why?
<bencoh>
because it doesnt really exist on a physical screen
<DocScrutinizer05>
of course it exists on screens
<bencoh>
?
<bencoh>
at least not on TVs, afaict
<kerio>
analog video transmission doesn't have the concept of horizontal resolution, right?
<DocScrutinizer05>
when it wouldn't exist, what is it then?
<MonkeyofDoom>
why is there so much persistent state in the N900 hardware?
<MonkeyofDoom>
I booted maemo once and now I can't get wl1251 to load firmware under Arch for the life of me
<kerio>
LOL
<DocScrutinizer05>
also what means "on screen"? this is not a camera, this is a tool to analyze electrical signals. Sure there's a thing like PAL 525i which for comes from N900 AV output
<bencoh>
kerio: right, it only has vertical resolution
<DocScrutinizer05>
it has a concept of bandwidth though
<DocScrutinizer05>
MonkeyofDoom: there's pretty few "persistent state" in N900 hw
<DocScrutinizer05>
I know how composite video works
<DocScrutinizer05>
I just was temporarily puzzled what they meant by 480p
<bencoh>
oh
<MonkeyofDoom>
DocScrutinizer05: there's definitely something that doesn't get reset with a mere reboot
<DocScrutinizer05>
e.g. VGA would qualify as 480p
<bencoh>
I trully believe they dont mean much than "480lines"
<bencoh>
yeah
<bencoh>
like "1080p" is commonly defined as 1920x1080
<bencoh>
much more*
<bencoh>
and if they insist on having 525 lines in so-called "480p" then they just mixed everything :D
<DocScrutinizer05>
they simply mean "NTSC non-interlaced"
<kerio>
MonkeyofDoom: remove the battery for like
<kerio>
more than 20 seconds
<DocScrutinizer05>
MonkeyofDoom: depends on your reset, no?
<kerio>
~n900-full-reset
<infobot>
somebody said n900-full-reset was when the user presses the PWRON (power-on) button for 8 seconds and removes the battery in the next 8 seconds, the TPS65950 enters NO SUPPLY state instead of BACKUP state, even if a valid backup battery is present. In such a situation, the backup domain registers are also reset, along with the VRRTC domain registers.
<DocScrutinizer05>
yes, not every subsystem gets a hw reset on a powercycle, since not all systems *are* powercycled
<MonkeyofDoom>
that's what I mean
<DocScrutinizer05>
e.g. indicator LED controller LP5523 is powered directly from battery, and the reset line (if it has any) is controlled by a GPIO of CPU, so not forced during CPU power cycle
<kerio>
ah fuck
<kerio>
this battery feels a bit swollen
<DocScrutinizer05>
so a real power down *may* reset most of subsystems. A mere reboot for sure doesn't
<DocScrutinizer05>
e.g. acellerometer needs a power cycle when it gets stuck. A warm reboot won't help
<MonkeyofDoom>
power down meaning shutdown, or battery removal?
<DocScrutinizer05>
LP5523 when ever getting stuck hard, needs battery removal
<DocScrutinizer05>
power down means shutdown. battery removal means just that
<MonkeyofDoom>
mm
<MonkeyofDoom>
I've been powering down
<MonkeyofDoom>
but wl1251 seems upset
* MonkeyofDoom
boots maemo again
<DocScrutinizer05>
lemme check if wl1261 is battery powered
<DocScrutinizer05>
yes, it is
<DocScrutinizer05>
and it doesn't even have a RESET input
<DocScrutinizer05>
all it has is a PMEN aka WLAN_ENA input to power it down
<MonkeyofDoom>
hm
<DocScrutinizer05>
seems you failed to shut down maemo gracefully, and your alternative OS has no proper init for the WLAN_ENA pin to power down the wl1251
<MonkeyofDoom>
could be, I'm running a 3.5.3 kernel on Arch but thought maemo had shut down fine
<DocScrutinizer05>
I dunno if maemo is supposed to set all GPIO to inactive state during shutdown
<DocScrutinizer05>
usually CPU should do this on power-down anyway
<kerio>
DocScrutinizer05: how much should i power off a n900 without battery for every capacitor to be discharged?
<DocScrutinizer05>
hah! an hour
<DocScrutinizer05>
or 10
<kerio>
omg
<kerio>
ain't nobody got time for dat
<DocScrutinizer05>
well, usually nobody cares about
<DocScrutinizer05>
why would you?
<DocScrutinizer05>
btw backup battery *might* also be a capacitor
<DocScrutinizer05>
for sure it has a parallel buffer capacitor
<DocScrutinizer05>
so the correct answer is "1 year"
<DocScrutinizer05>
if you're asking how long until all (short term) persistent states are returning to their idle default, that's a minute or two maybe
<DocScrutinizer05>
and surprisingly the last thing probably is RAM
<DocScrutinizer05>
it takes quite a while until a RAM wakes up with all zeroes
<DocScrutinizer05>
though this differs a lot between different builds of DRAMs
<DocScrutinizer05>
some can retain some partial info even after 10 minutes
<DocScrutinizer05>
which doesn't mean that _all_ bits are correct even after as short as one second without proper power
<kerio>
ofc, ofc
<DocScrutinizer05>
((short term)) saying this since flash - and generally all erasable ROM - also is an array of capacitors
<DocScrutinizer05>
supposed to keep charge for at least 10 years ;-)
ashneo76 has quit [Ping timeout: 264 seconds]
ashneo76 has joined #neo900
<DocScrutinizer05>
unless you worn it out by too many page erases which damage the isolation layer so the charge doesn't stay anymore and after a day or a week the flash builds up incorrect data bits
o_tobyy has joined #neo900
<bencoh>
"supposed to keep charge for at least 10 years" huhu
<bencoh>
that's not much :>
<bencoh>
(if you intend to keep data)
<DocScrutinizer05>
indeed
<bencoh>
basically keeping a disk-on-key in a safe for legacy or legal purpose is a terrible idea :)
<DocScrutinizer05>
yes
<DocScrutinizer05>
use magnetic HDD for this
<kerio>
was any data ever retained after thousands of years that wasn't sculpted in stone?
<DocScrutinizer05>
or DVD
<kerio>
without rewriting it, i mean
<DocScrutinizer05>
though those also are not guaranteed to be stable
<DocScrutinizer05>
kerio: yes, it seems paper and pergament are stable for 1000s of years if stored correctly. So is ink when it's the right type
<DocScrutinizer05>
sorry parchment
o_tobyy has quit []
<DocScrutinizer05>
cave panting are sometimes tens of 1000s of years old
<DocScrutinizer05>
paintings
mva has quit [Ping timeout: 244 seconds]
<DocScrutinizer05>
fact is: hardly anybody ever worries about durability of what they write down or sketch or whatever method they use to store info. It just happens that in former times the commonly used methods were incidentally more stable against deterioration than in our highly technical world
mva has joined #neo900
<DocScrutinizer05>
plus we simply don't know much of any less long living storage methods possibly used in former times, since... they vanished ;-)
<kerio>
our highly technical world has cheap, perfect copying
<kerio>
also, dropbox
<DocScrutinizer05>
particularly funny: invoice/receipt needed to claim that 5 year warranty, but printed on thermopaper that irreveribly fades out after < 2 years
<quatrox>
I think some backup companies use analogue film (e.g. 8mm)
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
silver ocxide in plastic is pretty stable
<bencoh>
kerio: papyrus ?
<kerio>
bencoh: sure, unless you're storing it in alexandria :>
<bencoh>
and a lot of parchments as well
<bencoh>
haha
<wpwrak>
i would settle for ceramics, punch-carded. stored in a shock-proof environment. if that can't be achieved, put a sheet of gold next with the same information to it.
<wpwrak>
of course, if you're an optimist about technological progress, just radio it with maximum energy into a particularly non-dense region of space. future generations can then use their ftl drives to catch up and receive it :)
<kerio>
LOL
<bencoh>
:S
<bencoh>
:D
<DocScrutinizer05>
hmm, simply send it to a distant planet system and receive the echo in due time
<DocScrutinizer05>
actually when you send it not that much focused, you'll receive echoes every few years
che12 has quit [Remote host closed the connection]
che1 has joined #neo900
che1 has quit [Remote host closed the connection]
che1 has joined #neo900
raccoon_ has quit [Ping timeout: 272 seconds]
che1 has quit [Remote host closed the connection]
che1 has joined #neo900
che1 has quit [Remote host closed the connection]
che1 has joined #neo900
paulk-aldrin has quit [Remote host closed the connection]