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