Is TEA suitable for encrypting/authenticating many short messages? I know that TEA has its weaknesses, but is easy to implement. My question is whether it would be suitable for my use case: The main reason for using encryption is not so much secrecy, but authentication and protection against interference.

I have a number (max 20-30) of GPS trackers, which send their location by radio in intervals to a base station.
Each message consists of a tracker ID, a timestamp, the location, and a checksum, so max 16 bytes, but in a fixed format.
Each message will be similar to the previous one, as the time increment will be constant, and the location will not change very much between two subsequent messages.
The time frame is about three hours, with probably about 800 messages sent per device during that period. So roughly 20k messages in total.
the code of the system will probably be public (so security through obscurity will definitely not work)

What I want to avoid from happening is anyone sending fake messages that are mistaken for real positions; decoding the message content is not a problem, as anyone can observe the trackers moving around anyway if they wanted to. So if it takes more than three hours to crack the key and enable sending fake messages, that would not be an issue, as that means the window in which a single key is used would be over.
I guess what I really need to know is:

Is TEA (or XTEA, or XXTEA) at all suitable for this use case? And if so, vanilla or X/XX? Or is there another algorithm that would be better suited? For example, just a hash checksum?
Are there any other ways I could improve security (eg use a different key for each tracker, randomly vary the format of the message (location first vs timestamp first), compress the message (only store difference to previous location, eg, to remove some redundancy))

My main design goals are reasonable security (it's competitive sports, not secret missile plans), simplicity of use and implementation (I am a developer, not a cryptography expert), and low computational overhead (this will run on an ESP32 micro-controller).
I have some basic thoughts on this, but would appreciate some expert advice!
UPDATE: Since this was asked in one of the answers: the trackers will be initialised in close proximity on power-up, and the base station can transmit a 'secret' key via Bluetooth Low Energy to each tracker. I do realise that Bluetooth is not really secure, but given the proximity this is in my view a negligible risk.
The main reason for using encryption is not so much secrecy, but authentication and protection against interference.

In that case, what you want is an authenticated encryption scheme.  While TEA, as a block cipher, may be used to implement such a scheme by using it in some suitable AE mode (such as SIV), there are also a number of dedicated lightweight authenticated encryption schemes that you may wish to look into.
In particular, I'd suggest taking a look at Ascon, which was selected as the primary choice for the use case 1 (lightweight authenticated encryption) in the final round of the CAESAR competition last year.  While not quite as simple as TEA, the reference implementation isn't all that complicated.

Since your message length is fixed and very short, you could obtain a simple authenticated encryption scheme just by using a block cipher with a block size longer than your message length, padding your messages up to the block size e.g. with zero bytes, encrypting the padded message directly with the raw block cipher (i.e. in &quot;ECB mode&quot;) and verifying the correctness of the padding after decryption.
However, for this you'd want a block cipher with a block size of (at least) 128 bits (= 16 bytes), which TEA doesn't have.  XXTEA could work, though.
With 4 bytes of padding, the odds of an attacker randomly guessing a valid ciphertext would be 1/232 per attempt, which seems likely to be low enough for your purposes.  This would be a deterministic encryption scheme, so it would leak whether or not two plaintexts are equal, but that shouldn't be an issue for you since your messages include presumably unique timestamps anyway.

As for the security of TEA or other crypto primitives for your purposes, the first thing I'd like to note is that it seems extremely unlikely that anyone would develop and implement a novel cryptanalytic attack just to interfere with your system.  Thus, you should be fine as long as the scheme you're using:

has withstood any serious cryptanalysis at all (i.e. it's not just some random homebrew cipher kludged together by someone with no crypto experience),
has no known practical attacks (i.e. with complexity well under 264 or so operations) with published attack code that someone could just download and run, and
the way you're using it isn't broken in some way that would allow someone to bypass the actual cipher entirely.

In fact, you might be fine even if one or more of the above happened to be false, as long as none of your potential opponents has the skills or motivation to analyze your scheme and develop an attack against it.  But as long as you're using a cipher with no simple practical attacks, and use it correctly, you should be safe even if someone with some crypto skills does decide to try to attack your system.
Honestly, your biggest weakness is likely to be the last point.  That's how most cryptosystems get broken in practice — not by breaking the underlying ciphers or other crypto primitives, but by finding bugs or design flaws in the way they're used.
To give a simple analogy, the strongest lock on your door won't help if you leave a window open or leave the key under your doormat.  With crypto, as with physical security, the whole system is only as secure as its weakest link.  And the weakest link in your system is almost certainly not the block cipher, whether it's TEA or AES.