Thread Tools
Jun 18, 2017, 03:20 AM
Registered User
Quote:
Originally Posted by night_ghost
3.6 was just wrong number and should be 3.5dev, current stable is 3.4.
Latest changes from upstream fixes a lots of bugs - see ReleaseNotes.txt in Copter's folder
I asked this because they have a default "master" branch and a "Copter-3.5" branch, when you merge changes from upstream from which branch do you get code?
Sign up now
to remove ads between posts
Jun 18, 2017, 05:22 AM
Registered User
vierfuffzig's Avatar
however, commit 810de706 plane version works perfectly on workbench. flight test asap, no surprises expected though...
Jun 18, 2017, 08:35 AM
Registered User
Quote:
Originally Posted by anbello
I asked this because they have a default "master" branch and a "Copter-3.5" branch, when you merge changes from upstream from which branch do you get code?
I always use Master branch but in that moment when Copter's ReleaseNotes updates - so where Master merged to Copter-N.N.
Jun 18, 2017, 01:00 PM
Registered User
RC output is fixed in new commit. The race in initialization sometimes could cause wrong timer's state
Jun 19, 2017, 07:12 AM
Registered User
Quote:
Originally Posted by night_ghost
RC output is fixed in new commit. The race in initialization sometimes could cause wrong timer's state
Tested commit 566137b, RC output now is OK but I see other problems:

- when I power on with the USB connector sometimes it hangs on boot, when it boots OK if I plug the battery all works OK;

- if I power on directly with the battery it always hangs, I ear the first tones from the ESC but not the final tones that are normally played when all is OK.

I repeated this many times to be sure.

I know that is not an HW problems because after this I re-flashed 810de706 and all went OK.
Jun 19, 2017, 07:30 AM
Registered User
>- if I power on directly with the battery it always hangs, I ear the first tones from the ESC but not the final tones that are normally played when all is OK.

Hmm... What does onboard LEDs on hang? I now test on AirbotV2 and never seen hang on boot.

Also pls connect any console terminal to VCP and copy/paste what will be there on hang.
Jun 19, 2017, 08:44 AM
Registered User
Quote:
Originally Posted by night_ghost
>- if I power on directly with the battery it always hangs, I ear the first tones from the ESC but not the final tones that are normally played when all is OK.

Hmm... What does onboard LEDs on hang? I now test on AirbotV2 and never seen hang on boot.

Also pls connect any console terminal to VCP and copy/paste what will be there on hang.
I will do this ASAP
in the meantime from what I remember:
when it boots OK I see the blue led flashing, when it hangs I see no activity on blue led (don't remember if always on or always off)
Jun 20, 2017, 06:11 AM
Registered User
New binaries as try to fix hangups
Jun 20, 2017, 09:50 AM
Registered User
Quote:
Originally Posted by night_ghost
New binaries as try to fix hangups
This morning I did some other test on previous commit (566137b) and I see that if I plug the battery with wifi telemetry (esp8266 on serial1) the system hangs, if I plug the battery without wifi telemetry all goes OK and plugging wifi after boot it works without problems.
With precedent release I never had this problems, I always used wifi on serial1.

I will try new binaries.
Jun 20, 2017, 11:36 AM
Registered User
Quote:
Originally Posted by anbello
wifi telemetry (esp8266 on serial1) the system hangs
seems like there is noise on some pins. Airbot's controllers don't has filters on input/output (contrary to true Revo) so requires special measures to filter.
I hate WiFi so I can't reproduce this.

Latest binaries has corrected order of tests in SPI transfers and limits a time per transfer. Time for I2C transfers is limited a time ago.
Jun 20, 2017, 11:57 AM
Registered User
Quote:
Originally Posted by night_ghost
seems like there is noise on some pins. Airbot's controllers don't has filters on input/output (contrary to true Revo) so requires special measures to filter.
I hate WiFi so I can't reproduce this.
I can understand this but what seems strange to me is that I had this WiFi telemetry on serial1 on all other commit I tested and it has always worked both on RevoMini and on AirbotF4.
Jun 20, 2017, 12:12 PM
Registered User
Quote:
Originally Posted by anbello
I can understand this but what seems strange to me is that I had this WiFi telemetry on serial1 on all other commit I tested and it has always worked both on RevoMini and on AirbotF4.
It is strange also the fact that if I connect it before the boot it makes the system hangs but if I connect it after the boot all works flawlessly.

However if the problem is unresolvable, I will change the telemetry system.
Jun 20, 2017, 01:04 PM
Registered User
Quote:
Originally Posted by anbello
I had this WiFi telemetry on serial1 on all other commit I tested and it has always worked both on RevoMini and on AirbotF4.
That's why this testing so required. Something may work in good conditions and stops/do errors in air, that's wrong.



Quote:
Originally Posted by anbello
It is strange also the fact that if I connect it before the boot it makes the system hangs but if I connect it after the boot all works flawlessly.
On boot there is an init process so most values are sended by one byte with lots of writes. After init there are mostly reads in blocks.
Jun 24, 2017, 04:36 AM
Registered User
Tested commit b4d3322
same problem with WiFi telemetry on serial1
Yesterday, 01:50 AM
Registered User
It's sad. As I understand it, there no ability to connect the debugger and see what it's doing? It remains only to try to repeat your configuration, for this I need a complete description of the connected telemetry.