oops - yah - recent display improvements might have been related to this new bug. will fix soon. thanks for the report!
btw @NEKLAN - I haven’t forgotten about your bug report. It is at the top of my queue (still - took a day off for hiking), I should get to it later today or tomorrow.
@neklan - it turned out the fix was simple. It was a strange setting on the Soyes phones.
And good news with this change, the soyes reconnects to bluetooth devices after reboot. So your phone should be fully functional now. It seems solid to me and I’ll be using this phone as one of my three “development” phones now. Please comment in this bug with how it works for you.
Details on what to change are here:
1 Like
0.7.84 of the android app is out (for alpha and beta test members)
Just fixes a few super-rare autobugs. And adds some debugging output to track down one more bug. If this release is okay I’ll be making it the new official build.
Ps @NEKLAN, sorry, the Soyes phone still works sometimes vs sometimes not - I think I’m going to have to give up, whatever they did in their BLE implementation is just too buggy to work reliably. Even if I try it with a BLE headphone it shows the same problems.
2 Likes
@geeksville just tried 0.7.84 on a tbeam running the latest version. Still get a problem with my Sony model C6903. The app picks up the device really quickly. I also get the pairing request and pair at the BT settings menu (with not apparent error). However if I go back to the app I just get the message please pair device in Android Settings. From the cloud icon state no connection has been made. I reported the bug. Sorry this Sony is causing so much hassle!
Ooh. Ok feh, I’ll look into this today!
Thanks. Much appreciated. If it helps 0.7.80 seemed to work quite well.
1 Like
Android app: 0.7.84
Tbeam firmware: 0.7.9
Phone: original pixel
Everything seems to be working good for me! Thanks!
1 Like
All our T-beams are at 0.7.9.
Interestingly one of our andriod devices upgraded to 0.7.84 without any intervention.
Mine, however, despite repeated delete and reinstall from the play store sat at 0.7.82. It was only after deleting app storage, that it upgraded as soon as I reloaded from the store to 0.7.84. I wanted to put it down to a delay / different app store server on the Google side but; this clearly came down to the storage & cache empty.
Other experiences we’ve had are pretty great. Just received our OLEDs which I’ve put in place today. So we’ve seen on-radio UI for the 1st time it’s pretty slick. Nice work!
Can I ask if the percent radio strength is logarithmic or linear? Also, the direction towards the other is relative to North? I looked for the docs but could not locate.
Some of the Android UI querkiness seems diminished; and it’s certainly more responsive - however, double messages & disappearing history are still present.
I also got no ‘ack’ ticks on the UI a couple of times despite being sat in the same room as the other party, and they received messages & response near immediately visible on the T-beam. I should also add that my given-name was visible on both T-beams, but not on the remote UI for some time.
In general a real uplift over the last days in functionality and stability.
I’m going to comment on the rather splendid new aerials we researched & received today (they are a bit massive though).
1 Like
bug here so we can chat as needed about it: https://github.com/meshtastic/Meshtastic-Android/issues/76
android app 0.7.85 is up. It is a minor release just to fix some autobugs (and hopefully fix the problem on @feh123’s phone - which I’m remote debugging).
Also it fixes the “old messages are not kept on the messages screen” bug.
@sens8tion, regarding your question “Also, the direction towards the other is relative to North?”
According to my understanding, the direction is relative to your direction of movement. The device calculates its direction (heading) from a couple of your last GPS positions, and thereafter shows the direction to other nodes (if your node knows their position).
@geeksville or @Professr, There could be an option, for changing the compass, on the node, to north up or heading up? Moreover, there could be a small N on top of the compass for north up, and a small sign beneath the compass for heading up?
3 Likes
That is correct and yeah a North up option would be a good idea!
(oops 0.7.87 had a build issue, I just pushed a hotfix to the play console)
0.7.88 of the android app is ready for alpha testing:
- @lgx’s cool new battery level stuff is in - it shows battery levels for all nodes in the mesh
- firmware update button now properly handles clicks
- Fix one more bluetooth bug - should make app work better on older phones (I made a stress tester which allows me to fake error returns from any BLE call and ran that for a long time)
- Fix a few autobugs
- A few brands of phones try to filter log messages, so for those phones I blacklist them and just do all logs at ERROR severity (so the log reports are actually useful)
3 Likes
If you mean add a north indicator on the device, that might be doable. The problem is rotation; it’s vector graphics so we’re doing 3D transformations on 4 points already for the arrow. Adding a letter N would be 4 more points and 3 more lines we have to transform / draw per frame. It’s using a fixed float library for the math so it shouldn’t be too bad, though, so I will try it out and see what the impact is.
1 Like
@Professr, In north up mode, N would be statically on the top of the circle. Regarding heading up, there could be a different static symbol beneath the circle, to indicate heading up mode? The symbol for heading up could be a small upward arrow, or something more descriptive. 
Therefore, there shouldn’t be need to do coding for new transformations?
1 Like
The reason for requesting North up is, as many will have experienced; direction calculations via GPS are poor. Add to this that the most likely thing we do to look at the device, is stop.
Also, without a North (or other) datum, it’s impossible to tell what state the direction sensing is in.
1 Like
Good point. I plan to abstract out the long-press functionality for the middle button (I really want to take the excellent screen-brightness setting and put it behind a long-press menu on the main display) so I could have that switch between north-up and offset heading views. For now, I’ve added a small “N” to the compass circle to indicate where the device thinks its heading is, since that heading is already part of the calculations for where the node direction arrow points.
3 Likes
btw - if a couple of folks could report back on the 0.7.88 android build that would be super useful. I’d like to promote it to production (because the production build is over a week old) - but I don’t want to do that until some other folks say it was good for them.
1 Like
everything seems to be working for me with 0.7.88 android build and devices on 0.7.10.
I haven’t done a ton of testing but tried connecting a few times and sending messages, no issues.
1 Like