On the steep development curve of the cross-platform app, now it’s the crucial time to make the phone talk to the TTGO. Which means using protobufs.
After taking a deep look at the defined databags, here are a few considerations.
message Position battery_level shouldn’t be here. I’d add accuracy, it is given by default by most geolocation plugins. time should be renamed timestamp or sent_at as “time” is reserved in many languages.
message User
Is there a real need for long_name and short_name? Can’t we just use a nickname and cap it to x chars so that it can fit on tiny screens too?
message ChannelSettings tx_power useless.
Move ModemConfig and other hardware settings to the more general “RadioConfig” protobuf for global hardware configurations.
Uncomment
// uint32 bandwidth = 5;
// int32 spread_factor = 6;
// int32 coding_rate = 7;
in the app there will be the possibility to switch to “Advanced Mode” and tune-up these parameters.
message RadioConfig position_broadcast_secs : In another discussion it seemed we needed a spot position sharing pretty much like messaging apps where I can send my current position as a message to somebody.
Which ones of these should be configurable via app?
uint32 wait_bluetooth_secs = 4;
uint32 screen_on_secs = 5;
uint32 phone_timeout_secs = 6;
uint32 phone_sds_timeout_sec = 7;
uint32 mesh_sds_timeout_secs = 8;
uint32 sds_secs = 9;
uint32 ls_secs = 10;
uint32 min_wake_secs = 11;
ChannelSettings channel_settings = 2; why here? Isn’t RadioConfig supposed to be general?
wifi_ap_mode should be an enum supporting Access Point, Station and Off modes.
Clarification of these points will be very much appreciated for a deeper understanding of what kind of info is transmitted on the mesh and the inner tunings of meshtastic.
re: battery_level. This is kinda an artifact of the state we need to keep in the NodeDB for each node. I’m not so sure we should move this field out because it would mean adding one level of our protobuf heirarchy (so two extra bytes on the wire).
re: accuracy, good idea - though we will often not populate it because we want to keep the position packet small
re: timestamp - good idea. also good post 1.0
long name is useful for use in the app - especially once we support gatewaying to other message systems.
short name is nickname (though I’d recommend not changing it)
Why? - though we we should change the default 0 value to mean ‘maxpower’ so in the common case it doesn’t take up any space in the protobuf.
I think there is a slight misunderstanding here. The state inside ChannelSettings is the minimum config needed to describe a channel (so that it can be shared). So modem_config needs to be here. Though we will move a few other things into this protobuf as we progress.
Agree, though we need to do this taking into account how we want simultatenous multichannel support to work.
The radio config is union of state that any client app can change about the device. ‘preferences’ is the device specific config. ‘channel_settings’ is the channel info that radio is using. When we add multi-channel channel_settings will change into an array of currently provisioned channels.
I cannot inherit protobufs in ionic so I had to rewrite everything and this thread is just a collection of thoughts, glad it was helpful.
Battery level should go in a dedicated message like a system_status or power_status containing other info about solar-power/charging as well as current consumption.
I don’t get the need for a short and a long name, let’s just use a nickname and if really needed we can take the first two chars. UI-wise is also very confusing to have two input fields asking for a relatively identical info.
tx_power is useless because you don’t know what type of modules people will mount, it can be the E22 with 30dbm or the other E20 with 22dbm. If you really want to keep it, it should be a kind of potentiometer like 25% - 50% - 75% - 100% power, the firmware will handle the request accordingly.
I believe the misunderstanding comes from the crossover between channels and hardware configs. The way I see it, hardware configs are shared by all channels on the same device. After all, channels are a layer up in abstraction in relation to LoRa.
Regarding position sharing, I’ve implemented a button to send a message with location data (whatsapp-like). Do we need a constant broadcast too?
I’m busy on the app so this time I won’t be making the changes on GitHub for protobufs.
The devices always do position sharing occasionally based on movement (in the background). So I’m not sure you need an extra “send my location button in the UI.” I’d recommend leaving that out at first.
Also play with the JS export options for the protobuf compiler - you might like the wrappers it generates (and they are automatically updated if the protos change)
protoc is the tool you use. Javascript instructions here.
Does ionic use npm for builds? If so, I bet someone has made a nice protobuf plugin that auto regens the JS code anytime the .proto file changes. (I haven’t looked)
If not, you can do what we do in the device code, a little script run by the engineer anytime they change the protobuf submodule in that project. Then check in the generated files into source control with all the other stuff. (Your commandline flags would be different per the javascript instructions in the link above)
I think we should basically leave it as is for now. I’m busy this week on finishing NRF52 and the esp32 pairing bug. The changes you propose are minor and I think we can make them after I’ve got the 1.0 monkey of my back.
Interesting. Did the “earthquake” example from the ionic tutorial still work? If so, then comparing how the example used the generated classes might help find the problem.
