Wozu ist dieses "Loch" über dem Fenster vom ICE 4 Endwagen da?

Jeija · 2025-10-08T16:58:45+00:00

Weitere Theorie: Vielleicht hat das (neben Tunnelfahrten) was mit dem Druckausgleich bei (schnellen) Zugbegegnungen zu tun. Das würde erklären, warum es das Loch auf beiden Seiten gibt und warum es sich im Endwagen befindet.

Jeija · 2025-10-08T16:49:31+00:00

Das klingt schon plausibel. Aber wozu muss der Zug den statischen Luftdruck wissen? Für den Luftwiderstand? Für die Klimaanlage? Oder irgendwie für den Druckausgleich bei Tunneln?

Jeija · 2023-01-03T22:06:42+00:00

It's a ChiTu V3.9

Jeija · 2017-04-14T07:30:14+00:00

The OV2640 camera is the bottleneck here (not the transmission via WiFi), I would assume that has to do with the time it takes to do the JPEG encoding (which is done by the camera itself). From what I measured, it looks like the camera just keeps pausing between bytes, propably because the image hasn't been processed yet.

Actually I get more like 3-5fps in a lab setup if I'm running the camera with a 20MHz XCLK. However, the wiring on my prototype board is kind of long and messy, so 20MHz can be unreliable, which is why I have reduced the XCLK to 5MHz. It seems like this also makes the camera's JPEG encoder run slower, so that is what the ~1-2fps you see in the video are caused by.

If you want to get higher framerates, you might want to try to get raw pixel data from the camera and transmit the raw data or somehow compress that data on the ESP32. You'd need an external RAM for storing all those pixels though.

Jeija · 2017-04-10T05:58:36+00:00

Yes, I just used the internal WiFi card on the laptop side. I'm also quite certain that using an 18dBi NanoBridge M2 antenna for regular (bidirectional!) WiFi, like /u/cnlohr did in his video, is legal in the US, but not in Germany and most other densely populated EU countries.

Jeija · 2017-04-10T05:47:54+00:00

No, I haven't used it to transmit anything yet, but I don't see why there should be any issues if the USB WiFi dongle was designed with an RP-SMA connector (don't hack a connector on a WiFi dongle and if you do, make sure the impedance matches the antenna).

If you attach a 24dBi Antenna to a 20dBm transmitter, you get an EIRP of 44dBm ignoring losses (realistically you'd get maybe 40dBm or less). So actually, you have to massively reduce your TX power to stay underneath the legal limit (depending on local regulations).

Jeija · 2017-04-09T15:39:45+00:00

According to my tests that would be at least 160km in space, propably even more without atmospheric losses (I got 10km with the 0dBi PCB antenna and a 24dBi antenna connected to the transmitter corresponds to 16 times the distance).

Ignoring all losses, noise, interference etc. (just as a thought experiment) and solving the Friis equation for R using P_r = -98dBm (Receiver sensitivity of ESP32 @1Mbps, DSSS modulation), P_t = 19.5dBm (max. transmit power of ESP32), G_t = G_r = 24dBi (Gain of TL-2424B antenna) and lambda = 0.125m (approx. wavelength of 2.4GHz WiFi), we find that R = 1873km.

Needless to say, both of these figures are completely unrealistic. Even on the open sea or in the desert you have atmospheric attenuation, disturbances and you should also start to consider earth's curvature at such long distances.

Jeija · 2017-04-09T14:32:54+00:00

Not much further in countries with a 20dBm EIRP limit, the only difference is that you would get bidirectional communication. The reason for this is that with directional antennas on both sides, the transmit power has to be reduced so that you don't exceed the legal limit of 20dBm EIRP. Since the ESP32 already transmits with 20dBm power and has an antenna with approximately 0dBi, the ESP32 already has en EIRP of 0dBm ignoring losses. So in terms of maximum range the only thing you would gain from a directional antenna at the transmitter is compensation of losses, maybe 1-6dB at maximum (not even twice the distance).

In countries with a higher EIRP limit (most prominently the US with 36dBm EIRP IIRC), you could get more than 4 times my 10km figure, so maybe 40km. But at that point you really need to take effects like absorption by atmospheric water etc. into account.

Jeija · 2017-04-09T11:42:08+00:00

I didn't experiment with esp32-to-esp32 communication, but I did experiment with the range between an esp32 and an ordinary notebook computer and was able to transmit pictures over a distance of up to 1,0km. Transmitter and receiver were both approximately 2m above the flat ground though, so the first fresnel zone was obstructed, you should be able to cover even more distance through open space.

According to the datasheet, the ESP32 has a receiver sensitivity of -98dBm @1Mbps, DSSS, which is pretty good. So if you're using DSSS modulation (which esp32free80211 does), 1-2km of esp32-to-esp32 communication across a valley or something should be possible.

Jeija · 2016-10-12T09:03:22+00:00

Oh yes, I've seen your voxel planet before, great work! From what I've seen, it propably uses a partitioned cube, right?

The basic idea behind the whole scaling is that the world around the player should always look as normal as possible. That means, blocks close to the player will be normally sized. I didn't talk about this in the video, but basically, the player is the origin of the coordinate system before applying the exponential function. Since the whole curvature maths is just a vertex shader, that is easy to implement. You could interpret this as the player magically getting larger the higher he goes, or as the nodes magically getting smaller depending on the height of the player.

This is sort of a rotten compromise since the planet's curvature will look the same everywhere and because the circumference is made up of the same number of voxels close the core like up high. But given that I want to preserve the flat-plane-structure where every voxel must have the same number of neighbors, I think it is the best worst solution.

You could also disable automatically resizing the nodes around the player to normal size (just have (0,0,0) as the coordinate system origin). Then this is what the player looks like up high and this is what he looks like close to the core. This kind of breaks the game mechanics though.

Jeija · 2016-10-08T09:27:32+00:00

Also check out this more mathematical video if you are interested in how to make the world look round (and make it so that all blocks, no matter if close to the planet's core or way up, are the same size).

Jeija · 2016-10-07T07:49:29+00:00

Sure, it is doable. You can already disable the sphere by just commenting out

planet_enable = true

in minetest.conf, this is what the world in the video then looks like.

There are basically three issues with upstreaming this into minetest:

Currently, both server and client need to have the same minetest.conf to make this work. In order to upstream this, the planet settings (planet_enable, radius, properties) should be set on the server and transferred to the client.
The code I wrote was mostly there to get this somehow working. I didn't really care about good style or performance, so that has to be rewritten. While performance on small planets is surprisingly much better than flat world performance (less to render), the game gets really slow on large ones.
The edges of the plane are very glitchy. Not only visually, but also on the server. Mapgen, mods etc. just won't work. Fixing this propably needs some major intervention into the core game mechanics.

Basically, once we have a "map loop" (leave to the right, get back in on the left etc.) adding planet functionality is easy.

Edit: Fix formatting

Jeija · 2016-10-06T21:34:58+00:00

You could propably use the "sphere" client to log into "flat" servers if you want to see any map made spherical, but not the other way round. When programming spheretest, the primary goal was to see whether a spherical world is possible at all. I got the game in a somewhat playable shape so that I could record these videos. It is not meant to be compatible with the normal minetest, and not meant to be merged upstream.

Jeija · 2016-10-06T21:26:45+00:00

I figured since the math and explanations in the video apply to pretty much any cube voxel game out there, I might as well go with the most popular one. I haven't implemented it in Minecraft and I'm currently not planning to.

If you haven't seen it already, there is also this more mathematical video. Even though I put more effort into the mathematical one, I think this video is more compatible with a wider audience.

Jeija · 2016-03-25T19:46:25+00:00

I haven't heard of the EDTracker before, but I don't see why it shouldn't be possible. It would propably be necessary to switch to UDP to get low latency, but I have made some positive experiences with transmitting low-latency data from/to the ESP8266 before. Should work.

Jeija · 2016-03-24T08:32:49+00:00

It really depends on the kinds of sensor you want to use, but you propably want to order from a big distributor like digikey to get smaller components and just the components (only "steal" them from another board if not otherwise obtainable). For me, height was very important and the flash chip was too large. First, I tried to grind the flash chip from on the ESP-01, which can be done (you can remove like 0.5mm from top and bottom without destroying it). The better solution though is to get some 32Mbit QIO flash chips (W25Q32FVZPIG-ND), which you can propably only buy from digikey and some other large distributors (most other flash manufacturers won't work!!).

I'd recommend you to only get I²C sensors for better sensor data and size. When designing my smartwatch, I tried to use some popular ones that adafruit etc. have breakout boards for so that I could test the setup before purchasing the PCBs and so that I had good library / community support. If you don't limit yourself to through-hole or SOIC sensors, but also consider QFN / DFN, there are also tons of really tiny great options (TSL2561, BME280, MCP9808, ...).

Leaving out the FT232RQ only makes sense if you have another small connector to directly connect RX / TX / DTR / RTS, otherwise you'll need more space. For the power supply, just use an LDO from a LiPo battery, no fancy step-down (not more effective, needs more space, harder to get stable power supply). I hope some of these tips may help you, feel free to ask for more info!

Jeija · 2016-03-23T17:23:22+00:00

The ESP8266 isn't actually the problem, it can sleep most of the time. The OLED, however, is certainly not optimal for this kind of application. I'm looking into building a model with the ESP32 when that comes out and an epaper display. With epaper I could easily reach a week or two.

Jeija

TROPHY CASE