search

piotrC4 / mqtt-ir-transceiver

ESP8266 based bidirectional bridge between MQTT and IR (change MQTT message to IR signal and change received IR signal to MQTT message)
143 stars 34 forks source link

Raw IR code capture problem #5

Open travplan opened 7 years ago

travplan commented 7 years ago

@enc-X - Your update for the RAW code sending routine seems to be working well. I think my problem lays with learning the raw codes.

Its a satellite receiver that I'm having the issue with, none of the codes listed on global cache work, so im being forced to use RAW codes since none of the "ReceiveDump" sketches recognize the IR transmission as anything but "UNKNOWN".

The other odd thing is when i point my satellite receiver oem remote at the esp8266 receiver, and push a button, the code is never repeatable.

This leads me to think it isnt being captured fully or something.

Any ideas?

piotrC4 commented 7 years ago

I had similar situation with my STB. It have some kind of hashing RAW IR data. When I pressed and keep pressed button on STBs' remote it send 2 different codes. I used one of them and it worked well. Try to use test one of the raw codes.

travplan commented 7 years ago

@enc-X - I did try that. I push the button on the STB remote and get sometimes infinitely different codes. I have tried sending many of them from the MQTT tranceiver module and none seem to make the STB respond. I can confirm the codes are be transmitted correctly with another module running "IRrecvDumpV2".

I set the RAWBUFF variable to 1500 (default 100) in IRremoteESP8266.h because I thought maybe the buffer was running out when trying to capture the codes, but that didn't seem to make the receive from the STB remote to be any more repeatable.

Something else to note. I captured the RAW codes using IRrecDumpV2 for one of the SONY codes that works with my Yamaha Receiver for Volume Up. When I send it using the Raw code instead of the SONY code, it doesnt seem to respond either.

So i still can't confirm if I'm not able to capture RAW correctly, or there is some issue sending them (even though they do seem to be transmitting exactly how they're sent using the separate capture module).

I really wish there was another Global Cache database that worked with this STB, since the Global Cache codes work perfectly!!

piotrC4 commented 7 years ago

I have one idea, maybe it is because of wrog frequency of receiver and sender (I hardcoded 38kHz). As I read articles some devices may use even 50kHz or 40kHz (for example Sony).

travplan commented 7 years ago

@enc-X

I have ordered a couple different receivers - AGC2 and AGC4 protocol in both the 38kHz and 56kHz. Hopefully I can get some repeatable results out of one of them. TSOP4856 - 56kHz LEGACY, FOR LONG BURST REMOTE CONTROLS (AGC2) TSOP4838 - 38kHz LEGACY, FOR LONG BURST REMOTE CONTROLS (AGC2) TSOP4456 - 56kHz RECOMMENDED FOR LONG BURST CODES (AGC4) TSOP4438 - 38kHz RECOMMENDED FOR LONG BURST CODES (AGC4)

I will report back here once they come in, and I do a little bit of testing. Thanks enc-X

travplan commented 7 years ago

@enc-X

In the meantime, can you advise how to change the hardcoded sendRAW frequency?

piotrC4 commented 7 years ago

I've just pushed version 0.07 with frequency definition in file globals.h in line 32 #define TRANSMITTER_FREQ 38 - it is global hardcoded parameter for now, but I want to make it configurable.

travplan commented 7 years ago

@enc-X In mqtt.cpp, Line 346 "irsend.sendRaw(rawIrData,elementIdx,38);" Should I replace the "38" with TRANSMITTER_FREQ? that way it will read the set frequency from globals.h?

Also, have you made any progress on making the frequency setting more dynamic?

Im still struggling with getting this STB to respond to anything I send it, but im not quite ready to give up yet.

Also, does the varaible "TRAMITTER_FREQ" apply to all sent codes? sendGC for example?

piotrC4 commented 7 years ago

Yes you should replace 38 with TRANSMITTER_FREQ. I'll we be able to make more progres after Sunday. Now I'm almost totaly unavailable. TRANSMITTER_FREQ apply only for send methods which have such option (like raw) sendGC don't have such parameters.

travplan commented 7 years ago

@enc-X No problem. I appreciate everything you've helped with so far.

piotrC4 commented 7 years ago

In last update I introduced passing frequency in raw mode - just add to raw sequence frequency in kHz. For example if raw sequence is "37,56,...,43,12" and frequency is 38kHz you should send as message "37,56,...,43,12,38".