Menu Close

MeshCom 4.0 FAQ

Questions and answers

Q: Can a HELTEC V3 / 3.2 be put into sleep mode?

A: A HELTEC V3 + V3.2 can be set to sleep mode by pressing the RST + PRG buttons simultaneously. The HELTEC can be reactivated by pressing the RST button.

Q: My HELTEC E290 can no longer be reflashed, the serial via USB keeps reconnecting, what can I do?

A: Process:
  • Unplug USB from PC/laptop.
  • AKKU on? then unplug it.
  • BOOT buttons directly on the board by the three buttons, hold and reconnect the USB.
  • Start the flasher and release the BOOT button when the % display starts to run

Q: Can an EMCOMM message (EMC) now be used by anyone? Also for other emergency alerts, or was this a special new case?

A: No, this is not a special case. As you have already seen, the top lines of the dashboard have always been intended for warning messages. Only an extension has been added so that group 9, which is otherwise not displayed, can be used for this purpose.
The message is written as a text message beginning with "EMC:" and sent to the GRC 9 group.

Q: What are the PL and M values in the LHEARD display on the WEBServer?
What does this indicate?

A: to gain experience with the protocol (AirTime, robustness, ...) you need information:
  •  With the RX-LOG you can see every message that comes in at the receiver
  •  with LHEARD the whole thing is somewhat summarized therefore
    •  who, what, when, how strong and with which hardware we go through:
      •  dist .. Distance
      •  pl length of the PATH, i.e. how many HOP participants there were
      •  m was activated in older versions with a MASH-HOP but is also shown by pl, so m will be used differently in future

Q: Which incoming messages can be selected on the node for display on the display or via APP?

A:
-DM message with callsignand SSID is clear. Must match
- no group set all group messages (GRC) are displayed or sent to the APP
- if at least one group (max. 6 possible) is set, only GRCs matching the set groups are displayed or sent to the APP
- NOALLMSG (via APP, WEBService or console command) set to on -> no messages to All ('*') are displayed or sent to the APP

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: These are messages which have the word "Test" at the beginning of the text. The spelling "Test", "TEST" or "test" does not matter. Test messages are used to check on the dashboard whether the send path is working.
DM messages that begin with "Test" in the text are also not forwarded. No feedback ("ACK") is sent and therefore no cloud with hacker is reported. However, if two nodes hear each other directly on the RF frequency, the messages are displayed but not acknowledged in any way. Test messages to a group (GRC) are also not forwarded.

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"