Android Debug Mode - Please add?

It would be really useful to have a ‘debug mode’ in the android app. I know the app is processing all the data so it has it. Possibly just a toggle that adds this data to the screens? Generally I try not to be that guy who critiques beta software about features to add. This time I’m tossing it out there because I think this very likely would be something fairly easy to add and benefit a LOT of people. Sadly I suck at coding and I fully accept an, ‘If you want it, do it yourself’ reply :slight_smile: I’d buy you beers anytime though :slight_smile:

Information on each node (consider all these values to be time stamped):

  1. How long ago these items were last heard/updated: map location update, distance from a node, signal strength, number of hops, number of tries.

  2. The actual numerical signal strength for transmissions in the chat window or the list of nodes window. (Did that last transmission just barely make it through?.. am I approaching loss of connectivity? Was it rock solid and can I go for a faster speed setting?)

  3. A countdown next to the sent message in the chat window so we know how many times it has tried sending with no ACK and what the signal strength is. (I was making it through on try 1… now I moved to a different room and it’s taking 3 tries… Maybe I should change location for better reliability?)

  4. Speed settings and what they are actually setting the LoRa radio to in technical terms beyond just “Long Range” in the app.

  5. Show hop data for those of use that are using 3 or more radios so we can see how far our message made it and what node is the failure point in a net. Sorta like APRS can display all that data.

Basically just give us an option to see this technical data easier… so say I try swapping antennas to see what one performs better. Poll the radio on the other side and see what the received power is in dB or RSSI of sorts. Swap to a different antenna and can compare the two number and see what antenna is a better performer.

I realize some of this may be easy… like appending a numerical signal number in the chat window. Even if it’s derived. Some may be harder than I think.

A few more ideas (Less of a priority as I think they would require more work than the above ones):

  1. A button option to force re-polling of a node or all nodes (if the node allows it) for their current GPS/ battery power level/etc information for when things are lagging in the app. Similar to a force polling or force send for this data so it is updated as a priority. For security reasons, this could be disabled at the app level.

  2. A toggle to use the Phone’s GPS information as if it were from the node for a lat/lon when connected to a radio that has no GPS.

  3. A toggle (or build) to pair without a password. (Would solve tons of complaining right now about pairing issues :slight_smile: If I can see the pairing password in the serial stream, can the app not capture that and at least show it on the phone screen? Possibly just automatically pair? (not a coder here, sorry). It would solve the problem of me walking out of BT range, back into range, and the phone trying to pair over and over (still does it sometimes on 0.9.1)

  4. A new window in the app that will show a log of all the communications from the phone to the connected radio… Similar to attaching it to a serial port terminal, which I physically need to do on some of my units with no display to snag the pairing password.

  5. Forwarding SMS message… ok I won’t even go there :slight_smile: Joking.

Thanks for all the hard work so far. We appreciate it! The debugging stuff would help a LOT!



I’ve already began working on a “dev mode”

It will list all communications received by the phone. Signal included


That would be great. Would love to ‘alpha’ test that out.

Having the option of displaying that data in the current various windows would be a big plus.

Love to hear more about your plans if you care to share.

Again. Great work. None of this is meant to be a critique. You all are doing coding that I can’t do and I appreciate that. (fair to say we all do). Thanks!

The main idea behind the list of communications is to have some analytic data like :

  • history of a device to draw a path on a map of its position with each message sent
  • display the history of the battery life to predict when it will be out of usage

There are plenty of other ideas that could come up with the data collected :hugs:


Please feel free to message me when you need someone to test this out. I’m, to say the least, very excited to get me paws on this ! ! Much Thanks.

1 Like

That’s a really good list.

@devnull The work is in progress. The debug panel display every packet received from radio, in a raw message.

We can spot a time format error

A position received by another device:


Looks great! Are you releasing this version?


1 Like

Tonight, it needs a close button and reverse the order

1 Like

Any luck tying up the loose ends?

It’s in Pull request

Available next release i guess


Hi @lgx - I am seeing the Debug Panel, but only the message heading. I am not able to expand the message (tap, double-tap) to see the details that you show above. Is there some setting required to enable that - i.e. is this a bug or me?

I am running Android 10, on Samsung S10, Meshtastic App version 1.1.02.

(Edited to add a screenshot below)


When I look at the phone using Logcat - after a double-tap I see this information
2020-10-11 11:29:15.861 1012-1012/? D/GameManagerService: identifyGamePackage. com.geeksville.mesh, mCurrentUserId: 0, callerUserId: 0 2020-10-11 11:29:15.861 1012-1012/? D/GamePkgDataHelper: getGamePkgData(). com.geeksville.mesh 2020-10-11 11:29:15.971 12269-12269/? V/InputMethodManager: Starting input: tba=com.geeksville.mesh ic=null mNaviBarColor -855310 mIsGetNaviBarColorSuccess true , NavVisible : true , NavTrans : false 2020-10-11 11:29:15.971 1012-1012/? D/GameManagerService: identifyGamePackage. com.geeksville.mesh, mCurrentUserId: 0, callerUserId: 0 2020-10-11 11:29:15.971 1012-1012/? D/GamePkgDataHelper: getGamePkgData(). com.geeksville.mesh

Interesting. I don’t see any of what you posted. Header…

@lgx Is it possible to get SNR data for every packet? Not sure if it’s sent.

If you have a newer version (map again maybe?), please message me.



Next Android release on Google play will fix the missing data, when the apk is built in production mode, the serialized data are not displayed, not happening in dev mode, this bug was my fault.

For the SNR data, when the packet contains this information, it is automatically displayed, in fact the debug panel display raw data coming from the device. I’m planning to include the data sent to the device soon.

Hi ya’ll,

Sorry - I’m running a bit behind on getting back to do an Android release with all of @Lgx’s good works. I’ll have it out in a couple of days ;-).

Thanks. This information in really valuable for drive-testing. Thanks to both of you.

If there is a build to try now, let me know. I’m in Friday night tinkering mode.