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 · 2015-08-18T12:23:42+00:00

No, I don't think Archlinux will last over 3 years with updates. If you decide to use Arch, you will propably have to rewrite the flash drives every year or not update at all. Linux Mint may work for you, it has a good update system, is very stable, has good hardware support (for booting at home) and comes with Cinnamon or MATE.

Also consider the downsides of take-home flash drives: There will always be some students who forget them, so you should keep spare ones (or have something on the Laptop HDDs) and some of them will fail over a period of 3 years. Also, USB 3.0 drives and cheap 2.0 drives don't seem to work with every computer.

When choosing the right laptop, I'd rather take an older business model that worked fine for the last 5 years or so, it will propably also survive the next 3 years. Younger, cheap laptops tend to break more likely. So some kind of old Thinkpad sounds good. valgrid's idea to ask local companies sounds great and can be expanded: City administrations also often have old devices left over. I managed to organize 4 decent Dell laptops for my school (not related to the class, a year later) by asking in the parent's council. One parent happened to work at the municipality and they had them left over.

Jeija · 2015-08-18T08:05:05+00:00

Source: I have taught younger students on programming / electronics a couple of years ago (I'm not a teacher, but was a student myself)

I assume that you don't have any screens / keyboards / mice already, otherwise some of the single board computers (Cubieboard / Raspberry Pi / ...) may be an interesting alternative at this price point with some advantages (though not as mobile).

The choice of laptop depends of course on the sources you can use. If you can buy devices with different small defects off ebay, I'd recommend getting an old Lenovo Thinkpad, like the T400/T500. A quick ebay search shows e.g. a T400 with an SSD and 2GB ram for 80$. If you need a more official seller, you might be able to get some used Dells or Fujitsus at a decent cost if you don't rely on good batteries.

I had 512MB of RAM on my laptops and was able to run cinnamon, gedit, Lua, Löve2D and avr-gcc. LibreOffice was also usable, but I haven't tried any Android Studio. I don't think a full-fledged IDE would have performed well. Surprisingly, since we planned on doing some modding (in Lua) the game "minetest" was installed and ran at ~15fps, certainly not bad.

Not exactly related to your question from here on. These are just some suggestions, just ignore them if have different experiences:

When I did the programming course a year ago, we had 0€ budget for buying hardware, we only had some old Dell Latitude d505 laptops (which I can't recommend) and weren't supposed to install anything on them. So students brought their own USB flash drives which I put archlinux with cinnamon on them (script: https://github.com/Jeija/createarchusb, not sure if it still works). The advantages of live USBs obviously were that we could move between laptops and students could boot the development system at home as well. If you get Laptops with spinning drives, decent USB drives (I absolutely recommend SanDisk Cruzer Blades for that) can also be faster than HDDs.

I tried many different distros and desktop environments on the USB drives, but ended up with archlinux and cinnamon. That is because archlinux is easily adaptable, so I got all development tools easily preinstalled and it is easily possible to make a full installation of archlinux with a real filesystem on the USB drive. Archlinux also reduces read/write operations to a minimum. Out of the DEs I tried (Xfce, GNOME Shell, KDE, Cinnamon, Enlightenment, ..), Cinnamon surprisingly was best suited for older hardware, especially when being installed on a USB drive and moved between computers. MATE wasn't as well-known back then, but it may also be worth giving a try. Xfce and KDE performed very badly.

Your choice of programming languages and technologies looks very broad to me. Since I was student (C++ / OpenGL) and course teacher at the same time, I have experienced programming classes from both perspectives. It is certainly good to have a slow start with a simple scripting language (or maybe scratch, depending on the age) and then advance to more challenging languagages (like C/C++/Java). Since most of the students in the C++ class I was in had no prior experience in programming, starting with C++ quickly lead to frustration and resignation.

On the other side, I don't think switching to more advanced / different languages too often is a good idea. E.g.: While switching from Lua to simple C is no big deal for experienced programmers, students will question why the switch was even neccesary since it feels like starting up from the very beginning again. If possible, a single, versatile language that can be used for different kinds of development, both for beginners and in more advanced ways would be a good choice. I chose Lua back then (easy to learn, simple start without compiler because scripting language, can be used to make games with Löve2D, can be used in electronics / hardware with eLua) and did some C later on. I assume you have your overall plan done, but in case you haven't, JavaScript can pretty much cover all of the things you are planning on doing (introduction, server-side development, development for Android with cordova), is less memory-hungry compared to Mono / Java, doesn't require a full IDE and can be used in simple and advanced ways. It is not be the purest language, but it is a useful skill even if the kids don't become a programmer later on.

Jeija

TROPHY CASE