Data bandwidth and latency

1

Hello,

I am trying to find radio solution to build realtime messaging system between 10-20 devices. Whats is the real data bandwidth available via API? Is it possible to build system based on Meshtastic that support up to 20-30 messages (each about 20 bytes) per second?
Also why it is so much latency (about 3-5 seconds) to send/receive messages?

Best Regards,
Dmitry

2

I guess it depends on which channel config you use. But for the default very long range config it takes about 3 seconds to send 60ish bytes. Using so many chirps lets lora get long range with very low power, but it is super slow. No where near fast enough to do 400-600 bytes/sec.

3

On the second sheet of this spreadsheet you can play with different options and it will do the math to tell you how long it takes to send a packet:

1 Like
4

Thanks a lot for info. It is mean that on 500Khz, 4/5, SF7, 100% CPU I can get 600 bytes in less than 300ms. Right?

5

In all of these cases CPU utilization is essentially zero.

Sf7 corresponds to our “short range / high speed” option - but I haven’t measured the range for that setting.

6

Hello,

Today I tried to make some bandwidth test but no luck to get more than 1 message per second (:

 channel_settings {
   tx_power: 23
   modem_config: Bw500Cr45Sf128
   psk: "\327\241i\317\275\025y\301F\273t:\217\346@F\371\344\345\274\371D\336\007W\335\001i\336~Nc"
   name: "G1"
 }

Pyhton script send 6 messages via first device

import time
import meshtastic
interface = meshtastic.StreamInterface("COM6")
for x in range(6):
  interface.sendText(str(x),'^all', False, False)

and meshtastic script display messages on second device:

Trigger powerFSM 5
Transition powerFSM transition=Received text, from=ON to=ON
Received: {'from': 2988736560, 'to': 4294967295, 'decoded': {'data': {'typ': 'CLEAR_TEXT', 'payload': 'MA==', 'text': '0'}}, 'id': 2005531750, 'rxSnr': 4.75, 'rxTime': 315965859, 'fromId': '!ac67b2248030', 'toId': '^all'}
Trigger powerFSM 3
Trigger powerFSM 5
Transition powerFSM transition=Received text, from=ON to=ON
Received: {'from': 2988736560, 'to': 4294967295, 'decoded': {'data': {'typ': 'CLEAR_TEXT', 'payload': 'MQ==', 'text': '1'}}, 'id': 2005531751, 'rxSnr': 5.0, 'rxTime': 315965861, 'fromId': '!ac67b2248030', 'toId': '^all'}
Trigger powerFSM 3
Trigger powerFSM 5
Transition powerFSM transition=Received text, from=ON to=ON
Received: {'from': 2988736560, 'to': 4294967295, 'decoded': {'data': {'typ': 'CLEAR_TEXT', 'payload': 'Mg==', 'text': '2'}}, 'id': 2005531752, 'rxSnr': 5.5, 'rxTime': 315965863, 'fromId': '!ac67b2248030', 'toId': '^all'}
Trigger powerFSM 3
Trigger powerFSM 5
Transition powerFSM transition=Received text, from=ON to=ON
Received: {'from': 2988736560, 'to': 4294967295, 'decoded': {'data': {'typ': 'CLEAR_TEXT', 'payload': 'Mw==', 'text': '3'}}, 'id': 2005531753, 'rxSnr': 5.0, 'rxTime': 315965865, 'fromId': '!ac67b2248030', 'toId': '^all'}
Trigger powerFSM 3
Trigger powerFSM 5
Transition powerFSM transition=Received text, from=ON to=ON
Received: {'from': 2988736560, 'to': 4294967295, 'decoded': {'data': {'typ': 'CLEAR_TEXT', 'payload': 'NA==', 'text': '4'}}, 'id': 2005531754, 'rxSnr': 5.25, 'rxTime': 315965866, 'fromId': '!ac67b2248030', 'toId': '^all'}
Trigger powerFSM 3
Trigger powerFSM 5
Transition powerFSM transition=Received text, from=ON to=ON
Received: {'from': 2988736560, 'to': 4294967295, 'decoded': {'data': {'typ': 'CLEAR_TEXT', 'payload': 'NQ==', 'text': '5'}}, 'id': 2005531755, 'rxSnr': 5.25, 'rxTime': 315965867, 'fromId': '!ac67b2248030', 'toId': '^all'}

Why it still take 1-2 seconds to send/receive 1 message?

7

Hmm - could you open a bug for this? Bw500Cr45Sf128 should be fairly fast, but all testing/usage has been on longer range spread factors. I bet what you are seeing is that our random send delay (and ack timeouts) are not currently scaled based on expected packet time. Instead it picks from a range that probably only makes sense for really slow transmission. It would be better to scale those timeouts based on the expected time of packet transmission.

1 Like
8

thanks, I will open bug report

9

@geeksville, Those TX and RX related parameters could eventually be scaled based both on the expected packet time, and on hardware? This might easy up the steps towards supporting different hardware and multiple physical interfaces.

1 Like
10

Yep. That would be the idea!