Decode result is not stable about micropython_ir HOT 8 CLOSED

I don't think you should change anything in your code as my test is only for my specific remote and may not work with others. Thanks a lot for the great lib.

from micropython_ir.

It's hard to comment as IR reception depends on local conditions - distance between TX and RX, accuracy of pointing the TX, optical or electrical interference etc.

A specific ESP32 issue is that interrupts are always soft. This means that if a garbage collect occurs during reception an error will probably occur. In the case of ESP32 with SPIRAM a GC can take >100ms. So reception may depend on what else the application is doing and how frequently it triggers GC.

IR communication always seems to be subject to some errors. It's a common experience to press a button on a remote and have to repeat the action. That said, in my testing under good conditions errors were infrequent.

from micropython_ir.

Thanks for your explanation. Looks like there is no better solution for now.

Another question, in case I need the lib to work with only one specific remote type, is there anyway to map the received raw signal to one of the remote keys based on best guess?

from micropython_ir.

I'm not entirely sure what you mean here. It sounds like you're talking about a mechanism for tolerating minor errors like Hamming distance? If so, I guess it's a theoretical possibility but it would need considerable study and might turn out to be unfeasible. I have no plans to do this.

from micropython_ir.

Yes, that's what I want to do, tolerating for minor errors but not by using any complex math algorithm. I have recorded the raw data and compared ones well recognized and ones with error, and I found that the invalid data error happens even with "look rather good" raw data. I have not gone through the details in decode function to see what's wrong in the data yet, but only tried to comment out the invalid data error and repeat error case. And I got very stable result using my remote and controlling my remote car is good enough.

Here is my recorded raw data in case anyone wants to take a look https://docs.google.com/spreadsheets/d/1ksSjXazcKixxS3fKZB_aiWfX9MpiWVuQvIs9kpeFEsU/edit?usp=sharing.

Thanks for the great library. I will close this issue and it is solved on my side.

from micropython_ir.

That dataset is interesting. In the "invalid data" sets there are some odd pulse lengths.

The "invalid start" records seem to hint at external interference. If you leave the receiver running without transmitting, do these events occur? They all seem similar with a ~1ms pulse followed by ~44μs and ~33μs. If some external source is generating these, it could also explain the data errors.

from micropython_ir.

The "invalid start" records are repeat event when I pressed key and hold it. All data in the sheet were generated due to my actions. I did not see many strange raw data when not transmitting. So in the decode function, by updating the code like this, I treat them as repeat event correctly. It works really well.

elif width > 1000: # 2.5ms space for a repeat code. Should have exactly 4 edges.
raise RuntimeError(self.REPEAT if (self.edge == 3 or self.edge == 4) else self.BADREP) # Treat REPEAT as error.

ths is your original code:
elif width > 1700: # 2.5ms space for a repeat code. Should have exactly 4 edges.
raise RuntimeError(self.REPEAT if self.edge == 4 else self.BADREP) # Treat REPEAT as error.
`

from micropython_ir.

All three of the references in my docs agree about repeat codes:

a 9ms leading pulse burst
a 2.25ms space
a 562.5µs pulse burst to mark the end of the space (and hence end of the transmitted repeat code).

This accords with my own measurements. I therefore don't plan to change my threshold of 1.7ms unless some new information turns up. I'm baffled by your results but you've clearly been very thorough in studying this. Thanks for the information, I'll bear it in mind in case anyone else has a similar problem.

I'm glad you've got something working.

from micropython_ir.