<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?
<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.)"
<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?
<larsc>
i think the carrier wave mostly only matters for the IR-filter
<wolfspraul>
don't understand
<wolfspraul>
the receiver is available in different part numbers, 30, 33, 36, 38, 40 and 56 khz
<wolfspraul>
why that? what does it mean if you have the 'wrong one'?
<larsc>
the signal won't go through the filter i guess
<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?
<wolfspraul>
sorry same question as before :-)
<wolfspraul>
what if the distance is bigger, say a control sending on a 56khz carrier, and the receiver being a 30 khz part number?
<larsc>
maybe ;)
<larsc>
it all depends on how narrow the filter is. if you wnat to be sure, use the 38khz receiver
<wolfspraul>
we use a 38khz receiver right now
<wolfspraul>
oh you mean because it is in the middle from 36 to 40?
<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?
<larsc>
depends on how narrow the filter is. take a look at the datasheet
<wolfspraul>
datasheet only says "should be close to the band-pass center frequency", cannot find more details
<wolfspraul>
not sure whether 2khz distance is 'close' or not :-)
<wolfspraul>
it's probably obvious, but not to me...
<roh>
hm. i think it will work even if its off a bit
<wolfspraul>
yes but what is 'a bit'?
<roh>
Fig.5
<wolfspraul>
wikipedia seems to say rc-5 is often found on 36, 38 or 40 khz. ok, I got that.
<roh>
there is a bandpass curve for f+-5%
<wolfspraul>
now, our vishay part is of 38 khz type. did we choose that because it's in the middle of 36-40?
<roh>
dunno
<roh>
but i guess it will work best with 38, and maybe with a few percent less range also with 36 and 40khz ones
<roh>
atleast thats what that graph tells me
<roh>
f=f0 +-5%
<roh>
delta f(3dB)=f0/10
<roh>
its half as sensitive at 3.8khz up and down
<wolfspraul>
hmm
<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
<wolfspraul>
ok
<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
<roh>
it works less well, but maybe one only notices when using it on long distance
<wolfspraul>
so maybe we did choose 38 to be in the middle of 36-40
<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)
<wolfspraul>
but then, it looks like sensitivity goes down quite a lot, even with 5% off
<roh>
yes.
<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
<larsc>
needs coffee...
<larsc>
ha! coffee!
<wolfspraul>
roh: is it possible that the infrared goes through the wood case you made once?
<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)
<lekernel>
have you looked at the waveform from a DSO or logic analyzer?!??
<aw>
um...good stuff my toggle bit is strange...checking that protocol...
<xiangfu>
I bought another controller. it do give only one value when press one button. but the value is not correct.
<xiangfu>
(the two phillips brand remote controller is on the way to me)
<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.
<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.
<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
<wolfspraul>
we are not trying to 'find/extract' the right value, we are trying to test the transmission :-)
<xiangfu>
I got reliably value when press same button
<xiangfu>
wolfspraul: (20 times) yes.
<aw>
so now the problems is that our ir transmitter is not sending correct one since second start bit is wrong
<wolfspraul>
second start bit is a toggle bit I think
<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.
<wolfspraul>
to tell the difference between two button presses versus someone walking through the signal
<aw>
wolfspraul, NO, start bit have two bits with "1"
<aw>
so this is surely my remoter is not sending a good code when i press the same button "1" key
<xiangfu>
"transmitter" what is that? one component on m1 pcb? the TSOP34838?
<aw>
xiangfu, sorry, i said transmitter is your remoter. :-)
<xiangfu>
aw: I don't know that. I just configure it as phillips remote controller. it's a universal controller, very cheap.
<xiangfu>
aw: transmitter ok. get it.
<xiangfu>
back online in 10 Mins
<aw>
xiangfu, hmm..got it.
<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.
<aw>
xiangfu, pls take picture of your universal remoter so that i can find if it exists here i can buy.
<xiangfu>
aw:hmm.. I think let's wait the 'phillips branch remote controller' in next two days.
<xiangfu>
aw: I just bought them at small shop, you know in China. it's only 10RMB.
<xiangfu>
I mean I just bought this one at small shop.
<aw>
hmm..okay..bad asia not just China. :-)
<aw>
okay..let's stick on a real philips remote controller.
<xiangfu>
I meet another problem. I get different value in Flicernoise and Test image.
<aw>
xiangfu, hup? what's difference in flickernoise when you press the same button 1?
<aw>
xiangfu, what value the gui read for button 1? 0x0c? 0x1c?
<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
<xiangfu>
wolfspraul: but there is another problem. you have to press the button very fast then you can get only one time value.
<xiangfu>
wolfspraul: I will change code that handle the repeat values.
<aw>
xiangfu
<aw>
i finally realized that toggle bit
<aw>
1 toggle bit (change everytime when a new button is pressed on the ir transmitter)
<wolfspraul>
yes. that's a bit we need to mask out when comparing against the value we expect for a particular button.
<aw>
yes so xiangfu needs to mask it when repeating code coming.
<wolfspraul>
aw: I'm looking at the two scope pics you uploaded earlier
<wolfspraul>
the 0x0c one looks like 111000000000011 to me
<wolfspraul>
the 0x1c one looks like 110000000000011, so no difference other than the toggle bit
<wolfspraul>
the 11 at the end should come out as 0x03, neither 0x0c nor 0x1c
<wolfspraul>
so obviously I misunderstand something :-)
<wolfspraul>
am I misreading the scope output?
<aw>
it's 11111111111101
<wolfspraul>
which one is that? 0c or 1c?
<aw>
please forget about the first two bits on those two waveforms, the remaining rightest bits is all the same **111111111101
<aw>
i need to probe in a suitable time slot again.
<wolfspraul>
well OK, I cannot make sense of the scope pics then.
<wolfspraul>
why should I forget the first two bits?
<aw>
the picture file name show 0x0c and 0x1c were read by gui not i read from waveforms.
<wolfspraul>
and why are all 1 - inverted? that doesn't look right
<wolfspraul>
yes sure, I understood that
<wolfspraul>
so I tried to find out why one came out as 0x0c in the GUI, one as 0x1C
<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
<wolfspraul>
2 start bits, 1 toggle bit, 5 address bits, 6 command bits (last bit almost not on the picture)
<wolfspraul>
anyway, I cannot make sense reading those pics, so I cannot help :-)
<wolfspraul>
they look like 0x03 to me, both of them, differ only in toggle bit
<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.
<wolfspraul>
let's focus on reading the scope bits correctly first
<lekernel>
aw, btw, have you ordered the RC3 PCBs already?
<wolfspraul>
you looked only at the cleanliness, or also the bit values?
<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.
<lekernel>
just cleanliness, but hey... that simple analogue receiver isn't going to switch bits
<lekernel>
if it doesn't work with such a signal, either the remote isn't rc5 or the fpga design needs fixing
<aw>
after this done, I'll gerber out.
<lekernel>
aw, can you get that done, and only then play with the remotes?
<aw>
lekernel, whe i get the final gerber, I'll gerber out. right now I've receive final yet. No related about this remote.
<lekernel>
you're waiting for the layout house? or do you still have something to do on your side?
<aw>
just waiting only.
<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
<lekernel>
ok
<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
<wolfspraul>
but it looks like 11111111101 to Adam, so whatever :-)
<wolfspraul>
I'll wait :-)
<lekernel>
the pattern isn't complete
<aw>
wolfspraul, wait..i do probe again. :-)
<lekernel>
capture for a longer time
<wolfspraul>
yes it's cut off a little
<lekernel>
aw, how much work is needed by the layout house? any idea when this will be done?
<lekernel>
omg... the rc3 run is incredibly slow
<wolfspraul>
at least it's almost done. we should plan for rc4 already :-)
<lekernel>
i'm doing it, I ordered samples of adv7180 yesterday
<lekernel>
that should be the only change...
<wolfspraul>
I still see, without an Ethernet cable connected, both my green and yellow led at the Ethernet connector on sometimes
<wolfspraul>
that was some hardware bug, right? that's fixed in rc3?
<lekernel>
it's not fixed in the PCB
<lekernel>
I had it once, even with the new bitstream
<lekernel>
the software is able to recover from this condition by resetting the PHY
<lekernel>
so it's fixable in software on all boards no matter what
<aw>
with wider view, should be easily read it although it's narrow.
<lekernel>
btw, the IR sensor output is inverted
<lekernel>
so IR signal present = 0 level
<wolfspraul>
I read this as 11000000000001
<wolfspraul>
maybe I get it wrong though :-)
<lekernel>
no IR signal present = 1 level
<kristianpaul>
what? clang-lm32
<kristianpaul>
:-)
<kristianpaul>
does it works?
<lekernel>
there's no difference between the two pictures... is there?
<lekernel>
kristianpaul, partly, see email on list
<kristianpaul>
sure sure, just waking up here :-)
<lekernel>
this looks like RC5, but with 0x01 code, not 0x0c or 0x1c
<wolfspraul>
that's good because he pressed the '1' button
<wolfspraul>
no difference? the signal looks different to me at the beginning (third bit), but I probably misread the whole thing...
<wolfspraul>
but if you read it as 0x01, even better
<lekernel>
ah, yeah, but that's the toggle bit I gues
<wolfspraul>
yes
<lekernel>
so that one is RC5
<lekernel>
but the fpga core doesn't decode it correctly
<wolfspraul>
or we do something wrong in how we read 0x0c/0x1c
<lekernel>
it should be just a read of a memory mapped register in the FPGA
<lekernel>
you can try with the mr command in BIOS
<wolfspraul>
xiangfu said he got different values when running the test software vs. the flickernoise gui :-) he's looking into that now
<lekernel>
get it to work with "mr" in BIOS first
<lekernel>
more layers = more sources of problems
<wolfspraul>
so we agree that the scope pic looks like a clean 0x01, that's a start :-)
<wolfspraul>
roh: when you laser the button pieces, can you take the protective films off before you laser?
<wolfspraul>
I think it's crazy work to take off all the film from those little pieces...
<wolfspraul>
I hope you can ship the buttons pre-assembled anyway, but that may we one way to take out some work...
<lekernel>
bbl
<xiangfu>
hi
<xiangfu>
i just try button1 in bios. read it by [mr 0xe000e000 4]
<xiangfu>
I got 00001000, 0000100c 0000181c, inconsistent values
<wolfspraul>
xiangfu: looks like your first change to fix a bug in Verilog :-)
<xiangfu>
I tried ~30 times. I also get 0000101c, 00001804, 000010fc
<wolfspraul>
chance
<xiangfu>
seems all random.
<wolfspraul>
is that with the same remote control like Adam's?
<xiangfu>
yes. I am use the same remote control Adam sent to me.
<wolfspraul>
so for now let's assume it sends a proper rc-5 code to your m1
<wolfspraul>
which key are you pressing?
<xiangfu>
'1'
<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
<roh>
wolfspraul: the button spacers are already lasered.
<roh>
pre assembling them will delay everything massively. i will need to build rigs and manually glue them all.
<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
<aw_>
please ignore left 3rd bit which is for repeat mode.
<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.
<wolfspraul>
roh: who should glue them together?
<wolfspraul>
if 'pre assembling' them delays everything massively, I'm wondering whether post-assembling them will not delay 'everything' massively? don't understand
<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
<wolfspraul>
maybe we can replace the middle piece with some gluing mass/rubber?
<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
<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 :-)
<wolfspraul>
roh: the buttons are my biggest concern right now
<wolfspraul>
I am not aware of any controlled way to assemble them in good quality
<wolfspraul>
when I do it, it ends up in a big mess, and not very functional either
<wolfspraul>
xiangfu has been a little better, but also far from polished look
<wolfspraul>
from my perspective, the biggest need is to remove the glue
<wolfspraul>
I think we have no chance to get it under control as long as we use glue
<wolfspraul>
my m1 froze twice rendering over the last 3 hours or so...
<wolfspraul>
didn't see this before, so it looks like a regression
<kristianpaul>
too bad, what you did exactly?
<wolfspraul>
just froze a third time
<wolfspraul>
simply running a patch, nothing but power and vga connected, it was Aderassi - Variants of Eternity (shaking mix)
<wolfspraul>
kristianpaul: do you have a remote control?
<kristianpaul>
yes i do have some
<wolfspraul>
ahh - froze again
<wolfspraul>
well I can definitely reproduce the freeze right now, which is good :-)
<wolfspraul>
kristianpaul: have you ever tried one successfully with m1?
<kristianpaul>
nope
<kristianpaul>
no luck last time and lekernel point me to buy another brand of remote control..
<wolfspraul>
it turns out nobody but lekernel seems to have ever had IR remote working
<kristianpaul>
hehe
<wolfspraul>
the test routine we ran in rc2 was very, let's say 'generous'
<wolfspraul>
so it masked everything that was wrong successfully
<wolfspraul>
Adam has no working remote, neither does Xiangfu or me
<kristianpaul>
yeah i was rading backlog
<wolfspraul>
did you try to get that remote Sebastien was suggesting?
<wolfspraul>
so all the ones you have don't work, oh well
<kristianpaul>
nope
<kristianpaul>
actually last thing i cared about mm1 was remote control..
<wolfspraul>
maybe but that logic doesn't work with me. we have IR so it has to work.
<wolfspraul>
we are quite generous in calling other people's stuff 'crap'
<wolfspraul>
I'm wondering whether Sebastien's remote is actually rc5 :-)
<wolfspraul>
or when he last used it...
<wolfspraul>
something is strange
<kristianpaul>
sure sure, not saying is not important, just i dint look it at it yet
<wolfspraul>
yes same here
<wolfspraul>
but now that I do look at it it's quite an surprise :-)
<kristianpaul>
i bet is not used too much..
<mumptai>
hello
<kristianpaul>
hi mumptai
<wolfspraul>
kristianpaul: yes, definitely not used much :-)