2010-12-26 02:26 xiangfu: hi! is there a final solution for that libiconv-full and gettext-full problem? 2010-12-26 02:33 kyak: so far , no :( . my idea is wait Upstream a little. 2010-12-26 02:33 kyak: by the way. I think we only build the SDK. I have remove the Imagebuilder and Toolchian in config.full_system. 2010-12-26 02:34 kyak: I have try the SDK a little. seems it's easy develop package. in sdk. 2010-12-26 02:34 kyak: there are so many packages in my TODO list. :)  I need ask in mailing list for help. 2010-12-26 02:35 kyak: but first. I will write a manual about how to develop package in SDK. I think I will finish that today. 2010-12-26 02:35 yes, this sounds great 2010-12-26 02:36 xiangfu: is there a bug report for *-full? 2010-12-26 02:37 kyak: only me report me. :) 2010-12-26 02:37 only me report one. 2010-12-26 02:40 do you expect to get it fixed soon? 2010-12-26 02:40 *do you expect it will be fixed soon? 2010-12-26 02:42 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. 2010-12-26 02:44 *report package error 2010-12-26 02:46 i have a feeling they won't change anything 2010-12-26 02:46 kyak:  oh.. 2010-12-26 02:46 maybe we will have to override libiconv and gettext from openwrt-packages 2010-12-26 02:46 kyak: another thing. for fix our problem. I upload the feeds.conf to the "image files" : 2010-12-26 02:46 http://downloads.qi-hardware.com/software/images/Ben_NanoNote_2GB_NAND/latest/feeds.conf 2010-12-26 02:47 kyak: yes. that is another solution. :) 2010-12-26 02:47 this is not a real fix.. just a way to follow the latest "release" 2010-12-26 02:47 if someone (like me) want to build the latest image, he will get problems 2010-12-26 02:47 kyak: yes. 2010-12-26 02:49 kyak: hmm... let's just start add 'libiconv' and 'gettext' in openwrt-packages. 2010-12-26 02:50 yep, it seems like we can take the *-full versions, but with some modifications 2010-12-26 03:20 the SDK always try to use the static PATH. 2010-12-26 03:21 so myabe we need a better static PATH on build host. like /opt/openwrt 2010-12-26 03:21 when people can just extra the SDK.tar.gz2 to /opt 2010-12-26 03:23 hm, i thought that SDK would build the toolchain, so it doesn't really matter where to extract? 2010-12-26 10:21 damn no sync.. 2010-12-26 10:34 oh well.. lets review wiring scheme again 2010-12-26 10:35 ahh i missed that on the ucf file, hehe 2010-12-26 11:17 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? 2010-12-26 11:23 dont remenber it was solved latelly for other jlime version.. 2010-12-26 11:58 [commit] David Kühling: Fix problems with missing tty for launched applications http://qi-hw.com/p/gmenu2x/dd0709e 2010-12-26 12:07 "EMC allows to configure Setup(TAS), Wait(TAW) and Hold(TAH) cycles" that explain my ramdon sync readings.. 2010-12-26 12:16 hmm i'm reading 3-4 times same data.. 2010-12-26 12:38 http://downloads.qi-hardware.com/people/kristianpaul/data_sige.bin.tar.gz 2010-12-26 13:04 mux != array :S 2010-12-26 13:13 thats explain why so much 0s.. 2010-12-26 13:17 *may* 2010-12-26 13:19 s/may/could 2010-12-26 13:27 perhaps 2010-12-26 13:30 argg no i changed the case stament by to if and still same.. 2010-12-26 13:30 s/to/two 2010-12-26 13:32 why so muchs 0s between data.. 2010-12-26 13:43 weak signal ? 2010-12-26 13:46 i'm about to find it, i'll dump data without wait for sync 2010-12-26 13:49 weak i hope not, i already tested edge of signals (clk  and sync from SiGE) on the fpga with a counter and worked fine 2010-12-26 13:51 i mean a weak analog signal. 2010-12-26 13:51 froma atenna? 2010-12-26 13:51 well, GPS analog signal, to be precise 2010-12-26 13:51 yes 2010-12-26 13:51 weak signal -> lots of zeroes :-) 2010-12-26 13:52 well i already tested my atenna with my closed source GPS and worked well (this was some weeks ago tought) 2010-12-26 13:52 the atenna is not on the roof but in  the window should be okay 2010-12-26 13:54 by the way, how much is "so much 0s" ? 99% of all bits ? 100% ? ... 2010-12-26 13:55 in a 10Mb samples every ~12 Bytes 2010-12-26 13:55 i dont have the method to get the % now 2010-12-26 13:58 a non-zero value every ~12 bytes ? 2010-12-26 13:58 yes 2010-12-26 13:58 the ~ scare me more ;) 2010-12-26 13:59 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. 2010-12-26 13:59 i did that before !! 2010-12-26 13:59 and works like a charm.. 2010-12-26 13:59 why would the ~ be scary ? if you're receiving a real signal, you can expect some variation 2010-12-26 13:59 well may be i need a bigger test patterm 2010-12-26 13:59 (test) great ! 2010-12-26 14:00 (scary) yes but... data is supposed to be synced 2010-12-26 14:00 synced with what ? 2010-12-26 14:00 SiGE sync/2 2010-12-26 14:01 every 8 bits of data there is a 1 bit sync signal 2010-12-26 14:01 in other registers 2010-12-26 14:01 (s) < ignore 2010-12-26 14:01 and that doesn't appear either ? 2010-12-26 14:02 i dint measure that yet, in a proper way 2010-12-26 14:02 wait a min 2010-12-26 14:02 i'll check that i was doing it but i swiched to something else (data dump) dont remenber why now 2010-12-26 14:08 Any recomedantion for a good hexeditor? 2010-12-26 14:09 able to highliht patterns given in binary or hex? 2010-12-26 14:09 hd 2010-12-26 14:12 link? 2010-12-26 14:12 i founded but hdx. is that the same? 2010-12-26 14:13 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.. 2010-12-26 14:14 http://www.manpagez.com/man/1/hexdump/ 2010-12-26 14:14 ah hexdump is better selfexplain ;-) 2010-12-26 14:14 kristianpaul: okteta :) 2010-12-26 14:15 (kde) 2010-12-26 14:15 or biew (console) 2010-12-26 14:16 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. 2010-12-26 14:16 Jay7: sounds interesting in spanish :) ok-teta = nice tit ? :) 2010-12-26 14:16 wpwrak_: hehe :) 2010-12-26 14:16 after that, I want to merge your eeschema --plot patch with my --bom, and I want to add --erc too, and --help etc. 2010-12-26 14:16 didn't know that :) 2010-12-26 14:16 wolfspraul: (eda-tools) sure. perfect place. 2010-12-26 14:17 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... 2010-12-26 14:17 like spanish language.. one time I'll learn it :) 2010-12-26 14:18 wolfspraul: i don't think there is much risk of causing confusions. and eventually such things should migrate from openmoko.org anyway 2010-12-26 14:18 yes but I don't want to trample over your sources :-) 2010-12-26 14:19 so since the next step would be to merge your --plot patch into something bigger (in eeschema), I wait a bit... 2010-12-26 14:19 naw, feel free :) your C++ is probably lots cleaner than my feeble attempts anyway :) 2010-12-26 14:21 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. 2010-12-26 14:22 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. 2010-12-26 14:22 for example hpgl, postscript, gerber and dxf are in one dialog, and svg is in another. 2010-12-26 14:22 doesn't make real sense 2010-12-26 14:23 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. 2010-12-26 14:23 and so on 2010-12-26 14:23 then, we may want more options on the command line, that depends on your input too 2010-12-26 14:23 yeah. i also wonder if one of the two BOM outputs is preferred over the other 2010-12-26 14:23 there are _many_ options in the dialogs that you cannot control from the command line right now. 2010-12-26 14:23 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. 2010-12-26 14:24 yup. stability is nice to have :) 2010-12-26 14:25 for bom formats, they draw from different base files, .sch or .brd 2010-12-26 14:25 and as you know in eeschema or pcbnew, there is pretty much no knowledge of the 'other' side 2010-12-26 14:25 so the bom of eeschema and pcbnew may diverge 2010-12-26 14:25 I think for something like boom, it doesn't matter which one it takes 2010-12-26 14:25 what we can do on the server is to do automated consistency checks between the two boms 2010-12-26 14:26 together with automatically generating erc and drc reports, and many other useful automated tasks 2010-12-26 14:26 but let's first stabilize the whole cmdline thing 2010-12-26 14:26 then get it deployed on the server (upon commits) 2010-12-26 14:27 and then think what additional value we can extract from the generated files 2010-12-26 14:27 in parallel (client side), you will hopefully be able to Makefilize your entire cam workflow... 2010-12-26 14:35 (bom) hmm, not sure if it's so easy for them to diverge. eeschema does seem to pass all the bom information along. 2010-12-26 14:36 (makefilize) yup, that's the plan 2010-12-26 14:54 wpwrak_: oh it's very easy for them to diverge. Someone just edits the schematics :-) 2010-12-26 14:55 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... 2010-12-26 14:55 wolfspraul: (edit schematics) okay, but when you then export the netlist and import it in pcbnew, the changes should propagate 2010-12-26 14:56 yes, 'when', or 'if'? :-) 2010-12-26 14:57 a check that .sch < .cmp, .net < .brd would indeed be useful 2010-12-26 14:57 i think we had such stale netlists already :) 2010-12-26 15:11 If FPGA in SIE shares IO with (SDRAM, 2010-12-26 15:11 Who manage or keep acess timing to both devices.. 2010-12-26 15:12 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. 2010-12-26 15:13 read Ingenic datasheet again 2010-12-26 15:17 Hi everyone ! 2010-12-26 15:37 hmm i need a buffer 2010-12-26 15:37 LunaVorax: hola :) 2010-12-26 15:38 Is qi-hw planning to make an ARM based device ? 2010-12-26 15:39 ergg no 2010-12-26 15:39 milkymist CPU based for sure i think :-) 2010-12-26 15:43 oh Burst ROM 2010-12-26 15:43 looks interesting aprouch for my current needs 2010-12-26 19:08 [commit] Andres Calderon: some footprints has been assigned http://qi-hw.com/p/xue/ff84a19 2010-12-26 19:08 [commit] Andres Calderon: mdc rule added to modules makefile http://qi-hw.com/p/xue/8f5c2e3 2010-12-26 19:16 [commit] Andres Calderon: new psu components in the pcb... placement pendent http://qi-hw.com/p/xue/e1d2dfa 2010-12-26 19:17 [commit] Andres Calderon: cleanup http://qi-hw.com/p/xue/3ca941d 2010-12-26 22:30 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?