New project announcement

Happy New Year everyone!

By popular demand, the GTM Lab project is now live on GitHub - sybip/gtm-lab: goTenna Mesh protocol playground

From the project introduction:

This is a fun project to study and re-implement the goTenna Mesh protocols on inexpensive hardware based on the ESP32 MCU and RFM95W radio modules, using only unrestricted, publicly available information. All project code is open source under the MIT license.

Currently it’s nowhere near a complete relay, or even endpoint solution, and will probably never be a true drop-in replacement for goTenna brand devices, however:

(it) can send and receive messages to/from the goTenna mesh network

And this alone should be sufficient for a few hours of fun and excitement - a well-deserved break from these stressful times.



How about using something like this: Mini Ultra Pro V3 (With Radio) – Rocket Scream

Not gonna lie - my gut reaction was NO. The SAMD21 MCU is slower than the ESP32, the RAM and Flash are fairly unimpressive too, there are no built-in BLE or WiFi connectivity and no hardware crypto.

However, on closer examination, the hardware reqs of GTM Lab are really not that demanding! There’s a pretty good chance that you’ll get some results with your SAMD board. Also, “no built-in BLE” shouldn’t be a dealbreaker - considering all the messages “how do I turn off Bluetooth” on this forum :slight_smile:

In conclusion, I think it’s definitely worth a try.

A few pointers to help you get started:

  • to make the code 100% portable and compilable on your platform, you need to remove/replace a few lines of ESP32-specific code (don’t worry, it’s easier than it sounds):
    • eliminate all references to ESP-specific logging, maybe replace the LOG* macros with Serial.printf() or similar, and also comment out the HEXDUMPs
    • 64-bit arithmetic is used in the Reed-Solomon ECC and the Park-Miller LCG; it’s unlikely that this will be an issue, but if it is, you can replace those functions with 32-bit ones (ping me if you need a hand with this)
  • packet timing is a mess, expect to be even more so on a slower CPU, so focus on receiving even one single packet at first, and work gradually from there.

Good luck, let us know how you go, and most important, have fun!

Update: as of today, it’s a bit less of a mess, at least on RX side. @Roman, if you’re already working privately on a SAMD21 port, have a look at commit 3af4a6d, lines referencing pktStart, as they may be relevant to your work.

I wish I had time, I’ll probably get to it later at some point. I was asking about the Ultra pro because it had everything built in for a custom relay except the power is low, but most of those small devices use low power. I was imagining this with an amp, to make a relay with ability to control and check status remotely.

i got a heltec HTCC-AB02S board based on ASR6502 SoC and it seemed it was a better fit for what i needed (GPS+long range radio) and i remembered about gotenna mesh only after board has arrived, but i seems SX1262 RF should work too, so question is how specific is ESP32 code and what should i do to give it a try?

other question if i want to work in both LoRAWAN and GTM modes what are my options, i guess cant do that at the same time, but would it make sense to switch from one to another to send/receive messages in both?

given ASR6502 has M0+ too it seems SAMD21 port should be what will help?

Oh great thanks!
first thing was i tried it with heltec esp32 wifi-lora v2 board, and only change needed was RST pin to 14 compared to board 1. Otherwise everything worked like charm - receiving and sending SHOUTs. didnt really get if i can send a private message to gotenna user or not. also receiving shouts in hex - is there a way to decode it back to ASCII?

now tried HTCC-AB02S:
and got confused looking at pinout at

i dont see RST/CS/IRQ pins… and without those it wont build as it seems those are params for constructor.
UPDATE: my bad lora is part of SoC, so found internal pins for CS/RST but not for IRQ, frankly missed IRQ on previous board too, not sure if it is important

1 Like

yep added those

#elif BOARD_TYPE==9
// Settings for HTCC-AB02S
#define pinCS P4_3 // LoRa radio chip select
#define pinRST P5_7 // LoRa radio reset
#define pinIRQ P4_6 // Hardware interrupt pin
#define PIN_SCLK P4_2
#define PIN_MISO P4_1
#define PIN_MOSI P4_0

everything compiles fine but still got

3 (103) GTMLIB: Receiver startup: board=9, region=1
1 (127) GTMLIB: Radio init failed. Check pin definitions

I’m sorry, I have bad news. Some of the information that I gave you above was incorrect in a highly relevant way.

The Semtech radio used by gtm-lab is SX1276.
SX1262 has a completely different API and is currently incompatible with Sandeep’s Arduino LoRa library, which gtm-lab uses. For this reason, SX1262 is currently not supported.

My apologies to you, and everybody else who may have wasted hours of their time trying to get this radio to work in gtm-lab.

I have edited the post to correct the erroneous information, and will make it a point to double-check my messages before posting.

(Originally posted on 2021-03-20, edited on 2021-03-22 to amend some incorrect information)

I have pushed an update which completely isolates the ESP32 code. The Arduino compiler will now check if the target platform is ESP32, and, if not, will replace any ESP specific code with generic equivalents or placeholders.
Note that this is work in progress, and some debug functions (like hexdump etc) are still unavailable, but in a non-breaking way. The code should compile and run OK without them.

SX1262 is the radio of choice for the project and will definitely work well.
SX1262 is currently unsupported - see explanation below above in this thread.

This part I’m a bit worried about. 48MHz single-core, 16K RAM, 128K Flash is at the lower limit of usable specifications. It might be able to run the code, but there’s definitely not much room for growth. Worth a try, anyway.

NOTE: the instructions below will not work for the HTCC board, due to the incompatible radio module. They are still useful as a method for testing non-ESP boards.

  1. Change BOARD_TYPE to 2 in gtmConfig.h and try compiling the code for your target board, but do not upload it yet (the pinouts are still wrong). Hunt and fix any errors before proceeding to next step.
  2. Create a new board definition under HARDWARE SETTINGS in gtmRadio.c using the existing ones as an example. You will need to enter the correct pin definitions for your board, which are probably here:
    ASR650x-Arduino/board-config.h at master · HelTecAutomation/ASR650x-Arduino · GitHub
  3. Give the new board a number, say 9 (#elif BOARD_TYPE==9 … you get the idea)
  4. In gtmConfig.h, change BOARD_TYPE to 9 (the number chosen above)
  5. Compile the code again, and now you can also upload it to your board.
  6. Have fun :slight_smile:

There is a way :slight_smile:

The gtm-lab RX_MSG output contains the raw data object, as received over the air. This object contains several layers of encoding: a generic one, an optional encryption step, and an application-specific one. You need to peel them off one by one.

The generic layer is application-independent; it contains the message metadata (sender, destination, app ID, class etc) and the message content blob (which will require further attention). We have code for this.
Python module:
Example code: goTenna Mesh traffic metadata logger · GitHub

The encryption layer is optional, application-specific and only partially documented and is applied to the content blob only. No published code available yet; not needed for shouts.

The application-specific layer applies to the unencrypted (or decrypted) content blob and defines its formats and structures. For the goTenna app it is documented in GTA Message Format and we have some code available:
Python module:
Example code (sending only): 30-second, 60-line demo of pyGT library (2021 version) · GitHub

Back to your question, the quickest way to recover the individual fields from received messages in readable form is:

  • get the metalogger script working first with your gtm-lab, then
  • edit it to feed the content (m['msgBlob']) to compatGTA.gtReadGTABlob() and
  • print the result.

In particular, your message text, if present, will be in result[MSGB_TLV_TEXT] aka result[4]

Good luck!

LOL, sorry for the wall of text, it was rather uncalled for :slight_smile: Is this what you had in mind?

minilogger - goTenna Mesh traffic logger, similar to (and based on) metalogger, but also including cleartext dump when practical · GitHub

Oh yes totally, actually i checked ascii codes and was able to find my message at the end.

But one question was can i send/receive private messages using current gtm-lab sw?

My current goal is to build kids “smartphones” so they can communicate without cell coverage and i can receive their gps location ))), so need some kind of reliable protocol on top of lora. If that can communicate through some kind of mesh would be a great bonus. Looking into gotennamesh(which i have four units as a KS backer) meshtastic disaster radio etc, trying to understand what are the options.

Also looked at the code it seems the radio is encapsulated into lorax.h/cpp but after second look writeregister/readregister is very heavily used so changing radio isnt that easy( seems sx1262 is what next rev of ttgo will use.

You can, just not to the official goTenna App. Point-to-point and group messages support optional encryption, however it appears (in my experience) to be mandatory in the GTA - unencrypted messages are dropped and not displayed.
Currently, AFAIK, there is no published code for the GTA encryption, and the Python code that has been circulated a couple years ago has no license terms attached so I can’t just include it in pyGT.

This particular application seems to me the ideal use case for the original goTenna Mesh and App. No other option comes even close. Is there any element of your idea that you feel isn’t already supported by goTenna?

This is true, and that’s why I made it a priority to document the radio waveform, the packet formats and protocol (see wiki). My long-term plan is that the radio hardware, API, registers etc shouldn’t matter; as long as the radio can operate with that specific set of parameters, finding someone to write the actual code is a non concern.

Great, this will give us a chance to put my theory to the test :slight_smile: