Menu Close

MeshCom 4.0 FAQ

Questions and answers

F: Kann ein HELTEC V3 / 3.2 in einen sleep-Modus versetzt werden?

A: Ein HELTEC V3 + V3.2 kann durch gleichzeitiges drücken der tasten RST + PRG in den Sleep-Modus gesetzt werden. Der HELTEC kann durch drücken des RST-Buttons wieder aktiviert werden.

F: mein HELTEC E290 lässt sich nicht mehr neu flashen, die Serielle via USB verbindet sich ständig neu, was kann man tun?

A: Vorgang:
  • USB von PC/Laptop abstecken.
  • AKKU dran? dann diesen abstecken.
  • BOOT-Tasten direkt am Board bei den drei Buttons zu finden, halten und USB wieder anstecken.
  • Flasher starten und wenn die %-Anzeige zu laufen beginnt BOOT-Taste los lassen

F: Kann eine EMCOMM Meldung (EMC) jetzt von jedem verwenden werden? Auch für andere Notfall Warnungen, oder war das jetzt ein spezieller neuer Fall?

A: Nein ist kein spezieller Fall, Wie ihr bereits gesehen habt waren schon immer im Dashboard die obersten Zeilen für Warnmeldungen vorgesehen. Es wurde nur noch eine Erweiterung eingebaut, das die Gruppe 9 welche sonst nicht angezeigt wird dazu verwendet werden kann.
Die Meldung wird als Textmeldung welche mit „EMC:“ beginnt verfasst und an die Gruppe GRC 9 gesendet.

F: Was sind die PL und M Werte in der LHEARD Anzeige am WEBServer?
Was gibt das an?

A: um mit dem Protokoll auch Erfahrungen zu sammeln (AirTime, Robustheit, ..) benötigt man Informationen:
  •  mit dem RX-LOG sieht man jede Meldung welche am Empfänger rein kommt
  •  mit LHEARD wird das ganze etwas zusammen gefasst daher
    •  wer, was, wann, wie stark und mit welcher Hardware wir durch:
      •  dist .. Entfernung
      •  pl Länge vom PATH, also wie viele HOP-Beteiligte hat es gegeben
      •  m wurde bei älteren Versionen bei einem MASH-HOP aktiviert aber zeigt sich ja durch pl auch, daher wird m in Zukunft anderswertig verwendet

F: Welche eingehenden Meldungen können am Node zur Anzeige am Display oder via APP ausgewählt werden?

A:
– DM Message mit Rufzeichen und SSID ist klar. Muss passen
– keine Gruppe gesetzt alle Gruppen-Meldungen (GRC) werden angezeigt bzw. zur APP gesendet
– wenn mindesten eine Gruppe (max. 6 möglich) gesetzt ist werden nur mehr GRC passenden zu den gesetzten Gruppen angezeigt bzw. zur APP gesendet
– NOALLMSG (via APP, WEBService oder Konsol-Kommand) auf  on –>  keine Meldungen an Alle (‚*‘) werden angezeigt bzw. zur APP gesendet

Q: What position data is displayed in the app and for how long?

A:In this version 4.21, the app saves the nodes for 7 days. This will be reduced to 5 days in the next version. For a node to appear on the map in the app, a POS must be received from the node connected to the app. If you are not connected to the app at a time when a POS is "in the air", it cannot appear on the map.

Q: Is it possible to change the transmission interval of the GPS location data? Or is it only sent when there is movement, if so what is the interval?

A: If you are in MeshCom basic mode, the position data is sent at 30-minute intervals. If you switch to tracking mode with the command - TRACK on command, positions are automatically sent out when a connected GPS-RX changes. In tracking mode, the positions are not transmitted on the MeshCom frequency (EU...433.175) but on the LoRaAPRS frequency (EU...433.775). But even in tracking mode, if you do not change the location, it switches back to the 30-minute interval.
This should reduce the AirTime via LORA to what is necessary to get all your messages away.

Q: My node does not display the time immediately after a reboot, when is it created?

A: The node receives the time from the MeshCom server via a gateway. This message is sent every 5 minutes. If you have an RTC (Real Time Clock), this time is adopted immediately but still synchronized with the server time every 5 minutes. This time is also displayed immediately if the GPS is connected and receives a SAT-FIX. The GPS time is not overwritten with the server time.

Q: Why does the clock show the wrong time?

A: The time that comes from the MeshCom server via a gateway and also the time that comes from the GPS is always given in UTC. It is therefore necessary to set the time offset to the local time. Either via APP (Node UTC Time Offset), via WEBService or serial command (- - utcoffset 2.0 for summer time CEST or - - utcoffset 1.0 for standard time CET).
)

Q: What do I have to do when using an APP via Bluetooth if I equip my MeshCom node with new firmware and also use ERASE?

A: The "old" existing peering information must be deleted in the system settings under Bluetooth.

Q: What are TEST MESSAGES ?

A: Das sind Meldungen welche im Text mit dem Wort „Test“ am Anfang des Textes haben. Wobei die Schreibweise „Test“, „TEST“ oder „test“  egal ist. Test Meldungen dienen dazu um am Dashboard zu überprüfen ob der Sendepfad funktioniert.
Auch DM Meldungen welche im Text mit „Test“ beginnen werden nicht weiter geleitet. Es wird auch keine Rückmeldung („ACK“) gesendet und somit wird keine Wolke mit Hackerl gemeldet. Wenn sich jedoch zwei Nodes direkt auf der HF-Frequenz hören werden die Nachrichten schon angezeigt aber auch nicht irgendwie quittiert. Auch Testmeldungen an eine Gruppe (GRC) werden nicht weiter geleitet.

Q: What does the green tick mean?

A: If a message from the APP has arrived in the MeshCom node via Bluetooth, this is reported back to the APP and displayed with a green check mark.


Q: What does the green cloud mean?

A: After the message has been sent out by the own MeshCom node and at least one other MeashCom node has heard this message and sends it out again (mesh network). The own NODE receives this message and passes on this information to the SmartPhone APP. In short: at least one other MeshCom node has heard us.

Q: What does the green cloud with a small check mark mean?

A:
1) The cloud with a small check mark gives us the information that our message was received by a MeshCom gateway node and passed on to the server.
For this a special ACK message goes from the gateway node via mesh network back to its own node.
2) If we have sent a direct message (DM), this cloud informs us with Hakerl that the destination callsign of the DM message has been received.
For this purpose, an ACK message goes directly from the receiver node back to the sender node via the mesh network (including MeshCom server).

Q: The Hop number, in the DashBoard, what does it say ?

A: The hop count always counts down by a maximum of 1 from 5 when a message has passed through a node, i.e. has been sent out again. 4 means that the message has just made a hop. If the counter reaches 0, it will no longer be sent out again because it has made the maximum permissible hops. This prevents messages from being sent again and again forever.
Additional note: ah thanks for the clarification! I previously thought it was the number of hops the message had taken to reach a GW. I was surprised that the values were so high. So it's the other way around - the remaining hops are displayed. "Hops remaining"