search

peterhinch / micropython_ir

Nonblocking device drivers to receive from IR remotes and for IR "blaster" apps.
MIT License
240 stars 51 forks source link

Decode result is not stable #5

Closed vanminh0910 closed 3 years ago

vanminh0910 commented 3 years ago

Hi @peterhinch ,

Thanks a lot for your great effort in writing this lib as there are not many good micropython for handling IR communication out there. I have tried your lib using my esp32 board with nearly the same hardware setup:

But the result is not very stable, it could not decode the key correctly many times it. Here is sample output:

Data 04 Addr fd00 Ctrl 00 Repeat code. Data 09 Addr 0000 Ctrl 00 Repeat code. Repeat code. Error: bad block Repeat code. Repeat code. Repeat code. Repeat code. Error: bad block Repeat code. Repeat code. Data 05 Addr 0000 Ctrl 00 Repeat code. Repeat code. Repeat code. Repeat code. Error: bad block Invalid start pulse Repeat code. Repeat code. Repeat code. Invalid start pulse Invalid start pulse Invalid start pulse Invalid start pulse Invalid start pulse Repeat code. Repeat code. Invalid start pulse Invalid start pulse Repeat code. Repeat code. Repeat code. Repeat code. Repeat code. Repeat code. Repeat code. Repeat code. Repeat code. Repeat code. Repeat code. Data 04 Addr 0000 Ctrl 00 Repeat code. Repeat code. Data 04 Addr 0000 Ctrl 00 Repeat code. Repeat code. Error: bad block Repeat code. Repeat code. Data 04 Addr f700 Ctrl 00 Repeat code. Repeat code. Repeat code. Repeat code. Repeat code. Error: bad block Repeat code. Repeat code. Repeat code. Repeat code. Data 05 Addr 0000 Ctrl 00 Repeat code. Data 01 Addr ff40 Ctrl 00 Repeat code. Data 06 Addr fd00 Ctrl 00 Repeat code. Repeat code.

Do you have any idea how to improve the result? Are you seeing the same on your side or yours is way better?

peterhinch commented 3 years ago

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.

vanminh0910 commented 3 years ago

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?

peterhinch commented 3 years ago

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.

vanminh0910 commented 3 years ago

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.

peterhinch commented 3 years ago

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.

vanminh0910 commented 3 years ago

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. `

peterhinch commented 3 years ago

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.

vanminh0910 commented 3 years ago

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.