Frequently Asked Questions
Mon-Fri, 9am to 5pm
U.S. Mountain Time:
Chat With Us
July 10, 2011
about 4 days ago
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?
about 2 months ago
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).
about a year ago
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
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.
about 2 years ago
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).”
about 3 years ago
Possibly “ublox”, but here is one:
(Although it looks like it only has 4 cables…)
Tutorial - GPS Tracking Comparisons
about 3 years ago
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.
about 3 years ago
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)).
about 4 years ago
How the hell do you connect this to an arduino? Perhaps you could supply a wiring diagram and some example code, or at least a quick description?
I connected it up with SDA/SCL going to pin A4/A5 on the arduino, and +5V/0V going to Vcc/Gnd, as seemed obvious from the lack of description. None of the chips respond to my register queries though. I read noworries' comment about the pull-up resistors in twi.cpp and tried that but it didn’t work either.
I’ll be pretty -ing pissed off if this expensive produce is somehow incompatible with the most popular microcontroller available, and you didn’t even give a warning!
No public wish lists :(
Forgot your password?
No account? Register one!