SparkFun Forums 

Where electronics enthusiasts find answers.

General project discussion / help
Did you make a robotic coffee pot which implements HTCPCP and decafs unauthorized users? Show it off here!
By kirash4
#171748
UPDATE: After switching the module to use SPI mode instead, I don't experience the freezing anymore. So perhaps it does indeed have something to do with I2C mode. Even at a 500ms refresh rate, it was still quitting. Not so with SPI. It's been running with 5ms refresh for the past half hour, no hiccups.

I have an SFE LSM9DS0 (default configuration) connected to a genuine UNO (no 'R' version printed, it's that old) via a TXS0104 that handles the voltage difference. There's a sketch running that's spitting out all the sensor variables to serial. Serial connection is setup at 115200. From there I have Processing capturing the serial data and plotting them. See attached image for an example. Everything works as I would expect except after a while it just freezes, or stops sending data. I have to reset the UNO for it to start sending data again. Thinking it may be because I'm trying to send data really fast (the loop cycles every 5ms), I thought I'd slow it down to maybe 50ms. Same thing, it stops after some random time has passed, sometimes within a few seconds, other times it will last a few minutes.

At that point I decided to try a different board, namely SFE's RedBoard. Unfortunately, the same thing kept happening. It just freezes. And it doesn't matter if I'm monitoring the data flow through the Arduino IDE, or parsing and displaying the graph within Processing; it will freeze after some random time has gone by. But, the RedBoard also threw in another wrench: for some reason it does not stream as well as the UNO does. What I mean with that is this: with the UNO, when I have the refresh rate set at 5ms, the serial output is a steady (and fast) stream of data. Processing also plots the data as a steady stream. However, with the RedBoard, that stream turns into bursts of data. Is it because of the FTDI, is it buffering data then sending the entire buffer out when it fills up? It's a consistent amount of data each time, which leads me to think it's a buffer. Somewhat annoying.

But, ultimately I need to be able to get the refresh rate down to either 0ms or within 5ms. The reason is that this will be going onto something that's spinning anywhere between 150-300 rpm, and I need to be able to see the data and plot it for now - ultimately I won't need to plot the data, just read and do some calculations. But for now, while I'm testing things, I need to figure out why it's locking up at seemingly random times and how to fix that.

Does anyone have any suggestions of things to try? Could it be because it's using I2C for communication between it and the Arduino board and it can't keep up?
You do not have the required permissions to view the files attached to this post.
User avatar
By Ross Robotics
#171756
It doesn't seem like a hardware issue so it's has to be a software one. Post your code.
By kirash4
#171757
For testing purposes, I'm running the exact code that's on the example page: https://learn.sparkfun.com/tutorials/ls ... no-example

Running the sensor in I2C mode with that exact code, will freeze after some random amount of time; sometimes seconds, sometimes minutes, eventually the Arduino stops sending serial data. Running it in SPI mode does not. In fact it's been running like that for hours now. I've made the refresh 5ms and it's still spitting out data.
User avatar
By Ross Robotics
#171762
I don't think it's that code. Sparkfun does do a good job writing their sketches. The only other thing I can think of would be interference when you are using I2C. I don't know how you are hooking it up, but true to use as short of jumpers as possible, and/or try to minimize signals/supplies that could interfere.
By Mee_n_Mac
#171768
What's the value of the pull-up resistors ? Do you know the I2C bus speed used ? You might have slowed down the loop requesting data, but I think you kept the bus speed the same. I wonder if the bus speed might be on the edge of what is possible given the pull-ups.
By kirash4
#171769
Mee_n_Mac wrote:What's the value of the pull-up resistors ? Do you know the I2C bus speed used ? You might have slowed down the loop requesting data, but I think you kept the bus speed the same. I wonder if the bus speed might be on the edge of what is possible given the pull-ups.
According to the schematic, the pull-ups are 10K. As for the bus speed, I never changed that from whatever the default is within Arduino. Right now, it's working flawlessly on SPI - I know, different bus, different protocol, different everything, apples and oranges. Just saying, if it was the sensor itself, I would expect it to also fail on SPI. But, just in case, I have a second one on order which I will once again run in I2C mode as-is, and see what happens.
By Mee_n_Mac
#171771
10k is a bit weak, 4.7k is probably the norm. I2C works by having each device actively pull the bus lines to ground via open drains or open collectors. But going back to a logic 1 is determined by the pull-ups and capacitance on the line(s). So the sensor could be fine but the pull-ups aren't bringing the line(s) back to a logic 1 quick enough for the bus speed used.

See this page re: changing the I2C speeds.
http://www.gammon.com.au/forum/?id=10896
By Mee_n_Mac
#171775
kirash4 wrote:I'd have to disable the resistors on the board and add my own. Should be able to cut the traces I think.
Or just add some in parallel. 10k in parallel w/10k gets you 5k.
By kirash4
#171777
No, can't do parallel, there's no place to solder on the board (maybe if I stack one on top of the other and reheat it again.) For now I'm going to keep using it as an SPI device. If it proves to be problematic with the SD card, which I'm also reading as a high rate, then I'll look into going back to I2C.
By kirash4
#171862
FYI, using 4.7K pull-ups made no difference. It would still freeze after some random time. It didn't matter if the pull-ups were between the sensor and the buffer, or between the buffer and the Arduino. It resulted in the same random freezes. Looks like I'm stuck running this in SPI mode.