<kyak> xiangfu: hi! is there a final solution for that libiconv-full and gettext-full problem?
<xiangfu> kyak: so far , no :( . my idea is wait Upstream a little.
<xiangfu> kyak: by the way. I think we only build the SDK. I have remove the Imagebuilder and Toolchian in config.full_system.
<xiangfu> kyak: I have try the SDK a little. seems it's easy develop package. in sdk.
<xiangfu> kyak: there are so many packages in my TODO list. :)  I need ask in mailing list for help.
<xiangfu> kyak: but first. I will write a manual about how to develop package in SDK. I think I will finish that today.
<kyak> yes, this sounds great
<kyak> xiangfu: is there a bug report for *-full?
<xiangfu> kyak: only me report me. :)
<xiangfu> only me report one.
<kyak> do you expect to get it fixed soon?
<kyak> *do you expect it will be fixed soon?
<xiangfu> kyak: I don't think so. but I want know their plan on this *-full. I mean what about other packages. who will test or they just wait for report package.
<xiangfu> *report package error
<kyak> i have a feeling they won't change anything
<xiangfu> kyak:  oh..
<kyak> maybe we will have to override libiconv and gettext from openwrt-packages
<xiangfu> kyak: another thing. for fix our problem. I upload the feeds.conf to the "image files" :
<xiangfu> kyak: yes. that is another solution. :)
<kyak> this is not a real fix.. just a way to follow the latest "release"
<kyak> if someone (like me) want to build the latest image, he will get problems
<xiangfu> kyak: yes.
<xiangfu> kyak: hmm... let's just start add 'libiconv' and 'gettext' in openwrt-packages.
<kyak> yep, it seems like we can take the *-full versions, but with some modifications
<xiangfu> the SDK always try to use the static PATH.
<xiangfu> so myabe we need a better static PATH on build host. like /opt/openwrt
<xiangfu> when people can just extra the SDK.tar.gz2 to /opt
<kyak> hm, i thought that SDK would build the toolchain, so it doesn't really matter where to extract?
<kristianpaul> damn no sync..
<kristianpaul> oh well.. lets review wiring scheme again
<kristianpaul> ahh i missed that on the ucf file, hehe
<valhalla> I'm still using jlime on the NN from tuxbrain and I can't find where the keymap is defined (and/or how do I enter a "`"), any hint?
<kristianpaul> dont remenber it was solved latelly for other jlime version..
<qi-bot> [commit] David Kühling: Fix problems with missing tty for launched applications http://qi-hw.com/p/gmenu2x/dd0709e
<kristianpaul> "EMC allows to configure Setup(TAS), Wait(TAW) and Hold(TAH) cycles" that explain my ramdon sync readings..
<kristianpaul> hmm i'm reading 3-4 times same data..
<kristianpaul> mux != array :S
<kristianpaul> thats explain why so much 0s..
<kristianpaul> *may*
<kristianpaul> s/may/could
<wpwrak_> perhaps
<kristianpaul> argg no i changed the case stament by to if and still same..
<kristianpaul> s/to/two
<kristianpaul> why so muchs 0s between data..
<wpwrak_> weak signal ?
<kristianpaul> i'm about to find it, i'll dump data without wait for sync
<kristianpaul> weak i hope not, i already tested edge of signals (clk  and sync from SiGE) on the fpga with a counter and worked fine
<wpwrak_> i mean a weak analog signal.
<kristianpaul> froma atenna?
<wpwrak_> well, GPS analog signal, to be precise
<wpwrak_> yes
<wpwrak_> weak signal -> lots of zeroes :-)
<kristianpaul> well i already tested my atenna with my closed source GPS and worked well (this was some weeks ago tought)
<kristianpaul> the atenna is not on the roof but in  the window should be okay
<wpwrak_> by the way, how much is "so much 0s" ? 99% of all bits ? 100% ? ...
<kristianpaul> in a 10Mb samples every ~12 Bytes
<kristianpaul> i dont have the method to get the % now
<wpwrak_> a non-zero value every ~12 bytes ?
<kristianpaul> yes
<kristianpaul> the ~ scare me more ;)
<wpwrak_> doesn't sound too horrible. something you could try: connect the FPGA inputs (for signals from the RF chip) to GPIOs of the SIE, and generate a test pattern by software. then see if it is received correctly.
<kristianpaul> i did that before !!
<kristianpaul> and works like a charm..
<wpwrak_> why would the ~ be scary ? if you're receiving a real signal, you can expect some variation
<kristianpaul> well may be i need a bigger test patterm
<wpwrak_> (test) great !
<kristianpaul> (scary) yes but... data is supposed to be synced
<wpwrak_> synced with what ?
<kristianpaul> SiGE sync/2
<kristianpaul> every 8 bits of data there is a 1 bit sync signal
<kristianpaul> in other registers
<kristianpaul> (s) < ignore
<wpwrak_> and that doesn't appear either ?
<kristianpaul> i dint measure that yet, in a proper way
<kristianpaul> wait a min
<kristianpaul> i'll check that i was doing it but i swiched to something else (data dump) dont remenber why now
<kristianpaul> Any recomedantion for a good hexeditor?
<kristianpaul> able to highliht patterns given in binary or hex?
<larsc> hd
<kristianpaul> link?
<kristianpaul> i founded but hdx. is that the same?
<kristianpaul> wpwrak_: (sync) well i think i'm missing something when reading this registers, or may be the verilog module, cause i'm getting the sync bit, but in a not very good looking pattern..
<kristianpaul> ah hexdump is better selfexplain ;-)
<Jay7> kristianpaul: okteta :)
<Jay7> (kde)
<Jay7> or biew (console)
<wolfspraul> wpwrak_: no worry about speed of kicad testing, take your time. the one thing that would help me is that you green-light the overall direction, and that we merge my patches and yours into one location, I suggest eda-tools, and that you are OK with me committing there directly.
<wpwrak_> Jay7: sounds interesting in spanish :) ok-teta = nice tit ? :)
<Jay7> wpwrak_: hehe :)
<wolfspraul> after that, I want to merge your eeschema --plot patch with my --bom, and I want to add --erc too, and --help etc.
<Jay7> didn't know that :)
<wpwrak_> wolfspraul: (eda-tools) sure. perfect place.
<wolfspraul> but I will wait (and again, zero urgency), so that we avoid scattering multiple patchsets around, that's the only reason why I don't move forward right now...
<Jay7> like spanish language.. one time I'll learn it :)
<wpwrak_> wolfspraul: i don't think there is much risk of causing confusions. and eventually such things should migrate from openmoko.org anyway
<wolfspraul> yes but I don't want to trample over your sources :-)
<wolfspraul> so since the next step would be to merge your --plot patch into something bigger (in eeschema), I wait a bit...
<wpwrak_> naw, feel free :) your C++ is probably lots cleaner than my feeble attempts anyway :)
<wolfspraul> alright then. I still wait a bit see whether the pcbnew stuff works for you. after that, we move kicad-patches to eda-tools, and I clean up my stuff a bit more, and add more options to eeschema.
<wolfspraul> also, you will see in the pcbnew options that the structure of the options is still in flux. I expect KiCad to evolve as well.
<wolfspraul> for example hpgl, postscript, gerber and dxf are in one dialog, and svg is in another.
<wolfspraul> doesn't make real sense
<wolfspraul> some dialogs are very big, and if you change the plot type, you will see some dialog controls getting enabled/disabled because they don't apply to that type.
<wolfspraul> and so on
<wolfspraul> then, we may want more options on the command line, that depends on your input too
<wpwrak_> yeah. i also wonder if one of the two BOM outputs is preferred over the other
<wolfspraul> there are _many_ options in the dialogs that you cannot control from the command line right now.
<wolfspraul> adding them is easy though, the biggest part is to understand what we need and evolve the command line options in such a way that we don't always break backwards compatibility with Makefiles we already have.
<wpwrak_> yup. stability is nice to have :)
<wolfspraul> for bom formats, they draw from different base files, .sch or .brd
<wolfspraul> and as you know in eeschema or pcbnew, there is pretty much no knowledge of the 'other' side
<wolfspraul> so the bom of eeschema and pcbnew may diverge
<wolfspraul> I think for something like boom, it doesn't matter which one it takes
<wolfspraul> what we can do on the server is to do automated consistency checks between the two boms
<wolfspraul> together with automatically generating erc and drc reports, and many other useful automated tasks
<wolfspraul> but let's first stabilize the whole cmdline thing
<wolfspraul> then get it deployed on the server (upon commits)
<wolfspraul> and then think what additional value we can extract from the generated files
<wolfspraul> in parallel (client side), you will hopefully be able to Makefilize your entire cam workflow...
<wpwrak_> (bom) hmm, not sure if it's so easy for them to diverge. eeschema does seem to pass all the bom information along.
<wpwrak_> (makefilize) yup, that's the plan
<wolfspraul> wpwrak_: oh it's very easy for them to diverge. Someone just edits the schematics :-)
<wolfspraul> one thing I could see at some point in the future is a small consistency check script we could run on the server. but that's so many steps out now, don't know when it would be the top of the priority list...
<wpwrak_> wolfspraul: (edit schematics) okay, but when you then export the netlist and import it in pcbnew, the changes should propagate
<wolfspraul> yes, 'when', or 'if'? :-)
<wpwrak_> a check that .sch < .cmp, .net < .brd would indeed be useful
<wpwrak_> i think we had such stale netlists already :)
<kristianpaul> If FPGA in SIE shares IO with (SDRAM,
<kristianpaul> Who manage or keep acess timing to both devices..
<kristianpaul> Is funny but i'm reading fpga like a sram to then load this data on SDRAM.. so, i guess i'll fight agains latency or bus priority somehow at the end.
<kristianpaul> read Ingenic datasheet again
<LunaVorax> Hi everyone !
<kristianpaul> hmm i need a buffer
<kristianpaul> LunaVorax: hola :)
<LunaVorax> Is qi-hw planning to make an ARM based device ?
<kristianpaul> ergg no
<kristianpaul> milkymist CPU based for sure i think :-)
<kristianpaul> oh Burst ROM
<kristianpaul> looks interesting aprouch for my current needs
<qi-bot> [commit] Andres Calderon: some footprints has been assigned http://qi-hw.com/p/xue/ff84a19
<qi-bot> [commit] Andres Calderon: mdc rule added to modules makefile http://qi-hw.com/p/xue/8f5c2e3
<qi-bot> [commit] Andres Calderon: new psu components in the pcb... placement pendent http://qi-hw.com/p/xue/e1d2dfa
<qi-bot> [commit] Andres Calderon: cleanup http://qi-hw.com/p/xue/3ca941d
<hajabooja> Hey all, I'm looking to upgrade my video card. I'm look at the Radeon 5870. I currently have a OCZ PowerStream PSU http://www.ocztechnology.com/products/memory/ocz_powerstream_power_supply-eol Will this be enough to power it?