Meshcore: observer sobre cliente

EN CONSTRUCCION

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash


export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"

nvm install --lts

curl -fsSL https://raw.githubusercontent.com/agessaman/meshcore-packet-capture/main/install.sh -o install.sh

sudo bash install.sh

rm install.sh 

 Instalando como servicio

  • 1) System service (systemd/launchd) - installs Python dependencies on host
Conexión USB
  •   2) Serial - direct USB/serial cable
  •   1) /dev/serial/by-id/usb-1a86_USB_Single_Serial_5874124874-if00 -> /dev/ttyACM0

Configuracion del primer broker

===================================================

  Configuring MQTT Broker 1

===================================================


Server hostname/IP: broker.livemap-meshcorecat.com

Port [1883]: 8883

Use WebSockets transport? [y/N]: y

Use TLS/SSL encryption? [y/N]: y

Verify TLS certificates? [Y/n]: n


ℹ Authentication method:

  1) Username/Password

  2) MeshCore Auth Token

  3) None (anonymous)

Choose authentication method [1-3] [1]: 1

Username: cat-pub

Password: CatMesh2026pub


===================================================

  Configuring MQTT Broker 2

===================================================


Server hostname/IP: mqtt.meshmapper.net

Port [1883]: 443

Use WebSockets transport? [y/N]: y

Use TLS/SSL encryption? [y/N]: y

Verify TLS certificates? [Y/n]: Y


ℹ Authentication method:

  1) Username/Password

  2) MeshCore Auth Token

  3) None (anonymous)

Choose authentication method [1-3] [1]: 2

Token audience (optional): mqtt.meshmapper.net


Service management:

  •   Start:   sudo systemctl start meshcore-packet-capture
  •   Stop:    sudo systemctl stop meshcore-packet-capture
  •   Status:  sudo systemctl status meshcore-packet-capture
  •   Logs:    sudo journalctl -u meshcore-packet-capture -f


✓ Installation complete!

Diredctorios

ℹ Installation directory: /opt/meshcore-packet-capture

ℹ Configuration directory: /etc/meshcore-packet-capture


Referencias


Advertencia importante

Las modificaciones, configuraciones y procedimientos descritos en este sitio pueden implicar riesgos técnicos, legales o de seguridad. El autor no se responsabiliza del mal funcionamiento de los equipos, daños permanentes, pérdida de garantía ni de posibles infracciones legales derivadas del uso de esta información.
El lector asume plena responsabilidad por cualquier acción que decida realizar basándose en el contenido de este blog.

© 2026 EA5JTT. Queda prohibida la reproducción total o parcial sin autorización expresa del autor.

Meshcore: Meshcore packet capture

 Referencias

Advertencia importante

Las modificaciones, configuraciones y procedimientos descritos en este sitio pueden implicar riesgos técnicos, legales o de seguridad. El autor no se responsabiliza del mal funcionamiento de los equipos, daños permanentes, pérdida de garantía ni de posibles infracciones legales derivadas del uso de esta información.
El lector asume plena responsabilidad por cualquier acción que decida realizar basándose en el contenido de este blog.

© 2026 EA5JTT. Queda prohibida la reproducción total o parcial sin autorización expresa del autor.


Meshcore: Obsever

Actualizado a 2/7/2026

Un observer (Observador) es un nodo de la rede MeshCore (Repeater -repetidor, room server-buzón o Companion-cliente) que escucha el tráfico de la malla cercana e informa a uno o mas brokers MQTT por Internet.

Los observers pueden configurarse para compartir solamente los avisos o anuncios (advertisements) sin mostrar el reso del tráfico de la malla.

Una vez creado un observer, el propietario puede gestionar si quiere compartir los datos o no con un determinado broker (procesador que centraliza y explota los datos recibidos).

Los tipos de mensajes que genera un observer son:

  • INFO - [SERVICE]: informa sobre los aprametros de servicio (numero de mensajes recibidos y trnasmitidos, numero de brokers o MQTT conectados , numerod e falolos, etc. en un intervalo de tiempo (p.e. 5 minutos)
  • INFO - [DEVICE]: informa sobre los parametros de funcionamiento delnodo (Nivel de ruido, tiempo en el aire en TX y RX, estado de las baterias, etc.
  • INFO -[SERIAL]: Informa de los parámetros de los  paquete o mensaje recibido 
  • INFO- [MQTT]: informa de los paquetes publicos

Fuente: https://www.lorameshdevices.com/blog/meshcore/how-to-build-a-meshcore-observer-with-heltec-v3.html

El observer tiene dos funciones o partes

  • El NODO que se encarga de la recepción de los mensajes de la malla
  • El GATEWAY que se encarga de enviar al servidor la información de funcionamineto del NODO y del GATEWAY y la información de los mensajes publicos y provados recibidos al MQTT BROKER para que los procese

Así para  configurar un OBSERVER tenemos dos posibles soluciones:

  • Conectar un nodo meshcore a un procesador 24/7 (p.e. una raspberry con el software adecuado y conexión a Internet) (ESTA ES LA SOLUCIÓN QUE SE VA A ANALIZAR EN ESTA ENTRADA)
  • Crear un único dispositivo especifico OBSERVER sobre un hardware capaz de soportar ambas funciones (ESTA SOLUCIÓN NO SE VA A ANALIZAR EN ESTA ENTRADA)


OBSERVER: Nodo + procesador 


- Nodo

Se trata de un nodo estándar sin nada especial como los que hemos visto en Meshcor: montando una red y en Meshcore: Repetidores. En concreto uno con versión 1.6.1 como repeater / companion sobre una Lilygo LORA 32 T3_V1.6.1

Se ha optado por un NODO REPETIDOR.

En las pruebas con una placa Lilygo LORA 32 T3_V1.6.1 que se uso como repeater  y como companion noera capaz de proveer al procesador de los mensajes. Es como si no soportara el juego de instrucciones que posibilita el trafico de los mensajes mientras que los de informaión sobre el estado de la placa lo hacía sin problemas.

Se va a probar con un nodo  "XIAO ESP32S3 & Wio-SX1262" y así determinar si es un problema del hardware/firmware de la lilygo  o un fallo en el proceso de instalación/configuración


- Un procesador funcionando 24/7 con conexión a Internet

Hemos optado por compartir una Raspberry Pi 3B en la que ya se ejecutan otros programas.

El programa puede instalarse como

  • Manual
  • Como servicio
  • Como docker (la tendencia actual al aislarse la instalación del entorno).
Se pueden compartir varios tipos de instalaciones teniendo el cuidado de para servicios y dockers para que no se interfieran unos en otros al compartir recursos.

Preparando la instalación

  • sudo apt update
  • sudo apt install -y python3 python3-venv python3-dev build-essential
  • python3 --version    # ha de ser 3.11+
    • Python 3.13.5

Instalación como docker 

  • Conectar el nodo meshcore a un puerto USB de la Raspberry con un cable adecuado (USB datos)
  • Ejecutar  ls /dev/ttyUSB* /dev/ttyACM* 2>/dev/null
    • Si devuelve algo como  /dev/ttyACM0  todo OK
    • Si no devuelve nada es que no detecta la placa, la causa mas común es que el cable USB sea unicamente de alimentación y no de datos
  • Antes de continuar hay que recopilar la información del broker o brokers MQTT a los que queremos enviar la información:
  • Como consejo pruebe con uno y cuando funcione probar con otros MQTT, se pueden cambiar con facilidad y en cualquier momento y se puede enviar a uno a mas de uno o a ninguno. basta con editar el fichero de configuración y para y arrancar el programas/servicio/docker y esto no afecta al funcionamiento del nodo. Nosotros comenzaremos  por "CATALUNYA" por proximidad geográfica y por tener disponer una detallada  documentación sobre el tema
  • Ejecutar el proceso de instalación curl -fsSL https://raw.githubusercontent.com/Cisien/meshcoretomqtt/main/install.sh | sudo bash
    • Información sobre los directorios de innstalacion
      • Installation directory: /opt/mctomqtt (Por defecto)
      • Configuration directory: /etc/mctomqtt (Por defecto)
    • Usuario
      • Service account username [mctomqtt]: mctomqtt (Por defecto)
    • Elegir el procedimiento de instalación:
    • 1) System service (systemd/launchd) - installs Python dependencies on host
    • 2) Docker container - all dependencies in container (requires docker to be installed) => Se elige esta al disponer ya de docker
    • 3) Manual run only (install files, no auto-start)
    • Solicita el path del USB /dev/ttyACM0
    • Enter your IATA code (3 letters por defecto es BCN - Barceloa, en nuestro caso VLC - Valencia): VLC
      • ✓ IATA code set to: VLC
    • Server hostname/IP: broker.livemap-meshcorecat.com
    • Port [1883]: 8883
    • Use WebSockets transport? [y/N]: y
    • Use TLS/SSL encryption? [y/N]: y
    • Verify TLS certificates? [Y/n]: n
    • ℹ Authentication method:
      • 1) Username/Password
      • 2) MeshCore Auth Token
      • 3) None (anonymous)
      • Choose authentication method [1-3] [1]: 1
        • Username: cat-pub
        • Password: CatMesh2026pub
          • ✓ Broker 1 configured
  • Construir el DOCker
    • docker build -t mctomqtt:latest /path/to/meshcoretomqtt
  • Arrancar el DOCker
docker run -d \
  --name mctomqtt \
  --restart unless-stopped \
  -v /path/to/mctomqtt-config:/etc/mctomqtt:ro \
  --device=/dev/ttyACM0 \
  mctomqtt:latest

  • Gestion del Docker
    • Start:   docker start mctomqtt
    • Stop:    docker stop mctomqtt
    • Status:  
      • docker ps -a | grep mctomqtt
      • sudo docker ps -a | grep mctomqtt

    • Para que no arramque solo cuando se haga reboot
      • docker update --restart=no mctomqtt
    • Logs:    docker logs -f mctomqtt
      • 2026-06-30 18:00:09,319 - INFO - Loaded base config from /etc/mctomqtt/config.toml
      • 2026-06-30 18:00:09,324 - INFO - Loading config override: /etc/mctomqtt/config.d/99-user.toml
      • 2026-06-30 18:00:09,330 - INFO - Configuration loaded from TOML
      • 2026-06-30 18:00:09,333 - INFO - IATA: BCN
      • 2026-06-30 18:00:09,334 - INFO - Serial ports: ['/dev/ttyACM0']
      • 2026-06-30 18:00:09,334 - INFO - Brokers configured: 1
      • 2026-06-30 18:00:09,339 - INFO - Connected to /dev/ttyACM0
      • 2026-06-30 18:00:09,346 - WARNING - timedatectl not found — skipping sync check and continuing.
      • 2026-06-30 18:00:10,352 - INFO - Repeater name: VC.V EA5JTT R8
      • 2026-06-30 18:00:11,356 - INFO - Repeater pub key: ...
      • 2026-06-30 18:00:12,365 - INFO - Repeater priv key: D018... (truncated for security)
      • 2026-06-30 18:00:13,369 - INFO - Firmware version: v1.16.0-07a3ca9 (Build: 06-Jun-2026)
      • 2026-06-30 18:00:13,871 - INFO - Board type: LILYGO T-LoRa V2.1-1.6
      • 2026-06-30 18:00:15,378 - INFO - Device stats: {'battery_mv': 4194, 'uptime_secs': 1947, 'debug_flags': 0, 'queue_len': 0, 'noise_floor': -120, 'tx_air_secs': 10, 'rx_air_secs': 15, 'recv_errors': 35}
      • 2026-06-30 18:00:15,379 - INFO - Client version: meshcoretomqtt/1.3.0.0-preview
      • 2026-06-30 18:00:15,380 - INFO - Remote serial: DISABLED
      • Todo OK
    •   Restart: docker restart mctomqtt

Instalación como servicio (mas habitual)

cd /opt
sudo git clone https://github.com/Cisien/meshcoretomqtt.git
Clonando en 'meshcoretomqtt'...
remote: Enumerating objects: 733, done.
remote: Counting objects: 100% (241/241), done.
remote: Compressing objects: 100% (84/84), done.
remote: Total 733 (delta 198), reused 160 (delta 157), pack-reused 492 (from 1)
Recibiendo objetos: 100% (733/733), 474.00 KiB | 1.21 MiB/s, listo.
Resolviendo deltas: 100% (431/431), listo.
Comprobaciones

cd meshcoretomqtt
sudo pip3 install pyserial paho-mqtt toml --break-system-packages
sudo pip3 install ed25519-orlp --break-system-packages
sudo nano /etc/systemd/system/mctomqtt.service
[Unit]
Description=MeshCore to MQTT Native Service
After=network.target
[Service]
Type=simple
User=root
WorkingDirectory=/opt/meshcoretomqtt
ExecStart=/usr/bin/python3 /opt/meshcoretomqtt/mctomqtt.py --config /etc/mctomqtt/config.toml
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload

sudo systemctl enable mctomqtt.service

sudo systemctl start mctomqtt.service

o

sudo systemctl restart mctomqtt.service


Comprobaciones previas

ls -la /dev/ttyACM*
crw-rw---- 1 root dialout 166, 0 jul  2 11:51 /dev/ttyACM0

sudo journalctl -u mctomqtt.service -f

sudo journalctl -u mctomqtt.service  -n 50 --no-pager


Funcionamiento

El Observer definido para enviar la información de estado y tráfico del repetidor "VC.V EA5JTT R8" al Broker "CATALUNYA" con código "VLC" debe verse en https://www.livemap-meshcorecat.com/ => Analyzer => observadors

Listado de los observers en donde vemos VC.V EA5JTT R8" con la etiqueta "VLC" 



Detalle del un observer de VC.V EA5JTT R8" 


OJO En el mapa  https://mapa.livemap-meshcorecat.com/ solo sale Catalunya


Mas Brokers

Un mismo observer puede publicar en "catalunya", que es el ejemplo que hemos visto, pero tambien en otros BROKERS como LetsMesh, MeshMapper, etc.

MESHMAPPER 

Editar con sudo nano /etc/mctomqtt/config.d/99-user.toml e incluir a continuación (realmente sobre escribe el archivo  sudo nano /etc/mctomqtt/config.toml) :

# 2. BROKER MESHMAPPER (WebSockets + TLS + Token)
[[broker]]
name = "meshmapper"
enabled = true
server = "mqtt.meshmapper.net"
port = 443
transport = "websockets"
keepalive = 60
qos = 0
retain = false

Para  /etc/mctomqtt/config.d/99-user.toml

tls = { enabled = true, verify = true }
auth = { method = "token", audience = "mqtt.meshmapper.net" }"

para /etc/mctomqtt/config.toml

[broker.tls]
enabled = true
verify = true

[broker.auth]
method = "token"
audience = "mqtt.meshmapper.net"  

Se comprueba que arranca con  docker logs -f mctomqtt y tenemos que ver

2026-06-30 19:55:29,438 - INFO - [meshmapper] Connected to broker




LETSMESH 

Editar con sudo nano /etc/mctomqtt/config.d/99-user.toml e incluir a continuación:

# 2. BROKER LETSMESH
[[broker]]
name = "letsmesh"
enabled = true
server = "mqtt-us-v1.letsmesh.net"
port = 443
transport = "websockets"
keepalive = 60
qos = 0
retain = false

Para  /etc/mctomqtt/config.d/99-user.toml
tls = { enabled = true, verify = true }
auth = { method = "token", audience = "mqtt-us-v1.letsmesh.net" }

para /etc/mctomqtt/config.toml 

[broker.tls]
enabled = true
verify = true

[broker.auth]
method = "token"
audience = "mqtt-us-v1.letsmesh.net"  

Se comprueba que arranca con  docker logs -f mctomqtt y tenemos que ver
2026-06-30 20:17:18,656 - INFO - [letsmesh] Connecting to mqtt-us-v1.letsmesh.net:443 (transport=websockets, tls=True, keepalive=60s)
2026-06-30 20:17:18,838 - INFO - [letsmesh] Connected to broker


Tambien aparece en https://vlc.meshmapper.net/

MM de MeshMapper y LM de LetsMesh


Visualizaciones



Resolucion de problemas

1 - ERROR EN LA INSTACIÓN

Si se aborta la instalación, se borran las carpetas y se vuelve a comenzar
  • sudo rm -rf /opt/meshcoretomqtt
  • sudo rm -rf ~/meshcoretomqtt


2 - FALTA DE PERMISOS EN EL DOCKER

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.45/containers/json?all=1": dial unix /var/run/docker.sock: connect: permission denied

  • sudo usermod -aG docker $USER
  • newgrp docker


3 - ERROR EN LOS PARAMETROS DE CONFIGURACIÓN

Observe la estructura de los ficheros de parámetros o definiciones. Existen tres ficheros de configuración que uno sobre escribe al anterior y son comunes a cualquier tipo de instalción (manual, servicio o docker)

# =============================================================================
# MeshCore to MQTT - Configuration Reference
# =============================================================================
# This file documents all available configuration options with their defaults.
#
# Config loading order (default):
#   1. /etc/mctomqtt/config.toml (base defaults, overwritten on updates)
#   2. /etc/mctomqtt/config.d/10-*.toml   (broker presets)
#   3. /etc/mctomqtt/config.d/99-user.toml (local overrides, loaded last)
#
# Put your customizations in /etc/mctomqtt/config.d/99-user.toml
#
# The --config flag bypasses default loading entirely. Multiple --config flags
# are supported; files are loaded in order, each overlaying the previous.
# =============================================================================

Por lo que sea cuando es un servicio hay que tocar /etc/mctomqtt/config.toml   mientras que como docker se hace en  /etc/mctomqtt/config.d/99-user.toml

Editar el fichero de parametros en este caso para docker

  • sudo nano /etc/mctomqtt/config.d/99-user.toml
[[broker]]
name = "catalunya"
enabled = true
server = "broker.livemap-meshcorecat.com"
port = 8883
keepalive = 60
qos = 0
retain = true

[broker.tls]
enabled = true
verify = true

[broker.auth]
method = "password"
username = "cat-pub"
password = "CatMesh2026pub"


4 -  EL OBSERVER NO ENVIA INFORMACIÖN DE TRAFICO AL BROKER (Packet Healt = Never)

Este es el problema que en la actualidad sigo sin resolver, funcionan las dos parter del observer, nodo (repetear o companion ) y procesador (docker o servicio), pero no se envia información del trñafico al broker, unicamente del estado

En el log se observa que se envian al broker mensajes de estado del procesador 

2026-07-02 04:08:03,585 - INFO - [SERVICE] Uptime: 5m | RX/TX: 0/0 (5m: 0.0/min) | RX bytes: 0B | MQTT: 3/3 | Reconnects/24h: none | Failures: 0
2026-07-02 04:08:03,586 - INFO - [DEVICE] Noise: -120dB | Air (5m): Tx 2.0s (0.66%), Rx 3.0s (0.99%) | Battery: 4228mV | Uptime: 13h 12m | Debug Flags: 0 | Queue: 0 | Err/min (5m): 0.0

Pero no se ven mensajes de tráfico que son del tipo 

[SERIAL] Received packet...
[MQTT] [catalunya] Published packet to .../packet/adverts

Cosas que se pueden hacer

Comprobar USB

ls -la /dev/ttyACM*

crw-rw---- 1 root dialout 166, 0 jul  2 10:59 /dev/ttyACM0

Incluir nuevos parámetros

# --- NUEVA SECCIÓN DE ACTIVACIÓN DE TRÁFICO ---

[mqtt]
# Habilitamos el envío de paquetes de datos puros de radio
publish_packets = true  

[filters]
# Dejamos la lista de bloqueos vacía para asegurarnos de que NO filtre nada
disallowed_packet_types = [] 
# -----------------------------------------------

Tras modificar los parametros en los ficheros de configuración con un editor como nano hay que rearrancar los docjers o servicios y listr el log correspondiente
  • docker restart mctomqtt
  • docker logs -f mctomqtt

comprobar el flujo de salida de datos del nodo hacia el observer

sudo apt-get install screen -y
screen /dev/ttyACM0 115200
CTRL-A K

5 FALLO EN EL TIEMPO / RELOJ 

jul 02 12:47:16 raspberrypi python3[902]: 2026-07-02 12:47:16,238 - WARNING - System clock is not synchronized: Local time: jue 2026-07-02 12:47:16 CEST
jul 02 12:47:16 raspberrypi python3[902]:            Universal time: jue 2026-07-02 10:47:16 UTC
jul 02 12:47:16 raspberrypi python3[902]:                  RTC time: n/a
jul 02 12:47:16 raspberrypi python3[902]:                 Time zone: Europe/Madrid (CEST, +0200)
jul 02 12:47:16 raspberrypi python3[902]: System clock synchronized: no
jul 02 12:47:16 raspberrypi python3[902]:               NTP service: active
jul 02 12:47:16 raspberrypi python3[902]:           RTC in local TZ: no
reiniciar hilos

sudo systemctl restart systemd-timesyncd

timedatectl status
               Local time: jue 2026-07-02 12:54:19 CEST
           Universal time: jue 2026-07-02 10:54:19 UTC
                 RTC time: n/a
                Time zone: Europe/Madrid (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

 6- REINICIO TOTAL 

  • sudo systemctl restart docker 
  • docker restart mctomqtt && docker logs -f mctomqtt
OJO Si tiene mas aplicaciones en docker las tendra que reiniciar de nuevo asi para ADS-B se hará
  • sudo docker restart docker-node-sdr-1
  • sudo docker restart ultrafeeder
 7 - TERMINAL REMOTO 
sudo systemctl stop mctomqtt.service

python3 -m serial.tools.miniterm /dev/ttyACM0 921600
--- Miniterm on /dev/ttyACM0  921600,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---

get name
  -> > VC.V EA5JTT R8


8 - COMPROBACION DEL TIME EN LA RASPBERRY 

timedatectl

               Local time: jue 2026-07-02 17:06:04 CEST
           Universal time: jue 2026-07-02 15:06:04 UTC
                 RTC time: n/a
                Time zone: Europe/Madrid (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no


CONCLUSIONES

La red MESHCORE es y será lo que cada uno aporte

  • Dibulgación
  • Instalación de repetidores
  • Actualización del mapa de cobertura con MESHMAPPER 
  • Información sobre el tráfico con OBSERVER 
Sin embargo al ser una tecnología relativamente reciente el hardwware y software no estan muy  depurados y los procedimientos no estan muy claros, por ello no hay que desanimarse si las cosas no salen a la primera y hay que perseverar, como es en este caso el hecho de que por el momento no se haya conseguido enviar información del tráfico a los brokers.

No se aprende con el éxito , sino con los fracasos que nos llevan al éxito


Ver más


Referencias


Advertencia importante

Las modificaciones, configuraciones y procedimientos descritos en este sitio pueden implicar riesgos técnicos, legales o de seguridad. El autor no se responsabiliza del mal funcionamiento de los equipos, daños permanentes, pérdida de garantía ni de posibles infracciones legales derivadas del uso de esta información.
El lector asume plena responsabilidad por cualquier acción que decida realizar basándose en el contenido de este blog.

© 2026 EA5JTT. Queda prohibida la reproducción total o parcial sin autorización expresa del autor.




Tropo vs. Sporadic-E: The VHF/UHF Propagation Dilemma

If we listen to a transmission on the VHF or UHF bands from a distance greater than what a direct line-of-sight ray provides, we are experiencing sporadic propagation. But has it occurred in the troposphere or in the ionosphere's E-layer?

Differences in Appearance

  • If it is Sporadic-E (Es): The signal bursts in suddenly but is highly unstable. It will sound perfectly clear for 2 or 3 minutes, after which it will begin to distort deeply and then disappear completely. The phenomenon usually lasts from a few minutes to a couple of hours at most, vanishing without a trace.

  • If it is Tropospheric: The signal is much more stable and progressive. Stations start to be heard with background noise early in the morning or at sunset, gradually increasing in intensity. The signal remains stable on the dial for hours (sometimes entire days) without sudden fading.

Geographic Distance

  • If it is Sporadic-E: The skip distance is usually between 800 km and a maximum of 2200 km.

  • If it is Tropospheric: The maximum range rarely exceeds 400 or 500 km.

Geographic Areas

  • If it is Sporadic-E: Signals are received from stations across a very wide geographical area.

  • If it is Tropospheric: It is much more localized.

Example 1

On Friday, I was traveling by car, and while scanning the FM band, an Italian station came in (the minimum distance is 795 km) => Sporadic-E.

Example 2

On the afternoon of the 29th, my MeshCore client (868 MHz) located in Valencia received signals coming from central Catalonia between 17:57 and 20:05. (A specific area, a distance of around 300 km, and a prolonged opening—the three textbook characteristics of a tropo opening).

Detailed breakdown of the tropospheric opening on Monday, June 29, 2026, including times (17:57 - 22:11) and distances (256 - 327 km). Map generated with https://geojson.io/

General overview of the tropospheric opening on Monday, June 29, 2026, on 868 MHz. Generated with https://geojson.io/


Note the difference in propagation (distance and times) of the tropospheric openings toward the south.



See also:


Important Warning The modifications, configurations, and procedures described on this site may involve technical, legal, or security risks. The author is not responsible for equipment malfunction, permanent damage, loss of warranty, or potential legal violations arising from the use of this information. The reader assumes full responsibility for any action they choose to take based on the content of this blog.

© 2026 EA5JTT. Total or partial reproduction is prohibited without the express authorization of the author.

¿Apertura de Tropo o Esporádica-E? El dilema de la propagación en VHF/UHF

Si escuchamos una transmisión en las bandas de VHF o UHF desde una distancia superior a la que proporciona el rayo directo, nos encontramos ante una propagación excepcional. Pero, ¿se ha producido en la troposfera o en la capa E de la ionosfera?

Diferencia en su aparición

  • Si es Esporádica-E: La señal entra de golpe pero de forma muy inestable. Se escuchará perfecta durante 2 o 3 minutos, tras lo cual empezará a sufrir una profunda distorsión y desaparecerá por completo. El fenómeno suele durar desde unos minutos hasta un par de horas como mucho, y desaparece sin dejar rastro.

  • Si es Troposférica: La señal es mucho más estable y progresiva. Las emisoras empiezan a escucharse con ruido de fondo a primera hora de la mañana o al atardecer, van subiendo de intensidad poco a poco y se mantienen estables en el dial durante horas (a veces días enteros) sin desvanecimientos bruscos (fading).

Distancia geográfica

  • Si es Esporádica-E: El salto suele ser de entre 800 km hasta un máximo de 2200 km.

  • Si es Troposférica: El alcance máximo rara vez supera los 400 o 500 km.

Zonas geográficas

  • Si es Esporádica-E: Se reciben señales de emisoras de una zona geográfica muy amplia.

  • Si es Troposférica: Es mucho más localizada.

Ejemplo 1

El viernes viajaba en coche y, escaneando emisoras de FM, entró una emisora italiana (la distancia mínima es de 795 km) => Esporádica-E.

Ejemplo 2

La tarde del lunes 29, mi cliente MeshCore (868 MHz) situado en Valencia recibió señales procedentes de la Cataluña central entre las 17:57 y las 20:05 (zona concreta, distancia sobre los 300 km y apertura prolongada: las tres características de una apertura troposférica).

Detalle de la apertura troposférica del lunes 29/06/2026 en el que se incluyen horas (17:57 - 22:11) y distancias (256 - 327 km). Mapa generado con https://geojson.io/

Vista general de la esporadica tropo del lunes 29/6/2026 en 868 MHz 
Generado con 
https://geojson.io/


Observe la diferencia de propagacion (distancia y horas)de los tropos hacia el sur.


Detalle sobre la propagación por troposcatter sobre tierra que es aproximadamente 1/3 de la que se obtiene sobre el mar

ANEXO

De las mas de 80 de observaciones de troposcatters en Meshcore 868MHz se observa que no produce desde las 7h00 a las 16h00 hora local (05h00 a 12h00 UTC) hacia el NE (sobre el mar). Se produce el pico a las 04h00




Desde las 7h00 a las 20h00 hora local (05h00 a 18 h00 UTC) hacia el S (sobre tierra). Se produce el pico a las 05h00

 

Ver también:


Advertencia importante Las modificaciones, configuraciones y procedimientos descritos en este sitio pueden implicar riesgos técnicos, legales o de seguridad. El autor no se responsabiliza del mal funcionamiento de los equipos, daños permanentes, pérdida de garantía ni de posibles infracciones legales derivadas del uso de esta información. El lector asume plena responsabilidad por cualquier acción que decida realizar basándose en el contenido de este blog.

© 2026 EA5JTT. Queda prohibida la reproducción total o parcial sin autorización expresa del autor.


Meshcore: observer sobre cliente

EN CONSTRUCCION curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash export NVM_DIR="$HOME/.nvm" [ -s ...