So there are now about 400 regular users. So I should probably become a bit less reckless about pushing out new code so often? Is there anyone out there who would volunteer to be alpha testers? Ideally we’d have a few volunteers so the work any one person would need to do is minimal.
Here’s kinda what I’m thinking (though it would mostly be up to the volunteer testers):
I only release the android app and device code to the alpha test group initially
Then sometime in the fiveish days that follow any of the volunteer testers does a basic “sanity” test. i.e. they could send messages between two nodes and see positions on maps.
If that sanity test passes they post on this thread saying “I just tested 0.6.7 and it seems good to me”
Based on that info (i.e. someone other than me could run the code), we release the build to everyone else.
Sound reasonable? Anyone want to do this (no long term committment required) ?
0.7.4 of the android app is out for alpha testing. If someone could try it and post here to say “yeah, I can send and receive messages with this app” that would be great.
Fixes for a number of bugs I introduced in 0.7.x (sorry)
Add early alpha support for direct USB connection to radios (cc @sexycyborg). A release later this week will add automatic connection/disconnection to the USB radio when it is plugged in. For now you need to go to the settings page and select it.
Fixes for the Soyes XS phone
Fix a few autobugs detected by google
I will also be releasing a new device load for testing in a few minutes. But they are independent - the new app should work with the old devices.
In addition to the new android app release (see message prior). If someone could confirm that 0.7.4 of the device code works for them that would be great!
This is an alpha test, if you don’t want bleeding edge, use the next oldest release.
Change nodenum and packet ID to be 32 bits (this should be backwards compatible with the apps, and this should be the last protocol change before 1.0). Longer nodenums enable the upcoming MQTT/internet gateway feature, longer packet IDs make the encryption more secure.
Only one phone available however I tested sending from phone and then reception on screen. Message reception and acknowledge working flawlessly.
Tested using OTG adapter to phone over USB. Worked great also. TBeam was discovered straight away and the unit stays awake. However the app still requires Bluetooth to be turned on otherwise an error message is received every time you change app screen. Is it possible to change the Bluetooth requirements or have an option to enable it within the settings screen?
Is there a reason to disable the “next screen” button on USB? Still handy to see battery charging and GPS status.
Sometimes within the app, when sending a message it gets displayed twice in the message log (unsure if sent twice). This has occurred after unlocking the phone after it has gone to sleep. On unlocking again after a second sleep, the duplicate message is gone but if you send a new message, the new message then shows twice. This can be repeated over and over.
Amazing work @geeksville! Would you like some kind of standardised response in this thread to give you a better idea of what has been tested and how?
Sometimes within the app, when sending a message it gets displayed twice in the message log (unsure if sent twice). This has occurred after unlocking the phone after it has gone to sleep. On unlocking again after a second sleep, the duplicate message is gone but if you send a new message, the new message then shows twice. This can be repeated over and over.
No doubt our testing reports will evolve overtime into something pretty standard. Just confirmed through App Settings that it was in fact 0.7.4 so a sneaky wee bug still floating around. Seems to be entirely GUI based as I’m not seeing any replication in the debug.
If the app tries to send a message to the device but it is sleeping, does the app retry once the device wakes up? If not we could perhaps just not write the message to the display log and give an error message about the device being asleep.
yes, if the app tries to send a message when the device is asleep the message will have a “cloud with uparrow” icon (which means ‘queued’) until the device calls back in to ask if the app has anything to go out.
Communication between two devices- OK. Duplicating sended message only after phone wake up. Message only show in app twice, not sending. Sending is OK (monitoring with SDR reciever).
I can confirm it’s working. I had an issue with app (switching between people and settings tab crashed/closed the app). It happened 3 times in a row and now I can’t reproduce it anymore.
thanks for the report! btw - that crash also happened to me. In my case, the cause was this. I think the workaround I just put in will probably fix it. Time will tell:
I submitted a bug report on this phone because Android spontaneously rebooted when I pressed the Android “Home” button from within the Meshtastic app, after configuring a new Meshtastic install. I haven’t been able to reproduce it.
I am also seeing some duplicate messages, but otherwise everything seems good.