<kristianpaul>
ha, i found the root cause for the accum int signal not asserted... i did a bad asumption about ignoring bus cycle signal from  avalon to wishbone port...
<kristianpaul>
oh well
<kristianpaul>
damn, can be? in namuru i need to read/qeite some registers  to clean some flags...
<kristianpaul>
i cant see where is it pointed in the documentation.. but
<kristianpaul>
cross fingers and hope Artyom to confirm this
<kristianpaul>
well, if this is true i can implemnent id to fit milkymist csr bus workflow, but is tricky to cath it from avalon as current it is..
<kristianpaul>
"real soon now " :-)
<kristianpaul>
300 more and i can buy a ephel ;)
<wolfspraul>
kristianpaul: should we remove the "real soon now"?
<wolfspraul>
I mean the whole line?
<wolfspraul>
I didn't wnat it there but Sebastien added it...
<wolfspraul>
if there's something I don't like, it's announcements
<kristianpaul>
well, the soon now is kinda odd imho
<wolfspraul>
thanks, that helps
<wolfspraul>
removed
<wolfspraul>
:-)
<kristianpaul>
like, is here but not can touch it !!, just wait a bit ;-)
<kristianpaul>
ok
<kristianpaul>
also i asume you had a BIG annoucment for the this rc3?
<wolfspraul>
I first want to actually have it
<kristianpaul>
considering new stuff on the box and all software improvements since the EDK era :)
<kristianpaul>
not to much effort i think all is already wrritten just need to be organized.
<kristianpaul>
those videos from xiangfu are a must to include,
<kristianpaul>
from all my mm1 demostration people always get amazed with the effects and the music just playing in the background :)
<kristianpaul>
(no complaing for the resolution or dunno what else)
<rjeffries_>
.
<kristianpaul>
one it run people like. so the preview videos should keep that sensation
<kristianpaul>
now i consider again the must word :)
<kristianpaul>
rjeffries_: \.? ;-)
<rjeffries_>
$#@(*!
<rjeffries_>
;)
<wolfspraul>
kristianpaul: I don't understand you. What is your point?
<kristianpaul>
wolfspraul: better quality on the preview videos for patches :)
<wolfspraul>
you mean the 4 new ones?
<kristianpaul>
well i'm not saying current are bad, just keep improving :)
<wolfspraul>
not good enough?
<wolfspraul>
what needs to be improved?
<wolfspraul>
for the 4 new ones, what needs improvement?
<kristianpaul>
resolution
<wolfspraul>
probably that needs improvement on the m1 side
<wolfspraul>
those videos are taken with a camera mounted on a tripod filming an LCM :-)
<kristianpaul>
looks like those movies ripped from cinema , in the good senseof my comment
<kristianpaul>
he, yes that !
<wolfspraul>
yes, but that's the only practical way I have right now
<wolfspraul>
I'm not sure whether the resolution actually can be improved on the recording side
<wolfspraul>
the camera certainly has a high resolution, and then there's video compression
<kristianpaul>
sure i understand just dropping some comments for what i think can call atention for rc3 annoucement
<kristianpaul>
ok
<wolfspraul>
I don't know how to quickly increase the quality of recordings
<wolfspraul>
vga grabber _might_ help but I don't have one and it's expensive and may need Windows etc.
<wolfspraul>
and it may very well end up in the same quality
<kristianpaul>
he i was about to point that (vga grabber)
<wolfspraul>
what would help is real-time video encoding on the m1, or higher m1 resolution
<wolfspraul>
until then I think the camera from lcm approach is not bad
<kristianpaul>
if you say so :)
<wolfspraul>
kristianpaul: you think it's too bad?
<kristianpaul>
no no
<wolfspraul>
it's just a practical idea now that works, and we can record a lot of patches fast
<wolfspraul>
I want to record some with different kinds of music
<kristianpaul>
just "rip" a video from another video camera is not always good, sure is practical
<wolfspraul>
well
<wolfspraul>
you try with a vga grabber then we compare
<kristianpaul>
;-))
<wolfspraul>
it's slow and expensive
<wolfspraul>
I am thinking practical
<wolfspraul>
now we have those 4 videos, today
<wolfspraul>
in the wiki
<kristianpaul>
sure, i just complaing...
<wolfspraul>
and I can easily make another 10 or 20
<wolfspraul>
I will not go down the vga grabber direction
<wolfspraul>
I checked a little, not good
<wolfspraul>
if someone else does - great :-)
<wolfspraul>
wiki uploads work for anybody...
<wolfspraul>
so better videos from me will only come if either real-time m1 encoding/streaming works, or if the m1 resolution goes up
<wolfspraul>
both of which is not to be expected soon
<wolfspraul>
meaning that, unless someone else steps up and beats me to better quality, we will get more of this current quality level you see there
<wolfspraul>
it's the best I can pull off right now
<wolfspraul>
I think it's better than the ones we had before, a step in the right direction
<wolfspraul>
:-)
<kristianpaul>
oh, sure
<kristianpaul>
as i said, keep improving :)
<kristianpaul>
just after you watched several times, details pop-up
<kristianpaul>
no more :)
<wolfspraul>
definitely
<wolfspraul>
I am just describing what I did so far and why, and what next steps are planned.
<wolfspraul>
Sebastien tried to work on 1024x768 resolution, but could only get it to about 4 fps at first
<wolfspraul>
then he worked on several speed improvements like a TMU
<wolfspraul>
which got it up but not enough
<wolfspraul>
so as a side effect we have faster memory now, and smoother 640x480 rendering :-)
<wolfspraul>
but more work is needed to squeeze out more performance on the memory side
<wolfspraul>
he mentioned a complete redesign of the memory controller, which would require serious work and research he said
<wolfspraul>
won't happen soon
<wolfspraul>
and/or that Xilinx code snippet, which unfortunately comes without source redistribution rights
<wolfspraul>
we'll get there eventually, but more people need to join and help ramp up the speed
<wolfspraul>
at least Sebastien already saw the rendering in 1024x768 and said it looked noticably better :-)
<wolfspraul>
that's great
<wolfspraul>
he said 800x600 doesn't look much better than the current 640x480 (also related to some texture sizes I think)
<wolfspraul>
so I guess we can skip 800x600
<wolfspraul>
either 1024x768 or stay at 640x480 and make that better
<wolfspraul>
that's all I know
<kristianpaul>
640x480 looks nice
<kristianpaul>
you really take a while to realize the real resolution and bits per pixed, if you are not told
<kristianpaul>
actually i started the concern after playing with the video-in, before that i even  thought about it
<kristianpaul>
Artyom, how do you clean status_read flag? i guess as writing to STATUS reg isnt?
<kristianpaul>
that will explain also that i need to re-load some values per channel, after a accumulator interrupt
<kristianpaul>
a/an/
<kristianpaul>
i poiting it because i think that was my problem with zeroes accumulators, i just implemented wrong all the flags for enable and registers and internal flags in namuru..
<kristianpaul>
so once written they keep asserted hihg.. ;-)
<kristianpaul>
s/hihg/high
<kristianpaul>
anyway, fixing  now i think that was my problem :), waiting for your feedback
<kristianpaul>
gn8
<kristianpaul>
wolfspraul: can you check please sige.com i dont see GPS in products anymore...
<kristianpaul>
ah yes it is ;)
<kristianpaul>
sorry for the noise
<kristianpaul>
that Search box is not very helpfull
<wolfspraul>
at the level you are working on, we will be able to move to different front-ends later I'm sure, with relative ease
<wolfspraul>
that's the whole point of copyleft hardware after all, to push the software level to the point that every chip we source can easily be replaced with another chip from a second, independent, manufacturer
<wolfspraul>
I am not checking with SiGe on the business side, because I have so little to show to them / talk about
<kristianpaul>
he, sure, just wpwrak was concern about the acquired i wanted to make sure current status :)
<wolfspraul>
but once I do, I will definitely reach out to them
<wolfspraul>
remember they sent us this EVB of a (back then) unreleased chip for free, to support our project
<wolfspraul>
I owe them a report back
<kristianpaul>
sure :)
<kristianpaul>
current report signal detected no tracking, i'm working on it.. :)
<wolfspraul>
sure, no rush
<kristianpaul>
ok off bed now tomorrow i have boring meeting ;)
<wolfspraul>
n8
<rjeffries_>
wpwrak trying to recall when I advocated "open loop design"
<rjeffries_>
was that the time I suggested Argintina should become a US Territoty? I can't remember. ;)
<rjeffries_>
"Even a mistake may turn out to be the one thing necessary to a worthwhile achievement." - Henry Ford
<qwebirc73004>
hello.
<xiangfu>
qwebirc73004, hi
<aw>
0x50: C154 re-soldered its two pads, the impedance err disappears. phew~I took out L8/U11/C136/U13 sequentially then found C154. ;-)
<wolfspraul>
aw: not bad
<wolfspraul>
another board recovered?
<wolfspraul>
was the cold soldering visually detectable? (would have been cool if you had taken a microscope picture before the resoldering)
<aw>
didn't take microscope. :( but I would like to change 0805's footprint to avoid of this. the gap between two pads seems too closer.
<wolfspraul>
sure sounds good. take a pic now to document it.
<wolfspraul>
would have been interesting to know whether it was detectable before, visually
<aw>
cold soldering can't cause "short" in C154
<wolfspraul>
oh sorry, yes
<wolfspraul>
wrong word
<wolfspraul>
I was just curious how it looked before
<wolfspraul>
but no pic, no problem
<aw>
it must be haven a "short" condition under two soldering pads to cause this. but bad that I forgot to take mircoscope, it may still not easily to discover by microscope top view though.
<wolfspraul>
top view not, maybe from the side?
<wolfspraul>
well, now it's too late
<wolfspraul>
but a good discovery, let's see how the rest of the board works...
<aw>
this happens of course if solder paste is too much then get this.
<wolfspraul>
change footprint sounds good
<wolfspraul>
if that helps
<aw>
but I would also narrow the gap between 0805 footprint. ;-)
<aw>
now~go to soldering those parts back and see. :)
<wolfspraul>
wpwrak: yes, I really like Milkymist Hardware Family, but one more word missing
<wolfspraul>
Hardware Family Requirements?
<wolfspraul>
which family has 'requirements'...
<wolfspraul>
so in that style it needs to be something friendlier then
<wolfspraul>
description? too meaningless
<wolfspraul>
characterizations? particulars?
<wolfspraul>
Milkymist Hardware Family Particulars? MHFP :-)
<wolfspraul>
or just Milkymist Hardware Family, nothing else
<LunaVorax>
Hi everyone !
<DocScrutinizer>
short probably caused by either to much solder paster, or poor alignment/stencil-layout, or too much pressure when placing components into solder paste bed
<DocScrutinizer>
dang, I bet this time it will take a week til OM box chandra is up again
<DocScrutinizer>
I have a pretty clear idea where "our" sysops are right now and what they're doing
<wolfspraul>
LunaVorax: hi
<LunaVorax>
wolfspraul, :)
<LunaVorax>
Got the newsletter
<LunaVorax>
I have ONE complain
<LunaVorax>
Some people have computers that cannot play HD videos correctly
<LunaVorax>
(in this case, me)
<LunaVorax>
So I cannot enjoy some of them
<wolfspraul>
which one?
<LunaVorax>
The hello world video
<LunaVorax>
And probably the "How to boot the Nanonote into USB mode" also
<LunaVorax>
I would have rencoded them in half the size but for some reason avidemux doesn't want to open them
<aw>
DocScrutinizer, yes, since I currently found one 0805 for short condition: although surely the stencil-layout and much solder pastes or much pressure will cause this, I'd still prefer to narrow the gap between 0805's two pads. ;-) surely the a smaller stencil's aperture can help this. the right effort should not be at smt vendor side though. ;-)
<wolfspraul>
LunaVorax: can you explain more?
<wolfspraul>
what system do you have? how do you watch videos?
<wolfspraul>
do you use the javascript viewer?
<wolfspraul>
or download the .ogv file?
<wolfspraul>
oh wow, indeed. the original of those two videos was done at 1920x1080 pixels - cool
<wolfspraul>
that will still play nice on the 4000x4000 pixel screens we will have in a few years :-)
<LunaVorax>
wolfspraul, I am using a 1.3ghz (mono core) computer (with an old gefore mx400 64mb card running the open source driver)
<wolfspraul>
hmm
<LunaVorax>
wolfspraul, and I download the .ogv files on the computer and play it with mplayer
<wolfspraul>
have you tried using the javascript viewer?
<LunaVorax>
wolfspraul, not sure it will go faster but let me try
<LunaVorax>
I browse the web with JS off
<wolfspraul>
I don't know technically where it's scaled down, but the view is definitely much smaller than 1920x1080 there
<LunaVorax>
Oh ok
<wolfspraul>
what I can do in the future is for any video above a certain resolution, to upload a second lower resolution one
<wolfspraul>
but it's all work and I need to understand where the problem is first
<wolfspraul>
your mplayer cannot scale down the 1920x1080 video?
<LunaVorax>
Hmm no, no good, twice as sluggish
<wolfspraul>
it may be scaled down locally
<LunaVorax>
wolfspraul, i tried with no success but maybe I'm using the wrong parametters
<wolfspraul>
otherwise I don't know who could do the computing intensive scaling
<aw>
DocScrutinizer, the distance between two pads of 0805 I'll expand it, currently it's too close. sorry that I used wrong word. ;-)
<wolfspraul>
I guess MediaWiki is not that good yet in auto-scaling videos
<wolfspraul>
for pictures it's great
<wolfspraul>
so I can easily upload the absolute highest-res picture I have, because in any place I use it MediaWiki will scale it down on the server, and cache the scaled down version
<wolfspraul>
but for videos that's not the case (yet, I would hope)
<wolfspraul>
so if I upload a super high-res 4000x4000 video, that'd be bad
<wolfspraul>
people would have to download all that data, only to have it scaled down after download - not good
<wolfspraul>
that's my current understanding
<wolfspraul>
so I guess I need to manually create lower-res versions, until MediaWiki is better with videos
<wolfspraul>
LunaVorax: which resolution is best for you?
<DocScrutinizer>
aw: look, neither the PCB nor the component has any surface that would make the molten solder migrate and close the gap between the two pads. The pads shall be no closer to each other than the contacts of the component. There is no way the solder shorts the gap unless either your solderpaste blobs merged into each other due to too much paste or pressure, or you apply pessure when solder is molten so it will spread under component
<LunaVorax>
woakas, for video playback, 640x480 is good (in know it's 2011)
<LunaVorax>
-in + I
<wolfspraul>
the size of the window on the news will not be bigger than that anyway
<wolfspraul>
it's just maintenance overhead
<wolfspraul>
first a lower-res video needs to be created manually, then uploaded
<wolfspraul>
then there are 2 uploads of the same video
<wolfspraul>
and some people may prefer the high-res one, but even if you link to both resolutions, that's not very user friendly
<wolfspraul>
best would be if the scaling would be more automatic and built-in...
<DocScrutinizer>
aw: general rule: the amount of solder paste applied never can be too small
<wolfspraul>
LunaVorax: thanks for the feedback! I will look into this
<wolfspraul>
I noticed that on Wikimedia Commons many videos are uploaded in multiple resolutions
<LunaVorax>
wolfspraul, thank you :)
<LunaVorax>
wolfspraul, i'll try to scale down the video using ffmpeg
<wolfspraul>
he
<wolfspraul>
a lot of work
<wolfspraul>
the server should do that for us
<wolfspraul>
our time is valuable, and there are better things to do...
<LunaVorax>
Oh ok
<LunaVorax>
Let the server do the work then :P
<wolfspraul>
feel free, feel free...
<wolfspraul>
:-)
<wolfspraul>
best would be if MediaWiki could do video scaling (and caching) like they do for images
<wolfspraul>
but it's a lot of work throughout the whole system
<wolfspraul>
I'm sure
<wolfspraul>
I'll think about it
<LunaVorax>
If you can tweak that also, try to make the server use the svn version of theora, it has really been improved and makes videos looks better
<aw>
DocScrutinizer, the stencil built from smt vendor, the stencil's 0805 size will never be the same as equivalent to design solder paste layer size, I agreed your idea though. but I would change our design not to ask smt vendor to request if their thickness of solder paste is under spec. or not. ;-) The design from ours should be producible everywhere to let any smt vendor can mount/assembly boards. ;-)
<DocScrutinizer>
aw: otoh increasing the gap between pads to more than the distance of contact to contact distance on component is generally not a good thing either
<LunaVorax>
woakas, (even better than wp8, hum hum)
<aw>
DocScrutinizer, :-)
<DocScrutinizer>
aw: what you sugest can not work. The SMT population and reflow process has to be tuned anyway, and there's no such thing like a universal layout
<DocScrutinizer>
IOW when smt fab is doing nonsense, there's nothing you can do against it on layout side
<DocScrutinizer>
but maybe the footprint is actually sub-optimal, I haven't checked it
<DocScrutinizer>
getting good footprints seems the holy grail of smt designers
<wolfspraul>
LunaVorax: the server is not using theora (what exactly?)
<wolfspraul>
the only thing the server does is the thumbnails from videos
<wolfspraul>
using oggthumb now because ffmpeg caused too many problems
<wolfspraul>
but the server is not doing video scaling, at all
<wolfspraul>
that's the thing
<wolfspraul>
so a video uploaded as 1920x1080 will be downloaded like that, full resolution
<wolfspraul>
and then scaled down locally, I'm pretty sure
<LunaVorax>
wolfspraul, hum ok
<LunaVorax>
theora = the ogg video codec, is that what you were asking ?
<DocScrutinizer>
aw: anyway doublecheck your pad size vs size of component contacts. I'd think they have to exactly match, otherwise you're asking for trouble
<DocScrutinizer>
SMT components get pulled into position by solder cohesion and adhesion
<DocScrutinizer>
only if footprints match exactly - otherwise they get pulled *out of pos*, they move in unpleasant ways
<wolfspraul>
LunaVorax: I do not believe the server touches (encodes or decodes) the ogv file
<wolfspraul>
from my understanding, the only thing the server does with uploaded ogv files is to extract thumbnails with oggthumb
<wolfspraul>
that's it
<wolfspraul>
the rest is on the client
<wolfspraul>
that's my understanding, I need to look into it
<LunaVorax>
Ok
<wolfspraul>
now that I understand your problem I think we will find a solution :-)
<wolfspraul>
thanks A LOT for the feedback
<wolfspraul>
that's the kind of stuff we need to get better...
<LunaVorax>
I'm sorry I'm a bit confused with all of this
<LunaVorax>
Haha
<wolfspraul>
well I am guessing too
<LunaVorax>
Well, thank you... I though i was only one single grumpy user
<wolfspraul>
I need to do some study on it...
<wolfspraul>
even if so, so what
<wolfspraul>
then we improve it for you
<wolfspraul>
individuals always have the purest perspective on things, imho
<LunaVorax>
Hum
<wolfspraul>
once you start to ask groups/polling, you are in all sorts of social experiments and surprises
<wolfspraul>
hard to understand what 'the group' really meant and wanted :-)
<wolfspraul>
so I rather go with individual feedback
<aw>
DocScrutinizer, pad size and size of components are not match well though I just realized when I see it. ;-) this is primary, others surely is secondary idea. but glad to see here you gave us great inputs.
<wolfspraul>
and then either you are happy or not, I can understand that feedback
<DocScrutinizer>
aw: bottom line: make sure your footprint is *correct*, there's only one correct padsize for footprints. And you can do nothing if SMT fab applies too much solder paste
<LunaVorax>
Anyway, about this tutorial, I think I'll have to work on it and write a wiki page about it, cause the guys is asuming that the user already installed the GCC toolchain. That's pretty discouraging if you're a noob.
<wolfspraul>
DocScrutinizer: keep in mind the statistics too. If we have a problem with 1 of tens of thousands of parts, that needs to be considered as well.
<wolfspraul>
so a solution like "too much solder paste" may well lead to problems with a few hundred parts in the next run, instead of 1 :-)
<DocScrutinizer>
sure
<wolfspraul>
this was a run of 90 boards, and Adam now foudn this one instance of this once capacitor on one board
<wolfspraul>
that's a pretty important data point to consider in any counter measure
<DocScrutinizer>
applying solder paste is a critical process and prone to have glitches every now and then
<DocScrutinizer>
but uneven printing of solder paste is a problem of SMT manuf
<DocScrutinizer>
only thing designer can do is make sure the FP is _correct_
<DocScrutinizer>
a _correct_ footprint is already optimized to avoid issues with too much solder paste - there's no ueber-optimization especially to avoid shorts
<DocScrutinizer>
as you got a distance of contacts on component as well and that won't change no matter which footprint. Ideally footprint and component match 100%
<DocScrutinizer>
you *may* optimize solder paste stencil though
<DocScrutinizer>
and make sure your solder stop mask printing is OK
<wolfspraul>
set the license to cc-by-sa, copyright status and source just fill in your own name, if you want to be perfect you can link to the higher-resolution original somewhere
<LunaVorax>
\o/
<wolfspraul>
maybe in source
<LunaVorax>
ok
<LunaVorax>
wolfspraul, uploaded and newsletter fixed
<wolfspraul>
oh, let me check
<wolfspraul>
ok, the thumbnails look different already, strange :-)
<LunaVorax>
Yeah I saw that
<LunaVorax>
I don't know if that's very important
<LunaVorax>
Anyway, I think it teached us a valuable lesson, video embedded in the newsletter should follow some standards like max height = 360px and max bitrate = 220kbits/s
<LunaVorax>
The question is now, how to configure the server to do the job for us every time. Maybe a simple bash script should do the trick
<LunaVorax>
wolfspraul, does the reencoded video suits your standards ?
<wolfspraul>
the thumbnail is very important
<wolfspraul>
because that's the impression people get from looking over the page
<wolfspraul>
the thumbnail will make a _huge_ difference as to whether someone will watch the video or not
<wolfspraul>
it's a bit tedious to find a good one, and unfortunately you can only pick a second, not a frame. so it's a hit and miss.
<wolfspraul>
I think I found 2 acceptable ones for the 2 new videos now, check it out
<wolfspraul>
LunaVorax: ok check it, now I changed the download link to download medium/high
<wolfspraul>
it's not nice but I guess we have to do this because we cannot sense which resolution make sense for the client
<wolfspraul>
oh, and the size is also wrong :-)
<wolfspraul>
updating...
<LunaVorax>
which size ?
<wolfspraul>
aw_: how can we find the root cause of boards like 0x34 ?
<wolfspraul>
LunaVorax: look under the video
<wolfspraul>
wait let me update this
<LunaVorax>
Haha
<LunaVorax>
wolfspraul, I thing that what would make sense for the client would be something they see every day. Therefore (if the video were encoded following a pixel height rule) using terms like (360p, 720p, 1080p) instead of (low, medium, high) which can be considered somewhat vague
<wolfspraul>
well
<wolfspraul>
you will find out that there are as many resolutions as there are videos
<wolfspraul>
check now, updated again
<wolfspraul>
I think now it's good
<wolfspraul>
I removed the medium/high, sure that is vague but we will always be pushing the problem around
<aw_>
wolfspraul, not only 0x34 which stopped at 'Bitstream length: 1484404', few boards have been also stopped at that err, it seems that i would say(but right now I can't approve it. ;-) ) that 1). s/w codes can't fit h/w tolerance caused by parts, then corrupted somewhere then can't restore/recover. 2) what's exactly part caused shift easily by part itself tolerance?
<wolfspraul>
yes but which h/w tolerance? :-)
<wolfspraul>
we can send 0x34 to Sebastien, that's one option
<LunaVorax>
wolfspraul, your edit is perfect :)
<wolfspraul>
or you try to find out the hardware difference, by comparing until you find something suspicious. or maybe by looking for certain things? (if sebastien has ideas)
<wolfspraul>
the good news is that it seems we can reproduce the problem on 0x34, that is it happens every time
<wolfspraul>
that's better than a problem that appears only rarely
<wolfspraul>
LunaVorax: so basically what we do in the future is this:
<wolfspraul>
a video should always first be created and uploaded in the highest resolution possible
<wolfspraul>
no limits
<wolfspraul>
the higher the better
<aw_>
wolfspraul, don't know yet just guess (without hard data), just to be verified later like: taking working board and that issued board, taking scopes again. but it could be hard to take many signals in parallel from my current equipment.
<wolfspraul>
then, if it's more than 1024x768 or so, we will create a scaled down version that matches the window size we will have for the embedded viewing
<wolfspraul>
in that case, instead of one 'download' link, we will have 2 links linking to the smaller and larger video by stating their file sizes (for people who want to download)
<wolfspraul>
aw_: understand, hard. maybe sebastien can give us some ideas, or we send 0x34 to Sebastien.
<wolfspraul>
we'll see
<wolfspraul>
we do have a few of those boards, so at some point we probably need to investigate
<wolfspraul>
LunaVorax: sounds like a plan?
<LunaVorax>
wolfspraul, be also sure when embedding a video in a webpage that your server can deliver the video fast enough so users don't have lags because of their/your connection speed
<LunaVorax>
wolfspraul, perfect but I have two suggestion
<LunaVorax>
Embedded videos = 220kbits/s
<LunaVorax>
And
<LunaVorax>
I suggest a limit of 480pixels in height instead of 1024x768
<wolfspraul>
he, ok :-)
<LunaVorax>
sorry if I'm too picky :P
<aw_>
wolfspraul, regards to which h/w part I don't know now only once we deeply digging into probe sequencies of several signals to see if any secrets behind.
<wolfspraul>
we are 'wasting' some download capacity and client load when embedding larger videos and letting the client scale down
<wolfspraul>
but you were the first one to notice and complain
<LunaVorax>
Haha
<LunaVorax>
Maybe because I'm the first to have weak hardware
<wolfspraul>
it's a tradeoff between maintenance overhead and our actual users
<wolfspraul>
well the rule is for 1 person to speak up, there's 100 with the same problem who will not speak up
<wolfspraul>
so it's a good thing you brought up there, I think
<wolfspraul>
but, you will admit, this creates more manual work
<wolfspraul>
so I'll see on which videos I do this extra work :-)
<wolfspraul>
it's a wiki, anybody can help
<wolfspraul>
also this can be done retroactively
<LunaVorax>
wolfspraul, that's why I was wondering how to solve that with a script
<wolfspraul>
as long as we first always upload the highest-resolution video first, everything else is optimization and can be done at any time
<wolfspraul>
nah, too much work
<LunaVorax>
You sure ?
<wolfspraul>
if even Wikimedia Commons is doing this manually now, I wait until their pain is high enough that they implement it server side
<LunaVorax>
ok
<wolfspraul>
Qi is a copyleft hardware project
<wolfspraul>
it's not that I'm dwiddling my thumbs looking for ways to kill my time
<wolfspraul>
push the Mediawiki guys :-)
<wolfspraul>
or even help them
<wolfspraul>
perfect
<wolfspraul>
but no custom scripts on the qi server, which will add more maintenance work for me
<LunaVorax>
That sounds better indeed
<LunaVorax>
Yep I understand perfectly
<wolfspraul>
and plus, this won't be easy
<wolfspraul>
I would extend the pretty neat picture thumbnailing infrastructure they have already
<wolfspraul>
that just needs to be extended to video thumbnailing
<wolfspraul>
I guess it's not high enough in their huge priority list
<wolfspraul>
so video thumbnailing needs to be done manually right now
<wolfspraul>
which is only really an issue for high-res videos, and people on slow links or lower mhz machines
<LunaVorax>
wolfspraul, I'm asking the problem on #mediawiki :)
<LunaVorax>
We'll see if they have a solution
<wolfspraul>
let's see whether you get an answer
<wolfspraul>
that channel is pretty crowded
<wolfspraul>
you have a good chance when the full-time san francisco staff are online, which is probably a bit too early now
<wolfspraul>
6 am there now, I think
<wolfspraul>
even the hackers are sleeping then, except if they have an American roh there... :-)
<LunaVorax>
Oh darn I forgot about that
<wolfspraul>
mediawiki is global, just wait and see. but in my experience in that channel it helps when the americans are awake...
<wolfspraul>
I've fixed a few bugs over the years and I like the project in general. they really do well.
<wpwrak>
rjeffries: (vga tester) heh, that would work ;-)
<LunaVorax>
Question
<LunaVorax>
Would it be possible to display a little animation when the Nanonote is booting ?
<wolfspraul>
LunaVorax: surely possible but someone needs to implement it
<wolfspraul>
and not everybody would like it probably, for example I just want it to boot as fast as possible
<LunaVorax>
Ok
<LunaVorax>
I was just wondering
<wolfspraul>
but you can experiment in that area :-)
<LunaVorax>
wolfspraul, I think my knowledge is too poor for now
<LunaVorax>
But sure
<Ayla>
hi guys
<Ayla>
one question about gmenu2x:
<Ayla>
on nanonote, the icons of the buttons are shown as "A", "B", etc?
<Ayla>
I mean, does the the graphic of the "accept" button on gmenu2x is a button with the "A" or "B" letter? If so, would you want to change that?
<Ayla>
I believe you don't use the "A" letter on your keyboard to launch apps
<xiangfu>
Ayla, it's only shows 'A' 'B', it should be : cancel=keyboard,104#NanoNote H
<xiangfu>
accept=keyboard,13#NanoNote Enter
<xiangfu>
the new gmenu2x input system changed them to cancel and accept I think.
<Ayla>
I'm speaking about button icons
<Ayla>
the .png files still show "A" and "B" buttons
<xiangfu>
Ayla, oh. sorry. yes.
<xiangfu>
yes. change to a better one will be great.
<rjeffries_>
wpwrak someone on G+ commented thusly re qi-hardware newsletter I pimped today:
<rjeffries_>
[1 of 2]
<rjeffries_>
Guess what everyone will notice. Milkymist stuff? Open hardware progress? Nope, nyan-cat. (Of course)
<wpwrak>
(working the backlog once more. you guys are killing me. go out for the evening and you have a day's worth of stuff piling up on the channel)
<wpwrak>
rjeffries_: (open loop design) that was in reference to your question about the cost of doing purely the "design" (without making any hardware) for a potential ya
<wpwrak>
rjeffries_: i think you underestimate just how unpredictable making hardware can be. e.g., it's extremely easy to misunderstand how a chip works, and fixing the misunderstanding can be difficult. then, a chip's documentation may claim this or that, but the chip behaves differently.
<wpwrak>
rjeffries_: also, sometimes all you can understand from the data sheet is that you have to be careful about certain things, but you need to combine this with hands-on experience to be sure just how careful, and what happens if you aren't (e.g., because doing what they suggests would conflict with other design goals)
<wpwrak>
rjeffries_: and so on. if you're doing a design with components that you're not already very familiar with, you have no chance if you don't make prototypes and check them.
<wpwrak>
rjeffries_: we also have the issue that our component and footprint libraries are not very complete yet. so this is an additional risk factor. again, it's all well and under control if you actually try things.
<wpwrak>
rjeffries_: (G+ responses) heh ;-)
<wpwrak>
wolfspraul: (hw family) characteristics ? but i think it can stand without "characteristics". if you talk about a family, it's kinda implied that it'll be about some of the characteristics of its members
<wpwrak>
DocScrutinizer: (I have a pretty clear idea where "our" sysops are right now and what they're doing) in the tent where all the raucous singing and drinking happens till the early dawn ? ;)
<DocScrutinizer>
actually I guess they are crawling some cable tunnel or sth, at a location next to berlin
<wpwrak>
(M1 demo videos) one problem are the washed-out colors and the blur. when you see the demo videos, they look "nice" but not very captivating. they look a LOT better in real life. kinda like going from VHS-to-YouTube to a DVD.
<Artyom>
kristianpaul: yes, when you read data from couple of registers their value is cleared automatically.
<LunaFrizzle>
I couldn't NOT see you were interested by marcan's OpenLase project
<LunaFrizzle>
If Qi makes a device that is OpenLase compatible, you can have ALL of my damn money
<wpwrak>
LunaFrizzle: i hope wolfgang records this statement of yours and one day when you're rich and famous, he'll bring it out again ;-)
<LunaFrizzle>
wpwrak, I'll prostitute myself just to get this device ;P
<LunaFrizzle>
Or sell one of my kidneys... sounds familiar ? ;)
<wpwrak>
very good. i think we could put that to good use :)
<LunaFrizzle>
hahaha
<wpwrak>
and the kidney, too :)
<LunaFrizzle>
Back to the serious thing, I still have troubles compiling SDL things on the Ben
<LunaFrizzle>
I need to talk about it to xiangfu
<LunaFrizzle>
I though about a neat thing to do to advertise the Nanonote, I should try to code a demo in the same spirit of the first Macintosh show off by Apple
<LunaFrizzle>
You know, the one with the Chariots of Fire music :P
<LunaFrizzle>
The bad side is, in order to show how capable the device it, I should integrate some 3D in it... too complex for me
<wpwrak>
are the SDL problems caused by the build environment ? or are you uncertain how to use SDL ?
<LunaFrizzle>
wpwrak, the code is a simple C hello world with only #include <SDL/SDL.h>. I'm sure there's something wrong with the build environment
<wpwrak>
what error do you get ?
<marcan>
LunaFrizzle: there's a hacked up branch of openlase with ASCII art output instead of laser output
<marcan>
I wrote that while on more than a couple drinks during the 27c3 afterparty
<marcan>
to put 3D ascii art on a little PC they had there ;)
<wpwrak>
LunaFrizzle: you should send him a few bottles of cognac ;-)
<LunaFrizzle>
Oh ! I didn't saw you were there marcan :o
<LunaFrizzle>
I'm a big fan of your work !
<marcan>
:) thanks!
<LunaFrizzle>
wpwrak, I think I fixed it. I need to compile more complex code to be sure
<LunaFrizzle>
wpwrak, so far I just installed the uclibcxx package
<LunaFrizzle>
marcan, a few month ago we were still laughing with a college professor about Sony's mistake with the encryption key when using a random number that wasn't random at all
<marcan>
lol :D
<LunaFrizzle>
He suggested me that it was a trainee's mistake 'cause he couldn't see any other alternative
<marcan>
it's not just Sony, Nintendo botched the Wii signature verification because they strncmp()ed the hash
<marcan>
instead of memcmp()ing it
<LunaFrizzle>
Yeah I'm sure they made that kind of thing also
<marcan>
Sony is worse though, Nintendo had good design and horrible implementation. Sony has horrible design and horrible implementation
<LunaFrizzle>
Still it was more impressive since the PS3 has been still untouched for a very long time
<marcan>
nobody cared because of OtherOS
<marcan>
I'm entirely serious, none of the hackers that I know did anything until OtherOS was pulled
<marcan>
OtherOS is the only _real_, working PS3 security system, by accident or not :)
<marcan>
or, rather, was
<Ayla>
otherOS was a good idea against piracy...
<LunaFrizzle>
marcan, wow but I wa still hearing people not happy about the fact that they couldn't get full power from the console. That's what Geohot tried to fix initially, right ?
<marcan>
not really, geohot started once they had already pulled it from the slim
<LunaFrizzle>
Ah yeah I forgot about that
<marcan>
and OtherOS wasn't really _that_ limiting, the _only_ thing it didn't have was 3D graphics
<wpwrak>
Ayla: and pulling it just got everyone very determined to take revenge. very smooth planning on sony's side :)
<LunaFrizzle>
Yeah that's it
<marcan>
now we know that GameOS is exactly the same thing with exactly the same interfaces for everything, except the 3D reference to the GPU is nulled out
<marcan>
wpwrak: when they retroactively pulled OtherOS from the Fat they basically sealed their fate hard
<LunaFrizzle>
I might buy a second-hand PS3 when people will thing PS3 is lame because of PS4
<marcan>
if there's something worse than not allowing homebrew, it's allowing homebrew and then illegally removing the feature retroactively
<LunaFrizzle>
-thing +think
<LunaFrizzle>
haha
<wpwrak>
marcan: yeah, i think we know the answer to whether it is worse to have loved and lost or to never have loved ;-)
<marcan>
:)
<wpwrak>
marcan: at least as the geeky kind of love of technology is concerned ;-)
<marcan>
oh, I love it when companies do evil stuff, it gives me the motivation to hack their products :P
<LunaFrizzle>
marcan, fail0verfow is still active or did Sony just pushed you down ?
<LunaFrizzle>
I have to admit I didnot quite understood what really happenned and how are the things now
<LunaFrizzle>
(if I can ask...)
<marcan>
fail0verflow was never about anything in particular, just a group of people doing stuff
<marcan>
the lawsuit made us go into stealth mode regarding the PS3 and then we got bored of the PS3
<LunaFrizzle>
no code release then ?
<marcan>
we already released everything :
<marcan>
*:P
<LunaFrizzle>
What ?
<marcan>
the ps3 tools, asbestos, noralizer
<LunaFrizzle>
Dammit I'm always the last one informed :(
<marcan>
that stuff got released like a week after 27c3
<LunaFrizzle>
Oh ok
<LunaFrizzle>
Damn
<marcan>
it got pulled later due to the lawsuit, but there are tons of mirrors
<LunaFrizzle>
When I heard you saying "It still need a lot of cleaning" I was like "oh shit, not after 32months or so"
<marcan>
well, it did still need a lot of cleaning, but then the lawsuit happened and we got bored
<LunaFrizzle>
Ok, good to know marcan :)
<LunaFrizzle>
Ok I understand
<marcan>
and in the meantime lots of other people started going about their own way with the PS3
<marcan>
but basically everything we had/used for the demo was published
<marcan>
and it was in fact significantly cleaner, some of the hacks we used for the demo were... hilariously horrid.
<marcan>
picture brute-forcing zlib lengths to match the compressed size because we didn't have a working self creator yet
<marcan>
the tools did come with a working self packer afterwards ;)
<LunaFrizzle>
haha
<LunaFrizzle>
Good to know :)
<LunaFrizzle>
Good thing I'm broke or that would have make me buy a ps3
<marcan>
also, dhewg (Andre Heider) is working on getting some clean PS3 Linux patches upstream
<marcan>
(to support all the new GameOS stuff)
<marcan>
including cleaning up my ugly patches ;)
<marcan>
but yeah, fail0verflow is just a bunch of hackers doing random stuff, mostly an offshoot of the iPhone Dev Team and Team Twiizers (wii)
<marcan>
there are other projects in the works, probably nowhere near as media-attention-grabbing as the PS3 stuff, but still interesting
<marcan>
(probably nowhere near as lawsuit-inducing too :P)
<marcan>
then there's noralizer, which is just a fairly generic nor reader/writer FPGA thing, and the tools to work with PS3 formats/crypto
<LunaFrizzle>
ok :)
<Ayla>
it's easy to run homebrew?
<marcan>
Ayla: there are many gradations of "open", I don't think anything is "fully open" :P
<LunaFrizzle>
Thanks marcan
<marcan>
Ayla: if you're running an older firmware, yes. if you're running a newer firmware, no, but that's entirely predictable
<marcan>
every existing PS3 (except for maybe the most recent batches) can be flashed via hardware to run homebrew though, that's what we "broke"
<Ayla>
I thought the official signing key was found, thus it was possible to sign homebrew?
<marcan>
yes, but obviously they changed the key for newer firmwares (and just keep a whitelist of existing games)
<marcan>
there are certain "absolutes" that you can hit in security
<Ayla>
ok
<marcan>
it's nice when there's, say, a vulnerable ROM that lets you exploit existing systems forever in software, but the PS3 has no such thing
<LunaFrizzle>
Hehehe people are all asking PS3's firmware on second-hand websites
<marcan>
the absolute that we did hit is that you can hardware-flash all PS3s to run homebrew
<marcan>
and you can run homebrew on PS3s with (now) old firmware
<mth>
taking over the firmware update proceess would be the only way to keep control, I guess
<mth>
but then you'd have to patch every new firmware release
<Ayla>
ok
<marcan>
well, sony hid the new firmware's keys inside by wraping them in bootldr, which is the single last unbroken thing in the PS3
<mth>
ah, so a patched firmware won't even boot then
<marcan>
you can't decrypt the latest firmwares (or any games released for them)
<marcan>
it's unbroken because the people who want to break it want to do so for piracy and the people who want piracy tend not to be very good at breaking things in practice
<LunaFrizzle>
marcan, so if someone break it, Sony won't have anymore places to hide ?
<Ayla>
heh, that's actually true
<marcan>
(bootldr is vulnerable to the same issues, and the keys have been used with the same non-random numbers, but for practical reasons you need hardware to exploit it and not that many people know what they're doing)
<marcan>
LunaFrizzle: correct
<LunaFrizzle>
wow
<LunaFrizzle>
end of the world or something for Sony then
<marcan>
if someone gets the bootldr keys then Sony cannot hide new firmwares and games from people
<marcan>
basically they'd entirely lose any chance at protecting newer games
<marcan>
since all the PS3's cryptographic secrets would be divulged, i.e. by necessity anything they do will have to be decryptable by existing hardware and we'd have all the keys
<LunaFrizzle>
can't say I wouldn't like to see such a thing happen
<marcan>
what they did right now is a hack, btw
<marcan>
up until recently bootldr was only used early on in the boot chain and was largely irrelevant
<LunaFrizzle>
Even if I won't use it, just to see SOny's reaction
<marcan>
but since it's the only bit left, they wrapped everything else inside the bootldr crypto
<marcan>
it's funny, because we theorized they could do this, and then geohot claimed if they hired him he'd help them "fix" things (he was definitely referring to this idea too)
<marcan>
and of course that's what they ended up doing
<marcan>
it really is their last chance though
<mth>
they're probably hoping it will last until the PS4 launch; it doesn't have to last forever
<marcan>
possibly
<Ayla>
the PS4 has been announced?
<mth>
I haven't heard anything about the PS4 yet though, so it's probably not close to launch
<marcan>
the PS4 will be... interesting
<LunaFrizzle>
Ayla, they said they'll put less money in it so far
<marcan>
I highly doubt it will be backwards-compatible
<Ayla>
I'm not really following video games news
<LunaFrizzle>
Ayla, I don't think it's anymore "video games" at this state. Business maybe
<marcan>
I wonder if they've fired their engineering team or if they're still going to design a hilariously cost-unoptimized design again
<marcan>
this should amuse the people in here, some gems about the original PS3 hardware design
<Ayla>
LunaFrizzle: that's sad, but true :(
<marcan>
they put WiFi in the PS3, fair enough
<marcan>
but instead of using a USB or SDIO device like everyone else, they decided to... put a wireless router inside the PS3 and have it act as a WiFi to Ethernet bridge
<marcan>
complete with its own marvell ARM SoC running eCos
<LunaFrizzle>
wow wtf ?
<marcan>
and since the chipset only has one GMII port, they put an 8-port gigabit switch inside the PS3
<LunaFrizzle>
it really is overengineered
<marcan>
one gigE port for the external plug,one GMII port for the chipset
<marcan>
one 10/100 port for the wlan
<marcan>
the rest, unused
<marcan>
they use VLANs to separate the traffic
<marcan>
speaking of the chipset, it has more die area than the Cell
<mth>
sounds like they took a prototype and did a 1:1 translation to make it a product
<Ayla>
marcan: awesome :D
<marcan>
it has a built-in graphics and DRAM subsystem, PCI Express, a MIPS processor, media accelerators, ...
<marcan>
all entirely unused
<marcan>
(it's meant for STBs and TVs)
<marcan>
the original chipset only had IDE though, no SATA, so they used an IDE to SATA converter for the HDD
<marcan>
then they came out with a new revision of the chipset, with SATA
<marcan>
but since it didn't have IDE, and their Blu-Ray drive was IDE, they kept the IDE to SATA bridge... in reverse
<Ayla>
let me guess
<Ayla>
ah, ok
<mth>
they had a plan once to use the PS3 as an STB; said the Cell was powerful enough to demultiplex transport streams; but I don't think it ever materialized
<LunaFrizzle>
marcan, no wonder why they lost so much money in the PS3 (?)
<marcan>
more funsies, in older PS3s with 4 USB ports they use a built-in USB hub, since the chipset doesn't have enough ports
<marcan>
in newer ones with two ports, they do have enough ports... but they kept using the hub
<marcan>
LunaFrizzle: exactly.
<marcan>
it's by far the worst cost-optimization (or lack thereof) I've ever seen
<marcan>
they finally got their act together with the slim and removed the switch, the vlans, the wifi router (now it's just usb), the hub, the SATA...
<marcan>
but that's after losing a LOT of money on the Fats
<LunaFrizzle>
marcan, you mean the slim is a fixed ps3 ?
<marcan>
design-wise, it's what the PS3 should've been from the get go
<LunaFrizzle>
ok
<Ayla>
you bet it's slim now :p
<LunaFrizzle>
marcan, sorry to have bothered you with the ps3, maybe you wanted to talk about something else
<marcan>
the funny part is it's not that much smaller than the original PS3 :P
<marcan>
in fact it's deeper
<marcan>
LunaFrizzle: nah, I'm bored :)
<LunaFrizzle>
hehe
<Ayla>
soooo they'll build a 'discount' PS4?
<LunaFrizzle>
"Doesn't play games, just pretend you have a functionnal PS4 to your friends, only 899$"
<Ayla>
don't forget the Blu-Ray2 reader
<mth>
and 3D... or is that hype already past?
<wolfspraul>
wpwrak: ok, Milkymist Hardware Family Characteristics it is - thanks!
<LunaFrizzle>
mth, intra-neuronal connection will be the next big thing... wait no
<mth>
LunaFrizzle: I'll wait a while until they got all the bugs out... ;)
<wolfspraul>
marcan: did you know that Andrew Zonenberg will work on a MEMS mirror next?
<marcan>
ugh, nvidia's blob crashed, did I miss anything? (besides what wolfspraul just said, I got that :)
<Ayla>
nope
<LunaFrizzle>
Just some trolling
<marcan>
wolfspraul: a MEMS mirror for?
<wolfspraul>
you tell me :-) for a laser?
<wolfspraul>
Andrew's project is a home MEMS and CMOS fab