On Monday 14 July 2008, Stephen Warren wrote: > 1) How was MAX_IR_SIGNAL_LENGTH chosen? Do we have any information on > whether this correlates well with the official Logitech software?
I didn't change that from the original version - looks like 'ten times more than we will ever need, just to make sure it's enough'. The longest code I have seen so far is 2*32 bits from my Pioneer DVD player, which would need roughly 400 durations to record 3 repeats. I have actually never tried what happens if you send a sequence of 4000 samples to the Logitech server... > Should the length not be hard-coded, but dynamically allocated based on > the amount of received data before timeout? We'd need to implement a > total-recording-timeout rather than (or in addition to) > time-since-last-data-seen timeout if we do this. IMHO, from the nature of IR codes, there is no much difference in limiting the total recording time (i.e. accumulated mark/space durations) vs. limiting just the number of recoded durations (like it is now - probably reducing the limit to around 600-1000). > 2) If I hold down the key on the original remote forever, > CRemote::LearnIR loops forever, since it never sees "t_off>=500000". > Since ir_signal_length is limited, perhaps the loop should break out if > the ir_signal array is completely full? Yes, the learning in remote.cpp should definitely terminate (probably with an error code, since the recoding is way too long then) in that case. The currrent code will just stop writing to the buffer if the maximum number of samples is reached, hoping that the user will eventually stop pressing that key (or run down the battery of the sending remote...). > 3) Are we supposed to detect/remove/mark/... repeats in the recorded > data. Or, does the Harmony website do this when it receives the encoded > capture? Judging from that famous 'bad IR signal...' message from the Logitech software, there seems to be some rough checking in the original driver for 'too many' 'long' gaps in the received signal. Apart from that, I think the web server will probably try to catch any IR signal you throw at it. I have started some code for detecting code repetitions, which I would need for conversion back to Pronto Hex codes, but haven't tested that yet. The tricky part is that the signal suffers slightly from jitter, so you have to add some tolerance when comparing sequences. > 4) Can this function have progress callback added; either: > > % of number of ir_samples array filled (if fixed size) > > or > > % of maximum recording time passed (if we limit recording time rather > than data size) A typical reasonable duration for a IR signal recording is approx. half a second or less, so I don't think that a progress indication will be very helpful - besides the timeout indicator for start of the recording that I added in congruity. Some next version of libconcord should probably have a quick plausability check, similar to the original driver. Andreas ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
