Only when you're on the ground in the first place. Otherwise, you have a circular problem: past a certain point your IMU needs a gravity map to remain accurate, else the drift from variations in gravity is larger than the drift in your sensor. And you need to know where you are and how you're moving to measure gravity.
They also vary over time or something, right? So even a more precise measurement device, to get better gravity maps, doesn’t solve the problem… maybe? This is all based on half-remembered other comments.
So I would like to learn more about gravity map matching. I've seen offhand references to it in context of placing an ICBM on target (can't find ref now) but that's it. I imagine it is, (or was for long enough to make info sparse) a classified piece of know-how.
For sufficiently accurate IMUs, like the ones found in ICBMs, you need a gravity map because otherwise the variations in gravity cause your position estimate to drift
That's helpful; so presumably for the same reason that gyrocompasses function (self-aligning vis-a-vis the local gravity vector).
A part of me was subconsciously entertaining that a subsystem of the IMU / INS was actually being used to provide gravimetric navigation (producing a coarse global position update de novo rather than correct for an error-prone open-loop one from an a priori generated gravity map).
a la
There's also the tides, and variations in the tides with 2nd and 3rd order effects on gravity. Absolute references based on variable references is ugly!
No, this is about preventing unwanted jamming/interference by a transmitter on frequencies it isn't intending or needing to transmit on as part of the design phase of a product. Overcoming intentional jamming is an entirely different ballgame.
Because we want to unambiguously refer to times in the future?
[edit]
It would of course have been possible to have NTP be based of of TAI rather than UTC (and that might have been a good idea), but it still begs the question of what any POSIX operating system will do given that posix timestamps are leap-second adjusted. And the reason that POSIX timestamps are leap-second adjusted is so that 2628198843 has always, and will always represent 2053-04-13T23:14:03Z. For better or worse, humans have standardized on UTC, so machines that expect to interact with humans must also do so.
That’s not ambiguous though. The answer is, unambiguously, that we don’t know how many seconds there will be. But we can still agree to meet at that time, assuming we will both continue using the same time standard.
I get OPs point though - coming from an outsiders perspective I would have thought that a key feature of a time format would be to know how much time there is between two other times.
The standard for communicating time between humans lacks this feature for times more than a year in the future. That computers (which interface with humans) implement this standard faithfully is a feature, not a bug.
I agree it should be implemented but it could be implemented differently. Just like zoned datetimes are represented as a UTC time + timezone. UTC could be represented as TAI timestamp + leap seconds.
Humans will be less bothered by you being off by 10s of seconds for "how many seconds until X" where X is multiple years in the future than they will be where X is a minute in the future. Any timestamp created today may be used far in the future, but durations are (by their very nature) transient. Even if you were to do a sleep(nominal seconds until 2038) the computer is likely to reboot before the interval expires, mooting any issues.
> "The Society of Motion Picture and Television Engineers (SMPTE) video/audio industry standards body selected TAI for deriving timestamps of media.[77] IEC/IEEE 60802 (Time sensitive networks) specifies TAI for all operations. Grid automation is planning to switch to TAI for global distribution of events in electrical grids. Bluetooth mesh networking also uses TAI.[78]"
I know. I know. It's bananas. People keep making time more and more complicated. Different kinds of smears, changes in the dates of daylight savings times, timezone shapes influenced by geography instead of the amount of light.
Honestly, time is complicated. Even on Earth, where we rarely have to address synchronization errors due to relativistic effects.
Users care very much about time preserving ordering of events and synchronization of events at disparate locales. They get grumpy if, say, their alarms start going off at what the local restaurants think is 1PM instead of noon because the national government passed a law starting (or stopping) observance of Daylight Savings this year. Similarly (though it's a slower-rolling error), they get grumpy if their alarms start firing at 11:59 and 59 seconds, 11:59 and 58 seconds, etc. when they have them set for noon.
Time is, ultimately, a human construct and software management of it is beholden to the need to get it right from the user's point of view.
You were downvoted unjustly. I think your opinion is mostly valid, but I think people undervalue simplicity because they underestimate knock-on effects of their decisions.
> Why don’t we use TAI or GPS time for generic world wide coordinated computer time?
I think that is valid as long as systems are talking to systems, but the interface with the world (when things are happening in the world) is where the solar day or year is still relevant.
I'm sort of joking, but watching Interstellar made me kinda cringe about what interstellar gravity wells is going to do to time-keeping, even if we use something like an atomic clock to keep time.
We will slowly get better at this until we discover something new, but the switch doesn't mean anything until the costs outweigh the change.
And the leap second is going look like 46-45 BCE[1].
In some polls I've seen there's plurality support for "permanent 'summer time'". People don't seem to care much that noon in civil time maps exactly to the sun being at its peak.
Leap second drift is super slow, too -- IIRC something like 10 minutes per millennium. If we shift our clocks by an hour in the year 8000 I think that's less disruptive than leap seconds every year or so.
GPS time is no use for far in the future (TAI is OK).
Imagine someone 2,000 years in the future, discovering an archive containing exact GPS timestamps for events. There is no reason to suppose that our present GPS system will still exist - so these timestamps won't be much use to them, since they won't know what the present time (their present) is in terms of GPS. The timestamps in the archive will no longer be precise, as far as they're concerned.
What I've seen with embedded systems is you have a real time clock. And the system when it updates the time updates the registers in the real time clock. And then bad things always happen sooner or later
I've always just let the thing run and use an offset to calculate 'users local time'. If the time gets updated I update the offset.
I think that's what programmers want[1]. Instead of the current system system where the primary time unpredictably jumps around.
[1] For time of day programmers probably want a standard formula that takes an offset and a rate to output the time of day.
The shortest possible TL;DR of https://en.wikipedia.org/wiki/Leap_second#History appears to be "because TV and radio broadcast systems in the 1950s were based on solar time rather than astronomical time and wanted to stay in sync to each other."
Among other reasons (and in line with why Google cares to keep things tied to astronomical time measurments instead of perfect-period atomic clock measurements): if a user schedules something to happen at 'noon every day', they become dissatisfied if the timing of the event begins to drift off of "sun overhead" time consistently because of leap seconds.
Sun overhead time drifts around throughout the year anyway, a couple of seconds is much less of a difference than the difference due to seasons and much less than DST.
For example, solar noon is 1:15pm today in Seattle, and will be 1:09pm at the end of the month. Way more variability than the accumulated leap seconds over a century.
There are very few times and places on earth where the sun is directly overhead at noon. For example, solar noon is at a different time depending on where within a time zone you live, as well as the time of year.
Where within a city even. Solar noon in london varies by over two minutes depending which end of the district line you are - that’s 5 times the error “corrected” by leap seconds over the last 50 years.
I have always thought the fork() interface was convoluted, perhaps it is more intuitive to some folks than me; using a old document to create a new one by copying it, opening it, and deleting its contents is not something I had considered.
Weakly, yes. Enough to hold its own mass at rest, but I don't think it would work with any type of acceleration. It will stick nicely to a neodymium magnet.
I'd expect sticking the tag to some ferromagnetic surface, such as a fridge door, by the magnet to have about the same effect as gluing the tag to that same surface would which I would guess would be none.
Generally in a permanent magnetic speaker the permanent magnet is solidly affixed to the speaker housing.
The part that actually moves to make sound (the diaphragm) has a coil attached to it. The signal is sent through that coil, which produces a variable magnetic field that interacts with the fixed magnetic field of the permanent magnet.
This interaction produces a force that moves the coil, and thus also moves the diaphragm producing sound.
You could probably design a speaker where the coil is fixed and the magnet is attached to the diaphragm, but that is generally not done. You want the moving parts to be as light as possible so that it doesn't take a lot of energy to rapidly change their motion.
Consider a speaker playing an N Hz sine wave--it has to change direction 2N times per second, and between each direction change you want it to move far enough to move enough air to for the sound to be easily audible.
If the moving part is too heavy you would need a lot more force to accelerate it enough to move far enough to move enough air in the short time you have in order to reach a specified loudness, and then it would take a lot of energy to quickly change direction and do the opposite movement. Hence, the heavy magnet is fixed and the light coil moves the diaphragm).
Microphones are similar. There are moving coil microphones, but I don't recall seeing moving magnet microphones.
You might think it would also be the same with phonograph cartridges, but there you do find both moving magment and moving coil designs [1].
The case I was thinking about was specific to the airtag. In this case a fixed voice coil moves a small permanent magnet attached to the diaphragm rather than the other way around (according to iFixit, quote below). So maybe a rare earth magnet oriented the right way could prevent the magnet from moving. There’s an air gap so it will have to wait until I can do an experiment.
Note from iFixit:
> Did you notice the “button” on the underside of the cover? That’s not a clickable button, like the Mate and SmartTag have, but rather the magnet we saw earlier in the X-ray. It sits right inside the donut-shaped logic board, nested into a coil of copper to form a speaker. You read that right—the AirTag’s body is essentially a speaker driver. Power is sent to the voice coil, which drives the magnet mounted to the diaphragm—in this case, the plastic cover where the battery lives—which makes the sounds that lead you to your lost luggage.
Next, if you really want to time something fast you should probably know about cache. In a modern computer there are levels of memory. For now we’ll say we have 3 levels: cache, ram, and a hard drive. Cache is small but very fast, it is the closest level to the CPU. RAM is bigger but slower and the hard drive is much much slower. Because the cache is small the computer has to pick what’s in it. At program load the cache will be full of information related to whatever was running before you. After you run you will have left some information in the cache which will not need to be fetched from slower levels of memory. Unless your usecase is to run your test code repeatedly very quickly, you should be wary of timing multiple calls in fast sequence as the later calls will execute faster due to the cache being primed to execute your code.
Great point. In addition to caching, there's potential for branch prediction effects.
This is why the JMH samples warn against including loops[0] of the operations you're trying to measure, and have an API that's designed to avoid the programmer having to every write their own looping code.
I'm not sure the JMH is meaningfully included in the JDK for others to use. The JDK happens to come with some JMH-based benchmarks in the source tree, that seems to be about it.
I won one from Sparkfun and just recently started using it. I have some experience developing on embedded platforms.
The unit I have was a pain to flash the first time. I guess something got corrupted at some point and I had to recover with a very unreliable process from a Debian box. That said after the first flash, everything install wise has been wonderful.
The development environment is great for my purposes, however setup was non-trivial. Had I not been comfortable in eclipse I doubt I could have gotten the ld flags set correctly, or changed the c++ std for the compiler.
