Radar Velocity

SUMMARY
Check out the full paper: https://doi.org/10.3390/s23146314

Extended abstract submitted to SPN2022: File:BoSL Radar sensor extended abstract.pdf

For instructions on how to assemble the sensor please see the wiki page Assembling the Radar Sensor

For information on how to use the velocity sensor please see the getting started page Getting Started With the Radar Sensor

27th January 2021

We have ordered some radar sensors from Acconneer, namely the A111, in the XM132, and XE132. And some radar lenses for these.

• 

  XE132 Front

• 

  XE132 Back

• 

  Acconneer Python Portable Exploration Tool in sparse short time FFT mode

The XE132 from acconeer comes with pre-compiled binary software, that allow it to connect via micro USB to a computer and create visualizations of the data.

The XE132 was set up as per the user guide, as was the Acconneer portable exploration tool.

Of interest to our application is the sparse short-time FFT visualisation as it allows the speed to be determined at different distances from the sensor. As can be seen from the gallery there is an FFT for each of the 6cm distant ranges, a matrix plot of the velocity-speed readout of the sensor.

Open question which need to be answered for this sensor are of question of how the lens impacts performance, if the Doppler shift of water can be measured, and at what angle to the flow is the Doppler shift successfully measured.

28th January 2021

Today we will test the XE132 in the flume. Just a basic test will be conducted. The radar sensor will be pointed at the flume surface and the short time fft visualization tool will be used to detect if a Doppler shift if present. Different angles and lens configurations will be tested.

It was found that the water velocity was not able to be easily seen with the acconneer radar sensor. It seem that the issue being had is that there is little reflection off the water surface. A wide range of angles were tested. Specifically the velocity was not seen to go above about 0.1 m/s. This was not easily separable from errors such as the water surface level changes.

Following some more tests in the flume it was seen that the high velocity readouts occurred when the water velocity was greatest, hence adding to the hypothesis that the changes in surface height were being measured more than the water velocity itself.

In another test outside the flume, the radar sensor was moved at an angle to the floor and at a constant height. At a 45 degree angle it was seen that the Doppler shift was able to be measured, however with a weak signal, as the angle decreases this signal became stronger in amplitude but the measured velocity decreased until when the radar was pointed vertically, no horizontal movement would cause Doppler shift. This test highlights that a good reflected signal occurs perpendicular to the surface, but a good Doppler shift occurs parallel to the surface.

If this system is going to function, it is needed to test how to achieve a better reflection of water and how to minimise the effect of water surface changes.

In investigating other high cost Doppler radar sensors, they all seem to require a minimum surface ripple height of about 3mm. I have a suspicion that this is because the reflect the Doppler signal off the rising slope of the wave, hence getting a good reflection angle to bounce the signal back to the sensor. These sensors are also quoted as measuring the surface velocity, which further supports this. https://www.mdpi.com/2072-4292/12/8/1296/htm discusses this listing the small surface waves as scatterers. That paper also predicts the optimal size for a 60GHz surface scatterer wave is 3mm. In reflecting on the flume experiment, it the flow was very smooth at some parts, the lack of reading is not explained with the above information.

2nd February 2021

The acconneer XE132 was tested along with the lens kit. With was done in a bath tub filled with water. The aim of the test was to see if the acconeer was able to measure the velocity of waves generated in the tub. To do this a cylindrical object was bobbed up and down propagating out waves which would then travel under the acconeer's measurement zone. The acconeer was mounted about half a meter above the waters surface, and angled at about a 45 degree angle. Hence the water surface was on the order of 1 meter away from the sensor. The results were monitored on an external computer via acconeer's portable exploration tool.

The short time fft measurement tool was used and it was found that the water waves were able to be measured. The waved needed to be of a sufficient size in order for them to be detected, a few millimetres in size as predicted by theory was found to be about right, surface bubbles or other small surface features greatly helped the sensor detect a stronger return signal.

The settings were then optimized, to get the best performance. This was found to be when:

• Range Interval - set as appropriate
• Profile - 3
• Sweep Rate - 2000 Hz
• Sweeps per frame - 32

• Sampling Mode - A (less correlation)
• Repetition Mode - Host Driven
• Down sampling factor - 1
• HW accel. average samples - 32
• Gain - 0.5

5th February 2021

Today was spent developing a testing device to further and numerically verify the performance of the radar sensor. It is a PVC pipe with an attachment point for the radar velocity sensor. This attachment point can vary the sensors height and angle above the water surface allowing the testing of these different parameters. The water will be sent down the PVC pipe where the angle of the pipe can be changed to allow different water velocities. Area in which this test environment is more challenging that an actual installation is that the PVC pipe is a very narrow water stream hence the radar reflection area is much smaller than in a more natural stream.

Images of the test platform can be seen below.

• 

  Radar test platform

• 

  Radar velocity sensor attachment point closeup

An endcap is attached to the far end of the pipe via duct tape this allows water to build up and increase the water surface height, hence also altering the velocity. The radar velocity sensor screws into the front of the attachment point.

The amount of metal in the design was reduced as metallic object might interfere with the radar beam.

8th February 2021

The apparatus built above was used to test the radar sensor. To do this the radar sensor was attached 800 mm above the pipe and angled at a 45 deg angle of declination. The pipe was inclined at an angle no greater than 5 deg. A hose pipe was used to flow water down the tube. The radar setting were as described above. Initially this didn't work with no reading being detected.

A jet setting was then used on the hosepipe to shoot water just above the pipe. This was able to be detected by the radar sensor with a velocity of about 1 m/s. Again, when this was done just inside the pipe, no reading was given. This indicates that the pipe adds too much attenuation to the signal.

The radar sensor was then lowered to 400 mm and angled at 45 deg. This time it was able to get a reading when there was flow in the pipe. This confirms that the attenuation was too high previously. In a real application it is hoped that the lack of the PVC cover and the wider width of the water surface will provide enough more signal for a reading to still be achieved. It should be noted that a wide surface helps significantly with falloff as point objects falloff with 1/r^4 and planar objects 1/r^2.

In a rudimentary test, the height of the pipe was increased and the water velocity was also seen to increase. Now a more detailed experiment will be undertaken mostly to determine the linearity of this device.

For the experiment some changes had to be made to the PC host. This was to get some form of averaging on the output as this fluctuated frequently. The way this was done is by taking the past N = 20 FFT frames and averaging these. The FFT frames are the arrays of speed vs distance. From this the average distance and speed coordinate from measurements at least half of the maximum was found and printed to the terminal. This will serve as the measured data for the experiment.

A hosepipe was used to send water down the pipe. The height of the far end of the pipe was changed to get different angle measurements. water was injected at approximately the point directly below the sensor.

The results of the experiment are included below:

Pipe Height Top (H)(mm)	ΔH (mm)	Velocity (v)(m/s)	Δv (m/s)
0	20	0.17	0.03
100	20	0.66	0.02
200	20	0.79	0.02
300	20	0.89	0.02
410	20	0.96	0.02
610	20	1.13	0.02

To analyse these data we will apply Bernoulli's principal, thus we will assume our flow is steady and viscous forces are negligible.

We will assume water is injected at the top of the pipe with some initial velocity v, and that as the water runs down the pipe its velocity increases. At the point of measurement by the radar sensor its velocity is u. As the pipe is inclined there is a height difference between the top of the pipe and the measurement point Δz. We assume that that any pressure gradients are negligible, hence
1/2 ρ u^2 = 1/2 ρ v^2 + ρg Δz
u^2 = v^2 + 2ρgΔz
Furthermore some geometry reveals that the height difference Δz is proportional to H, the height of the top of the pipe. Hence κH = Δz for some κ.
Finally this gives: u^2 = 2ρgκH + v^2.
Thus a plot of u^2 vs H should provide a linear plot. It should be noted that the radar velocity sensor does not measure u, but infact u*cos(θ), where θ is the angle of the sensor from the water velocity in our case this is 45 deg, and constant, hence this conversion factor can be ignored.

Doing this we get the plot below. Note the zero height data-point was excluded from analysis. As I'm not as confident that the approximation made fit at this regime.

The plot indicates that the trend is fairly linear with an R^2 value of 0.996. The line of best fit also lies within the uncertainty of the data points. It indicates that the sensor does indeed make linear measurements of water velocity in the right conditions. What this experiment does not tell us is if absolute measurement is correct or of a linear calibration will need to be conducted. It does also not let us know what errors we should expect from the difference between water surface velocity and mean water velocity.

9th February 2021

In the work so far a radar lens was critical to the performance and focusing of the radar sensor. In any future design it will be necessary to have a lens present. 3D printing the lens is feasible as the mm waves are long relative to the minimum feature size of the 3d printer and geometric optics can be used as the waves are short relative to the size of the lenses. Measuring and characterizing materials at 60 GHz to make accurate calculations of the of the performance of lens is out of the scope of equipment at hand. Instead a empirical approach will be taken. A number of lenses will be designed and they will be tested at a set of different distances from the sensor. The one which performs optimally will be chosen for the design.

To do this both the lenses and a jig will need to be designed which is able to hold different lenses and different distances from the radar sensor. For this a simple block of wood with a grove cut out in it was made. Adding some blu-tack into the groove allows a bit of z-positioning for alignment of the optical axis. Lenses can be rested on the surface of the wood. Their size is such that when resting on the block they are approximately aligned with the optical axis.

Lens holder for lens testing

In terms of the different lenses designed a variety designs were modded. The use of Fresnel lens was considered however it was found that diffractive effects would become prevalent if this was incorporated [1]. A Fresnel zone plate could also be considered however this is required to be made of metal, perhaps PCB printing will be an effective option for this however for the moment it won't be investigated.

The array of lens designs chosen were:

• A copy of the acnoneer Hyperbolic lens
• Hyperbolic lens scaled by 1.5
• 24 mm radius lens with surfaces on front and back (may be tricky to print)
• The 24 mm radius lens with front and back surfaces printed seperately
• 30 mm radius lens
• 30 mm radius lens (no holder to attach to back of previous)
• 30 mm radius lens with larger optical diameter
• 2 step Fresnel version of previous
• 4 step Fresnel version of previous.

In a second task the optimum angle for the radar sensor is to be considered. Previously 45 degrees had been used however this was chosen just for the convenience of setup. There are a number of factors which influence the optimum operation angle. 1. The lower the angle the short the return signal path is, hence getting a stronger return. 2. The lower the angle the less scatter is needed for it to be reflected back to the sensor. 3. The higher the angle the more parallel the water velocity and reflected signals are, hence the larger the cos θ term in the doppler shift equation. This gives better velocity resolution.

To test out the optimum angle the PVC tube device will again be used. Water fill be flowed down the pipe and the velocity will be measured by the velocity sensor. Different angled will be used and the recorded speed, distance, and amplitude of the maximum will be recorded. The pipe will be leveled flat with a spirit level to mitigate the affect of gravity on the speed of flow, and create a more uniform flow field. The radar sensor was 400 mm above the water with the hyperbolic lens, settings for measurement were as above except where otherwise noted.

The data obtained was

Angle of declination (deg)	Speed (m/s)	Distance (cm)	Amplitude (arb)	Speed/cos(θ) (m/s)
0	1.26	57	600	1.26
23	1.28	57	600	1.39
40	1.26	70	1000	1.64
53	0.13	53	2000	0.22
66	0.13	46	4000	0.32
90	0.11	43	13000	inf

It should be noted that a signal of 600 is approximately the background noise at these settings, 1.26 m/s and 57 cm are the center of the measurement range and so likely a null reading.

The speed of 0.13 is only 1 above the reading of zero, it was found that more resolution was needed to resolve these points so the sweep rate was decreased to 500 hz. Doing this obtained the data:

Angle of declination (deg)	Speed (m/s)	Distance (cm)	Amplitude (arb)	Speed/cos(θ) (m/s)
0	0.01	37	900	0.01
23	0.01	37	900	0.01
40	0.08	56	950	0.10
53	0.10	53	1500	0.17
66	0.05	45	3000	0.12
90	0.04	43	25000	inf

I still was't satisfied with the performance of the sensor at this point, particularly the quantisation of the speed at low velocities. Some setting were adjusted to be:

• Range Interval: 0.24 - 0.8 m
• Profile: 3
• Sweep Rate: 500 Hz
• Sweeps per Frame: 64
• Sampling Mode: A
• Repetition Mode: Host Driven
• Downsampling Factor: 1
• HW accel average samples: 32
• Gain: 0.5
• Power Saving Mode: Active
• Enable Asynchronous Measurement: True

With these settings the data obtained was:

Angle of declination (deg)	Speed (m/s)	Distance (cm)	Amplitude (arb)	Speed/cos(θ) (m/s)
40	0.15	60	1600	0.19
53	0.10	53	2400	0.17
66	0.04	45	4500	0.10
90	0.025	42	64000	inf

While the results are not definitely conclusive as to a best angle which can be chosen, it appears that generally the correction of cos(θ) works when the measured velocity isn't too small, or the angle too steep, this is important as it means that the water velocity recorded is more due to the propagation along the flow lines rather than change in the water surface height due to waves etc. It also appears in the data that angles too steep or too shallow cause problems with either no signal being obtained or no velocity data in that signal. An angle of declination somewhere between 40 - 65 degrees seems appropriate. A note that in the final design we should include an accelorometer to measure the angle without user input.

10th Februrary 2021

A useful resource with documents requirements for radar installation: https://my.usgs.gov/confluence/display/SurfBoard/Guidelines+for+Siting+and+Operating+Surface-water+Velocity+Radars This website is helpful in the listings of material properties at 60 GHz, https://www.infineon.com/dgdl/Infineon-Radar_wave_propagation_through_materials-Whitepaper-v01_00-EN.pdf?fileId=5546d462766cbe8601768a120c6d36cf&da=t

Using the infineon document an ehstimation of the losses due to the presence of the PVC pipe in the tests above can be calculated. Tables 2 and 3 give the surface and volume attentions due to various materials of 60 GHz, using figure 3, it is seen that the the angle of 45 degree inclination can be largely ignored as it does not have a significant impact for the estimation. The double pass surface attentation is ranging from -1.34 (Plexiglass) to -2.59 (nylon). The volume attenuation for 4 mm of PVC (double pass) is ranging from -0.44 (polycarbonate) to -8.64 (nylon). This gives a total transmittance range of 60% to 8% hence it is likely that the PVC pipe caused a reduction in the radar power of at least one half.

11th Februrary 2021

Today we will be testing out the various lenses printed yesterday. To start with the lens block will be fixed in place with some blutack and the XE132 inserted into the cutout grove. The lens block needed to be raised off the table with a plastic container as the surface of the table is metal and this interferes heavily with 60 GHz radar. In the portable exploration tool the power bins tool was used. The lab environment was likely a poor choice of location do to this experiment as there were many obstacles which the radar could reflect off. This issue was found to be too challenging to combat and it was thought that better results could be attained by relocating the experiment.

The experiment was then moved to a room with fewer obstructions. A whiteboard of several meters squared in area of positioned about 5 meters from the radar sensor and lens holder which were fixed atop a table such that and such that their height was approximately the same as the center of the whiteboard. Again the same radar settings were used in the exploration tool.

Some notes while conducting the experiment were that the lenses were difficult to position on and keep stable, this resulted in high uncertainty in the data collected. A better system will need to be designed for the final product and for more finalized testing. Factors such as angle and lateral positioning were seen to play a large role in the reading received. Also notable is that the reading tended to oscillate up and down with a period of a few millimetres when altering the distance of the lenses.

The specific settings used for the potable exploration tool were:

• Bin Count: 7
• Range Interval: 2 - 7 m
• Profile: 4
• Update Rate: Limit 50 Hz
• Repetition Mode: Host Driven
• Downsampling Factor: 4
• HW accel average samples: 10
• Gain: 0.5
• Power Saving Mode: Active
• Enable Asynchronous Measurement: True

In the data the amplitude measurement was taken as the amplitude in bin 5. The distance measurement was the distance from the base PCB of the XE132 to the back surface of the lens, note that the base PCB is attached to the XM132 PCB to which the A111 is mounted.

The data taken is included in the table below:

Lens	Distance (mm)	Amp (arb.)	Gain (dBFS)	Angle subtended by lens (deg)
none		600	0
ACC-HPL	8.2	4000	16.5	70
ACC-FZP	22	2000	10.4
ACC-COV	25	1000	4.4
PLA_1	37	3200	14.5	39
PLA_2	34	3800	16	41
PLA_3	14	5000	18.4	64
PLA_4	8.2	4200	16.9	70
PLA_5	25	3000	10.4	41
PLA_6	38	7000	21.3	52
PLA_7	29	6000	20	52
PLA_8	17	2600	12.7	52

The lens names for in the above table can be referenced to:

Name	Material	Infill(%)	Radius Front (mm)	Radius Back (mm)	Aperture (mm)	Notes
ACC-HPL	PA-12	100	12	inf	22
ACC-FZP	PA-12	100
ACC-COV	PA-12	100
PLA_1	PLA	95	24	inf	30
PLA_2	PLA	100	24	inf	30
PLA_3	PLA	100	12	inf	30
PLA_4	PLA	100	12	inf	22
PLA_5	PLA	100	12	12	22
PLA_6	PLA	100	30	inf	49
PLA_7	PLA	100	30	inf	49	2-step Fresnel
PLA_8	PLA	100	30	inf	49	4-step Frenel

Firstly to note that Acconeer specifies the gain of the ACC-HPL at 8.2 mm as 17.3 dB_FS which is somewhat similar to the value of 16.5 dB_FS measured here. We can see that the performance of the best lens the PLA_6 had a performance of 21.3 dB_FS. This lens design will be used in the final product. Also interesting is determining the focal length of the lenses as this can be used to estimate the refractive index of the the PLA plastic used. If we assume that the focal length is the distance at which maximum power was achieved (This can be justified as 5 m is very far relative to the other distances in the problem and hence can be treated at infinity) then we can apply the lens makers formula to get the refractive index. When this is done a value of between 1.7 and 2.0 is given. For the purpose of future design a value of 1.8 will be used however it will be noted that this can be used for rough calculation only, and final design will need to be verified via experiment. The calculated angle subtended by lens is useful as it gives some indication of how much of the radar output is being "picked up" by the lens. Note that acconeer specifies that the half power beam width is 40 deg in the E-plane and 80-deg in the H-plane.

12th February 2021

At 10 GHz this paper: https://ieeexplore.ieee.org/document/7535340 finds that the refractive index of PLA is about 1.85. Another consideration for lens design is that it should preferably a multiple of λ/2 away from the sensor, this minimizes destructive interference. The A111 has a specified center frequency of 60.5 GHz, hence giving a wavelength of 4.96 mm. Thus the focal point of our lens should be some multiple of this. We will go for a lens most similar to PLA_6, hence the r_f ~ 30 mm and r_b ~ inf. Thus the lens makers formula gives: 1/f = (n-1) 1/r_f. Since f = mλ/2, then: r_f = m(n-1)λ/2. We will use a PLA refractive index of 1.85, hence, the closest focal lengths available are m = 15: r_f = 31.6 mm and f = 37.2 and m = 14: r_f = 29.5 mm and f = 34.7

As there is still some uncertainty in this calculation, a number of lenses close to these values should be built and evaluated experimentally to see which gives the best performance.

15th February 2021

The flow measuring experiment was rerun, this time with a few improvements. The analysis this time will be using manning equation as this provide an estimation of the velocity rather than relying on just relative measurements from Bernoulli. A few modifications were made to the pipe apparatus. Firstly a stand was constructed so now the start of the pipe could be positioned in heights of 50 mm increments. A sponge was also inserted into the start of the pipe to make the flow more consistent.

First the flow rate was measured. This was found to be 60 mL/s. The pipe was then placed on a level surface, as measured with a spirit level. At this height the stand was at its "0mm" setting. The radar sensor was placed at 400 mm above the pipe at an angle of declination of 53 deg.

The sponge had to be removed as when it was present no water velocity could be measured. This is likely something to do with the removal of scatters that is created.

The stand of the pipe was used to set the pipe to a given height. The water was then turned on and allowed to flow down the pipe, after a few tens of seconds the acconeer portable exploration tool on the settings shown below, was used to measure the water velocity, distance to water surface, and amplitude of the signal. A ruler was then used to measure the width of the water flow at the far end of the pipe. These data were recorded in a table and then the height was changed to proceed to the next data point.

It is noted that the some difficulty was had to measure the the width of the water flow, this is because the width only changed slightly through the experiment and the edges of the flow become hard to determine to a high precision. This also had to be measured at the far end of the pipe away from the center, where the measurement was occurring, due to the need of visual access for the ruler.

Aconneer Settings:

• Range Interval: 0.24 - 0.8 m
• Profile: 3
• Sweep Rate: 500 Hz (1000 Hz for height 200 mm and higher)
• Sweeps per Frame: 64
• Sampling Mode: A
• Repetition Mode: Host Driven
• Downsampling Factor: 1
• HW accel average samples: 32
• Gain: 0.5
• Power Saving Mode: Active
• Enable Asynchronous Measurement: True

The data obtained is recorded in the table below:

Height (mm)	Velocity (m/s)	Distance (cm)	Amplitude (arb)	Flow Width (mm)	Velocity/cos Θ (m/s)	Slope (m/m)	Hydraulic Radius (mm)	Manning's Velocity (m/s)
0	0.10	51	2700	60	0.17	0	47	0.00
50	0.33	54	10000	45	0.55	0.03	49	0.24
100	0.41	54	12000	37	0.68	0.07	50	0.35
150	0.50	55	10000	35	0.83	0.10	50	0.43
200	0.58	55	6800	30	0.96	0.13	50	0.50
250	0.62	55	11000	40	1.03	0.17	50	0.55
300	0.68	55	10000	36	1.13	0.20	50	0.61
350	0.70	55	9800	40	1.16	0.23	50	0.65
400	0.72	55	9000	38	1.20	0.27	50	0.70
450	0.78	56	7500	38	1.30	0.30	50	0.74
500	0.81	56	7200	40	1.35	0.33	50	0.78

Some other measurements about the setup were that the length of the pipe was 1500 mm, and its diameter 103 mm. From this the slope can be calculated as h/length, and the Hydraulic radius can also be calulated noting that the cross section of the pipe is a circle. Manning's equation can be applied to get the manning velocity, this requires a manning coefficient, this can be looked up to be roughly 0.01 as the pipe was made of PVC.

The uncertainties involved can be estimated as the following: Height - 5mm, Velocity - 0.02 m/s, Flow Width - 5mm, Pipe Length - 10 mm, Pipe radius 1 mm. From these the uncertainties in other quantities can be derived. The Manning's Roughness obviously had uncertainty however this will be excluded from the numeric analysis initially.

A graph can be drawn comparing the manning velocity to the measured velocity this is done below:

The graph shows that there exists a strong linear correlation between the manning velocity and the radar velocity with an R^2 value of 0.996. The gradient of the plot and its y-intercept are not 1 and 0 respectively. It is possible that the error in the gradient is due to the uncertainty in the Manning's roughness, as it is possible that the value found from a lookup table was off by some amount, and it is also the case that the Manning's roughness would directly alter the gradient of the graph. The non-zero y-intercept could be because the flow isn't entirely driven by gravity by also the water pressure from the water source.

Overall this experiment gives me confidence that a implementation of this radar velocity system will work well at measuring the water velocity, perhaps requiring a linear calibration to achieve grater accuracy.

17th February 2021

Today was spent porting over functionality of the acconeer portable exploration tool to a python script. The python script will directly control the registers of the XM132 hence this code becomes easily integrate-able into a future design. The reason this was first done in python is that it is much quicker to debug if something isn't working quite right. Details of the registers are found from documents on acconeer's website.

25th February 2021

More work was done porting over the processing algorithm. Specifically, work was done to take the python algorithm developed and rewrite this into c++ code which can be uploaded to the chosen microprocessor. The microprocessor to be used has not be chosen yet so the code cannot be specialized, however general algorithmic functions are still able to be implemented. One major consideration is memory usage, if the chosen processor is the ATmega328p then memory will be quite tight, and so the program is being optimized to minimize this usage. The same modified library for FFT calculations used in the in water velocity sensor is being used since it fulfills the same design requirements. Of course the discreet Harley Transform is always very appealing due its its more efficient operation and memory usage however, its difficult to find an efficient implementation for Arduino and well optimized FFT would still be faster.

Some notes about the program is that it current takes the FFT over a large set of distances, to get a distance-velocity matrix. There could be another possible method which would achieve higher distance accuracy and less memory usage. This would involve fist using a distance optimized service on the A111 to get the water distance within some millimetres, and then using this distance to the water surface to set the A111 sparse service used for doppler measurement to measure only at this distance. This would compress the 2D distance-velocity matrix to 1D only velocity array and so save substantial memory. The downside of this approach however is that it would likely take more time to make a measurement, code would need to be written to detect a reflection off water from the distance service, and this information would then need to be given to the sparce service. Giving a inaccurate distance measurement could mean that no velocity data is obtained when in fact the water is flowing.

28th February 2021

Some reading was done into the ideal processor for the radar velocity sensor. Memory permitting a good option would be an ATmega328PB, this is like the ATmega328P however has two serial ports, this is useful as we would need one serial port for communication with the BoSL and one for communication with the XM132 module. It is also familar being able to use all the familiar tools. If memory does not permit then it looks like the SAMD21G would again be a good choice. After completing the code it looks at if the maximum number of memory needed will be less than 2K. This is because the XM132 does not like to go above 64 sweeps per frame, so even with 7 range bins this is approx 1.2K including auxiliary memory needed for data processing.

We will now begin work on the hardware integration.

7th March 2021

More work was done on designing a board for the radar sensor. The basic design was an ATmega328PB and the XM132. These communicate via a serial connection. The XM132 is connected through a load switch and tri-state buffer, this allows it to be entirely turned off when not in use, lowering quiescent current. We have additionally exposed the XM132 SWD interface and a communication/programming interface for the ATmega.

An accelomometer will be included to determine the orientation of the sensor, this is necessary to determine coefficients in the dopper shift and distance calulations. The chosen accelorometer is will be the KXTJ3-1057.

24th March 2021

The final checks were conducted on the schematic. A bill of material was made for the device with total cost coming to around $25 USD. A few adjustment had to be made in the part list due to stock shortages. Mounting holes were added to the PCB to aid in the designing of the case. I have put in two screw holes with the idea that the other side can be secured with a ledge from the casing.

4th April 2021

Silkscreen detailed were added to the PCB and the schematic was double checked against the datasheets. A prototype design (rev 0.1.0) of the PCB was sent off for printing. The design files can be found at the design library .

Radar Velocity PCB rev 0.1.0

27 May 2021

We got the radar PCB's back however there was a light issue with the buffer-gate footprint. This was removed and the relevant pads were shorted.

The minicore ATmega328PB bootloader was able to be uploaded and then the device could be used as expected.

There exists another issue with the radar power regulator, it turned on far too fast for the circuit, that is that it causes a brownout condition when it turned on. For now we can just supply 3V3 volts to the VRDR. For the future there exists a version of the the power switch used with a soft start.

After JP1 was bridged closed the ATmega328p could talk to the XM132 module. The XM132 firmware was flashed over SWD.
To do this first the SWD header was connected to the j-link base and power was supplied to the XM132.
The j-flash lite utility was then used with the STM32G071CB mcu setting to program the firmware binary supplied on the acconeer website.
The offset address is set to 0x08000000 in the j-flash software.

Some debugging was done to the firmware written for the ATmega328PB. Some work still needs to be done on reading the buffer data. It currently seems to be too fast for the arduino to keep up.

The buffer work was completed, it was actually mostly just buggy code, the current issue is memory. Memory related crashes are causing issues with the sensor. These need to be ironed out.

These were ironed out and now we are getting velocity and distance readings which are fairly close as when compared to the same data analysed in python.

We now move on to testing the accelorometer.

It was found possible to get the accelorometer working, and easy to get the declination angle out afterwards.

All the parts have been verified working and are able to be integrated together in one firmware.

29th June 2021

A case for the Radar sensor is being designed. The case needs to host the lens and the radar PCB. The below design was used a first prototype:

• 

  Radar Case Front

• 

  Radar Case Back

30th June 2021

The radar was placed in its enclosure and tests were conducted to determine the radar performance and to check if any of the enclosure would inhibit the radiation power and range of the device.

To do this the radar module was firmly fixed in place and pointed at a metal screen about 3 meters from a large metal screen. The following code was then uploaded to the module: File:Radar velocity pwr test.zip file attach and the module was connected to a computer via a serial port. The python script File:XM132serial livepwr.zip, was then used to analyse the data coming back. This data was a measurement of the reflected power in 1 m bin increments away from the sensor. The average over time of the bin at 3 meters was then recorded with different lens setups.

Case number 3 and radar module 001 and the 30 mm radius lens were used. The lens was positioned at different distances from the lens stop on the case via plastic shims of know thickness.

The results are below:

Distance (mm)	Power (arb.)
no lens	12300
0	20800
1	21000
2	21000
3	21100
4	20700
5	20900
6	21000
7	21000

as is seen the presence of the lens had a large effect on the reflected power +75%. This is less than seen in previous lens tests were increases of 10x were seen. This could either be due to the radar case affecting performance or the 3 m reflection distance being closer than other tests, and the lens having a greater effect at increasing the reflected power at greater distances.

More tests involving different lenses and case designs should be investigated.

An interesting example how the sensitivity of the radar module to the case was found, putting a 4mm thick 1 mm wide radar lens shim in the case while there was no lens reduced the no lens reflected power by 3000. This indicates that several different radar case designs should be trialed

The test above was repeated with lenses of radius 31 mm and 29 mm however the results were immeasurably different.

2nd July 2021

The test on the 30th of June were repeated for lenses of radius 45mm 40mm 35mm 27.5mm and 25mm. The data is tabulated below,

Distance (mm)	Power (arb.)
Lens radius: (mm)	no lens	25	27.5	35	40	45
0	11000	13200	17800	20300	18600	15800
4	-	10400	15600	20500	19300	18300
6	-	7600	14000	20300	18600	17700

The results indicate that lenses of these sizes perform no better than the 30mm lens used previously. Therefore the 30mm lens will be chosen for the design.

5th July 2021

A number of different cases for the radar PCB were tested to see their impact on radar performance. A similar test was used to the power testing on prior days. The results are shown below, a distance '-' indicates no lens was used. Otherwise the 30mm radius lens was used.

Case number	Distance (mm)	Power (arb.)
3	-	11500
3	4	20800
4	-	4500
4	4	20700
5	-	6000
5	4	17200
6	-	2700
6	4	16600
7	-	2600
7	4	19400
none	-	2000

Case number 3 was the case used for the previous testing it features a conical taper from the aperture to the size of the XM132 board.
Case number 4 features no taper at the aperture until halfway down the barrel. It then features a conical taper to the size of the XM132 board.
Case number 5 features a conical taper from the aperture to the size of the A111 radar sensor.
Case number 6 is like number 4 except it has large cutouts in the barrel to reduce to leave only a small section of material for lens support.
Case number 6 is like number 3 except it has large cutouts in the barrel to reduce to leave only a small section of material for lens support.

It was noted that it was difficult to install the radar PCB, and thus case number 5 was significantly misaligned with respect to the center of the A111 center. The data reveals that the tapering cases act to intensity the received power by up to 5 times compared to without any casing. The lens brings this up to 10 times greater. These results are similar to what was measured in February and explain why the tests in may did not see a 10x increase as those in februrary - because the casing which was used in may already had a 5 times gain when compared to the bare sensor.

It is not clear why the pretense of the case taper tends to increase the received radar power. A detailed radiation analysis would be out of the scope of this work. However some suggestions include increase focusing of the radar reflected off the tapered surface.

Case 8 was a tested which is like case 5 but fixes the alignment issues. This gives a with 4mm distant lens a power of about 19500. This is close to case 3. I think for the final design a version of case 8 with a wider aperture will be chosen. As the taper in case 8 allows for better cable management.

7th July 2021

Today a prototype radar sensor was built. This is built into a housing, however is not yet waterproofed. Below are some images which display the sensor.

• 

  Radar front

• 

  Radar back with lid

• 

  Radar back without lid

A stand was also built which holds the sensor. The sensor wiring is detailed in the table below:

Pin	Colour (ethernet)
3.3 V	Green
GND	Half Green
Reset	Orange
Wake	Half Orange
TX	Brown
RX	Blue

22nd July 2021

A quick test was conducted with the PVC pipe to see if the new integrated radar velocity design was able to detect water-flows. The setup was largely the same as in the tests conducted on Feb 15. The data for the two trial was:

	Sensor Distance Above pipe (mm)	Line of sight distance to flow (mm)	Angle relative to flow (deg)	Recorded Amplitude (arb.)	Velocity (angle corrected) (mm/s)
Trial 1	600	1000	40	120	1440
Trial 2	1000	1200	46	50	1440

As is seen the radar velocity sensor is able to measure the flow velocity from two different positions. The distance at which it is measuring these from is greater than when the XM132 module was being used, which was unable to measure flow beyond 400 mm. The signal was quite noisy however, so it is unlikely that the velocity would be able to be recorded from a much greater distance with this setup. Baring in mind that the quantity of flow was small and the radar needed to penetrate through the PCV pipe. The auto-ranging built into the firmware did not function correctly for this experiment. The auto-ranging focused on the distance block which contained the floor, rather than the pipe which was elevated above the floor. This is to be expected as the floor is a much larger reflector. It is hoped that this will not be an issue in common installations where the water channel will be located on the 'floor'. Still it is likely that more work is needed on this auto-ranging system. Regarding the noise of the sensor. It should be investigated how best this can be reduced. With the current flow-level while a prominent peak is seen at the water velocity, other noise associated peaks are seen elsewhere. This will inevitably reduce the accuracy of the sensor as it will sometimes regard one of these noise peaks as the measured velocity.

29th July 2021

The acconeer SDK was downloaded which allows development of applications on the STM32G071 integrated on the XM132. This is useful as we modify the functionality to also perform the majority of the signal processing on the the STM32G071 which is both faster running at 64 MHz, and has much more RAM, 36 kB as opposed to the ATmega 2 kB. This allows much more radar data to be stored and thus processed simultaneously. This is beneficial as it lessens the need to the 500 mm range of interest system, which would have been needed for an implementation entirely on the ATmega (recall that the power bins were first scanned to see which had the greatest reflection) a system like this will no longer be necessary. The first step to getting this working was to mimic the functionality of the acconeer supplied radar module server. In other words writing some code which accepts commands over UART and converts these to actions on the radar module. The set of commands used were identical to those used by the radar module, therefore the software is interchangeable with the software supplied by acconeer (mostly some functions are unimplemented to save on development time).

An issue was encountered that the radar firmware did not allow for arbitrarily long radar sweep lengths. The internal buffer appeared to be limited to 4 kB. This effectively means that the sweep length is capped at 1920 mm. Still a large improvement over the previous 500 mm, however. In addition there remains enough free memory to collate the multiple 1920 mm runs. This is different to what was done with the ATmega as all the data can be processed simultaneously. This system was able to be gotten preliminary working. That is the two services could be set up a measurement made, and then the data could be returned in a contiguous block over serial. This still needs some work, for instance the two data buffers from either service when concatenated are not ordered properly for the current FFT algorithm to work.

5th August 2021

The above work with storing the results in the two arrays was implemented. Indeed it turned out that this was the only way to get the data out, as deactivating a service destroys the data in it. The memory footprint is very mandible for the size of the arrays worked with. Once issue noted was that when started a measurement at a far distance from the sensor >1m the first data point looks low, that is that it looks like it has a very weak reflected signal compared to the other sweeps. Additionally the value it returns stays constant regardless of what is occurring in-front of the sensor. A hypothesis is that the reflected radar signal was not yet reached the sensor at the time this measurement was taken as the radar sensor has just been turned on. This could be tested buy perhaps making two measurements and then looking only at the second one. This may turn out not to be a significant issue. Some investigation on how this affects the FFT output will need to be done to test this.

15th August 2021

Output capture of radar velocity sensor. Top: time-distance raw data from sensor. Middle: distance velocity data as calculated from raw data on local computer. Bottom: distance-velocity data as calculated by xm132

It was determined that the weak reflected signal did not majorly affect the fft output especially considering that this data is scaled close to zero in the FFT windowing. A Gaussian filter was then coded up in the xm132 firmware to provide a bit of noise reduction and smoothing to the distance-velocity data. This Gaussian filter was implemented by using separating the 2d gaussian kernel into the outer-product of 2 1d gaussians kernels (also Gaussian). One of these gaussian kernels was applied across the rows and the other was apply across the columns. This data is now largely gives good information about the velocity information recorded by the sensor. A screenshot of the output of the sensor is shown on the left. It is seen that the xm132 and local computer produce very similar velocity-distance graphs. This is good verification that the data analysis implementation on the xm132 is working as intended. Note that the scale difference between the two distance-velocity graphs is due to different conventions used in the fft on the computer and xm132 and is not of much significance. Once important feature needed in the velocity sensor is the ability to differentiate between between two measurements and low signal measurements. One way to do this is via the amplitude as good measurements will have stronger reflected signals. However another way to do this is via the spread of the data. A velocity-distance distribution with all the data focused in a central point is typical in good measurements and those with data spread widely over the velocity-distance surface are more typical of random noise. I have attempted to calculate the standard deviation of the distribution to calculate this however this didn't discriminate between the two scenarios as very well. Currently some other measures of spread are being investigated for which works best. I believe one of the reasons the standard deviation does not differentiate very well is that even on strong measurements there is still a background signal roughly equal to the background signal on a noisy measurement. Additionally, the peak does not have a very large 'mass' about 10x the noise level. Hence its affect on weighting down the standard deviation is less than expected. I suspect any measure of spread which works well will need to take this into account.

19th August 2021

A solution was found to the measure of spread issue. The solution was to only calculate the measure standard deviation on the points which had a value above half of the maximum. An example image of this concept is shown below.

Spread Algorithm explaination. Top left: Random Noise data. Top right: noise + signal bump. Bottom right: noise data > 50% of max. Bottom left: noise + bump data > % of max

In the image the random noise represents the typical noise signal expected on the radar sensor. When this is run through the 50% level we expect the remaining points to be distributed broadly across the plot. This is because noise is uncorrelated. Hence when a standard deviation is measured. It returns a large value. However if some signal is present in the image when the 50% level is taken the points above this level should mostly be close the to signal center. Since the signal data is correlated in this way. When the standard deviation of this data is taken. Most of the remaining points are close to the peak so a smaller value is returned.

In testing this algorithm It was found that for a peak of amplitude ~2x the noise the worst case seen was the output standard deviation was twice as much as the standard deviation calculated on the data with the signal. Hence this test provides a good indicator of if the signal is noisy.

This will now be implemented in the XM132 firmware.

Having implemented this into the XM132 firmware. This firmware is now mostly complete. Further updates may come about as issues and ideas are found. However it is worth uploading this to the radar modules and being building radar sensors to test. I have made some of the variables in the data analysis modifiable at run-time by writing the the UART registers. This enables various different sub-routines of the data evaluation to be turned on and off, and some threshold values adjusted. This will help as it will allow the settings to be tweaked as found necessary without re-uploading the firmware.

26th August 2021

Today we have received the rev 0.1.1 versions of the radar velocity pcbs. These sensors already have a boot-loader preinstalled so are able to be uploaded from the Arduino IDE with the ATmega328PB bootloader out of the box.
The accelerator was verified to be in a working state.
The soft-start power switch as also verified. A 12 Ω resistor was placed between the switch output and ground and the switch was turned on. It took the switch 3ms to rise and in which time the ATmega328p did not reset itself. A plot of the switch rise is shown here:

• 

  radar switch rise time

It was also verified that all the UART and reset connection are working on the tri-state buffer which connects the ATmega328P to the radar velocity sensor.
A note for future revisions is to put the power and tri-state buffer enable on different pins to allow for easier programming.
The XM132 was then soldered onto the radar PCB. The best way found to do this is to add some solder to all the pads on the XM132, then add flux then place it onto the radar PCB. Applying a soldering iron to the exposed pads on the PCB solders the two components together
The next task was to burn the firmware onto the XM132. This proved more difficult than desired as we do not have a direct connection to the XM132 SWD (the reset pin is always pulled high or low by the arduino and hence we cannot reset it wit the J-link). It was tried to upload over uart through the ATmega328p however this also was had some difficulties and ultimately didn't work.

27th August 2021

Today we will continue working on how to upload the firmware to the XM132 while mounted to the radar velocity board. First we will test uploading through SWD, however to circumvent the reset constantly being pulled high by the arduino we will connect the reset pin to the an input on the arduino. We will then upload a script to the arduino to change the value of the reset pin connected to the XM132 based on this input.

Using this method the debugger is able to connect to the XM132. The firmware can then be uploaded to the XM132. For reference we are using this File:Radar velocity firmware.zip firmware. Once this is done the some issues needed to be fixed with the serial data such as the ATmega not receiving characters correctly. However once the baud rate was taken down to 57600. The device started functioning correctly again.

After much trying a good way to upload the firmware to the XM132 via UART was not found. The programmer could not connect to the XM132 for a reason I wasn't able to diagnose. We will thus need to upload the firmware via SWD. This will thus limit us to not being able to upload the firmware once the devices are potted in gel.

The firmware was tested in combination with the radar velocity board. After some bug fixing relating to different timings experienced between the computer and XM132 it was found that the the velocity and distance was able to be read out. For instance when the a hand was waved above the module. One issue which did crop up however was that long sweep lengths did not work. The velocity information would return zeros apart from the distance which would return 65 meters. The highest tested working sweep length was 1500 mm. I will need to investigate why this issue is occurring when we put the XM132 with the ATmega.

7th September 2021

The issue with long sweep lengths was fixed. This was caused by an error with the value set for the hardware accelerated averaged samples register. The power consumption was also verified. In full operation with the Radar on the system drew 55mA. When the radar power switch was set low and the ATmega328pb put to sleep the sleep mode current draw was about 300 μA. The remaining boards will now be assembled.

The firmware file used uploaded to the XM132 is available here File:Radar velocity STM firmware rev1.0.0.zip. This is uploaded via SWD with the following script uploaded to the ATmega File:Radar Velocity STM resetremap.zip

Hardware rev 1.0.0 updates

Based on the learning from rev 0.1.1 the following changes have been made to rev 1.0.0

• The tri-state buffer is not enabled with pin 7 on the ATmega, with the radar power switch remaining on pin 6.
• The CTS-RTS jumper for the XM132 is now default closed.

8th September 2021

One of the sensors made yesterday is now being tested in an inclined pipe. The sensor has been installed in the 3D printed case with the 3D printed radar lens. It has been placed a vertical distance 800 mm above the pipe and a hose pipe was used to flow water down the pipe. The pipe was inclined by 500 mm. The sensor was able to detect the water flow when placed at a range of angles of declination from the flow however a declination of 60 degrees from the pipe flow seemed to work best. The velocity recorded was quite variable +-100 mm/s difference in the measurement however some readings were at 100 mm/s. Interesting when the velocity resolution was doubled this reading became 50 mm/s. It is suspected that this is due to some sort of leakage in the lowest velocity bin. Perhaps it would be beneficial to introduce some sort of configurable band-pass velocity filter to mitigate this issue.

Below is the data table for the data collected with the rev 0.1.1 sensor. Some notable changes from defaults were that the register 0xD5 was set to 2000, and register 0xD7 was set to 3. The SWEEP_RATE was also reduced from 2E6 to 1E6 and the HW_ACC_AVE_SAMPLES increased to 50.

Angle (deg)	Velocity (mm/s)	Distance (mm)	Amplitude (arb)	Spread (arb)	Height (mm)	Pipe Inclination (deg)	Angle Corrected Velocity (mm/s)
70	312	1020	6400	20	200	8	624
72	317	1020	6300	20	250	9	634
74	341	1020	6400	8	300	11	681
76	405	1020	6800	4	350	13	810
78	420	1020	5200	37	400	15	840
80	440	1020	6500	31	450	17	880
82	434	1020	6700	41	500	18	868
85	469	1020	6500	29	550	20	938

The angle measure is the angle from the horizontal as measured by the onboard accelorometer. For the velocity, distance, amplitude, and spread measurements. 3 readings were recorded from the sensor. The velocity is given as the average velocity of these measurements. The distance measurement changed insignificantly between measurements and so was recorded directly. For the amplitude and spread the maximum returned value of the three measurements was recorded. The height column gives the height that the far end of the pipe was elevated.

From the data of the pipe inclination and the sensor angle we may conclude that the sensor was pointed at about 63 degrees declined from the water flow. We can use this to correct the Doppler velocity. (NB the pipe was remeasured and its length was actually 1440mm, not 1500mm as assumed in this analysis)

Below is a graph of the slope of the square root of the slope of the pipe against the velocity measured. Assuming gravity is the only force acting on the water. This graph should be linear with intercept zero.

linear correlation plot

The linear trend has an R² value of 0.95 and the linear trend line is within the error bars of the data. (The error bars were calculated as half the width of one bin). Additionally the y-intercept is quite small. All these point towards that the sensor is working effectively to measure the velocity of the water in the pipe. However it is noted that some improvements might be attainable by further tweaking various parts data acquisition and processing setup.

23rd September 2021

To enclose the sensor some more test cases were printed. Different sizes for the front thread were tested to see which was the most waterproof. I have also updated the radar board again to the rev 1.1.0 which added a larger soldering header for the TTL cable.

29th September 2021

A further change has been made in the rev 1.1.1 design the FPF1038UCX power switch has been changed to the SIP32508. This was done for ease of soldering and durability reasons. The two power switches should perform similarly.

More testing has been done to try and find a good attachment method for the front lens on the radar sensor. This partly tweaking the 3d print design to create a better thread fit and also to tests sealants between the lens male and female thread. So far the following have been tested:

• Automotive grease
• PTFE tape
• none

all three of which had issues with leaking after a short period of time ~ 1 hour.

7th October 2021

It was found that some potting compound placed between the thread and the body worked well in preventing leaks over a timescale of days. Some final tweaks were made to the radar velocity case including adjusting screw hole diameters and tolerances. A instruction set on how to construct the sensor will be posted soon...

21st October 2021

Video of installation site

• 

  Radar sensor installation at old joes creek

A sensor was installed in the field at Old Joes creek together with a hach velocity sensor in a field test. The radar sensor has been connected to a BoSL datalogger which is uploading as OJ_RADAR_TEST approximately every minute. Specifically we are working with the rev 0.1.1 sensor. Data will be collected weekly from the hach sensor weekly, and will be posted here.

26th October 2021

• 

  radar velocity field test week 1

• 

  radar velocity field test week 3

It would be interesting to test how applying a Kalman filter to the data affects the velocity reading.

On the side here we have the plots of the week 1 data. Specifically we have from top to bottom radar velocity, hach velocity, radar depth, hach depth. The initial observations tell us that the velocity sensor is working as it is as the events between the two sensors seem to be correlated, however there exists significant noise present. It is suspected that some of the velocity readings for the of the hach sensor are anomalous as there is no change in water depth when this occurs and the events are not very continuous. The radar depth performance seems also at a first observation to perform well. One noteworthy point is that the chaotic depth measurements of the radar sensor on the 23rd of October are likely due to the sensor being submerged in the water at this point. The radar velocity measurements seem to be quite noisy so I think there is some work to do here on how best to pick out the velocity from the frequency domain plots.

NOTE: On 15 November 2021 at about 12:00 to 16:00 AEST another logger was logging to OJ_RADAR_TEST thus this data needs to be filtered out. It will probably be easiest by battery level.

28th October 2021

Looking at the data from collected this week it would be helpful to collect the full phase space portrait. To do this we will implement a way to slowly pass the buffer (of size about 4k and so too large to be stored in an ATmega328) to the SIM7000 where it may be uploaded via FTP or other means. That is the chain will look like XM132 -> radar sensor -> bosl -> sim7000. This is quite a long serial chain and so we need to perform a few handshakes a long the way to ensure that the signal is not having any information getting lost. To do this we will need up update the firmware of the XM132, radar sensor and bosl.

First we will get the XM132 -> radar sensor step working. After some code rearrangement this was able to be accomplished. The radar sensor -> bosl step was also completed. Now just remains the bosl -> sim7000 step.

6th November 2021

We now need to figure out how to get the FTP system working on the sim7000. The first step to this is to figure out how to write files to the sim7000 internal file system.
This can be done as follows

AT+CFSINIT
AT+CFSWFILE=2,"filename",append,size,timeout
file data

AT+CFSINIT initializes the file system
AT+CFSWFILE opens the file "filename" to be written to. The append option changes whether the file is appended to (1) or overwritten (0). The size of the data sent to the file should be sent in size, and all the data to be written should be sent within a time of timeout ms. Once this command is sent the word DOWNLOAD is returned by the sim7000, and the file contents should now be sent to the SIM7000 over serial.

The AT+CFSRFILE can be used to read the file.

Now to move on uploading this file via FTP. There does not seem to be an easy way to upload data directly from the SIM7000's flash memory via FTP, so it will have to be copied out in stages and gradually uploaded.

To enable an FTP transfer first

AT+SAPBR
needs to be run to activate the bearer. Then:
AT+FTPPORT
AT+FTPMODE
AT+FTPSERV
AT+FTPUN
AT+FTPPW

Can be run to set up the TFP connection. To set the file path of the upload

AT+FTPPUTNAME
AT+FTPPUTPATH

Can be run, once this is set up

AT+FTPPUT

Can be run and then the upload data can be streamed to the sim7000 and the file should upload to the FTP server.

It has been found that instead of writing the file to a flash buffer using the AT+FTPEXTPUT=1 mode allows the file to be uploaded to be streamed into ram with AT+FTPEXTPUT=2. A simple call of AT+FTPPUT=1 will then upload the file. Using AT+FTPPUTOPT="STOU" will upload the file in the root directory of the ftp server with a name "pureftpd.xxxx". The xxxx is the unix timestamp in hexadecimal.

15th November 2021

The CAD files for the radar case are provided in the zip file: File:Radar-case.zip

22nd November 2021

Acconeer released their v2.9.0 version of the SDK, this includes improvements such as better handling of strong reflections and experimental extended range for space of 12.4 meters. It will be interesting to see if this means that we no longer need to stitch two space readings together, as this will significantly reduce measurement time and power. Unfortunately the sparse buffer is still limited by the 4kB size, which we have already maxed out, so we will have to continue using our current solution.

23rd November 2021

The versions of the radar firmware and bosl logging code which were used to just log the radar data and log the raw radar data were unified into a single code base. To change the mode of what the sensor logs can now be done by setting the VERBOSE flag in the bosl logging code. I have also added a mode to take the average of 6 readings.

24th November 2021

The Kalman filter has been implemented in python, currently the model being used is inertial, that is that the filter assumes that the velocity will change according to the current rate of change. As more data comes in the Kalman filter updates this this estimate of the velocity and the rate of change of velocity. The measurement of the rate of change of velocity is given by the change in velocity between the previous two measurements.

29th November 2021

I turned on -03 optimization on the during the compilation of the FFT algorithm and the radar signal processing. This gave a 3% speedup, which is not very much, but since this is the longest part of the velocity reading it still good to have.

30th November 2021

The envelope system was able to be gotten working and making measurement. However the current issue is had with interpreting the data. The documentation is not very detailed on how the data should be interpreted. The python script used to interpret the data is working with the firmware supplied by Acconeer. This means that the error is likely somewhere in the transmission of the data in our firmware. And indeed this issue was just resolved as a typo in the code.

The the raw data can be returned by the envelope service, however as with the velocity it is useful for the STM32 to do some of the processing. For the proccing we will find the 4 largest peaks and return these. This gives us the opportunity to filter out the ground if this is an issue. To find the peaks we will set a blanking distance where if a peak is found no peaks can be in this range.

With the added envelope service for distance measurement and the peak finding algorithms the binary size comes in at 123 KB, and so just fits within the 128KB available on the microcontroller!

The firmware with the envelope (distance) functionality was tested and all the commands seemed to work out. This was released as version 1.4.0. It still remains to be tested how well it is able to detect water.

In further work to minimise the time taken to process the sparse (velocity) date some profiling was done. It was found that the FFT took up 1.2 seconds of the total 1.5 spent in data evaluation. Thus efforts should be focused on improving the FFT time.

3rd December 2021

The rev 0.1.1 PCB's are 1 mm longer than the rev 0.1.0 to accommodate the extra soldering pins. The radar case needed to be slightly adjusted to add a bit of room for this. This was done by decreasing the lip width on the backplate where they interfered with the PCB

6th December 2021

For future reference here is the collection of the radar and BoSL firmware without distance logging: File:Radarfirmwarenodist.zip

7th December 2021

Some work was done on a mount for the radar sensor, the first idea was to use a ball and socket joint which could be secured by a set screw. The ball and socket part of the joint worked well with the ball clipping nicely into the socket, however the set screw part did not work as nicely. This was essentially because the spring-ness needed in the side clip to insert the ball into the socket also caused set screw to open up the socket when tightened. Hence not clamping down on the ball very hard. The next idea was to use a collet.

• 

  Ball-socket and set screw top view

• 

  Ball-socket and set screw side

The rev 0.1.1 radar pcb's were also verified to be working. Some improvements were made to the radar firmware to decrease the measurement time. 4 seconds were saved, which represents about a 30% decrease for the 6 measurement average and 80% for the single measurement. The changes to include more detailed depth measurements were also propagated into the code and verified.

Here is the collet. This worked better than the set screw however still needs a bit of tweaking to get the locking very tight

• 

  Ball-socket with collet locking

8th December 2021

Both sensors in the field stopped logging and so were taken back to the lab. The first sensor made OJ_RADAR_6AVE, turn out to have nothing wrong with it. The second sensor OJ_RADAR_FTP, had a 1Ω short between power and ground. When de constructed this sensor had about 2 cm of water behind the lens. The water appeared to come from the seal between the lens and the body. The inside of the cable hole was dry and there didn't appear to be any water coming from backplate. It was also observed that there were some small particles of dirt with the water behind the lens. Some photos below show the state of the sensor:

• 
• 
• 
• 

9th December 2021

The the tolerances on the collet were fixed and now it worked very nicely for locking the sensor. The key change was adding a slot for an o-ring to clip into, this added the necessary extra grip to lock the sensor in place. To resolve the leaking issues with the case future cases are going to be printed at 60% infill (up from 15%) and with 7 shells. The top and bottom set of layers will be printed at 100% infill.

10th December 2021

Some further changes were made the the collet to increase the part width where it was a bit small which increases durability. A metric R22 O-ring is used in the design. It is helpful to put some lubricant on the thread and between the collet and chuck (not the ball socket!) as this keeps the collet from binding while being tightened. This is not essential however and is mostly useful for multiple tightening's and loosening's.

22nd December 2021

After building up 14 sensors, some notes were made on where the constructions could be improved. These include:

• The sensor has to be soldered to the cable after the cable is inserted into the case
• The sensor is difficult to position once soldered (and screw down)
• The cable entry is difficult to waterproof
• When filling the back of the sensor up with gel-gum care needs to be taken to not let this flow into the lens cavity (hot glue is needed)
• The front lens needs a fair bit of time to silicon the thread and waterproof, while making sure not too much silicon is added leaking into the lens cavity

These points should be addressed in an iteration of the design.

14 January 2022

Some improvements were made the radar case design. A render of the new design is attached in the galley below. These changes include:

• finer threading on the lens for (hopefully) increased waterproofing
• o'ring seal for lens
• radar cable now in main cavity (ie radar sensor with pre-soldered cable can be installed)
• pcb retention mechanism changed to clips + 1 optional screw
• plastic skirt around A111 sensor to reduce leakage of gel-gum into lens cavity
• sensor cable retention clip to reduce leakage of gel-gum out of cable exit point
• backplate secured with clipping mechanism

My main concerns with the new design are that the changes to the lens cavity to accommodate the o'ring seal may affect the radar performance (although the current solution with silicon may also leave pieces of silicon in the lens cavity, so this too is imperfect).

• 

  o-ring seal and lens

• 

  top without pcb

• 

  top with pcb

15th February 2022

Today we will be testing the radar sensor in the lab for both distance and velocity measurements. The sensor is supported at a variable height range (0 to 3 meters) above a horizontal half pvc pipe, water is flowed through the pipe and we will measure the velocity and distance output by the sensor. The angle of the sensor has been set at 80 degrees from the horizontal. This is to replicate conditions in sewers (3 m deep, 1 meter diam, we assume that the line of sight can only do across 500 mm to allow for good tolerance in installation, etc...)

This experiment will be continued later. While setting up two sensors which were both sitting face up on the table. The difference between the reflected signal strength measurements was quite different. To investigate this phenomena 6 sensors were sampled with the same setup. The following was noted: working sensors ranged in max amplitude from 10000 to 15000 (arb). There were two reflections present in the testing one at 1800 mm and one at 2300 mm likely the ceiling and ground level of the next floor. The 1800 mm reflection was ranging in amplitude from 10000 to 12000 (arb), the 2300 mm reflection ranged from 4000 to 12000 (arb). Interestingly while the 1800 mm reflection generally stronger this was not always the case for one sensor the 2300mm reflection was stronger than the 1800 mm reflection. I think the conclusion of this is that we may need to do some sort of calibration for each sensor. It is also known known at the moment if the variability stems from the components themselves or the assembly of the sensor.

16th February 2022

It has proven difficult to get the required velocities with the testing setup. We are aiming for velocities above 200 mm/s up to at least 1000 mm/s. The issue is that the flow rates needed from the hose to obtain these velocities cause the water to jet out of the hose and not actually be in contact with the pipe for a significant portion of the run of the pipe. So where the radar sensor is measuring the velocity the water is not in a steady state and running along the surface of the channel. The velocity sensor is able to detect these flows well, however regime is makes it very difficult to get the velocity of the water by another means to compare against the sensor and isnt the type of flow we are attempting to characterise the velocity sensor for.

One way we can get these flow rates without the jetting issue is by reducing the flow rate and therefore also the water depth. This however makes it less certain what the wetted area is, and so gives more uncertainty to the velocity. By some preliminary testing this would require the wetted area do have a depth of only a 1 or 2 cm, which is quite a narrow flow.

• 

  Testing Setup

• 

  Testing Setup

To solve this we can measure the width of the flow, this is better than measuring the depth because the the depth is very insensitive to changes in width at low points. To allow the flow more time to settle we have doubled the length of the channel by adding another pipe: see picture below, the gradient was continued at 1.5%.

• 

  pipe testing setup double length

• On off test at max flow rate

The maximum flow rate of the system is about 1.5 L/s.

17th February 2022

To achieve the 75 to 80 degree angle required for the test the drop in the cosine requires a lower sampling frequency. I'm not sure what sampling frequency is best and what combination of angle/sampling frequency gives the most reliable measurements. I'm going to sample some of this matrix to get a better idea of the behaviour of the sensor.

Experiments were done sweeping the velocity at a given angle sampling frequency and height. To begin the script setting the sample frequency was uploaded, the sensor angled, and then hoisted up to the correct height.

The flow rate through the testing setup mentioned yesterday was set by adjusting a valve.

1. The water valve was turned on and water was allowed to flow through the system for a few seconds. 
2. A bucket of known volume (55 L) was placed under the outflow of the pipe, a stopwatch was started and the sensor recordings were started.
5. The depth of the water present was measured using an arc length method. That is that the pipe had marking of circumferential distance, the two distances of the left and right side of the water flow were recorded and subtracted to get the arclength of water, this can be used to calculate the depth and area with a bit of trigonometry.
3. Once the bucket filled to the 55 L point, the stopwatch was stopped and the sensor was made to stop recording.
4. The flow was then stopped.

The testing setup needs some adjustment. Velocities from about 0.6 to 2.5 m/s were achieved, but the velocity was rather insensitive to the flow rate, with little dependence of flow rate on velocity seen until the very high flow rates. Thus most measurements taken were from 0.7 to 0.9 m/s. It also seems that this method of determining the velocity had a reasonably large uncertainty.

22nd February 2022

The data received from the sensor when plot on a graph of distance on the y-axis and time on the x-axis is shown in the galley, also shown in the galley is the data when transformed to the frequency domain, distance on the y-axis and frequency on the y-axis. I am going to take the RMS average of all the frames for each experiment trial. From these plots I will record the frequency and distance bin of the highest signal strength point. This will give a quick first estimation of how the velocity sensor works in each of the different regimes tested.

• 

  raw data from radar sensor flow testing

• 

  fft data from radar sensor flow testing

Attached are the results of the experiments: File:Velocity testing results.xlsx

23rd February 2022

After doing some error calulations the velocity calculated via the depth measurement method is has a very high uncertainty. I will still include these on the graphs of velocity vs flowrate however this needs to be considered when looking at the graphs. The graphs below are plots of velocity vs flowrate for the different test series, the red line indicates the Nyquist velocity of the radar sensor, that is the maximum velocity after which higher velocities will begin to decrease the measured velocity.

• 

  radar series 0

• 

  radar series 1

• 

  radar series 2

• 

  radar series 3

• 

  radar series 4

• 

  radar series 5

• 

  radar series 6

• 

  radar series 7

• 

  radar series 8

• 

  radar series 9

Test Series	Angle (deg)	Sampling Frequency (Hz)	Height (mm)
0	80	250	3000
1	80	500	3000
2	70	500	3000
3	70	250	3000
4	70	1000	3000
5	60	1000	3000
6	60	250	3000
7	60	250	1500
8	60	1000	1500
9	70	1000	1500

From these graphs we can make a few conclusions. 1. is that the angle of 60 degrees does not work very well when at a 3000 mm distance but seems to work better at 1500 mm. 80 degrees seems to work okay, however it seems the readings jump around more than the 70 degrees which seems to work a bit better. These tests advocate for a radar sensor angle somewhere between 70 - 80 degrees to have good performance over a wide range of distances. The sampling frequency should be adjusted to meet the maximum expected velocity, but didn't seem to have a major effect aside from this.

27th February 2022

It is also of interest to see the recorded velocity based on not taking the PSD but rather averaging the peaks of each frame. Performing this analysis it seems that doing this performs mostly similarly however it sometimes causes large overestimations at low flow rate and tends to has an aversion for very low or high velocities. These results extend to when an average of just 6 measurements are taken and also when convolution is applied, as is currently being performed on the radar sensor.

There are many install time DSP parameters which have yet to be tweaked. Using this dataset may be a good opportunity to perform such tweaking. Specifically we will use the data-series 0,1,2,4,8,9.

To do this we will compile the current c code used on the radar sensor to target my local machine. These data series can then be fed into the algorithm and the output can be readout and compared.

1st March 2022

Having done this and played around with the parameters a little, it seems that the parameters used in the attached photo perform the best. In particular the null thresholding helps quite a bit with reducing the high reading at low flow rates.

• 

  Series parameters multiple

5th April 2022

Further tests of the velocity sensor were done in a small teaching flume. This flume was able to achieve velocities in the range of 0.1 - 1.5 m/s, an attached flow meter is able to measure the flow rate (when compared against a volume-time measurement at low flow rates it was quite accurate), and two rules printed on the side of the flume allow the water level to be measured at different depths. For these tests the sensor was mounted at about 800 mm above the water level and at an angle of 75 degrees from the horizontal. The measurement was taken through a layer of Acrylic 10 mm in thickness. A plot of the results are provided below, data from the radar sensor was converted to a velocity via the algorithm native to the sensor. That is the average peak position from 6 measurements were used in the velocity calculation. The error in the radar measurement was taken to be one bin width and the error in the calculated velocity was propagated from estimated errors in water level, channel width, and flow rate. It is noted that at low water levels this caused a very large uncertainty in the calculated velocity. In future trial the water level should be increased while maintaining a moderate flow rate when achieving low velocities, thus mitigating the uncertainty.

• 

  Correlation plot from small flume test

The graph shows that the radar sensor is able to perform good measurements of the water velocity, particularly at higher flows. The line of best fit has a R^2 value of 0.94, but it has a gradient of 0.74, this is a bit low. Some of this may be due to that the sensor's angle is not exactly 76 degrees as measured, the angle of the sensor only need be 80 degrees before the gradient is above 1. Furthermore the water level is slightly sloped in such a way to increase the effective angle between the sensor and the water surface, this tilt is only on the order of an extra degree however. Some further difference in the gradient could also be due to difference in the velocity of the peak vs the velocity of the fastest surface, or perhaps some error in calibration constants. The high correlation coefficient for the linear fit gives confidence that the sensor is able to accurately measure the velocity even if a linear calibration curve is needed to fix the gradient offset. Most of the measurements at measured velocities greater than 0.5 m/s fall on the line of best fit. At velocities below 0.5 m/s a greater error is seen in the measurements and below 0.3 m/s the radar readings seem to plateau to a minimum measurement of 0.3 m/s.

6th April 2022

Current measurement tests were attempted for the different power states of the sensor. Using an oscilloscope to get the current-time curve for each operation (measurement, idle, dsp) was attempted. To do this a 0.5 Ω shunt resistor was placed on the ground return path and the oscilloscope probe was measuring voltage over the shunt resistor. This work alright, however the small shunt resistance and abundance of ground noise caused the SNR to be a bit too large to make good measurements of the current. Using a larger shunt resistance would alleviate this issue.

13th April 2022

With a 5 Ω shunt resistor the tests can now be conducted. Below is a table of measured currents in different power modes:

Mode	Peak Current (mA)	Time (ms)	Charge (mA.s)
Power-on-idle	14	--	--
Radar-on-idle	10.2	--	--
Acc-on-idle	13.4	--	--
Radar-acc-on-idle	10.2	--	--
Radar-off-idle	4.76	--	--
Radar-off-sleep	10 (µA)	--	--
Sparse-measurement(2000mm)	58.2	342	16.6
Sparse-measurement(3800mm)	58.2	342	16.6
Sparse-measurement(1000mm)	59.2	179	7.52
Sparse-measurement(100mm)	59.2	179	7.52
Sparse-dsp(2000mm)	64.6	1296	70.4
Sparse-dsp(3800mm)	63.4	2060	112.8
Sparse-dsp(1000mm)	63.4	714	39.8
Sparse-dsp(100mm)	63.4	339	17.6
Envelope-measurement(2000mm)	61.8	341	14.2
Envelope-measurement(3800mm)	64.2	453	20.6
Envelope-measurement(1000mm)	61.4	255	10
Envelope-measurement(100mm)	59.4	200	6.8
Envelope-dsp(2000mm)	61.8	346	15.4
Envelope-dsp(3800mm)	63.6	458	22.3
Envelope-dsp(1000mm)	61.8	309	11.6
Envelope-dsp(100mm)	59.8	228	8.2
Typical-measure	63.4	8520	424

Power-on-idle: Power is applied to the radar sensor with no Arduino script running
Radar-on-idle: The Arduino script idles after powering on and initialising the xm132
Acc-on-idle: The Arduino script idles after powering on the accelerometer
Radar-acc-on-idle: The Arduino script idles after powering on and initialising the xm132 and accelerometer
Radar-off-idle: The Arduino script idles explicitly powering off the xm132.
Radar-off-sleep: The Arduino script goes into powerDown after explicitly powering off the xm132.
Sparse-measurement(x mm): A sparse measurement with a sweep length of x mm.
Sparse-dsp(x mm): A sparse digital signal processing with a sweep length of x mm (also includes 1 measurement).
Envelope-measurement(x mm): An envelope measurement with a sweep length of x mm.
Envelope-dsp(x mm): An envelope digital signal processing with a sweep length of x mm (also includes 1 measurement).
Typical-measure(x mm): A typical measurement consisting of 6 2000 mm sparse measurements, an envelope measurement, and the associated dsp.

Learnings: The open sensor needs to be closed and deactivated (reg 0x03 val 0x00) in order for the radar to turn off the radar sensor (which draws significant current) this can only be done after all the data is read from the sensor.

27th April 2022

Also of interest is how well the radar velocity sensor is able to measure the volumetric flow rate. Data from the small flume tests was used to calculate the sensor's flowrate by multiplying the sensors's velocity, the sensors depth measurement, and the known channel width. This was compared against measurement of the flow rate via the attached flow meter on the small flume. Below two graphs are displayed, one with all three sensors plot, and the other comparing just sensor B.

• 

  Graph of flume measured flow rate vs radar measured flow rate for sensors A,B,C

• 

  Graph of flume measured flow rate vs radar measured flow rate for sensor B

It is seen that the measurement of radar flow rate is generally quite poor, this is due to the large amount of error seen at flow flow rates, (likely a compounding of the sensitivity to small changes in water depth, and the velocity readings tend to become non-linear at low velocities). If sensors A,C are excluded as in the second plot to focus just on sensor B, then a significantly better relationship is seen, the correlation still could use improvement at R^2 = 0.59. The gradient is 1.4 and the y-intercept is 8.8 L / min. Particularly large error is seen here in the higher flow rate region. It is encouraging however that the general trend of the data is linear.

5th May 2022

In the gallery are graphs of the three sensors velocity and depth performance from the small flume test. Note that the depth and velocity data are not from the same test series. The depth performance of sensors A and B are quick good with C a bit further off. The gradient of sensors A,B are within 2% of unity and they both have a high R^2 value. It is observed that the linearity is maintained throughout the whole measurement range. For the velocity data sensors A and B are again best performing. The gradient of sensors A and B are within 6% of unity and y-intercepts with in 0.1m/s. The linearity suffers below 0.3m/s where the linear slope tends to flatten off.

• 
• 

We also have data from the Hach sensor at Old Joes Creek. This was turned around to face downstream and is now giving much better data a weeks with is plot here:

• 

  Hach velocity and depth data from old joes creek

The data is looking much better now with no discontinuities or gaps present. It should act as a suitable point of comparison for the radar sensor we intend to install.

11th May 2022

The velocity data uploaded directly to the logging website did not look very good, it was essentially uniform random noise. The FTP data however was able to be processed into a good signal so it is assumed that the error their is an error somewhere in the uploading chain. This will need to be tracked down. Taking the maximum of the velocity readings within 10 minutes seem to do a good job of cleaning up the data. Using a kalman filter further smooths the data if this is desired. A video of the raw sensor data over the week is provided below. The raw sensor data is also provided below in an excel file. I have just included the sweep at the depth for which the signal was strongest (columns K to AP) column K being zero velocity and column AP being ~ 1.6 m/s.

• 

  comparison of hach and radar ftp data.

• 

  radar velocity data filtered by taking maximum reading over 10 minutes

• 

  radar velocity data further filtered by taking kalman filter

• video of ftt sensor data. x axis velocity y axis depth

• 

  Raw radar data from old joes field trial

19th June 2022

Some new data was received from the testing of the sensor at Troup's Creek wetland. A few different methods of processing and averaging the data were tested. The results are provided in the gallery below.

• 

  A

• 

  B

• 

  C

• 

  D

• 

  E

• 

  F

Algorithm	averaging	velocity detection	nulling
A	mean of 6 raw data frames	weighted average	max/3
B	mean of 6 raw data frames	peak	none
C	rms of 6 raw data frames	weighted average	max/3
D	2/3 memory decay	weighted average	mean
E	2/3 memory decay	weighted average	max/3
F	none	weighted average	mean

Based on these the weighted average looks like quite a promising method to extract the velocity when using max/3 nulling. A mean of 6 frames taken via the rms seems to be sufficient to get a decent velocity reading.

20th June 2022

Here we examine some of the algorithms in more detail, specifically we also look at their correlation with the HACH velocity and perform a linear regression between the two datasets.

algorithm	averaging	data	nulling	velocity estimation
	6 frame rms	peak bins	max/3	weighted mean
	12 frame rms	peak bins	max/3	weighted mean
	3 frame rms	peak bins	max/3	weighted mean
	6 frame rms	peak bins	average	weighted mean
	6 frame rms	peak bins	max/3	peak
	2/3 memory decay	peak bins	max/3	weighted mean
	2/3 memory decay	whole frame	max/3	weighted mean

From these trials a few factors can be seen as being most important. a) sufficient averaging is needed. Both the rms averaging on at least 6 frames and 2/3 memory decay averaging seem to perform well. b) There is little difference between performing the data analysis on the whole frame vs just the peak bin. c) nulling out data which is less than 1/3 of the maximum appears to work better than nulling data which is less than the average. d) taking the velocity as the weighted mean of the power spectrum works better to taking the velocity as the as the peak of the power spectrum. The R^2 value of the correlations peaks at about 0.5 - 0.6, the gradient falls within 0.95 - 1.05 and the intercepts are at about -100 mm/s. One limitation of this trail is that the velocities tested peak at around 700 mm/s.

For testing at Troup's creek we have decided on 6 frame rms, only using the peak bins, nulling at max/3 and estimating velocity from the weighted mean. This program was uploaded on the 21st of July 2022.

5th September 2022

While the FTP upload of the radar data from the sensor at troop's creek is working well. The onboard algorithm to process the data is not. 2 issues were found. The first was that the weighted mean of the velocity power spectrum was not being computed correctly. This was due to an issue with integer overload, and was easy to correct. The second issue was that the onboard FFT algorithm on the FFT did not seem to be working properly. Taking the raw frame and computing the FFT gave quite different results to computing the FFT onboard. The exact reason for this is not know however it is a bit difficult to diagnose as the firmware on the XM132 is not upgradeable on the constructed sensors.

6th September 2022

It was discovered that the version of the firmware uploaded to all the currently assembled and water-proofed sensors was has a critical error that the FFT does not work. This version uploaded is not a tagged version but comes from the repository https://github.com/Monash-BoSL/xm132-radar-firmware/commit/80ee75d52b1e881cb25bf2305bb9fec337c77c82 and is compiled on 2021/11/30 at 16:05:58. Due to this error for the waterproofed sensors to be viable, they will need to be stripped of their waterproofing, have their xm132 reprogramed, and then waterproofed again.

To prevent this sort of thing happening again. I am going to make a comprehensive test program which will automatically verify that the sensor code and algorithms are working

8th September 2022

The radar firmware for the atmega was updated to be compatible with the xm132 updated and will be released as version 1.6.1. Some lab tests with an aluminium foil ball reflector indicate that that the onboard algorithm is providing equal results to the off-board analysis. As the XM132 firmware is quite difficult to change once in the sensor, a lab flume test should also be conducted. This will be similar to the previous tests however the velocity data will be recorded directly from the sensor's output. It was also found that the lab flume had a volumetric tank for an additional way to compute the volumetric flow rate in the trials. Today the lab flume was setup again and filled with water.

9th September 2022

The radar velocity sensor was again quickly tested in the teaching flume. A similar method was used to previous tests, however the velocity reading from the radar sensor was processed onboard using the firmware which will be loaded on all the velocity sensors currently under construction. This is firmware 1.6.2. Below is a graph of the results found. Overall the correlation is quite linear, however the gradient is a bit off, it is 0.62. This might be worthwhile to investigate in the future, but for now so long as this gradient is known it can be compensated for. The firmware is provided here File:Radar-velocity firmware rev1.6.2.zip

• 

  onboard velocity results for lab flume test of firmware revision 1.6.2

12th September 2022

The teaching flume was used for batch testing of a sensor programmed during assembly. This was done to ensure that a working program was completed had been flashed onto the sensor. The results can be found below:

• 

  v16 flume verification results

The linear correlation is pretty good, but again the gradient is a bit low. Overall this flume testing provides a good way to check that a sensor is working properly.

So that this verification step can be repeated in the future. An excel document and a python script are provided: File:Sensor batch testing.zip

General pieces of advice when running the test in the flume include:

• The Venturi meters should be placed near the water surface.
• To remove any bubbles in the Venturi meter lines the board with the level meters can be moved below the water level. This can also be done if no water is in the tubes
• If the Venturi meter level readings are fluctuating it is likely that the meter is not entirely submerged in the water
• The radar sensor should be angled at about 70 degrees from the onboard angle reading.
• To get a variety of flow speeds the weir should first be fully opened to not restrict the flow. The flow rate can then be adjusted. To get faster flow rates the weir should be placed to obstruct the top of the flow. Adjusting this height with the flow rate will be able to get faster velocities up to about 1.4 m/s.
• Always measure the venturi meter levels and water level from the bottom of any meniscus or surface roughness.
• Ensure that your eye is level with the water when reading off any water levels.

24th October 2022

Here below is the latest data from the troupes creek sensor. The radar velocity data looks good, with it capturing several large rainfall events. The hach velocity however was mostly zero over the measurement period. This radar velocity comes processed directly on the sensor. The depth data correlates very well.

• 

  radar data troupes creek

Alternatively we can look at the HACH sensor placed in the middle of the steam. This has previously shown to have worse correlation with the radar sensor, and the level offset is a bit different but the data is mostly present over the plotting period. It is seen that the response to the flow events are shaped differently but their size and magnitude is similar. This is shown below:

• 

  radar data troupes creek, alternate hach sensor

16th November 2022

Still looking at the middle sensor, this plot shows the a few more weeks of data. We have also clarified the labeling of the plots with now the course depth plot being removed due to it no longer being relevant. We also add a Kalman filtered velocity data series. A good degree of correlation is seen between the events in the HACH and radar data series.

• 

  radar data from troups creek

21st November 2022

Firmware revision 1.7.1 is under testing. In this version I have added a fine depth decoded column to the output. This decodes the fine depth and displays the one closest to the to the course depth. In this way a quick estimation of the depth can be taken directly from the logging data. It remains backward compatible with the previous logging code, however if the old logging code is used. The new depth estimate won't appear in the logs

30th January 2022

A bug was found where Wire.end() was forgotten to be called before going to sleep. After making this change the sleep current reduced drastically to 100 nA. A quick current test was performed to get the new power in each mode:

Mode	Peak Current (mA)	Time (ms)	Charge (mA.s)	Average Current (mA)
sleep	100 (nA)	--	--	--
idle	4.68	--	--	--
measure	64	7020	267.2	38.1

sleep: sleep mode in firmware after measurement has been taken
idle: current with mcu on but accelerometer and radar off
measure: the sparse and fine measurement + dsp for both

These tests also demonstrate the benefit of moving the processing onto the STM32 chip. Charge needed for a single measurement is approximately half of what it used to be and the measurement time is reduced by 1.5 seconds.

3rd February 2022

Some sensors in the field have developed an issue by where the fine depth measurement has avoided values which are a multiple of 60 mm. To determine the cause of this it is first necessary to try and replicate this effect in the lab. To do this a velocity sensor will be set to perform fine measurements and the sensor will be gradually lifted from the ground. The distance from the ground and the measured distance will be recorded. Using this method the issue can be reproduced. At certain distance above the ground the distance measurement will not be constant by it will oscillate between two measurements about 30 mm apart. The physical distance from the sensor at which this issue occurs does not seem to be affected by the sweep start parameter.

6th February 2022

A potential solution was found by changing some of the envelope sweep settings for the XM132. Specifically we change the profile from profile 1 to profile 2, and the number of measurements from 6 to 12. The profile 1 profile 2 distinction changes the radar pulse length. This reduces the resolving power of the sweep, however given that the water surface will often be the dominant reflection, this shouldn't matter too much. As an example of the issues had with the previous settings, and the discontinuities in distances reported, 4 of the returned envelope measurements are reported. The y axis is signal strength and the x axis is the radar distance (mm). Two important features can be distinguished here. The first being that peak has much higher visibility on profile 2, and the second being that at some distances from the sensor the peak signal becomes weaker at certain distances from the sensor. On the new settings however the peaks to not diminish below the noise level and so still remain resolvable.

	profile 1, 6 ave	profile 2, 12 ave
22 mm
40 mm

A graph of the reported distance from the radar sensor versus a relative distance measured by a calliper can be measured for both profile settings. In these graphs the discontinuities of the depth sensing are visible on the profile 1 settings, however the graph becomes much more linear on profile 1. The gradient of the line should not be 1 in these graphs as this has not been corrected for the sensor velocity.

profile 1, 6 ave	profile 2, 12 ave

9th May 2024

The challenge of detecting when a velocity reading is due to low or no signal (the "300mm/s line") is something I have returned to investigating. Originally I had hoped to use the data gathered in the FTP trials at old joes creek in 2021-2022 however, after an initial inspection, I noticed that this dataset does not have a large amount of the nosignal data. The data that is present is quite noisy, so much so that it is difficult to determine the true velocity from it (the hach velocity data is also patchy). One quick change that can be made immediately is to turn on the calculation of spread with a threshold of 0.6. This will calulate the weighted mean square distance of all points above 0.6 of the peak value. The idea here is the spectral power should be distributed in frequency and distance when the signal strength is low (hence high mean square distance), and concentrated in a central peak when the signal strength is high (hence a low mean square distance).

20th May 2024

Today a quick lab test of the ability of the enabled SPREAD variable calculation to discern between valid data-points and the no-signal "300 mm/s line" will be determined. First it is important to capture some no-single data. To achieve this I set SWEEP_START = 300 and SWEEP_LENGTH = 2000 and kept a clearance of 2500 mm in front of the sensor.

Doing this gave distance velocity plots all similar to the example in the gallery. As seen, the signal looks fairly uniformly distributed throughout the whole plot (the right half of the plot is contained the time series data before the FFT. After the FFT only the left half of the plot contains all the data). Statistics were collected on the VEL, DIST, AMP, and SPREAD variables in the no-signal measurement and given in the table below. These statistics give us some interesting findings: 1) the standard deviation on VEL is quite tight when there is no-signal, only 5mm/s. Therefore, assuming the data is normally distributed, we can expect only 0.3% of the no-signal velocity readings to lie outside the range (286,316). Next we note that the DIST has a large standard deviation, this fact is difficult to use when determining if a single point is no-signal, however could be more useful if a timeseries is available. AMP also has a small standard deviation, however I am not sure how this compares to when a strong signal is present and so not much can be said of this right now. Finally we have SPEAD, which again has a large standard deviation and is unfortunately not constricted to a narrow range of values however, we need to await the strong-signal data to see how SPREAD differs.

	no-signal (N = 354)		static-signal (N = 165)		reflector-signal (N = 41)
variable	mean, µ	standard deviation, σ	mean, µ	standard deviation, σ	mean, µ	standard deviation, σ
VEL (mm/s)	301	5	286	7	167	105
DIST (mm)	1345	370	970	133	1708	276
AMP (arb)	2.15	0.21	3.05	0.87	13.40	12.28
SPREAD (arb)	253	69	232	72	85	130

• 

  No-signal distance velocity plot.

• 

  Static-signal distance velocity plot.

• 

  Reflector-single distance velocity plot.

Next it is important to look at the situation where we have a direct static reflector in front of the radar sensor. This will likely change AMP, but hopefully DIST or SPREAD may be used now to discern the low-signal regime.

I have now collected some data in the static-signal regime. This data has been collected by placing a static reflector approximately 1000 mm from the radar sensor. The idea here is to model the signal in dry-weather where the dominant signal is coming from the bottom of the channel. As seen from the plot in the gallery, this situation visually looks similar to the no-signal situation except that there is one row which has a higher signal strength, particularly so at low velocities (left hand side of the plot). From the statistics we note that mean of VEL has decreased significantly, and the standard deviation has increased. Taken together the low-signal data is no longer confined to such a tight VEL range and may extend down to 265 mm/s instead of 286 mm/s. As expected for a static reflector we are getting a defined DIST measurement, though the standard deviation here is still quite large (so it is not sufficient to filter based on DIST being equal to a particular number ie: the height of the sensor). The AMP variable has an increased µ and σ, however it is unclear if the statistics of AMP will remain the same when a genuine signal is present. SPREAD has only a slight change to µ and σ, and likewise it is unclear if it will change in the presence of a genuine signal.

Next I moved a static reflector slowly (100s mm/s) perpendicular to the radar sensor (ie: keeping the same distance). This is not a completely accurate representation of water flow (it is probably much higher in signal strength) however it is a moving object, which distinguishes it from the previous two cases. When I have access to a flume, I can collect more data on how real water flows behave. It is obvious from the relfector-signal plot that the signal is highly localised both in velocity and more so in distance. In the statistics we now see that VEL has a different mean, a good indicator that the reflector was moving. DIST is very context dependant for a real signal. The mean AMP is now much greater > 10. It has high variance however, and its range overlaps with the low-signal trails. SPREAD has a significantly lower mean (~90 vs ~ 250), yet its standard deviation is also high and some of the valid data points have a SPREAD comparable with those of the low-signal data. One cavate of the reflector-signal dataset is that as the reflector was moved back and forth, I can't be confident that a) it was in the field of view of the radar detector at all times, and b) was moving while the measurement was occuring. Hence, it may be possible that some of the reflector-signal data actually are actually not measuring anything. This issue will be resolved when I perform the flume testing.

2nd July 2024

A critical bug was fixed in the calculation of the angle corrected velocity. The incorrected /sin calculation was modified to the correct *sin. This has been released in radar firmware rev 1.8.2.