Remote RX not functioning

[RoboTechie]

I am unable to get the Spektrum Quad Race Serial Receiver, which uses the RemoteRX protocol, to work with the Flight Controller (RevB1/2.0.1)

I know that the Transmitter and Receiver are bound correctly (as indicated by solid orange light on Rx), but I don't get any useful response on GroundStation (receiver type set to RemoteRX, though I did try all the other options too). I initially had some response to stick movement, but directions and channels and ranges were all messed up. After I hit "reset" all of the values jumped a bit farther away from reason, and no longer respond to any change in TX input.

Here's what it looks like on GroundStation:

And a useful resource: Specification for Spektrum Remote Receiver Interfacing by Spektrum

[JasonDorie]

Try this:

Open your Elev8-FC firmware in SimpleIDE. Open the remote_rx_driver.spin file, and find the ConvertToChannels label. You'll see this:

ConvertToChannels

       mov     inWord, inputWords
       and     inWord, #$ff
       cmp     inWord, #$12    wz                              '11ms

2048 DSM2 master if_e jmp #:DoConvert

Try removing the "if_e" - just that part.

This bit of code checks to make sure that the receiver has a valid ID in the system field. Removing that "if_e" will make the check "succeed" all the time. If the packet format is the same and the ID is new, this will work.

J

On Thu, Oct 6, 2016 at 4:19 PM, Kyle M notifications@github.com wrote:

I am unable to get the Spektrum Quad Race Serial Receiver http://www.spektrumrc.com/Products/Default.aspx?ProdID=SPM4648, which uses the RemoteRX protocol, to work with the Flight Controller (RevB1/2.0.1)

I know that the Transmitter and Receiver are bound correctly (as indicated by solid orange light on Rx), but I don't get any useful response on GroundStation (receiver type set to RemoteRX, though I did try all the other options too). I initially had some response to stick movement, but directions and channels and ranges were all messed up. After I hit "reset" all of the values jumped a bit farther away from reason, and no longer respond to any change in TX input.

Here's what it looks like on GroundStation: [image: image] https://cloud.githubusercontent.com/assets/13735732/19173863/6dd5988a-8bdf-11e6-8ada-bcebe148cba6.png

And a useful resource: Specification for Spektrum Remote Receiver Interfacing http://www.spektrumrc.com/ProdInfo/Files/Remote%20Receiver%20Interfacing%20Rev%20A.pdf by Spektrum

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/Flight-Controller/issues/48, or mute the thread https://github.com/notifications/unsubscribe-auth/ANak_gxpoBXPTiFL6ZaKcHVwg-nijRu7ks5qxYHrgaJpZM4KQhHm .

[RoboTechie]

Thanks! I removed "if_e" and now the values are closer to range and do change as I manipulate the TX inputs, but in a completely nonsense manner (like I'll move throttle, and every other channel also changes, some skipping around, some smoothly, etc). Every time I move the TX sticks, then return them to their original position, the readout on GS is completely different. Here's what it looks like now (I ran calibration, but it didn't make much of a difference:

[JasonDorie]

It's possible that it was bound in DSM2-22 mode (IE 10 bit data instead of 11 bit). What transmitter are you using, and how are you binding it?

On Thu, Oct 6, 2016 at 4:39 PM, Kyle M notifications@github.com wrote:

Thanks! I removed "if_e" and now the values are mostly in range and do change as I manipulate the TX inputs, but in a completely nonsense manner (like I'll move throttle, and every other channel also changes, some skipping around, some smoothly, etc). Every time I move the TX sticks, then return them to their original position, the readout on GS is completely different. Here's what it looks like now (I ran calibration, but it didn't make much of a difference: [image: image] https://cloud.githubusercontent.com/assets/13735732/19174412/6b219bbc-8be3-11e6-9ba1-03a12caf45f2.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/Flight-Controller/issues/48#issuecomment-252118033, or mute the thread https://github.com/notifications/unsubscribe-auth/ANak_moCBjdWH-9fImlUCjN7HsIBTirQks5qxYasgaJpZM4KQhHm .

[RoboTechie]

I'm using a Spektrum DX7 transmitter. I check on the "frame rate" screen of the transmitter, and it was using DSMX modulation at 22ms. I noticed the receiver docs say it's supposed to be 11ms, so I changed the transmitter settings to DSMX @ 11ms. I re-calibrated groundstation, and everything worked (responded correctly) except for channel 7, which didn't respond at all (it should have, since the TX is 7 channel and RX is up to 20). So I tried re-calibrating, and all hell broke loose again - channels are mixing, values randomly changing, etc. I tried restating the TX, FC, and GS, re-setting the GS Radio setup, double-checked that the TX was still in DSMX@11ms, and tried re-binding, but none resolved the problem.

Then I tried re-setting the GS radio setup again, and it "randomly" started working, except that AUX 2 is still out of range. I performed calibration, and channels 1-6 calibrated correctly, but ch7 was still not working. So I pressed "reset" on the radio setup tab again, which cleared the radio calibration, which worked as expected (no longer calibrated, but values still respond as expected). I rebooted Gs and the FC, and the problem re-appeared (nonsense values, channel mixing, etc).

So sometimes it works, sometimes it doesn't, but I'm having trouble picking up any sort of pattern.

[JasonDorie]

Calibrating doesn't change how the data is received - it just changes how it's scaled / mapped after it's received. It can move a channel, but nothing in the calibration could "mix" one channel into another, so that's all happening in the receiver code.

Whether it's 22ms or 11ms doesn't affect me - that's all in the physical receiver. Everything but the DSM2-22 mode sends data to the host in the same format.

My guess is that the baud rate setting is wrong. I have it set to 115,200 because that's what most closely synced with the receiver I have, but the spec says 125,000.

Try this:

• Open sbus.cpp in the Flight-Controller project
• Around line 52, change the 115200 to 125000
• Compile and flash your flight controller

Their spec says that you can use 115200 safely, but I'm not sure that's true - standard serial only tolerates a timing error of 5%, and the difference between 125k and 115k is 8%. We could split the difference and make the flight controller's base timing 120k - That would be ~4% error in both directions, which is within spec for serial comms.

If 125000 works for you, try again at 120000. Let me know if either of those work for you.

J

On Friday, October 7, 2016, Kyle M notifications@github.com wrote:

I'm using a Spektrum DX7 transmitter. I check on the "frame rate" screen of the transmitter, and it was using DSMX modulation at 22ms. I noticed the receiver docs say it's supposed to be 11ms, so I changed the transmitter settings to DSMX @ 11ms. I re-calibrated groundstation, and everything worked (responded correctly) except for channel 7, which didn't respond at all (it should have, since the TX is 7 channel and RX is up to 20). So I tried re-calibrating, and all hell broke loose again - channels are mixing, values randomly changing, etc. I tried restating the TX, FC, and GS, re-setting the GS Radio setup, double-checked that the TX was still in DSMX@11ms, and tried re-binding, but none resolved the problem.

Then I tried re-setting the GS radio setup again, and it "randomly" started working, except that AUX 2 is still out of range. I performed calibration, and channels 1-6 calibrated correctly, but ch7 was still not working. So I pressed "reset" on the radio setup tab again, which cleared the radio calibration, which worked as expected (no longer calibrated, but values still respond as expected). I rebooted Gs and the FC, and the problem re-appeared (nonsense values, channel mixing, etc).

So sometimes it works, sometimes it doesn't, but I'm having trouble picking up any sort of pattern.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/Flight-Controller/issues/48#issuecomment-252316374, or mute the thread https://github.com/notifications/unsubscribe-auth/ANak_kwzGSLV-YUhdVQgJoVtFlrP6zS4ks5qxoV8gaJpZM4KQhHm .

[RoboTechie]

I set the baud rate to 12500, but unfortunately that didn't resolve the issue. Then I used an oscilloscope to measure the baudrate from the receiver, and it is 114943, so would think a rate of 115200 should work. Interestingly, the RX is operating at 22ms, not 11ms as the receiver documentation implies.

I also tried the RemoteRX output on the Spektrum AR7700 High-Speed Serial Receiver, and it did not work either (but the PPM output does still work). I measure all three outputs of the AR7700 receiver at 22ms, even though the manual says the SRXL and RemoteRX output at 11ms, so I'm not really sure what's up with that (though it sounds like that shouldn't be impacting the GS receiver values). I might try to call spektrum at least about the 11ms question.

[JasonDorie]

Does your scope have capture with protocol decoding? I have a Saleae logic analyzer that I use and it does it. If you can see what the decoded bytes are that might help point to the issue.

If you're getting data at 114950 that's easily within the timing spec, so it has to be something in the protocol that's not being accounted for.

On Fri, Oct 7, 2016 at 12:45 PM, Kyle M notifications@github.com wrote:

I set the baud rate to 12500, but unfortunately that didn't resolve the issue. Then I used an oscilloscope to measure the baudrate from the receiver, and it is 114943, so would think a rate of 115200 should work. Interestingly, the RX is operating at 22ms, not 11ms as the receiver documentation implies.

I also tried the RemoteRX output on the Spektrum AR7700 High-Speed Serial Receiver, and it did not work either (but the PPM output does still work). I measure all three outputs of the AR7700 receiver at 22ms, even though the manual says the SRXL and RemoteRX output at 11ms, so I'm not really sure what's up with that (though it sounds like that shouldn't be impacting the GS receiver values). I might try to call spektrum at least about the 11ms question.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/Flight-Controller/issues/48#issuecomment-252344244, or mute the thread https://github.com/notifications/unsubscribe-auth/ANak_qh_Lz9vWvXZDKqCRroccokArs4Eks5qxqFegaJpZM4KQhHm .

[JasonDorie]

How are you feeding that RX the 3.3v it needs? I just tested with my JR9303, DSM2, with the Spektrum AR7700, and the RemoteRX out of that works as expected.

On Fri, Oct 7, 2016 at 12:51 PM, Jason Dorie jason.dorie@gmail.com wrote:

Does your scope have capture with protocol decoding? I have a Saleae logic analyzer that I use and it does it. If you can see what the decoded bytes are that might help point to the issue.

If you're getting data at 114950 that's easily within the timing spec, so it has to be something in the protocol that's not being accounted for.

On Fri, Oct 7, 2016 at 12:45 PM, Kyle M notifications@github.com wrote:

I set the baud rate to 12500, but unfortunately that didn't resolve the issue. Then I used an oscilloscope to measure the baudrate from the receiver, and it is 114943, so would think a rate of 115200 should work. Interestingly, the RX is operating at 22ms, not 11ms as the receiver documentation implies.

I also tried the RemoteRX output on the Spektrum AR7700 High-Speed Serial Receiver, and it did not work either (but the PPM output does still work). I measure all three outputs of the AR7700 receiver at 22ms, even though the manual says the SRXL and RemoteRX output at 11ms, so I'm not really sure what's up with that (though it sounds like that shouldn't be impacting the GS receiver values). I might try to call spektrum at least about the 11ms question.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/Flight-Controller/issues/48#issuecomment-252344244, or mute the thread https://github.com/notifications/unsubscribe-auth/ANak_qh_Lz9vWvXZDKqCRroccokArs4Eks5qxqFegaJpZM4KQhHm .

[JasonDorie]

Also, the receiver you mention supports SRXL protocol as well - is it possible that it's in SRXL mode? The packet format for SRXL is different.

I hooked up my logic analyzer and picked apart the packets, then modded the RemoteRX driver to handle SRXL too, and changed the base timing to 1200000 baud so it should gracefully deal with 125k or 115k.

With the AR7700 I can now hot-swap between RemoteRX and SRXL outputs and the FC keeps reading correctly. This is submitted to the ActiveDevelopment branch, so try that and see if it works for you.

On Sat, Oct 8, 2016 at 3:55 PM, Jason Dorie jason.dorie@gmail.com wrote:

How are you feeding that RX the 3.3v it needs? I just tested with my JR9303, DSM2, with the Spektrum AR7700, and the RemoteRX out of that works as expected.

On Fri, Oct 7, 2016 at 12:51 PM, Jason Dorie jason.dorie@gmail.com wrote:

Does your scope have capture with protocol decoding? I have a Saleae logic analyzer that I use and it does it. If you can see what the decoded bytes are that might help point to the issue.

If you're getting data at 114950 that's easily within the timing spec, so it has to be something in the protocol that's not being accounted for.

On Fri, Oct 7, 2016 at 12:45 PM, Kyle M notifications@github.com wrote:

I set the baud rate to 12500, but unfortunately that didn't resolve the issue. Then I used an oscilloscope to measure the baudrate from the receiver, and it is 114943, so would think a rate of 115200 should work. Interestingly, the RX is operating at 22ms, not 11ms as the receiver documentation implies.

I also tried the RemoteRX output on the Spektrum AR7700 High-Speed Serial Receiver, and it did not work either (but the PPM output does still work). I measure all three outputs of the AR7700 receiver at 22ms, even though the manual says the SRXL and RemoteRX output at 11ms, so I'm not really sure what's up with that (though it sounds like that shouldn't be impacting the GS receiver values). I might try to call spektrum at least about the 11ms question.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/Flight-Controller/issues/48#issuecomment-252344244, or mute the thread https://github.com/notifications/unsubscribe-auth/ANak_qh_Lz9vWvXZDKqCRroccokArs4Eks5qxqFegaJpZM4KQhHm .

[RoboTechie]

The scope I have in Truckee doesn't have protocol decoding..

I'm using the SRR/DSM port on RevB (I soldered in the connector, which won't come with the board), it supplies 3.3 V (I measured 3.28). I just realized that you've been making all the changes in Active Dev branch, but I've been using the Main Branch. oops

So I loaded the flight controller up with the latest code from the Active Dev. Branch, and used QT Creator to Run the new GroundStation, but the FC and GS didn't seem to be communicating properly, I was getting data from the FC, but it wasn't accurate, and I couldn't even get RGB led to respond with the LED test button.

So until we can figure out why there were FC-GS issues with v3.0, I went back to the main branch. With that code, i got the following results:

The Spektrum SPM4648 Quad Race Serial Receiver still doesn't work properly, and neither does the RemoteRX port of the AR7700. However, for the first time I tried a "standard" Spektrum Remote Receiver (SPM9645) after using a "master" receiver to bind it, and it worked! I was able to complete Radio Calibration and all channels responded as expected!

[JasonDorie]

If you're in the ActiveDev branch, you should see 3.0.0 in firmware and GroundStation version fields. Double check that, just in case you ran but didn't build, or flashed to RAM but not EEPROM. I've been working in the ActiveDev branch with no issues, so maybe try a previous rev of the FC as well.

I know the RemoteRX support works for some receivers, as I was flying one on my mini-quad for a while, but I found the range was quite lacking using just a single satellite. Using the RemoteRX or SRXL output of a 7700 would be much better for range.

On Tue, Oct 11, 2016 at 12:16 PM, Kyle M notifications@github.com wrote:

The scope I have in Truckee doesn't have protocol decoding..

I'm using the SRR/DSM port on RevB (I soldered in the connector, which won't come with the board), it supplies 3.3 V (I measured 3.28). I just realized that you've been making all the changes in Active Dev branch, but I've been using the Main Branch. oops

So I loaded the flight controller up with the latest code from the Active Dev. Branch, and used QT Creator to Run the new GroundStation, but the FC and GS didn't seem to be communicating properly, I was getting data from the FC, but it wasn't accurate, and I couldn't even get RGB led to respond with the LED test button.

So until we can figure out why there were FC-GS issues with v3.0, I went back to the main branch. With that code, i got the following results:

The Spektrum SPM4648 Quad Race Serial Receiver still doesn't work properly, and neither does the RemoteRX port of the AR7700. However, for the first time I tried a "standard" Spektrum Remote Receiver (SPM9645) after using a "master" receiver to bind it, and it worked! I was able to complete Radio Calibration and all channels responded as expected!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/Flight-Controller/issues/48#issuecomment-253016438, or mute the thread https://github.com/notifications/unsubscribe-auth/ANak_pGtWw-03R2hkkmN4YZH4eoKnWG2ks5qy-CkgaJpZM4KQhHm .

[RoboTechie]

Ok, so I loaded the v3.0 firmware and software up to a RevA3 flight controller, and I got the the AR7700 receiver PPM output to work, as well as the SRXL output to work when GS is set to RemoteRX. I couldn't get the RemoteRX output to work. I tried the RevB flight controller, and got the same results. In both cases, when the receiver type is set to RemoteRX in GS and uploaded to the FC, the values just "freeze", rather than going crazy out of range like they did with the main branch.

Just as when running firmware 2.0.1, the standard Spectrum Satellite Receivers (SPM9645) work with the RemoteRX setting, but the SPM4648 Quad Race Serial Receiver (which has much better range than the normal Satellite Receiver, but similar form factor) still doesn't work.

So there's obviously something weird going on: It seems like you have the AR7700 working correctly, while the RemoteRX port on my AR7700 still doesn't work. On the other hand, the RemoteRX receiver type setting seems to work for standard remote receivers, but not for the more advanced one.

Looking on my scope, both the SPM9645 and SPM4648 have a signal timing of 22ms, with packet length of about 1.37ms, but without a logic analyzer, there's not much more I can deduce.

[JasonDorie]

When you say "the RemoteRX port on my 7700" you mean the one right next to the SRXL output with the normal 3-pin servo connector, right? Not the little plug on the side that takes a remote receiver as input? It feels like a dumb question, but I'm trying to eliminate the obvious, since I verified this working on that receiver.

It is possible that it's the transmitting radio that's the difference here. Mine is a JRx9303, and it's transmitting data in DSM2. Maybe yours is transmitting DSMX and I'm just missing the check to make sure the header signature is valid for that specific type of input. Can you take a screenshot or a picture of the actual packet data on the screen of the scope? If you get a decent image I can probably just decode it by hand. I'd need to be able to see the first 4 bytes, so about 0.35 to 0.5 ms worth of sample time.

On Tue, Oct 11, 2016 at 2:31 PM, Kyle M notifications@github.com wrote:

Ok, so I loaded the v3.0 firmware and software up to a RevA3 flight controller, and I got the the AR7700 receiver PPM output to work, as well as the SRXL output to work when GS is set to RemoteRX. I couldn't get the RemoteRX output to work. I tried the RevB flight controller, and got the same results. In both cases, when the receiver type is set to RemoteRX in GS and uploaded to the FC, the values just "freeze", rather than going crazy out of range like they did with the main branch.

Just as when running firmware 2.0.1, the standard Spectrum Satellite Receivers (SPM9645) work with the RemoteRX setting, but the SPM4648 Quad Race Serial Receiver (which has much better range than the normal Satellite Receiver, but similar form factor) still doesn't work.

So there's obviously something weird going on: It seems like you have the AR7700 working correctly, while the RemoteRX port on my AR7700 still doesn't work. On the other hand, the RemoteRX receiver type setting seems to work for standard remote receivers, but not for the more advanced one.

Looking on my scope, both the SPM9645 and SPM4648 have a signal timing of 22ms, with packet length of about 1.37ms, but without a logic analyzer, there's not much more I can deduce.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/Flight-Controller/issues/48#issuecomment-253052932, or mute the thread https://github.com/notifications/unsubscribe-auth/ANak_jgFkQWYG7NDl0yIirz61H_B1NwDks5qzAA1gaJpZM4KQhHm .

[JasonDorie]

Worst case scenario you can send me the radio and receiver(s) to connect to my setup, I'll scope them and figure out the difference, then send them back to you.

On Tue, Oct 11, 2016 at 2:39 PM, Jason Dorie jason.dorie@gmail.com wrote:

When you say "the RemoteRX port on my 7700" you mean the one right next to the SRXL output with the normal 3-pin servo connector, right? Not the little plug on the side that takes a remote receiver as input? It feels like a dumb question, but I'm trying to eliminate the obvious, since I verified this working on that receiver.

It is possible that it's the transmitting radio that's the difference here. Mine is a JRx9303, and it's transmitting data in DSM2. Maybe yours is transmitting DSMX and I'm just missing the check to make sure the header signature is valid for that specific type of input. Can you take a screenshot or a picture of the actual packet data on the screen of the scope? If you get a decent image I can probably just decode it by hand. I'd need to be able to see the first 4 bytes, so about 0.35 to 0.5 ms worth of sample time.

On Tue, Oct 11, 2016 at 2:31 PM, Kyle M notifications@github.com wrote:

Ok, so I loaded the v3.0 firmware and software up to a RevA3 flight controller, and I got the the AR7700 receiver PPM output to work, as well as the SRXL output to work when GS is set to RemoteRX. I couldn't get the RemoteRX output to work. I tried the RevB flight controller, and got the same results. In both cases, when the receiver type is set to RemoteRX in GS and uploaded to the FC, the values just "freeze", rather than going crazy out of range like they did with the main branch.

Just as when running firmware 2.0.1, the standard Spectrum Satellite Receivers (SPM9645) work with the RemoteRX setting, but the SPM4648 Quad Race Serial Receiver (which has much better range than the normal Satellite Receiver, but similar form factor) still doesn't work.

So there's obviously something weird going on: It seems like you have the AR7700 working correctly, while the RemoteRX port on my AR7700 still doesn't work. On the other hand, the RemoteRX receiver type setting seems to work for standard remote receivers, but not for the more advanced one.

Looking on my scope, both the SPM9645 and SPM4648 have a signal timing of 22ms, with packet length of about 1.37ms, but without a logic analyzer, there's not much more I can deduce.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/Flight-Controller/issues/48#issuecomment-253052932, or mute the thread https://github.com/notifications/unsubscribe-auth/ANak_jgFkQWYG7NDl0yIirz61H_B1NwDks5qzAA1gaJpZM4KQhHm .

[RoboTechie]

Yep I, I'm using the port as you described - always good to check. My radio has been using DSMX. I tried switching to DSM2, but it still didn't seem to work.

Here's what I got with the scope:

[RoboTechie]

After I sent @JasonDorie some RX signal samples (using a wrote up a program he wrote to read the signal from the receiver and print it into the terminal), he came up with the solution!

By adding the following code to the "ConvertToChannels" function in remote_rx_driver.spin, we were able to get both the RemoteRX output of the Spektrum AR7700 and the Spekturm SPM4648 receiver working!

                   cmp     inWord, #$a2    wz                  '22ms 2048 DSMX master
         if_e      jmp     #:DoConvert

                   cmp     inWord, #$b2    wz                  '11ms 2048 DSMX master
         if_e      jmp     #:DoConvert

Once the change is implemented in the code, we can wrap this issue up! Also, @JasonDorie should we move SRXL out of RemoteRX and make it its own receiver type option, since it seems to be working and that way it's easier for customer to know it's an option?

[JasonDorie]

No, as that'll take twice as much space as having it in the RemoteRX receiver code. I'll just modify the UI in GroundStation to show SRXL / RemoteRX as an option.

On Wed, Oct 12, 2016 at 11:40 AM, Kyle M notifications@github.com wrote:

After I sent @JasonDorie https://github.com/JasonDorie some RX signal samples (using a wrote up a program he wrote to read the signal from the receiver and print it into the terminal), he came up with the solution!

By adding the following code to the "ConvertToChannels" function in remote_rx_driver.spin, we were able to get both the RemoteRX output of the Spektrum AR7700 and the Spekturm SPM4648 receiver working!

               cmp     inWord, #$a2    wz                  '22ms 2048 DSMX master
     if_e      jmp     #:DoConvert

               cmp     inWord, #$b2    wz                  '11ms 2048 DSMX master
     if_e      jmp     #:DoConvert

Once the change is implemented in the code, we can wrap this issue up! Also, @JasonDorie https://github.com/JasonDorie should we move SRXL out of RemoteRX and make it its own receiver type option, since it seems to be working and that way it's easier for customer to know it's an option?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/Flight-Controller/issues/48#issuecomment-253300775, or mute the thread https://github.com/notifications/unsubscribe-auth/ANak_n2apAuPaFZ3g2khiQ5zbhfunAKGks5qzSmbgaJpZM4KQhHm .

[RoboTechie]

@JasonDorie Sounds good to me! Thanks!

[JasonDorie]

This is committed to ActiveDevelopment

On Wed, Oct 12, 2016 at 12:02 PM, Kyle M notifications@github.com wrote:

@JasonDorie https://github.com/JasonDorie Sounds good to me! Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/Flight-Controller/issues/48#issuecomment-253306773, or mute the thread https://github.com/notifications/unsubscribe-auth/ANak_i-tYVrGDbJ_qeGykpXqD1SqFLsoks5qzS7DgaJpZM4KQhHm .

[JasonDorie]

This is completed, and Kyle has tested it.