Stubborn 4th Byte in 3-digit Coordinates, & Furious Red LED - Joy Stick Machinations
BrainStrain
Posts: 30
After declaring success in figuring out where the X,Y coordinate Joy Stick values were stored in MCP3202_Demo.spin, I was immediately confronted with a number problem I could not figure out. That is to say, after of mucking around until the wee hours, I didn't even have a good idea of what to try next or where to continue looking.
The problem is that the X,Y coordinate values I am getting from the Joy Stick refuse to drop below 1,000 on the X or Y axis. The value of coordinates generated by the Joy Stick through the LTC1298 analog-to-digital converter (a 3202 chip) range from 0 - 4095 for both X and Y. The values generated by MCP3202_Demo.spin are stored in LONG variables named CH0 and CH1, named for channels 0 (X) and 1 (Y) of the DAC chip. The values running through CH0 and CH1 ran the full range of 0 - 4095. That was excellent. But, when I duplicated the code that created CH0 and CH1 into variables I stored as Xval and Yval, the values would not drop below 1000.
The values for Xval and Yval were only good as long as they were >= 1,000. All values that should have run from 0 - 999, a drop from a 4-digit number to a 3-digit number, resulted in the code adding an inconsistent fourth digit. So, for example, if the real CH0 X or CH1 Y coordinate was 999, the Xval value showed 9990, or 9996, or 9993, etc., for the whole range of coordinates < 1,000. The code was filling in an inconsistent 4th digit when the numbers should have been only 3 digits; not acceptable.
If anyone knows the solution to copying or generating duplicate values for CH0 and CH1 that won't stubbornly stick with 4 digits, I would greatly appreciate the help.
A second issue, which has existed since I first fired up MCP3202_Demo.spin, is that the red LED between the power plug and USB connection on my Propeller Proto USB board blinks furiously whenever the USB cable is plugged in and the terminal window is enabled. I think I have boiled this issue down to the generation of the CH0 and CH1 variables. When the Demo code is generating an average of 100 values before storing the results in CH0 and CH1, the red light just goes nuts. When I changed the Demo code to averaging 400 values before it updated the CH0 and CH1 variables, the red light flashed noticeably more slowly.
Again, help getting the red LED to turn off would be great.
Thanks!
BrainStrain
The problem is that the X,Y coordinate values I am getting from the Joy Stick refuse to drop below 1,000 on the X or Y axis. The value of coordinates generated by the Joy Stick through the LTC1298 analog-to-digital converter (a 3202 chip) range from 0 - 4095 for both X and Y. The values generated by MCP3202_Demo.spin are stored in LONG variables named CH0 and CH1, named for channels 0 (X) and 1 (Y) of the DAC chip. The values running through CH0 and CH1 ran the full range of 0 - 4095. That was excellent. But, when I duplicated the code that created CH0 and CH1 into variables I stored as Xval and Yval, the values would not drop below 1000.
The values for Xval and Yval were only good as long as they were >= 1,000. All values that should have run from 0 - 999, a drop from a 4-digit number to a 3-digit number, resulted in the code adding an inconsistent fourth digit. So, for example, if the real CH0 X or CH1 Y coordinate was 999, the Xval value showed 9990, or 9996, or 9993, etc., for the whole range of coordinates < 1,000. The code was filling in an inconsistent 4th digit when the numbers should have been only 3 digits; not acceptable.
If anyone knows the solution to copying or generating duplicate values for CH0 and CH1 that won't stubbornly stick with 4 digits, I would greatly appreciate the help.
A second issue, which has existed since I first fired up MCP3202_Demo.spin, is that the red LED between the power plug and USB connection on my Propeller Proto USB board blinks furiously whenever the USB cable is plugged in and the terminal window is enabled. I think I have boiled this issue down to the generation of the CH0 and CH1 variables. When the Demo code is generating an average of 100 values before storing the results in CH0 and CH1, the red light just goes nuts. When I changed the Demo code to averaging 400 values before it updated the CH0 and CH1 variables, the red light flashed noticeably more slowly.
Again, help getting the red LED to turn off would be great.
Thanks!
BrainStrain
Comments
The 4th digit problem was solved by adding a Serial Terminal command on the line following the code line that generated the number. For example:
serial.dec(Xval)
serial.ClearEndOfLine
It had seemed to me that commands like ClearEndOfLine and CarriageReturn were text formatting commands. I was quite wrong.
The residual characters are not limited to lines with numerical values. Lines with text also are prone to having residual data tacked on to the ends.