I need to spend the next two days dealing with some miscellaneous broken house things, so I’m taking a very brief break from this fun project. I thought though, this would be a good time to give an update on usage and next steps. I’ll make a separate thread about 1.5 features.
But first I have to say ya’ll are doing a great job of helping each other. Huge thanks in no particular order:
The thirteen of you who have donated translations into your native language
Everyone who has sent in code fixes, improvements and bug reports. Especially those who have become pretty active co-developers @dafeman, @lgx and @Professr.
The remaining fixes for 1.0 are looking like they going pretty well, if you’d like to help out - see any of the items in the left two columns of our project tracker.
My personal work queue for the next 1-2ish weeks (just because I know some of you are waiting on bug fixes) is:
some channel names don’t work - check for illegal symbols per forum report
auto invalidate old BLE handles (bug in esp32-arduino)
disable software update button after update finishes
check BLE handle stability across sleep - stress test sleep/wake - btu_init_core calls gatt_init - which assigns handles global
@feh123 Sony Xperia Z1 C6903 running Android 5.1.1
first message sent is still doubled for some people
Android frontend should refetch the android messages from backend service on Resume
let users set arbitrary params in android
implement first cut of router mode: preferentially handle flooding, and change sleep and GPS behaviors
NRF52 BLE support
Usage has really been progressing at a good clip. Some stats: about 2000 people a day read this forum. The android app has a little over 1000 installs. About half of those people are probably just ‘tire-kickers’ - i.e. the app reports they don’t have a radio connected. But about 600 people regularly have radios connected to their apps talking to a mesh with at least two nodes. Usage is about 1/3 Europe, 1/3 Asia and 1/3 US+Brazil. There are still bugs (alas, of course) but the app reliability is now much better than it was just three weeks ago. I’ll include a screencap at the end of this update…
I’ve heard through the grapevine that a Chinese manufacturer will soon be pre installing meshtastic on the devices they ship (and I just reactivated BLE based software update of ESP32 boards - it will be in this weeks android release). I’ve asked them about this and as soon as I have an update I’ll post.
I’ll post a device build in a couple of days, which include some really good fixes contributed by the other devs.
Superb intro to the next wave, and excellent progress. We (the 3 of us in W Yorks, UK) have just bought into this merry game and are very impressed with how things are shaping up.
We can test methodically, perhaps scientifically over rugged terrain. We are operational, and have exchanged messages. We have grand plans for the transport, so the API is as important as the UI. Also I’d like to think about some telemetry so we can do better than seeing if messages arrive as a measure of performance. Please point me in the right direction for that - we are each data scientists, so comfy with going deep.
So I’m not doing much software this weekend, but I just did a bit of bug triage and I thought I’d send an update:
@slavino fixed support for the older tbeam0.7 boards (they will be supported starting in the next device release). I’ll release a device build in a couple of days.
@Professr is making a new ‘menu’ layer as part of improving our app UX
@Anelito reported some really great progress on a cross platform (particularly for iOS) app
The NRF52 boards are almost feature complete, the only thing remaining is the BLE API
The android bug queue is looking pretty good now
There is a ESP32 bug in BLE which causes devices to sometimes need re-pairing. I’ll work on this next week after I finish the NRF52 stuff
The remaining 1.0 work items are the left two columns in this list:
ok. 0.9.1 went mostly really well (but with one big exception see below). So this last week I haven’t been coding much (I have a crummy back and it has been acting up the last few days). Fortunately @Professr seems like she is happily merging changes into the device code tree (woot)! And @lgx fixed a good bug in Android app land.
I had hoped to start coding again today, but alas I think I need to take it easy one more day. But tomorrow I should be able fix issue 305 reported by @zone and improve the protocol documentation (finally) so that @CycloMies can improve it further ;-). Until bug 305 is fixed, some TTGO “lora32” boards (not TBEAMs) have a problem with rebooting on the 0.9.1 load - those boards should stay on the prior device firmware release a bit longer. It seems like some of those boards have defective SPI pram parts stuffed? (and we don’t require that part but in 0.9.1 I turned on probing for it so we could use it if present - and that probing goes really badly if the the part is not right)
btw - 305 turned out to be a relatively minor bug that only affects firmware update (and onyl when you are trying to update a node while it is receiving packets from another). 0.9.1 is okay for everyone (even lora32 boards).
I’ll push out a device build in the next day or two which fixes a few of the smallish # of 1.0 bugs.
alas - one more update on my playing hookie - I’m now on about week 1.5 of no programming and I swear I’ll be back at it soon (Fri?). This is the longest/crummiest bad back stretch I’ve ever had. The queue of doc tasks and remaining bugs to finish 1.0 is really quite short.
okay - I seem to be a all fixed again so I’m futzing away and will put out a device release tomorrow. Alas, usage is way up which translates into more new members in this forum. So I don’t think I’ll be able to carefully read all the threads from my two week absence. As always thank all of you for helping new users when they have questions.
If there are any threads that I’ve missed that you think I should comment on, please add an “@ geeksville” comment and discourse will ping me.
Get the NRF52 code running on @Corvus’ board (@einzeln00 has sent me some that should arrive soon)
Declare project 1.0, so we can start working on cool new things
( the following items are kinda tenative until we have a devchat on the post 1.0 tasks)
Ok - since this thread is turning into my personal (other devs work on what they want - as always any help is appreciated) queue update. Here’s an update:
My rough personal queue is now:
Soonish:
DONE: fix display bug #333 that shows for nets with >=4 nodes (today / tomorrow)
DONE Get the NRF52 code running on @Corvus’ board (@einzeln00 has sent me some that should arrive soon)
Declare project 1.0, so we can start working on cool new things
Septemberish?
New: add some sort of hack so that if folks want to deinstall meshtastic they can change GPS to NEMA (next two weeks) #334
( the following items are kinda tenative until we have a devchat on the post 1.0 tasks)
Repeater/router/super-long battery life modes sound really interesting for the kinds of things I’d like to do with meshtastic. I’d like to have the lead group in large group hike plant some repeaters as they reach the top of a ridge/mountain. Trailing groups would use them to maintain contact with those on the other side and the last group would pick up the repeaters as they pass through.
I’m also intrigued by the “new exciting board…”!!!
It has been about 10 days since the last update on my personal work queue. Since the bug count in the march to finishing 1.0 is (finally) looking pretty good, I’ll probably declare the device and android app 1.0 (though there will still be bugs) late next week.
Also late next week I’ll propose a guess of key 1.1 work items (aside from the usual bug fixes). Then we can chat and tweak that list of work-items (with the usual caveat that if a dev wants to work on item X - that’s the best way for item X to end up in the work queue, it is easy to become a dev - just ask and we’ll help).
For the next few days I’m working on a side project because a) it will help the RAK815 port, b) it will make it much easier for everyone to debug/test, c) it will allow continuous-integration builds to run actual meshes in simulation before blessing. It also might be useful for other projects:
My rough personal queue is now:
Soonish:
(DONE) Make Portduino and use it to run Meshtastic in simulation
Finish NRF52 support for the RAK815 board (use Portuino to run on MyNewt OS)
Fix a few minor bugs
Declare project 1.0, so we can start working on cool new things
Discuss 1.1 features/work-items
(@eriktheV-king I think already did this?) add some sort of hack so that if folks want to deinstall meshtastic they can change GPS to NEMA (next two weeks) #334
( the following items are kinda tenative until we have a devchat on the post 1.0 tasks)
Ok - I just declared the device load 1.0. Thanks everyone for your contributions! (Either code, graphics, translations, testing, or kindly helping new forum members)
In the next couple of days I’ll start a thread that tries to reference the 1.1 feature list wiki. Please edit that wiki with your ideas. When I do that post we can then triage and propose which items are in the 1.1 bucket (because a developer wants to work on them mostly…).
My rough personal queue is now:
Soonish:
(Done) I’m about three days behind on my (mountain) of github notifications. So later today/tomorrow I should get caught up there.
(Done) Fix Samsung bug on pairing with devices
(Done) Fix python bug with string preferences
(Done) Document how channel name->freq hash works for @tuxphone
(Done) Tell TTGO they should update their flash images to 1.0
(Done) Discuss 1.1 features/work-items
add comments on issue 182 (gpios)
nrf52 mergification for wifi
Finish NRF52 support for the RAK815 board (use Portuino to run on MyNewt OS)
(@eriktheV-king I think already did this?) add some sort of hack so that if folks want to deinstall meshtastic they can change GPS to NEMA (next two weeks) #334
( the following items are kinda tenative until we have a devchat on the post 1.0 tasks)
Cleanup and generalize the code (remote attribute support, let other code widgets do things with GPIOs)
Let ESP32s connect to wifi (and provide API access over a TCP link)
MQTT/internet gateway support (and let ESP32s gateway without needing a phone/PC helping). (@mc-hamster has actually taken a fair portion of this on - woot!)
I am hoping for the standalone WIFI and MQTT implementation. I think that could unleash the creativity of the community to do new things with meshtastic.
I’ve created a new branch for the development wifi work.
I’m currently working on the effort in my own repository, but as soon as it meets @geeksville’s review comments, I will merge my changes into dev-wifi.
WiFi is really stable right now and the the plumbing for a robust HTTP server is in place. There’s a bug on the Python API and when that’s fixed, it should be a few days for me to be confident with the WiFi changes before checking in my code to dev-wifi.
Something like this?
Even if only available on the local screen (to avoid bandwidth spamming) I see some usefulness for it while hiking or other activities.
?
