<wpwrak>
wolfspraul: will you bundle a remote with M1 ? or just tell people what to get ?
<wolfspraul>
hah
<wolfspraul>
your humor is the best, by far!
<wpwrak>
(-:C
<wolfspraul>
there is, reportedly, one known working remote control
<wolfspraul>
an unknown Philips model
<wolfspraul>
from my investigations so far, I have been unable to find anyone else who was able to find a working one
<wolfspraul>
although many have tried
<wolfspraul>
I have 4 right in front of me here
<wolfspraul>
Xiangfu has 6 now, quickly growing to 10+
<wolfspraul>
kristianpaul has tried 4 or more
<wolfspraul>
at this point I can neither bundle one, nor tell people 'what to get'
<wpwrak>
that's even more damning than i imagined ;-)
<wolfspraul>
but... we're getting there
<wolfspraul>
I'm optimistic as always
<wpwrak>
"just get one that works" ;-)
<wolfspraul>
I make a few assumptions
<wolfspraul>
Sebastien's working one is really rc-5
<wolfspraul>
38khz
<wpwrak>
"take M1 to the remotes shop, then keep on trying" :) that may actually be a strategy for finding one more that works
<wolfspraul>
the one Adam used, and sent an identical one to Xiangfu, is rc-5 as well
<wolfspraul>
the reason Adam and Xiangfu cannot get their to work is timing issues in the rc5 core in the SoC
<wolfspraul>
if that's true and can be fixed, perfect. we are back on track.
<wolfspraul>
at least that would explain everything I've seen so far.
<wpwrak>
(timing issue) yeah, i saw the discussion in #qi-hardware
<wpwrak>
then you'd bundle a known to be good one ?
<wolfspraul>
too speculative, one by one
<wolfspraul>
yes sure, if I can easily source a nice one that works for 2-3 USD, I'll throw it in
<wolfspraul>
without batteries as that would create too many shipping problems (will be standard cr2025 or so though)
<wpwrak>
okay, in this case the rc5-only route would work
<wolfspraul>
I cannot in a controlled way buy even a single working one.
<wpwrak>
yeah. i'd just dismiss rc5 and "learn" what the remote can do
<wolfspraul>
this IR problem will soon be resolved, I'm optimistic
<wpwrak>
make the fpga send a sequence of on/off interval values. two parameters: denoise delay and maximum idle time (before you signal the core that a new packet has arrived)
<wolfspraul>
well I cannot just hack that together
<wpwrak>
LIRC should have solved most of the technical side already
<wolfspraul>
if I'm lucky and I find a control that works well with m1, I'd forego any SoC fix
<wpwrak>
yeah, the nice thing about fpga - you can always fix it later ;-)
<wolfspraul>
but maybe it's easier to improve the rc5 core and then source a remote
<wolfspraul>
well, to a degree
<wolfspraul>
it gets dangerous when you start to fool yourself in testing
<wolfspraul>
I don't like that.
<wpwrak>
hehe ;-)
<wolfspraul>
I have a lot of experience in dealing with customer support cases.
<wpwrak>
yeah, if you can't even tell whether the IR receiver is connected or not, then your testing may be in trouble ;)
<wolfspraul>
and the one thing I need is _certainty_ on my side, what was originally tested.
<wolfspraul>
people come up with the craziest stories what happened and how something is not working
<wolfspraul>
if I don't have hard data on my side ("we tested this and that, so his problem must be ..."), then I have no chance
<wolfspraul>
for example Xiangfu and Adam over the last months started to believe that 'different values' are normal in IR remotes
<wolfspraul>
I cannot blame them, it's natural. We learn what is 'normal' from our environment.
<wolfspraul>
you wouldn't find that too funny on your TV remote though
<wolfspraul>
press '3', sometimes it goes to channel 5, sometimes 1, sometimes 4, etc.
<wolfspraul>
in the end this leads to cases where tech support tells the customer "it all works" and the customer says "nothing works"
<wpwrak>
well, you may not even notice the occasional incorrect value all that much
<wolfspraul>
and that's it. return, refund, big loss, frustration. needs to be fixed early.
<wpwrak>
but of course, here the situation seems to be a lot worse that just one bad code in a hundred
<wolfspraul>
you bet
<wolfspraul>
:-)
<wolfspraul>
long story short - it's not working
<wolfspraul>
but no drama, we are close now
<wolfspraul>
it was my oversight to not notice this earlier
<wolfspraul>
I always thought "remote will just work" - ha!
<wpwrak>
what could possibly go wrong ? ;-)
<wolfspraul>
Sebastien cannot see it, because his remote works and all is perfect, and why should he test many different ones...
<wolfspraul>
Adam didn't see anything wrong because it looked like the behavior we got was 'normal'
<wolfspraul>
Xiangfu inherited his knowledge from Adam
<wolfspraul>
I became frustrated because I was unable to find any single remote that actually worked, although kristianpaul had been in this situation before but I didn't notice/understand the significance.
<wolfspraul>
That's how it goes :-)
<wpwrak>
kristianpaul is also a good test buyer because he doesn't live all that close to philips. "just buy a philips" may be rather tricky in some markets
<wolfspraul>
nah it's ok. if sebastien's latest theory is correct, the problem may simply be that the timings are way too specifically tuned/correct for the one remote Sebastien was working with in development.
<wolfspraul>
maybe even another control of the same model wouldn't work :-) we don't know right now
<wpwrak>
another benefit of a generic receiver - you see pretty quickly when your values are off :)
<wolfspraul>
my m1 just froze again in rendering (was testing) - 50 minutes
<wolfspraul>
starting over...
<wolfspraul>
yesterday I had the impression it got shorter over time, as if temperature or so mattered
<lekernel>
wolfspraul, get a damn stack trace when it freezes. just reporting "it freezes" isn't going to help.
<lekernel>
yeah well... it's a very simple piece of Verilog. no need to write a PhD on that :)
<xiangfu>
lekernel: how to get stack trace when it freezes?
<xiangfu>
lekernel: (timing rc5 verlog) you can give me a little info. I can test it in my m1 with IR remote controller :)
<xiangfu>
this is my first patch :D http://dpaste.com/551822/ but fix nothing. still same result as before :(
<wolfspraul>
ok the reason hadez is not moving forward is because he is waiting for the jtag-serial board
<wolfspraul>
at least it's an m1 owner who communicates :-)
<lekernel>
xiangfu, generate a .elf with debug information (built by default), load the very same binary into the M1, then use gdb remote
<lekernel>
lm32-rtems4.11-gdb flickernoise.elf
<lekernel>
flterm --gdb-passthrough
<lekernel>
in gdb: target remote /dev/pts/xxx
<lekernel>
backtrace
<xiangfu>
lekernel: thanks.
<wolfspraul>
lekernel: did you see what I wrote about errors when compiling patches?
<lekernel>
no
<wolfspraul>
it looks like a memory corruption
<wolfspraul>
ok I had this yesterday: I press "SImple Mode"
<wolfspraul>
it stops at some patch X, saying "error compiling X"
<wolfspraul>
I press "ok", then "Simple Mode" again
<wolfspraul>
then it stops at another path Y, again "error compiling Y"
<wolfspraul>
can go in that cycle forever, every time stops at another patch
<lekernel>
gdb is the tool you need to track down such problems
<lekernel>
otherwise it's just wild guesses
<lekernel>
you can attach gdb at any time, just make sure the debug-enabled .elf and the flashed binary are in sync
<lekernel>
maybe it'd be a good idea to put the debug elf into the msd archives ...
<xiangfu>
sounds good.
<lekernel>
wolfspraul, can you ship me a few remotes you plan including with the M1 package (preferably that one Adam made the scope trace of)? or can someone else fix the design?
<kristianpaul>
wolfspraul: i just tested so far one remote control,  a LG MKJ33981408
<kristianpaul>
wpwrak: i better can easilly buy a universal remote control, informall mercants sell it screaming it on streets all time ;)
<CIA-29>
flickernoise: Sebastien Bourdeauducq master * ra431f9d / (7 files): Long press on left pushbutton to trigger automatic web update - http://bit.ly/kwT3v0
<kristianpaul>
lekernel: what you think in rc5 about making the divisor a register that can be written from csr so the software can fix posible sampling timing issues related to IR?
<lekernel>
and how would it fix it?
<kristianpaul>
well... finding right offset by trial and error :p
<wolfspraul>
should I send an rc-5 sample remote from Adam to lekernel? or kristianpaul wants one?
<lekernel>
unfortunately this is perhaps the only way to get rc5 to work in a timely fashion
<kristianpaul>
in dont want rc5
<kristianpaul>
sample
<wolfspraul>
from the scope pics Adam took (which all read as correct rc-5), I think lekernel's latest theory about timing issues must be the right one
<kristianpaul>
i have a remote control it should work some how.. also i will try source philis one today
<kristianpaul>
may be i woks out of the box :)
<wolfspraul>
kristianpaul: maybe it's the same, it sends proper rc-5 but the SoC cannot decode it
<wolfspraul>
is the feedback from the vendor about timing and tolerances helpful at all?
<kristianpaul>
so lekernel you think a more flexyble counter for the rc5 sampling part will help?
<lekernel>
no, I don't
<lekernel>
because there is no sensible way to program it
<kristianpaul>
so? still hardcoding the core to get it work with a single control?
<lekernel>
yes, that's what taking the least time from me
<lekernel>
so unless wpwrak or you want to implement a more elaborate pattern matching system, that's how it's going to be done
<kristianpaul>
okay i tought it was a sampling issue
<kristianpaul>
or port the lirc gpio code and do bitbang from lm32/navre?
<wpwrak>
lekernel: sigh, if it was just a question of wanting ...
<lekernel>
wpwrak, so what's the problem?
<lekernel>
it's not harder than e.g. ubb-vga
<wpwrak>
lekernel: buying a mm1, finding the time, ...
<lekernel>
well, if you do it, I can give you one of my rc1's which are collecting dust anyway
<wpwrak>
heh, now that's tempting ;-)
<wpwrak>
i have no practical verilog experience, but i guess that wouldn't be an unsurmountable problem. having to install a pile of windows-only junk on my pc would be a bit of an annoyance, but i suppose everything necessary works well under wine ?
<kristianpaul>
xilinx ise run on linux btw
<kristianpaul>
and using makefiles :-)
<wpwrak>
kristianpaul: oh, even natively ? wow
<kristianpaul>
sure
<larsc>
huge 11GB blob
<wpwrak>
kristianpaul: so the whole m1 fpga development cycle can be done under linux ?
<kristianpaul>
wpwrak: sure
<kristianpaul>
wow, i tought you already knew it
<wpwrak>
hmm, 89 GB free under /
<kristianpaul>
indeed larsc
<kristianpaul>
/dev/sdb6Â Â Â Â Â Â Â Â Â Â Â Â Â Â 31GÂ Â 22GÂ Â 6,9GÂ Â 77% /opt
<kristianpaul>
all my xilinx rtems stuff is there^
<lekernel>
yeah you only need windows for the pcb (altium)
<kristianpaul>
yeah :/
<lekernel>
and to get started with verilog, you can use a free simulator like gplcver or icarus verilog
<kristianpaul>
plus gtkwave :-)
<wpwrak>
lekernel: now, what exactly would i have to do for it ? :) would be piece of code that has a "learn" (spits out a string of timing data) and a "play" mode (matches timing data with a set of known functions), along with the lower-level bits needed for it be enough ?
<lekernel>
imo the verilog module could write a RLE-compressed list of the received 0 and 1's into a small on-chip memory whenever it gets an IR burst
<lekernel>
then the CPU can do the rest
<wpwrak>
lekernel: that's exactly what i had in mind ;-)
<wpwrak>
lekernel: basically needs four parameters: sample rate, buffer depth, minimum pulse length (to de-noise), and maximum idle time (to finish burst and notify the core)
<lekernel>
you can hardcode the sample rate and buffer depth
<wpwrak>
yup. they're just design parameters.
<lekernel>
and maximum idle time can simply be set to the maximum RLE counter value before it overflows :)
<lekernel>
minimum pulse length, I'm not even sure that would be needed in hardware
<lekernel>
software can probably do it
<lekernel>
or just not do it at all, as it wouldn't match any pattern
<wpwrak>
(max) possible ... hmm, lemme see if i still have my notes from the ir research i did some eons ago ...
<wpwrak>
the min filter's main purpose would be to avoid filling the buffer with junk. some remotes are VERY chatty, so you want to make good use of the space.
<kristianpaul>
interesting, sounds like a know issue :-)
<wpwrak>
(from my notes, remotes for tv, roomba, some pinnacle IR, one where i don't remember what it was, and one from an air conditioning) i had short vs. long intervals. duration of short about 0.5-1 ms. long 2-7 ms. burst duration 30-75 ms.
<wpwrak>
the air conditioning sent about 30 intervals (i.e., 15 pulses) :)
<wpwrak>
alas, i didn't write down the time between bursts
<wpwrak>
back then i used a 100 ms timeout
<wpwrak>
64 us sample period = ~15.6 kHz
<kristianpaul>
ah, thats the known functions for
<wpwrak>
all with a meager PIC.
<kristianpaul>
(PIC) i remenber when the only way to get serial port was bitbanging :-)