SV-Net Protocol and Data Rate

[Taildragger]

is the SV-Net protocol closed or some open standard? I assumed it was RS-232 but doesnt appear to be. Also, what are the data rates?

 

[Rhino]

It's non-standard wiring. Not sure of the rate.

 

[Dynon]

It's RS-485 based, not sure of the bitrate off the top of my head. Because it's complex, connects critical modules, and changes over time, the SkyView Network format/protocol is not published.

 

[vlittle]

Dynon publishes it's serial RS-232 protocol in the Installation Guide. It is comprehensive and very useful. It also can send this information over WiFi, which allows many other devices to connect.

Better yet, I managed to get Dynon and Garmin to (mostly) agree on the serial specifications when I was the editor of the specs. There has been a divergence over the years, but easy to handle. I have written decoding routines for D10/D100x, SkyView, G3X and OnSpeed.

I also have developed a test set that produces RS232 serial streams in the SkyView and G3X formats, plus the WiFi UDP stream from SkyView.

 

[hedley]

Dynon publishes it's serial RS-232 protocol in the Installation Guide. It is comprehensive and very useful. It also can send this information over WiFi, which allows many other devices to connect.

Better yet, I managed to get Dynon and Garmin to (mostly) agree on the serial specifications when I was the editor of the specs. There has been a divergence over the years, but easy to handle. I have written decoding routines for D10/D100x, SkyView, G3X and OnSpeed.

I also have developed a test set that produces RS232 serial streams in the SkyView and G3X formats, plus the WiFi UDP stream from SkyView.

Is there any chance of sharing what you have of the protocol ? . If so please send to my email ( hedley.davidson@gmail.com) . My end point would be to capture the rs485 ? dataflow packets, and then build two ' sv servo ' emulators with a small microcontroller that would drive a little stepper motor. Im sure they will have a checksum or arc to validate packets so this may take some time. This would allow pilots to practise using the autopilot , and see the results ( little motors turning on their desk , with a Button to initiate sending ' overload messages back to the SV unit ) ) . The sv unit is driven by and connected to X-Plane but as it does not detect the servos the functionality is disabled. In the reverse direction I would share what I come up with. One the Rand $ rate improves ( if ever ) I hope to order 2 * servo units to install in my Falcomposite Furio that I am building .

 

[swatson999]

Appendix E of the Installation Guide, as vlittle just told you.

 

[Marc_J._Zeitlin]

Umm

Appendix E of the Installation Guide, as vlittle just told you.

Ummm, Appendix E is "Serial Data Output". The serial line outputs information only - nothing goes in. It doesn't "communicate" with any of the other devices on the Dynon bus, which is what was being asked.

If @hedley wants to make believe he's a servo and communicate with the EFIS over the SV bus, Appendix E has exactly zero information on how to do that, and @Dynon explicitly said in post #3 that the network protocols are not published, so unless you want to sniff the bus and reverse engineer it (which an acquaintance has done for a project that never went anywhere), you're SOL.

 

[hedley]

Guess will just have to hook up a protocol analyser with an rs485 interface , then implement functions on the Skyview , and then capture bi directional packets related to each function and document the protocol which would then allow the edge device to emulate a mini servo. . At least when finished I can use as a training aid for the Sky-view, without having to drop Us$ 1700 , on 2 servos - plan is to use small microcontroller driving RC servos . The forcing function is to have a lot of sim time on the sky view , especially in depth understanding of autopilot control sequencing for normal and expert mode . One does not want to experience ' startle effect ' , when something unexpected happens especially as a 67 year old pilot.

 

[vlittle]

I have spent well over $250,000 developing avionics devices that work with Dynon’s EFIS systems, not including the aircraft I built as 'test mules' for flight testing And the hangars to contain them. Much of my work has been published as open source, but there are certain things that I keep as proprietary— because I don't want people depending on the stuff for flight safety.

For example, I designed an autotrim/autopilot controller a decade ago that predates Dynon‘s version, and I am still flying behind it. It also performs flaps control and has presets for take-off and landing. It will never be publically released because of liability issues. My new build will use it as well.

In conclusion, if you want to play, you have to pay!

 

[swatson999]

Umm

Ummm, Appendix E is "Serial Data Output". The serial line outputs information only - nothing goes in. It doesn't "communicate" with any of the other devices on the Dynon bus, which is what was being asked.

If @hedley wants to make believe he's a servo and communicate with the EFIS over the SV bus, Appendix E has exactly zero information on how to do that, and @Dynon explicitly said in post #3 that the network protocols are not published, so unless you want to sniff the bus and reverse engineer it (which an acquaintance has done for a project that never went anywhere), you're SOL.

To quote:

Dynon publishes it's serial RS-232 protocol in the Installation Guide. It is comprehensive and very useful. It also can send this information over WiFi, which allows many other devices to connect.

Is there any chance of sharing what you have of the protocol ? .

 

[Rhino]

Appendix E is only an informational data dump you configure the system to output on an unused serial port. It is not communication between devices or control signals, which is what hedley wants to emulate. He'll have to capture the data he wants with a protocol analyzer and interpret it to produce the results he's looking for.

 

[bbaggerman]

It's RS-485 based, not sure of the bitrate off the top of my head. Because it's complex, connects critical modules, and changes over time, the SkyView Network format/protocol is not published.

The data rate is 1 megabits per second (looked at it on a scope) but other than that it was hard to tell what was going on. Since SkyView Network is so critical to the operation of the system it doesn't surprise me that Dynon would not publish the details. I'd love to build some boxes that could hang on the SkyVIew network but fully understand Dynon's position on this one. I'd probably do the same.

 

[hedley]

My servo arrived and an AP panel , so hooked it up to start the data capture and analysis process - but alas , I then established that autopilot functionality requires a minimum of 2 serves to be active on the SV1000 . If I get this working, I will ensure that I do not publish any protocols without Dynon's written approval . The goal is to just build the small training servos , for training and simulation .

 

[swatson999]

I then established that autopilot functionality requires a minimum of 2 serves to be active on the SV1000 .

Not sure that's true...?

 

[hedley]

Not sure that's true...?

Not sure that's true...?

I was not clear - for the AP-Panel to work the sky view must be set to expert mode , and this is when two servos must be connected . If not the AP-Panel will not work .

 

[hedley]

Setting the SkyView AP to EXPERT mode requires that two SkyView AP servos (Roll and Pitch) are installed. If only one servo (either Roll only, or Pitch only) is installed, the SkyView AP can only be set to SIMPLIFIED mode.