Skip to content
Questions and answers
Q: How does the firmware react when several temperature sensors are connected?
A: The firmware only works with two temperature memories, one for indoor and one for outdoor use
- The reason for this is that we also forward the temperature values to aprs.fi via the APRS protocol and these are then also displayed graphically. However, the graph only offers 5 measured values per callsign.
- Displayed and graphically represented values in aprs.fi
- Air pressure measured
- Indoor temperature
- Relative humidity
- Air pressure calculated at sea level
- Outdoor temperature
- The firmware takes the indoor temperature value in the following order. The temperature from the higher-value sensor overwrites the lower-value sensor:
- The outdoor temperature value is taken from the OneWire outdoor-capable sensor (metal-encapsulated):
- Another outdoor-capable sensor is being planned
- SHT21 then becomes the higher-value
Q: Is there a Telegram or Matrix group where people can ask questions directly?
A: yes there is
- Telegram for questions, chat, info - here is the invite link: https://t.me/+xSvhuEq66b45NmNk
- (if the code has expired, send an e-mail to oe1kbc@icssw.org)
- This group is subdivided into:
- General - general topics
- Firmware issues - direct messages to the FW but important with notes
- Dashboard & WEB MAP & ICSSW homepage
- DEV Chat - if required when the developers solve a topic together with the users
- ESP32-E22 PCB - Project group for the development and assembly of MeshCom node boards
- Ideas - Please put everything "NEW" here that MeshCom brings into the future
- Interfaces - discussion on front ends
- MeshCom APP - everything about IPhone and Android APPs
- WEB Flasher - everything about flashing nodes via WEBFlasher
- Chat when testing - users want to try something and are connected here in the background
- Teleram group so that you can also participate in the communication of MeshCom from the Internet - here is the invite link:https://t.me/+AAXB-v4tmTIzYTQ0
- (if the code has expired, send an e-mail to oe1kbc@icssw.org)
- There are options:
- Read messages to "ALL"
- Messages to be sent to "ALL", "GROUPS" or DM and a callsign
- /help helps with the first contact
Q: What do the highlighted colors mean next to the callsign in the MeshCom Dashboard?
A: This is the status when a node/gateway was last heard:
-
After 3 hours of inactivity, a node/gateway is removed from the list.
-
After two hours of inactivity the call sign will be highlighted in RED.
-
After one hour of inactivity the call sign will be highlighted in ORANGE.
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"
We use cookies to ensure that we give you the best experience on our website. If you continue to use this website, we will assume that you are happy with it.
OK
