Task #306

Feature #161: Support the FrSky Sensor Hub Protocol

create channels for sensor hub data

Added by Hans Cappelle over 6 years ago. Updated about 6 years ago.

Status:ClosedStart date:02/10/2012
Priority:HighDue date:02/10/2012
Assignee:Hans Cappelle% Done:

100%

Category:FrSky HubSpent time:-
Target version:3.0 FrSky hub and sensors

Description

Channels required for passing sensor hub data to GUI. Some sensors need specific parsing of frame. For example voltage sensor where first byte is nr of cell while next 3 bytes represent the voltage. For these multi value types we'll have to create some composite channel.

ChannelView.png (4.29 KB) Hans Cappelle, 05/07/2012 11:06 am

UserDataTranslator.png (4.14 KB) Hans Cappelle, 05/07/2012 11:06 am


Related issues

Follows Task #344: translate 16 bit hub values to human readable format Closed 02/09/2012
Precedes Feature #396: Implement preferences panel for sensor and hub related se... Closed 04/19/2012

Associated revisions

Revision 338
Added by Espen Solbu over 6 years ago

refs #306 Added a few channels to the hub to test the concept. I am unable to get playback working, so can't properly test it.
Try to use Hub: rpm as source channel for a channel, and see if it works.

Revision 463
Added by Hans Cappelle about 6 years ago

closes #306 and closes #446 using proper Channel Interface update mechanism instead of broadcasts

History

#1 Updated by Espen Solbu over 6 years ago

Question: (eso) can this frame parsing happen outside the channel? So that we can still use a setRaw on the Channel?

Comment: (eso)
Feel free to refactor Channel class into multiple subclasses of a Channel class if needed.
I would like to still be able to use the Hub "sourceChannels" as source for other custom channels--

#2 Updated by Espen Solbu over 6 years ago

  • Target version set to 3.0 FrSky hub and sensors
  • Parent task set to #161

#3 Updated by Hans Cappelle over 6 years ago

  • Assignee set to Hans Cappelle
  • % Done changed from 0 to 30

Translation of the 16 bit values to human readable numbers has to be completed first.

new pacakage for hub related code created.

#4 Updated by Hans Cappelle over 6 years ago

  • Category set to FrSky Hub
  • % Done changed from 30 to 60

I added some more channels now.

For non c14n values like GPS and Lipo Sensor I created separate channels. Maybe strange to have them separated that way. Should we look into some kind of combined (concatenated or whatever) channels? For instance GPS position is now 2 separate channels for longitude, and one for latitude. The end user probably can't do much with one of these values. Maybe this is more related to the specialized views to be created in the future where lat & lon would translation in a map view...

#5 Updated by Espen Solbu over 6 years ago

Comments:
1. The individual channels should be configured individually, not in general method, (or at least add precision to the method)
2. My intention is that the values that are split into "before ." and "after ." must be properly converted/concatenated to double before they are passed to their respective channel setRaw (there is a comment regarding this in "altitude_before" handler), for the testing purposes i made a quick'n'dirty fix to this (i basically did setRaw(before+after/100)) (don't know what revision that code is in). A better fix for this need to be in place as we don't know what "after ." belongs to what "before .". The "before ." and "after ." shall not go into separate channels.
3. Channel ID's should add to some HUB id, so that we can be sure they are unique if we add another hub etc (the id's are also used for the broadcast messages)

#6 Updated by Espen Solbu over 6 years ago

Ignore 3. above

#7 Updated by Hans Cappelle over 6 years ago

Espen Solbu wrote:

Comments:
1. The individual channels should be configured individually, not in general method, (or at least add precision to the method)

I agree, I've been too fast by trying to write as less code as possible :). I'll adapt this to have the integers (temp, rpm, ...) reported with precision 0.

2. My intention is that the values that are split into "before ." and "after ." must be properly converted/concatenated to double before they are passed to their respective channel setRaw (there is a comment regarding this in "altitude_before" handler), for the testing purposes i made a quick'n'dirty fix to this (i basically did setRaw(before+after/100)) (don't know what revision that code is in). A better fix for this need to be in place as we don't know what "after ." belongs to what "before .". The "before ." and "after ." shall not go into separate channels.

Also agree on this. These values should be concatenated somewhere. It's currently in an intermediate state. The Sensor specific Translator (check references from interface for overview) collects the values (before and after) and always returns a double value having both latest values. So they are combined already. Allthough I don't know how to combine the correct 2 halves. The race effect you're talking about. I just combine the 2 as they come in. Maybe if after is always second value we could collect first, wait for after and then broadcast. But for this to work we need to be able to test if this order is respected and what order is used.

Also the communication with the broadcasts isn't combined yet. If a frame is found having either the before or the after value it's still handled separately so also broadcasted twice. Allthoug each broadcast contains the 2 latest values. That is what I ment by intermediate solution.

For time and date from gps the combined value is ms presentation for time (since X). So it can be converted again in the GUI. I didn't create Channels for it yet since these channels would need a very specific presentation (creating data instance with time in ms and then format time). The same issue was found with some other combined values like the lipo cells. I now had to create a channel per cell in order to be able to broadcast the channel with just a raw double value.

In the end I believe this should be fixed by letting all channels have some view as well. Then we provide a set of available views like Data (with format in options), gps location, ... This could hold the graph views also. Then set this on channel en in creating listview for configured channels reference that specific view in the adapter. That is available in Android so no issue there. Just need to implement it.

See attached UML

#8 Updated by Hans Cappelle over 6 years ago

#9 Updated by Espen Solbu over 6 years ago

Also agree on this. These values should be concatenated somewhere. It's currently in an intermediate state. The Sensor specific Translator (check references from interface for overview) collects the values (before and after) and always returns a double value having both latest values. So they are combined already. Allthough I don't know how to combine the correct 2 halves. The race effect you're talking about. I just combine the 2 as they come in. Maybe if after is always second value we could collect first, wait for after and then broadcast. But for this to work we need to be able to test if this order is respected and what order is used.

I would assume that the "before" and "after" would always come in the same frame. I would also believe that the order is fixed, probably before, then after. easiest/fastest way is probably to make the correct double and update the channel whenever you receive an "after" part.

Also the communication with the broadcasts isn't combined yet. If a frame is found having either the before or the after value it's still handled separately so also broadcasted twice. Allthoug each broadcast contains the 2 latest values. That is what I ment by intermediate solution.

You mean the broadcast from Server to the hub?
In general, i want the server to have no knowledge of the hub protocol, so i would prefer the entire chunk of userdata sent as a single broadcast to the hub. I have not looked at how this is currently implemented.
After the hub receives the userdata, it should extract the individual values, and update the corresponding channels (Channel class).
They way i see it, the hub is responsible for decoding the byte stream, and properly configuring its own fixed channels.

For time and date from gps the combined value is ms presentation for time (since X). So it can be converted again in the GUI. I didn't create Channels for it yet since these channels would need a very specific presentation (creating data instance with time in ms and then format time). The same issue was found with some other combined values like the lipo cells. I now had to create a channel per cell in order to be able to broadcast the channel with just a raw double value.

"Complex" or advanced channels, need to have their own class. We need to refactor Channel class, so it is generic (or even abstract), then we can extend/override that for custom/specific channels.
The Channel class should have a view/activity for configuration that can also be extended/overriten. (e.g. for RPM, User should not be asked about an offset, and factor should be replaced by number of blades)

These advanced/complex channels need to wait until after 2.5 for proper implementation i think.

In the end I believe this should be fixed by letting all channels have some view as well. Then we provide a set of available views like Data (with format in options), gps location, ... This could hold the graph views also. Then set this on channel en in creating listview for configured channels reference that specific view in the adapter. That is available in Android so no issue there. Just need to implement it.

I don't fully understand this, but i think it is along these lines i think. However i think we need to properly refactor our Channel concept first

#10 Updated by Hans Cappelle about 6 years ago

  • Status changed from New to Closed
  • % Done changed from 60 to 100

Applied in changeset r463.

Also available in: Atom PDF