Move hub looses print data in a tight loop on windows

[BertLindeman]

Describe the bug
Running on win10 the program pybricks-micropython/tests/basic/count_forever.py
The print looses some data from time to time.

To reproduce
Steps to reproduce the behavior:

1. Go to code.pybricks.com (on windows only?)
2. load the program (or copy from github) pybricks-micropython\tests\basic\count_forever.py
3. Connect the movehub and run the program
4. Keep an eye at the print output.

Expected behavior
Neat correct print.

Screenshots
None sofar

Environment
Win10
Microsoft Edge Versie 90.0.818.51
('movehub', '3.0.0b6', '7b3d1b42 on 2021-05-01')

Copied print data
From #320:

As seen before, but really clear here, there is data missing from the print.
Showing the complete print - see missing data at/near 32, 33, 69, 70

count: 0
count: 1
count: 2
count: 3
count: 4
count: 5
count: 6
count: 7
count: 8
count: 9
count: 10
count: 11
count: 12
count: 13
count: 14
count: 15
count: 16
count: 17
count: 18
count: 19
count: 20
count: 21
count: 22
count: 23
count: 24
count: 25
count: 26
count: 27
count: 28
count: 29
count: 30
count: 31
count: 3 34
count: 35
count: 36
count: 37
count: 38
count: 39
count: 40
count: 41
count: 42
count: 43
count: 44
count: 45
count: 46
count: 47
count: 48
count: 49
count: 50
count: 51
count: 52
count: 53
count: 54
count: 55
count: 56
count: 57
count: 58
count: 59
count: 60
count: 61
count: 62
count: 63
count: 64
count: 65
count: 66
count: 67
count: 68
c
 count: 71
count: 72
count: 73
count: 74
count: 75
count: 76
count: 77
count: 78
count: 79
count: 80
count: 81
count: 82
count: 83
count: 84
count: 85
count: 86
count: 87
count: 88
count: 89
count: 90
count: 91
count: 92
count: 93
count: 94
count: 95
count: 96
count: 97
count: 98
count: 99
count: 100
count: 101
count: 102
count: 103
count: 104

count 104 is the last printed data this time.

[BertLindeman]

Windows reboot did not solve the problem.

O,oh . . .
During my test my spikehub was advertising its Bluetooth (hope the term id correct)
So that might cause the Bluetooth traffic disturbance??

[dlech]

So that might cause the Bluetooth traffic disturbance??

It is possible it could cause some interference. Does does the Move hub improve with the SPIKE hub off?

2.4 GHz Wi-Fi (and other radios on the same frequency) can also interfere.

The closer antennas are to each other, the more potential for interference.

[BertLindeman]

It is possible it could cause some interference. Does does the Move hub improve with the SPIKE hub off?

2.4 GHz Wi-Fi (and other radios on the same frequency) can also interfere.

The closer antennas are to each other, the more potential for interference.

The spike hub was hidden behind a book, but within 20 cm from the move hub.

Indeed the movehub misses less print data with the other hubs OFF.
Some print characters are sometimes missing though.

And off course there are phones and the like are in the area.

[BertLindeman]

The technic hub is less sensitive to radio interference.
I placed the technic hub against the spike hub and ran the test up to 10000.
Did not see dropped data. But that is not 100% sure, just a visual check on passing strings.

Was thinking of two hubs in a model like the 42100 Liebherr shovel
On the LEGO control+ app I did not notice trouble with interference.

Is it oke to close this issue as caused by radio interference

[dlech]

Is it oke to close this issue as caused by radio interference

Let's leave it open to make it easier for other people to find. If lots of people have this same issue, we may have to reconsider how we send data.

[dlech]

I was able to make a significant improvement here. However, I'm not sure we will ever be able to entirely fix this.

As seen below, after the improvements, we still lose some data (counts 11 and 12). Bluetooth packet capture shows that this is really what the chip is sending, so the loss is on the Bluetooth chip on the Move hub. Also the fact that the c in count on count 10 is replaced with a 2 (presumably from the lost count 12) makes me think there could be some sort of buffer overrun bug on the BlueNRG chip.

count: 0
count: 1
count: 2
count: 3
count: 4
count: 5
count: 6
count: 7
count: 8
count: 9
2ount: 10
count: 13
count: 14
count: 15

This loss at the beginning can be worked around by adding a wait(1) before any use of Bluetooth in a program. There is still some data loss/corruption observed if you try do other Bluetooth things in your program, like use the Remote class.

[dlech]

For example, sometimes this program works just fine (running it while pressing and releasing buttons on the remote all of the time). Sometimes it eventually will show some similar data corruption/loss. Once it just stopped printing altogether which means we probably got stuck waiting for an event that never came, although pressing the stop button and starting the program again seemed to work.

from pybricks.pupdevices import Remote

remote = Remote()

def count():
    n = 0
    while True:
        yield n
        n += 1


for n in count():
    print("count:", n)
    remote.light.off()

[laurensvalk]

🎉

[dlech]

If we comment out the line remote.light.off() in the program above, we can see the following when the stop button is pressed in Pybricks Code:

count: 720
count: 721
count: 722
count: 723
count: 724
26
count: 727
counThe program was stopped (SystemExit).

If I recall correctly, currently we have a hack to not properly wait for Bluetooth tasks to finish when the stop button is pressed, so this could be due to that hack or it could be due to the suspected BlueNRG chip issues or a combination of both. EDIT: I don't recall correctly, this hack only takes effect when the hub is shutting down.

[dlech]

After some more reworking of the BlueNRG driver, the missing data in #324 (comment) is no longer observed. The occasional missing data when the stop button is pressed as in #324 (comment) is still occasionally seen.

But I think we can finally close this one since the original issue here seems to be fixed.