Skip to content

v0.1.0-alpha.1

Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 08 Oct 14:10
· 195 commits to main since this release
156afb9

The first build meant for someone other than its authors: two Heltec WiFi LoRa 32 V3 boards that
find each other, set up a session and send each other encrypted messages, driven from a web page.

It is an alpha. The protocol is a draft and will change, and a later build may not talk to this
one or keep its sessions. Nobody outside the project has reviewed the cryptography. Do not rely
on it for anything that matters.

What you need

  • Two Heltec WiFi LoRa 32 V3 boards (ESP32-S3 and SX1262, the 863-928 MHz kind), each with its
    antenna fitted. Never power a board with nothing on the antenna connector.
  • Chrome or Edge on a computer, and a USB cable that carries data.

Flashing

Take the image for where you are. A board sends on its region's frequency as soon as it starts,
so the wrong image breaks the rules of the place you are in.

tern-heltec-v3-us915-0.1.0-alpha.1.bin United States, Canada: 921.25 MHz
tern-heltec-v3-eu868-0.1.0-alpha.1.bin Europe: 869.475 MHz, at most 10% of any hour

Write it at address 0x0, with esptool-js in the
browser or esptool.py write_flash 0x0 <image>. This replaces whatever is on the board,
Meshtastic or MeshCore included, and the board starts with a new address. The
port's README
has the steps.

The -app.bin images are the application alone, for a board that already runs Tern: written at
0x10000, they leave its address, sessions and contacts as they are.

SHA256SUMS has the SHA-256 of each image.

Using it

Open https://ternmesh.org/app and press Connect over USB. Add the other board as a
contact by its address, which its own page shows, and send it a message. The first message
makes first contact, which takes a few seconds; after that a message is delivered when the other
board's acknowledgement comes back.

A board with no session accepts whoever makes contact with it. One that already has a session
refuses a board it does not know until accept is typed on its serial console, which lets one
in for two minutes. So a third board needs a terminal for now.

The serial console (115200 baud) does all of this from a terminal as well: the
port's README
lists the commands.

What is in it

  • First contact and encrypted, acknowledged messages between boards, with a session with each of
    up to eight others.
  • Routes: boards announce themselves, a message follows the route to its destination, and a
    board built as a relay passes others' frames on.
  • Listening first: a board sends nothing while its radio is receiving a frame.
  • The companion link over USB and Bluetooth LE, and the web client over USB.

What is not

  • First contact does not follow routes. Two boards must hear each other directly to meet.
    Once they have, messages between them may go through relays.
  • No group or broadcast messages. Every message is to one address.
  • Messages are kept only in memory on the board. The web client keeps what it has seen in
    the browser; a message that arrives while no client is connected is lost if the board restarts
    before one connects.
  • A session cannot be ended from the web client, only from the console (drop).
  • The web client does not use Bluetooth yet, so there is no phone client.
  • Transmit power is 2 dBm, a bench setting that reaches across a building, not a town. The
    web client cannot change it yet; a client that speaks the companion protocol can (SET 3), as
    can a build of your own.
  • The web client cannot let a new board in once the board has a session: that takes
    accept on the console.
  • Keys sit in flash unencrypted. Anyone holding the board can read them.
  • One board only. An nRF52 port is next.