wolfspraul | lekernel: the vishay infrared receiver we use is for 38kHz carrier frequency, but Wikipedia RC-5 seems to indicate that it should actually be 36 kHz? | 05:04 |
---|---|---|
wolfspraul | will this still work? Wikipedia is a little unclear there, it says "The command data is a Manchester coded bitstream modulating a 36 kHz carrier. (Often the carrier used is 38 kHz or 40 kHz, apparently due to misinformation about the actual protocol.)" | 05:05 |
wolfspraul | so any of those 3 will work? If the remote control sends with a 36 khz carrier, can our receiver with a 38khz carrier still pick it up? | 05:05 |
larsc | i think the carrier wave mostly only matters for the IR-filter | 05:07 |
wolfspraul | don't understand | 05:09 |
wolfspraul | the receiver is available in different part numbers, 30, 33, 36, 38, 40 and 56 khz | 05:09 |
wolfspraul | why that? what does it mean if you have the 'wrong one'? | 05:10 |
larsc | the signal won't go through the filter i guess | 05:10 |
wolfspraul | so if the remote control uses a 38 khz carrier, and the receiver is a 36 khz type (part number), will it receive or not? | 05:12 |
wolfspraul | sorry same question as before :-) | 05:12 |
wolfspraul | what if the distance is bigger, say a control sending on a 56khz carrier, and the receiver being a 30 khz part number? | 05:13 |
larsc | maybe ;) | 05:13 |
larsc | it all depends on how narrow the filter is. if you wnat to be sure, use the 38khz receiver | 05:19 |
wolfspraul | we use a 38khz receiver right now | 05:21 |
wolfspraul | oh you mean because it is in the middle from 36 to 40? | 05:21 |
wolfspraul | so our vishay part with 38 khz part number will be able to receive correct codes from remote controls sending on a 36, 38 or 40 khz carrier? | 05:21 |
larsc | depends on how narrow the filter is. take a look at the datasheet | 05:23 |
wolfspraul | datasheet only says "should be close to the band-pass center frequency", cannot find more details | 05:29 |
wolfspraul | http://www.vishay.com/docs/81732/tsop348.pdf | 05:29 |
wolfspraul | not sure whether 2khz distance is 'close' or not :-) | 05:30 |
wolfspraul | it's probably obvious, but not to me... | 05:31 |
roh | hm. i think it will work even if its off a bit | 05:33 |
wolfspraul | yes but what is 'a bit'? | 05:33 |
roh | Fig.5 | 05:33 |
wolfspraul | wikipedia seems to say rc-5 is often found on 36, 38 or 40 khz. ok, I got that. | 05:33 |
roh | there is a bandpass curve for f+-5% | 05:33 |
wolfspraul | now, our vishay part is of 38 khz type. did we choose that because it's in the middle of 36-40? | 05:34 |
roh | dunno | 05:34 |
roh | but i guess it will work best with 38, and maybe with a few percent less range also with 36 and 40khz ones | 05:35 |
roh | atleast thats what that graph tells me | 05:35 |
roh | f=f0 +-5% | 05:36 |
roh | delta f(3dB)=f0/10 | 05:37 |
roh | its half as sensitive at 3.8khz up and down | 05:38 |
wolfspraul | hmm | 05:40 |
roh | means at 36khz (2 khz down, 5% f0 off down) its something like 0.6 to 0.8 times as sensitive as on 38khz | 05:40 |
wolfspraul | ok | 05:40 |
wolfspraul | that doesn't explain why we see so many different/random values then, when doing controlled tests with the sending remote control essentially directly in front of the receiver | 05:40 |
roh | it works less well, but maybe one only notices when using it on long distance | 05:40 |
wolfspraul | so maybe we did choose 38 to be in the middle of 36-40 | 05:41 |
wolfspraul | although you could also make the same argument about 36 being more in the middle of 30-40 (since 30 and 33 exist as well) | 05:41 |
wolfspraul | but then, it looks like sensitivity goes down quite a lot, even with 5% off | 05:42 |
roh | yes. | 05:42 |
wolfspraul | I'm trying to find the root cause of the 'different values' problem me, Adam and Xiangfu have, but can't be related to carrier frequency then, it looks like | 05:44 |
Action: larsc needs coffee... | 05:44 | |
larsc | ha! coffee! | 06:08 |
wolfspraul | roh: is it possible that the infrared goes through the wood case you made once? | 06:19 |
wolfspraul | I was just trying that and even when I hold the control immediately in front of the wood (so the light cannot go anywhere else but through it), I do receive a value (albeit wrong, as always) | 06:20 |
lekernel | have you looked at the waveform from a DSO or logic analyzer?!?? | 06:25 |
lekernel | btw: https://github.com/milkymist/llvm-lm32 | 06:26 |
wolfspraul | lekernel: aw will be looking at it, I think | 06:29 |
wolfspraul | and xiangfu will improve the test in tests_ir.c to be more strict and log more | 06:29 |
lekernel | ok but please do not delay the rc3 because of this minor problem... | 06:29 |
lekernel | capturing that waveform should take less than 5 minutes | 06:30 |
wolfspraul | well we need to be able to test whether ir works | 06:31 |
wolfspraul | yes I agree, most likely all is good, but we (not you, me/Adam/Xiangfu) have fooled ourselves a little the last months | 06:31 |
wolfspraul | we clean that up now :-) | 06:31 |
wolfspraul | it also turns out that Adam had to press standby 'multiple times' to get it to pass in December, in the rc2 run | 06:31 |
wolfspraul | that's all wrong, even if we assume/know that the underlying stuff is ok | 06:31 |
wolfspraul | otherwise why test at all... | 06:31 |
wolfspraul | lekernel: is that correct that we chose a 38 khz carrier frequency receiver because it is in the middle of 36-40? | 06:32 |
wolfspraul | or because for some reason we specifically wanted 38? | 06:33 |
lekernel | according to the lirc website most remotes are 38, furthermore the receiver has some tolerance as roh said | 06:33 |
wolfspraul | which control are you using? | 06:35 |
wolfspraul | do you know whether you control uses 38 khz? | 06:35 |
lekernel | some philips one | 06:38 |
lekernel | no | 06:38 |
lekernel | I don't know | 06:38 |
lekernel | why don't you have a look at that waveform? it's going to help a lot more than those time sinking wild guesses | 06:38 |
wolfspraul | I have no scope or logic analyzer, and wouldn't even know how to use one if I had. Adam will do that. | 06:39 |
wolfspraul | yes it sounds like 38 is good, it's all written up here (from lirc data as you said) http://en.wikipedia.org/wiki/Consumer_IR#Technical_information | 06:39 |
xiangfu | wolfspraul: lekernel http://dpaste.com/551388/ | 06:42 |
aw | lekernel, xiangfu http://downloads.qi-hardware.com/people/adam/m1/pic/button1_0x0c.JPG | 06:42 |
xiangfu | the tests_ir patch | 06:42 |
aw | this is the one gui shows "0x0c" and i probed it. | 06:43 |
lekernel | for first it seems that the signal is clean, so there is little doubt the decoder works at the remote's frequency | 06:43 |
aw | yes, very much clean on signal level | 06:44 |
lekernel | then have a look at http://users.telenet.be/davshomepage/rc5.htm | 06:44 |
aw | um...good stuff my toggle bit is strange...checking that protocol... | 06:45 |
xiangfu | I bought another controller. it do give only one value when press one button. but the value is not correct. | 06:46 |
xiangfu | (the two phillips brand remote controller is on the way to me) | 06:47 |
aw | lekernel, my button 1 is the same as that one in web page. i need to probe more. I don't see what else is wrong from tsop34838's output. | 06:49 |
wolfspraul | xiangfu: i<sizeof(rc5_code), can remove while(1) and break I think, can return TEST_STATUS_FAILED right away since you also return a few lines higher. | 06:49 |
wolfspraul | why do we do rx&0x3F? Is that needed? are some of the high bits on/different? there is one bit that toggles but we mask out a whole bunch of them, don't know why | 06:50 |
wolfspraul | we are not trying to 'find/extract' the right value, we are trying to test the transmission :-) | 06:51 |
xiangfu | http://dpaste.com/551392/ | 06:51 |
lekernel | if the fpga receives a correct rc5 signal but does not decodes it correctly, then the fpga design is buggy | 06:52 |
lekernel | period | 06:52 |
aw | hmm..the toggle bit is correct from read it without doubting. :-) | 06:53 |
wolfspraul | xiangfu: ah wait, sizeof is not correct :-) just write 5, it's easier... | 06:53 |
aw | checking for others buttons though. :-) | 06:53 |
lekernel | sizeof(rc5_code)/sizeof(rc5_code[0]) | 06:54 |
xiangfu | oh. yes. some define arraysize.. should be ok. let's just use 5, | 06:54 |
lekernel | use sizeof(rc5_code)/sizeof(rc5_code[0]) | 06:54 |
wolfspraul | I don't see the return PASSED now, but anyway, looks better now | 06:55 |
wolfspraul | we will not be able to fool ourselves with this test :-) | 06:55 |
wolfspraul | check whether we need the &0x3F | 06:55 |
wolfspraul | I would like to only mask out bits that we know can differ, like the toggle bit | 06:55 |
wolfspraul | this is a test routine, it's supposed to catch suspicious stuff | 06:56 |
xiangfu | http://dpaste.com/551393/ | 06:57 |
lekernel | xiangfu, as wolfgang said, the return "passed" is missing | 06:58 |
wolfspraul | yes, good. except for 3F, but let's see what values you get | 06:58 |
wolfspraul | now you can try to run this and see whether you can make it pass :-) | 06:59 |
wolfspraul | so you say you bought a universal remote now and at least it gives unique (and always the same) values for each key? | 06:59 |
xiangfu | lekernel: http://dpaste.com/551393/ line 38 | 07:00 |
xiangfu | wolfspraul: yes. | 07:00 |
xiangfu | but the value is not correct. VolumeUp is 0x1E, not 0x10 | 07:01 |
lekernel | ok, we got that | 07:01 |
wolfspraul | xiangfu: ok but that's a start | 07:02 |
wolfspraul | there's a huge difference between 'sometimes not working', or 'different values', and 'the values do not correspond to the rc-5 standard' | 07:02 |
xiangfu | :) | 07:02 |
wolfspraul | so it's unique now, and every time you press you reliably get that same number? | 07:03 |
wolfspraul | just asking again so we are clear :-) | 07:03 |
wolfspraul | you can press 20 times, it should reliably give you the same number 20 times | 07:04 |
xiangfu | wolfspraul: yes. | 07:04 |
aw | hmm...my ir transmitter transmits different codes, see another probed code i got on button 1. http://downloads.qi-hardware.com/people/adam/m1/pic/button1_0x1c.JPG | 07:04 |
xiangfu | I got reliably value when press same button | 07:04 |
xiangfu | wolfspraul: (20 times) yes. | 07:05 |
aw | so now the problems is that our ir transmitter is not sending correct one since second start bit is wrong | 07:06 |
wolfspraul | second start bit is a toggle bit I think | 07:08 |
aw | xiangfu, but how do you know that your remoter is rc5 format? since if used my other not rc5 remoter, the gui still can detect with the same value. | 07:08 |
wolfspraul | to tell the difference between two button presses versus someone walking through the signal | 07:08 |
aw | wolfspraul, NO, start bit have two bits with "1" | 07:09 |
aw | so this is surely my remoter is not sending a good code when i press the same button "1" key | 07:09 |
xiangfu | "transmitter" what is that? one component on m1 pcb? the TSOP34838? | 07:10 |
aw | xiangfu, sorry, i said transmitter is your remoter. :-) | 07:10 |
xiangfu | aw: I don't know that. I just configure it as phillips remote controller. it's a universal controller, very cheap. | 07:11 |
xiangfu | aw: transmitter ok. get it. | 07:11 |
xiangfu | back online in 10 Mins | 07:11 |
aw | xiangfu, hmm..got it. | 07:12 |
aw | wolfspraul, i think now the results is clear? test s/w is strictly more and he has a universal controller, so i need to get the same as phillips remoter controller. | 07:13 |
aw | xiangfu, pls take picture of your universal remoter so that i can find if it exists here i can buy. | 07:37 |
xiangfu | aw:hmm.. I think let's wait the 'phillips branch remote controller' in next two days. | 07:38 |
xiangfu | aw: I just bought them at small shop, you know in China. it's only 10RMB. | 07:38 |
xiangfu | I mean I just bought this one at small shop. | 07:39 |
aw | hmm..okay..bad asia not just China. :-) | 07:39 |
aw | okay..let's stick on a real philips remote controller. | 07:39 |
xiangfu | I meet another problem. I get different value in Flicernoise and Test image. | 07:48 |
aw | xiangfu, hup? what's difference in flickernoise when you press the same button 1? | 07:49 |
aw | xiangfu, what value the gui read for button 1? 0x0c? 0x1c? | 07:50 |
xiangfu | I test with button 'standy/power' | 07:50 |
xiangfu | the flickernoise give me 0x26 | 07:50 |
xiangfu | the test image give me : http://pastebin.com/T58QBQkR, it like totally random. | 07:51 |
aw | xiangfu, before you used the new bin image, your flickernoise reads all good? | 07:54 |
xiangfu | aw:I guess the IR code in test is not as good as in flicerknoise. | 08:00 |
aw | xiangfu, but you used universal remoter to test 20 times and always got the same value, didn't you? by flickernoise? | 08:08 |
xiangfu | yes. | 08:08 |
wolfspraul | xiangfu: "ir code in test not as good as flickernoise"? | 08:33 |
xiangfu | wolfspraul: the test image give me : http://pastebin.com/T58QBQkR, it like random | 08:46 |
xiangfu | 1. I change the rc5_code to {0x26, 0x3c, 0x38, 0x34, 0x1e}; | 08:47 |
xiangfu | (I got those values in flickernoise with my cheap universal controller) | 08:48 |
xiangfu | 2. boot to test image. then it give me http://pastebin.com/T58QBQkR, | 08:48 |
xiangfu | (anyway I still not sure this controller is RC5.), | 08:49 |
wolfspraul | xiangfu: why does the test image give you values that are different from the ones you see in flickernoise? | 08:51 |
xiangfu | wolfspraul: I am not sure. the test image not link to rtems. so maybe there is some different. | 08:59 |
Action: lekernel just compiled the first milkymist c source file with llvm | 09:08 | |
Fallenou | \o/ | 09:09 |
lekernel | clang -ccc-host-triple mico32-generic-generic -o blah -c memstats.c -I../include/base -I../include -ccc-gcc-name lm32-rtems4.11-gcc | 09:13 |
lekernel | now trying the integrated assembler... | 09:13 |
xiangfu | wolfspraul: ok. the values is same(value & 0x003f), check here http://pastebin.com/xTDzvxkW, the first colume is and 0x003f, the second colume is without 0x003f | 09:17 |
xiangfu | wolfspraul: but there is another problem. you have to press the button very fast then you can get only one time value. | 09:18 |
xiangfu | wolfspraul: I will change code that handle the repeat values. | 09:18 |
aw | xiangfu | 10:14 |
aw | i finally realized that toggle bit | 10:14 |
aw | 1 toggle bit (change everytime when a new button is pressed on the ir transmitter) | 10:16 |
wolfspraul | yes. that's a bit we need to mask out when comparing against the value we expect for a particular button. | 10:17 |
aw | yes so xiangfu needs to mask it when repeating code coming. | 10:18 |
wolfspraul | aw: I'm looking at the two scope pics you uploaded earlier | 10:30 |
wolfspraul | http://downloads.qi-hardware.com/people/adam/m1/pic/button1_0x0c.JPG | 10:30 |
wolfspraul | http://downloads.qi-hardware.com/people/adam/m1/pic/button1_0x1c.JPG | 10:31 |
wolfspraul | I don't get it | 10:31 |
wolfspraul | the 0x0c one looks like 111000000000011 to me | 10:31 |
wolfspraul | the 0x1c one looks like 110000000000011, so no difference other than the toggle bit | 10:32 |
wolfspraul | the 11 at the end should come out as 0x03, neither 0x0c nor 0x1c | 10:32 |
wolfspraul | so obviously I misunderstand something :-) | 10:32 |
wolfspraul | am I misreading the scope output? | 10:33 |
aw | it's 11111111111101 | 10:33 |
wolfspraul | which one is that? 0c or 1c? | 10:34 |
aw | please forget about the first two bits on those two waveforms, the remaining rightest bits is all the same **111111111101 | 10:40 |
aw | i need to probe in a suitable time slot again. | 10:40 |
wolfspraul | well OK, I cannot make sense of the scope pics then. | 10:41 |
wolfspraul | why should I forget the first two bits? | 10:41 |
aw | the picture file name show 0x0c and 0x1c were read by gui not i read from waveforms. | 10:41 |
wolfspraul | and why are all 1 - inverted? that doesn't look right | 10:41 |
wolfspraul | yes sure, I understood that | 10:41 |
wolfspraul | so I tried to find out why one came out as 0x0c in the GUI, one as 0x1C | 10:41 |
wolfspraul | but I read the bits very different from you already, of course I start at the very left, assuming that's the first start bit | 10:42 |
wolfspraul | 2 start bits, 1 toggle bit, 5 address bits, 6 command bits (last bit almost not on the picture) | 10:43 |
wolfspraul | anyway, I cannot make sense reading those pics, so I cannot help :-) | 10:43 |
wolfspraul | they look like 0x03 to me, both of them, differ only in toggle bit | 10:43 |
aw | from http://users.telenet.be/davshomepage/rc5.htm shows, the rightest bit is read as the same big status though, me either. I don't know why gui reads it as 0x0c and 0x1c though. | 10:43 |
wolfspraul | let's focus on reading the scope bits correctly first | 10:44 |
lekernel | aw, btw, have you ordered the RC3 PCBs already? | 10:45 |
aw | lekernel, no | 10:45 |
lekernel | what's missing? | 10:45 |
wolfspraul | lekernel: you looked at adam's pics earlier - what is the value of those bits? http://downloads.qi-hardware.com/people/adam/m1/pic/button1_0x0c.JPG | 10:47 |
wolfspraul | you looked only at the cleanliness, or also the bit values? | 10:47 |
aw | gerber file on zener I realized it's not good to insert through hole part, so we changed the footprint again to meet suitable zener diode with two pins length. | 10:49 |
lekernel | just cleanliness, but hey... that simple analogue receiver isn't going to switch bits | 10:49 |
lekernel | if it doesn't work with such a signal, either the remote isn't rc5 or the fpga design needs fixing | 10:49 |
aw | after this done, I'll gerber out. | 10:49 |
lekernel | aw, can you get that done, and only then play with the remotes? | 10:49 |
aw | lekernel, whe i get the final gerber, I'll gerber out. right now I've receive final yet. No related about this remote. | 10:51 |
lekernel | you're waiting for the layout house? or do you still have something to do on your side? | 10:51 |
aw | just waiting only. | 10:52 |
wolfspraul | lekernel: yes but in order to find this out, one would need to read those bits. because if it's 0x03 there, but 0x0c/0x1C in the gui, then the problem is in the fpga | 10:52 |
lekernel | ok | 10:52 |
wolfspraul | that's why I read it, and even though I cannot clearly see the start bit and last bit, it look like 0x03 to my untrained eyes | 10:52 |
wolfspraul | but it looks like 11111111101 to Adam, so whatever :-) | 10:52 |
wolfspraul | I'll wait :-) | 10:52 |
lekernel | the pattern isn't complete | 10:52 |
aw | wolfspraul, wait..i do probe again. :-) | 10:53 |
lekernel | capture for a longer time | 10:53 |
wolfspraul | yes it's cut off a little | 10:53 |
lekernel | aw, how much work is needed by the layout house? any idea when this will be done? | 10:55 |
lekernel | omg... the rc3 run is incredibly slow | 10:55 |
wolfspraul | at least it's almost done. we should plan for rc4 already :-) | 10:57 |
lekernel | i'm doing it, I ordered samples of adv7180 yesterday | 10:59 |
lekernel | that should be the only change... | 10:59 |
wolfspraul | I still see, without an Ethernet cable connected, both my green and yellow led at the Ethernet connector on sometimes | 10:59 |
wolfspraul | that was some hardware bug, right? that's fixed in rc3? | 11:00 |
lekernel | it's not fixed in the PCB | 11:00 |
lekernel | I had it once, even with the new bitstream | 11:00 |
lekernel | the software is able to recover from this condition by resetting the PHY | 11:00 |
lekernel | so it's fixable in software on all boards no matter what | 11:01 |
wolfspraul | ok | 11:01 |
aw | wolfspraul, http://downloads.qi-hardware.com/people/adam/m1/pic/button1_0x0c_wide.JPG | 11:01 |
lekernel | i'd guess this has to do with the FPGA sending it a clock it doesn't like during startup phases | 11:01 |
aw | wolfspraul, http://downloads.qi-hardware.com/people/adam/m1/pic/button1_0x1c_wide.JPG | 11:02 |
aw | with wider view, should be easily read it although it's narrow. | 11:03 |
lekernel | btw, the IR sensor output is inverted | 11:05 |
lekernel | so IR signal present = 0 level | 11:05 |
wolfspraul | I read this as 11000000000001 | 11:05 |
wolfspraul | maybe I get it wrong though :-) | 11:05 |
lekernel | no IR signal present = 1 level | 11:05 |
kristianpaul | what? clang-lm32 | 11:12 |
kristianpaul | :-) | 11:12 |
kristianpaul | does it works? | 11:13 |
lekernel | there's no difference between the two pictures... is there? | 11:13 |
lekernel | kristianpaul, partly, see email on list | 11:13 |
kristianpaul | sure sure, just waking up here :-) | 11:13 |
lekernel | this looks like RC5, but with 0x01 code, not 0x0c or 0x1c | 11:14 |
wolfspraul | that's good because he pressed the '1' button | 11:15 |
wolfspraul | no difference? the signal looks different to me at the beginning (third bit), but I probably misread the whole thing... | 11:15 |
wolfspraul | but if you read it as 0x01, even better | 11:16 |
lekernel | ah, yeah, but that's the toggle bit I gues | 11:16 |
wolfspraul | yes | 11:16 |
lekernel | so that one is RC5 | 11:16 |
lekernel | but the fpga core doesn't decode it correctly | 11:16 |
wolfspraul | or we do something wrong in how we read 0x0c/0x1c | 11:17 |
lekernel | it should be just a read of a memory mapped register in the FPGA | 11:17 |
lekernel | you can try with the mr command in BIOS | 11:18 |
wolfspraul | xiangfu said he got different values when running the test software vs. the flickernoise gui :-) he's looking into that now | 11:18 |
lekernel | get it to work with "mr" in BIOS first | 11:18 |
lekernel | more layers = more sources of problems | 11:18 |
wolfspraul | so we agree that the scope pic looks like a clean 0x01, that's a start :-) | 11:19 |
wolfspraul | roh: when you laser the button pieces, can you take the protective films off before you laser? | 12:16 |
wolfspraul | I think it's crazy work to take off all the film from those little pieces... | 12:16 |
wolfspraul | I hope you can ship the buttons pre-assembled anyway, but that may we one way to take out some work... | 12:17 |
lekernel | bbl | 12:18 |
xiangfu | hi | 12:36 |
xiangfu | i just try button1 in bios. read it by [mr 0xe000e000 4] | 12:36 |
xiangfu | I got 00001000, 0000100c 0000181c, inconsistent values | 12:37 |
wolfspraul | xiangfu: looks like your first change to fix a bug in Verilog :-) | 12:38 |
xiangfu | I tried ~30 times. I also get 0000101c, 00001804, 000010fc | 12:39 |
wolfspraul | chance | 12:39 |
xiangfu | seems all random. | 12:39 |
wolfspraul | is that with the same remote control like Adam's? | 12:39 |
xiangfu | yes. I am use the same remote control Adam sent to me. | 12:39 |
wolfspraul | so for now let's assume it sends a proper rc-5 code to your m1 | 12:39 |
wolfspraul | which key are you pressing? | 12:39 |
xiangfu | '1' | 12:40 |
wolfspraul | ok. I think you look in Verilog to see why it's coming in as 11x00000000001 on one side (we assume that now), and out as all sorts of numbers, instead of 0x01 | 12:42 |
roh | wolfspraul: the button spacers are already lasered. | 13:15 |
roh | pre assembling them will delay everything massively. i will need to build rigs and manually glue them all. | 13:16 |
aw_ | wolfspraul xiangfu from my two waveforms (button1_0x1c_wide.JPG and button1_0x0c.wide.JPG) which we extracted from ir receiver's output is both the same 000-11111-111110, after inverted code (by visua) is 111-00000-000001 | 14:08 |
aw_ | please ignore left 3rd bit which is for repeat mode. | 14:08 |
aw_ | thus this approves my current remoter and xiangfu's is totally correct and good remoter. so there's no such "different codes" from remoter at all. | 14:10 |
wolfspraul | roh: who should glue them together? | 14:11 |
wolfspraul | if 'pre assembling' them delays everything massively, I'm wondering whether post-assembling them will not delay 'everything' massively? don't understand | 14:12 |
wolfspraul | I need about 20-30 minutes for 3 buttons, and after that there is glue everywhere, and the buttons look horrible, and don't fit/work well | 14:14 |
wolfspraul | maybe we can replace the middle piece with some gluing mass/rubber? | 14:18 |
wolfspraul | we can take the thickest two-sided glue film we can find, and then lay them over each other until it's thick enough to replace the middle piece | 14:19 |
wolfspraul | then we laser small round pieces out of this and voila, we only have to glue this between the bigger button piece and the colored front piece :-) | 14:20 |
wolfspraul | roh: the buttons are my biggest concern right now | 14:33 |
wolfspraul | I am not aware of any controlled way to assemble them in good quality | 14:33 |
wolfspraul | when I do it, it ends up in a big mess, and not very functional either | 14:33 |
wolfspraul | xiangfu has been a little better, but also far from polished look | 14:34 |
wolfspraul | from my perspective, the biggest need is to remove the glue | 14:38 |
wolfspraul | I think we have no chance to get it under control as long as we use glue | 14:39 |
wolfspraul | my m1 froze twice rendering over the last 3 hours or so... | 14:55 |
wolfspraul | didn't see this before, so it looks like a regression | 14:56 |
kristianpaul | too bad, what you did exactly? | 15:06 |
wolfspraul | just froze a third time | 15:07 |
wolfspraul | simply running a patch, nothing but power and vga connected, it was Aderassi - Variants of Eternity (shaking mix) | 15:07 |
wolfspraul | kristianpaul: do you have a remote control? | 15:08 |
kristianpaul | yes i do have some | 15:08 |
wolfspraul | ahh - froze again | 15:08 |
wolfspraul | well I can definitely reproduce the freeze right now, which is good :-) | 15:08 |
wolfspraul | kristianpaul: have you ever tried one successfully with m1? | 15:08 |
kristianpaul | nope | 15:08 |
kristianpaul | no luck last time and lekernel point me to buy another brand of remote control.. | 15:09 |
wolfspraul | it turns out nobody but lekernel seems to have ever had IR remote working | 15:09 |
kristianpaul | hehe | 15:09 |
wolfspraul | the test routine we ran in rc2 was very, let's say 'generous' | 15:10 |
wolfspraul | so it masked everything that was wrong successfully | 15:10 |
wolfspraul | Adam has no working remote, neither does Xiangfu or me | 15:10 |
kristianpaul | yeah i was rading backlog | 15:10 |
wolfspraul | did you try to get that remote Sebastien was suggesting? | 15:11 |
wolfspraul | so all the ones you have don't work, oh well | 15:11 |
kristianpaul | nope | 15:12 |
kristianpaul | actually last thing i cared about mm1 was remote control.. | 15:12 |
wolfspraul | maybe but that logic doesn't work with me. we have IR so it has to work. | 15:13 |
wolfspraul | we are quite generous in calling other people's stuff 'crap' | 15:13 |
wolfspraul | I'm wondering whether Sebastien's remote is actually rc5 :-) | 15:14 |
wolfspraul | or when he last used it... | 15:14 |
wolfspraul | something is strange | 15:14 |
kristianpaul | sure sure, not saying is not important, just i dint look it at it yet | 15:15 |
wolfspraul | yes same here | 15:15 |
wolfspraul | but now that I do look at it it's quite an surprise :-) | 15:15 |
kristianpaul | i bet is not used too much.. | 15:33 |
mumptai | hello | 15:38 |
kristianpaul | hi mumptai | 15:38 |
wolfspraul | kristianpaul: yes, definitely not used much :-) | 16:20 |
--- Wed Jun 8 2011 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!