When the day started, it seemed like it would be an easy task to get the transmission working on the tagger. Often, combining two pieces of code is a matter of where to place them and when to activate them. I found this wasn't the case here and it became a long day.
Example code in Ken Shirriff's infrared remote library placed the code for sending remote signals into a different example than the code for receiving signals. Combining them caused the reception portion to stop working and the transmission didn't work to begin with.
At first, it seemed that the transmission needed to be separated from the reception but other people reported success in forum posts. Then it seemed that the problem was the microcontroller. Most people in the forums were using ATMega328 controllers but I was using an ATMega32U4 controller.
The solution finally came after reading deeply into some of the posts and discovering that it was necessary to change some of Ken Shirriff's code. In the "Arduino-IRremote-Master" directory I changed line 87 and line 89 of the boardsdef.h file. Line 89 was commented out and line 87 was uncommented. This had the effect of changing the transmission pin, previously 3, to pin 9.
The picture below shows the current state of my boardsdef.h header file. This was only necessary because I was using an Arduino Micro with a 32U4 controller.
Transmission was finally taking place. A resistor was also added to the IRLED to keep it from receiving too much power. Transmissions can be seen in the animation below. Each blip of the LED is a burst of 8 bits plus any header and parity provided by the IR library.
Another vital piece of code was found which kept the code from receiving after a transmission. The line was posted by Ken Shirriff himself in a forum. Once it was added there were no more issues with sending or receiving.
A second computer had been running an older version of the code which simply printed all the signal it received during the evening. This was periodically receiving signals from the handheld remote and the newest code which was transmitting the HEX code with the Sony protocol which was right out of the IRSendDemo example code.
Downloads:
The rest of the posts for this project have been arranged by date
First time here?
Completed projects from year 1
Completed projects from year 2
Completed projects from year 3
Disclaimer for http://24hourengineer.blogspot.com/ and 24hourengineer.com
This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.
All information in this blog, or linked by this blog, are not to be taken as advice or solicitation. Anyone attempting to replicate, in whole or in part, is responsible for the outcome and procedure. Any loss of functionality, money, property or similar, is the responsibility of those involved in the replication.
All digital communication regarding the email address 24hourengineer@gmail.com becomes the intellectual property of Brian McEvoy. Any information contained within these messages may be distributed or retained at the discretion of Brian McEvoy. Any email sent to this address, or any email account owned by Brian McEvoy, cannot be used to claim property or assets.
Comments to the blog may be utilized or erased at the discretion of the owner. No one posting may claim property or assets based on a post.
This blog, including pictures and text, is copyright to Brian McEvoy.
2017-04-03 (M)
Example code in Ken Shirriff's infrared remote library placed the code for sending remote signals into a different example than the code for receiving signals. Combining them caused the reception portion to stop working and the transmission didn't work to begin with.
At first, it seemed that the transmission needed to be separated from the reception but other people reported success in forum posts. Then it seemed that the problem was the microcontroller. Most people in the forums were using ATMega328 controllers but I was using an ATMega32U4 controller.
The solution finally came after reading deeply into some of the posts and discovering that it was necessary to change some of Ken Shirriff's code. In the "Arduino-IRremote-Master" directory I changed line 87 and line 89 of the boardsdef.h file. Line 89 was commented out and line 87 was uncommented. This had the effect of changing the transmission pin, previously 3, to pin 9.
The picture below shows the current state of my boardsdef.h header file. This was only necessary because I was using an Arduino Micro with a 32U4 controller.
boardsdef.h file. Pay attention to lines 87 and 89
Transmission was finally taking place. A resistor was also added to the IRLED to keep it from receiving too much power. Transmissions can be seen in the animation below. Each blip of the LED is a burst of 8 bits plus any header and parity provided by the IR library.
Transmitting IRLED
Another vital piece of code was found which kept the code from receiving after a transmission. The line was posted by Ken Shirriff himself in a forum. Once it was added there were no more issues with sending or receiving.
A second computer had been running an older version of the code which simply printed all the signal it received during the evening. This was periodically receiving signals from the handheld remote and the newest code which was transmitting the HEX code with the Sony protocol which was right out of the IRSendDemo example code.
Evening's receptions
Downloads:
The rest of the posts for this project have been arranged by date
First time here?
Completed projects from year 1
Completed projects from year 2
Completed projects from year 3
Disclaimer for http://24hourengineer.blogspot.com/ and 24hourengineer.com
This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.
All information in this blog, or linked by this blog, are not to be taken as advice or solicitation. Anyone attempting to replicate, in whole or in part, is responsible for the outcome and procedure. Any loss of functionality, money, property or similar, is the responsibility of those involved in the replication.
All digital communication regarding the email address 24hourengineer@gmail.com becomes the intellectual property of Brian McEvoy. Any information contained within these messages may be distributed or retained at the discretion of Brian McEvoy. Any email sent to this address, or any email account owned by Brian McEvoy, cannot be used to claim property or assets.
Comments to the blog may be utilized or erased at the discretion of the owner. No one posting may claim property or assets based on a post.
This blog, including pictures and text, is copyright to Brian McEvoy.
2017-04-03 (M)
Comments
Post a Comment