OpenVario with OpenSoar stops reacting to USB stick inputs

[DanD222]

A friend and I were flying in a competition recently with OpenVarios with the latest OpenSoar 3.22 images (https://opensoar.de/releases/v7.42.22/OV-3.22.0/) and have both experienced the following issue:

• After a while, the OpenVario would stop responding to USB stick inputs
• Infobox and map data would be updated normally
• Restarting the OpenVario would make the system respond to the USB stick inputs again for a short while
• Keeping the map zoomed in to a smaller area would make the issue manifest later than if the map was zoomed out to view a larger area

Incidentally, reverting to an older image, such as Freevario 23212, which we have been using before without problems, did NOT cause the issue to go away - the older OpenVario image would stop responding to USB stick inputs too.

[August2111]

I've known about the problem for a while now - but I've only noticed it with homemade (Arduino) sticks.
For a few weeks now, complaints have been piling up regarding the devices from SteFly and others - both with XCSoar and with OpenSoar on the OpenVario!
In some cases the OpenVario was repeatedly switched off and on hard, but that is of course not a solution ;-(
However, the automatic detection of such a condition with a possible debug log requires some development work, which I won't find time for until after the season...
Nevertheless, this topic has a very high priority!
I already sent this answer to XCSoar forum (OpenVario section)!

[August2111]

Hi @DanD222,
maybe we can do a private discussion about this and other issues over eMail? And maybe in German? My address is August2111@OpenSoar.de!
Thanks August

[lehrerhans]

Was ich herausgefunden habe, ist dass die Micro-USB Buchse auf dem Leonardo sehr empfindlich gegen mechanische Belastung ist.
Selbst die Steifigkeit des Kabels führt dazu, dass die Buchse sich bewegt bzw. abbricht. Man muss also nur durch dass Biegen des Kabels in 10cm Entfernung vom Stecker angefasst die Buchse verbiegen oder gar abrechen.

Die Masse-Verlötung der Buchse ist zwar da, aber bei mir ist die Leiterbahn von der Platine gerissen.
Probleme mit der mechanischen Unzulänglichkeit von Micro-USB Buchsen sind auch von Serienprodukten bekannt.

Vielleicht liegt ja hier der Hase im Pfeffer, statt , dass es sich um ein Softwareproblem handelt.
Nette Grüsse
Christoph Roters

[DanD222]

@lehrerhans - Thanks for the suggestion; I'm using my own remote stick design where the four USB wires are soldered directly to the PCB, with strain relief, so there's no USB connector in the path on this end of the USB cable.

@August2111 - I emailed you a day or two after your suggestion.

[August2111]

@DanD222 - Unfortunately, I didn't receive any email information from my server - so I unfortunately overlooked your email from August - and will answer this with eMail too...
@lehrerhans - In your case it could be that there are problems with a broken conductor track - but I can rule that out with most other RemoteSticks: The SteFly stick has a circuit board modeled on the Leonardo - there is no (mini) USB socket at all, but the 4 USB wires are soldered directly there... And there can't be any hardware problems on the component with the clamp and USB plug either. An indication that this is more likely due to an electromagnetic problem is provided by SteFly's new circuit board layout, which is said to produce significantly better results due to better shielding...
I approached this matter again from the software side: My sketches first activated the (Leonardo) watchdog timer, which resets the stick in the event of a program crash or something similar - and secondly, you can also trigger the reset manually by long pressing (over 4 seconds) the JoyStick enter key - then the RemoteStick logs on to the OpenVario again - and should work as originally... - without unplugging and plugging in. Unfortunately, a field test is still pending, so far I've only tried it in the 'laboratory' ;-)
For this 'software solution' please look here: https://github.com/OpenSoaring/Stick_Remote_Control_SteFly/releases

[lehrerhans]

The elctromagnetical problem seems a good hint. Most of the USB Cables have a ferrite ring in the cable.

@DanD222
Do you have a ferrite ring in your cable?

@August2111
I will use your Software Solution, so you have one more tester in the field.
Thanks for your great work!!!

[August2111]

@lehrerhans

I will use your Software Solution, so you have one more tester in the field.

This would be very nice, the (software) proposal is very new, ready two weeks ago only ;-)

[DanD222]

I don't have a ferrite ring on the USB cable; I also don't have a SteFly device either.
Please note that this was not a new installation, it's been flying in that particular configuration for at least a season before the issue occurred. I've since bought two new CubieBoards for the two devices that I've been troubleshooting and reverted back to using a pre-OpenSoar FreeVario image.

[lehrerhans]

@DanD222
Thank you very much for your clarification.
Which pre-OpenSoar FreeVario image did you use without issuses?
Where i can download it?

[DanD222]

@lehrerhans It was a FreeVario image with Kedder’s menu, which used do be available for download here https://freevario.de/en/downloads-en/, before FreeVario merged with OpenSoar.

[August2111]

@lehrerhans: I can't believe that DanD555's suggestion can solve your problem: I know that this connection is broken on many devices - and occurs with different firmware and software (OpenVario, SteFlyNav - XCSoar, OpenSoar, Shell(!) etc.). - older and newer ones. DanD555 himself has a big problem with my OpenVario and OpenSoar packages - I don't know why, but in my opinion his error diagnoses don't describe the real cause-and-effect relationships. And now I can't help him from a distance to clarify his impressions ...