IEEE 802.15.4 subsystem
Sign in or create your account | Project List | Help
IEEE 802.15.4 subsystem Git Source Tree
Root/
Source at commit e2b2df2e315c6b0338aed53dffd1dce9cae8196e created 13 years 6 months ago. By Werner Almesberger, Made the libatspi API driver-agnostic. | |
---|---|
1 | General |
2 | ======= |
3 | |
4 | Things not done yet |
5 | ------------------- |
6 | |
7 | - document directory hierarchy |
8 | |
9 | - make sure all files have a copyright header or are listed in AUTHORS |
10 | |
11 | - connect all the bits and pieces of the build system |
12 | |
13 | - combine io-parts.h generation |
14 | |
15 | - combine "standard" EP0 commands, such as *_ID and *_BUILD |
16 | |
17 | - implement return to DFU in application's EP0 protocol |
18 | |
19 | - consider removing *_ID and using bcdDevice instead |
20 | |
21 | |
22 | Bugs to fix |
23 | ----------- |
24 | |
25 | - builds fail if .version isn't there yet |
26 | |
27 | |
28 | |
29 | atrf |
30 | ==== |
31 | |
32 | AT86RF230-based IEEE 802.15.4 transceiver. Two variantes: one to make a USB |
33 | dongle for use with any Linux host, and one that connects with SPI directly |
34 | inside a Ben. |
35 | |
36 | |
37 | Things not done yet |
38 | ------------------- |
39 | |
40 | - examine spectrum around carrier frequency and first harmonic to look for |
41 | obvious distortions. Vary transmit power. |
42 | |
43 | - measure throughput as a function of placement/distance, carrier frequency, |
44 | and transmit power |
45 | |
46 | - atspi-txrx: suppport "extended mode" with IEEE 802.15.4 CSMA-CA for more |
47 | realistic throughput figures |
48 | |
49 | - measure full spectrum (ideally up to 25 GHz, but just 2nd and 3rd harmonic |
50 | will already tell most of the story) with calibrated antenna for FCC/ETSI |
51 | compliance assessment. Vary transmit power. |
52 | |
53 | - use IEEE 802.15.4 stack from linux-zigbee |
54 | |
55 | - verify that the Ben can output an a) 16 MHz clock, and b) with +/- 40 ppm |
56 | |
57 | - replace discrete balun and filter with integrated solution, to reduce BOM |
58 | size, maybe cost, insertion loss, and PCB space (see ATRF/ECN0003) |
59 | |
60 | - check if we really need three DC blocking caps in the RF path |
61 | |
62 | - change layout of transceiver side of the board for placement inside Ben |
63 | |
64 | - define EMI filters for placement inside Ben |
65 | |
66 | - check USB standard for recommended USB dongle dimensions |
67 | |
68 | - change layout for straight USB dongle |
69 | |
70 | - generate proper BOM |
71 | |
72 | - implement sleep mode |
73 | |
74 | |
75 | Bugs to fix |
76 | ----------- |
77 | |
78 | - atrf vs. atspi naming is a bit confusing |
79 | |
80 | |
81 | ccrf |
82 | ==== |
83 | |
84 | Board similar to the atrf, but with the TI/Chipcon CC2520. |
85 | |
86 | |
87 | cntr |
88 | ==== |
89 | |
90 | Simple USB-based counter to measure a clock's long-time accuracy with |
91 | arbitrarily high precision, by comparing it to an NTP time reference. |
92 | |
93 | |
94 | Things not done yet |
95 | ------------------- |
96 | |
97 | - measure duty cycle |
98 | |
99 | - use the LED to display activity on clock input and duty cycle |
100 | |
101 | - consider using a comparator and a DAC to allow for programmable logic levels |
102 | |
103 | - evaluate termination resistance |
104 | |
105 | - document circuit design |
106 | |
107 | - record beats between 16 bit counter polls and use them for the estimate |
108 | of lost cycles (2*1 is way too optimistic) |
109 | |
110 | - include system clock resolution in accuracy calculation |
111 | |
112 | - consider running shorter sliding windows to estimate drift |
113 | |
114 | - consider detecting unusual half-periods |
115 | |
116 | - consider using a reversed USB connector, to avoid having to cross D+/D- and, |
117 | worse, VBUS and GND |
118 | |
119 | - test input performance by counting a source that emits a known number of |
120 | cycles |
121 | |
122 | - consider using historical margins to sanity-check the current margin (if any |
123 | old.max < curr.min or old.min > curr.max, we have a problem) and to further |
124 | narrow the effective margin, thus achieving faster convergence. We would have |
125 | to consider temperature drift of the frequency source in this case. |
126 | |
127 | - find out why frequency measurements always seem to start high and then slowly |
128 | drop |
129 |