Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Telemetry Lockups #40

Open
jrleeman opened this issue Sep 17, 2016 · 49 comments
Open

Telemetry Lockups #40

jrleeman opened this issue Sep 17, 2016 · 49 comments
Assignees

Comments

@jrleeman
Copy link

Using the 2.0 firmware and 2.0 ground station on Windows 10 the telemetry will lock up every few minutes for up to a minute before restoring. This has been a problem in the last couple of releases.

@MatzElectronics
Copy link
Collaborator

@jrleeman This is probably related to issue #23. Can you describe your setup? Are you connecting through XBee or USB?

Currently, there is no handshaking, so the idea is to keep the packets small and coming in a steady enough stream that they don't overflow the buffer on the FTDI chip. Windows also has a bad habit of de-prioritizing the FTDI driver, which means data isn't getting pulled frequently enough to prevent buffer overrun. It helps to close any other programs that are running, and see if that makes a difference

I'll mark this duplicate for now. Thanks for the input!

@jrleeman
Copy link
Author

The lockup happens though XBee only in my testing. This is running on a low-end surface with Windows 10. I'd be a bit more hesitant to mark this as a duplicate. There were no other programs open and I can't find a reliable time interval between lockups. Also as @JasonDorie pointed out I'm unsure that handshaking would do anything here.

@JasonDorie
Copy link
Collaborator

I don't have a Surface, or anything running Windows 10, so I have no means
of testing or debugging this. Does the bottom of the screen still say
"Connected" when the telemetry isn't showing?

On Sat, Sep 17, 2016 at 7:27 PM, John Leeman [email protected]
wrote:

The lockup happens though XBee only in my testing. This is running on a
low-end surface with Windows 10. I'd be a bit more hesitant to mark this as
a duplicate. There were no other programs open and I can't find a reliable
time interval between lockups. Also as @JasonDorie
https://github.com/JasonDorie pointed out I'm unsure that handshaking
would do anything here.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_pftelCay9t9p2z2srGG8we_n3Deks5qrKGIgaJpZM4J_r6G
.

@jrleeman
Copy link
Author

Yes - still says connected. I was just able to reproduce this error on a MacBook Air running 10.11.6. Telemetry runs for ~15 seconds, then locks up. If I power the ELEV8 down, the ground station still says connected. XBees are still talking from the comm activity LEDs.

@MatzElectronics
Copy link
Collaborator

@jrleeman Are you willing to do some testing of an improvement in the dev branch?

@jrleeman
Copy link
Author

Sure - I don't have the GCS build environment setup. Is it built using QT Creator?

@JasonDorie
Copy link
Collaborator

Yes, GroundStation is built with Mingw, Qt 5.5 (though newer should be
fine).

J

On Sunday, September 18, 2016, John Leeman [email protected] wrote:

Sure - I don't have the GCS build environment setup. Is it built using QT
Creator?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_niXLhlDpYtAmAK0spcuzTXFnmdNks5qrSqbgaJpZM4J_r6G
.

@MatzElectronics
Copy link
Collaborator

Yes, it is

On Sep 18, 2016 5:12 AM, "John Leeman" [email protected] wrote:

Sure - I don't have the GCS build environment setup. Is it built using QT
Creator?


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AS0quDfc6Me2uf3Avzs_VA5EHcvrKyLNks5qrSqbgaJpZM4J_r6G
.

@jrleeman
Copy link
Author

Can you all duplicate?

@MatzElectronics
Copy link
Collaborator

MatzElectronics commented Sep 19, 2016

I won't be able to until I get back tomorrow, I'll let you know what I find when I try it out.

On Sep 18, 2016 7:03 PM, "John Leeman" [email protected] wrote:

Can you all duplicate?


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AS0quA_m-abGSBRb2miYlgHr1_ljoKBIks5qre1WgaJpZM4J_r6G
.

@MatzElectronics
Copy link
Collaborator

@jrleeman It might take me a few days before I can set this up, but I'm going to clip on a serial monitor and watch all of the data going through - I'm starting to suspect that the xbee is going into command mode or getting "illegal" combinations of chars. I'll keep everyone posted on what I find.

@jrleeman
Copy link
Author

@MatzElectronics any luck on just reproducing the behavior? From the activity LEDs I think data is still being sent, but haven't verified with a serial dump.

@MatzElectronics
Copy link
Collaborator

Not yet. I haven't been able to get this all set up yet as we have a
deadline on another project approaching. My plan was to use a prop plug or
FTDI device to probe and capture the communication, and see if any clues
emerge from that.

On Sep 23, 2016 5:48 AM, "John Leeman" [email protected] wrote:

@MatzElectronics https://github.com/MatzElectronics any luck on just
reproducing the behavior? From the activity LEDs I think data is still
being sent, but haven't verified with a serial dump.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AS0quMjD2IYAmV7bSQggCzHsnUl5f4A_ks5qs8qQgaJpZM4J_r6G
.

@jrleeman
Copy link
Author

jrleeman commented Oct 7, 2016

Any luck? I'm hoping to write this up for a Servo Magazine article, but want to make sure it is a working system first.

@RoboTechie
Copy link
Collaborator

@jrleeman
Sorry we've been so slow to respond; it's been very very busy around here. I can't imagine how frustrating it is that your telemetry is not working. I think one of the challenges is that we (or at least I) have not been able to reproduce. I set up telemetry on my ELEV-8 running firmware v2.0.0 connected to GroundStation v2.0.0 and left it running for a little over 7 minutes, and the telemetry never dropped (the sensor graph in this GS version does loop around at x=6000, but all of the values continue to update). Here are a few more thoughts:

  1. If have the means to do so and haven't already, try a different computer, especially if the only one you have tried is a tablet.
  2. Another possible cause is interference in or around the 902 to 928 mHz (33cm) band, as that's what this telemetry equipment uses. If there is a high level of noise, the data or heartbeat signal could get jumbled beyond recognition, casing the data to drop out. As far as evaluating interference goes, the easist step is to consider if you know of any possible signal source near you. Around this band, that may likely to include amateur radio activity, and radiolocation (as use by cell towers, among other things). I also recommend you try out the Spectrum Analyzer function of XCTU to look for interference. You'll need to connect one of your XBees to the computer and connect to it in XCTU, then click on the wrench/screwdriver icon near the top of the XCTU window and select "Spectrum Analyzer" from the drop-down menu. In the SA tool, select the XBee connected to you computer, and then run the default analysis, which should take a few minutes. Here's what the results of my analysis look like:
    image

In the meantime, I'll work on putting together and testing an entire Flight Controller + Telemetry system to send to you tomorrow if we don't get anywhere from trying another computer and checking for interference.
Thanks for you patience!

@JasonDorie
Copy link
Collaborator

Did someone on this thread mention that it was repro'd on a non-windows
system too? I seem to remember that, but can't find it. I don't have a
surface or win10 system, and I've been trying to report but can't. I've
left this running for 15 minutes (over XBee) and not seen any loss of
communication, and I've been through the code a few times now looking for
suspects, and can't see any reason it'd be dropping for that long. A few
packets here and there I totally expect, but it should re-sync right away.

On Wed, Oct 12, 2016 at 11:21 AM, Kyle M [email protected] wrote:

@jrleeman https://github.com/jrleeman
Sorry we've been so slow to respond; it's been very very busy around here.
I can't imagine how frustrating it is that your telemetry is not working. I
think one of the challenges is that we (or at least I) have not been able
to reproduce. I set up telemetry on my ELEV-8 running firmware v2.0.0
connected to GroundStation v2.0.0 and left it running for a little over 7
minutes, and the telemetry never dropped (the sensor graph in this GS
version does loop around at x=6000, but all of the values continue to
update). Here are a few more thoughts:

  1. If have the means to do so and haven't already, try a different
    computer, especially if the only one you have tried is a tablet.
  2. Another possible cause is interference in or around the 902 to 928
    mHz (33cm https://en.wikipedia.org/wiki/33-centimeter_band) band, as
    that's what this telemetry equipment uses. If there is a high level of
    noise, the data or heartbeat signal could get jumbled beyond recognition,
    casing the data to drop out. As far as evaluating interference goes, the
    easist step is to consider if you know of any possible signal source near
    you. Around this band, that may likely to include amateur radio activity,
    and radiolocation (as use by cell towers, among other things). I also
    recommend you try out the Spectrum Analyzer function of XCTU
    https://www.digi.com/products/xbee-rf-solutions/xctu-software/xctu
    to look for interference. You'll need to connect one of your XBees to the
    computer and connect to it in XCTU, then click on the wrench/screwdriver
    icon near the top of the XCTU window and select "Spectrum Analyzer" from
    the drop-down menu. In the SA tool, select the XBee connected to you
    computer, and then run the default analysis, which should take a few
    minutes. Here's what the results of my analysis look like: [image:
    image]
    https://cloud.githubusercontent.com/assets/13735732/19322404/bd58a450-906d-11e6-82fb-ee8d078087a4.png

In the meantime, I'll work on putting together and testing an entire
Flight Controller + Telemetry system to send to you tomorrow if we don't
get anywhere from trying another computer and checking for interference.
Thanks for you patience!


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_sAw358WF5LGJUV1FmfylyOE9E8Cks5qzSVAgaJpZM4J_r6G
.

@jrleeman
Copy link
Author

jrleeman commented Oct 13, 2016 via email

@JasonDorie
Copy link
Collaborator

I have a Mini Mac, and will have a Macbook next week, so I can try to repro
this on those. It's very hard to diagnose if I can't reproduce the issue,
but I have a few ideas for things to try. At the very least I can add a
logging file with some diagnostics and have you run that version and send
me the results. It's not ideal, but it might be our best option if I can't
get it to happen locally.

On Thu, Oct 13, 2016 at 1:04 PM, John Leeman [email protected]
wrote:

I did reproduce on a mac as well. I’m on the road again, but will take a
screen video this weekend and check for interference. Jim was having this
same problem though.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_mkTv7_LgEWH9kaCBOjddFosPXCuks5qzo7TgaJpZM4J_r6G
.

@RoboTechie
Copy link
Collaborator

Good news/Bad news. I borrowed Ken's xBee setup, and it's having the intermittent connectivity issue, so I should finally be able to start troubleshooting first thing tomorrow. But this indicates the issue is probably not related to your operating system or interference.

@jrleeman
Copy link
Author

jrleeman commented Oct 14, 2016 via email

@RoboTechie
Copy link
Collaborator

Ok, I've been able to re-create (and then fix) the issue by changing the CE Routing/Messaging mode setting of base-station xBee using XCTU.

To see if that's what's causing your problem, try this fix:

  1. Plug you base-station xBee into your computer
  2. Launch XCTU (the xBee configuration program) on your computer.
  3. Click on the "Add Devices' Icon
  4. Select the COM port corresponding to your xBee, and click "Finish". XCTU should automatically find and add the xBee to your radio modules list. (If it doesn't, give me a call at 916 625 3003 and I'll walk you through recovering the module)
  5. Click on the module listing below Radio Modules . Wait for XCTU to load all of the module's settings.
  6. First, scroll down until you find the setting for BD Baud Rate, and double-check that it's set to 57600
  7. Next, scroll back up to CE Routing/Messaging and select Non-Routing Module from the drop-down menu
  8. Click the pencil icon to the right of the Routing/Messaging setting or the Write icon in the top bar to save your settings.
  9. Once XCTU confirms it has sucessfully made the settings change, close out of the program, and try connecting to your ELEV-8 again. (note that you should only be changing the base-station xBee to a Non-Routing Module, leave the xBee on your ELEV-8 as a Standard Router"

@jrleeman
Copy link
Author

@RoboTechie I'll give this a shot tonight/tomorrow morning and let you know.

@jrleeman
Copy link
Author

Ok - that does the trick it looks like. On my tablet (Windows 10) there would be very occasional and brief losses of telemetry, but that's possibly due to it's weak processor. Was maybe a few seconds every 5 minutes at most. MacBook Air had no issues at all.

@JasonDorie
Copy link
Collaborator

I've done some reading and experimenting with my own XBee pair here and
come up with some additional recommendations:

  • Use point-to-point mode instead of broadcast mode by setting the DH / DL
    entry of each device to match the SH / SL entry of the other. This makes
    them talk only to each other and reduces comm overhead
  • On the base station, leave the RR (retry count) setting as 'A' (10), but
    on the flight controller, lower the retry count to 3. We don't really care
    about individual packets as much as more current data.

These two settings reduce the latency from FC to PC significantly.

You can also bump the baud rate to 115,200 on both sides. This means
changing the serial init of the FC firmware to initialize the 2nd port as
115200 instead of 57600. It does not change the actual throughput, because
that's limited by how often I send the packets, but it means that the XBee
itself gets the data a little quicker, and is more likely to packetize
properly because there's more time between packets. I'm likely to make
this the new default setting - I initially thought this was the comm rate
between XBees, but it's actually just the comm rate between the host and
the XBee. The XBees communicate at their own rate regardless, and the
throughput is the important bit.

On Fri, Oct 14, 2016 at 8:18 PM, John Leeman [email protected]
wrote:

Ok - that does the trick it looks like. On my tablet (Windows 10) there
would be very occasional and brief losses of telemetry, but that's possibly
due to it's weak processor. Was maybe a few seconds every 5 minutes at
most. MacBook Air had no issues at all.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_phKNa_Qh12NCouWQk3gb8tRlZ5kks5q0EYfgaJpZM4J_r6G
.

@MatzElectronics
Copy link
Collaborator

Interesting. I'm anxious to try this out over the weekend!

On Oct 14, 2016 10:57 PM, "Jason Dorie" [email protected] wrote:

I've done some reading and experimenting with my own XBee pair here and
come up with some additional recommendations:

  • Use point-to-point mode instead of broadcast mode by setting the DH / DL
    entry of each device to match the SH / SL entry of the other. This makes
    them talk only to each other and reduces comm overhead
  • On the base station, leave the RR (retry count) setting as 'A' (10), but
    on the flight controller, lower the retry count to 3. We don't really care
    about individual packets as much as more current data.

These two settings reduce the latency from FC to PC significantly.

You can also bump the baud rate to 115,200 on both sides. This means
changing the serial init of the FC firmware to initialize the 2nd port as
115200 instead of 57600. It does not change the actual throughput, because
that's limited by how often I send the packets, but it means that the XBee
itself gets the data a little quicker, and is more likely to packetize
properly because there's more time between packets. I'm likely to make
this the new default setting - I initially thought this was the comm rate
between XBees, but it's actually just the comm rate between the host and
the XBee. The XBees communicate at their own rate regardless, and the
throughput is the important bit.

On Fri, Oct 14, 2016 at 8:18 PM, John Leeman [email protected]
wrote:

Ok - that does the trick it looks like. On my tablet (Windows 10) there
would be very occasional and brief losses of telemetry, but that's
possibly
due to it's weak processor. Was maybe a few seconds every 5 minutes at
most. MacBook Air had no issues at all.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/parallaxinc/Flight-Controller/
issues/40#issuecomment-253959306>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ANak_phKNa_
Qh12NCouWQk3gb8tRlZ5kks5q0EYfgaJpZM4J_r6G>
.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AS0quMpyB2JE4qoY3UIGEVVuwflHmOFmks5q0GtBgaJpZM4J_r6G
.

@hurricanehover
Copy link

hurricanehover commented Oct 15, 2016

Publison here.
Jason. Just reprogramed XBEE's. Looks like it works well. 30 minutes and no dropouts.

Jim

@jrleeman
Copy link
Author

jrleeman commented Oct 17, 2016

I had it working well - after making all changes (and playing around compiling v3.0 of GCS) I have a mysterious issue. I've gone back to V2.0.1 everything and upon connecting to the quad the indicators go away (see screenshot). It still responds to remote commands, but most of the telemetry isn't showing.
screenshot 17

@MatzElectronics
Copy link
Collaborator

Good evening,

Did you reinstall version 2.0.1 of the FC firmware back on your v3? The
two FC firmware versions are not compatible...

On Oct 16, 2016 8:19 PM, "John Leeman" [email protected] wrote:

I had it working well - after making all changes (and playing around
compiling v3.0 of GCS) I have a mysterious issue. I've gone back to V2.0.1
everything and upon connecting to the quad the indicators go away (see
screenshot). It still responds to remote commands, but most of the
telemetry isn't showing.
Uploading Screenshot (17).png…


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AS0quFFhCxmjQK74d8pMzJ0klEPonYpEks5q0r8lgaJpZM4J_r6G
.

@jrleeman
Copy link
Author

jrleeman commented Oct 17, 2016 via email

@MatzElectronics
Copy link
Collaborator

Sorry! I can't see the screenshot from my phone. Jason may have to answer
this one...

On Oct 16, 2016 8:43 PM, "John Leeman" [email protected] wrote:

Yes (visible in the screenshot, both are running 2.0.1)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AS0quGUc-aw52dRHJjwXO-2Enl1uzWzbks5q0sSUgaJpZM4J_r6G
.

@JasonDorie
Copy link
Collaborator

Hmm - I haven't seen that before. I'll take a look tonight. I flip
between the ActiveDev and another branch quite a bit, and was back on 2.0.1
to release it. Do you have a saved prefs file you can re-apply?

On Sunday, October 16, 2016, Matthew Matz [email protected] wrote:

Sorry! I can't see the screenshot from my phone. Jason may have to answer
this one...

On Oct 16, 2016 8:43 PM, "John Leeman" <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

Yes (visible in the screenshot, both are running 2.0.1)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/parallaxinc/Flight-Controller/
issues/40#issuecomment-254089073>,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/AS0quGUc-aw52dRHJjwXO-2Enl1uzWzbks5q0sSUgaJpZM4J_r6G>
.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_qGNXdBVZHLGQ2CyiKDmgEq24JXFks5q0sT7gaJpZM4J_r6G
.

@jrleeman
Copy link
Author

No, I don’t.

I may blast everything clean and try again if you can’t reproduce.

@JasonDorie
Copy link
Collaborator

Try bumping back to the other version, use GroundStation to save a prefs
file, revert back to 2.0.1 and apply it. (You'll need to go to one of the
screens with an "upload" button to apply the loaded prefs).

That might not work, but the prefs are written is such a way that they are
mostly compatible between firmware versions. You should also just save the
prefs from your 2.0.1 firmware and attch the file - I'll take a look and
see if anything looks wrong.

On Sunday, October 16, 2016, John Leeman [email protected] wrote:

No, I don’t.

I may blast everything clean and try again if you can’t reproduce.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_g7dvYT94iwrQ-O1nrSeNowWehF7ks5q0sljgaJpZM4J_r6G
.

@jrleeman
Copy link
Author

I had already deleted V3. Bad news is that the problem is replicated on my Mac which has never had anything but 2.0.1. I re-downloaded a clean set of firmware and set the XBees back to 57600. No luck. Should we close this issue since telemetry is indeed flowing, but open a new issue for the display?

@JasonDorie
Copy link
Collaborator

It'll be an issue with the format of the data coming from the Elev8, most
likely. Everything is responding incorrectly? IE, radio movement,
orientation display, sensor graph, or just some of those?

When you re-flashed the firmware, you programmed to EEPROM, not just RAM,
correct?

J

On Tuesday, October 18, 2016, John Leeman [email protected] wrote:

I had already deleted V3. Bad news is that the problem is replicated on my
Mac which has never had anything but 2.0.1. I re-downloaded a clean set of
firmware and set the XBees back to 57600. No luck. Should we close this
issue since telemetry is indeed flowing, but open a new issue for the
display?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_pU3THyNTTTHzaQuh_HUlfogZ-sOks5q1XIJgaJpZM4J_r6G
.

@jrleeman
Copy link
Author

Yes - EEPROM programmed. I noticed my radio settings carried over. Settings file attached.

Sticks on screen and some telemetry are fine, others like battery are not working.

JRL.zip

@JasonDorie
Copy link
Collaborator

I'll take a look after dinner and see if I can spot anything. Meanwhile,
make sure you're loading / flashing the right firmware and running
GroundStation from that same location. It's possible if you grabbed an
active-dev version that the version number hadn't been update but there
were format changes. Sometimes the version number change happens after
other stuff.

J

On Tuesday, October 18, 2016, John Leeman [email protected] wrote:

Yes - EEPROM programmed. I noticed my radio settings carried over.
Settings file attached.

Sticks on screen and some telemetry are fine, others like battery are not
working.

JRL.zip
https://github.com/parallaxinc/Flight-Controller/files/537739/JRL.zip


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_o87cLEdpe6kJAZTm_GwGlct3ZTeks5q1XRRgaJpZM4J_r6G
.

@JasonDorie
Copy link
Collaborator

More to the point, what you're suggesting shouldnt be possible with
release versions, so just double check in case it's something simple and
the UI is mis-reporting the version no.

On Tuesday, October 18, 2016, John Leeman [email protected] wrote:

Yes - EEPROM programmed. I noticed my radio settings carried over.
Settings file attached.

Sticks on screen and some telemetry are fine, others like battery are not
working.

JRL.zip
https://github.com/parallaxinc/Flight-Controller/files/537739/JRL.zip


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_o87cLEdpe6kJAZTm_GwGlct3ZTeks5q1XRRgaJpZM4J_r6G
.

@jrleeman
Copy link
Author

Okay - I reset all factory defaults and reflashed. Indicators are back working now. Sorry for all the back and forth. Hopefully the data format is settling down soon?

w.r.t. trying future dev stuff. Is master working generally and all development in ActiveDev?

@JasonDorie
Copy link
Collaborator

Going forward, yes. Master should always be working and stable. ActiveDev
will be in-flux, brought to stability, then branched across to master.

J

On Tuesday, October 18, 2016, John Leeman [email protected] wrote:

Okay - I reset all factory defaults and reflashed. Indicators are back
working now. Sorry for all the back and forth. Hopefully the data format is
settling down soon?

w.r.t. trying future dev stuff. Is master working generally and all
development in ActiveDev?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_vU8ReaOjdtER5e8UKAaOlH6az3Fks5q1XrEgaJpZM4J_r6G
.

@jrleeman
Copy link
Author

Happy to contribute to the write-up/tutorial if there's an easy way to. Is that content on GitHub somewhere or does it live on a Parallax server somewhere?

@JasonDorie
Copy link
Collaborator

Probably not - that would all exist within Parallax. Matt's baby.

J

On Tuesday, October 18, 2016, John Leeman [email protected] wrote:

Happy to contribute to the write-up/tutorial if there's an easy way to. Is
that content on GitHub somewhere or does it live on a Parallax server
somewhere?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_qMho1MhHZAr3OhCwBsq-OaWnnWhks5q1X9HgaJpZM4J_r6G
.

@MatzElectronics
Copy link
Collaborator

Going to hold this open until I edit related docs, once there, I will close.

@JasonDorie
Copy link
Collaborator

Assigned to Matt as he's holding open until docs are updated.

@jrleeman
Copy link
Author

jrleeman commented Mar 8, 2017

Did the parallax docs ever get updated on this? Servo released the article as a free and open to all article: http://www.servomagazine.com/index.php/magazine/article/January2017_MultiRotorHobbyist_Telemetry

@hurricanehover
Copy link

hurricanehover commented Mar 8, 2017 via email

@jrleeman
Copy link
Author

jrleeman commented Mar 8, 2017

Right - I mean the online "assembly guide/tutorial" from Parallax that needed some revision after the issues we found troubleshooting this.

@MatzElectronics
Copy link
Collaborator

MatzElectronics commented Mar 9, 2017 via email

@jrleeman
Copy link
Author

No worries - I was just going through cleaning up issues, etc I'm involved with :)

@hurricanehover It was mostly the setup of the XBee radios that we changed I believe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants