OK my bad! Looking at the source for mesh devices, the only working choices for speed are the 400k and 100k constants. You should try the 100k.
It is hard for me to say that your wiring in the photos above is OK or not. It does not look too bad, but the wires are long and the gauge is small (30ga?) and it could be causing some electrical issues. A0lso I found and read the datasheet for the sensor but the breakout board around the actual sensor seems to have a similar but not quite exactly the same pinout. Is there a link to the datasheet for the breakout board?
The oâscope confirms that no matter what code I put before the Wire.begin() statement, the SCL signal does not change.
Each time I flash the code, I can see the clock stops while it is uploading, then the xenon updates the code, but still no change in the scope indications.
Hi Bko,
I made the breakout board. I often add a few different types of breakout boards for tiny components whenever I have new designs of different projects made. THe pinout is just extended for easy attachment of wires. The 5803 data sheet recommends a .1 uf ceramic cap close to the sensor, and that's also what you see.
Bko, I sure don't know it all, but I think the wire thickness and length is no issue. I prototype designs all the time. But...I'll happily shorten them. I appreciate any help, and surely will take recommendations.
I have tried all of the commented out commands relating to Clock speed that you can see in the editor below. It never makes a different in the SCL scope display.
I looked at library linked above, from Sparkfun, and if you are using that, I would go in to the function getADCconversion and add a zero to all the delay(xxx) calls to try slowing it down.
Regarding your breakout board: there must be some connection between pin 6 (the PS pin where you bring in +3.3V) and pin 5 (the actual Vdd pin) that I cannot see.
I would make sure that lower lead of the cap is not touching the sensor body, just in case.
Your scope probe should be around 1Mohm in parallel with 5-10pF to ground if you want to duplicate that.
Another good trick with i2c is use 50ohm resistors in series from the Xenon pins to the pull-ups and sensor pins. This slew-rate limits the output signals from the Xenon and provides some termination for ringing problems.
[quote=âbko, post:28, topic:45618, full:trueâ] Responses within your quote.
I looked at library linked above, from Sparkfun, and if you are using that, I would go in to the function getADCconversion and add a zero to all the delay(xxx) calls to try slowing it down.
There are no delays in any of the getSDCconversion commands in either the .h or .ccp or .ino codes. I donât really think they are actually reading Analog to digital signals from the sensor. I am not an experienced programmer, but I think those are conversion commands that relate to internal calculations, not analog signal reads.
Regarding your breakout board: there must be some connection between pin 6 (the PS pin where you bring in +3.3V) and pin 5 (the actual Vdd pin) that I cannot see.
The PS signal is bridged by a small soldered connection on the breakout board.
I would make sure that lower lead of the cap is not touching the sensor body, just in case.
Checked. It is close, but not touching.
Your scope probe should be around 1Mohm in parallel with 5-10pF to ground if you want to duplicate that. I had made an RC network that duplicates the scope lead closely enough to give good readings, but this is a work-around. I am thinking of adding another device to the i2c line, so I donât think a Resistor Cap. workaround is appropriate. I donât think we are dealing with a marginal speed issue here. It is a major one, in my opinion. I need to get the circuit to where 3K to 10k pullups are used, I think.
Why cannot the changes in code be reflected on what I see on the scope? The xenon must ignore some code, or it overrides it. (in my humble opinion). Can you think of another explanation?
Another good trick with i2c is use 50ohm resistors in series from the Xenon pins to the pull-ups and sensor pins. This slew-rate limits the output signals from the Xenon and provides some termination for ringing problems.
[/quote] That idea of the 50 ohm resistors is interesting. It will take me a long time to set things up like this. My resistor stock is a mile from here. I also do not have anything less than 220 ohm through hole resistors in my resistor bins lately.
sensorWait(1); //general delay HERE
switch( _precision )
{
case ADC_256 : sensorWait(1); break; //HERE DOWN
case ADC_512 : sensorWait(3); break;
case ADC_1024: sensorWait(4); break;
case ADC_2048: sensorWait(6); break;
case ADC_4096: sensorWait(10); break; //TO HERE
}
Oh. Yes, you are right. How would you suggest I modify that code? Put longer values in the sensorWait(?) parenthesis? Suggested value?
I am shortening the wires and adding some 68 ohm resistors. That's the closest I can get to 50 ohms.
Remember, my bench setup works fine with Arduino Mega2560. I have tested it numerous times and it works flawlessly with the unmodified sparkfun code library.
I will shorten wires and add delays as soon as you suggest values. Thanks again.
I do not believe that the Mega2560 has hardware i2c so it uses i2c emulation and bit-bangs all the commands out one bit at a time. This is generally much slower and more timing forgiving.
I did all three suggestions at the same time, and now I am getting good readings from the sensor. I will back out the delays to see if that was the main issue.
Anyhow, this is great! thank you for hanging in there with me. Iâll let you know on the next post if the delays were the main fix. I changed the delays to (256)- 10, (512)-17, (1024)-20, (2048)- 25, (4096)-30.
Well, Bko, MUCH to my surprise, the delays were not the main issue. The main issue is the 68 ohm resistors I put into the circuit. The shorter wires were not the issue either. It was the resistors.
YOU fixed my problem! Thanks for sticking with me. I never would have thought of this fix.
How can I put in a good word for you? I will tell my sales rep, Arjun. Is there anyone else I can tell?
I wrote to Arjun and Benedict, two Particle sales reps:
"One of the Particle guys on the community forum stuck with me on an issue that I have been working on for a while. His patience and engineering/ troubleshooting skills are excellent, and he came up with a hardware solution to my problem which I would never have discovered without his help, and it is not covered anywhere else that I know of. I just want to put a good word in for him. This is the guy!
bkoElite
A big thanks for bko! You guys are blessed to have him on your team. I also want to say that others were also a help. Particle support just stepped up to the top for me!"
Thanks for the kind wordsâwe âelitesâ are forum moderators but not Particle employees. We do this because we like the platform and want it to succeed.
That makes your contribution even more amazing! You stuck with me! Well, if these results could be summarized somewhere for future users, that would be helpful, but at least the log of our troubleshooting is here, and the fix of the terminating resistors is there for others to see. I used 68 ohm resistors and 4.7k ohm pullups. The 68 ohm resistors terminate the SCL and SDA signals near the xenon.
Thanks again.
Now to the next step! Getting data to the Boron (gateway).
