Looks like you've been working. Here's what I see from the pics.
1. You didn't say what the scope is hooked up to. Is it the voltage output from the 1st IR sensor?
2. Comparing the first two pics, it looks like the sensor has something in its range the whole time of the scan.
This is because the average voltage is higher in the second pic. Is it seeing you in the beam? OK if it is.
3. Your trigger seems to be set around 0.7 V, I would set it to around 1.5 V to eliminate the noise.
4. Along with setting the trigger higher, I would also change it from Continuous to Single shot mode.
It the trigger is right, then it should sit there until it sees the barbell and then spike.
5. If you can, increase the sample rate so you see a shorter period with greater detail.
6. You might also want to change from Auto to a Fixed voltage scale, say 0 to 5 V.
That way, all the pics will have the same reference scale.
1.) It is hooked to the output of sensor 1 voltage
2.) They have a steady .7v with nothing in front of them, it is in the GP2Y specs as well. I am not sure why. What I was trying to showing with the first 2 pics was that with only 1 sensor, it has a clean output. With multiple sensors shining the same way, it gets messier.
3.) I will make the trigger suggestions.
4.) I think the prop has the sensors pinned as being the weak link.
That was the intent from conception before 1 soaked up 800 of them. It doesn't work that way as we have developed more than 2 generations of this thing. Each time we add sensors it adds some sort of distortion at sensor idle feedback. If you note one of the pics had a nice smooth line to follow. The distortion grows in amplitude and seems unpredictable.
Now that we finally have a high speed machine (propeller chip) I am able to put these sensors to the test. It hasn't gotten much better with detection. The small object whizzing by doesn't help either. But that is the challenge.
The best detection from 6 years of playing with this is through-beam technology. I haven't seen a diffuse sensor that scans this far and this precise for the money as the Sharp Gp2Y. I still need to bring some things to life here for final analysis (i.e. your 74hc's) but just from these scope tests I am bummed out. Basically it misses the bb during high speed movements.
You should be able to display the voltage seen by the adc chip and compare this with the chart.
This should be more reliable than the scope setup you have.
I've used a very similar IR sensor with this adc. It gives reasonably good range results.
You should be able to see it in the little pic to the left, it's the scanning eye of the robot.
Just code a 100 ms loop to update the voltage display at the same place on the screen.
It sounds like something isn't set up quite right. Once you see the voltage, you should
be able to tell what's going on.
Let me know if you need help with the display code.
That is what I was getting at. If there is more than 1 it seems to throw garbage ito the other sensors at idle. I am not sure why, but with just 1 sensor it is perfect. More than 1 make some sort of distortion.
I made the 100ms loop to pc terminal. What do you want me to look for. It just seems the update is slower now and doesn't update as fast.
1. How often are you sampling each port of the 3-MCP3208's?
Maybe you could post the code used to generate the display.
2. What are the target conditions for the 24 IR sensors.
I.e. Is the barbell in front of sensors 0 thru 3, are you standing farther away in front of all of the sensors?
What I need to know is what each sensor SHOULD be seeing, to correlate the adc voltages.
Remember, each target should be at least a meter from the sensor.
3. The middle sensors (channels 8 thru 15) seem to have reasonable values.
The first and third MCP3208's (channels 0 thru 7 and 16 thru 23) seem to have strange values.
The very low and very high values don't look right. Check the wiring of these strange ones.
How about posting the code you use to generate the values, along with a photo of the test setup.
Make sure you use the code directive before and after the code, to make it easier to read.
You have to be very careful with the indenting within repeat loops.
In this code:
b := 0
repeat
repeat while chipnumb <4
b :=0
repeat while b <8
You don't need the first two lines, since the second repeat loop repeats forever.
Also, the way you're doing the test, you should replace the lines
repeat while chipnumb <4
b :=0
with just:
repeat
b :=0
Notice a couple of things here. The b := 0 needs to be indented two spaces, not one.
Also, the value of chipnumb is not defined before this repeat and is not needed here.
Finally, the line:
r := adc.in((b - 15),chipnumb) ' 87us
should be:
r := adc.in((b - 16),chipnumb) ' 87us
Since the first value of b is 16 for this loop.
Even with these little changes, I don't think we've accounted for the strange numbers seen
in the first and third MCP3208 chips. The voltage returned should always be between 500 and 3000 mv,
according to the range response curve I posted above.
Check the wires and let me know when you get a test case setup with values.
'' ******************************************************************************
'' * "HC595.spin" 74HC595 SPIN Object *
'' * coded by Jim -- 12/31/08 -- Happy New Year! *
'' * Version 1.0 *
'' ******************************************************************************
''
'' Calling sequence
'' OBJ
'' SReg : "HC595"
''
'' code segment
'' SReg.InitSer595 ' to initialize driver
'' more code
'' DataByte := toSend ' set up data to send to chip
'' SReg.WriteSer595(DataByte) ' send data to chip
'' more code
''
CON
_PinHigh = 1
_PinLow = 0
CLK = 16 ' pin number of CLK pin on chip (AKA SCK)
SER = 17 ' pin number of SER pin on chip
CLR = 18 ' pin number of SCLR pin on chip
RCK = 19 ' pin number of RCK pin on chip
GPN = 20 ' pin number of G pin on chip
VAR
long bitout, databyte
PUB InitSer595 ' initialize 74HC595 for startup
' set the control lines as outputs
dira[noparse][[/noparse]CLK] ~~
dira[noparse][[/noparse]SER] ~~
dira[noparse][[/noparse]CLR] ~~
dira[noparse][[/noparse]RCK] ~~
dira[noparse][[/noparse]GPN] ~~
outa[noparse][[/noparse]CLK] := _PinLow ' init main clock line to low
outa[noparse][[/noparse]RCK] := _PinLow ' init latch clock line to low
outa[noparse][[/noparse]GPN] := _PinHigh ' set outputs to 3-state
outa[noparse][[/noparse]CLR] := _PinLow ' set to clear register on chip
outa[noparse][[/noparse]GPN] := _PinLow ' turn on the chip and clear pins
outa[noparse][[/noparse]CLR] := _PinHigh ' return CLR pin to high after clear
PUB WriteSer595(Data) ' Data is long with 8 bits of data in bits 7 - 0
' Write 8 bits of data. Data byte is output MSB first.
databyte := Data ' transfer to working storage
repeat 24 ' shift out 8 bits
bitout := databyte & %1000_0000_0000_0000_0000_0000 ' take hi bit from byte -> bitout bit 7
bitout >>= 23 ' shift to bit zero for output
databyte <<= 1 ' shift data left 1 bit for next loop
outa[noparse][[/noparse]SER] := bitout ' shift out high bit to serial pin (0 or 1)
outa[noparse][[/noparse]CLK] := _PinHigh ' toggle the clock pin to shift bit out
outa[noparse][[/noparse]CLK] := _PinLow ' high then low to cycle the clock
outa[noparse][[/noparse]RCK] := _PinHigh ' toggle the RCK pin to latch the output
outa[noparse][[/noparse]RCK] := _PinLow ' high then low to cycle the clock
I've posted the MCP3208 multi-chip support driver to the Object Exchange, "MCP3208_fast_multi".
This driver supports up to 24 ADC channels using up to three MCP3208 ADC 8-port 12-bit chips.
danthony has been testing it using 24 IR range sensors, and it seems to be working fine.
The calling sequence is different than the original driver, due to the multi-chip support.
Here are the main entry points:
PUB start(dpin1, cpin1, spin1, dpin2, cpin2, spin2, dpin3, cpin3, spin3) : okay
'' Start driver - starts a cog
'' returns false if no cog available
'' may be called again to change settings
''
'' dpin = pin connected to both DIN and DOUT on MCP3208
'' cpin = pin connected to CLK on MCP3208
'' spin = pin connected to CS on MCP3208
'' dpin1 = dpin for 1st MCP3208, etc.
PUB in(channel, chip)
'' Read the current sample from an ADC channel (0..7)
'' Chip number 1, 2 or 3
PUB average(channel, chip, n)
'' Average n samples from an ADC channel (0..7), n <= 16
'' Chip number 1, 2 or 3
Did you locate the source of the intereference? Could it be the illumination from the other 23 IR emitters, bouncing off the round barbell, could be the source of the noise? This could be checked by fixing the barbell in position, monitoring the single closest channel while covering up a range of the other 23 sensors?
I'm using the MCP3304 in an 4 channel application (works well) and am about to test the same sharp sensor for a silo level monitoring application. No plans yet for multiple sensors, but knowing how these things tend to evolve... so thanks for blazing the trail.
And many thanks Jim for the driver
I second that thanks to Jim for the driver. The interference happens without anything in front of the sensors at all. The sensors are packed so close tight it could be related. However it works pretty good.
Comments
example: adc.in(1,0)
It is producing data that coincides with the sensor but just making sure....
basically in the .in··· right?
val := adc.in(chan, chipnum) ' get single adc value
Jim
7 segment leds and knight rider scroll....
pic attached
Latest data.....
Don
Looks like you've been working. Here's what I see from the pics.
1. You didn't say what the scope is hooked up to. Is it the voltage output from the 1st IR sensor?
2. Comparing the first two pics, it looks like the sensor has something in its range the whole time of the scan.
This is because the average voltage is higher in the second pic. Is it seeing you in the beam? OK if it is.
3. Your trigger seems to be set around 0.7 V, I would set it to around 1.5 V to eliminate the noise.
4. Along with setting the trigger higher, I would also change it from Continuous to Single shot mode.
It the trigger is right, then it should sit there until it sees the barbell and then spike.
5. If you can, increase the sample rate so you see a shorter period with greater detail.
6. You might also want to change from Auto to a Fixed voltage scale, say 0 to 5 V.
That way, all the pics will have the same reference scale.
Let me know if you have more questions.
Jim
1.) It is hooked to the output of sensor 1 voltage
2.) They have a steady .7v with nothing in front of them, it is in the GP2Y specs as well. I am not sure why. What I was trying to showing with the first 2 pics was that with only 1 sensor, it has a clean output. With multiple sensors shining the same way, it gets messier.
3.) I will make the trigger suggestions.
4.) I think the prop has the sensors pinned as being the weak link.
I'll be back....
The reason for moving the trigger to 1.5 V and setting it to single shot mode was to make it see nothing until the signal was greater than 1.5 V.
This way you'll see the signal on the scope only when the barbell is lifted into its beam.
Anything else will be too far away (voltage too low) to trigger the scope.
Jim
I attached the voltage response curve for the IR sensor you're using.
It looks like the barbell should be between 1 and 2 meters from the sensor.
And everything else more than 2 meters from it.
Then if you ignore all adc readings less than 1.5 V, it should have no problem seeing the barbell.
You can choose a different voltage, such as 2.0 V if the barbell is about 1 meter from the sensor.
I think you should have no problem with the sensor you're using.
Jim
That was the intent from conception before 1 soaked up 800 of them. It doesn't work that way as we have developed more than 2 generations of this thing. Each time we add sensors it adds some sort of distortion at sensor idle feedback. If you note one of the pics had a nice smooth line to follow. The distortion grows in amplitude and seems unpredictable.
Now that we finally have a high speed machine (propeller chip) I am able to put these sensors to the test. It hasn't gotten much better with detection. The small object whizzing by doesn't help either. But that is the challenge.
The best detection from 6 years of playing with this is through-beam technology. I haven't seen a diffuse sensor that scans this far and this precise for the money as the Sharp Gp2Y. I still need to bring some things to life here for final analysis (i.e. your 74hc's) but just from these scope tests I am bummed out. Basically it misses the bb during high speed movements.
Don
You should be able to display the voltage seen by the adc chip and compare this with the chart.
This should be more reliable than the scope setup you have.
I've used a very similar IR sensor with this adc. It gives reasonably good range results.
You should be able to see it in the little pic to the left, it's the scanning eye of the robot.
Just code a 100 ms loop to update the voltage display at the same place on the screen.
It sounds like something isn't set up quite right. Once you see the voltage, you should
be able to tell what's going on.
Let me know if you need help with the display code.
Jim
Did you have multiple eyes pointing in the same direction on your robot?
Don
No, in this case it's just the one eye on the post in back. It scans back and forth to see where it's going.
Jim
I made the 100ms loop to pc terminal. What do you want me to look for. It just seems the update is slower now and doesn't update as fast.
Let's use this thread for attachments only, unless someone else is interested[noparse]:)[/noparse]
I wish they'd fix the PM forum to allow attachments... Anyone listening?
Jim
Don
This is a good start.
I need to know what your test conditions are:
1. How often are you sampling each port of the 3-MCP3208's?
Maybe you could post the code used to generate the display.
2. What are the target conditions for the 24 IR sensors.
I.e. Is the barbell in front of sensors 0 thru 3, are you standing farther away in front of all of the sensors?
What I need to know is what each sensor SHOULD be seeing, to correlate the adc voltages.
Remember, each target should be at least a meter from the sensor.
3. The middle sensors (channels 8 thru 15) seem to have reasonable values.
The first and third MCP3208's (channels 0 thru 7 and 16 thru 23) seem to have strange values.
The very low and very high values don't look right. Check the wiring of these strange ones.
How about posting the code you use to generate the values, along with a photo of the test setup.
Make sure you use the code directive before and after the code, to make it easier to read.
Hang in there, you're getting close.
Jim
{ .} '' DonTest_multi -- 12/26/08 '' Used to test MCP3208_fast_multi with up to 3 MCP3208's attached to Prop CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 ' VGA and Keyboard info for vga.start BasePin = 16 ' base pin for video output (0, 8, 16, 24) - 16 on proto board kbd_dpin = 26 ' keyboard dpin number - pin 26 on proto board kbd_cpin = 27 ' keyboard cpin number - pin 27 on proto board kbd_lock = %0_001_000 ' keyboard locks: disable scroll lock key, NumLock, CapsLock, ScrollLock all off kbd_auto = %01_01000 ' keyboard auto repeat: 0.5 sec delay, 15 chars/sec repeat (?) kbdflag = 0 ' set this to 1 if a keyboard is connected/needed ' MCP3208 adc stuff dpin1 = 10 ' ADC data pin on Propeller cpin1 = 11 ' ADC clock pin on Propeller spin1 = 12 ' ADC Chip Select pin on Propeller dpin2 = 13 ' ADC data pin on Propeller cpin2 = 14 ' ADC clock pin on Propeller spin2 = 15 ' ADC Chip Select pin on Propeller dpin3 = 25 ' ADC data pin on Propeller cpin3 = 26 ' ADC clock pin on Propeller spin3 = 27 ' ADC Chip Select pin on Propeller 'chipnum = 1 ' chip number to test ' Don's conversion factor to get us from count us = 80 VAR long CS long DIO long CLK long txa, txb ,txc, txd ,txe, y0, x0 long scantime, admcp1[noparse][[/noparse]7], admcp2[noparse][[/noparse]7], admcp3[noparse][[/noparse]7] DAT ' Misc Values AOK byte "All COGs Started, ready to rock!", 0 OOPS byte "Oops, cog start failed...",0 ' Values for Test_adc routine ADCdisp byte "ADC", 0 VALdisp byte "val: ", 0 AVGdisp byte "avg of 10 samples: ", 0 CLKcycl byte "clk cycles: ", 0 OBJ '' Include VGA/Keyboard, MCP3208 ADC and Floating Point Objects adc : "MCP3208_fast_multi" debug : "FullDuplexSerialPlus" vp: "Conduit" SReg : "HC595mod2" 'vga: "VGA_1024" PUB Init | char, b, chipnumb, chip2cnt, chip3cnt, r debug.start(31,30,0,115200) debug.tx(Debug#CRSRX) 'indent debug.tx(3) '' start ADC chip MCP3208 if adc.start(dpin1, cpin1, spin1, dpin2, cpin2, spin2, dpin3, cpin3, spin3) waitcnt(clkfreq * 1 + cnt) 'wait 1 second for cog to start else debug.Str(String(" OOPS No COG " ,debug#CR)) debug.Str(String(" AOK COG Start Up " ,debug#CR)) SReg.InitSer595 ' to initialize driver SReg.writeSer595(%000000000000100000000000) ' set up data to send to chip waitcnt(clkfreq/100 + cnt) debug.Str(String("MCP 3208 Tests" ,debug#CR)) debug.tx(Debug#CRSRX) 'position the cursor on X (indent) debug.tx(10) debug.tx(Debug#CRSRY) 'position the cursor on Y (up and down) debug.tx(3) debug.Str(String("Sensor # Raw Value Sensor Voltage Set Point Number of Hits ", debug#CR)) waitcnt(clkfreq/100 + cnt) b := 0 repeat repeat while chipnumb <4 b :=0 repeat while b <8 chipnumb := 1 r := adc.in(b,Chipnumb) ' 87us debug.tx(Debug#CRSRX) debug.tx(14 ) debug.tx(Debug#CRSRY) debug.tx(5 + b) debug.dec(b++) debug.Str(string(" ")) debug.dec (r) debug.Str(string(" ")) debug.dec ((r*5000)/4096) debug.Str(string(" mv ",debug#CR)) repeat while b > 7 AND b < 16 chipnumb := 2 r := adc.in((b-8),chipnumb) ' 87us debug.tx(Debug#CRSRX) debug.tx(14 ) debug.tx(Debug#CRSRY) debug.tx(5 + b) debug.dec(b++) If b < 10 debug.Str(string(" ")) else debug.Str(string(" ")) debug.dec (r) debug.Str(string(" ")) debug.dec ((r*5000)/4096) debug.Str(string(" mv ",debug#CR)) repeat while b > 15 AND b < 24 chipnumb := 3 r := adc.in((b - 15),chipnumb) ' 87us debug.tx(Debug#CRSRX) debug.tx(14 ) debug.tx(Debug#CRSRY) debug.tx(5 + b) debug.dec(b++) debug.Str(string(" ")) debug.dec (r) debug.Str(string(" ")) debug.dec ((r*5000)/4096) debug.Str(string(" mv ",debug#CR)) waitcnt(clkfreq/5 + cnt) ' wait about 100 ms ' transfer the mcp data to global variables ' Test_adc repeat while TRUE ' loop forever to keep COGs running PUB Test_adc repeat txe := cnt ' init time for 24 reads admcp1[noparse][[/noparse]0] := adc.in(0,1) admcp1[noparse][[/noparse]1] := adc.in(1,1) admcp1[noparse][[/noparse]2] := adc.in(2,1) admcp1[noparse][[/noparse]3] := adc.in(3,1) admcp1[noparse][[/noparse]4] := adc.in(4,1) admcp1[noparse][[/noparse]5] := adc.in(5,1) admcp1[noparse][[/noparse]6] := adc.in(6,1) admcp1[noparse][[/noparse]7] := adc.in(7,1) admcp2[noparse][[/noparse]0] := adc.in(0,2) admcp2[noparse][[/noparse]1] := adc.in(1,2) admcp2[noparse][[/noparse]2] := adc.in(2,2) admcp2[noparse][[/noparse]3] := adc.in(3,2) admcp2[noparse][[/noparse]4] := adc.in(4,2) admcp2[noparse][[/noparse]5] := adc.in(5,2) admcp2[noparse][[/noparse]6] := adc.in(6,2) admcp2[noparse][[/noparse]7] := adc.in(7,2) admcp3[noparse][[/noparse]0] := adc.in(0,3) admcp3[noparse][[/noparse]1] := adc.in(1,3) admcp3[noparse][[/noparse]2] := adc.in(2,3) admcp3[noparse][[/noparse]3] := adc.in(3,3) admcp3[noparse][[/noparse]4] := adc.in(4,3) admcp3[noparse][[/noparse]5] := adc.in(5,3) admcp3[noparse][[/noparse]6] := adc.in(6,3) admcp3[noparse][[/noparse]7] := adc.in(7,3) vp.share(@scantime, @admcp3[noparse][[/noparse]7]) scantime := ((cnt - txe) /us)I discovered a couple of thing with the code:
You have to be very careful with the indenting within repeat loops.
In this code:
b := 0 repeat repeat while chipnumb <4 b :=0 repeat while b <8You don't need the first two lines, since the second repeat loop repeats forever.
Also, the way you're doing the test, you should replace the lines
repeat while chipnumb <4 b :=0with just:
repeat b :=0Notice a couple of things here. The b := 0 needs to be indented two spaces, not one.
Also, the value of chipnumb is not defined before this repeat and is not needed here.
Finally, the line:
r := adc.in((b - 15),chipnumb) ' 87usshould be:
r := adc.in((b - 16),chipnumb) ' 87usSince the first value of b is 16 for this loop.
Even with these little changes, I don't think we've accounted for the strange numbers seen
in the first and third MCP3208 chips. The voltage returned should always be between 500 and 3000 mv,
according to the range response curve I posted above.
Check the wires and let me know when you get a test case setup with values.
Have fun.
Jim
'' ****************************************************************************** '' * "HC595.spin" 74HC595 SPIN Object * '' * coded by Jim -- 12/31/08 -- Happy New Year! * '' * Version 1.0 * '' ****************************************************************************** '' '' Calling sequence '' OBJ '' SReg : "HC595" '' '' code segment '' SReg.InitSer595 ' to initialize driver '' more code '' DataByte := toSend ' set up data to send to chip '' SReg.WriteSer595(DataByte) ' send data to chip '' more code '' CON _PinHigh = 1 _PinLow = 0 CLK = 16 ' pin number of CLK pin on chip (AKA SCK) SER = 17 ' pin number of SER pin on chip CLR = 18 ' pin number of SCLR pin on chip RCK = 19 ' pin number of RCK pin on chip GPN = 20 ' pin number of G pin on chip VAR long bitout, databyte PUB InitSer595 ' initialize 74HC595 for startup ' set the control lines as outputs dira[noparse][[/noparse]CLK] ~~ dira[noparse][[/noparse]SER] ~~ dira[noparse][[/noparse]CLR] ~~ dira[noparse][[/noparse]RCK] ~~ dira[noparse][[/noparse]GPN] ~~ outa[noparse][[/noparse]CLK] := _PinLow ' init main clock line to low outa[noparse][[/noparse]RCK] := _PinLow ' init latch clock line to low outa[noparse][[/noparse]GPN] := _PinHigh ' set outputs to 3-state outa[noparse][[/noparse]CLR] := _PinLow ' set to clear register on chip outa[noparse][[/noparse]GPN] := _PinLow ' turn on the chip and clear pins outa[noparse][[/noparse]CLR] := _PinHigh ' return CLR pin to high after clear PUB WriteSer595(Data) ' Data is long with 8 bits of data in bits 7 - 0 ' Write 8 bits of data. Data byte is output MSB first. databyte := Data ' transfer to working storage repeat 24 ' shift out 8 bits bitout := databyte & %1000_0000_0000_0000_0000_0000 ' take hi bit from byte -> bitout bit 7 bitout >>= 23 ' shift to bit zero for output databyte <<= 1 ' shift data left 1 bit for next loop outa[noparse][[/noparse]SER] := bitout ' shift out high bit to serial pin (0 or 1) outa[noparse][[/noparse]CLK] := _PinHigh ' toggle the clock pin to shift bit out outa[noparse][[/noparse]CLK] := _PinLow ' high then low to cycle the clock outa[noparse][[/noparse]RCK] := _PinHigh ' toggle the RCK pin to latch the output outa[noparse][[/noparse]RCK] := _PinLow ' high then low to cycle the clockHere are some more pics
Don
This driver supports up to 24 ADC channels using up to three MCP3208 ADC 8-port 12-bit chips.
danthony has been testing it using 24 IR range sensors, and it seems to be working fine.
The calling sequence is different than the original driver, due to the multi-chip support.
Here are the main entry points:
Let me know if you have any questions.
Jim
Did you locate the source of the intereference? Could it be the illumination from the other 23 IR emitters, bouncing off the round barbell, could be the source of the noise? This could be checked by fixing the barbell in position, monitoring the single closest channel while covering up a range of the other 23 sensors?
I'm using the MCP3304 in an 4 channel application (works well) and am about to test the same sharp sensor for a silo level monitoring application. No plans yet for multiple sensors, but knowing how these things tend to evolve... so thanks for blazing the trail.
And many thanks Jim for the driver
tubular.
I second that thanks to Jim for the driver. The interference happens without anything in front of the sensors at all. The sensors are packed so close tight it could be related. However it works pretty good.
What are you looking at in the silo?
Don
tubular
Don