I tried setting the bandwidth to ‘31’ on both a T-Beam and a T-Echo, which have an SX1262 onboard. Apparently setting a lower bandwidth improves the range significantly.
I have been told that setting such a low bandwidth requires a precise TCXO. The Lilygo sales page on Aliexpress claims that it comes with a 32 MHz TCXO. My tests on the T-Beam were extremely unstable, so I decided to try the T-Echo.
I tried setting the bandwidth to 31, and messages do go across if they are short. But I never get a message confirmation which is strange. Also, when I went out of my home, it stopped working completely. Like, 2 walls across, and it fails immediately.
As far as I can read online, a 31 kHz bandwidth is indeed possible and it’s even recommended by Semtech in some cases. What I am wondering about is, if the T-Echo lacks a TCXO, or if the Meshtastic firmware has some bug that prevents it from working well with this bandwidth setting, or some other reason I am missing?
Indeed a smaller BW gives less noise in the receiver which increases your link budget with 3dB for each halving of the BW. More link budget means more range.
I have never tried a BW smaller than 62.5kHz because the Xtals in my nodes are no_TCXO and not accurate enough.
In the CLI I give , for instance, this command:
meshtastic --ch-set spread_factor 10 --ch-set coding_rate 5 --ch-set bandwidth 62 --ch-index 0
You can fillin any spread_factor of 7,8,9,10,11 or 12, and a coding_rate of 5,6,7 or 8.
Bandwidth of 250, 125, 62, 31 are all accepted.(maybe more)
Maybe your T-beam and T-echo have a ‘Chinese’ TCXO.
Chinese antenna gain is usually too high. Frequency accuracy of a Chinese TCXO may be too low, (who knows ?).
You must check the frequency of your nodes. You don’t need a >>1000$ instrument. If you have a good SDR receiver you can see if the 2 nodes are on the right frequency, if not exact than relative, depending on the frequency accuracy of your SDR. If there is an offset between them of more than 8kHz (25% of 31kHz) you have found the reason a BW of 31 is not working well for you.
If there is just a small offset, you have to investigate further.
I own a SDRPlay and think it is a good receiver but if you want it very cheap even a RTLSDR dongle will do the job. https://www.rtl-sdr.com/about-rtl-sdr/
Bandwidth of 31.25khz was defined as the configuration for the “LongFast” modem configuration over the last few years (v0.9 → 1.2). It did work but there were periodic reports of reliability issues which we tracked down to a lack of TXCO on at least one of the devices.
v1.3 has all new modem configurations and LongFast will be on 125khz to improve reliability at roughly the same link budget. We are also introducing a new configuration called “Very Long Range / Slow” that uses 31.25khz. I don’t expect that setting to work for a mesh with more than a half dozen devices, but will also allow for about 50-100 more range than “Long / Slow” because of an estimated 6db gain.
There’s a method that the semtech radios exposes that returns the frequency drift of the last received packet. That may give the information he’s looking for.
I am exploring 31.25 kHz because on our new prototype, we intend to have an “emergency mode” in which transmit power is set to 1 Watt, and the bandwidth will be set to 31.25 kHz to potentially increase the range in times of distress.
I am still speaking to Lilygo about the hardware, so at this stage, I am just running some experiments to verify if it will actually work.
I even considered 7 kHz but the bit rate is around 11 bits per second which is too low in my opinion.
Has the combination of SF12, BW 62.5, and CR 4/8 ever been tested by anyone before? I am considering giving it a go today on the T-Echo.
There are use cases where lower bandwidth is ideal, it’s not always only for range.
Spreading factor 7, coding rate of 4 and bandwidth of 31.25 will result in a bitrate of about 900bits / sec. That’s about 3 or 4x our long rage settings.
The different bandwidths could be used for amplifier / antenna tuning or even because of an application specific band plan.
In some situations, a higher bandwidth may have attenuation or propagation that’s not ideal so a lower one is chosen.
Funny enough this was my first try of channel settings after realizing sending 15s updates on default longslow was just not going to work. I think I stumbled onto the developers docs page developer docs before settling on any of the defaults. I remember getting ack packets more often when testing then but this could also very well be due to me getting more ambitious with mesh setups.
I had no issues using longfast with my t-beams (with maybe china TCXO?) but immediately shifted to using mediumfast as most of my deployment ideas revolve around many nodes with the need to handle some realtime traffic.
edit:
I actually believe I set it as 50 because I liked the round number and wanted to compromise. Reading more about LoRa it seems like that would have set the PHY layer to the 62.5 bandwidth? I am not sure about this all yet. But in testing I was still running into mostly line of sight issues and stock antenna problems so not sure much about range comparison between any of the stock channels but I plan to try more of these “middle ground settings” with my new quality aerials soon.
For my idealist deployment, I am looking for a larger node count and many hops; I think the bandwidth limitation with anything below 1kbps is going to make me reconsider how I envision using my planned ~20 node network. I will be experimenting a lot with the different channel settings in the coming weeks will keep much better records than before.