- Sat Jun 07, 2014 12:12 am
#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?
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.