Version 1.3.25 is out with a great fix for a smart position broadcast bug that was spamming the mesh with position updates, this should improve stability quite a bit.
There are also some cool new features that I have tested as working for the first time in the last week.
RAK Buzzer working for startup and shutdown tunes on Slot C
Environment Telemetry is working nicely for available I2C sensors (Tested on a RAK 19007 on Slot D), a telemetry log is available on the node details view in the Apple apps.
A 1.3.25 Android version is available and a 1.3.25 version of the Apple app is available in TestFlight on iOS and macOS is awaiting beta app review.
We are still interested in your experience with default settings (region can be changed in both apps).
WiFi features including the WebUI and MQTT are not a part of this preview.
you introduced a cool info screen when Lora settings where unset in version 1.3.23. Sadly that is gone since 1.3.24.
Message acknowledgement doesn’t work since version 1.3.24
and if I set the display carousel interval it works until the Device is switched off or goes to sleep. With a Heltec board Bluetooth seems to be off and I can’t connect to the device anymore. With a T-Beam the display is off and can’t be switched on again. Only re-flashing helped me here.
I’m using the iOS/macOS App 1.3.23 (51) and the device firmware 1.3.25.
Channel/LoRa settings are sometimes not written. In the serial logs, I can see it is unable to write the config file to storage sometimes.
Message delivery confirmation is broken.
The device owner’s name and shortname remains unchanged on the T-Echo screen.
I tried out 1.3.x in general to observe range improvement using a combination of VeryLongRange/Slow modem config and compression. Right now due to the aforementioned bugs I didn’t take them out for a field test.
I installed 1.3.25 this afternoon and deleted and replaced the iOS and Android apps. I unpaired/ forgot the devices in the Bluetooth screens.
Everything paired properly, and went directly to ‘Properly subscribed’ in iOS, Android also worked well. No problems. Locations seem to be shared properly. Everything is getting quite slick.
However, I could not send or receive messages. They appeared to send, but nothing ever appeared at the other end. In Android they eventually got a line through them, in iOS they never said ‘Acknowledged’ under them. Nothing showed on the T-Beam’s screen.
I had a few of these in the Mesh Log: ROUTING PACKET received for RequestID: 999094211 Error: We reached the max retransmission count (typically for naive flood routing) - 7/18/22 11:31:55.1520
So I changed the ‘Number of Hops’ from 3 to 7. Then I was able to send a message from Android to iOS, but not the other way.
Android > iOS = Successfully sent and received on iPAD and TBeam screen. No tick seen on Android. (No ACK).
iOS > Android = Message seems to send. Shows ‘Acknowledged’ (ACK), shows on Tbeam screen, but nothing received on Android device.
Also, setting the Region in the iOS app doesn’t ever appear to set according to the UI. Even though the Mesh log shows:
Saved LoRa Config for Meshtastic 1320 - 7/18/12 11:43:05.6830
As soon as you load the LoRa screen in the UI again, the region is blank again.
Power cycling the Tbeam fixed this behaviour.
I couldn’t get the Tbeam to connect to the Android as ‘Properly subscribed’ after the power cycle. I had to Unpair/ forget it in iOS Bluetooth then rebind it.
I think channel settings need a reboot every time. @mc-hamster I have seen zero cases in 1.3 where changing lora settings does not require a device reboot. For 1.2 I feel like it was only one preset, but it seems to be all now.
Any clues why iOS > Android messages don’t send, unless you set hops to 4 or more?
Why does the log say: ROUTING PACKET received for RequestID: 999094211 Error: We reached the max retransmission count (typically for naive flood routing) - 7/18/22 11:31:55.1520
Any ideas why the Android app doesn’t show incoming messages or ACKs? (Messages appear on the Tbeam screen, but not on the Android device).
I have not seen the hop behavior you describe, I never change hops and have not found it necessary for any of the functionality to work. I ran a 100 sequence range test a couple of times Friday on 1.3.25 nodes and got both acks and messages for all of the messages. There does seem to be a periodic routing issue when there are only two nodes similar to what you describe, I would not focus on the hops.
The routing packet error means exactly what it says, the message got no acks after transmitting the hop limit number of times.
I have two android phones and mostly use iOS devices. I have been testing range testing with one of each because I wanted to make sure iOS behaved the same as android does already.
Meshtastic uses flood routing so hops is the number of times a message is re-broadcast before it stops, I don’t think it really cares about the number of nodes (though I suspect it may need to care if there are only two). The new routing essentially try not to waste a hop on a very close node.
