Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sendJVC() freezes on sending Power command (0xC5E8) #400

Closed
schelm87 opened this issue Jan 25, 2018 · 3 comments
Closed

sendJVC() freezes on sending Power command (0xC5E8) #400

schelm87 opened this issue Jan 25, 2018 · 3 comments
Assignees
Labels

Comments

@schelm87
Copy link

Version/revison of the library used

"version": "2.3.1",

Expected behavior

  • recorded PowerONOFF Command of my JVC Receiver ( 0xC5E8 )
  • send 0xC5E8 via irsend.sendJVC(JVCPower, 16, 1);
  • code stopps working (see below)

For verification, I tried another key press (Sleep) - which was recorded as 0xC5C0.
This works fine. Command was done correctly by my device.

Code

//sleep Button pressed...
	//code received...
	//	Timestamp : 000011.600
	//	Encoding : JVC
	//	Code : C5C0(16 bits)

//Power Button pressed
	//code received...
	//	Timestamp : 000014.601
	//	Encoding : JVC
	//	Code : C5E8(16 bits)


#define JVCPower          0xC5E8 //doesn't work...
#define JVCSleep			  0xC5C0  //works fine
	Serial.println("send sleep...");

	irsend.sendJVC(JVCSleep, 16, 1);
	Serial.println("1...");
	delay(100); 
	Serial.println("send power...");
	irsend.sendJVC(JVCPower, 16, 1); 
	Serial.println("3...");
	delay(100);
	Serial.println("4...");

//SERIAL OUTPUT: 
//	send sleep...
//	1...
//	send power...
// <NO FURTHER OUTPUT AFTER THAT>

The ordering of sending those two commands does not have any effect - JVCPower always stops the code working, regardless if send first or second.

@crankyoldgit crankyoldgit self-assigned this Jan 25, 2018
crankyoldgit added a commit that referenced this issue Jan 25, 2018
Since `sendJVC()` was updated to use `sendGeneric()` it has produced a double
minimum gap at the end of each message, instead of a single one.
This wasn't picked up by our unit-testing.
This tickled a situation where an integer underflow happened when calculating
the required `space()` length, which would cause a delay of approx 1h20m.
Refactored code to eliminate this problem, and a potential similar case
in `sendWhynter()` too.

This is a derivative of the bug/issue #381

This instance was reported in #400, which this patch should fix.
@crankyoldgit
Copy link
Owner

Thanks for the detailed report. Yep, that's a bug alright. Sorry it affected you.
Can you please try the fix in this branch https://github.com/markszabo/IRremoteESP8266/tree/issue-400 and let me know if that fixes it for you or not?

crankyoldgit added a commit that referenced this issue Jan 26, 2018
Since `sendJVC()` was updated to use `sendGeneric()` it has produced a double
minimum gap at the end of each message, instead of a single one.
This wasn't picked up by our unit-testing.
This tickled a situation where an integer underflow happened when calculating
the required `space()` length, which would cause a delay of approx 1h20m.
Refactored code to eliminate this problem, and a potential similar case
in `sendWhynter()` too.

This is a derivative of the bug/issue #381

This instance was reported in #400, which this patch should fix.
@schelm87
Copy link
Author

Hi,
thanks for your very quick fix.
3382348 works perfect for 0xc5e8 and still works for 0xc5c0.

Just for clearification:
the Sample "JVCPanasonicSendDemo" also works well now.

It could be simplified (at least with my device) by removing the second send command and adding a repeat to the first.

  irsend.sendJVC(JVCPower, 16, 1);  // hex value, 16 bits, **REPEAT**
  // see http://www.sbprojects.com/knowledge/ir/jvc.php for information
  //delayMicroseconds(50);
  //irsend.sendJVC(JVCPower, 16, 1);  // hex value, 16 bits, repeat
  //delayMicroseconds(50);

@crankyoldgit
Copy link
Owner

crankyoldgit commented Jan 26, 2018

FYI, I've just released v2.3.2 of the library which contains this fix. If you are using the Arduino IDE, it should be available via the Library Manager in less than 24 hours.

crankyoldgit added a commit that referenced this issue Jan 27, 2018
This commit is 98% housekeeping. The only user-facing changes are in ir_LG.cpp.
These changes should hopefully eliminate or highlight the symptoms & causes
of some recent bugs. e.g. #400

Overview:
* Add support for pseudo-tracking the passage of transmition time in the tests.
  This has the affect of making the messages produced in the unit tests much
  more similar to real-world message timings. Notably, the end of a
  message space()/gap is now a realistic size.
* Update all the message timings in the existing unit-tests to reflect this.
* Remove redundant "#include <IRtimer.h>" lines.
* Fix typo(s) in Unit Tests named "SendUnusualSize".

User facing changes:
* Remove an ugly hack in the LG protocol related to gap timing. (yay!)
* Add a check for the correct min message size when decoding LG32 messages.
crankyoldgit added a commit that referenced this issue Jan 28, 2018
This commit is 98% housekeeping. The only user-facing changes are in ir_LG.cpp.
These changes should hopefully eliminate or highlight the symptoms & causes
of some recent bugs. e.g. #400

Overview:
* Add support for pseudo-tracking the passage of transmition time in the tests.
  This has the affect of making the messages produced in the unit tests much
  more similar to real-world message timings. Notably, the end of a
  message space()/gap is now a realistic size.
* Update all the message timings in the existing unit-tests to reflect this.
* Remove redundant "#include <IRtimer.h>" lines.
* Fix typo(s) in Unit Tests named "SendUnusualSize".

User facing changes:
* Remove an ugly hack in the LG protocol related to gap timing. (yay!)
* Add a check for the correct min message size when decoding LG32 messages.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants