Best way to structure data
Hard limits:


JOINs, including implicit ones in Views: 61.  
Columns per table &lt; 1000 (1017 in 5.6.9, InnoDB); 2598(?) for MyISAM -- But don't use MyISAM.
others


But why do you need a lot of JOINs?  Please elaborate on the schema (SHOW CREATE TABLE, leaving out many of the columns) and SELECT (leaving out all but a couple of representative JOINs).

Do you actually do arithmetic or searching in MySQL on the 240 readings?  If not, simply pack them in a JSON string and let the app break them apart.  Further, compress the JSON string (in the client) and store in a BLOB.  (Smaller --> faster)  PHP would have no problem unpacking 4000 fields with json_decode().  And it could be in the desired structure (array / hash / nested arrays / etc)

The main thing is to structure the schema for what works well in the database, then leave the rest for the application.  The database is a repository; the app is the compute engine.

One table per hour or one table per location -- this smells bad.  One table per location per hour would be really bad.  Once you have thousands of tables in a database (or thousands of databases), the OS gets sluggish in accessing them.

So... 3 (or 1?) tables with


location_id (normalized, to save space)
hour (probably a DATETIME)
one (or a few or maybe 80) JSON strings each with 87(?) numbers, structure for the convenience of the app.


(Sorry, I got lost in the dimensions -- 3 somethings * 80 something else * 87 * 52 * ???)

Plus, PRIMARY KEY(location_id, hour) (or possibly in the opposite order.  And (probably) a plain INDEX with those columns in the opposite order.  Pick the order in the PK based on which order is more important for the SELECTs.  (Don't worry about INSERTs.)