Open Vrushabhgada opened 1 year ago
So this is for a bluestar AC unit? Do you have the exact model of both remote and unit as well?
@Vrushabhgada Please provide a link to your github branch with all of the changes you've made. What you've provided so far is an incomplete picture.
Also, auto_analyse_raw_data.py
would have warned you that the protocol is using more than 64bits, and as such, couldn't use the <= 64 bit versions of the generic code it generated.
e.g.
// DANGER: More than 64 bits detected. A uint64_t for 'data' won't work!
&
// Alternative >64bit function to send TBD messages
It reported that:
Total Nr. of suspected bits: 112
Which is larger than 64bit, so it can't be stored in a uint64_t
. It needs to be stored in a uint8_t[14]
. i.e. A 14 byte array.
Please refer the below github repo https://github.com/Vrushabhgada/IRBlueStartProtocol
Also I didn't got any warning
That's because you didn't follow the instructions correctly in [Adding support for a new IR protocol](Adding support for a new IR protocol). i.e. See the comment "... If you use the -g -n TestExample
arguments to the program, ..."
I'll take a look at your repo shortly.
Please refer the below github repo https://github.com/Vrushabhgada/IRBlueStartProtocol
FYI, it is best to fork the repo, rather than create/upload a new one. That way I people can easily track & see what changes you've made, and you can more easily merge changes back into the original fork too.
After a very quick look, I am sure your first problem is as I said before, you're using the wrong sort of decode routine structure etc for the bit size of the message. The -g
option while generating code, will warn you about that.
I suggest you look at the MITSUBISHI112
code for some pointers.
https://github.com/crankyoldgit/IRremoteESP8266/blob/2bfdf9719250471f004b720e81c14ab00a244836/src/ir_Mitsubishi.cpp#L1252-L1357
or MitsubishiHeavy's decode:
https://github.com/crankyoldgit/IRremoteESP8266/blob/2bfdf9719250471f004b720e81c14ab00a244836/src/ir_MitsubishiHeavy.cpp#L993-L1050
or decodeCarrierAC64()
, which is a bit simpler/cleaner:
https://github.com/crankyoldgit/IRremoteESP8266/blob/2bfdf9719250471f004b720e81c14ab00a244836/src/ir_Carrier.cpp#L205-L240
Ok. Thanks for the help will follow the suggested instruction and let you know .
how can i create library which use any state data for send method for example sendxyz(uint8_t state[],length,repaet) ...help me
i have state[14] data but it use for particular protocol and it for send--model this type so i made sendxyz method for any state data
Version/revision of the library used v2.8.6
Describe the bug
I had followed the steps provided in Adding support for a new IR protocol to added new ac protocol It showed as UNKNOWN Protocol even after following all the steps On debugging came to know following condition is failing present in IRrecv.cpp->_matchGeneric under if (use_bits) condition `if (!result.success)
I couldn't understand what is the exact working of IRrecv::matchData and IRrecv::_matchGeneric function
To Reproduce
data.txt
Please refer to the data.txt file containing the raw values of remote and following is the output of the auto_analyse_raw_data.py file
`Found 227 timing entries. Potential Mark Candidates: [3402, 656] Potential Space Candidates: [1334, 1008, 300]
Guessing encoding type: Looks like it uses space encoding. Yay!
Guessing key value: kHdrMark = 3402 kHdrSpace = 1334 kBitMark = 600 kOneSpace = 1001 kZeroSpace = 273
Decoding protocol based on analysis so far:
kHdrMark+kHdrSpace+1110101000110010000010100000000000000000001001001100010011100000000111000000000000000000000000000000000010011110 Bits: 112 Hex: 0xEA320A000024C4E01C000000009E (MSB first) 0x7900000000380723240000504C57 (LSB first) Dec: 4750048350230980578690287332753566 (MSB first) 2454171562042885653260110014729303 (LSB first) Bin: 0b1110101000110010000010100000000000000000001001001100010011100000000111000000000000000000000000000000000010011110 (MSB first) 0b0111100100000000000000000000000000000000001110000000011100100011001001000000000000000000010100000100110001010111 (LSB first)
Total Nr. of suspected bits: 112`
Please refer to the attached file which i have created for new protocol `// Copyright 2023 Vrushabh Gada /// @file /// @brief Support for BlueStar A/C protocols.
// Supports: // Brand: BlueStar
include
include "IRrecv.h"
include "IRsend.h"
include "IRutils.h"
// Constants const uint16_t kBluestarTick = 500; const uint16_t kBluestarHdrMark = 3400; const uint16_t kBluestarHdrSpace = 1334; const uint16_t kBluestarBitMark = 600; const uint16_t kBluestarOneSpace = 1000; const uint16_t kBluestarZeroSpace = kBluestarBitMark; const uint16_t kBluestarMinGap = 40000;
if SEND_BLUESTAR
/// Send a Bluestar Toilet formatted message. /// Status: STABLE / Working. /// @param[in] data The message to be sent. /// @param[in] nbits The number of bits of message to be sent. /// @param[in] repeat The number of times the command is to be repeated. /// @see https://github.com/crankyoldgit/IRremoteESP8266/issues/706 void IRsend::sendBluestar(const uint64_t data, const uint16_t nbits, const uint16_t repeat) { sendGeneric(kBluestarHdrMark, kBluestarHdrSpace, kBluestarBitMark, kBluestarOneSpace, kBluestarBitMark, kBluestarZeroSpace, kBluestarBitMark, kBluestarMinGap, data, nbits, 38, true, repeat, kDutyDefault); }
endif // SEND_BLUESTAR
if DECODE_BLUESTAR
/// Decode the supplied Bluestar Toilet message. /// Status: Stable / Known working. /// @param[in,out] results Ptr to the data to decode & where to store the result /// @param[in] offset The starting index to use when attempting to decode the /// raw data. Typically/Defaults to kStartOffset. /// @param[in] nbits The number of data bits to expect. /// @param[in] strict Flag indicating if we should perform strict matching. /// @return True if it can decode it, false if it can't. /// @see https://github.com/crankyoldgit/IRremoteESP8266/issues/706 bool IRrecv::decodeBluestar(decode_results *results, uint16_t offset, const uint16_t nbits, const bool strict) { if (strict && nbits != kBluestarBits) return false; // We expect Bluestar to be a certain sized message.
uint64_t data = 0;
// Match Header + Data + Footer if (!matchGeneric(results->rawbuf + offset, &data, results->rawlen - offset, nbits, kBluestarHdrMark, kBluestarHdrSpace, kBluestarBitMark, kBluestarOneSpace, kBluestarBitMark, kBluestarZeroSpace, kBluestarBitMark, kBluestarMinGap, true)) return false; // Success results->bits = nbits; results->value = data; results->decode_type = decode_type_t::BLUESTAR; results->command = 0; results->address = 0; return true; }
endif // DECODE_BLUESTAR
`
Expected behaviour
it should have identity the signal as BLUESTAR protocol
Output of raw data from IRrecvDumpV2.ino or V3 (if applicable)
uint16_t rawData[227] = {3408, 1332, 602, 1008, 604, 1006, 606, 1002, 610, 262, 608, 1002, 600, 300, 582, 1000, 600, 272, 610, 262, 608, 266, 606, 1004, 608, 1000, 600, 272, 610, 264, 606, 1002, 610, 264, 606, 266, 606, 294, 576, 266, 604, 268, 600, 1010, 604, 268, 600, 1008, 604, 268, 602, 272, 600, 298, 582, 292, 580, 266, 606, 266, 602, 270, 602, 296, 574, 274, 608, 262, 610, 262, 606, 268, 602, 296, 576, 268, 600, 272, 610, 264, 604, 264, 608, 292, 578, 268, 602, 272, 600, 270, 610, 264, 606, 1002, 600, 302, 580, 292, 578, 1002, 612, 998, 602, 298, 574, 272, 608, 264, 608, 1000, 600, 274, 608, 262, 608, 1000, 610, 1000, 602, 1006, 606, 266, 604, 270, 600, 270, 610, 290, 580, 294, 578, 268, 602, 268, 602, 270, 600, 1008, 606, 1004, 608, 1000, 610, 264, 608, 262, 608, 264, 604, 294, 576, 298, 572, 272, 610, 262, 606, 264, 608, 294, 576, 294, 576, 270, 600, 272, 608, 266, 606, 292, 578, 266, 604, 268, 602, 272, 600, 298, 582, 292, 580, 266, 604, 268, 604, 268, 602, 296, 576, 298, 582, 262, 606, 264, 606, 268, 604, 296, 576, 296, 574, 270, 612, 262, 608, 264, 606, 268, 604, 268, 604, 1008, 602, 294, 576, 1006, 606, 266, 606, 1002, 608, 1002, 598, 1010, 602, 294, 574}; // UNKNOWN 501A1597
What brand/model IR demodulator are you using?
brand = BLUESTAR
I have followed the steps in the Troubleshooting Guide & read the FAQ
Yes.
Has this library/code previously worked as expected for you?
No