« first day    last day (18 days later) » 

1:07 AM
I haven't been able to really digest what you have written just yet, but I did completly reflash, and start over the tutorial from the beginning. Still nothin. I am using raspian buster with all the recommended libraries. I have no idea whats going on, unless we got a bad batch of chips
 
1:38 AM
No problem. Let me see what you have been doing. (1) You successfully completed the SPI loopback test. (2) Next test is to use a multi-meter to test CS0 when repeatedly send out bytes, using the plug and play function also in my loopback module. (3) Next test is the ping MCP3008 test. If you understand what is going on in test (2), then you can try to following the design of my ping MCP3008 test.
If you are not trying to upgrade yourself to higher ninja levels, you can skip my design notes and wait sometime for me to finish the ping program and just plug and play the ping program to verify if you indeed got a batch of bad chips. But as I hinted earlier, the chance of getting a batch bad chips is much smaller then getting a batch of impatient and lazy newbies. Anyway, have a nice new year.
Ah, I forgot to ask two questions: (1) Do you know Ohm's Law, (2) Do you know how to use a multi-meter?
 
 
2 hours later…
3:22 AM
I do know Ohms law, and I do know how to use a multimeter.
Something that I thought was curious was this. I connected an LED to the analog in pin (channel 0), then connected the other leg to 3.3v then to ground. Both of those configurations didn't make the LED light up. I would think that if the chip was accepting a signal, then the led would light up, but nothing happened. I don't know what to do with this information, but I feel like I am not allowing the pin to accept a signal somehow
Looking at the datasheet, and the specs for the chip select pin, It seems like that pin is high when it is low, and low when it should be high. I think you had mentioned a test for that above that i will look back on.
 
3:59 AM
This is a dumb question, but where can I get your loopback code? I have my multimeter ready.
 
 
1 hour later…
5:08 AM
I though you have read my suggestion below and tried it!
"For spi loopback tests in Rpi python 3.5x and 3.7x, you can search this forum using key words "SPI", "loopback". If you add the search word "tlfong01" you might find a couple of my answers with loopback python test programs, colourful waveforms illustrating the CLK, MOIS, MISO, CSn waveforms. You don't need to understand the details of the programs. My programs are "plug and play/run" no library is required. Though you need to "uncomment" to select slight variation of loopback, say one, two, or three characters, or control characters
 
5:40 AM
You need to study carefully the loopback three bytes test, because later you will find that if you replace the three input MOSI bytes by MCP3008 "Start ADC operation", "Single/Differential Mode, Channel number" and third byte just dummy byte, then the second and third of the three bytes return at MISO contains the 11 bit ADC results. Never mind if you don't know what actually I am talking about, because I am going to show the real ping MCP3008 function, with the input parameters in detail.
So after you tried the 3 byte loopback OK, you can then sit back and watch me how to ping MCP30008. Actually this this the second last step to read MCP3008. So you are almost there!
 
 
1 hour later…
7:02 AM
One more thing. I have not checked your program if it is using single or differential mode. Either case you need to pull the free input pins to ground, otherwise the dangling input pins might float and become higher or lower to the input pin you are using. The result is that the output will be zeros. See explanation below.
Also important is the I2C speed cannot be too high or too low. If too high, then MCP3008 might not have time to charge up the sampling capacitor. If frequency too low, then the charge in the sampling cap will bleed or leak away, causing results too low, but should not to zero. I once tried very low frequency and found results unreliable.
 
7:48 AM
Now the time has come to write the ping MCP3008 function, based on the SPI loopback three bytes function which has already been tested (together with the multi-meter CS check when repeatedly write one byte). The only things remaining is to decide the first byte with the start ADC bit, and the single/diff/D2/D2/D0 byte.
So I go reading the MCP3008 datasheet for details. Then I had pleasant surprise, I found the MCP3008 config bits is identical to that of MCP3208. In other words, the same ping function can be used for both MCP3008 and MCP3208. Actually MCP3208 hardware architecture is almost the same as MCP3008, except the resolution is 12 bit instead of 10 bit, as can be compared with the pictures below.
Now I am using the simplest test config: (single channel, channel number 0). In other words S/D D2/D1/D0 = 0b1000. The only difference with MCP3008 is that the four config bits for MCP3208 is shifted two bits to the left. So far so good, ah, time for delayed afternoon coffee break, then jogging time. :)
 
 
6 hours later…
2:23 PM
Now I have drawn a schematic for testing both MCP3008 and MCP3208.
Next step is writing the Ping MCP3x08 function.
 
3:06 PM
I was testing everything with the other channels not connected through ground. Maybe that was messing with it. I also did not mess with the frequency of the chip.
How do I drop the speed of the chip?
 
 
2 hours later…
5:10 PM
Just another little update. I got some MCP 3202 (similar, just with less channels, and 12 bit resolution) now I am just getting 1023 even if the signal going in is hooked up to 3.3V or ground.
 
5:52 PM
It works!!!
 

« first day    last day (18 days later) »