Nyt isoja uutisia!

Firmani (Paxsudos IT) saa käsiinsä rautaa jonka avulla voin kommunikoida satelliittien kanssa!

Tuo tulee kovaan käyttöön, kun saan sitten aivan kaikki tukemani siirtotiet (ETH/LTE/SAT) testattua ja mitattua.. Julkaisen raaka-mittaus tulokset omana metriikkanaan, ja vertailu sivuston teen, jossa voi verrata kaikkien noiden siirtotapojen toimintakykyä verrattuna toisiin.

… Sitten alkaa STCP:n kehitystarina olla päätepisteessään ja siirtyy bugi korjaus moodiin.

MUT nyt voi sanoa, et kohta on se hetki kun samppakaljaa pienen pullon sihauttaa 🙂

Onhan tuota STCP:tä tullu tehtyä jo pari vuotta, ja koodia pirusti, noin 80k riviä.

Erityiskiitokset kuuluu Äidilleni, Isälleni, Spotille ja Manelle! Tietäjät tietää keille! 😀

STCPv3 is now READY!

🛰️ STCPv3 is being built satellite-first.

Satellite communication makes one design constraint impossible to ignore:

Every bit on the wire costs.

Bandwidth is limited. Airtime matters. Radio transmission consumes energy. On constrained and long-distance links, protocol overhead that looks insignificant on Ethernet can become something worth eliminating.

That principle has become a major design driver for STCPv3:

Transmit as little as possible while keeping the protocol useful.

STCPv3 already uses a compact 17-byte wire header. Now v3 adds another tool specifically suited to constrained links: optional automatic payload compression.

Compression is controlled per socket. An application can enable or disable it and define a payload-size threshold for when compression should be attempted.

And there is an important rule:

If compression does not make the payload smaller, STCP sends the original payload instead.

In other words, compression is there to save bytes — not simply to say that compression is enabled.

The first full compression interoperability tests are now passing across Linux and Raspberry Pi with both STCP-TCP and STCP-UDP.

The latest test run produced:

16 / 16 payloads compressed successfully
98,816 bytes → 1,156 bytes
97,660 bytes avoided on the wire
98.83% payload reduction
0 compression errors
0 decompression errors

The payload in this functional test is intentionally highly compressible. 98.83% is therefore not a claim about the compression ratio of arbitrary real-world traffic. Real-world savings depend entirely on the data being transmitted.

What the test demonstrates is that STCPv3 can automatically compress suitable payloads, transport them and reconstruct the original data correctly end-to-end.

And the complete STCPv3 regression suite remains green:

Linux / Raspberry Pi ✅
Zephyr / nRF9151 ✅
CoAP ✅
MQTT ✅
P2P 3-node ✅

Next comes benchmarking with different payload types and frame sizes to quantify the benefit under more realistic traffic patterns.

The direction for STCPv3 is very clear:

Satellite-first networking.

17-byte wire header.
Optional automatic payload compression.
Compression only when it saves bytes.
Linux, Raspberry Pi and embedded Zephyr targets.
CoAP, MQTT and P2P interoperability.

For terrestrial broadband, a few unnecessary bytes may not matter much.

On a satellite link, I want STCP to treat every one of them as something worth avoiding. 🛰️

#STCP #STCPv3 #Satellite #SatelliteIoT #IoT #EmbeddedSystems #Networking #Rust #Zephyr #nRF9151 #LowPower #Compression

STCPv3 näkee kohta päivänvalon!

STCPv3 osaapi automaattisesti pakata lähetettävän datan, jos käyttäjä haluaa. Erittäin hyvä esim IoT-laitteisiin jotka pelaavat radioaalloilla => bytejä aina menee optimi määrä, jos lähtevä data on pakattuna isompi, niin orggis lähetetään, jos ei, niin lähetetään pakattu data.

Vastaanottopuoli purkaa tavaran, ennenkuin ojentaa sitä loppukäyttäjälle. Eli pakkaaminen/purkaminen toimii ’piilossa’ käyttäjältä kokonaan.

Ihan tein satelliitit mielessä ja IoT-laitteet, varsinkin joissa energian käyttö pitää optimoida pieneksi.

Tuossa STCPv3:ssa on vaivaton tapa optimoida todella tiukaksi paketti + tarjoaa AES 256 bit salauksen silti..