Intercepting & modifying serial data

[KRviator]

G'day folks,

A bit of a spin off from the request for a Dynon knob module is my interest in DIY'ing one myself.

To that end, I'm wondering about the viability of intecepting & modifying certain parameters contained in the Dynon network serial data stream, primarily the Baro setting and autopilot bugs and mode status.

The installation manual specifies the content of the various serial stream options, as well as the requirement for Data 1A&B and Data2A&B to be continuous throughout the network to avoid a Standby Network Error, so presumably Data1 is the primary?

The question's I have can be summarised as follows:
What streams (DYNON ADAHRS + SYS + EMS etc) are actually transmitted over the network?
Is this stream transmitted simultaneously over Data1 & Data2?
If Display "A" transmits a packet of data, that is captured and altered by a 3rd party device, would Display "B" recognise the discrepancy or would it trust the "new" data?

The general idea is as follows:
[list bull-blackball][*]Intercept each packet of serial data
[*]Compare the Baro, Autopilot Bug & Current Mode to that held by the MCP
[*]If MCP data is different, replace the values in the data stream with MCP values
[*]Export the entire "new" datastream in the relevant format
[/list]

 

[dynonsupport]

The SkyView network is a master/slave network. The master needs to know about you in order to ask you for data, and it only understands devices that are in it's database of Dynon devices. So you can't put something on our network and have the master ask for data from it nor send data to it.

The network is also deterministic and synchronous, and each item has it's own time slot, so there is no random time you can publish data and have anything understand it.

As a purely mental, engineering thought exercise: You'd have to create a man-in-the-middle attack, and put your device between the master and the rest of the network and intercept all the data coming in and out in order to figure out when to inject your data. This has a few challenges:

1) You need to have multiple screens in the plane, since baro and such is not on the network if there isn't another screen to share it with

2) Mastership is arbitrary when you have more than one screen, you would need to figure out which direction of the datastream to mess with in real time since it can change on you at any time

3) The data changes with software releases

4) Timing matters, you can't delay the signal much or the whole network halts

5) You have to deal with both of the redundant data streams or it will act very odd

6) There is no cryptography, but there are things like CRC's, so you would need to re-calculate these based on changes you make to the datastream

7) There is a huge amount of data on the network. Remember, every AHRS, EMS, Servo, ARINC module and Screen lives on this network, so all the data they are transmitting or receiving is on the network. Just finding the BARO datablock in this would be a challenge

What you have is probably a technically possible challenge, but one I would expect would take a smart engineer a huge amount of time to solve. The whole point of the Dynon network is a stable, Dynon controlled network that doesn't have arbitrary devices on it, so we never designed it to make adding a device like yours easy.

I think it would be easier to get all your fellow Dynon customers to convince us to make the device ourselves

 

[keye]

What would the purpose of this device be? To allow remote control of a Skyview screen?

 

[dynonsupport]

He wants to put a knob on his panel to adjust things like baro or altitude bugs without using the knobs on SkyView.

 

[TRCsmith]

Something like the HS34 would be great to add to the SV.

 

[KRviator]

What would the purpose of this device be? To allow remote control of a Skyview screen?

He wants to put a knob on his panel to adjust things like baro or altitude bugs without using the knobs on SkyView.

What Dynon said...

These blokes developed something similar for their RV-7, albeit for the Advanced system. Knowing Dynon streamed the serial data, and published their protocols made me wonder - in true Top Gear fashion - "How hard can it be?".

Dynon's answer seems to indicate the answer is "very"... [smiley=laugh.gif]

 

[dynonsupport]

Developing that for the Advanced system required "flexibility of the owner of AFS to cooperate with the AFCU "pet project"" in the words of that guy who did that control panel.

Amazing project for sure, but even that required his EFIS vendor to write custom software for him, and that's not something we can make a reasonable business case for.

 

[KRviator]

Amazing project for sure, but even that required his EFIS vendor to write custom software for him, and that's not something we can make a reasonable business case for.

No wuckka's, that's an entirely understandable, and reasonable position. When/if Dynon releases an HS34-equivalent for SkyView, I'm sure there's more than afew of us that'd have them on order.

At least you guys output the serial data to make any number of stand-alone 3rd party devices useable.

 

[mmarien]

It seems like a good idea but taken to the extremes I don't have enough panel space to place a knob for every input function the SV offers. It's a bit inconvenient when I forget to switch the joystick menu back to HDG or ALT after setting BARO but for the most part SV input menus are intuitive and easy to use. BARO is also a single use function. Set it and forget it. It may be set a few times for xcountry but probably only once for a trip around the city. I don't see a lot of sense in having a dedicated knob and display when it's already easily available.

Having said that it would be nice to have a persistent favorite for the joystick. The joystick would return to the menu item selected as the persistent item after use or a few seconds of inactivity. You could count on it being the function you expect much like the joystick under the map is always the range function.

The SV discrete input lines are still unused. There is an opportunity for user inputs along with USB.

 

[jeffa]

Having said that it would be nice to have a persistent favorite for the joystick. The joystick would return to the menu item selected as the persistent item after use or a few seconds of inactivity. You could count on it being the function you expect much like the joystick under the map is always the range function.

100% agree about this. Seems like it would be a relatively easy feature to add to Version 5.X (although I have no idea how to write code/data  ). Would be nice to allow a user selectable favorite/default.

 

[swatson999]

It seems like a good idea but taken to the extremes I don't have enough panel space to place a knob for every input function the SV offers. It's a bit inconvenient when I forget to switch the joystick menu back to HDG or ALT after setting BARO but for the most part SV input menus are intuitive and easy to use. BARO is also a single use function. Set it and forget it. It may be set a few times for xcountry but probably only once for a trip around the city. I don't see a lot of sense in having a dedicated knob and display when it's already easily available.

I'll reiterate my concurrence here...I think the idea of a separate box with knobs for a single function block (autopilot) is an ugly solution, both from a panel aesthetics view AND an engineering standpoint (not to mention Human-computer interface aspects).

There's no reason it shouldn't be easily doable with the system you have now, without having to force people to cut holes in their panels for a dedicated box. If you think you can't do it, think harder until you solve it.

Separate boxes are, IMHO, a nasty approach to an antiquated view of instrument panel design.