| 00:34.49 | *** join/#qi-hardware vano (~vano@176.Red-83-58-7.dynamicIP.rima-tde.net) |
| 00:37.35 | vano | Has anyone ever manager to use a USB mouse with the nanonote? |
| 00:37.35 | vano | ? |
| 00:37.54 | kristianpaul | not yet i remenber |
| 00:40.32 | vano | another thing… any fix for the hwclock not working ? Result: "select() to /dev/rtc0 to wait for clock tick timed out" |
| 00:51.45 | kristianpaul | ah, mouse i tought you meant nanononote as HID ! |
| 00:52.27 | kristianpaul | vano: you cant use nanonote with a usb mouse, the usb port is not host type |
| 00:53.07 | vano | yep. |
| 00:53.43 | wpwrak | you could of course try implementing a usb host via bit-banging ... |
| 00:53.50 | wpwrak | zrafa: how's that project going ? ;-) |
| 00:54.20 | vano | serial mouse? :P |
| 00:54.49 | wpwrak | vano: that would be even easier :) |
| 00:54.55 | kristianpaul | ah bit-bang nanonote most used feature yes :-) |
| 00:54.55 | vano | was thinking that |
| 01:00.39 | vano | Where can I find a boot image which doesn't have the fb screen (so I can see the console errors?) |
| 01:23.48 | mth | vano: there were some proposed patches on the mailinglist for that issue |
| 01:24.06 | mth | I don't really understand though why the error occurs on the NanoNote and not on the Dingoo |
| 01:24.18 | mth | (the RTC issue) |
| 01:24.28 | vano | yeah saw it there... |
| 01:25.09 | vano | any good links on compiling the kernel? |
| 01:27.42 | mth | get qi-kernel jz-3.2 branch from git |
| 01:27.47 | mth | make ARCH=mips qi_lb60_defconfig |
| 01:27.58 | mth | make ARCH=mips <image-type> |
| 01:28.06 | mth | not sure what the image type is that the NanoNote needs |
| 01:28.24 | mth | for Dingoo, it's vmlinuz.bin, but afaik the NN boot loader wants a different type |
| 01:52.25 | *** join/#qi-hardware rwil (~rwil@host86-162-165-136.range86-162.btcentralplus.com) |
| 01:53.46 | *** join/#qi-hardware TBJ (~tbj@host86-162-165-136.range86-162.btcentralplus.com) |
| 02:18.18 | qi-bot | [commit] Werner Almesberger: postscript.c (ps_for_all_pkg): "pages" was never initialized (master) http://qi-hw.com/p/fped/5130707 |
| 02:18.19 | qi-bot | [commit] Werner Almesberger: purge unused measurement instances (master) http://qi-hw.com/p/fped/43928db |
| 02:32.18 | *** join/#qi-hardware jurting (~jommpa90_@ip-159-244-230-46.dialup.ice.net) |
| 02:42.06 | roh | wpwrak: tried dxf2gcode yet? |
| 02:42.43 | roh | wpwrak: its on google projects... make sure to try the tkinter version from 2010 |
| 02:42.47 | roh | dxf2gcode-read-only/tags/2010-05-04-b02_tkinter253/ |
| 02:43.04 | roh | that one makes working gcode for me at least |
| 02:53.05 | *** join/#qi-hardware wej (~j@m2.mullvad.net) |
| 03:00.10 | wpwrak | looks interesting, thanks ! trying ... |
| 03:15.25 | wpwrak | hmm, can it also visualize the toolpath ? |
| 03:17.16 | wpwrak | all i get are outlines but not the areas themselves |
| 03:21.46 | wpwrak | e.g., for this sort of piece: http://downloads.qi-hardware.com/people/werner/tmp/t2.ps |
| 03:22.14 | wpwrak | keep or remove the hatched area |
| 03:22.52 | wpwrak | the outlines are a good start. but that's something i already have :) |
| 04:51.54 | *** join/#qi-hardware GNUtoo (~gnutoo@50.118-226-89.dsl.completel.net) |
| 05:24.02 | *** join/#qi-hardware panda|x201 (~hzhang@2001:5c0:1000:a::ac1) |
| 06:51.13 | qi-bot | [commit] Xiangfu: use kanoi repo. include the api changed (master) http://qi-hw.com/p/openwrt-packages/0a035ec |
| 06:51.14 | qi-bot | [commit] Xiangfu: remove other u-boot include SDK and toolchain (master) http://qi-hw.com/p/openwrt-packages/0f72773 |
| 06:51.15 | qi-bot | [commit] Xiangfu: nanonote-files: compile script file: collect all failed package in minial build (master) http://qi-hw.com/p/openwrt-packages/97b9b84 |
| 06:56.09 | roh | wpwrak: ah. i see what you mean. not something like the 'profile' but something like the 'pocket' in heeks, right? |
| 06:56.49 | wpwrak | yup |
| 06:56.59 | roh | check out the opencamlib stuff heeks uses, maybe thats something for you |
| 06:57.15 | roh | http://opencamlib.googlecode.com/ |
| 06:57.30 | wpwrak | i think i'm already halfway there :) NIH rules ! |
| 06:57.36 | roh | ah. its on github now |
| 06:58.32 | roh | well.. what i worry about on the current state of free cad and cam are the 'un-completeness' and buggy-isms |
| 06:59.27 | roh | would be good to have some of the features for '2.5d cam' which we have as half-way decent libs now in some working tool |
| 06:59.43 | roh | something between heekscam and dxf2gcode |
| 07:00.30 | roh | currently we are at a point where using commercial stuff like cambam on win32 solves problems more easy than my quite big opensource tool collection |
| 07:01.25 | wpwrak | phew. the top-level latest commits sound scary. " I got the Windows build to work again", "all the ocode scripts are deprecated", ... |
| 07:02.02 | roh | yeah, one can choose code from good coders or code from people who have a clue about milling |
| 07:02.15 | wpwrak | i think one problem is that it |
| 07:02.22 | roh | i havent seen something combined |
| 07:02.28 | wpwrak | 's hard to combine user-friendly and efficient |
| 07:02.42 | wpwrak | e.g., user-friendly often means some GUI that kinda guides you |
| 07:02.56 | roh | true. |
| 07:02.56 | wpwrak | efficient means scripting of all the parameters involved |
| 07:03.12 | roh | e.g. on heeks the ui was crappy due to mad multiplatform madness |
| 07:03.55 | roh | meant choosing wxwindows which made all platforms unbearable due to missing default dialogs and keybindings |
| 07:04.09 | roh | or tkinter |
| 07:05.28 | wpwrak | yeah, better to code for proper unix only |
| 07:05.39 | wpwrak | who cares about windows anyway ? |
| 07:06.10 | roh | ack. also if it works there properly, porting to others is easy. gtk on win32 and osx is available native now afaik. |
| 07:06.49 | wpwrak | (scripting) e.g., here's the script i used for the labsw front panel: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/labsw/mech/doit |
| 07:06.53 | roh | and yes, win32 and osx are really neccessary.. you would wonder how many 'users' there are, who still could give good advice |
| 07:07.23 | roh | have you seen the script heeks generates? |
| 07:08.39 | wpwrak | it does: 1) setting of the machine coordinate system. 2) positioning in a array (in case we want multiple parts from the same workpiece). 3) translation from 2D to 2.5D (that task has two different depths, one for engraving, the other for cutting). 4) at the end, conversion to RML |
| 07:08.45 | roh | all the toolpath is first converted to a python script with the individual function calls and comments, which is then executed to generate the gcode which is then parsed back and displayed into the gl-view with your model |
| 07:09.34 | wpwrak | i just use gnuplot as my interchange format :) |
| 07:09.40 | roh | and one can render out into different gcode dialects and formats |
| 07:09.53 | wpwrak | overengineering ;-) |
| 07:09.56 | roh | gnuplot isnt mighty enough i think |
| 07:10.13 | wpwrak | well, if you want arcs and such, then things get messy |
| 07:10.22 | roh | atleast not for complex 2.5d stuff (making surfaces by zigzag or waterlining) |
| 07:10.29 | wpwrak | i just turn everything into polygons |
| 07:10.45 | roh | dxf is nice for 2d stuff and easy to read and write (using dxflib, which seems to be the industry standard) |
| 07:11.02 | roh | wpwrak: doesnt work in reality (i need arcs for example) |
| 07:11.18 | roh | also the machine natively does arcs in the end |
| 07:11.37 | wpwrak | yeah, i convert arcs to polygons |
| 07:12.13 | roh | thats too simplified for what we need in reality... e.g. i currently work on milling pcb dummies for a customer |
| 07:12.14 | wpwrak | not super-efficient but it doesn't see to create any bottlenecks |
| 07:12.33 | wpwrak | well, in the end the mill does polygons too :) |
| 07:12.46 | wpwrak | it's just a question of the resolution |
| 07:12.58 | roh | i get dxf from the customer, remove the unneeded markings, and layers, and get lines and arcs as well as circle elements in the end |
| 07:13.25 | roh | that i need to preprocess to emc gcode in my case (iso gcode that means) and mill |
| 07:13.47 | roh | there is a gcode for the resolution, you know? |
| 07:14.25 | wpwrak | there's a gcode for pretty much everything :) |
| 07:14.47 | roh | because its also affecting the breaking and accelerating behaviour in curves and on corners. if you set it lower than the default (0.001mm) the machine gets _really_ slow since it wants to be really exact on positioning |
| 07:16.07 | roh | gcode for tool offsets are nice. basically you only need to tell it if it should be on line, left or right of it, and what tool, and it does the rest for you. no nasty math. somebody else made sure it does work and debugged it. |
| 07:16.30 | wpwrak | well, it's not all that bad ... |
| 07:17.44 | wpwrak | http://projects.qi-hardware.com/index.php/p/cae-tools/source/tree/master/cameo/path.c function path_offset (and the stuff it calls) |
| 07:17.54 | wpwrak | also does dog bones if asked nicely |
| 07:18.08 | roh | i actually like it, since its a grown up intermediate for the problem, which is still flexible enough, while so simple that one can parse/modify/write it by hand. |
| 07:21.31 | roh | where does rml come from? does anything besides roland mills/plotters use it? |
| 07:22.17 | wpwrak | is some bastardized HPGL |
| 07:22.18 | roh | just asking since the mit fablab cam.py is also supporting it |
| 07:22.31 | wpwrak | and no, i don't know of anything else using it |
| 07:22.47 | roh | ehehe. well.. thus it really makes sense to have pluggable output renderers |
| 07:22.48 | wpwrak | i think the mdx-15/20 are reasonably popular |
| 07:22.59 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 07:24.06 | wpwrak | i wonder why people don't make mills that understand gcode directly. the whole external machine control integration (via PC) is messy. |
| 07:24.46 | roh | wpwrak: hm? you need a strong cpu anyhow for the ui |
| 07:25.01 | roh | actually i havent seen a better ui that axis from emc2 |
| 07:25.25 | wpwrak | what kind of heavy lifting does the ui of emc2 do ? |
| 07:25.30 | roh | even has a gl-preview which commercial products are not havinh |
| 07:25.41 | roh | wpwrak: it does all the realtime-controlling |
| 07:25.55 | wpwrak | the UI ?? |
| 07:25.58 | roh | axis is only the ui (well.. one of the possible ones) |
| 07:26.34 | roh | the core is realtime since the control loop runs over it (motion planning etc). the mills are completely stupid. they do nothing intelligent. |
| 07:26.37 | wpwrak | what i mean is just gcode -> machine control. no fancy gui at that point |
| 07:26.46 | roh | doesnt help anybody |
| 07:27.23 | roh | without that ui i couldnt use the machine more than a really sucky to use 30 year old machine with a floppy for file input. people hate that. thats why they use mach3 or axis |
| 07:27.43 | roh | you need to home to your workpiece, you want to see if its moving over your clamps properly etc. |
| 07:28.15 | roh | it helps a lot seeing what it wants to do and where it wants to move BEFORE it actually does it. |
| 07:28.18 | wpwrak | http://projects.qi-hardware.com/index.php/p/cae-tools/source/tree/master/cngt/ |
| 07:29.05 | wpwrak | hmm, how can you till if it will bump into your clamps before it starts moving ? do you scan the clamps and model them ? |
| 07:29.52 | roh | also you need to understand that besides our 'childs toy mills' which only have a spindle, and 3 stepper motors and 3 homing switches, there are actually proper big machines. |
| 07:30.17 | wpwrak | cngt reads the model and then positions to selected points there (heavily 2.5D, of course. so it's the corners of the projection and the pen up / z = 0 positions) |
| 07:30.43 | roh | e.g. emc can be used to controll stuff which has dc motors and encoders on their axis (servos), or even hydraulic servos and more axes, rotating heads, complex toolchangers etc. |
| 07:31.55 | wpwrak | oh sure. but ... wouldn't it be nice of those low-cost china mills had their own controller that understands something like gcode ? |
| 07:31.58 | roh | people even used it to build robot controls by using a different motion planning code and different control interface. you do not always need to use gcode as input (one can also move it manually) |
| 07:32.13 | roh | no. you cannot even home properly without ui |
| 07:32.50 | wpwrak | add a pair of encoders :) |
| 07:32.51 | roh | because you wouldnt know what way around your part is facing etc. thats why milling engineers are quite well paid. |
| 07:33.17 | roh | the point is that it makes it more difficult by not having a proper computer there. also its 'no cost' compared to the mill |
| 07:33.31 | wpwrak | you're talking about fancy mills again |
| 07:33.35 | wpwrak | i mean the low-cost china stuff |
| 07:33.38 | roh | complete computers with enough power are 5 years old. even for fancy mills |
| 07:33.48 | roh | we HAVE a low cost china mill. |
| 07:34.01 | wpwrak | sigh. you know what i mean :) |
| 07:34.21 | roh | and it came with mach3. a parport is better and cheaper than anything else which can do controlling |
| 07:34.45 | roh | just mach3 sucked for us. so we used emc2, and its great. |
| 07:35.09 | roh | one of the few things in opensource cad/cam which is 'featurecomplete' from my pov. |
| 07:35.29 | wpwrak | is the parport assignment standardized ? or did you first have to reverse-engineer it ? |
| 07:35.43 | roh | also havent run into any real bugs or problems which werent my fault (not reading the documentation) |
| 07:36.29 | roh | its a parport, not much to document besides the pinout. we reversed it from mach3 configs and some cheap measurements (e.g. learning the chargepump-freq) |
| 07:37.12 | roh | the chargepump is a pin you wiggle constantly. if you stop the hardware disables all motors immediately. its like a software-dead-man-switch |
| 07:37.52 | wpwrak | sounds like a very reasonable safety precaution :) |
| 07:38.28 | roh | _yes_ for sure. especially if your motors are strong enough to not only cost you a finger but even worse |
| 07:39.04 | roh | the steppers do 2 digit newtonmeters and the spindle has 800W and gearheads |
| 07:39.55 | qi-bot | [commit] Xiangfu: nanonote: config.full_system, update uboot-envtools add CONFIG_PACKAGE_uboot-envtools_setenv_symlink (master) http://qi-hw.com/p/openwrt-packages/797ea0f |
| 07:40.37 | wpwrak | if i was your enemy, i wouldn't accept any invitation to the lab ;-) |
| 07:40.55 | roh | *veg* |
| 07:41.08 | roh | you know my definition of if something is a powertool or not? |
| 07:41.39 | roh | if it can cost you a finger, its a tool, if you can loose a limb, its a powertool |
| 07:44.25 | wpwrak | if it can casually paint the wall with you, then you begin to get interested ... :) |
| 07:44.59 | roh | maybe i can 'mix a pot of red paint' with the mill.. should leave nice red splatter around the room |
| 07:45.10 | roh | 'that was the last customer who was too nosy' |
| 07:50.15 | roh | wpwrak: you know http://www.hotrodscustomstuff.com/OLD_SITE/HUMOR/LABOR RATES.gif ? |
| 07:51.01 | roh | and http://yamato.hyte.de/tmp/lab_rules.png |
| 07:51.10 | roh | important for every lab/workshop |
| 07:55.08 | wpwrak | hehe :) |
| 08:01.26 | roh | hm. i think i'll test http://gcam.js.cx/index.php/Main_Page tomorrow |
| 08:34.29 | *** join/#qi-hardware vano (~vano@176.Red-83-58-7.dynamicIP.rima-tde.net) |
| 08:46.45 | *** join/#qi-hardware Ayla (~paul@186.132.123.78.rev.sfr.net) |
| 08:46.52 | *** join/#qi-hardware vano (~vano@176.Red-83-58-7.dynamicIP.rima-tde.net) |
| 08:48.01 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 08:48.22 | *** join/#qi-hardware panda|x201 (~hzhang@2001:5c0:1000:a::7e3) |
| 08:51.43 | vano | what would be the best sources.list for a debian squeeze sid on the nanonote? Anything should go in there apart from the stock sources.list that comes with the debian rootfs? |
| 08:52.53 | Ayla | I think the default one is fine |
| 08:56.10 | vano | I guest /binary-mipsel/Packages.gz 404 Not Found and similar messages |
| 08:56.27 | vano | also I cannot find things like fbterm with apt-get search fbterm... |
| 08:56.37 | vano | I think something might be off here |
| 08:59.08 | pabs3 | vano: which mirror are you using? |
| 08:59.23 | pabs3 | (pastebin your sources.list) |
| 09:01.12 | vano | http://pastebin.com/CABRq54t |
| 09:03.15 | pabs3 | looks like ftp.es doesn't have mipsel on it, you will want to choose a different mirror |
| 09:04.27 | lindi- | incomplete mirrors :( |
| 09:04.41 | pabs3 | check the mirror list for Spanish mirrors with mipsel on them: http://www.debian.org/mirror/list |
| 09:05.09 | pabs3 | lindi-: in this case, partially incomplete. they have the Contents files for mipsel, but no useful stuff like .debs/Packages :) |
| 09:07.55 | vano | k will check thanks! |
| 09:11.32 | Ayla | what the hell is fbterm? |
| 09:12.12 | pabs3 | http://packages.debian.org/sid/fbterm |
| 09:13.11 | Ayla | well, I did guess it was a terminal for the framebuffer |
| 09:13.38 | Ayla | but I don't get the point of that thing, |
| 09:13.48 | Ayla | the kernel already provide framebuffer consoles |
| 09:15.48 | viric | Ayla: it allows using TTF fonts |
| 09:15.59 | viric | Ayla: at the size you want. |
| 09:16.05 | viric | Ayla: I use it to get proper utf-8 support |
| 09:16.08 | Ayla | ah, ok |
| 09:35.47 | whitequark | farnell is impressive |
| 09:36.04 | whitequark | delivered from Britain to Russian in 24 (twenty four) hours |
| 09:36.11 | whitequark | for 20 EUR |
| 09:51.36 | whitequark | Ayla: have you managed to successfully play any music on NN? |
| 09:51.48 | whitequark | it fails to play 44.1k OGG file for me |
| 09:52.40 | viric | whitequark: did you ask a raspberrypi? |
| 09:52.53 | whitequark | viric: huh? |
| 09:53.05 | viric | (farnell was a distributor of it :) |
| 09:53.16 | whitequark | ah, no. a friend of mine ordered some components |
| 09:53.21 | whitequark | raspberry pi is broadcom |
| 09:53.21 | viric | whitequark: I can play any ogg in the nanonote |
| 09:53.44 | viric | what happens to your ogg? |
| 09:53.47 | whitequark | broadcom is nonfree enough for me to hate it, even through I'm not a fanatic like Stallman; it just doesn't work good with the closed drivers |
| 09:54.05 | whitequark | the playback is interrupted each several hundred ms and the cpu usage is topping to 100% |
| 09:54.22 | viric | whitequark: that can come from using a floating-point based player |
| 09:54.33 | viric | are you using int-based decoding? |
| 09:54.43 | whitequark | erm, I just typed "play file.ogg" |
| 09:54.49 | viric | 'play'? what is play? |
| 09:54.50 | whitequark | sox |
| 09:55.02 | viric | sox can play something other than wavs? I Didn't know |
| 09:55.05 | viric | I use mplayer. |
| 09:55.10 | whitequark | sox can play practically anything |
| 09:55.20 | whitequark | at least more than any other player around here |
| 09:55.36 | viric | so.. I'd bet sox tries to use floating point deocding |
| 09:55.46 | whitequark | yeah, mplayer works |
| 09:56.03 | viric | it's a matter of using the 'tremor' lib vs the 'libvorbis' lib. |
| 09:56.09 | viric | int vs fp |
| 09:57.10 | whitequark | huh, the sound is somewhat good both with headphones and the integrated speaker |
| 09:57.21 | whitequark | *with both |
| 09:58.15 | whitequark | does mpd work? |
| 10:00.56 | viric | I only have mplayer |
| 10:11.39 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 10:29.46 | Ayla | whitequark: I don't have a nanonote |
| 10:30.02 | Ayla | but 44.1k OGG should work just fine |
| 10:31.33 | Ayla | about the problem you're having, I had a similar behaviour when running a system installed on NAND |
| 10:32.13 | Ayla | and never when running from SD |
| 10:33.59 | *** join/#qi-hardware zear (~zear@h196n1-g-kt-a31.ias.bredband.telia.com) |
| 10:41.44 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 10:42.33 | viric | Ayla: do you know if there is a way I can have sysrq working on panic? |
| 10:42.50 | viric | so, on panic, leave some minimal code working... |
| 10:43.26 | viric | Ayla: solved your alarm clock? |
| 10:44.39 | Ayla | about sysrq, I don't know |
| 10:44.57 | Ayla | about my RTC alarm... not yet |
| 10:46.55 | *** join/#qi-hardware panda|x201 (~hzhang@2001:5c0:1000:a::b8f) |
| 11:14.07 | whitequark | viric: what's your problem? |
| 11:14.25 | larsc | Ayla: patch you kernel to log the application which changes the alarmtimer ;) |
| 11:15.16 | viric | whitequark: I like 'sysrq-B' :) |
| 11:17.19 | viric | larsc: How would you debug a latency problem between two userspace programs? |
| 11:17.34 | viric | larsc: I'm looking at enabling ftrace and getting scheduler statistics with perf |
| 11:18.22 | larsc | viric: depends on the problem i guess |
| 11:18.44 | viric | larsc: I have 'qemu' and 'smbd' communicating through a unix socket. 5% of cpu usage in the host... |
| 11:18.59 | viric | larsc: 95% idle (not waiting) |
| 11:19.31 | viric | 'strace' shows there is syscall activity... it's not somehting blocking for long (as name resolution could be, for example) |
| 11:20.58 | larsc | and you'd expect higher throughput? |
| 11:21.04 | viric | yes. |
| 11:21.10 | viric | a lot higher. |
| 11:21.54 | larsc | hm |
| 11:23.38 | larsc | have you tried iotop? |
| 11:25.06 | *** join/#qi-hardware wej (~j@m2.mullvad.net) |
| 11:26.11 | whitequark | viric: just pass a parameter |
| 11:26.19 | whitequark | something like reboot_on_panic=5 (not the real name) |
| 11:26.24 | viric | larsc: iotop will tell hd only , not? |
| 11:26.47 | viric | whitequark: hm ok. And launch kdb? |
| 11:27.20 | viric | whitequark: don't worry much... I can live without that :) I just wondered if it was possible |
| 11:27.37 | derRichard | viric: why do you think it's an latency problem? sounds more like one of the 2^10 io-related bugs in qemu... |
| 11:28.00 | viric | derRichard: could be! I tried kvm 0.15.1, kvm 1.0.0, ... |
| 11:28.11 | larsc | viric: so it is all mem-to-mem? |
| 11:28.21 | viric | larsc: it's a unix socket |
| 11:28.34 | derRichard | viric: so, it's qemu-kvm? and _not_ qemu? |
| 11:28.41 | viric | derRichard: right. |
| 11:29.08 | viric | derRichard: I checked, and kvm works much faster when there is not that samba activity... when it goes to the samba activity, qemu and qemu-kvm perform equally 'fast' |
| 11:29.09 | larsc | viric: yes, but you don't send random data, do you? I mean the data has to come from somewhere |
| 11:29.29 | viric | larsc: ah yes, but 'top' would show the cpu is in waiting state, not idle state |
| 11:29.55 | viric | (I have iotop running) |
| 11:30.06 | derRichard | is the feature you are using supported? qemu-kvm offers lots of features which are kinda broken. (that's why you shalt not call it without a wrapper like libvirt) |
| 11:30.33 | viric | larsc: 0% all in iotop... only super minimal transfers |
| 11:30.42 | larsc | hm |
| 11:31.04 | viric | I wanted to check latencytop, but I see their site is down. uch.- |
| 11:31.04 | viric | ouch. |
| 11:34.35 | *** join/#qi-hardware steve|m (~steve@osmocom/steve-m) |
| 11:35.59 | *** join/#qi-hardware vano (~vano@93.Red-79-149-164.dynamicIP.rima-tde.net) |
| 11:37.08 | *** join/#qi-hardware wej (~j@m2.mullvad.net) |
| 11:40.40 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 11:41.45 | whitequark | viric: if you want to launch kdb on panic, it's easier |
| 11:41.56 | whitequark | should be a matter of inserting one function into platform panic handler |
| 11:42.34 | whitequark | through you may need some UART magic if IRQ handling would be dead at that moment |
| 11:42.44 | whitequark | I've used kdb on jz47xx, through |
| 11:43.44 | steve|m | if someone is interested in SDR: http://sdr.osmocom.org/trac/wiki/rtl-sdr |
| 11:44.09 | derRichard | larsc: btw: so, there is no intent from your or qi-hardware's side to make dma work with ben's usb device controller, right? http://projects.qi-hardware.com/index.php/p/ben-nanonote/issues/59/ |
| 11:46.13 | viric | whitequark: clear |
| 11:58.08 | *** join/#qi-hardware pabspabspabs (~pabs@d122-109-116-184.per801.wa.optusnet.com.au) |
| 11:58.47 | larsc | derRichard: i guess not |
| 11:59.00 | derRichard | very sad |
| 11:59.53 | derRichard | do you have an idea why it's broken? ingenic claims that dma works... (at least in their bsp) |
| 12:01.57 | larsc | no, sorry |
| 12:09.15 | viric | derRichard: I even did not know of that issue. Sad, yes. |
| 12:11.56 | derRichard | viric: my dream is to use ben as external encrypted harddisk. e.g. put a luks-encrypted fs on an mmc, plug it into ben. then plug ben via usb to your pc. enter the passwort on ben and you see a harddisk on your pc :) |
| 12:12.28 | viric | ah clear |
| 12:14.07 | derRichard | but without udc dma this is not possible |
| 12:14.19 | viric | I thought the ben could only do usb1.1, and that's why it was slow |
| 12:14.33 | derRichard | yep |
| 12:15.35 | derRichard | usb on ben is slow because dma for usb seems broken (it's disabled by default) |
| 12:15.40 | viric | make the dma work :) |
| 12:15.59 | derRichard | i've spent already two days with hacking the driver |
| 12:22.37 | *** join/#qi-hardware wej (~j@m2.mullvad.net) |
| 12:22.59 | wolfspraul | derRichard: that's sounds like a great idea but afaik you are the pioneer then |
| 12:23.19 | wolfspraul | there may be issues in the chip that require workarounds, or make it entirely impossible. hard to say. |
| 12:26.33 | derRichard | wolfspraul: yeah, maybe. the soc is able to use dma and the driver too. but on ben it does not work (i see corrupted usb packets). maybe it's only a pinmux issue. who knows... |
| 12:27.18 | wolfspraul | I can tell you honestly that the Ben NanoNote is most likely my last Ingenic-based device. All future devices from me will be Milkymist SoC based :-) |
| 12:28.07 | wolfspraul | I'll keep the discussions with Ingenic open, but I think I moved on. |
| 12:28.44 | wolfspraul | of course that still means we want to make the Ben kernel well maintainable, fix bugs or even improve something as you try to do :-) |
| 12:29.06 | wolfspraul | I could torture Ingenic a little by going back asking about 4720 related bugs :-) |
| 12:29.32 | whitequark | no MIPS abomination anymore. definitely a good thing. |
| 12:30.57 | wolfspraul | oh there will be 100 times more bugs and issues in Milkymist SoC for sure |
| 12:31.07 | derRichard | i'm currently working a lot with mpc5125 socs from freescale |
| 12:31.13 | wolfspraul | but I feel better about it, especially when tracking down bugs and strange behavior |
| 12:31.26 | wolfspraul | derRichard: nice. and what's your experience? |
| 12:31.54 | derRichard | their bsp are horrible. but the device itself is nice. |
| 12:32.32 | derRichard | fortunately a lot is already mainline |
| 12:32.39 | wolfspraul | derRichard: are you following Milkymist SoC a little? |
| 12:32.52 | wolfspraul | it'll be a long path, but eventually should be really cool |
| 12:32.59 | derRichard | not really |
| 12:33.09 | wolfspraul | yes maybe too exotic right now :-) |
| 12:33.20 | wolfspraul | what kind of device do you build with the mpc5125 ? |
| 12:41.39 | whitequark | wolfspraul: bugs are fine. MIPS is broken by design |
| 12:42.04 | whitequark | well, you could expect brokenness from a design which was developed at an university as a teaching example or something |
| 12:42.27 | whitequark | I'm all for LM32. |
| 12:44.46 | wolfspraul | well, let's use it more and more then we know :-) |
| 12:48.22 | viric | what is a bsp? |
| 12:48.32 | derRichard | board support package |
| 12:48.48 | derRichard | IOW the driver to make the hardware work |
| 12:48.54 | viric | ah ok |
| 12:49.25 | wolfspraul | industry lingo for a tarball (or even zip) with a kernel tree to 'make a board work' |
| 12:49.36 | viric | :) |
| 12:49.43 | wolfspraul | often with large amounts of code in never-upstreamable quality |
| 12:49.47 | derRichard | yeah. and most bsps are really crappy. |
| 12:49.50 | wolfspraul | often with lots of bugs |
| 12:50.18 | wolfspraul | often mostly meant so managers can put their engineers under pressure to make things work "but we got the software for it, didn't we?" |
| 12:50.25 | derRichard | full with hardcoded addresses, #if 0, //TODO and stuff :D |
| 12:50.47 | wolfspraul | to be fair to the other side, the time and resource pressure is so intense that better qualities bsps are just impossible, imho |
| 12:51.09 | wolfspraul | that would only be possible if the industry changes their innovation and tech-race cycles upside down |
| 12:51.28 | wolfspraul | which is what crazy ideas like Qi are for, but you cannot do that at an existing company that has to meet quarterly targets, or else... |
| 13:20.54 | *** join/#qi-hardware infobot (~infobot@rikers.org) |
| 13:20.54 | *** topic/#qi-hardware is Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs |
| 13:20.54 | *** mode/#qi-hardware [+v infobot] by ChanServ |
| 13:22.35 | viric | and there use to be volunteers that will improve that bsp :) |
| 13:23.23 | derRichard | this is a lot of work |
| 13:23.27 | wolfspraul | that's very difficult because of the stream of things, I like the Linaro model |
| 13:23.34 | derRichard | basically it's my $DAYJOB |
| 13:59.44 | whitequark | wolfspraul: what does Linaro do? |
| 14:00.09 | whitequark | hm. they have Ubuntu font on the homepage. |
| 14:01.24 | derRichard | wolfspraul: http://www.linaro.org/about/ |
| 14:01.34 | derRichard | ups, i meant whitequark |
| 14:06.58 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 14:11.34 | *** join/#qi-hardware rejon (~rejon@118.143.62.3) |
| 14:14.16 | kristianpaul | steve|m: i do :) |
| 14:28.14 | kristianpaul | steve|m: tought will be could connect it to a ben nanonote .. |
| 14:28.30 | *** join/#qi-hardware wolfspraul (~wolfsprau@222.130.125.213) |
| 14:28.37 | kristianpaul | looks at zrafa for the bit-bang usb host implementation |
| 14:30.05 | steve|m | kristianpaul: that'll be hard, given that you need some 'serious' throughput ;) |
| 14:30.33 | kristianpaul | ;-) |
| 14:31.13 | kristianpaul | see, now he will not look at it again ! :) |
| 14:34.11 | kristianpaul | perhaps one of those MR11U.. plus a nanonote, then a portable and over eng sdr solution :-/ |
| 15:22.21 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 15:26.59 | zrafa | wpwrak: usb project? |
| 15:27.17 | zrafa | wpwrak: if so then no well. I need a big hand to start as I asked several months ago |
| 15:27.54 | zrafa | wpwrak: after somebody can help me with to get 0-1 and 1-0 via mmc maybe I will be albe to continue with software side |
| 15:28.13 | zrafa | wpwrak: I can not do that |
| 15:28.44 | zrafa | wpwrak: sorry, no enough knowledge and hw knowledge to test (like how to use the scope, or how to get a good scope, etc). |
| 15:30.10 | wpwrak | zrafa: hmm. maybe write a bit of code that bit-bangs the UBB ? then you can watch it with the scope |
| 15:30.32 | wpwrak | zrafa: you can find code that does such things in ben-blinkenlights |
| 15:30.42 | zrafa | wpwrak: no enough hw knowledge should be here at qi chat children games |
| 15:30.54 | zrafa | wpwrak: you already said me that around 20 times :) |
| 15:31.02 | wpwrak | it's simple ;-) |
| 15:31.07 | zrafa | wpwrak: I can not do that :) and I do not how nothing with scope |
| 15:31.16 | wpwrak | fine. use a voltmeter :) |
| 15:31.19 | zrafa | wpwrak: yes.. I nkow it is simple here at qi hw chat :) |
| 15:31.30 | zrafa | wpwrak: that is why maybe I am not here a lot of time :P |
| 15:32.01 | zrafa | wpwrak: I learnt to turn on/off scope. That is something at leas |
| 15:32.03 | zrafa | t |
| 15:32.09 | wpwrak | here is some code that does what you need: http://projects.qi-hardware.com/index.php/p/ben-blinkenlights/source/tree/master/bbl/bbl.c |
| 15:32.23 | zrafa | wpwrak: I modified that code several times |
| 15:32.32 | zrafa | wpwrak: and I saw something via ubb with scope |
| 15:32.40 | wpwrak | good ! :) |
| 15:32.42 | zrafa | wpwrak: but I do not know what is next |
| 15:32.51 | wpwrak | do you see a stable signal ? |
| 15:32.54 | zrafa | because I do not know how to use the scope |
| 15:33.12 | wpwrak | yes. so you'd use this simple program to play with the scope. until you're more confident with it |
| 15:33.25 | zrafa | I can do the easy part (via direct I/O ubb without mmc command)= |
| 15:33.35 | zrafa | and I have seen the 1010101 at scope |
| 15:33.43 | zrafa | but I can not do the same with mmc command |
| 15:33.59 | zrafa | the program is not the problem |
| 15:34.00 | wpwrak | okay, that's a start. so you already do know how to use the scope :) |
| 15:34.15 | zrafa | I feel like a blind without to know what to touch on scope |
| 15:34.37 | zrafa | because I ddid not get the same with mmc command |
| 15:34.53 | wpwrak | is the 0101 pattern stable on the scope ? or does it jump around ? i.e., is your trigger set properly ? (at least the edge at the trigger point should never move. the others may) |
| 15:55.57 | *** join/#qi-hardware dptech (~dptech@can06-1-82-242-223-39.fbx.proxad.net) |
| 15:57.18 | *** join/#qi-hardware dptech (~dptech@can06-1-82-242-223-39.fbx.proxad.net) |
| 16:12.20 | *** join/#qi-hardware kilae_ (~chatzilla@catv-161-018.tbwil.ch) |
| 16:13.53 | *** join/#qi-hardware wolfspraul (~wolfsprau@221.220.182.253) |
| 16:19.54 | qi-bot | [commit] Werner Almesberger: cameo: an attempt at area fill (WIP) (master) http://qi-hw.com/p/cae-tools/2530a11 |
| 16:19.55 | qi-bot | [commit] Werner Almesberger: cameo/test/: test scenario for area fill (master) http://qi-hw.com/p/cae-tools/8c4dfc5 |
| 16:24.36 | qi-bot | [commit] Werner Almesberger: b2: BOOM rewrite (WIP) (master) http://qi-hw.com/p/eda-tools/aa2fe3e |
| 16:51.56 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 16:55.15 | *** join/#qi-hardware GNUtoo (~gnutoo@smb-rcdg1-01.wifihubtelecom.net) |
| 16:56.15 | whitequark | wow, bitbanging usb host |
| 16:56.33 | whitequark | given that there is even no working USB 2.0 FOSS softcore... |
| 16:59.53 | wpwrak | V-USB doesn't count ? |
| 17:03.08 | Ayla | whitequark: where? |
| 17:03.33 | Ayla | reads the log |
| 17:08.04 | whitequark | wpwrak: V-USB isn't USB host |
| 17:08.18 | whitequark | ... and we're already talked about it like half a year ago :) |
| 17:17.34 | *** join/#qi-hardware dptech (~dptech@can06-1-82-242-223-39.fbx.proxad.net) |
| 17:37.23 | zrafa | wpwrak: the 0101 is stable, but I have seen it just with direct I/O in bbl.c If I try a mmc command I never gets nothing. |
| 17:37.52 | zrafa | wpwrak: well, no nothing. Something is there. But I have not able to stop the command at some moment to have the required 0101 pattern |
| 17:38.06 | zrafa | wpwrak: and Ihave tried to stop it (the clock for example) |
| 17:38.30 | zrafa | wpwrak: what I can not do is to manage the scope to see something from my mmc commands signals |
| 17:39.02 | zrafa | wpwrak: so I am stuck at the same situation like one year ago at your place when you gaveme some ubb to play :P |
| 17:41.11 | zrafa | wpwrak: sorry for the ignorance about the topic. Simply I gave you the real situation because you asked |
| 17:41.14 | zrafa | :) |
| 17:41.28 | qi-bot | The build has FAILED: http://fidelio.qi-hardware.com/~xiangfu/building/Nanonote/Ben/openwrt-xburst.minimal-20120317-1814 |
| 18:07.40 | *** join/#qi-hardware bitkiller (~bitkiller@201.22.42.233.dynamic.adsl.gvt.net.br) |
| 18:15.30 | *** join/#qi-hardware |dptech| (~dptech@can06-1-82-242-223-39.fbx.proxad.net) |
| 18:26.48 | wpwrak | zrafa: hmm yes, one problem with your scope is that it's not a storage scope. so you only see the signal flash by briefly |
| 18:27.23 | wpwrak | zrafa: of course, for a contemporary of Neuquensaurus it's still a pretty impressive device ... |
| 18:47.36 | *** join/#qi-hardware panda|x201 (~hzhang@123.116.123.213) |
| 19:13.19 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 19:29.45 | kristianpaul | after rtl-sdr we need a cheap device for the DAC part too :) |
| 19:46.43 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 20:04.09 | *** join/#qi-hardware kuribas (~user@d54C43316.access.telenet.be) |
| 21:10.38 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 22:17.43 | whitequark | DocScrutinizer: can you explain how MIMO works? |
| 22:18.24 | whitequark | I thought it just used twice the bandwidth, but Wikipedia states that it "enhances spectral efficiency by spreading same transmit power over the antennas to achieve an array gain" |
| 22:19.33 | DocScrutinizer | what's MIMO? |
| 22:19.39 | *** join/#qi-hardware wej (~j@m2.mullvad.net) |
| 22:19.40 | DocScrutinizer | antenna technology? |
| 22:19.57 | whitequark | yeah |
| 22:20.19 | whitequark | I remember you're working on LTE modules and so you may know |
| 22:20.25 | DocScrutinizer | it's simple: you use different antennae to create paths with different properties between receiver and transmitter |
| 22:20.54 | whitequark | hm, what properties? |
| 22:21.14 | DocScrutinizer | properties like frequency response etc |
| 22:22.04 | whitequark | ok. I have a router which claims to be 3x3 MIMO. it has three identical antennas placed with a spacing of ~5cm between each other |
| 22:22.06 | DocScrutinizer | or you could think of it like the multiple antennae forming an active directional antenna with multiple more or less independents paths between the 2 stations |
| 22:23.09 | DocScrutinizer | with an antenna array you can simulate a directional antenna - planar sat antenna is working that way |
| 22:23.35 | DocScrutinizer | in RADAR such arrays are used instead of rotatinf dishes |
| 22:24.12 | whitequark | interesting |
| 22:24.41 | DocScrutinizer | you basically have a signal processor of some kind from TX output to each antenna element |
| 22:25.33 | DocScrutinizer | when all processors are just "wires" you get a directional antenna array that faces right ahead of the plane |
| 22:25.56 | whitequark | so, does my router split its whole TX power in three parts and deliver these parts to the antennae in such a way so they effectively direct a "beam" towards a STA? |
| 22:26.15 | DocScrutinizer | when you delay each antenna element some degrees phase from the one left of it, you get a direction to the right |
| 22:26.24 | whitequark | but how does it determine the location of STA? by measuring some properties of the received signal? |
| 22:26.46 | DocScrutinizer | whitequark: yes, just not only one beam, but ideally more |
| 22:27.33 | whitequark | how could one make more? splitting antennae in groups? |
| 22:27.35 | whitequark | *by splitting |
| 22:27.41 | DocScrutinizer | I guess it analyzes the RX signal to find paths the "waves" used to reach it |
| 22:28.01 | DocScrutinizer | with 3 elements I guess you can use 2 paths |
| 22:28.15 | DocScrutinizer | though, not sure about that |
| 22:28.47 | DocScrutinizer | nah, probably it's not limited in any way on number of paths, just the separation gets better and better between them with more elements |
| 22:29.20 | whitequark | hm. I have some cards that are "normal" (i.e. one antenna and tx/rx), and some other ones which are presumably 2x2 MIMO |
| 22:29.58 | DocScrutinizer | yep, some LTE classes specify 2*2 MIMO as mandatory to achieve the bandwidth |
| 22:30.35 | whitequark | yes, bandwidth increases substantially when I use the MIMO cards. at least I think it increases because I took some measurements and they were better with MIMO ones |
| 22:30.58 | whitequark | may very well be e.g. poor RF frontend on the non-MIMO card or some weird incompatibility or whatever |
| 22:31.17 | DocScrutinizer | it's the expected effect of MIMO |
| 22:31.33 | DocScrutinizer | you're adding info to the media channel |
| 22:32.12 | whitequark | oh. this is the part I don't understand. how could I add more info by using more antennas if I transmit my data over the same chunk of spectrum? |
| 22:33.47 | DocScrutinizer | I've never completely wrapped my head around it, but it's kinda like old 56k POTS modems used that adaptive phase to analyze the landline properties, then agreed on a set of symbols and thus transmitted more than what you originally thought was possible bandwidth with 4800Hz signal |
| 22:34.38 | DocScrutinizer | the symbol/signal arriving at RX is different for TX using antenna element A than wehn TX uses element B |
| 22:35.26 | DocScrutinizer | RX distinguishes them with the different signals on its own antenna array, though it's always same freq |
| 22:35.52 | whitequark | I think that 56k modems just checked if the line can actually handle bandwidth they required and if yes, used the different modulation parameters |
| 22:35.57 | whitequark | but here, medium is the same, isn't it? |
| 22:38.24 | DocScrutinizer | think about somebody shouting info words to you. He may shout "zero" and "one" and you hear the difference. He also may shout "zero" in your direction and also shout "zero" in a direction that reaches you via some echo. You still can distinguish two distinct info bits though he only shouted "zero, zero, zero, zero" |
| 22:39.11 | DocScrutinizer | as you hear the difference between him shouting in your direction and him shouting direction echoing wall |
| 22:39.51 | DocScrutinizer | I'm not sure I'm that good in making up analogies and examples. Hope you were able to follow |
| 22:42.45 | whitequark | hm |
| 22:44.01 | whitequark | so MIMO requires support from both the AP and STA (in case of the WiFi) |
| 22:45.17 | DocScrutinizer | not necessarily, as the different pathes have different properties, which help distinguishing the direction the shouter shouted, even when you listen with a mono microphone |
| 22:45.36 | DocScrutinizer | but of course MIMO setup on both ends help a lot |
| 22:46.37 | DocScrutinizer | in some weird way you can even reverse the whole setup and TX uses only one antenna but signals that match the path properties |
| 22:46.54 | whitequark | so, do you just randomly place antennas in the space (well, because the placement of router itself is random) and hope that you could distinguish between these signals because they happen to travel different paths? |
| 22:47.03 | DocScrutinizer | while RX uses MIMO to distinguish the paths used |
| 22:47.25 | DocScrutinizer | yes, basically that's what's happening |
| 22:48.45 | whitequark | it's weird that this actually works works |
| 22:49.02 | DocScrutinizer | yeah, DSP is a fun topic |
| 22:49.11 | DocScrutinizer | s/D// |
| 22:49.11 | qi-bot | DocScrutinizer meant: "yeah, SP is a fun topic" |
| 22:50.18 | DocScrutinizer | frequently beyond my mind |
| 22:50.44 | DocScrutinizer | I can understand the theory, but practice is all obscure to me |
| 22:51.05 | DocScrutinizer | practice as in "algo used to do MIMO" |
| 22:51.50 | DocScrutinizer | I'm probably too less of a mathematician for that |
| 22:52.18 | *** join/#qi-hardware urandom__ (~user@p548A46C2.dip.t-dialin.net) |
| 22:52.32 | DocScrutinizer | I always need to be able to figure things, juggling with 7-dimensional stuff etc is beyond my mind |
| 22:54.21 | DocScrutinizer | the dudes developing those algos are pure theoretics, they don't figure what their formulae mean in RL, they just solve them, implement them and it magically works |
| 22:54.59 | whitequark | seven dimensions?! O_o |
| 22:55.31 | whitequark | as per the formulaes and RL, yes, I have the same feeling. it's pure magic |
| 22:56.10 | DocScrutinizer | for example they might just run thru all possible symbols (= antenna element DSP settings * TX signal codings) and see what they can distinguish on other end, then agree on that set |
| 22:57.41 | DocScrutinizer | or they send some white noise, consider that as a mix of all possible symbols at same time, and on RX side see how they can dissect it into a proper symbol set |
| 22:58.10 | DocScrutinizer | then agree on that set with TX side |
| 22:58.33 | DocScrutinizer | honestly I have no real clue |
| 23:00.23 | whitequark | sigh. thanks anyway |
| 23:09.28 | *** join/#qi-hardware Ornotermes (~rikard@78-69-248-123-no180.tbcn.telia.com) |
| 23:10.44 | DocScrutinizer | http://en.wikipedia.org/wiki/Mimo#Principle |
| 23:16.22 | DocScrutinizer | after all my simplified examples above you actually might guess what all the terms in this wiki article mean |
| 23:16.54 | DocScrutinizer | esp in http://en.wikipedia.org/wiki/Mimo#Functions_of_MIMO |
| 23:19.40 | DocScrutinizer | LOL @ http://en.wikipedia.org/wiki/Mimo#Mathematical_description |
| 23:20.12 | DocScrutinizer | however that's exactly how this stuff is developed and put into silicon |
| 23:20.38 | wpwrak | (math) kinda obvious, eh ? (-:C |
| 23:26.30 | whitequark | (math) *emergency brain shutdown* |
| 23:33.01 | wpwrak | whitequark: you're russian. you're supposed to solve such equations in your head :) |
| 23:46.05 | *** join/#qi-hardware GeorgeH (~George@c-69-141-105-145.hsd1.nj.comcast.net) |
| 23:49.56 | roh | DocScrutinizer: actually i wonder why they do not just write 'poor mans phased array' |
| 23:50.03 | roh | would be much easier to understand |
| 23:50.10 | DocScrutinizer | indeed |
| 23:52.11 | roh | well.. its something in between. not really phased array, but more to the diversity direction |
| 23:54.29 | roh | bbl -> off to the lab |
