I just spent some time working through the great list of ideas you offered during the 1.0 development. I’ve tried to approximately sort these lists in the order I think I’ll work on things now that 1.1 development has started.
Fundamentally - this project is supposed to be a) useful to people and b) fun/friendly to use and develop. So please don’t feel bad if your particular favorite feature isn’t high on the list.
We have a fairly large group of occasional developers and a few more active ones (lately me, @mc-hamster, @lgx and @Professr). The devs work on whatever they are excited to work on . Also if you are interested in being a dev, we are happy to encourage and mentor as needed. If you do want to work on a particular feature or bug, please attach your name to it on the wiki so we know it might happen.
So please read the wiki page I just (fairly brutally) edited. I’ve added some context/description at the beginning of the page which might be particularly useful. For a few of the ideas I’ve attached notes at the end of them (look for ‘geeksville’ with my thoughts on why the priority is what it is) If you think some idea you’ve mentioned really should be higher on the list, please post in this thread.
Ok, so this is a nice planning of the features.This project just has been much more interesting than it is.
My suggestion is to work on a TODO list (You can try Trello if you consider).We should have a clear step by step plan before moving in the next week and it would help devs and other people to follow the plan.
For now, I will start ordering new bords specially for this project.I think I’m gonna also consider a CubeCell as a repeater.
Insert geo-tagged messages into google maps app? (dunno how feasible this is)
Ability to enter in AES encryption key manually or to seed the RNG manually and get reproducible keys
QR code scanner integrated into app?
Ability to tweak hop limit in app
Display how many hops a message went through(useful for testing)
Display message SNR in app
I recently ran an experiment with some new users, and sharing the encryption key was one of the issues we encountered. Even when using google lens to scan the QR code, the phones we were using still wanted an internet connection. It looks like currently the app is using SecureRandom to generate the AES key, which is secure but doesn’t allow one to seed the random number generator. I think a less secure key generator option where one can type in some characters to seed the Random random number generator and produce an encryption key which is reproducible on other phones would have been helpful.
The WiFi Client code and initial HTTP server code will be checked into the dev-wifi branch tonight. Was going to do it last night, but I broke the CI and need to fix a small something.
I did run into a bug in the ESP32 SDK (They introduced the problem in Oct 2019) which has not yet been resolved – it affects being able to wake up Wifi from power down. I found the PR for their fix but it has not yet been merged. What I will check in will work enough for now, but we need to have a medium term workaround until Espressif fixes the SDK.
Since all nodes know their position it would maybe be possible to send messages to locations, (point on map, or draw area on map), send message to nearest node(s) or nodes within an area. this could be useful for emergency warnings.
Will this be usefull in limiting unneccesary network traffic?
Also to tie in with @mc-hamster 's work to implement wifi/HTTP I have been thinking about the upcoming ID changes, from node ID to app ID, and maybe we should keep the node ID as a separate ID, so than it is possible to message a single node, with everyone directly connected by bluetooth/wifi getting the message.
Also a message box, so that users not currently connected can receieve messages either addressed to them, or the node, or the area/location as they reconnect.to this node.
(this is useful for public nodes, emergency services as few users will have a personal device)
There would probably be needed some timeout for the messages(24/48 hours?), I don’t know how much space there is for storing unclaimed messages, maybe specify pr message?
[message] [timeout: 24h] [recipient:all wifi/Ble logins at this node/nodes in this area]
I’m sure similar thoughts are being thought
I am amazed by the rate of develoment on this project. Good job Devs:
I’m gonna pitch the idea of porting to a device that’s much easier to acquire (i.e., not Ali Express). I have two collecting dust, so I’m biased, but other options would be cool too:
Pycom LoPy4 (LoRa + WiFi + Bluetooth. No GPS, but readily available via mouser, etc.)
I see other boards on the wiki. Maybe some are more readily available and I just don’t know it, but a lot of them are sourced from the same places causing folks to sit around and wait for cargo ships to sail the seven seas for a few weeks.
hmm - can you point me at the PR on slack? We already use a custom build of ESP-IDF for other bug fixes I needed to make. I could pull in that PR and rebuild.
My biggest wish is that Meshtastic would become the default civilian long-range comm layer for the TAK system.
For those not familiar with the system, TAK is a suite of geospatial awareness applications (which is a fancy way of saying “a map that talks to other maps”) developed by the US Air Force.
The most popular TAK application is ATAK for Android. It’s Google-free, sideload-able, fully offline-able, can work client-server or fully decentralized and can import most geospatial data sources and formats known to man into a superbly integrated 3D mapping engine. It can even FLY DRONES. I’m a long time user and great fan of this app.
Previously only available though government and underground channels, the ATAK app has been recently released under GPL and published at:
There is currently a complete lack of affordable civilian long-range comm options in the ATAK app. By default it supports some military radios, not really useful to peaceful users :). There’s a commercial closed-source plugin for goTenna Pro (there used to be a goTenna Mesh plugin too, but it got cancelled for business reasons). And that’s it.
I think there’s a great opportunity for the Meshtastic project right now to become “the” ATAK radio - basically what goTenna Mesh had a chance to be and opted not to.
There have been a couple of ATAK devs that have made posts in the past about using meshtastic as a transport for their project - I think that would be great (one of them made a Go API for talking to meshtastic). I’m happy to answer questions if they have questions on either the python API or the (alas, minimally documented) android api.
I tried different variants of turning off the wifi, but they’re all aliases of the same on the back end. Also tried not turning wifi off before the radio is turned off, that was a disaster.
I’ve checked in the changes into dev-wifi. There are two known bugs. One to keep track of the Espressif SDK bug and the other is that the branch is now broken for the nrf52 boards.
If anyone is familiar with the nrf52 boards, I could use a hand with fixing that build.
Next - going to implement a Soft AP mode where it will broadcast its own network.
If I were to “scratch my own itch” and work on some code to enable GPIO stuff, what guidance should I get beyond Github issue #182 ?
I’m not sure yet whether my personal use cases make sense in the device code, of if I’d be better hanging an Arduino off some GPIO pins, or a RasPi Zero off the usb port (and doing all my stuff in Python).
What I’d like to do is have a few LEDs I can turn on/off, and a few buttons that send “canned” messages (“Let’s all meet back at camp!”, “Come to me!”, “I’m coming to you!” - with some non-phone means to select other mesh nodes for those last two.) I’d also like the ability to control a string of WS2812-style LEDs. That’d let me have, say, a circle of 16 LEDs which light up showing the direction to each other node (possibly a distinct color for each node, and indicating distance by brightness).
I’m guessing “push buttons on one node, turn on LEDs on other nodes” might be common enough to be core Meshtastic functionality, but probably “drive a string of individually addressable RGB leds based on some specific algorithm using other node id, direction, and distance” almost certainly isn’t.
Then I googled how to create my own Fork of the Meshtastic project and started to put my changes there before feeling comfortable contributing.
WS2812 has a lot of tight timing requirements, probably will use more available CPU resources than what’s available here – that is without glitching the WS2812 or the device. Take a look at the APA102. It’s just a few more cents more per LED and has almost no load on the CPU in exchange for using just one more GPIO.
I was also thinking of building in an output for an alarm, light, horn, bell or buzzer. Maybe some day.
I should clarify, I’ve got as far as installing/configuring PlatformIO, and successfully building and installing my own copy of the device firmware onto both TBeams and LoRa2 boards (with a stupid tiny code update to change to the screen output so I can confirm I’m really running my version…)
And you’re right about ws2812 timing stuff, but I have a fair bit of experience driving that from an Arduino, so my tendency is to assume I’ll reuse some of that code. You’re right that probably WS2802 or APA102 would be better choices, except I have quite a lot of WS2812 strip (and production samples of strings of 50 of them) kicking around here (we used WS2812 at a startup I was involved with 4-5 years back, because the difference between 3 and 4 wires between LEDs mattered a lot back then…)
I guess the advice I’m asking for is - does geeksville (or anyone else in the dev team here) already have strong opinions on how they’d like GPIO implemented in the core Meshtastic Device codebase, and can I do some or all of what I want in a way that helps out there? From what I can find in this Discourse, discussion about it went a but quite past July or so, and there’s a few hints that maybe it’s planned to happen on top of other work in the queue for named entities and MQTT stuff?
. Also if you are interested in being a dev, we are happy to encourage and mentor as needed. If you do want to work on a particular feature or bug, please attach your name to it on the wiki so we know it might happen.
