qi-hardware/ben-wpan
1
0
Fork 0
mirror of git://projects.qi-hardware.com/ben-wpan.git synced 2024-12-23 15:35:30 +02:00
Code

prod/doc/test.html: added a decription of the tests

Browse Source
This commit is contained in:
Werner Almesberger 2011-05-26 19:42:57 -03:00
parent 1410027dd2
commit f5c46de802
2 changed files with 164 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
prod/doc/Makefile
View File

@ -1,6 +1,6 @@
PNGS=flow.png setup-A.png setup-B.png setup-C.png setup-D.png
HTMLS=index.html setup.html flash.html test.html analysis.html
JPGS=atusb-programming.jpg
JPGS=atusb-programming.jpg atrf-path.png atrf-path-small.png
.PHONY: all upload clean
@ -17,6 +17,13 @@ setup-%.png: setup.fig
atusb-programming.jpg:
wget http://downloads.qi-hardware.com/people/werner/wpan/tmp/atusb-programming.jpg
atrf-path.png:
wget http://downloads.qi-hardware.com/people/werner/wpan/tmp/atrf-path.png
atrf-path-small.png: \
atrf-path.png
convert -scale 50% $< $@
upload: $(HTMLS) $(PNGS) $(JPGS)
rsync -e ssh $^ \
www-data@downloads.qi-hardware.com:werner/wpan/prod/

158
prod/doc/test.html
View File

@ -5,11 +5,12 @@
<!-- ====================================================================== -->
<!-- ---------------------------------------------------------------------- -->
<H2>Test setup for atben</H2>
To test an <B>atben</B> board, place a reference <B>atusb</B> board into
the PC, insert the
<P>
<IMG src="setup-A.png">
<P>
@ -30,6 +31,159 @@
<H2>Test procedure</H2>
The test process is started with
<PRE>
make ben
</PRE>
for an <B>atben</B> DUT and with
<PRE>
make usb
</PRE>
for an <B>atusb</B> DUT. It performs the following steps:
<UL>
<LI>Enumeration (<B>atusb</B> only)
<LI>LED (<B>atusb</B> only; not yet implemented)
<LI>GPIO scan (not yet implemented)
<LI>Identification
<LI>Crystal frequency (only implemented on <B>atben</B>)
<LI>Spectrum
<LI>Receive
<LI>Send
</UL>
Of these tests, only "LED" and "Spectrum" require operator input. The
other tests run without interaction.
<P>
The test scripts log the commands they execute and their output in the
file <B>_log</B>.
<!-- ---------------------------------------------------------------------- -->
<H3>Enumeration (atusb only)</H3>
The enumeration test verifies that the <B>atusb</B> board has been
identified by the PC's USB stack. If this test fails, the board may
not be plugged in correctly or it may be missing the firmware. A
board that has passed both stages of the firmware flashing process
should always pass the enumeration test.
<!-- ---------------------------------------------------------------------- -->
<H3>LED (atusb only)</H3>
@@@
<!-- ---------------------------------------------------------------------- -->
<H3>GPIO scan</H3>
@@@
<!-- ---------------------------------------------------------------------- -->
<H3>Identification</H3>
This test reads the transceiver's registers that contain values identifying
the manufacturer, the chip's part number, and the chip revision. If an
<B>atusb</B> board fails this test, this probably means that the MISO signal
between transceiver and the microcontroller has a problem.
<P>
On <B>atben</B>, failure may simply indicate an improperly
inserted board. Eject the board, re-insert, and try again. If the test
keeps on failing, this may indicate a problem with MOSI, MISO, nSEL,
SCLK, the power supply, the crystal oscillator, or possibly the position
of the transceiver chip.
<P>
Note: this test is meant as a higher level test. The GPIO test should
eventually provide more detailed results for problems with the SPI interface.
<!-- ---------------------------------------------------------------------- -->
<H3>Crystal frequency (atben only)</H3>
This test measures the frequency of the crystal oscillator in the DUT.
On <B>atben</B>, it does this by transmitting packets, and measuring
the time between the SLP_TR pulse that starts the transmission and the
interrupt signaling the end of the transmission.
<P>
If this test fails, this may indicate that the load capacitors of the
crystal are missing, badly soldered, or have the wrong value. It could
also mean that the crystal itself is defective. Another possible cause
of oscillator malfunction could be flux residues bridging traces.
<P>
The <A href="fault.html">fault analysis page</A> has more details on
testing the crystal oscillator.
<!-- ---------------------------------------------------------------------- -->
<H3>Spectrum</H3>
The spectrum test measures the reception of a signal sent from the
reference device to the DUT. It does this across the entire frequency
range in which the WPAN boards operate, allowing the detection of
frequency-dependent anomalies.
<P>
This test depends on numerous external factors, like the exact position
and orientation of the two devices with respect to each other, and the
presence of any items that can reflect or absorb RF signals. Such items
include metal chairs and human bodies. Because of the test's sensitivity
to environmental factors, the operator needs to decide when the result
represents a valid measurement and then confirm the result shown.
<P>
The image below shows the typical display during the spectrum test:
the white line is the measured signal strength. The red lines indicate
the minimum and maximum allowed values. The green circle in the upper
right corner indicates that the signal strength is within the limits.
A downward-pointing red triangle would indicate that the signal is too
weak, an upward-pointing yellow triangle would indicate that the signal
is too strong.
<P>
<A href="atrf-path.png"><IMG src="atrf-path-small.png"</A>
<P>
To finish the test, the operator must type either <B>P</B>, <B>F</B>,
or <B>Q</B> in the window shown. <B>P</B> means "pass" and can only be
entered if the measurement is within the limits. <B>F</B> means "fail"
and can only be entered if the measurements is outside the limits.
<B>Q</B>, quit, can be entered at any time and also fails the test.
<!-- ---------------------------------------------------------------------- -->
<H3>Receive</H3>
In the receive test, the reference device sends a number of frames to the
DUT. The test program verifies correct reception of all the frames. A
device that has passed all the preceding tests should not encounter
problems in the receive test. If it does, there may be a problem with
the bypassing of the transceiver's 1.8 V supplies.
<!-- ---------------------------------------------------------------------- -->
<H3>Send</H3>
The send test is like the receive test, but with the DUT acting as the
sender and the reference acting as the receiver. If a device passes the
receive test but fails the send test, there is probably an issue with
the bypass capacitors of the analog 1.8 V supply.
<P>
Another possible cause could a problem with the SLP_TR signal. The
GPIO test should eventually catch this issue, but it may currently
remain undetected until the send test.
<P>
<HR>
@ -37,7 +191,7 @@ Up: <A href="index.html">Production and testing</A>&nbsp;
Prev: <A href="flash.html">Flashing (<B>atusb</B> only)</A>&nbsp;
Next: <A href="analysis.html">Fault analysis</A>&nbsp;
<HR>
Last update: 2011-05-18&nbsp;&nbsp;<I>Werner Almesberger</I>
Last update: 2011-05-26&nbsp;&nbsp;<I>Werner Almesberger</I>
<HR>
</BODY>
</HTML>