Member #237447

Member Since: July 10, 2011

Country: United States

  • From the schematic it seems like this won’t work with 3.3V boards (e.g. the Arduino Due or any mBed boards). It would be nice if a future revision allowed this (e.g. using the same circuit as your RS232 shifter).

  • with a little extra effort – can be programmed just like any microcontroller

    So… is there actually any documentation available for this chip? Or is this another really-useful-but-impossible-to-use thing?

  • Be warned, these modules require a purchase of IAR (a $3k compiler) to program. Seriously. They’re only really usable by large companies with large budgets.

    TI’s newer CC2650 chips have more standard ARM cores and are fully documented unlike these. They can be programmed with GCC which is free. I’d wait for those modules if I were you. Or use Nordic’s nRF51822 which is easy to program (supported by mBed) and available in many different modules (there’s a list on the Nordic site).

  • Thanks! This (well the mirror at https://github.com/richards-tech/MPU9150Lib ) was the only code that worked with the DMP for me. However their example does have huge latency (maybe 1 second) which makes it rather useless.

    Anyone know why?

    Edit: Never mind. There is a bug in the polling delay code in Due9150.ino. Hacky fix but it demonstrates where the problem is, change:

    pollInterval = (1000 / MPU_UPDATE_RATE) - 1; // a bit less than the minimum interval

    to

    pollInterval = (500 / MPU_UPDATE_RATE) - 1; // a bit less than the minimum interval

  • This does not include any documentation for the DMP which is what everyone is annoyed about.

  • According to the datasheet: “An optical filter (long-wave pass) that cuts off the visible and near infra-red radiant flux is integrated in the package to provide ambient and sunlight immunity. The wavelength pass band of this optical filter is from 5.5 till 14μm (except for xCH and xCI type of devices which incorporate uncoated germanium lens).”

  • Try https://store.diydrones.com/FTDI_GPS_Adapter_cable_15_cm_p/ca-0001-09.htm

  • Possibly “ublox”, but here is one:

    https://store.diydrones.com/FTDI_GPS_Adapter_cable_15_cm_p/ca-0001-09.htm

    (Although it looks like it only has 4 cables…)

  • Actually Apis’s description is not really correct either unfortunately! You should probably update it; especially since the same incorrect explanation is given in many other official places. It would be nice if the true one were known more. Here’s my attempt:

    In order to know your distance from a satellite, you need to know the transmission time of the signal and the reception time (and the speed of light). However for the GPS received to know the transmission time it would need an atomic clock syncronised to the one on the satellite. Obviously this is not feasible, and therefore YOU CANNOT KNOW THE DISTANCE TO ANY SINGLE SATELLITE.

    Fortunately there is a trick. If there are several satellites that do have synchronised atomic clocks, you can get them to all transmit at the same time (or one after another in a fixed sequence, but it’s easier to think about if they do it at the same time).

    Now you can know the relative distance to a set of satellites. For example with four satellites you might know their distances are:

    Sat1: 20000 km + C Sat2: 25000 km + C Sat3: 18000 km + C Sat4: 21000 km + C

    Where C is some unknown number. Now using geometry we can see that three satellites are not enough for a 3D fix (since we have four unknowns: X, Y, Z and C; and three equations: the relative distances to the satellites).

    Four satellites is enough. There’s a good way to visualise this that I heard somewhere (can’t remember where sorry; there was a great video that explained all this). Imagine the four satellites, and the distances to them are pieces of string of various lengths attached to the satellites. Tie the ends of the string together (at the GPS received). Now you will be able to pull two strings taught, and then rotate the knot until another of the strings is also taught. At this point the fourth string will be loose. Now all you have to do is pull all four strings through your hand, moving the GPS receiver to keep the first three strings taught until all four strings are taught. That is the correct location.

  • These seem to be quite nice, but… well they don’t work reliably.

    I have set up two identical boards to do simple transmit-receives and display the results on 2-line displays. The results are not good. Initially transmission works, but at random points the transmission just stops working, as if there were heavy interference. However the transceivers are right next to each other, and I live in the country away from large populations of wifi.

    I cannot really work out what the problem is. I’ve tried both the “Mirf” code, and my own driver, written with reference to the data sheet. Both exhibit the same effect. It seems to happen more with high speed transmissions, and I’ve tried various settings (enable/disable CRC, auto-acknowledge, etc) with no luck. All the device registers are consistent with out-of-range conditions.

    It’s a shame because these are quite cheap, but I’m pretty sure I’ve done nothing wrong, so I much recommend avoiding these.

    Another reason you might want to avoid them: there are a few annoying architectural decisions (e.g. it doesn’t automatically go into receive mode after transmitting like you’d expect, and the ack-payload behaviour is pretty badly documented (or maybe it really is as random as suggested)).

No public wish lists :(