@geeksville Hmm … 1.2.0 may also be a good opportunity to get away from region specific builds.
5 Likes
Yeah. Everything is all ready for that except no gui yet on the device to let the user pick. I guess we could just “default to USA” and if you want different you’ll need to use the python, web gui(?) Or Android app to change it.
For android we could even guess from the phones region code.
1 Like
but I hate those region builds (omg so slow and huge and ugly - for just setting an int constant).
So I just did it - btw - progress is going well, about half done, for the list of tasks I’m doing see docs/software/TODO.md:
4 Likes
… just thinking of the tech debt that stands out. If moving away from region builds would impact the user experience, it may not be the right time for that.
I have two ideas on how to simplify setting that int, I’ll mull over those a bit then send you a PM some time today.
1 Like
If the region isn’t set, could you have the device go into some sort of no region set mode where you press the middle button to change the region. When the screen shows the correct region, you reset the device and are all set to go.
4 Likes
Yes, that’s what I was thinking for a minimum device gui. Alas my queue of work has a couple of months in front of this one.
I think for now it will be “default install the device will use usa freqs”, Android app will force you to choose the correct freq on first connect.
1 Like
Center of the universe and all, it makes sense. 
@geeksville Your approach for using the android app will get us where we need. We can always refine it later.
Another approach would be to make region specific SPIFFS binaries which is loaded onto the device by the install script.
A file like /region.cfg could include the value of the int that we need to specify the region.
@isinglass Jumped in with the idea for the on screen configuration. That would be the other elegant solution.
These other solutions could be implemented in due time. No need to wait on them to get 1.2.0 done.
1 Like
This is what I was thinking of as well - perhaps powering on the device while the middle button is held in could trigger a low-level configuration mode if a display is attached/detected? It would be great if we had more buttons available - having only 3 buttons and one being ‘power’ and one being ‘reset’ is rather limiting in terms of a user interface 
Thinking about it more, the ‘hold’ function of the middle button to set the display brightness is nice, but probably far from the most useful thing that can be done, especially given the paucity of inputs. I’m not about to suggest navigating on-screen menus via morse code, but if it helped to make configuring the device easier in ‘standalone’ mode, I’d consider learning something beyond . . . - - - . . .
[at least, I think that’s SOS in Morse… One of those weird things you learn in gradeschool…]
Now get this … not all devices have a button. Gasp!
True, but don’t all devices with the provision for an SSD1306 display at least have GPIO for button inputs?
This is an exception. Most do.
One of the first things i did was solder a button on the GPIO 12 to allow the navigation between different pages on my TTGO Lora32.
1 Like
Oh, interesting… Though perhaps I should have been more specific - even if the device doesn’t have a proper button onboard, it probably has a few GPIO solder pads that can be jumped with a paperclip in a truly MacGuyver-esque fashion.
2 Likes