Ticket #10122 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

distance not working well on XO-1.5

Reported by: dsd Owned by: bemasc
Priority: high Milestone: 10.1.3
Component: acoustic-measure-activity Version: not specified
Keywords: Cc: erikos, sridhar, godiard, greenfeld
Action Needed: no action Verified: no
Deployments affected: Blocked By:
Blocking:

Description

On XO-1.5, Distance does not work well. Currently testing with something very close to 10.1.1 build 119 on the ramp production units.

The numbers displayed are bad, and the hissing often gets out of sync so much that the laptops start hissing at each other at the same time. Putting an XO-1 at one end does not really help.

Jon N suggests that it may be related to known issues with the default ALSA input - "dsnoop is not behaving well with the hardware"

Attachments

0001-Saves-initial-volume-value-sets-at-100-and-restore-w.patch (2.6 kB) - added by godiard 4 years ago.
Set output volume at 100%
0001-Changes-ringdown-values-for-mor-stable-meassures.patch (0.8 kB) - added by godiard 4 years ago.
fileb4QaBn (193.6 kB) - added by godiard 4 years ago.
Recorded sound
Screenshot.png (30.2 kB) - added by godiard 4 years ago.
Audacity showing recorded sound screenshot
CairoPlot.py (50.1 kB) - added by godiard 4 years ago.
testgraph.py (0.5 kB) - added by godiard 4 years ago.

Change History

  Changed 4 years ago by Quozl

  • milestone changed from Not Triaged to 1.5-software-later

  Changed 4 years ago by cjb

  • priority changed from normal to high
  • next_action changed from diagnose to add to build
  • milestone changed from 1.5-software-later to 1.5-software-update

We have a fixed activity now; would be good to take this into 10.1.1 if we do another build.

  Changed 4 years ago by cjb

  • next_action changed from add to build to test in release

test in os206

  Changed 4 years ago by Quozl

Tested in os206 on XO-1.5 C1 and C3.

Via an access point, works reasonably consistently, only occasional pauses in measurements, which appear related to wireless network stalls (as seen also by top over ssh).

Via ad-hoc, works fine for distances under a meter, tends to report 14m above that, not sure why yet.

Other testers wanted.

  Changed 4 years ago by dsd

I saw the 14m thing too but attributed it to a noisyish environment. (distance was never perfect). I was using an AP for the test.

  Changed 4 years ago by Quozl

  • milestone changed from 10.1.1 to 10.1.2

  Changed 4 years ago by Quozl

  • next_action changed from test in release to review

No other testers have come forward, pushing this back for review before we close it.

  Changed 4 years ago by martin.langhoff

  • cc erikos added

  Changed 4 years ago by erikos

From my testing it does not matter if you share over an AP or an Ad-hoc network. Especially when changing the distance between the two machines while measuring one gets false numbers. After certain 'calls-and-response' most of the times the measurement does not re-calibrate anymore, it does a bit more reliable at the beginning.

  Changed 4 years ago by sridhar

  • cc sridhar added

  Changed 4 years ago by Quozl

  • milestone changed from 10.1.2 to 10.1.3

Changed 4 years ago by godiard

Set output volume at 100%

follow-up: ↓ 13   Changed 4 years ago by godiard

The attached patchs do the following: 1) At the activity start, save the values of volume and set value at 100%. When the activity close restore to the initial values. In my tests I couldn't measure more than 4 meters with the volume at 80% (the default value). When I set to 100% I could measure 12 meters.

2) The second patch change values of times between the messages sent by network and the start of the sounds. I have more stable measurements with these values.

in reply to: ↑ 12 ; follow-up: ↓ 14   Changed 4 years ago by erikos

Replying to godiard:

The attached patchs do the following: 1) At the activity start, save the values of volume and set value at 100%. When the activity close restore to the initial values. In my tests I couldn't measure more than 4 meters with the volume at 80% (the default value). When I set to 100% I could measure 12 meters.

I wonder a bit if an activity should be setting the general Volume. At least in GNOME you have relative volumes (though we use pulseaudio there). Maybe we can get away with an alert to set the volume to high?

2) The second patch change values of times between the messages sent by network and the start of the sounds. I have more stable measurements with these values.

I presume that those values are dependent on the network conditions. Best is if bemasc could comment here, as he knows the logic in this place of the code, if it makes any difference.

in reply to: ↑ 13 ; follow-up: ↓ 15   Changed 4 years ago by godiard

Replying to erikos:

Replying to godiard:

The attached patchs do the following: 1) At the activity start, save the values of volume and set value at 100%. When the activity close restore to the initial values. In my tests I couldn't measure more than 4 meters with the volume at 80% (the default value). When I set to 100% I could measure 12 meters.

I wonder a bit if an activity should be setting the general Volume. At least in GNOME you have relative volumes (though we use pulseaudio there). Maybe we can get away with an alert to set the volume to high?

You say we must ask the user to set the volume?

2) The second patch change values of times between the messages sent by network and the start of the sounds. I have more stable measurements with these values.

I presume that those values are dependent on the network conditions. Best is if bemasc could comment here, as he knows the logic in this place of the code, if it makes any difference.

Yes, the change is based a tests in my network environment only.

in reply to: ↑ 14   Changed 4 years ago by erikos

Replying to godiard:

Replying to erikos:

Replying to godiard:

The attached patchs do the following: 1) At the activity start, save the values of volume and set value at 100%. When the activity close restore to the initial values. In my tests I couldn't measure more than 4 meters with the volume at 80% (the default value). When I set to 100% I could measure 12 meters.

I wonder a bit if an activity should be setting the general Volume. At least in GNOME you have relative volumes (though we use pulseaudio there). Maybe we can get away with an alert to set the volume to high?

You say we must ask the user to set the volume?

Yes, I think it is not good practice to set the general volume level of Sugar in an activity.

I actually think that it makes sense to inform the user in any case that the volume should be raised when using distance. He might better understand what the activity is about and how it works.

  Changed 4 years ago by Quozl

Measure already manipulates the volume levels, because a working activity is more important than the user's volume preferences. It puts it back afterwards. It is appropriate for Distance to do this. Catch the loss of visibility events in GTK+ in order to restore the volume to normal, therefore it will happen when switching between activities.

  Changed 4 years ago by bemasc

OK, I have applied the delay changes by godiard. I am happy to add 0.2 seconds to the cycle time if his tests show that this improves the behavior on XO-1.5.

Regarding volume: I want the user to have full control over the volume while Distance is running. I have often run demonstrations well below full volume on the XO-1, because the distances were short and I wanted to have a conversation.

Maybe the right answer is to print some warning text if the system volume is too low. I think a better patch would probably show the user the amplitude of the last received signal and the noise floor. This is easy to measure, but I'm not sure how to display it in the GUI.

  Changed 4 years ago by godiard

  • cc godiard added

Changed 4 years ago by godiard

Recorded sound

Changed 4 years ago by godiard

Audacity showing recorded sound screenshot

Changed 4 years ago by godiard

Changed 4 years ago by godiard

  Changed 4 years ago by godiard

I am testing showing the signal in the GUI. Testing this, i commented the line what delete the recorded file and prepared a set of test files. Almost all the files start with 200 milliseconds with the max negatives values, and then a curve to cero. If you copy the files CairoPlot.py and testgraph.py to the Distance.active directory can generate similar images.

I think this can explain why adding time before the play of the first sound, i have better measurements. But why is happening? The device is sleeping? Can we awake it before start arecord or it's a bug in arecord?

  Changed 3 years ago by martin.langhoff

Where are we with this?

This bug seems to have a issue (delays from the sound HW?) which can be worked around, and we have the workaround.

Volume mgmt issues, can we do something practical quickly, or otherwise move those to a separate bug so we don't block on that?

  Changed 3 years ago by godiard

I have asked but didn't have response from the maintainer.

  Changed 3 years ago by bemasc

Hey. I didn't realize there was any urgency on this ticket, since I don't have much visibility into the target milestones, etc. I already committed godiard's suggested parameter changes, and I can spin up a new release .xo with those fixes easily enough.

Putting in a signal strength meter, which is the only decent solution to that problem, in my view, will require some analysis on what the received signals look like. I don't expect to have time to perform those sorts of experiments any time soon.

  Changed 3 years ago by godiard

If you want, I can work in this issue if we agree in the solution. I have attached a simple code to show the signal.

This can be used to show the noise level / signal, and if we show the signal from the two machines compared, explain how works the activity.

The graph show why the delay added get better measurements.

  Changed 3 years ago by bemasc

I uploaded version 21 to ASLO with the ringdown timeout change.

  Changed 3 years ago by erikos

  • cc greenfeld added

Ok, it is still in 'updates pending'. Maybe Sam can have a quick review (you need to be logged in ASLO).

@bemasc: Previous releases were uploaded to http://dev.laptop.org/~bemasc/ (linked at http://wiki.laptop.org/go/Activities/G1G1), so we change this now to fetch from ALSO then, ok?

follow-up: ↓ 27   Changed 3 years ago by bemasc

erikos: OK, I uploaded a copy of the .xo to dev.laptop.org/~bemasc as well. I thought that ASLO was the preferred source for these things now, but of course it's easy for me to do both.

in reply to: ↑ 26   Changed 3 years ago by erikos

Replying to bemasc:

erikos: OK, I uploaded a copy of the .xo to dev.laptop.org/~bemasc as well. I thought that ASLO was the preferred source for these things now, but of course it's easy for me to do both.

ASLO is fine with me. I was just wondering if I got the change fine. I will take ALSO from now on.

  Changed 3 years ago by godiard

  • next_action changed from review to test in build

  Changed 3 years ago by erikos

"The change increases the ringdown timeouts, which gives the electronics more time to stabilize before making measurements", this fix landed in 353. Gonzalo, maybe you can attach a testcase how to verify this.

  Changed 3 years ago by Quozl

Suggested testcase ... take two laptops, select a quiet location, install the unfixed version of Distance, measure the maximum distance than can be measured reliably, quantify the reliability, install the fixed version, repeat the measurement.

  Changed 3 years ago by godiard

In this activity es very important the volume of the xo.

If you have problems to have a stable measure, try putting the volume up in the two machines.

We need show in any way the necessary level to make the measure.

follow-up: ↓ 33   Changed 3 years ago by greenfeld

  • status changed from new to closed
  • next_action changed from test in build to no action
  • resolution set to fixed

Tested across 10.1.3 os355 and os356 using both XO 1 and 1,5 systems. 1.5 laptops were tested up to 6 meters; two XO 1's were used across the same table as two 1.5's to verify basic functionality still was there.

Mesh, ad-hoc, AP-based Salut as well as AP-based school server measurements were taken and verified to be equal. The laptops had to be kept still and face each other properly for an accurate measurement to be taken.

Of possible interest is that having an XO 1 share the Distance activity with a 1.5 seems to result in a ~0.1 meter measurement length increase, but it sounds like we are not trying to be that precise.

in reply to: ↑ 32 ; follow-up: ↓ 34   Changed 3 years ago by bemasc

Replying to greenfeld:

Of possible interest is that having an XO 1 share the Distance activity with a 1.5 seems to result in a ~0.1 meter measurement length increase, but it sounds like we are not trying to be that precise.

That is an interesting result. I expected this problem might occur, which is why I introduced a calibration bar that allows you to adjust the offset. Unfortunately, I was unable to determine any decent programmatic way to identify the hardware in use on both laptops, in order to set default calibrations that give accurate measurements across different hardware.

in reply to: ↑ 33   Changed 3 years ago by Quozl

Replying to bemasc:

I was unable to determine any decent programmatic way to identify the hardware in use on both laptops, in order to set default calibrations that give accurate measurements across different hardware.

In the Record activity the file hw.py was recently added for identifying XO-1 and XO-1.5 production hardware.

Note: See TracTickets for help on using tickets.