This article describes the creation of the TWC-Mesh device, along with its characteristics and components.
Numerous devices compatible with Meshtastic are available, with the following being among the most popular choices currently on the market.
RAK WisBlock Devices
LILYGO® TTGO T-Beam
LILYGO® TTGO T-Echo
LILYGO® TTGO Lora
HELTEC® LoRa 32
Station G1
Nano Series
Raspberry Pi Pico
The initiative began in Taiwan, a region facing growing geopolitical tensions and complex cross-strait relations. It is essential to select source chips carefully for hardware development to avoid products that might pose a national security threat. As a result, ESP32 is not considered a suitable choice, while other options not dependent on ESP32 are usually more expensive, less flexible, or harder to obtain.
As a result, the decision was made to start afresh with the device, thoroughly assessing all available components and revamping the project. Fortunately, Meshtastic stands out as an open-source initiative supported by a vibrant user community, where individuals explore a wide range of solutions and platforms.
To create a Meshtastic node, it needs to have, at a minimum, the following elements:
- Core processor
- LoRa communication module
- Antenna
- Display Screen
- GPS module
- Battery
(If cost reduction is a priority, a screen/GPS/batteries are not essential.)
After considering the program's level of development on various platforms, we have selected the following as the central elements of this project.
| Parts | Model |
|---|---|
| Processor | Nordic NRF52840 (Norway) |
| LoRa module | Semtech sx1262 (USA) |
| GPS module | NEO-6M (Switzerland) |
Following some unexpected challenges, we managed to acquire all the necessary components
and effectively transferred the meshtestic project to our hardware.
Initial indications suggest that it will function correctly and establish communication seamlessly. Our subsequent objective involves devising a portable device to eliminate the need for extensive wire connections.
Taking into account the overall dimensions, type and positioning of the battery, usage position, maintenance convenience, arrangement of different components, and potential impact on signal lines, we have developed a PCB model of these gadgets to simplify future experimentation and evaluation.
Following several refinements, the GPS component now features a removable configuration.
Subsequently, through the assembly of the diverse components, we have successfully created the hardware for demonstration purposes!
Moreover, we conducted some preliminary testing on the campus.
However, the process encountered some challenges...
We observed that the performance of the prototype system did not meet the expected theoretical value, showing a significant discrepancy.
Along with intermittent disconnections and a high packet loss rate, the maximum communication distance was limited to only 400m, and the Received Signal Strength Indication (RSSI) was notably poor, contrasting with our prior successful experiences with LoRa technology (later identified as a design flaw on our part).
Overall, the preliminary test results fell short of our initial expectations. This prompted me to question the integrity of the antenna being used.
We began to wonder about the quality and suitability of the antenna in our possession. Subsequently, we acquired a NanoVNA to assess all antennas available in the laboratory meticulously, conducting measurements, labeling, and categorizing each one.
We even ventured into constructing custom antennas tailored to the specific frequencies.
The investigation revealed that a 2.4GHz antenna had been mistakenly included among the four sets of 915MHz antennas we had purchased. In essence, the incorrect antenna had been utilized during the testing phase.
After repairing the antenna, we resumed our experiments, only to encounter a new issue this time. Upon sending a message to our node, we observed that the Bluetooth signal of the node would abruptly disconnect from the smartphone. Despite thoroughly reviewing the code, we could not identify any apparent cause for the system reset.
Initially, there seemed to be no viable method for debugging the issue. However, we had ensured the use of an appropriate antenna, the hardware aligned with the official design specifications, the software displayed no error messages, the power supply remained steady, and we dismissed the likelihood of the communication module drawing excessive power leading to a surge during command transmission.
Delving into the realm of electromagnetic interference, we made numerous adjustments to the placement of both the communication module and the microprocessor, yet to no avail. It was only after a prolonged observation of these components that we deduced that by rotating the antenna to a specific angle, the disconnection issue could be averted. Subsequently, we successfully replicated this phenomenon across multiple units. (The video below demonstrates the unique angle required for each unit)
Honestly, we have forgotten the exact source where we encountered this issue. It likely came about after extensively reviewing official documents, design guidelines, and analyzing various related hardware designs.
It became apparent to me that the connection "from the communication module to the SMA connector" was inadequately thin and lacked impedance matching.
Before undertaking this project, we had no prior experience in designing high-frequency circuit boards nor had we received formal training in this specific domain.
In previous projects, our requirements were mainly centered around UART/I2C/SPI interfaces, and we had always adhered to the prescribed parameters for PCB thickness, material, line width, and shielding without encountering any difficulties.
However, this time was different as wireless communication demands precision; simply connecting a cable and hoping for it to function was not feasible.
After conducting extensive research, consulting various resources, and utilizing tools and software to determine the optimal configuration,
We revised the PCB design for the second iteration.
Drawing from our past projects, we also devised different node setups to enhance compactness and portability of the overall system.
We conducted a trial with this iteration by positioning one extremity on the rooftop and transporting the other end along with us.
The outcomes of the test revealed that a communication range exceeding 4.5km was attained (although it could potentially reach further if there were no obstacles).
Nonetheless, LoRa remains susceptible to interference from structures and topography, with its signal penetration being constrained, hindering communication capabilities behind intricate buildings and mountains.
Nevertheless, considering it operates on approximately 120 milliwatts of transmitting power for a battery-powered device, we are content with its performance.
Through the development of our Meshtastic device, we successfully crafted a custom solution that precisely met our requirements and offered significant insights to the wider audience. Demonstrating a communication range exceeding 4.5 km truly showcases the capabilities of LoRa technology and the meticulous attention given to enhancing both the hardware and software components.
We are eager to further enhance our design, delve into fresh opportunities, and enrich the communal knowledge base. Your support towards the advancement of the TWC_Mesh device is greatly appreciated.