Protocols as a submodule?

Now that we have (unfortunately in my opinion) moved from hg to git, we might as well try and leverage some of the features of git.

In particular, the submodule feature makes it possible to push parts of the project into different repositories and manage their state separately from the rest of the project. While there are a number of things that I think might benefit from this, the one I think wins the most would be the protocols folder.

The downside is that you have to manage the state separately. An extra command to update to the latest versions in the build process. Similarly to push your changes back, branch, etc.

The upside is that it's now easy to work with different versions of the protocols and the rest of the project. So the build of the last release code with new protocols (something which I feel is of great value to the community) is easy. Similarly, if you're interested in working on protocol code but would rather stay with the release build - that's easy too.

Finally, and possibly most importantly, people working on other projects that use the protocol code - like the DIY mutlimodule - would be able to check out just the protocol code. i'm not sure how feasible sharing the code between the two now would be, but the ultimate goal here is to make it possible for such projects to use the protocols as a library/submodule/etc.

I don't really do much work on protocols so can't do much beyond set up the submodule. I'd be happy to do that if any of the people who do work on protocols is interested in seeing it.

I do support this in principle but there are many particular details we should figure out.

First, should it be done under the same group, deviationtx? I believe yes, but there are other people from RCGroups (@planger and @midelic) whom you mentioned in your post, who are also developing protocols and interested in them without Deviation. As their protocols are almost verbatim duplicate of ours we'd benefit from this effort, and some development was done in this direction, but as far as I understand not completed.

Second, how about Travis integration and nightly builds. I know too little about it to figure out how easy it is to retain CI builds and nightlies upon check in into a module.

We can add external collaborators to a repository with write permission. I've created a Protocols repository and invited @midelic to verify this is possible.

The hash you have checked out in the submodule is (well, should be) stored in the main repository. If you make changes to the submodule (pull, edit/commit), you need to commit in the main as well to record the hash. Similarly, you need to push both sets of changes to their respective remotes. Once that's done, the change in the main repository should trigger a build just like any other change.

Getting travis to update the submodules before the build requires adding the appropriate git command to the pre-installs script in the yaml file:

The protocol interface surface is quite limited. A protocol has only one exported function and uses very well defined set of externals to read the channels and to call the radio. Atmel AVR8 peculiarities are solved as a set of macros to mark progmem. And protocol code does not deal with hardware directly, so libopencm3 or any other hardware support library is completely irrelevant for this part of code, fortunately.

The only problem is telemetry, unfortunately is has very weak abstraction on protocol level, unlike the channels. We need to think about telemetry for sure.

Yes, protocols call the RF chip functions and they must be implemented outside of this module, as they are in midelic/pascal's code now.

Clock - we don't call any clock functions in protocol code, we just return required timeout in microseconds, so no dependency on clock.

Telemetry - yes, there are many value types, but the same is true about Channels - they're normalized to -10000..10000 range, but they can represent many actual protocol ranges. I would like to see Telemetry as just filling out the telemetry array in some detailed enough mapping (maybe floats, not integers) and then some kind of mixer which parse these values, maps them into sensible ones and display. The same flexibility as now in channel mixer settings.

Yea, timer - but it is always expressed in microseconds, and uses two functions CLOCK_StartTimer and CLOCK_StopTimer. They do it once in a lifecycle of protocol - at initialization (maybe call stop timer on deinit, but it's not necessary as far as I understand).

So right now the src/protocol/spi which contains RF chip drivers should be moved somewhere. Also support files src/protocol/protocol.c and src/protocol/Makefile.inc do not belong to the protocol module.

iface_*.h files are also Deviation-dependent - they contain Deviation's types like u8, u16 etc.

Telemetry - now we have several telemetry types, but what if all values representable in these types just live by themselves. Futaba's TXs have several types for GPS, temp etc. which represent corresponding instruments connected to the receiver. You can assign a type to a telemetry channel (or a block of channels in case of complex data) and they'll be deciphered from the channel(s).

The telemetry system is really in need of reorganization - it's all ad hoc on a per-protocol basis now. But this isn't the place to talk about it. So I'll just note that we don't use floats now, and that's probably a good thing since we don't have floating point hardware. Also, I'd like to see things set up with ranges instead of types, in large part so we can sanely add telemetry values to the mixers as percentages of those ranges.

And what if general telemetry field are just a nr as Tfield 1-100?
Then we need some kind of "ini" to define the telemetry field and label for each, Tfield 1 is volt 1, Tfied 2 is temp 1 etc etc. depending per protocol.

Is it really needed to decode, display all those telemetry variables in the protocol? If protocol is defined, could we not, just select scroll true the list as defined in the ini, (so per protocol there may be a smaller or bigger list), and user defines pick the values of interest and the Tx only read use those telemetry fields as user selected ? Other telemetry values not of interest are just discarded?

All a bit of topic but some related whishes for me:
a) I like to see some time thresholds on alarms and better use of telemetry to prevent too many alerts. So if telemetry event, V bat is Below 3.7V for more then 2sec (adjustable), only then alert.
b) I would like some very simple statistics; min-max values on telemetry fields and or an event counter, f.i. to see how many time RSSI was below threshold as set etc.
This just could be a handy fast check after each flight, may be discarded at power down.