Meshtastic-DIY project

Sorry, I meant the module I linked to above would be the cpu in a meshtastic device rather than the radio. That nRF52840 SoC it utilizes contains an ARM Cortex M4 processor. It’s a much lower power consumption architecture than the ESP32.
Since the RAK Wireless 4361 boards and the new TTGO T-Echos use that chip, there is precedence for targeting it. The problem is having to build out all of the ancillary circuits enable things like flashing the device via usb for instance.

A dedicated DIY firmware branch would be very useful for tinkers or anyone wanting to save money on nodes.

1 Like

I would say a fork in github might even give a bit more flexibility.

No need for forks. All changes will be present in the special official Meshtastic-diy branch. If you want - use E22, if you want - use E19, if you want - ordinary noname modules with Ali.
E19 modules are no different from the SX1276/1278 firmware, with the exception of the rx/tx switching contacts. They are easily added and are already hidden in the radio lib library. In the same way as the rx/tx contacts for SX1262/1268.

In the special official branch of the Meshtastic-diy, all this will be present. A little patience!

Added electrical diagrams for E-byte E19 modules.
Special firmware for E19 will be added a little later.

Added an example document for home made assembly of a Meshtastic-modem in Russian and English.

I thank all the colleagues involved in the project!


Thank you for the translations!

Added an electrical circuit with different simple LoRa-modules with aliexpress based on SX1276/1278 for 868/433MHz.

Added an electrical circuit with Nice-RF LoRa-modules based on low-power SX1262/1268 and on the based of powerful Lora1262/1268F30 and Lora1276/1278F30 modules at 868/433 MHz.

Note 1: I recently purchased but have not tested the Lora1276F30 modules yet. I think there shouldn’t be any problems with them.
Note 2: NiceRF also has low-power modules based on SX1276/1278. I didn’t draw separate diagrams on them, because they almost completely coincide with the schemes of Noname modules.

Hello friends!
When testing the firmware, our colleagues discovered a bug in the definition of the RX GPS pin. I fixed the problem, rebuilt the firmware, now the GPS on pin 15 is working correctly.

Also, together with other colleagues, work is underway to write the FAQ. See the DOC section.


Awesome work!

Are there enough pins available to expose the JTAG port on the esp32? That would help developers debug the device much easier than current methods.

Thanks for your great work towards DIY targets!
I will give it a try as soon as I get my hands on the hardware!
Maybe you can also add provisions in the code to switch off the GPS module to save power? The t beam is using the APX192 pmic chip, but it could be a simple as a GPIO pin+highside switch to kill power to the GPS.

Greetings friends! Hi Kevin. @geeksville
Recently, a friend of mine who is involved in programming and modifying the main code has made support for the new LoRa chips CC68. These chips are a continuation of the SX1262/1268 series. In my opinion, these are “cheaper” chips of the best SX1262/1268, since these chips have a small drawback. They do not support the “default channel”. There is no parameter SF = 12 in the settings of the CC68 chip. And this parameter is one of the most important in the “default channel settings” mode. The minimum available mode for the CC68 chip is SF = 11.

Thus, it turns out that the chip seems to be supported by the firmware now, but the configuration should be for a particular case (individual setting) - one of the 3 settings available in the program, but this will NOT BE SUPPORT by default “#LongSlow-V” (Very long range, but slow).
I hope in the near future our colleague will make a pull request and support for the new chip will be added by Kevin to the main project.

For those colleagues who are engaged in independent experiments and know how to assemble the firmware on their own, a git-project with CC68 support is available here, in the CC68 branch:


For this Diy-project, I am using a regular UART-port. The JTAG-port is not used.

1 Like

In case you haven’t seen it already, take a look at “project hydra” which is an offspring from your awesome efforts to push DIY hardware: GitHub - PlumRugOfDoom/project-hydra-meshtastic-pcb. I’ve just recently assembled the first V1 prototype and everything seems to be working.

J-Tag debugging for software development will be adressed in another upcoming DIY build, a “shield” pcb for the olimex esp32 devboard: ESP32-DevKit-LiPo - Open Source Hardware Board


I’m reviewing the PR and will likely approve it tonight. Could I ask that a bug be created to track that the LLCC68 chip doesn’t support SF12, there are errors with SF12 and we should have an elegant solution to handle that case? You’d have more info on the error and a possible solution than I do :slight_smile:

Thanks mate!

Edit: Reviewed, Approved and Merged

Thanks, @mc-hamster!

Issue #926.

Not sure that we have to prioritize it, as I don’t know any devices except the test one from @Der_Bear

Agreed. No need to prioritize it but we don’t want to forget about it either.


Hello fellow developers.
Now my friends and I are doing DIY V1.1
Tell me where in the code there is an instruction to change the battery icon on the OLED-screen to the real Voltage (Taking into account the voltage divider and the ADC_MULTIPLIER pointer).

Issue resolved. Thanks to Vladislav : @Vladislav

// Draw power bars or a charging indicator on an image of a battery, determined by battery charge voltage or percentage.

static void drawBattery(OLEDDisplay *display, int16_t x, int16_t y, uint8_t *imgBuffer, const PowerStatus *powerStatus)


char batStr[20];

if (powerStatus->getHasBattery())


    int batV = powerStatus->getBatteryVoltageMv() / 1000;

    int batCv = (powerStatus->getBatteryVoltageMv() % 1000) / 10;

     snprintf(batStr, sizeof(batStr), "%01d.%02dV", batV, batCv);

    // Line 1

    display->drawString(x, y, batStr);

} else


    // Line 1

    display->drawString(x, y, String("USB"));