Anyone want to try custom channel settings?

Support Python API
1

I updated the radio-settings documentation with quite a bit of information about the relationship of spreading factors, bandwidth and coding rates.

Also on the document some are example custom settings along with the effective bandwidth. There’s one setting example that is exceedingly slow but should offer twice the range as the existing “Very long range (but slow)”.

This uses, what I believe to be, a fairly unused feature on both the existing Python API along with the device firmware.

Wanna try it out?

If you do, something to remember is changing the channel setting will cause the crypto keys to be regenerated, so you’ll get a new QR Code and/or shared URL to have other devices join the network. I don’t know if you have to restart your device. Please let us know if you do or don’t.

Please share your experience. The code has been in there for a while. I don’t have the python API on my Mac so I have not actually tried this out, but I just documented the functionality in the code.

If you’ve read this far, you’re probably interested.

Here is the draft version of the radio settings document. Scroll all the way to the bottom and find the section “Data Rates”. I’ll take any feedback and update the document before merging it into the main project repository.

9 Likes
2

Thank you @mc-hamster!

Is that supposed to work on firmware 1.1.33 beta? For each parameter I get something like

Can't set spread_factor due to 'UserPreferences' object has no attribute 'spread_factor'
1 Like
3

Thanks for playing along! I looked through the python code and I was mistaken about the parameter. The doc has been updated but here’s your TLDR:

meshtastic --setchan spread_factor 10 --setchan coding_rate 8 --setchan bandwidth 125

4

Oh I see! Thanks for the clarification, I’ve just removed my PR.

5

I’m sorta shooting blind here. Python API hasn’t worked on my mac for a while so I did something a little difficult – wrote documentation based on reading code instead of actually using the tool. I hope this is the last roadbump.

6

One more thing @mc-hamster: how can I reset the device to the default channel without using the app? i.e. how can I make the meshtastic tool parse the default channel URL https://www.meshtastic.org/c/#GAMiAQE= ?

I’m aware of

--setch-longslow      Change to the standard long-range (but slow) channel
--setch-shortfast

but it’s unclear to me which two out of the four default channels correspond to those above.

7

Ahahahah I feel your pain, as I’m reading this on my iMac!
That’s why I keep a Raspberry Pi 3b+ under the desk and ssh/vnc into it to play around with Meshtastic.

8

Good question. If this works like the other settings on the device, try:

meshtastic --setchan spread_factor 0 --setchan coding_rate 0 --setchan bandwidth 0

LMK if that works and I’ll update the doc. I don’t know if your device will need to be restarted or if it will trigger the generation of new crypto keys.

9

I have a virtual machine for that but it’s on a rack server in the basement. Using it isn’t at all convenient, requires a scat-load of hoops. I do have a Pi 2 sitting in a box somewhere. Maybe I should set it up. Thanks for the idea!

10

It does! I’ve restarted for good measure.

1 Like
11

To me it’s invaluable having a Linux box at the ready.

1 Like
12

I’ll update the docs. Thanks.

13

How about varying the preamble length?

14

The preamble is hard coded. I also found this note:

A 32 bit LORA preamble (to allow receiving radios to synchronize clocks and start framing). We use a longer than minimum (8 bit) preamble to maximize the amount of time the LORA receivers can stay asleep, which dramatically lowers power consumption.

15

Why do you hardcode the preamble length? Further increasing preamble length allows for better synchronization and thus further increases successful communication range.

16

I can’t say why it was hard coded, but the length is currently set to 4x of the default.

You could try a change in a local fork and if there is a measurable difference, I’m sure that would be good information for @geeksville ’s consideration.

Just some quick math … At the long/slow setting that 32bit preamble takes up 1/5 of a second.

1 Like
17

yep - most projects use 8 bits. we use a 32 bit preamble because that gives a much better duty cycle of the lora rx unit spending most of its time sleeping (clocks stopped), then waking to listen to see if a preamble is going. Better synchronization is a good point but wasn’t even our goal.

I’m okay with picking any number for the # of preamble bits if a test show it improves performance.

(though fundamentally preamble length has to be hardcoded to some degree, because it gets programmed into a sx1262/sx1276 register. So that the ucode machine in the radio chip can do its own locking without having the involvement of the main cpu)

18

Im testing these in the cascades and would really appreciate help and setting up my channels for this, if I use:

meshtastic --setchan spread_factor 12 --setchan coding_rate 8 --setchan bandwidth 31

would that be the command to configure the channel for testing?

19

I added information to the document about the estimated dB gain for the different settings.

Thanks everyone who provided feedback, especially @zebus and @IZ1IVA !

2 Likes
20

Sending “hello” with these settings takes about 15 seconds to transmit and another 15s until the ack is received.

I will check tomorrow, if I get better range on my “personal test route”. Would be nice if I manage to connect to my parents house, wich was not possible with the "very long range (but slow) setting.

3 Likes