02-15-2016 03:49 AM
Hi,
I am trying to use my EMSENSR-MPU9250 sensor with labview. I take MMA8452Q example code(Help->Find Examples->Directory Structure->MakerHub->LINX->MMA8452Q Accelerometer) as reference and try to make some modifications over it in order to run my MPU-9250. When I go step by step over MMA8452Q Accelerometer.vi I pass 1. step(Initialize) just by selecting serial port COM7 but when I come to the 2. step I got a bit confused. I try to modify 2. step(Open) as in picture(MMA8452Q_open) but I don't know how to change xD and 2A values as to work with my MPU9250 (2A is shown as WHO_AM_I register in MMA8452Q.pdf).
I need help with choosing the correct addresses for my MPU9250.
Best regards,
02-16-2016 09:52 AM
Hi Albigi,
Thanks for posting in the Discussion Forums to get some help with your MPU 9250! After looking for what you should be populating the WHO_AM_I register with, I came across the MPU-9250 Register Map and Descriptions document, which shows on page 44 that the defualt value should be 0x71. ( https://strawberry-linux.com/pub/RM-MPU-9250A-00.pdf ).
Just out of curiosity, do you need to modify the 8452 example code to get it to work with your 9250? What errors are thrown if you run it as is? How did you determine which registers you needed to change the values of? I'm also curious what version of LabVIEW and what OS you are using?
Let me know if you have any sucess with the new WHO_AM_I value or if you have answers to the questions I asked.
Thanks!
02-17-2016 03:52 AM
Dear Austin,
First of all, I am using Windows 7 64 bit operating system and Labview 2013 32 bit.
I just need to get data from this sensor, MMA8452Q code is just a tool for me because I thought it could be similar to what I need so I am open to any kind of solution in Labview.
So when I try to run MMA8452Q code step by step in a new vi, I took the first two modules(as in MPU9250.jpg), changed the I2C address as 0x68 and get this error 5001(as in MPU9250_error.jpg). Then I enter Open.vi and change slave address as 0x69 in write.vi because it is in write mode and change the data as 0x71 in write.vi because it gets the WHO_AM_I value(0D) . After that I change the bytes to read as 8 but it makes no sense now. Becaues I get the same error when it is 1 also. Then I enter one step deeper and see the error mesaage is in I2Cread.vi (as in open_error.jpg). Again I enter one step deeper and see that the error is in other I2Cread.vi as in (I2Cread_error.jpg) And at last I enter I2Cread.vi and find the error generation as in (I2CRead_error2). I can not understand what is 00E3 here and I don't know how to solve this error.
I will be very glad with your hepls,
Best regards,
02-17-2016 06:39 AM
Hi,
I also have a chance to use NI PCIe-6353, X series Multifunction DAQ card. It might be better to use than Arduino. But I don't know how I can do it.
Best regards,
02-18-2016 03:27 PM
Hi Albigi,
After looking at your application a little further, I don't think using that drive you found on the MakerHub is the best idea, mainly because it was written for a completely seperate device.
I would recommend using your DAQ card like you suggested to do the SPI communication. There's a great I2C API (located here http://www.ni.com/example/31080/en/) which you could use with your DAQ and your MPU 9250. Alternatively you can use the SPI API with your DAQ (http://www.ni.com/example/31163/en/) to communicate as well. With either of these options, you could use the API in LabVIEW to create pulse trains to send to your device
02-19-2016 07:34 AM
Dear Austin,
I have looked at that links and read this sentence "These waveforms can be generated using any device that supports per-cycle tri-stating, like the NI 6547, 6548, 6551, 6552, and 6556 devices. Additionally, they support features of the 6547, 6548, 6551, 6552, and 6556 devices that make parsing a slave device's response faster and more efficient, like Hardware Compare" So I understand that my PCIe 6353 will not work (The same case exists for SPI communication). Am I right about this. If it is like this what could be alternative solution?
Best regards,
02-22-2016 04:21 PM
Hi Albigi,
I see where your concerns with that solution come from. I had misread that statment initially, because it differs in what the SPI protocol is. For I2C, I think you need an HSDIO card, but for SPI, the documentation says "These waveforms can be generated using any National Instruments hardware-timed digital I/O device."
Can you communicate with that sensor via SPI instead of I2C? I am going to try to do some testing on my own with a 6353 to detemine if this is possible for you.
Have a great day!
02-25-2016 10:03 AM
Dear Austin,
I hope I can communicate with this sensor via SPI. Therefore I am reading related information about SPI protocol.
Have a great day!
02-26-2016 01:05 PM
Hi Abilgi,
Using SPI looks like the best bet. With a little configuration, you should be able to do it. I tested it out with a 6343 and it worked out well. I've linked a few documents below that should help in the setup/parsing of the SPI communication. The first link discusses some the architectural considerations of using SPI with DAQmx cards. The next one is a link to the Discussion Forum page which specifically supports the SPI Digital Waveform Library.
http://www.ni.com/example/31200/en/
SPI Digital Waveform Library Discussion Forum-
http://forums.ni.com/t5/Components/SPI-Digital-Waveform-Library/td-p/866346
Hope this helps!
03-03-2016 09:11 AM
Hi Austin,
Thank you very much for the information you supplied to us. We have read the forums that you send in the previous post. Then we have downloaded and set the library up. In the library, we run the "SDW 16 bit register swap.vi" and get the following results as in the attachment. Now we are trying to set the parameters correctly but we get some troubles.
When we look at the "Serial Protocol Communication Reference Design for Digital Waveform Devices- " we see that it says "Some devices provide an onboard oscillator that can be used to generate the clock internally, while other devices provide counter/timer circuits for generating a clock signal." So how can we analyze if our device has onboard oscillator not? We will choose the correct solution from the article and then will run the correct vi according to this information.
Best regards,
Uğur ÖZENÇ