Member Since: March 25, 2008

Country: United States

  • The Sparkfun Arduino library example code is misleading. It leads one to think that changing the code to include a local adjustment for magnetic variation will get a valid yaw output that can be used to obtain heading data. Not so. The code contains bias values for the magnetometer that are unique to the MPU-9250 that was used to develop the library. These bias values will not be your required bias values to obtain useful heading data from the MPU-9250. Without these bias values, the library example AHRS code can be expected to output valid pitch and roll info, but wildly inaccurate (unusable) yaw info.

  • I am using this part with a 5v pro mini. I compiled the example code MPU9250BasicAHRS that was included with the library which I installed with the arduino library manager.

    The code is connecting to the MPU9250, displaying reasonable data for pitch and roll, but yaw, not so much.

    I applied the correct magnetic variation for my location, but note the following:

    When the x axis of the accelerometer is aligned with true north, the yaw output is around 35 degrees, east gives values around -159, south shows 135, west 84. This does not make sense. The Yaw is changing in the wrong direction when rotated from north to east.

    I know the magnetic sensor coordinate axes are not the same as the accel axes, but it is not clear if the example code is intended to correct for this before displaying yaw, pitch, and roll amounts.

    Has this code been verified to output sane results, and if so how exactly is the part oriented physically when oriented towards true north?

  • Pete,

    It is possible that you are reading the current state of the output pin, inverting that state, then outputting that state to the pin. This can and does work at high clock frequencies, but can, and will fail under lower frequencies in some circumstances. I have not looked at the code library to see if they shadow the value that is last written to the port in a register, so this may not be what you are running into. If they don't shadow the port. this may be what you are experiencing:

    The output node has an impedance and some amount of capacitance. When the pin is being driven as an output, this capacitance is charged to the voltage the pin is driven to. If the pin is then switched to be an input, (to read its current state) the output register is no longer driving the pin. The voltage is sampled that is currently on the pin which depends on the amount of capacitance in the circuit connected to the pin, the resistance of the load connected to the pin, and any stray leakage paths on the PCB. If, due to the slow clock speed, you give the leakage paths enough time to change the charge on the capacitance at the pin to a different logic level, the value read will be different than that written. It is most likely to be of a nature that tends to either drift to one of the power rails. Lets say it wants to drift to a high for argument sake. If the port wrote a low to the pin, but the pin drifted to a high before it was read due to the slow clock, the code would then invert that high state to a low and write that low state to the pin. However, that was the same state that was previously written to the pin, so the pin is no longer toggling, even though it is still running. The slower the clock is ran, the more sensitive to this problem the system will be in this circumstance. (You are giving the leakage paths present at the pin more time to modify the charge on the capacitance at the pin).

    This can be avoided by toggling a register in the processor and outputting the current state of the register to the pin. The pin then always stays in output mode, but just follows the state of the register which is toggled in code. The ATMEGA 328P is specified to be entirely static in nature, so you should be able to clock it at any slow clock speed you desire while maintaining the clock stability spec.

    One practical reason to do this could be to minimize power consumption for a micro controller while allowing it to wake up on external events where it would briefly switch to high speed for moments when an important event occurs. You are correct that such a design needs to be fully analyzed to minimize other losses so that such techniques actually achieve the desired results. Many processors for this use case exist with the ability to turn off unused peripherals to further reduce the quiescent power required.

    It would be interesting to see if this is what is causing your system to stop toggling the LED.

  • Without knowing the breakdown voltage spec on the transformers in the power supplies, I would not recommend connecting 100 of them in series. You might see sparks where you don't want them. Even if the 500V @ 2A supply worked, it would be very dangerous to experiment with.

  • ChipQuik is great for stubborn through hole as well as SMD parts.

    The level of difficulty in doing SMD rework depends greatly on the amount of free space around the part you are working on.

    Using adhesive-backed aluminum tape to shield the components around the area you are working on is also sometimes helpful when using hot air as it keeps the parts surrounding those worked on cooler and prevents solder from getting between their pins. You can get this tape in your local hardware store.

  • From a navigation perspective, your current position does not depend on temperature, so that is not a degree of freedom. The MEMS sensors are affected by temperature, so knowing the temperature the sensors are at may allow one to partially compensate for the errors that are introduced when operating the sensors over a range of temperatures.

  • The photos don't show the lens specs clearly. What is the focal length of the lens, what is the f number of the lens? What is the CCD sensor size?

    You mention it is Linux compatible, is it Video for Linux (v4l) compatible?

  • Given the new UAS rules from the FAA, how do you plan to hold the event regarding UAS vehicles? I would like to see the UAS portion of the AVC done outside as it has been done in the past. With the right safeguards, in my opinion it should be possible to do so under the UAS rules the FAA has published. Thoughts?

  • Offering the product without the headers installed, but headers included is my preference as it saves the hassle of sourcing headers, and potentially unsoldering them if their product would require odd headers or no headers (like in wearable situations). Soldering .1" headers is a pretty easy task.

    For those who lack the soldering equipment but want to use the product on a breadboard, offering it with the header pre-installed is also nice.

  • Set one fire alarm off at work, and they make you go outside to test things...

No public wish lists :(