Oh, I just had the similar problem a few days ago. I found the soft reset command "55555352007E4F" in hex.

@Jose said in IMU placement into a car:

Can you assure us that this that we have tried to describe does not happen with your module?

If you mean magnetic interferences, we will have the same problem.
If you mean pitch/roll error increase duration acceleration or braking, we have this into consideration in our algorithm. However, there will still be error increase. You need to test it to see if it meets your requirements.

What is the optimal location for the module?What are the possible ones?Where have they tried it?

For magnetic sensor, you need to put it aways from changing interferences.
You should also put it at a location with less vibration.

On the other hand, is there a possibility to connect with Arduino?

We have SPI and UART in OpenIMU300ZI. You need to prepare the driver for Arduino.

There is one simple principle when you want to use a magnetometer in your application: there should be no varying magnetic interference.
Varying magnetic interference includes:

1. hard iron. For example, a moving magnet, a chaning current around the sensor;
2. soft iron. For example, a moving steel.
3. Environmental magnetic field change. For example, moving the sensor for one location to another which has a different magnetic north from the first location.

@Swingw , you buy an OpenIMU300ZI evk.

@simon-rob , I will find the firmware engineer to answer your question.

Hi Simonrob,

Could you tell me more details about what you want to do? So, I can get a firmware engineer to help you.

Dong

Hi matteo,

I tried both the jumper ON and OFF, it worked fine.
When I first got this app to work, I tried the following steps. You can follow these steps.

1. Are you using the latest code? The latest code should be released around late in 2019. If no, get the latest code and then continue. If yes, Continue.
2. In the function TaskGps() in taskGps.c, you can check (by debugging in vscode or outputting debug messages) if the app can run to the line

            GPSHandler();

If not(unlikely), please tell me. If yes, that means the taskGps is working, and continue.
3. In GPSHandler(), check if the app can run into

_handleGpsMessages(gGpsDataPtr);

and then into

parseNMEAMessage(tmp, gpsMsg, GPSData);

If so, that means the app can run into the GNSS message decoder as in UserConfiguration.C, and continue. If not, you need to check your configuration.
4. In parseNMEAMessage(), you can see the final results. There are a few things you can do.
4.1 check if gpsMsg contains actual NMEA messages.
4.2 check if the app can run into processNMEAMessage().
4.3 in processNMEAMessage(), check if the app can run into _handleNMEAmsg().
4.4 and in _handleNMEAmsg(), you can check if all three messages can be decoded.

You can actually directly check step4.

In a serial monitor, can you see other messages than NMEA GGA/VTG/RMC? There may be some binary-format packets that should be disabled. Besides, are you sure the GPS protocol in the INS app is configured to NMEA?
If the above are confirmed, you need to dive into the taskGps.c to figure out why.

Hi Amin,

gAlgorithm.Behavior.bit.useGPS is used to control state transition. If it is set to false, the algorithm will stay in attitude only mode. This bit does not control the use of each GPS sample. To do that, you need to use gEKFInput.gpsFixType. Setting this bit to false means this GPS measurement is invalid and will not be used in the EKF update stage. You can either directly change this bit or change the GPS driver where this bit get its value.

Dong

Since you make it work sometimes, I assume the connection and baud rate are right. So you can first check if NMEA is the only output message via ucenter. You can do this using some serail tool on PC to see the output from the receiver.