1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
|
%global _empty_manifest_terminate_build 0
Name: python-fmcw
Version: 3.2.5
Release: 1
Summary: Library for fmcw radar
License: GNU General Public License v3 (GPLv3)
URL: https://github.com/AlexBdx/Heli/tree/master/fmcw
Source0: https://mirrors.nju.edu.cn/pypi/web/packages/c9/81/2945cd909e7d35267c251017c27238c81dc12deda81a0422b114585c2d83/fmcw-3.2.5.tar.gz
BuildArch: noarch
%description
# FMCW
Based on initial & ongoing work by Henrik Forstén/[@Ttl](https://github.com/Ttl/).
**Documentation:** [Read The Docs](https://fmcw.readthedocs.io)
1. [Generalities](#Generalities)
2. [Description of the flow](#Description-of-the-flow)
3. [Technical considerations](#Technical-considerations)
## Generalities
### Version convention
Releases have a version number in the following format:
X.YYY.ZZZ
- X is the hardware version.
- YYY is the release version
- ZZZ is the minor update version
### History
The FMCW package is a library designed to interact at a high level with the fmcw radar from Henrik Forstén/[@Ttl](https://github.com/Ttl/). If you are not familiar with it, start with taking a look at Henrik's blog post on the third version of the radar:
[FMCW 3](http://hforsten.com/third-version-of-homemade-6-ghz-fmcw-radar.html)
For additional information on this type of radar, you can also take a look at the previous blog posts written by Henrik. These older radars are not be compatible with this library but can help shine some light on radar theory and the history of the project:
- [FMCW 1](http://hforsten.com/6-ghz-frequency-modulated-radar.html)
- [FMCW 2](http://hforsten.com/homemade-synthetic-aperture-radar.html)
Additionnaly, Henrik's fmcw project was covered in a few articles. For instance:
- [Hackaday coverage](https://hackaday.com/2017/10/11/homemade-6ghz-radar-v3/)
### Where to get an fmcw3?
Short answer: you have to make it yourself.
Longer answer: only a few boards seem to have been made so far, all based on the files that Henrik uploaded on his GitHub repository.
If you plan on building one, make sure you have:
1. proper hardware to place the components & reflow them
2. 200+ hours ahead of you (**VERY** dependant on your existing knowledge)
3. ~$500
Of course, these are rules of thumbs and should not be taken at face value.
### I have an fmcw3, what should I do next?
Congratulations! There are two main options:
1. You write your own script based on the library. This is expected to be hard as the documentation is lagging behind the code I write.
2. You reuse the latest release I have for the main script. This is the recommended option.
In what follows, I will describe how I use the library with **190830\_rt\_fmcw3.py**, uploaded with release 3.1.ZZZ.
## Description of the flow
Four main tasks are being executed by the script:
1. Read the data from the FPGA
2. Process the data
3. Save the data to file
4. Display the data in real time
### Architecture
A picture is better than a thousand words so here is a schematic:
### Read the data from the FPGA
This step is less easy than it sounds for a simple the reason: the FPGA is a real time chip while everything else (the usb port, the OS on my laptop, python...) is not. As a result, the FPGA outputs data are fixed intervals and if anything down the chain is not ready to receive it, the 4 kb buffers on the FTDI chip will quickly overflow and be overwritten. I have not found a silver bullet for that problem so far and only managed to mitigate it.
See here for more information:
[Stack Overflow](https://stackoverflow.com/questions/57592288/pylibftdi-device-read-skips-some-bytes/57600370?noredirect=1#comment101895577_57600370)
### Process the data
The data coming from the FPGA is parsed to separate it in sweeps. Valid sweeps are then processed in order to display 3 types charts in real time. Invalid sweeps (most of the time incomplete sweeps due to dropped bytes on the USB bus) are zeroed and displayed as such.
### Save the data to file
Threads are used to write the data to file. A total of three threads are spawned from the main process:
1. One for writing the settings to file. Note that it is immediately closed after writing to file.
2. One to write the raw, byte data to a text file.
3. One to write the processed data to a csv file.
### Display the data in real time
The main script offers the option to display data in real time. But there is no such thing as perfect real time: there is always a lag. Depending on how many sweeps you read at once from the USB port before processing, and how long these sweeps are, the lag can be increased or reduced.
With the default settings, the lag is a few hundred ms.
The refresh rate is also severly limited on most laptop given the amount of work needed to refresh a plot that can have tens of thousands of pixels on it. Despite minimizing the amount of elements to refresh when updating a plot and keeping each plot in a separate subprocess, 10 Hz appears to be the maximum refresh rate on my CPU (i7-8565U).
Below, a few examples of the displayed plots:
## Technical considerations
### Batch processing
Here is quick description of how a batch of data is processed.
Feel like this is cryptic? It is.
In a nutshell, the point is to mitigate the non-real time nature of the script as much as possible. It is not perfect and some data will be lost, but these days less than 5% is lost.
If you ever want to learn more just reach out to me.
%package -n python3-fmcw
Summary: Library for fmcw radar
Provides: python-fmcw
BuildRequires: python3-devel
BuildRequires: python3-setuptools
BuildRequires: python3-pip
%description -n python3-fmcw
# FMCW
Based on initial & ongoing work by Henrik Forstén/[@Ttl](https://github.com/Ttl/).
**Documentation:** [Read The Docs](https://fmcw.readthedocs.io)
1. [Generalities](#Generalities)
2. [Description of the flow](#Description-of-the-flow)
3. [Technical considerations](#Technical-considerations)
## Generalities
### Version convention
Releases have a version number in the following format:
X.YYY.ZZZ
- X is the hardware version.
- YYY is the release version
- ZZZ is the minor update version
### History
The FMCW package is a library designed to interact at a high level with the fmcw radar from Henrik Forstén/[@Ttl](https://github.com/Ttl/). If you are not familiar with it, start with taking a look at Henrik's blog post on the third version of the radar:
[FMCW 3](http://hforsten.com/third-version-of-homemade-6-ghz-fmcw-radar.html)
For additional information on this type of radar, you can also take a look at the previous blog posts written by Henrik. These older radars are not be compatible with this library but can help shine some light on radar theory and the history of the project:
- [FMCW 1](http://hforsten.com/6-ghz-frequency-modulated-radar.html)
- [FMCW 2](http://hforsten.com/homemade-synthetic-aperture-radar.html)
Additionnaly, Henrik's fmcw project was covered in a few articles. For instance:
- [Hackaday coverage](https://hackaday.com/2017/10/11/homemade-6ghz-radar-v3/)
### Where to get an fmcw3?
Short answer: you have to make it yourself.
Longer answer: only a few boards seem to have been made so far, all based on the files that Henrik uploaded on his GitHub repository.
If you plan on building one, make sure you have:
1. proper hardware to place the components & reflow them
2. 200+ hours ahead of you (**VERY** dependant on your existing knowledge)
3. ~$500
Of course, these are rules of thumbs and should not be taken at face value.
### I have an fmcw3, what should I do next?
Congratulations! There are two main options:
1. You write your own script based on the library. This is expected to be hard as the documentation is lagging behind the code I write.
2. You reuse the latest release I have for the main script. This is the recommended option.
In what follows, I will describe how I use the library with **190830\_rt\_fmcw3.py**, uploaded with release 3.1.ZZZ.
## Description of the flow
Four main tasks are being executed by the script:
1. Read the data from the FPGA
2. Process the data
3. Save the data to file
4. Display the data in real time
### Architecture
A picture is better than a thousand words so here is a schematic:
### Read the data from the FPGA
This step is less easy than it sounds for a simple the reason: the FPGA is a real time chip while everything else (the usb port, the OS on my laptop, python...) is not. As a result, the FPGA outputs data are fixed intervals and if anything down the chain is not ready to receive it, the 4 kb buffers on the FTDI chip will quickly overflow and be overwritten. I have not found a silver bullet for that problem so far and only managed to mitigate it.
See here for more information:
[Stack Overflow](https://stackoverflow.com/questions/57592288/pylibftdi-device-read-skips-some-bytes/57600370?noredirect=1#comment101895577_57600370)
### Process the data
The data coming from the FPGA is parsed to separate it in sweeps. Valid sweeps are then processed in order to display 3 types charts in real time. Invalid sweeps (most of the time incomplete sweeps due to dropped bytes on the USB bus) are zeroed and displayed as such.
### Save the data to file
Threads are used to write the data to file. A total of three threads are spawned from the main process:
1. One for writing the settings to file. Note that it is immediately closed after writing to file.
2. One to write the raw, byte data to a text file.
3. One to write the processed data to a csv file.
### Display the data in real time
The main script offers the option to display data in real time. But there is no such thing as perfect real time: there is always a lag. Depending on how many sweeps you read at once from the USB port before processing, and how long these sweeps are, the lag can be increased or reduced.
With the default settings, the lag is a few hundred ms.
The refresh rate is also severly limited on most laptop given the amount of work needed to refresh a plot that can have tens of thousands of pixels on it. Despite minimizing the amount of elements to refresh when updating a plot and keeping each plot in a separate subprocess, 10 Hz appears to be the maximum refresh rate on my CPU (i7-8565U).
Below, a few examples of the displayed plots:
## Technical considerations
### Batch processing
Here is quick description of how a batch of data is processed.
Feel like this is cryptic? It is.
In a nutshell, the point is to mitigate the non-real time nature of the script as much as possible. It is not perfect and some data will be lost, but these days less than 5% is lost.
If you ever want to learn more just reach out to me.
%package help
Summary: Development documents and examples for fmcw
Provides: python3-fmcw-doc
%description help
# FMCW
Based on initial & ongoing work by Henrik Forstén/[@Ttl](https://github.com/Ttl/).
**Documentation:** [Read The Docs](https://fmcw.readthedocs.io)
1. [Generalities](#Generalities)
2. [Description of the flow](#Description-of-the-flow)
3. [Technical considerations](#Technical-considerations)
## Generalities
### Version convention
Releases have a version number in the following format:
X.YYY.ZZZ
- X is the hardware version.
- YYY is the release version
- ZZZ is the minor update version
### History
The FMCW package is a library designed to interact at a high level with the fmcw radar from Henrik Forstén/[@Ttl](https://github.com/Ttl/). If you are not familiar with it, start with taking a look at Henrik's blog post on the third version of the radar:
[FMCW 3](http://hforsten.com/third-version-of-homemade-6-ghz-fmcw-radar.html)
For additional information on this type of radar, you can also take a look at the previous blog posts written by Henrik. These older radars are not be compatible with this library but can help shine some light on radar theory and the history of the project:
- [FMCW 1](http://hforsten.com/6-ghz-frequency-modulated-radar.html)
- [FMCW 2](http://hforsten.com/homemade-synthetic-aperture-radar.html)
Additionnaly, Henrik's fmcw project was covered in a few articles. For instance:
- [Hackaday coverage](https://hackaday.com/2017/10/11/homemade-6ghz-radar-v3/)
### Where to get an fmcw3?
Short answer: you have to make it yourself.
Longer answer: only a few boards seem to have been made so far, all based on the files that Henrik uploaded on his GitHub repository.
If you plan on building one, make sure you have:
1. proper hardware to place the components & reflow them
2. 200+ hours ahead of you (**VERY** dependant on your existing knowledge)
3. ~$500
Of course, these are rules of thumbs and should not be taken at face value.
### I have an fmcw3, what should I do next?
Congratulations! There are two main options:
1. You write your own script based on the library. This is expected to be hard as the documentation is lagging behind the code I write.
2. You reuse the latest release I have for the main script. This is the recommended option.
In what follows, I will describe how I use the library with **190830\_rt\_fmcw3.py**, uploaded with release 3.1.ZZZ.
## Description of the flow
Four main tasks are being executed by the script:
1. Read the data from the FPGA
2. Process the data
3. Save the data to file
4. Display the data in real time
### Architecture
A picture is better than a thousand words so here is a schematic:
### Read the data from the FPGA
This step is less easy than it sounds for a simple the reason: the FPGA is a real time chip while everything else (the usb port, the OS on my laptop, python...) is not. As a result, the FPGA outputs data are fixed intervals and if anything down the chain is not ready to receive it, the 4 kb buffers on the FTDI chip will quickly overflow and be overwritten. I have not found a silver bullet for that problem so far and only managed to mitigate it.
See here for more information:
[Stack Overflow](https://stackoverflow.com/questions/57592288/pylibftdi-device-read-skips-some-bytes/57600370?noredirect=1#comment101895577_57600370)
### Process the data
The data coming from the FPGA is parsed to separate it in sweeps. Valid sweeps are then processed in order to display 3 types charts in real time. Invalid sweeps (most of the time incomplete sweeps due to dropped bytes on the USB bus) are zeroed and displayed as such.
### Save the data to file
Threads are used to write the data to file. A total of three threads are spawned from the main process:
1. One for writing the settings to file. Note that it is immediately closed after writing to file.
2. One to write the raw, byte data to a text file.
3. One to write the processed data to a csv file.
### Display the data in real time
The main script offers the option to display data in real time. But there is no such thing as perfect real time: there is always a lag. Depending on how many sweeps you read at once from the USB port before processing, and how long these sweeps are, the lag can be increased or reduced.
With the default settings, the lag is a few hundred ms.
The refresh rate is also severly limited on most laptop given the amount of work needed to refresh a plot that can have tens of thousands of pixels on it. Despite minimizing the amount of elements to refresh when updating a plot and keeping each plot in a separate subprocess, 10 Hz appears to be the maximum refresh rate on my CPU (i7-8565U).
Below, a few examples of the displayed plots:
## Technical considerations
### Batch processing
Here is quick description of how a batch of data is processed.
Feel like this is cryptic? It is.
In a nutshell, the point is to mitigate the non-real time nature of the script as much as possible. It is not perfect and some data will be lost, but these days less than 5% is lost.
If you ever want to learn more just reach out to me.
%prep
%autosetup -n fmcw-3.2.5
%build
%py3_build
%install
%py3_install
install -d -m755 %{buildroot}/%{_pkgdocdir}
if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
pushd %{buildroot}
if [ -d usr/lib ]; then
find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/lib64 ]; then
find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/bin ]; then
find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/sbin ]; then
find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst
fi
touch doclist.lst
if [ -d usr/share/man ]; then
find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst
fi
popd
mv %{buildroot}/filelist.lst .
mv %{buildroot}/doclist.lst .
%files -n python3-fmcw -f filelist.lst
%dir %{python3_sitelib}/*
%files help -f doclist.lst
%{_docdir}/*
%changelog
* Tue May 30 2023 Python_Bot <Python_Bot@openeuler.org> - 3.2.5-1
- Package Spec generated
|
