Simple Repeater Node, using a CubeCell

Hello,
based on the factory_test examples by Heltec i wrote the code for a simple repeater node.

I’m using this for range tests and the following scenario:

The CubeCell (devboard) is placed in a location with good transmitting conditions. Incoming packets are repeated to my T-Beam, which is located in bluetooth range to my mobile phone e.g. sitting room.

So i can watch TV, read a book and am still getting long range meshtastic messages.

10 Likes

Super impressive! I bought some CubeCells and hoped to use them (there is still a ‘cubecell’ test target in platformio.ini based on this experiment). I quickly thought they would be not useful because there was no way to fit the full routing protocol/message queuing in 16KB. I didn’t consider your clever approach of restricting the problem to a ‘dumb’ (in the best way) repeater.

Hi geeksville, thank you for the thumbs up.

I’m still not sure how changing the channel name translates to the actual used frequency. Can you give some input to that topic?

The repeater supports only Default channel using the base frequency with “very long range” settings. TO DO would be pre defined settings for data rates and other channels than Default.

Sure - in the next couple of days I’ll update mesh-alg.md doc to nicely document how that hash works!

To nicely get channel #, and the settings etc… the same channel URLs that we share between apps could be parsable by your project. Though you’d need to include the (autogenerated and very small) nanopb protobuf C code. Then you could convert that URL string to this:

Which is documented here:

Thank you very much, will look into it!

1 Like

So cool, thank you for the code.It would be cool to add a way to remote-access the device and set channel name by a specific password,and also trigger a function used to map it’s range(A ping loop test).Also more code optimisation would be cool to allow this to talk relay2relay.

I hope you can keep your repo up and add improvements.I have a small hill near me and I will need to place some relays and I’m gonna use your code.Maybe in a week or two, I will order a Heltec Cube to start testing it.I hope the channel thing will be implemented.

Anyway, thank you for this, it’s helpfull

@tuxphone actually, I decided to document the channel name to channel number hash function in mesh.proto instead. Here’s the relevant bit:

  /**
  A channel number between 1 and 13 (or whatever the max is in the current
  region). If ZERO then the rule is "use the old channel name hash based
  algoritm to derive the channel number")

  If using the hash algorithm the channel number will be: hash(channel_name) %
  NUM_CHANNELS (Where num channels depends on the regulatory region).
  NUM_CHANNELS_US is 13, for other values see MeshRadio.h in the device code.

  // hash a string into an integer - djb2 by Dan Bernstein. -
  // http://www.cse.yorku.ca/~oz/hash.html
  unsigned long hash(char *str) {
    unsigned long hash = 5381; int c;

    while ((c = *str++) != 0)
      hash = ((hash << 5) + hash) + (unsigned char) c;

    return hash;
  }
  */
  uint32 channel_num = 9;

Keep kicking ass.

2 Likes

Banggood has TWO TTGO modules for $26.00 USD shipped (no battery holder) for the 915MHz version.

And TWO for 23.50€ EUR shipped (again no battery holder) if you need the 868MHz.

Maybe I talk some friends into hosting a repeater at their apartments.

2 Likes

Yep! They can…

1 Like

@geeksville Ok, so my plan right now is to make some kind of repeater for Lora.I want to achive the following:

  • the channel settings should be remotely-configured through lora
  • the device will simply repeat the message.It’s not necesarry to connect to the meshtastic network.I just want to repeat it.

I know you want to implement a relay function and in the meshtastic.I think I will consider buying some boards of this kind and I hope to link them to a solar panel.

I will use my drone to place it on the top of a tree or on a pillar so I cannot access it anymore.That’s why I think it’s cool to implement a “relay password” and access it to change the channels if you need and other parameters with commands like /changeName “Name here” “Repeter Password”

I really don’t know what to do at this stage: Wait for the Mestastic project to implement a repeater mode or try to convert the code suggested by @tuxphone and stick with the default channel.

I am not a developer, but I usually copy-paste pieces of code.

I want to place the repeator in a month or so and I won’t be able to get it down for “Software updates”, so I need it to be remotly configured.

I‘m working on configuring the Channel Settings. Just busy with other work right now.

1 Like

Did some changes to the code. It is now using the mesh.pb.h and MeshRadio.h to be more “meshtastic” regarding types, definitions and … channel settings :slight_smile:

You can change settings right now, but should still know, what you are doing. I tried to document the differences to original meshtastic in the code (Bandwidth index instead of bandwidth in kHz).

To be more user friendly (like the App - set channel name and speed and you are done) is high on the TO DO list.

I tested the changes with the default settings (Channel 0 aka “Default”) and “Longe Range but Very slow” (aka SF 12, CR 4/8, BW 125kHz) and got no issues.

7 Likes

@tuxphone Man, I cannot wait to see the final version.I will start ordering repeater boards from monday specially for your project.I hope that the TODO will be ready by then.

Major release:

Will work with any channel name and speed setting! Change values in the MeshRadio.h

I did test it with various channel names and speeds, but please test and give feedback of any problems.

6 Likes

1 Like

The code is now more meshtastic. Received data is written to a valid “MeshPacket” with the payload stored to the “.encrypted” portion.

I’m looking into the how-to of decoding the packet and possibly check for a ChannelSetting command. AFAIK there is high public demand for remotely setting the repeaters to a new channel and speed setting in a safe way. :slight_smile:

These CubeCell’s look very interesting, particularly the mini-solar with the 70mahr battery. Priced at under $25US . I have ordered one and the ‘development/programming’ board ($4), I did not see a need any of sensor boards, but I did order a second one with the built-in gps and a oled just to learn about them (it is not in a plastic container).

I got an OLED CubeCell, too. A bit larger than devboard. Form factor is like an esp32 board.

Factory examples: https://github.com/HelTecAutomation/ASR650x-Arduino/tree/master/libraries/OLED/examples

The idea behind the CCRepeater node is to drop it somewhere without user interaction so i did not include any support for the display.

3 Likes

Man this project is great.Can’t wait for my CubeCell to be shipped

Excuse my noobness. I am just getting started and ordered a couple of these cubecell based on the ASR650x and am very interested in making this work.
I have them loaded onto the cubecell and booting, but I am not able to connect from my Meshtastic tbeam. I do not have another tbeam yet so not a complete network, just trying to get a head start for when the second shows up.
Should I see something in the serial output other than “Setting up radio” bit?
I have confirmed I have EU hardware running at 865. I have adjusted those settings as well in MeshRadio.h. Tried different speeds and names. Thanks for the awesome work and look forward to helping with anything I can.