Hi, I was wondering if the Single Channel packet forwarder with “XIAO ESP32S3 & Wio-SX1262 Kit” still works with TTN now? Has anyone tried it and is it still working fine for you?
I’m actually new to LoRa related stuff and I came to know that TTN doesn’t encourage Single Channel packet forwarder/gateway. But this official seeed studio wiki:
shows how to build one, and I guess this wiki was made even after TTN stopped supporting single channel packet forwarder.
Some other links…
This is a good question… I am hoping because this is old tech someone can reverse engineer it.. maybe AI… they went away from single channel because they want to sell LoRa Routers..
If you truly want to solve this issue let me know we can work on it here!
Here is why…
I feel like it is a root cause why meshtastic gets tangled when it comes to routing or anything other than a Broadcast…
1. Gateway / Network Packet Forwarders (LoRaWAN & SenseCAP)
If referring to gateways routing RF packets to an LNS (such as The Things Network or a self-hosted ChirpStack):
The Legacy Semtech UDP Protocol: Many cheap or older gateways still rely on the legacy Semtech UDP packet forwarder. Because UDP is connectionless and unencrypted, firewalls frequently drop or block port 1700, packets are lost without retry mechanisms, and there is zero mutual authentication (TLS).
Downlink Timing Jitter: In Class A LoRaWAN, downlinks must hit precise 1-second or 2-second receive windows ($RX1$/$RX2$). If the packet forwarder suffers from latency or scheduling jitter over cellular/WAN connections, downlinks miss their slot entirely.
No Remote Management: The legacy UDP forwarder cannot dynamically update frequency plans or channel configs over the air. Modern solutions require LoRa Basics Station (using WebSockets over TLS for secure data plane and CUPS for configuration/firmware updates), which many entry-level gateways either implement poorly or fail to support.
2. Sensor / MCU “Data Forwarders” (Edge ML & Radar Tooling)
If referring to passing binary radar/sensor frames from an on-board MCU up to Edge Impulse, a PC visualizer, or Home Assistant:
UART Buffer Overruns & Dropouts: High-frequency radar data (point clouds, range-Doppler bins, or raw FFT frames) generates massive serial throughput. Naive serial “forwarder” sketches running on Arduino or simple RTOS loops drop bytes when UART RX buffers fill up, corrupting binary frame headers and breaking the downstream parser.
Blocking Parsing vs. Streaming: Most stock forwarder examples parse serial frames byte-by-byte using blocking delays. When forwarding frames over Wi-Fi (MQTT/WebSockets) or USB, network latency hiccups stall the serial reader, causing sync loss with the radar’s internal DSP.
Lack of Timestamping & Synchronization: Standard serial forwarders rarely attach hardware microsecond timestamps at the moment of packet arrival. Downstream algorithms attempting to compute velocity, trajectory, or FFT changes suffer from timing jitter introduced by the host operating system’s USB-to-UART bridge.
Mesh core does route , so Hops are possible.
Still a WIP though but the Radio Tech is getting pretty solid.
YMMV
HTH
GL 
PJ 