#qi-hardware IRC log for Sunday, 2010-12-26

kyakxiangfu: hi! is there a final solution for that libiconv-full and gettext-full problem?02:26
xiangfukyak: so far , no :( . my idea is wait Upstream a little.02:33
xiangfukyak: by the way. I think we only build the SDK. I have remove the Imagebuilder and Toolchian in config.full_system.02:33
xiangfukyak: I have try the SDK a little. seems it's easy develop package. in sdk.02:34
xiangfukyak: there are so many packages in my TODO list. :)  I need ask in mailing list for help.02:34
xiangfukyak: but first. I will write a manual about how to develop package in SDK. I think I will finish that today.02:35
kyakyes, this sounds great02:35
kyakxiangfu: is there a bug report for *-full?02:36
xiangfukyak: only me report me. :)02:37
xiangfuonly me report one.02:37
kyakdo you expect to get it fixed soon?02:40
kyak*do you expect it will be fixed soon?02:40
xiangfukyak: 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.02:42
xiangfu*report package error02:44
kyaki have a feeling they won't change anything02:46
xiangfukyak:  oh..02:46
kyakmaybe we will have to override libiconv and gettext from openwrt-packages02:46
xiangfukyak: another thing. for fix our problem. I upload the feeds.conf to the "image files" :02:46
xiangfuhttp://downloads.qi-hardware.com/software/images/Ben_NanoNote_2GB_NAND/latest/feeds.conf02:46
xiangfukyak: yes. that is another solution. :)02:47
kyakthis is not a real fix.. just a way to follow the latest "release"02:47
kyakif someone (like me) want to build the latest image, he will get problems02:47
xiangfukyak: yes.02:47
xiangfukyak: hmm... let's just start add 'libiconv' and 'gettext' in openwrt-packages.02:49
kyakyep, it seems like we can take the *-full versions, but with some modifications02:50
xiangfuthe SDK always try to use the static PATH.03:20
xiangfuso myabe we need a better static PATH on build host. like /opt/openwrt03:21
xiangfuwhen people can just extra the SDK.tar.gz2 to /opt03:21
kyakhm, i thought that SDK would build the toolchain, so it doesn't really matter where to extract?03:23
kristianpauldamn no sync..10:21
kristianpauloh well.. lets review wiring scheme again10:34
kristianpaulahh i missed that on the ucf file, hehe10:35
valhallaI'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?11:17
kristianpauldont remenber it was solved latelly for other jlime version..11:23
qi-bot[commit] David K├╝hling: Fix problems with missing tty for launched applications http://qi-hw.com/p/gmenu2x/dd0709e11:58
kristianpaul"EMC allows to configure Setup(TAS), Wait(TAW) and Hold(TAH) cycles" that explain my ramdon sync readings..12:07
kristianpaulhmm i'm reading 3-4 times same data..12:16
kristianpaulhttp://downloads.qi-hardware.com/people/kristianpaul/data_sige.bin.tar.gz12:38
kristianpaulmux != array :S13:04
kristianpaulthats explain why so much 0s..13:13
kristianpaul*may*13:17
kristianpauls/may/could13:19
wpwrak_perhaps13:27
kristianpaulargg no i changed the case stament by to if and still same..13:30
kristianpauls/to/two13:30
kristianpaulwhy so muchs 0s between data..13:32
wpwrak_weak signal ?13:43
kristianpauli'm about to find it, i'll dump data without wait for sync13:46
kristianpaulweak i hope not, i already tested edge of signals (clk  and sync from SiGE) on the fpga with a counter and worked fine13:49
wpwrak_i mean a weak analog signal.13:51
kristianpaulfroma atenna?13:51
wpwrak_well, GPS analog signal, to be precise13:51
wpwrak_yes13:51
wpwrak_weak signal -> lots of zeroes :-)13:51
kristianpaulwell i already tested my atenna with my closed source GPS and worked well (this was some weeks ago tought)13:52
kristianpaulthe atenna is not on the roof but in  the window should be okay13:52
wpwrak_by the way, how much is "so much 0s" ? 99% of all bits ? 100% ? ...13:54
kristianpaulin a 10Mb samples every ~12 Bytes13:55
kristianpauli dont have the method to get the % now13:55
wpwrak_a non-zero value every ~12 bytes ?13:58
kristianpaulyes13:58
kristianpaulthe ~ scare me more ;)13:58
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.13:59
kristianpauli did that before !!13:59
kristianpauland works like a charm..13:59
wpwrak_why would the ~ be scary ? if you're receiving a real signal, you can expect some variation13:59
kristianpaulwell may be i need a bigger test patterm13:59
wpwrak_(test) great !13:59
kristianpaul(scary) yes but... data is supposed to be synced14:00
wpwrak_synced with what ?14:00
kristianpaulSiGE sync/214:00
kristianpaulevery 8 bits of data there is a 1 bit sync signal14:01
kristianpaulin other registers14:01
kristianpaul(s) < ignore14:01
wpwrak_and that doesn't appear either ?14:01
kristianpauli dint measure that yet, in a proper way14:02
kristianpaulwait a min14:02
kristianpauli'll check that i was doing it but i swiched to something else (data dump) dont remenber why now14:02
kristianpaulAny recomedantion for a good hexeditor?14:08
kristianpaulable to highliht patterns given in binary or hex?14:09
larschd14:09
kristianpaullink?14:12
kristianpauli founded but hdx. is that the same?14:12
kristianpaulwpwrak_: (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..14:13
larschttp://www.manpagez.com/man/1/hexdump/14:14
kristianpaulah hexdump is better selfexplain ;-)14:14
Jay7kristianpaul: okteta :)14:14
Jay7(kde)14:15
Jay7or biew (console)14:15
wolfspraulwpwrak_: 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.14:16
wpwrak_Jay7: sounds interesting in spanish :) ok-teta = nice tit ? :)14:16
Jay7wpwrak_: hehe :)14:16
wolfspraulafter that, I want to merge your eeschema --plot patch with my --bom, and I want to add --erc too, and --help etc.14:16
Jay7didn't know that :)14:16
wpwrak_wolfspraul: (eda-tools) sure. perfect place.14:16
wolfspraulbut 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...14:17
Action: Jay7 like spanish language.. one time I'll learn it :)14:17
wpwrak_wolfspraul: i don't think there is much risk of causing confusions. and eventually such things should migrate from openmoko.org anyway14:18
wolfspraulyes but I don't want to trample over your sources :-)14:18
wolfspraulso since the next step would be to merge your --plot patch into something bigger (in eeschema), I wait a bit...14:19
wpwrak_naw, feel free :) your C++ is probably lots cleaner than my feeble attempts anyway :)14:19
wolfspraulalright 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.14:21
wolfspraulalso, you will see in the pcbnew options that the structure of the options is still in flux. I expect KiCad to evolve as well.14:22
wolfspraulfor example hpgl, postscript, gerber and dxf are in one dialog, and svg is in another.14:22
wolfsprauldoesn't make real sense14:22
wolfspraulsome 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.14:23
wolfsprauland so on14:23
wolfspraulthen, we may want more options on the command line, that depends on your input too14:23
wpwrak_yeah. i also wonder if one of the two BOM outputs is preferred over the other14:23
wolfspraulthere are _many_ options in the dialogs that you cannot control from the command line right now.14:23
wolfsprauladding 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.14:23
wpwrak_yup. stability is nice to have :)14:24
wolfspraulfor bom formats, they draw from different base files, .sch or .brd14:25
wolfsprauland as you know in eeschema or pcbnew, there is pretty much no knowledge of the 'other' side14:25
wolfspraulso the bom of eeschema and pcbnew may diverge14:25
wolfspraulI think for something like boom, it doesn't matter which one it takes14:25
wolfspraulwhat we can do on the server is to do automated consistency checks between the two boms14:25
wolfspraultogether with automatically generating erc and drc reports, and many other useful automated tasks14:26
wolfspraulbut let's first stabilize the whole cmdline thing14:26
wolfspraulthen get it deployed on the server (upon commits)14:26
wolfsprauland then think what additional value we can extract from the generated files14:27
wolfspraulin parallel (client side), you will hopefully be able to Makefilize your entire cam workflow...14:27
wpwrak_(bom) hmm, not sure if it's so easy for them to diverge. eeschema does seem to pass all the bom information along.14:35
wpwrak_(makefilize) yup, that's the plan14:36
wolfspraulwpwrak_: oh it's very easy for them to diverge. Someone just edits the schematics :-)14:54
wolfspraulone 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...14:55
wpwrak_wolfspraul: (edit schematics) okay, but when you then export the netlist and import it in pcbnew, the changes should propagate14:55
wolfspraulyes, 'when', or 'if'? :-)14:56
wpwrak_a check that .sch < .cmp, .net < .brd would indeed be useful14:57
wpwrak_i think we had such stale netlists already :)14:57
kristianpaulIf FPGA in SIE shares IO with (SDRAM,15:11
kristianpaulWho manage or keep acess timing to both devices..15:11
kristianpaulIs 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.15:12
Action: kristianpaul read Ingenic datasheet again15:13
LunaVoraxHi everyone !15:17
kristianpaulhmm i need a buffer15:37
kristianpaulLunaVorax: hola :)15:37
LunaVoraxIs qi-hw planning to make an ARM based device ?15:38
kristianpaulergg no15:39
kristianpaulmilkymist CPU based for sure i think :-)15:39
kristianpauloh Burst ROM15:43
kristianpaullooks interesting aprouch for my current needs15:43
qi-bot[commit] Andres Calderon: some footprints has been assigned http://qi-hw.com/p/xue/ff84a1919:08
qi-bot[commit] Andres Calderon: mdc rule added to modules makefile http://qi-hw.com/p/xue/8f5c2e319:08
qi-bot[commit] Andres Calderon: new psu components in the pcb... placement pendent http://qi-hw.com/p/xue/e1d2dfa19:16
qi-bot[commit] Andres Calderon: cleanup http://qi-hw.com/p/xue/3ca941d19:17
hajaboojaHey 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?22:30
--- Mon Dec 27 201000:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!