distance not working well on XO-1.5

[dsd]

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"

[cjb]

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

[cjb]

test in os206

[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.

[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.

[Quozl]

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

[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.

[godiard]

Set output volume at 100%

[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.

[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.

[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.

[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.

[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.

[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.

[godiard]

Recorded sound

[godiard]

Audacity showing recorded sound screenshot

[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?

[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?

[godiard]

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

[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.

[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.

[bemasc]

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

[erikos]

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?

[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.

[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.

[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.

[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.

[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.

[greenfeld]

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.

[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.

[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.