I;m having problems reading from an I2C device

[TheLT]

smercurio,

   First, thanks for getting back to me. Ok, I did read the data sheet, but I am also here to learn. I am by no means an expert, and am trying to comprehend everything, so if you could guide me in the right direction, that would be great!

  1.) I didn't see where the memory map is 12 bytes. I honestly thought it was more than that per Table 9 in the data sheet. Can you please explain? Again, trying to understand, not trying to argue or anything of the sort.

   2.) Responding to your post, after I read the last byte (in your post the 12th byte), it would repeat itself I suppose.

   3.) What is so difficult about using read/write? Well, I really and honestly don't understand why you need to write anything to it. I thought you just needed to read the values. Aren't we making it more complicatied this way, no offense? I understand bytes 1-7 being X, Y, and Z, but what about bytes 8-15 per the data sheet (Table 9)?

   4.) Assume we did go with typecasting - would the cluster constant be outside of the for/while loop?

   I did try the former solution you provided via type casting, but I didn't get any values from that either. Again, not trying to be offensive, but trying to learn. And yes I have looked at examples and searched elsewhere, but no dice.

   Again, thanks for your help. It is much appreciated!

   TheLT

[smercurio_fc]

---

  1.) I didn't see where the memory map is 12 bytes. I honestly thought it was more than that per Table 9 in the data sheet. Can you please explain? Again, trying to understand, not trying to argue or anything of the sort.

---

Sorry, typing too fast and not reading what I write. That was 12 hex, which is 18 decimal. The memory map is 18 bytes.

---

   2.) Responding to your post, after I read the last byte (in your post the 12th byte), it would repeat itself I suppose.

---

Do you know this for a fact? It does not say this in the data sheet. The only auto-incrementing that's mentioned is with the fast writes. There is no mention of what happens to the register counter after reading the last byte in memory. It may or may not reset to zero. It's likely to be reset to zero, but unless you verify it by testing it yourself or contacting the vendor you don't know.

---

   3.) What is so difficult about using read/write? Well, I really and honestly don't understand why you need to write anything to it. I thought you just needed to read the values. Aren't we making it more complicatied this way, no offense? I understand bytes 1-7 being X, Y, and Z, but what about bytes 8-15 per the data sheet (Table 9)

---

What about those bytes? Do you use them? If you only need X, Y, and Z, you only need to read 6 bytes. If you do a write and read, the total number of bytes being transmitted is 9 (2 for the write to set the starting address, and 7 for the read). If you read the whole memory map the total number of bytes being transmitted is 19. And no, performing a write before a read is not "more complicated".

---

   4.) Assume we did go with typecasting - would the cluster constant be outside of the for/while loop?

---

This would not matter.

---

   I did try the former solution you provided via type casting, but I didn't get any values from that either. Again, not trying to be offensive, but trying to learn. And yes I have looked at examples and searched elsewhere, but no dice.

---

I don't know what you did, so I can't comment on what the issue was. If you are reading more bytes, or starting the read somewhere else, then the cluster constant would need to change.

[TheLT]

smercurio,

  Ok, I think I am on to something, er, I figured out what my problem is. Now maybe your solution can fix that, but the problem is that this magnetometer is in Standby mode. I've been trying to hard wire a write command to it for it to change a value (i.e., take it out of Standby), but no dice.

    Any suggestions? Please let me know if you'd like me to attach the code and output. I would just like to double check first and see if we can get on the same page and go from there.

  Thanks again!
    TheLT

[Eric-M]

Hi TheLT,

What write are you performing to move the device from Standby?  Have you checked in the manual to see if this is the correct procedure/command?

Regards,

[TheLT]

Eric,

   Well, with the help of another applications engineer (no offense), we came up with the following, but some questions still remain, and I did respond to him this morning as well:

1.)    The data being displayed on the indicator refreshes way to slow. Any ideas?

2.)    I am not getting any Z-data whatsoever, and I noticed this before I wired Y and Z. It looks like X and Y are fine (I just have to figure out what these numbers mean, since the data sheet does a fantastic job – sarcasm). Any suggestions on getting Z-data?

This device (not NI's, but the magnetometer) seems not to be the most user-friendly piece out there. Yay!

  Thanks Eric!

   TheLT

[Eric-M]

Hi TheLT,

1. What rate are you getting updates at, and what rate are you expecting to get updates at?  Do you know how well those rates match up compared to the speed at which the data is able to transfer from the magnometer?

2. When you read in the whole table, do you get any data for the registers that are not X and Y?  Do the rest of the values that are not Z axis related provide proper values back?

Regards,

[TheLT]

Eric,

  Sorry for the late replay, and thanks for getting back to me.

  I should state I am not the best skilled LabVIEWer out there, but learning as I go.

  With that, 1.) I am expecting to get updates of 80 Hz per the specs from Sparkfun/Freescale. If I can recall correctly, I believe the 8451 can handle up to 250kHz, so this shouldn't be a problem. In the code that I've been working on - I2C Write Read VI is slow compared to I2C Read. I've attached my latest code for a reference. I am honestly not too sure what rate I am getting updates at with the Write Read - any suggestions? I2C Read is fast! So fast I have to slow it down with a Wait. I guess Write really adds to the overall delay time? I should note that when I used Write Read I didn't have the wait in there.

    2.) In the current code, I am reading in the whole table now, but what the problem I am getting is that the data rotates through the table (like a roulette wheel or Price Is Right Showcase Showdown wheel) when using Read. When I use Write Read, I don't get that effect, but then we're back to slow speeds and seeing if the Z is even working. I even went one step further and checked another magnetometer and Z still doesn't change. What I did in the code is put in a for loop (I had a while previously) for 18 reads for the 18 bytes to see if the data repeats in some fashion. I tried to get the data out in hex in the attached text file, but no luck. I honestly don't think it lines up to anything, so I'm kinda stuck and back at the drawing board to see what is exactly going on. I should note that using this version, the 8451 LED is flashing, but when using Write Read, the LED is steady. I guess a flashing LED indicates the device (magnetometer) is in standby since you're not writing to it???

    Again, thanks Eric to check into this, and apologies if I am not clear on anything or getting any one frustrated. I was never a solid LabVIEWer, but I am currently taking a course and improving my understanding, so please go easy on me!

    Please let me know if you need any more detail.

   Thanks!
    TheLT

[Eric-M]

Hi TheLT,

1. I don't have the magnometer, so I'm not able to do benchmarking of the speed.  However, a couple of Tick Counts and a subtraction are pretty good for getting a rough estimate of loop speed. One thing that you should try is what smercurio suggested, which is only read the bytes that you need to.  You are currently writing 0 to the device, and then reading back the whole map.  Try writing 1 to the device, and only reading back 6 bytes instead of 18.  See how this speed compares to just the read.  Note that your index values for transforming the data will need to change, or you can do the typecast smercurio showed previously.

2.  Try the write/read mentioned above and you should avoid this behavior.  Also, the 8451 manual states what the LED behaviors mean.

-Off: interface is idle

-blinking: interface is active

-solid: interface is waiting on response from slave

Sincerely,

[TheLT]

Eric,

   Ok, put the write read back in and changed it to write 1 and read six, but speed is still horrible. For instance, to get a reading from the magnetometer, I'll stick a magnet in front of it. It'll take about 10 seconds to refresh itself, and same when I take it away (10-11 seconds).

   On the tick counts and subtraction, I added a tick count in the while loop (see attached), but I wasn't too sure how to implement the subtraction, and the tick count starts at another number other than zero (532471897, but increases positively). I tried to reintialize to zero, but can't find the option to do that.

  Apologies on the frustration, but trying to understand this. Once I figure out the speed, then I can try typecasting, which is another thing for me to understand (I haven't used typecasting in anything yet).

   Thanks!
    Jesse

[Eric-M]

Hi TheLT,

I'm attaching an image of what the timing would look like to see how long the read/write VI takes to complete.  According to the help file, the read/write process invovles a start - write - restart - read - stop sequence, so I can see where the restart adds a little bit more time than a read, but not to the extreme at which it appears to be slowing it down.  Try implementing the timing method, so that we can get a more exact idea of how much this process is taking.

Also, can you try producing another table just using the read VI like you previously.  However, this time could you add in some details, such as what values map to what byte and also what is occurring while producing the data.  Such as, details about when the device is moving, standstill, etc.

Thanks,