Sestriere: A native MeshCore client for Haiku

Software
1

Hi everyone,

I’m happy to introduce Sestriere, a native Haiku client I’ve been developing for MeshCore networking devices.

Sestriere allows you to communicate over LoRa mesh networks using MeshCore-compatible radio modules. I wanted to create something that wasn’t just a port, but felt like a true Haiku application, integrating deeply with the system’s unique features like the People app and attributes.

Hardware

For my development and testing, I’ve been using an Heltec V3.2 board. The app communicates with it flawlessly via the standard Haiku USB serial driver (typically found at /dev/ports/usb0 https://www.studiobernardi.eu/Tatooine/Sestriere/haiku-usb-serial-fix.zip ).

Features:

  • Native Contact Management: Contacts are synchronized from your MeshCore device and saved as native Haiku People files with custom attributes.

  • Messaging: Supports private encrypted Direct Messages (DM) and Public Channel broadcasts.

    screenshot7
    screenshot71024×768 92.4 KB

  • Persistence: Your chat history is saved and restored between sessions.

  • Dynamic Network Map: A real-time visualization of the mesh topology. Nodes are positioned based on signal strength (RSSI) with animated pulses for network activity.

    screenshot9
    screenshot91024×768 114 KB

  • Device Stats: A dedicated window for detailed radio performance, including SNR, channel busy, and battery monitoring.

  • Desktop Notifications: Get notified when a message arrives while the app is in the background.

  • Trace Path: Visualize the exact route a packet takes through the mesh to reach a contact.

Installation & Usage

  1. Connect your Heltec or MeshCore-compatible device via USB.
  2. Launch Sestriere and select the serial port (e.g., /dev/ports/usb0).
  3. Choose your regional radio preset (EU 868, US 915, etc.) and hit Connect.

Keyboard Shortcuts

The app follows Haiku standards for a fast workflow:

  • Alt+R: Sync Contacts
  • Alt+M: Show Network Map
  • Alt+S: Device Statistics
  • Alt+T: Trace Path

Source Code / Binary: https://www.studiobernardi.eu/Tatooine/Sestriere/Sestriere-1.1-haiku.zip

I would love to hear your feedback, especially if you have different LoRa hardware to test with!

Cheers,

21 Likes
2

These screenshots, alone, made me check about MeshCore map around my area to see if it’s time to buy some LoRa devices…

1 Like
3

It’s not clear: one must patch and rebuild Haiku’s usb driver, or the needed patches are already intégrated in latest Haiku builds, and in such case, since when?

4

Hi @Phoudoin, unfortunately my Heltec v3 doesn’t work without that patch; the USB serial connection doesn’t throw an error, but it just won’t function. :frowning:

I’m not sure if @waddlesplash would be willing to take a look and integrate the patch into Haiku, but I’d be really grateful if they could :slight_smile:

5

The USB serial driver is more @PulkoMandy’s area than mine. Perhaps he might take a look? At first glance the issue the patches are trying to fix looks sensible, but I don’t know if this is the proper fix or not.

According to what I can see from the patch, there actually should be errors in the syslog about failures to queue interrupt transfers or something like that on an unpatched driver. Is that the case?

1 Like
6

Sorry for not opening a ticket, but I have no idea how many nerds actually use a Heltec module with Haiku :smiley:
Above all, I’m not sure if the style and approach are correct, but I know for sure that without these changes, the device won’t connect properly. :sweat_smile:

If I can, I’ll try running it without the patch tonight and send you the syslog :slight_smile:

7

It looks good to me, except for the removal of the early exit from the loop looking for endpoints in Silicon.cpp (ìf (fPipesSet >= 3)). The check can be changed to check >= 2 instead. This allows to stop as soon as we have found the two needed endpoints and not look for more.

The errors are listed in the HAIKU_USB_SERIAL_FIX.md file (assuming it is correct).

4 Likes
8

photo_5785263833696898390_y
photo_5785263833696898390_y1024×768 113 KB

Version 2 is almost ready! Now we can view node telemetry, create a map of the mesh network we’re connected to, and send data via MQTT to global map services. It also features a packet analysis system and plenty of other goodies. :blush:

Now I just need someone to test it on a busy MeshCore network to see if it explodes or actually manages to generate a map with more than 3 nodes (LOL)

8 Likes
9

Maybe it’s a good time to contact meshcore.co.uk to notify about the existence of a mesh core software for Haiku.

This could improve the audience beyond the Haiku community alone…

5 Likes
10

I agree, it’s a great idea to reach out and give Haiku more visibility. However, I’d like to run a few more tests before making it official. :slight_smile:

I’ve just finished implementing delivery receipts to track if messages arrive and how long they take.

2 Likes
11

Bravo Andrea!

2 Likes
12

Quick update: Sestriere can now interact with MeshCore repeaters to send CLI commands and configure them over the MeshCore network. I’ve also started adding some icons and minor features for everyday use.

photo_5805157774319619542_y (1)
photo_5805157774319619542_y (1)1024×768 100 KB

13 Likes
13

@Andrea It looks like my machine doesn’t need the USB patch. I don’t have the devices yet, but plugged in a regular ESP32 and it is seen by both the system and by Sestriere.

term_usb
term_usb716×793 52.6 KB

ses_log
ses_log600×350 13 KB

So hopefully I’ll be good to go when the Heltec boards arrive!

1 Like
14

I got a Heltec device the other day, flashed it, and hooked it up to my Haiku box (without the USB patch) and it seems to work. There are no other nodes anywhere near me. According to the Meshcore site map, there should be a repeater in the same town. But, I’m also getting a poor signal strength warning.

1 Like
15

Just ordered two Heltec V3’s. I’m very curious if I would be in range of repeaters and such and how this all behaves on Haiku :smiling_face_with_sunglasses: (Looks like the Netherlands has activity enough (?))

1 Like
16

SiliconDevice::AddDevice() in Silicon.cpp calls SetControlPipe() on a BULK OUT endpoint, then SerialDevice::Open() calls queue_interrupt() on that pipe. The USB stack correctly rejects it because it’s not an interrupt endpoint.

Syslog shows:
usb_serial: Silicon Labs CP210x USB UART converter (0x10c4/0xea60) added
usb_serial: failed to queue initial interrupt

The device node never becomes usable.

Root cause:

CP210x chips only have two BULK endpoints (IN + OUT) — no interrupt endpoint. Unlike ACM or Prolific devices, all control operations go through USB control transfers. But SiliconDevice::AddDevice() assigns the BULK OUT handle to both fControlPipe and fWritePipe, and requires pipesSet >= 3 even though only 2 endpoints exist.

The fix (two files):

  1. Silicon.cpp — Remove SetControlPipe() call, change threshold to pipesSet >= 2
  2. SerialDevice.cpp — Add if (fControlPipe != 0) guards before queue_interrupt(), cancel_queued_transfers(), and in _InterruptCallbackFunction()

Note: FTDI.cpp has the same pattern and could benefit from the same fix.

Tested on: hrev59375, Heltec LoRa32 V3.2 (VID 0x10c4 / PID 0xea60)

2 Likes
17

1000386297
10003862971920×1446 360 KB

1000386301
10003863011920×1080 430 KB

4 Likes
18

photo_5846214165566000428_y
photo_5846214165566000428_y1024×768 219 KB

6 Likes
19

Looks super–It just keeps getting better! I can’t wait until my devices arrive…

20

It will depends on which USB UART chip is actually on the device, as ESP32 don’t do itself the UART part, only the USB bus controller.

If you have another board with an ESP32 on it, this board could use a different kind of USB UART chip.