new utilities: atrf-proxy and atrf-path
werner at almesberger.net
Wed Apr 13 21:45:13 EDT 2011
In preparation for production testing, I've written two new utilities:
- atrf-proxy gives access to an ATBEN/ATUSB card via TCP
- atrf-path measures the difference between the nominal transmit power
of one ATBEN/ATUSB card and the received signal strength of another
atrf-path makes one card emit a constant signal and measures the
strength of the signal received by the other. Then it switches both
cards to the next channel and repeats the procedure.
This is basically a poor man's spectrum analyzer with tracking
generator. atrf-path can dump the results to a file or display them
with SDL in a Ben-sized window.
One can also specify a profile of acceptable values and then perform
a pass/fail test. Here's a screenshot:
The white line shows the measured signal strength. Frequency is along
the x axis, signal strength along the y axis. The red lines mark the
upper and lower boundary. The green disc indicates that the white
line is within the limits.
Here is the profile I used in this example:
atrf-path needs to talk to two cards. The atrf-* utilities so far
assumed that there was only one card: ATBEN if running on a Ben,
ATUSB otherwise. Now, we have more choices:
- all utilities (except atrf-path) accept an option to select the
device: -d driver[:arguments]
- on a PC, one can select which USB device to use with
-d usb:bus/number, where "bus" is the bus number and "number" is
the logical device number. When lsusb -d:1540 shows
Bus 001 Device 015: ID 20b7:1540 Qi Hardware ben-wpan, AT86RF230-based
the correct option would be -d usb:1/15
- similarly, one can select the USB device by bus and sequence of
ports to cross. This is more difficult to use than the above
approach, but has the advantage that the numbers stay constant as
long as the cabling isn't changed.
The syntax of the path is the same as in sysfs,
For example, I have a seven-port USB hub connected to my PC. USB
hubs with more than four ports typically contain two cascaded hub
chips with four ports each. I've connected an ATUSB card to a port
that happens to be on the 2nd chip. The option to reach it is:
This means: bus 1, port 3 (on the PC), then the 1st port of the
first chip in the hub, which leads to the second chip, and of
this one the 4th port.
The driver still checks the product/vendor ID and thus won't
cause mayhem if the path leads to some other device.
- to select the ATBEN card (which would be the default on a Ben
- and now the fun part: with -d net:address[,port] an ATBEN/ATUSB
card on a different machine can be accessed. For this, the
machine must be reachable via TCP/IPv4, and that machine must
To give access to the default card, simply run atrf-proxy without
arguments. It will listen on port 5440 (0x1540, like the ATUSB
product ID) for an incoming connection. atrf-proxy accepts the
-d option as well.
Example: if I have atrf-proxy running on my Ben with host name
"ben", I can identify the card from the PC with
atrf-id -d net:ben
In this case, this would produce the same output as running
ssh ben atrf-id
Now, back to atrf-path. atrf-path needs to talk to two cards at the
same time, so it can't just pick the system's default card. Instead,
the two cards are specified on the command line, e.g., when we add
another Ben called "jlime", with
atrf-path net:ben net:jlime
This will make it do one sweep at +/- 0.5 MHz in each channel, and
print the result on standard output. The +/- 0.5 MHz comes from the
limitation that the transceiver can only send a constant test
signal at an offset of 0.5 MHz from a channel's center frequency,
but not exactly at the channels center frequency.
If we're only intrested in one transmit frequency per channel, we
can tell atrf-path which one to pick with -T -0.5 or -T +0.5. This
also makes the sweep run faster, which is useful with graphical
The output of atrf-path can be visualized with the "plot" script
in ben-wpan/tools/atrf-path/ or by running atrf-path in GUI mode,
with the option -g.
Our command line is now
atrf-path -g -T -0.5 net:ben net:jlime
The transceiver's signal strength mesurements have a granularity
of 3 dB, which is rather coarse. We can use averaging to get more
atrf-path -g -T -0.5 net:ben net:jlime 10
We may also want to set the transmit power with the option -p,
which accepts a value between 0 (-17 dBm or 20 uW) and 15 (3
dBm or 2 mW). The default is currently to use maximum power, but
I'll probably change this.
Last but not least, we can set the profile with the option -P:
atrf-path -g -T -0.5 -p 0 -P profile.example net:ben net:jlime 10
Next: pass/fail and a playful usage.
More information about the discussion