Standard serial protocol to external module

[WZ9V]

Sorry if this has been brought up before.

I think it would be interesting if a standard serial protocol were defined for connecting RF modules to the TX. It seems a waste for OpenTX to convert stuff to PPM and then have another processor convert it from PPM back to digital and then send it out via the RF section like is being done for several projects I've seen. It seems like a two way message based interface over SPI could be defined along with a standard set of messages to be processed by the module. This would allow the model setup to say what protocol is needed and the module could respond by either switching to that protocol or saying its not supported along with allowing other features like binding and range checks from the menus. Taken a setup further a standard for telemetry data could be defined and them module designers could just package that data and send it to the TX for display.

I think an abstraction layer like this would allow for some interesting ideas when creating modules. I do realize those modules would then be specific to OpenTX.

[Philipp]

I agree with you that a somewhat standardized open protocol (e.g. openRF, openJR....) would give developers of open source modules like the openLRSng or this one http://www.deviationtx.com/forum/7-deve ... sal-module the opportunity to settle on a powerful standard for communication between module and an open source radio, in addition to PPM for closed source JR style radios. Such an protocol would be very transparent and would save module developers ,who feel limited by using PPM, the hassle of adapting the DSM or XJT protocol to their hardware. Furthermore this could be easily expanded to support telemetry, binding and maybe configuration of module specific parameters. For some special use-cases one could even use this the other way around, the module could receive channel data from receivers like the spektrum satellites, infrared, or anything else and push this data to openTX for use in trainer or headtracker applications.

This seems to be the logical next step, however developing, documenting and maintaining such a protocol can be quite an elaborate task, especially when it becomes widely used by many different parties.

[MikeB]

We already have an asynchronous, serial protocol available, on pin 2, used for DSM hack modules. So the hardware and driver supports that. We can accept serial data back in on pin 5 (the SPort input). On the Taranis, this has to be inverted. On the 9XR-PRO, we have a programmable inverter on this input so it can handle either polarity. The next revision of the Orange DSMX module uses the SPort signal to reply when binding, but this is non-inverted, so I'm not sure it will work on the Taranis.

Mike.

[jhsa]

Funny that I'm reading this as today something similar was mentioned in another forum..
What about writing a new open source protocol/firmware for the frsky gear?

João

[WZ9V]

Gotcha MikeB, but I was thinking bigger like what Philipp said. Essentially an OpenModule standard serial protocol that would be the transfer mechanism to a DSM, Hubsan, etc module. It would also define a telemetry return standard and the module could take the SPort, Spektrum, whatever info and push it back to the TX for display. Its the serial stream of the DSM hack module that got me thinking along these lines when I saw thet people are putting an Atmel 328 in a module to convert PPM to digital data for a RF transceiver. Seem like a SPI serial interface would be better and let the processor convert the digital channel values received from the TX in OpenModule format to whatever protocol was needed. Then instead of using pulse data on channel 8 as the rc PPM to SPI project did you could just send the required protocol from the model settings as part of the transmitter initializing the module. The module could even repsond back to the TX it it was the wrong module for that RF protocol.

Just a thought. I might try putting together some digrams to flesh it out as an idea.

[WZ9V]

Where? I'd be interested in that discussion. It just seems silly IMO to take digital data convert it to analog PPM then convert it back to digital to send it out over the RF link. Just because thats how it was always done. I'd like to see it done smart so that PPM based modules still worked properly (like the DSM hack).

Funny that I'm reading this as today something similar was mentioned in another forum..
What about writing a new open source protocol/firmware for the frsky gear?

João

[jhsa]

Not really a discussion. It was more like a "Just saying/idea" thing..

http://www.rcgroups.com/forums/showthre ... 8&page=852

João

[MikeB]

I'd like to see it done smart so that PPM based modules still worked properly (like the DSM hack).

The DSM hack is NOT PPM, it is asynchronous serial data at 125K baud.

Mike.

[WZ9V]

I know that, but it also does not negate the use of PPM for compatibility with other modules that are not. Which is the feature of that design I was pointing out as wanting to keep.

It would be nice to keep the PPM interface for existing modules and have a way for designing better integrated modules in the future, the DSM hack module being an example.

I'd like to see it done smart so that PPM based modules still worked properly (like the DSM hack).

The DSM hack is NOT PPM, it is asynchronous serial data at 125K baud.

Mike.

[Philipp]

SPI is not available in the module bay due to the limited amount of signal pins and the hardware limitations, in case of the Taranis the inverter on pin 5 for example. But as Mike already said, the DSM protocol already uses a serial protocol on pin 2 (-> TX) and S.PORT is basically an inverted serial stream of data on pin 5 (-> RX). This means the hardware (Taranis, 9XR, ..) does already support bidirectional serial communication of some kind on pins 2 and 5 of the module bay. Using an 3.3V FTDI breakout and an inverter for pin 2 should be sufficient to receive DSM data on a PC and to send 'fake' S.PORT telemetry to the radio, right? If this is true one could write some scripts on the pc to simulate such openTX protocol enabled module, alternatively one could use a simple arduino or STM eval kit as a mockup module to test communication between the radio and the module.

For the protocol i would suggest to split it in parts:

1. The actual channel data either from radio to module, or in case of a trainer application from module to radio. The maximum number of channels would be determined by the available bitrate and the desired refresh rate. 6 to 16 channels should be plenty for any application.
2. Some sort of initialization routine which makes the radio and module familiar with each other. This should include atleast the protocol revision running on each of them, but could as well include the name of the module, hardware revision, supported RF protocols, etc. Binding could be done with this too.
3. Configuration data. This would be nice to configure the operation of the module to a certain degree on the field or even in relation to the selected module memory. Useful for multi RF modules for example.

This list probably is incomplete and might be naive to some point, but as João said

more like a "Just saying/idea" thing..

Further down the line would be some sort of configuration dialog in openTX, maybe a seperate JR Module Setup page which could be used to configure the module, maybe even to update its firmware from the SD card of the Taranis. I know I am going far with this one, but hey, if somebody feels in the mood to modify an arduino or STM bootloader to accept firmware updates over this simple serial link, this would be even more awesome.

[MikeB]

The SPort signal is also bi-directional, and I have implemented the FrSky SPort firmware update protocol on it to allow the firmware update of SPort modules, receivers and sensors.

Mike.

[Philipp]

Ah sure, I remember someone writing about bi-directional S.PORT telemetry in context to multirotor configuration I believe.
I guess you implemented the update protocol in er9x? I did not stumble upon it in openTX
Great to know that you already did a lot of what is discussed in this thread in some similar form!

[MikeB]

Yes the SPort firmware update is in ersky9x, and I have passed the code over to openTx. I have also built a version of openTx r2940 that includes this to make sure it works and have the code "openTx ready".

Mike.

[Spainman]

I think that defining and implementing an extensible, flexible and manufacturer independent protocol would most likely boost innovation and help finally bringing open-source into the rf-link and getting rid of the channel count based and unidirectional thinking. But maybe we are in a chicken-egg problem here - as long as there is no application for it (= plans for modules) OpenTx will probably not implement such a protocol.

Personally I already would have a very very simple application to do first tests with - I would love to implement a dual (or even triple) spektrum 'hack' module for use with micro aircraft and multiple micro 6-ch-receivers. Could do that reading ppm but it would feel simply plain _wrong_ and the latency would be horrendous.

Question independent of the actual protocol topic and regarding 'hack' dsm modules: Does the taranis module plug have more than only one tx-data pin available? So would it be possible to communicate with more than one serial 'hack' module from a hardware stand point?

[jhsa]

I would love a open source RF module.. The big question is, would it ever get certified so we are covered by our insurance in case of an accident?

João

[Philipp]

good question! But how would you explain to your insurance that your plane with an certified receiver controlled by an certified RF module or even a certified Radio came down and hit somebody / something because of a bug in the (awesome!!) opensource firmware you flashed on it or because of a bad solder joint that somehow passed your visual inspection? I know we have to obey to alot of rules and laws, but is there any difference between your plane coming down because of an (certified!?) underrated of-the-shelve BEC that you installed or because of a buggy RF module that you built and installed?

This is an important topic but might be offtopic in this thread. Are the Taranis and 9XR certified the right way / at all? What kind of certification is required by law, does your insurance depend on additional certificates? There might not be a general answer to this because of local differences, but I'd like to know anyway.

[Kilrah]

The only required certification is about RF emissions, not about maintaining control of your own model.
As the Taranis' module is independent and closed source, it can be certified without issues. An open source module where anyone can change the RF behavior and not comply to requirements in terms of power, timing, hopping etc anymore and thus risk causing problems to others it certainly wouldn't pass.

[jhsa]

AS far as I know the RF module needs to be certified and I think that is the reason the pro doesn't ship with a module.. But I heard that some customs here in Germany might have started to stop all kind of electronics coming from China. Arduino boards included.. will see. I have some stuff coming from dealXtreme that still didn't arrive. And it's already late..

João

[Philipp]

The only required certification is about RF emissions, not about maintaining control of your own model.

This is the level of certification that is required by law, right? Do you know of anything special an insurance might ask for?

[...] thus risk causing problems to others it certainly wouldn't pass.

This makes sense and sounds very reasonable, thanks for explaining!

[Spainman]

It might be beneficial to the discussion to focus on the technical challenge which was talking a bidirectional, generic serial protocol over the module plug instead of unidirectional old nasty limited ppm.
Is there a chance that such a thing would be implemented in OpenTx just to open up possibilities? I don't know the software design - it might be very involved to add such a protocol or easy. I assume that there are already abstraction layers present between the calculated channel outputs and the available protocols (dsm variants, ppm, pxx, ?), right?

[Kilrah]

Integrating a new protocol in OpenTX isn't a huge deal, but what is is designing it so it really is useful i.e. does offer more than the existing ones and taking potential future applications into account to make it sufficiently attractive for people to consider adopting it.
But yes it's something I'd like to see too one day, I actually should still have a draft I started somewhere.

But its a chicken and egg problem - Yes probably if OpenTX developed and implemented such a protocol then it might tempt people to use it, but on the other hand we've already got so much on our plate with requests that we have other stuff to do than something that "nobody asked for". So unless someone shows a serious intent of making a module and wants to use it "right now" it will stay somewhere on the pile of TODO things for some more time.

There was a discussion with a module maker some time ago, but it didn't work out, they instead implemented the FrSky PXX protocol in their module as it did enough for them. That's the problem - there are already quite a few protocols around that are good enough not to need more right now.