I’m beautiful and tough like a diamond…or beef jerky in a ball gown.

  • 3 Posts
  • 28 Comments
Joined 6 months ago
cake
Cake day: July 15th, 2025

help-circle





  • If you’re provisioning several or just like to have a good baseline for setting up future nodes, I like to use the Python client and make a provisioning script. I feel like it’s way uglier than it should be, but I’ve found that even though the docs say you can specify multiple config options in one call, they don’t all apply. So I have to do them in stages and wait for it to reboot between executing each config.

    This is my baseline provisioning script for reference. I like to have a private default channel but then also set the radio frequency manually to the “default” LongFast of 906.875 MHz and create the LongFast channel as a secondary so I can communicate with people using the default config (which is very common). This also lets me relay for them (and vice versa) while not sharing my location and such with the public mesh.

    #!/bin/bash
    # Optionally set the device name and short name.  If not provided, the user info step is skipped
    DEVICE_NAME=$1
    DEVICE_SHORT_NAME=$2
    
    # Admin key is optional but I set it on all of my managed nodes. If not using that, comment out the line further down where this is referenced
    ADMIN_KEY="{PUBLIC_KEY_OF_ADMIN_NODE}"
    
    # Use a private default channel.  
    PRIMARY_CHANNEL_KEY="{BASE64_PRIVATE_KEY_FOR_PRIMARY_CHANNEL}"
    PRIMARY_CHANNEL_NAME="{PRIMARY_CHANNEL_NAME}"
    
    
    function wait_for_reboot {
      echo "Press <ENTER> once device has rebooted"
      read a
    }
    
    echo "Setting LoRa Region..."
    meshtastic --set lora.region US
    wait_for_reboot
    
    # If device name and short name are supplied, set those
    if [ -n "$DEVICE_NAME" ] && [ -n $DEVICE_SHORT_NAME ]
    then
      echo "Setting Device Name..."
      meshtastic \
        --set-owner "$DEVICE_NAME" \
        --set-owner-short "$DEVICE_SHORT_NAME"
      wait_for_reboot
    fi
    
    # Set most options
    meshtastic --set display.screen_on_secs 120 \
      --set display.units IMPERIAL \
      --set device.led_heartbeat_disabled false \
      --set telemetry.device_telemetry_enabled true \
      --set lora.use_preset true \
      --set lora.modem_preset LONG_FAST \
      --set security.admin_key base64:$ADMIN_KEY \
      --set lora.override_frequency 906.875 
    
    wait_for_reboot
    
    meshtastic --set-canned-message "Affirmative|Negative|Unknown|Acknowledged|Require Assistance|Check-In Good|Check-In Bad|Status?"
    wait_for_reboot
    
    
    meshtastic \
      --ch-index 0 --ch-set psk base64:$PRIMARY_CHANNEL_KEY --ch-set name "$PRIMARY_CHANNEL_NAME" \
      --ch-index 1 --ch-set psk base64:AQ== --ch-set name "LongFast"
    wait_for_reboot
    
    meshtastic --set-time
    









  • Can confirm the similar battery life. Just the Heltec V3, connected over BT, with a 2000 mAh battery lasts about 14 hours. If it’s not connected to my phone and the BT shuts off, it’ll last well over a day (maybe more). I was going to add a GPS module to it but didn’t want to make the case any larger to accommodate a 3000 mAh battery.

    The ESP32’s radio is just power hungry it seems. I’ve noticed there’s nothing “low energy” about it’s BLE and it seems to use the same amount of power as an active wifi connection.

    And any time the power goes out for more than 5 mins the device resets its name

    I’ve only had that happen once, but I don’t recall the circumstances. My everyday carry node is always powered, but I have some nodes that just sit on a shelf. What I have noticed is that the soft shutdown is only temporary and after 3-5 days they’ll turn back on until they drain the battery. I think only one of them has had issues keeping its device name.

    I just updated all of them to the latest 2.7 firmware and am hoping that addressed the soft shutdown timeout. Which reminds me, I need to check in on them since that was about a week ago when I updated them.









  • I don’t think that will work. At best, it would split the signal power and neither antenna would perform well. That’s not even getting into the RF wizardry which I’m not equipped to fully explain (or understand lol).

    The “proper” solution would be to have two Meshtastic units. One in a high place for long range and configured with the “client base” role and the other one(s) with regular antennas optionally in the “client mute” role. The reason for that is they’d likely be able to “hear” the base station one just fine and relay through it and wouldn’t necessarily need to rebroadcast locally. If they do, then they can be in regular “client” role.

    Since I have multiple units inside, I keep mine in “client mute” when I’m home so they go through my “attic node” and switch to “client” when I’m out and about. The 2.7 firmware makes this easy to switch directly on the device without having to mess with the app settings.

    https://meshtastic.org/blog/demystifying-router-late/

    Now if you’re talking a highly directional Yagi for the high gain/high place antenna, then I believe the general guidance still stands. The newer firmware has some zero hop configuration where you can “pair” devices (via favoriting) and while they still hop the signal, it doesn’t decrement the hop count.

    https://meshtastic.org/blog/zero-cost-hops-favorite-routers/