What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

SL30 Serial output on Glideslope

AllThumbs

AllThumbs

Well Known Member
Friend
This is "technically" a nav question but, with no NAV forum I'll take a chance with COM. Moderator(s): free to move the thread if appropriate.

I'm looking for some examples of the Serial/9600/SL30 data output when its receiving a valid LOC/GS signal. I have the PMRRV NMEA spec from the install manual but am unsure of what sentences are actually sent, and how often.

If anyone has captured this data into a text file and has it lying around I'd appreciate it. I'm working on a home-brew converter to take ARINC LPV approach output from a Garmin waas unit and spit it into a Dynon D180.

Yes, I know the HS34 is a great box for a great price - I just wanted to try rolling my own. I have an Atmel based converter mostly working (GPS NMEA info drives the Dynon just fine) but the only way to auto-scale on the vertical is through SL30 emulation. Hence the plea for data.

Thanks!

Neil
 
Neil,

This is not what you asked for but it will help you since it is the info you need....

2py2cuq.jpg
 
Thanks!

I'm pretty sure the missing piece is the Nav Receiver status since the others are often invalid for a LOC or only sent at startup, which the Dynon might miss if it's not on yet.

I've got 2 Franken-Verter boards made - they are Arduino-Mega shields - and have parts to build up 4 more. Just in case you've always wanted to play with ARINC. I'm using the DEI-1016B and an RS232 driver. Pretty simple but fun to make my own board.

PM me if you want one, Brantel.

Thanks,

Neil
 
Neil,

Cool project. I thought about doing this at one point myself. I kinda stalled on it since there are some things with a LPV approach that don't really fit in the SL30 protocol.

I was really interested in possibly doing an analog to SL30 converter so that people could use older analog Nav radio's with anything that understands the SL30 protocol.

I know that that was the original intent for the analog interfaces on the HS34 but Dynon pretty much dropped support of that out of the gate since there was some issues with with getting the HS34 hardware to work with the radio's that people were trying it with. Something about King's way of doing things did not match the standard or something like that.
 
LPV vs Nav: Yup - you're right - not so simple. The way I'm tackling the issues are to use NMEA emulation (aka GPSMAP) for enroute and terminal mode and just leaving the D180 in 1 nm resolution. Then, when the ARINC starts to send valid vertical guidance, I send SL30 sentences and do the deflection calculations in the converter. ARINC sends LOC and GS deviation resolution updates frequently and I re-calculate as those change and/or new data streams in. Hopefully my TO-waypoint ID will show up on the green HSI to confirm I'm not heading to LIMBO.

I have the GPSMAP emulation working fine but the SL30 emu was missing something in the secret sauce. I've just re-coded to support ALL the defaults at the right rates (10hz or 1hz) and hope to go down to the RV-6 lab bench tomorrow to see if it works. The Dynon needs the EDC-10A plugged in so I have to do this test out in the cold of the ramp.

The Arduino Mega I'm piggy-backing on has MANY PWM and A/D inputs. It might be possible with enough isolation hardware to massage and invert levels as needed to support legacy nav radios. Probably not worth the trouble given there may be 400hz signals involved.

My goal was to make a "no dials" (HS34) box that would interface the 400W to the Dynon. I got a deal on a 400W and a mid-cont 2" OBS head and the project was born. The OBS head will be installed since the code is sure to explode occasionally.

PM me your email and I'll send you some pix of the tangled mess.
 
Cool fun project. I love playing with the Arduino hardware.

Something that may challenge you is that it can take some time for the Dynon to auto detect a change from GPSMAP to the SL30 protocol. A buddy of mine has a switch on his Dynon's serial line to pick between a GX60 gps and a SL30. When he flips it, sometimes it takes a while for the Dynon to detect the change.
 
Problem Solved

It was the checksum calculation. I was including the 'PMRRV' part of the sentence as you do with NMEA checksums. After RTFM'ing about 100 times it dawned on me what was happening.

Thanks to MGL's Rainier for some data that brought me to my senses!

The FrankenVerter now takes ARINC 429 from a 400W and EFIS telemetry from the Dynon 1x0 and converts them into NMEA (for enroute/terminal) and SL30 (for vertical guidance) formats. It also reformats the EFIS info into Shadin FADC and sends it to the 400W for heading and basic air-data.

I'm now working on psyching out what the Dynon is waiting for before it accepts and displays the HSI when I change from NMEA to SL30 formatting.

If Dynon support is reading this - you can put me out of my misery - I have no plans to market this thing other than as an ARINC and aviation formats playground and sniffer tool. I'll only fly with it because I have a mid-continent OBS head to cross check with.

For the record: if you really want to use an IFR gps with a dynon get an HS34. Its very well made and a bargain - like all of Dynon's products.

Neil
 
The Turbo Encabulator! I always wanted one of those. I built the FrankenVerter instead.

Here's my version of stupid Dynon tricks:

http://www.youtube.com/watch?v=Cvz845OpDRI&feature=youtube_gdata_player

The blank HSI n the first 10 seconds is my data changing from NMEA 0183 to SL30 emulation. The Dynon takes 10 seconds to give up on the NMEA data and 10 seconds to accept the SL30 stream. This appears to be data-rate invariant, unfortunately.

Dynon Support? Is this a fixed timeout in the code or is the parser waiting for some specific info before it will display the SL30 HSI? I'd love to get the change-over to happen quicker.

In lieu of that I may have to re-route the plebny wires and insulate them using extravengical material in a folic suspension of tri-ethyl-manganate. This may expose the whole project to the possibility of di-hydrogen-oxide damage. That would be bad. :)

Thanks,
Neil
 
We don't normally poke our heads in the COM area, so sorry for the delayed response.

There is a fixed timeout inside the system. The SL-30 and NEMA parsers are independent, and the one you are using first needs to time out and die before we'll switch to the other one and try it to see if the data meets the requirements of that parser. There's nothing you can do externally to speed this up.
 
Timeout

Thanks, Dynon tech. I figured as much. Due to the long timeout I re-coded to just piggy-back on the PGRMH vnav feature of NMEA and will add some LED annunciators to identify enroute, terminal, and approach modes.

Here's a pic of the GPS 400W on its test page with the Dynon receiving the converted data:

 
You must log in or register to reply here.
Back
Top