Arduino software was being written for a couple days. Fortunately, since the automation will take place in the computer, the firmware was pretty simple. Getting information to and from a computer via a USB cable is relatively easy but transmitting data over infrared isn't so straight-forward.
Two Arduinos with identical programming were placed across the room from one another. One was connected to a Windows machine running Arduino while the other was a RPi 0 with Putty.
Troubleshooting the data transmission of data finally yielded usable results so the first revision of the firmware is available for download. As of writing this, the revision is 0.0.5
The most perplexing case in the troubleshooting was a bizarre case where one byte was automatically decremented if the next byte was too large. This was noticed by chance and took an hour to track down. Obviously, there was something wrong when data came out too low but the cause required investigation. When the problem first appeared, the transmitted data was the highest possible value, 255 255 255 255 but the received value was 255 254 255 255. The only clue was that this happened when the values were high because transmitting 0 0 0 0 worked well.
Numerous transmission were made to discover that the byte was automatically lowered, for reasons unknown, when the following byte exceeded 127. An if statement had to be written for his one peculiar case but that sort of thing may be a mystery for a long time.
Each time I thought the firmware was finished I would update the revision. The first time I called it 0.0.1. When I saw that it wasn't satisfactory, I immediately rev'd it to 0.0.2. When I thought that was good it was rev'd to 0.0.3. Again back to an even number when things were clearly wrong, 0.04 and finally, today, 0.0.5. I'm certain there will need to be more changes in the future and until that point, it will never be considered 1.0. The most recent version is available below.
A list was made of the data swapped between the tagger and computer.
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-11 (Tu)
Two Arduinos with identical programming were placed across the room from one another. One was connected to a Windows machine running Arduino while the other was a RPi 0 with Putty.
Troubleshooting the data transmission of data finally yielded usable results so the first revision of the firmware is available for download. As of writing this, the revision is 0.0.5
Arduino propped up in the office
The most perplexing case in the troubleshooting was a bizarre case where one byte was automatically decremented if the next byte was too large. This was noticed by chance and took an hour to track down. Obviously, there was something wrong when data came out too low but the cause required investigation. When the problem first appeared, the transmitted data was the highest possible value, 255 255 255 255 but the received value was 255 254 255 255. The only clue was that this happened when the values were high because transmitting 0 0 0 0 worked well.
Numerous transmission were made to discover that the byte was automatically lowered, for reasons unknown, when the following byte exceeded 127. An if statement had to be written for his one peculiar case but that sort of thing may be a mystery for a long time.
Seriously‽
Each time I thought the firmware was finished I would update the revision. The first time I called it 0.0.1. When I saw that it wasn't satisfactory, I immediately rev'd it to 0.0.2. When I thought that was good it was rev'd to 0.0.3. Again back to an even number when things were clearly wrong, 0.04 and finally, today, 0.0.5. I'm certain there will need to be more changes in the future and until that point, it will never be considered 1.0. The most recent version is available below.
Screenshot of code, data window, and Device Manager
A list was made of the data swapped between the tagger and computer.
STUFF you can send TO the tagger from your computer0 0 <0-255> <0-255 > <0-255 > <0-255 >// This will transmit the four bytes over infrared one time. There are spaces between each byte and the two Zeros in front.
1 0 <0-255 > <0-255 > <0-255 > <0-255 > <0-255 > <0-255 > <0-255 > <0-255 > <0-255 > <0-255 > <0-255 > <0-255 >// Each bye here represents one of the LEDs on the ring. The color is a number from 0 to 255.// 000 - OFF. For convenience's sake// 001 - Red// 063 - Green// 127 - Blue// 191 - Back to red// 192 - Anything higher than 191 is a varying intensity of white.
1 1 <0-255 >// This time a single byte is used to change the rest of the LEDs.
2 0// Toggle the laser output. This is on pin A3
2 1// Toggle the flashlight output. This is on pin 10
3// This requests a reading from the analog inputs on the Arduino.
STUFF you can receive FROM the tagger########// A string of 8 HEX characters is an indication that some infrared signal has been received// There are no spaces in this string.
# # #// Three decimal values, each from 0-1023. These are the analog values.// There are spaces between each value.// This is received by a request (3) or an infrared remote signal.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #### ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##// This mess is the operatorArray, which is the information contained in the last// transmission from the computer. It is sent by the tagger when requested by an// infrared remote.
49// The trigger switch has been depressed.
50// The trigger switch has been released.
51// The reload switch has been depressed.
52// The reload switch has been released.
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-11 (Tu)
Comments
Post a Comment