<kyak>
xiangfu: when things get updated in openwrt backfire, how they get into our repo?
<xiangfu>
kyak: merge the upstream backfire branch to our 'master' branch.
<kyak>
i'm asking because there was a very important backport to backfire yesterday, but it's not in our git -\
<kyak>
xiangfu: i see.. so ot's not automatic
<xiangfu>
kyak: no.
<xiangfu>
kyak: I think it's like this "master" --(cherry-pick commit) --> "tracking_backfire" --(merge or send patch email) --> upstream "backfire" --(merge back to)--> our "master"
<xiangfu>
kyak: I will try to merge the upstream backfire to our "master" today (in local)
<kyak>
xiangfu: thanks, i was going to ask you about this, cause my git powers are limited :)
<kyak>
and the patches flow as you explained seem reasonable to me
<kyak>
xiangfu: btw, there was a great finding yesterday.. ncursesw was not working unless locale support is enable in uClibc
<kyak>
after i enabled locale support, rebuilt all things, ncurses-based programs were finally able to present wide chars!
<kyak>
(this also means that ncursesw package is kind of useless in openwrt trunk, because uClibc has not locale support there)
<kyak>
after enabling locale support in uClibc i had to drop a patch to fbterm, because calls to iconv are not stubbed anymore
<kyak>
maybe some other packages are related.. i will build with config.full_system and see
<kyak>
if it works, i think we should enable it.. it is as easy as adding to lines to toolchain/uClibc/config-0.9.30.1/mipsel:
<kyak>
guess it means we have synced with backfire --^ :)
<wolfspraul>
he :-) script works - patch flood stopped after 20 items... (last time we had > 500 ...)
<kyak>
wolfspraul: yesterday wprak have noticed that there are some packages with mp3 support in my ~/people/kyak directory.. how do you think, is it bad to keep it there?
<kyak>
i removed them for now
<wolfspraul>
kyak: yes please, we have to remove them
<wolfspraul>
no mp3, no mpeg4 or h.264
<wolfspraul>
in openwrt we have this PATENTED flag that you should always turn on when building stuff you are uploading to a Qi server
<kyak>
ok, i will be more carefull with that
<xiangfu>
kyak: you can try to run "git pull", our commit still on the top.
<kyak>
xiangfu: just did it, going to rebuilt from scratch with full_system
<kyak>
xiangfu: just for my understanding, you saved our commits somewhere, than you checked out the backfire into our master, and then you applied our commits on top?
<kyak>
how you managed to do this?
<xiangfu>
kyak: create a local branch follow the upstream backfire.
<xiangfu>
kyak: then 1. checkout to our "master",  2. git rebase backfire
<xiangfu>
kyak: then git will take care the merge
<kyak>
what would you do if you had to resolve soem conflicts?
<kyak>
if some of our commits would not apply cleanly?
<xiangfu>
kyak: when there is conflicts. it's will stop, then wait for your manual resole the merge.
<xiangfu>
kyak: if people know there is a bit conflict. usually they will use the "git rebase -i"
<xiangfu>
before the auto merge start, manually remove some commit. etc..
<xiangfu>
s/bit/big
<xiangfu>
kyak: since we just cleanup the 'master' branch. so I just use "git rebase" :)
<xiangfu>
hi kyak have you ever use the StarDict??
<kyak>
i stopped using it at some point when it got broken and then i discovered sdcv
<xiangfu>
kyak: ok. I think I will add (English --> Simple Chinese) dictionary package :)
<xiangfu>
kyak: now we only have Chinese and English font package. so the stardict display Chinese very well.
<xiangfu>
kyak: maybe we can add Russian font and dictionary :)
<kyak>
xiangfu: is a good idea! btw. sdcv is already working correctly english-russian and russian-english both ways :) because cyrillic input is handled correctly in console
<xiangfu>
kyak: for you understand the git rebase and branch with different remote URL. here is my git config -l :http://pastebin.ca/1988880
<kyak>
i have no idea right now how to implement russian input in gtk app like stardict
<kyak>
(without X server)
<xiangfu>
kyak: there is no russian dictionary in openwrt release . right?
<xiangfu>
(I forgot the cyrillic )
<kyak>
xiangfu: i'm still trying to figure out what you said about the git :) i started reading some git reference.. really i'm tired of git being stronger than me :)
<kyak>
xiangfu: there is no russian dictionary right now, i added some manually to my datafs
<kyak>
xiangfu: how does stardict know which fonts to use?
<kyak>
for exmaple, one has WenQuanYi-chinese-font-ttc and unifont
<kyak>
they both presumably support Chinese
<kyak>
which one will be used?
<kyak>
xiangfu: while i can imagine that cyrillic input (as well as accented characters) could be supported by stardict; how it could work for Chinese input?
<xiangfu>
kyak:Â Â I don't know how stardict deal with font. I just copy the Chinese font to system font folder. then stardict works fine.
<xiangfu>
kyak: but there is one option stardict, we can modify the default font to whatever we want.
<xiangfu>
but I don't know how 'default' works. :(
<kyak>
hm ok, thanks for the hints
<xiangfu>
kyak: no Chinese input method for now.
<kyak>
do you have an idea about how this could be done?
<kyak>
i guess there is some kind of chinese "alphabet".. in this case such input method could work
<xiangfu>
kyak: hmm... I know there are some Chinese input method like "SCIM" "IBUS" "FCITX"... we need port one to NanoNote :)
<kyak>
there is often a problem for me when something other than ascii is needed :) i guess for Chinese this is a double problem
<wolfspraul>
xiangfu: I just saw the inclusion of the 'triggerhappy' hotkey daemon on the openwrt mailing list. can we bring it to the NanoNote? Can it be a replacement for the fn-handle power-off daemon?
<xiangfu>
wolfspraul: I think it's much better then fn-handle.
<wolfspraul>
great maybe we try and see whether we can use it as a replacement
<xiangfu>
wolfspraul: yes. I will do that.
<wolfspraul>
if it doesn't get added to any upstream openwrt package repo, we can add it to openwrt-packages.git as an intermediate (but let's way a week or so, I would think it gets included somewhere else if it works well)
<wolfspraul>
s/let's way a week/let's wait a week/
<xiangfu>
wolfspraul: I will wait a little bit. it's not yet commit to upstream yet.
<wolfspraul>
yes, right
<xiangfu>
wolfspraul: oh. yes. same thinking :)
<wolfspraul>
no rush
<wolfspraul>
just keep an eye on it
<xiangfu>
ok
<kristianpaul>
wolfspraul: soemthing wrong with qi-hardware.com server?
<kristianpaul>
wolf.. !
<kristianpaul>
:-/
<kristianpaul>
ah works now :)
<drizzt>
hi
<drizzt>
wpwrak: I sent the transfer order to my bank
<wpwrak>
kristianpaul: (qihw.com) i've noticed that it occasionally has brief hickups where a http request times out
<drizzt>
you should get it in a few days
<kristianpaul>
wpwrak: seems
<wpwrak>
drizzt: that was quick. thanks !
<drizzt>
you were as well :)
<wpwrak>
:)
<drizzt>
wolfspraul: wpwrak: I'll try to keep to the specs I chosed, though I may split the design in two parts, with the fix 'dock' part being much more simple than the tablet part
<wolfspraul>
wpwrak: can you describe those hickups? maybe keep an eye on it
<wolfspraul>
I know we can do a lot on server performance, it's just a time sink and hard to accurately track down the bottleneck
<drizzt>
then I may ask you for the design of the dock part
<drizzt>
this should be decided within the next three months
<kristianpaul>
hmm
<wpwrak>
wolfspraul: it's just that occasionally an HTTP request times out. the next try works. i don't see it happen like this on other sites, so it doesn't seem to be a local problem.
<kristianpaul>
may be install a nagios on fidelio wil help tto keep eye
<wpwrak>
kristianpaul: guess he just reproduced the cause ;-)
<kristianpaul>
:D
<wolfspraul>
drizzt: where do you get the main tablet part from?
<drizzt>
I don't know yet
<drizzt>
there's a lot of possibilities
<drizzt>
working with existing tablet maker, designing one, buying an existing one (worst case)
<drizzt>
the best would be the design, to integrate all the wirless interfaces
<wpwrak>
drizzt: (integrate all the rf) that's when things get complicated again ...
<drizzt>
yes, but this is the mandatory part
<wpwrak>
drizzt: who not just make one ugly grey box with all the interfaces, then buy the sexiest tablet you can find and just communicate with the grey box over wifi ?
<drizzt>
that's the main purpose of the device : allow control of both wired and wireless
<wpwrak>
drizzt: about half the domotics stuff is wire-bound, so you'll eventually need that box anyway :)
<drizzt>
yes
<wpwrak>
drizzt: better have a sports car and a tractor than a ferrari with a plow ;-)
<drizzt>
If I can i'll choose a ferrary plus a tractor
<wpwrak>
drizzt: also gives you more flexibility. the tablet can be anything. so you can just visit wolfgang and he can show you the gazillion of generic/clone/whatever tables you find in the chinese markets like potatoes in european markets ;-)
<wpwrak>
drizzt: then you can patiently evaluate the beast. if you don't like it, there are many alternatives. no need to even solve their problems in case you hit any. just rinse and repeat.
<wpwrak>
drizzt: for the grey box, pick something that uses simple, proven technology. maybe just some pc platform. or, if you don't like that, and old arm, an xburst, or whatever.
<wpwrak>
drizzt: the less bleeding edge the technology, the more choices you have for getting it designed and produced.
<wpwrak>
well, within reason. if you end up with a cpu consisting of vacuum tubes, you've overshot the target :)
<drizzt>
lol
<wolfspraul>
drizzt: so you are interested in a tablet?
<wolfspraul>
any tablet?
<kristianpaul>
Hanvon tables? :D
<kristianpaul>
maybe with a Xburst chip? :O
<kristianpaul>
bbl i'm going to the lab now (finally !)
<wolfspraul>
I've seen a 4760-based tablet, if there is serious interest in it I guess I could try to find out more.
<wolfspra1l>
wpwrak: yes I am aware of glitches/problems, but it's hard to track them down.
<wpwrak>
(this is supposed to be a more or less straight line, with all of the ten runs yielding more or less identical results)
<wolfspra1l>
maybe first I need to try to make them reproducible, without bringing the server down :-)
<wpwrak>
wolfspra1l: maybe dns ? the error came back very quickly, apparently from some "transparent" proxy
<wolfspra1l>
wpwrak: at least your graphic looks like something IMPORTANT is happening
<wpwrak>
wolfspra1l: yeah. now i have to filter those ~8 dB of junk out of my < 1 dB signal ...
<Guest81366>
hi
<Guest81366>
i want a question
<Guest81366>
i have buy the hardisk samsung
<Guest81366>
but i see only 2 pins
<Guest81366>
:(
<Guest81366>
how must do for configuration?
<zear>
Guest81366, how is this related to qi-hardware projects?
<wpwrak>
zear: it's the swap you need for running libreoffice :)
<zear>
and crysis ;)
<wpwrak>
hmm, that would be a nice project indeed. crysis, with a retro mode with ASCII graphics
<zear>
libcaca
<zear>
anyway, it's time for me, bbl
<wpwrak>
hmm, to estimate how much power an antenna puts in the air, i want to look at the amplitude in the spectrum close to the carrier (i can get a very narrow carrier)
<wpwrak>
now, what do i do on the FFT side ? my input are Q/I values. should i do a complex fft and then use hypot(Re(x_i), Im(x_i)) for the signal strength ?
<wpwrak>
or maybe do this conversion from complex to real before the FFT and do the FFT on real numbers ?
<kristianpaul>
YEs the scope is almost 22pf load plust probes
<kristianpaul>
the signal got triangled
<kristianpaul>
i tested antenna and is detected and current and internal voltage regulator is under spected values
<kristianpaul>
i'm so happy :)
<kristianpaul>
so i can witre it to SIE tomrrow
<kristianpaul>
cause i'm sort of delayed i think
<kristianpaul>
listen to kevin jhojansen
<kristianpaul>
good sync and clock seems look ok
<kristianpaul>
argg data signal still trciky to catch even stoping rendering on scope it looks messy/blurr, lets see how it looks witht the spectrun analizer :)
<kyak>
bartbes: here?
<kyak>
bartbes: in nlove Makefile, PKG_SOURCE_PROTO:=hg - what's this?: )
<kristianpaul>
wpwrak:( maybe do this conversion from complex to real before the FFT and do the FFT on real numbers) totally agreee
<kyak>
the package can't be downloaded, build fails
<kristianpaul>
wpwrak: i'll do same with gps data before try get FFT and look PRN code matching
<kyak>
bartbes: k, seems i have to install hg-git.. first you made me install cmake, now that :) i guess you just nlove alternatives!
<bartbes>
kyak: ;)
<kyak>
bartbes: you could have a look at include/prereq-build.mk for an example of user-friendly build prerequisites
<kyak>
like if your build requires svn, it would inform the user about it
<bartbes>
oooooh
<bartbes>
user-friendliness
<bartbes>
what is that?
<bartbes>
:P
<kyak>
a curse word
<kyak>
don't get me wrong, i'm just hinting you :)
<bartbes>
oh, I'm not
<bartbes>
I just never even knew that existed
<bartbes>
so ehm, how does it work?
<kyak>
i don't really know :)
<bartbes>
:P
<kyak>
but who needs to know, prereq-build.mk shows a good usage example
<kyak>
you could use a define Require/ block if you need more advanced checking
<wejp>
a while ago somebody said the flac package in openwrt has been updated, but either that's not the case or i am looking in the wrong place. how do i update my openwrt build environment correctly?
<kyak>
flac version in openwrt is 1.2.1
<kyak>
i guess it's the new one
<kyak>
to update the feeds, make package/symlinks is good
<wejp>
yes, that's the new one, but how do i get that one
<kyak>
yeah, git pull only updates the base system.. most packages are in so called feeds
<kyak>
so you have to 'make package/symlinks'
<wejp>
okay, thanks
<kyak>
np! am i guessing correctly that you want to add flac support into gmu build for openwrt?
<wejp>
yeah, i'll enable flac by default in the next version of gmu for the nanonote, so the package that'll be build from that will include flac support
<wejp>
by the way, it will also come with speex support :)
<kyak>
awesome!
<wejp>
for speex libogg and libspeex are required, but both are available in openwrt, so no problem there
<kyak>
how do you use speex? for voice control?
<wejp>
some people have been asking about speex support. speex is useful for speech-only audio files, like podcasts
<kyak>
ah, i see
<wejp>
one can create really small files with speex , whith a pretty good speech quality
<wejp>
about 12 MB for an hour or so
<kyak>
sounds good; is there encoder available in openwrt, too?
<wejp>
probably yes, the encoder is included with the speex libraray source
<kyak>
this could be usefull, too.. because arecord is not compressing audio as it records
<wejp>
and as it is patent free it should be no problem to include it in the nanonote firmware
<kyak>
btw, while we are discussing gmu - why is alt+enter (for exit) is only working from withing F1 help menu?
<wejp>
it is also working from the playlist view. unfortunately i accidentally have used alt+enter in the file browser for something else. but i'll change that in the next release to be more consistent
<wejp>
then alt+enter should work in all screens
<wejp>
but it is also easily possible to change the whole keyboard mapping
<kyak>
'q' would be awesome for exit :)
<wejp>
without recompiling anything
<kyak>
ah, great
<wejp>
i can also change it to Q
<wejp>
q is cvurrently being used for the queue function though
<wejp>
but it is no problem to change all that
<kyak>
i'm very satisfied with default gmu keymap, other than 'exit'
<wejp>
:)
<kyak>
ok, you made it on purpose :) you don't want people to ever quit gmu ;)
<wejp>
yeah, alt+enter isn't the most intuitive one. it basically is inherited from the dingoo version where the start button is the same as enter and you quit gmu on the dingoo with select+start ;)
<wejp>
but you are right, people should never quit gmu :P
<rafa>
wejp: now you need to build a gmu kernel.. people boot and just gmu appears, exit would be = shutdown/power off ;)
<wejp>
good idea :D
<kyak>
daemonizing gmu would be enough :)
<wejp>
i just run gmu instead of init when booting ;)
<kyak>
i have a gmush, gmu-compatible shell
<wejp>
:D
<viric>
wpwrak: how do some small devices with microprocessors work with two 1,5V batteries?
<viric>
that's 3V
<wpwrak>
drizzt: kewl. then it will probably get credited to my account monday or tuesday. i'll let you know when it arrives.
<wpwrak>
kristianpaul: hmm, the GPS uses PM. not sure if you'll get much useful information if you just look at the amplitude.
<wpwrak>
kristianpaul: (scope) kewl. the signal in the picture is data, right ?
<wpwrak>
viric: hmm, just like devices that work with 5, 3.3, 2.7, 1.8. 1.5, or 1.2 V ? ;-)
<viric>
wpwrak: well, I don't know about that ;)
<viric>
It's a matter of choosing ICs that work, let's say, at 2,7V?
<wpwrak>
viric: well, depends on what you need. low voltages are not a problem for modern technology. used for fast and slow systems.
<viric>
for example, that 8051 mcu that had usb... can I find something close to that, that can work with two 1,5V batteries?
<wejp>
you do not run thos ICs directly from the battery voltage
<wpwrak>
yes, probably.
<wejp>
you rather use voltage regulators
<viric>
really?
<wpwrak>
wejp: why not ?
<viric>
I'd expect a very regular voltage from batteries
<wpwrak>
wejp: naw, battery generally is fine for mcus.
<wejp>
wpwrak, because the battery voltage varies, depending on its charging state
<viric>
well, I don't think the mcus worry much on that
<viric>
a regulator could take a lot of power from a battery
<wpwrak>
wejp: yes, but if your mcu has a voltage range from, say, 2-5 V, you don't really care ;-)
<wejp>
if you don't care about stability and don't care about using the battery efficiently, you cann use it without a regulator of course
<viric>
wpwrak: ah, really some have that range? That's great
<wpwrak>
viric: LDOs don't burn all that much power. but they cost money and space.
<viric>
what is a LDO?
<wejp>
and modern regulators are very efficient and do not use much energy themselves
<viric>
wpwrak: you said a cr2032 cannot power one of those f321?
<wejp>
switching regulators that is, linear regulators suck for battery operation
<wpwrak>
viric: e.g., PIC18F13K50. 1.8 - 5.5 V
<viric>
ahh.
<viric>
sdcc can target that?
<viric>
I'm checking those f321
<wpwrak>
wejp: LDO vs. switching: depends again on what you're doing.
<wpwrak>
viric: the f321 unfortunately don't go very low. not ideal for battery
<wejp>
LDO?
<wpwrak>
LDO = Low-DropOut regulator
<wejp>
ah, well those are usually still linear converters
<wejp>
their effiency is not the best
<wpwrak>
wejp: depends on what you're doing :)
<wejp>
yes, of course
<wejp>
but if you are running on battery, most of the time you want to achieve a long runtime with those batteries ;)
<wejp>
if the circuit is using very little current, it probably doesn't matter much though
<wpwrak>
wejp: yup. when running from battery, the first thing you do is try to minimize your duty cycle.
<viric>
wpwrak: I was thinking on making some device to control whether to switch the flat heating on and off (it requires a relay as 'output'
<viric>
)
<viric>
some buttons, and two or three 7-segments should do the job...
<kristianpaul>
back from snap
<kristianpaul>
wpwrak: yes is data
<kristianpaul>
but i;m here at University lab and get better scope probes
<kristianpaul>
signal is not triangled at least :)
<kristianpaul>
clock signal*
<kristianpaul>
i'll try data again
<kristianpaul>
wpwrak: about GPS, yes of course i dont need look just to the amplitude
<wpwrak>
viric: you'll probably need a transistor for the relay. also, don't forget the diode :)
<viric>
wpwrak: I know. :)
<wpwrak>
kristianpaul: (clean clock) that's good :)
<kristianpaul>
i see squares !
<kristianpaul>
is usign brand new probes
<kristianpaul>
can i suppose that the scope metter just miss the trigger bcause this is a "ramdon" pulse data siganl?..
<wpwrak>
good. such a slow signal really ought to look tidy :)
<wpwrak>
i don't think you miss the trigger. at least in the picture you posted, you got the trigger
<wpwrak>
just the signal before and after (that is, one cycle later) is variable
<kristianpaul>
yup
<kristianpaul>
i'm tunnign trigger right now
<kristianpaul>
i jsut met this scope today
<wpwrak>
100 MHz ?
<kristianpaul>
150mhz 25GS/s
<kristianpaul>
DSO
<kristianpaul>
wee
<kristianpaul>
fixed
<kristianpaul>
d
<wpwrak>
25 GS ? i doubt that :) 150 MHz is good
<kristianpaul>
sure i'm working ar 250MS/s
<wpwrak>
probably a GDS-820. hmm. data sheet says 100 MSa/s for real-time. it switches to effective time for higher rates. not so good. ET only gives valid results for periodic signals.
<wpwrak>
perhaps that explains the pattern you're seeing in the [-oo, 0] and [1 cycle, +oo] from the trigger
<kristianpaul>
ha i founded the doc for gps-sdr now i need to read 1024 pages, great !! (seriouslly)
<kristianpaul>
ah suspiciously generated by doxygen
<drizzt>
wpwrak: hi !
<drizzt>
a question, about CE/FCC and CEM tests
<drizzt>
how do you manage them for Qi-hardware ?
<drizzt>
and how does it cost ?
<wpwrak>
kristianpaul: very nice. these pictures look much better.
<wpwrak>
drizzt: you'd have to ask wolfgang for the details
<wpwrak>
drizzt: i think you just give the device to a certification lab, tell them what you want to have certified, then they run their tests ... and then comes the expensive part, fixing all the flaws they find :) in the end, they issue the certificate.
<drizzt>
yes, I already did this part
<drizzt>
but as employee, so I never new (and carred) about the bill
<drizzt>
knew
<wpwrak>
i don't know the cost structure either. i've heard something of a few kbucks, but don't have details -> wolfgang
<kristianpaul>
wpwrak: yeah just ready to wire SIE and SiGE EVB and begin the hard work with an already debuged envirioemnt :)
<wpwrak>
kristianpaul: you should tell the folks at the lab that they should get themselves a new scope and let you have their old junk :)
<kristianpaul>
:°)
<kristianpaul>
oops
<kristianpaul>
never use irssi with more than one window open !
<kristianpaul>
wpwrak:how the I/QÂ Â dta provided by the URSP?
<drizzt>
I have the details for medical devices (15Keuros for CEM tests only) but not for "simple" electronic devices, neither for both CE + CEM tests
<kristianpaul>
i meant timinng and data per "cycle" or sync
<kristianpaul>
i'm not aware of USRP signal adquisition process
<wpwrak>
kristianpaul: i/q ... oh, it's pairs of floats sent over Ethernet
<kristianpaul>
float ohh is BIG
<wpwrak>
actually ... floats is what the beastie outputs in the end. i think the usrp itself sends data in some 16 bit format.
<wpwrak>
yes, has to be 16 bits. the adcs are 14 bit.
<kristianpaul>
Ethernet?? but latency is about miliseconds is that god enoguht?
<kristianpaul>
s/god/good
<kristianpaul>
interesting lets way URSP2 get cheaper (~700) to get one
<wpwrak>
depends on what you're doing. most radio protocols don't mind a little bit of latency between stuff sent and received.
<kristianpaul>
i see
<wpwrak>
it's probably also less than milliseconds
<kristianpaul>
how come?
<wpwrak>
ettus just released a new model, kinda like the usrp2, but USD 300 more expensive :(
<kristianpaul>
ha
<kristianpaul>
tooo bad
<wpwrak>
consider a 1000 bytes frame. that's something in the order of 10 kbits. at 1 Gbps, that would take only 10 us.
<kristianpaul>
oh i forgot the 1Gps , is true
<wpwrak>
you can still get the USRP. it's a bit slower and its ADCs/DACs have less resolution but it can use the same cards. it's only USD 700.
<kristianpaul>
yeap i'll may consider that for neaxt year
<wpwrak>
as an added bonus, it can even host two cards at the same time
<kristianpaul>
full duplex usrp way?
<wpwrak>
drizzt: if it says "medical" somewhere, it's probably more expensive than "regular" :)
<wpwrak>
full duplex depends on the RF card. the USRP itself is always full-duplex-capable.
<wpwrak>
note for USB: if full-duplex-bw = 1/2 half-duplex bw.
<kristianpaul>
k
<wpwrak>
so don't quite expect to run 2 TX + 2 RX 802.11g streams over an USRP :)
<kristianpaul>
you got me !
<drizzt>
wpwrak: yes, and this price is from a lab in Switzerland ....
<kristianpaul>
wpwrak: btw is MAX1003 the 6bit ADC 90Mspschip you pointed last time?
<wpwrak>
kristianpaul: don't remember. could be.
<wpwrak>
actually ... maybe not. i was looking for the usual DC-coupled type.
<wpwrak>
it does look like a nice chip to make SDR with, though
<wpwrak>
ah, it supports DC coupled operation too. that's nice.
<wpwrak>
just a bit slow
<kristianpaul>
i aks then for a EVB is 60USD, i think is expensive.. what do you think?
<kristianpaul>
is not that i going to buy it just i like/survery
<wpwrak>
and for simple chips also captive or rich customers;-)
<wpwrak>
of course, if you consider an engineer's salary, it's hard to beat an EVB for only USD 60. you have to be very efficient to make your own EVB for less.
<wpwrak>
hmm .. the MAX105 has a DREADY signal. that could almost be a real english word ;-)
<kristianpaul>
Data Ready Clock ?
<wpwrak>
kristianpaul: qi-hw's openwrt wants to change the rootfs size (or for all i know may have already done so). now, how are other distros to deal with this ? particularly if they allow you to mount the rootfs
<kristianpaul>
yes done
<rafa>
wpwrak: no, I do not understand well the changes.. it seems that a time ago openwrt used 2gb, then used 512mb, then 256mb and now again 512mb.. No sure if that is the story.. but well
<wpwrak>
kristianpaul: yup. sounds like a mixture between dread and dreary :)
<kristianpaul>
rafa: it was i think
<rafa>
wpwrak: I do not understand well the reasons and how that is decided
<kristianpaul>
rafa: reason was current image was running out space
<rafa>
wpwrak: so.. jlime used the whole short life on nn just the 2gb.. and users will need to wait 5sec more to boot :)
<kristianpaul>
mostly because gcc inclusion so...
<wpwrak>
rafa: oh, i think it went something like this: at some point in time, the rootfs was full. then they discussed a bit about increasing the size (here, on #qi-hw)
<wpwrak>
rafa: then nothing happened for a while. and then xiangfu announced the immediate change :)
<kristianpaul>
rafa: i think that was the wrong way when resized the 2gb to 256mb, who cant wait 5s more
<kristianpaul>
wass  a too fast desicion at that time just for get 5 seconds of boot time
<wpwrak>
rafa: not sure if and how the 2 GB -> 512 -> 256 happened. just saw the 256 -> 512 change.
<kristianpaul>
i think larsc remenber better that us
<wpwrak>
well, 5 s is a long time if you're waiting ...
<kristianpaul>
yes sure
<rafa>
kristianpaul: yes.. but well, if nn is some day a product more like a phone I would like it booting in just 2seconds.. but now yes, we can wait a bit more. Or it would be cool to know the reasons ideas about modifying that
<rafa>
kristianpaul: so we can give our ideas/opinions as well
<rafa>
kristianpaul: before the change happens :)
<kristianpaul>
rafa: about that i will remove gcc at first place
<kristianpaul>
and just give it like an option
<kristianpaul>
but want i see is that every new package is included as no option
<rafa>
wpwrak: (announced) ah, I see then that is why I do not know well the whole story and their reasons
<kristianpaul>
wich is not bad , at least when it is 60MB big? i think is gcc, not sure at all
<kristianpaul>
any way..
<kristianpaul>
Night to take a beer
<kristianpaul>
see you tomorrow
<rafa>
jaja ;)
<kristianpaul>
about ssh and my ilusinations i say, why not give disable automatica startup and give a key bidning to acitvate it
<kristianpaul>
tha could save valious startup time too
<kristianpaul>
also save memory
<kristianpaul>
called "transfer mode" just make posible able and disable it
<kristianpaul>
you dont need it running all time
<kristianpaul>
but you need it there later
<kristianpaul>
chao !
<wpwrak>
kristianpaul: it's nice to have ssh even if you don't have a display :)
<kristianpaul>
wpwrak: why? what for?
<kristianpaul>
i SAID key binding
<kristianpaul>
but is true
<wpwrak>
when you disconnect it :)
<wpwrak>
key binding may still need some visual verification of the device state
<wpwrak>
naw, just launch it in parallel with the rest
<kristianpaul>
ok,,
<kristianpaul>
second try against ssh runing failed ;)
<kristianpaul>
ya
<kristianpaul>
not parallelr
<kristianpaul>
may be after 20 seconds
<kristianpaul>
just make sure you get a nice screen first with gmenu2x
<kristianpaul>
later lanuch ssh
<kristianpaul>
no?
<wpwrak>
it probably doesn't do much anyway. probably waits for /dev/random or such.
<kristianpaul>
hmm
<kristianpaul>
ok
<wpwrak>
anyway, enjoy your beer ! ;-)
<kristianpaul>
thanks
<roh>
hi wolfgang
<wolfspraul>
roh: pong
<roh>
i just found some milkymist-stickers here at the agency. also i heard that somebody of the devel team is in berlin atm?
<roh>
something about 'a mission to build a case for it' ?
<wolfspraul>
roh: ah, cool
<wolfspraul>
yes of course the founder of the Milkymist project moved to Berlin a few months ago
<wolfspraul>
Sebastien Bourdeauducq
<wolfspraul>
and yes, a case would be really cool
<roh>
nice. he should visit us sometime, then i am sure we can work something out
<wolfspraul>
ok let me make an email intro since he is not in irc right now (his irc nick is 'lekernel', and he is in #qi-hardware as well as #milkymist on freenode)
<roh>
ah. ok.
<wolfspraul>
roh: your email is still @om.org ?
<roh>
jabber is nice ;)
<roh>
wolfspraul use @hyte.de
<roh>
om still works, but i rarely check it
<wolfspraul>
email sent
<roh>
:)
<wolfspraul>
roh: what materials or process would you have for making the case?
<roh>
anything you can laser, mill or cut. just depends on how complex it will be
<roh>
i would go for finding a readymade plastic case and laser or mill the custom holes for the connectors
<roh>
alternatively one can always do sheet-matieral based cases with the laser.. e.g. acryllic
<wolfspraul>
that whole jtag-serial thing is probably only necessary for the first units, or first 1-2 years
<wolfspraul>
later there will be quite robust 'reset to factory default' and jtag-serial will only be necessary for a few people
<roh>
sure
<wolfspraul>
so :-) do you have any rough idea/first guess on how long this would take, to laser cut into plastic...
<roh>
nope. its really extremely material dependant. and thickness
<roh>
one usually buys some sheets of some material to test and does runs to find  optimum parameters, then comes the real run to do something useful
<wpwrak>
that board has connectors at all sides. that makes it difficult. probably impossible to find a ready-made case. (that is, unless one was considered when dimensioning the board)
<wpwrak>
for a custom case, how about a base and top sheet of acrylic, mill grooves for the positions of lateral plates. then make 2D lateral plates. maybe laser first, mill metal later.
<wpwrak>
then the only remaining problem would be the corners. maybe some flexible material could be found for them. seal the gaps with silicone ;-)
<roh>
we'll see
<roh>
sometimes after some prototyping in plywood one gets the right idea
<wpwrak>
to keep it all together, use (in the four corners) plastic tubes of precise length at stand-offs, with a long screw through them
<wpwrak>
wood is nice. you can always fall back to nails ;-)