Power management monitoring

As we move forward in the hardware design stage we are beginning to add in more and more potentially power-hungry devices that may make a field-based deployment of our system unfeasible. I think we need to start estimating power consumption so that we don't design something we can't keep powered with a solar panel.

Considerations:

What is the power consumption of USB hub units?
What is the power consumption of 4 RTL-SDRs? Can we get away with fewer? What are the tradeoffs?
What is the power consumption of a broadband USB dongle for data transfer? How does this compare to the CC1310's power consumption?

The USB hub unit consumes power according to the usb devices that draw current from it. The maximum power that the Plugable Multiport USB Hub can provide is 15 watts (5V/3A) [1].
Each RTL-SDR typically consumes 260-300 mA (300mA * 5 = 1.5A) [2,3]. One is used for supervisory commands to the other four RTL SDRs (there must be a supervisory device because a single RTL SDR cannot be multitasked to perform data extraction and supervisory commands at the same time). The other four RTL SDRs are used in the root MUSIC algorithm. Indeed there is a trade off here between an increased accuracy of root MUSIC and a larger power consumption as the number of antennas in the array increases. Moreover, you need to have enough antennas in order to counteract multipath interference effectively with forward-backward subspace smoothing [7]. The number of RTL SDRs was also chosen based on the number of antennas used in [4].
The CC1310 has a much lower power consumption, but both options are supportable under the solar power constraints for our system (see 4.) Huawei MS2131 USB-stick: 500 mA [5] CC1310 Maximum Core Current Consumption: 23.5 mA [6]
Total Current Draw from USB Hub: ~2.1 – 2.6 Amps (including 5 RTL-SDRs, Noise Card, Clock Card, and USB modem) Total Current Draw: (with Raspberry Pi) Absolute Minimum: 2.5 Amps Absolute Maximum: 5 Amps (most likely will not draw near here as the Raspberry Pi will not power any peripheral devices (usb hub does this) with the exception of a low-power CC1310 for one receiver)

Projected Wattage: Around 15 Watts (5 volts * 3 Amps). The Raspberry Pi and USB Hub are 5-volt devices in parallel.

Based on the expected power consumption of our system per hour (15 watts/hour), a standard sized 100 watt solar panel will have enough voltage and amperage to power a ground node during a whole ideal day (our system consumes 360 watts/day, and the solar panel collects 500 watt hours on an ideal sunny day).

[1] https://www.amazon.com/Plugable-7-Port-Speed-Power-Adapter/dp/B003Z4G3I6 [2] https://www.rtl-sdr.com/forum/viewtopic.php?t=1587 [3] https://www.reddit.com/r/RTLSDR/comments/2e9u7v/power_consuption/ [4] https://github.com/EttusResearch/gr-doa/blob/master/docs/whitepaper/doa_whitepaper.pdf [5] https://consumer.huawei.com/solutions/m2m-solutions/en/products/tech-specs/ms2131-en.htm [6] http://www.ti.com/lit/ds/symlink/cc1310.pdf [7] https://github.com/jakapoor/AMRUPT/blob/master/Literature/General_radio_direction_finding/Angle%20of%20Arrival%20Methods/Direction%20of%20Arrival%20Estimation%20in%20a%20Multipath%20Environment%20an%20Overview%20and%20a%20New%20Contribution.pdf

Thanks Russell!

15 W is almost 4X that of Krueger's system (4 W), and this cannot be completely attributed to the additional RTL-SDRs.

Krueger's system is capable of running with 20 W solar panels, and I think we need to be aiming for panels no larger than this for practical reasons and cost.

One way we may be able to cut back on current consumption is to reduce the number of RTL-SDRs running per ground-node. If we accommodate for multipath interference with frequency-hopping instead of subspace smoothing with MUSIC, we might be in a better range for power consumption.

15 Watts/hr was retrieved from adding worst-case power consumption values for each device in our system, this value is much likely to be lower. Kruger's 4 Watts/hr is not a worst-case power consumption value because a typical usb modem consumes 0.5 Amps/hr, an RTL-SDR has a worst case value of 0.3 Amps/hr, and the bare-board active current consumption of a Raspberry Pi 3 Model B is 0.4 Amps/hr (likely to be greater with higher cpu loads). This turns out to a wattage of around 6 Watts/hr using worst case values (with the exception of the Raspberry Pi 3 which could have higher amperage).

The recent decision to use CC1310s instead of usb modems will bring this our system down to 12.5 Watts/hr. Both 4 Watts/hr and 12.5 watts/hr are suitable power consumption rates for solar panels. Let us consider the case of a 50 watt solar panel, and compare that to a 20 watt solar panel. The surface of this 50 watt solar panel is twice the surface area of a 20 watt solar panel, with less volume for the 50 watt solar panel. Based on the above links, the price for a 50 watt solar panel is $30 more than a 20 watt solar panel. With 12.5 watts/hr, our system would consume 300 watts/day under worst case conditions with continuous runtime, and this solar panel would collect 250 watt hours on an ideal day. Under this power plan, our system would be able to collect measurements continuously for most of an ideal day. I believe this is reasonable as our system would require around 2.5x the power of Kruger's system, which would call for a solar panel that provides 2.5x power (but is is not 2.5x in price).

Two extra RTL-SDRs (on top of the clock card, noise card, two receiver rtl-sdrs, and supervisory rtl-sdr) will be essential in retrieving accurate AoA results. If we use only two receivers for AoA measurements, the MUSIC algorithm will be ineffective towards determining accurate AoA results. With a two-element array, we cannot perform subspace smoothing which would result in refracted signals being correlated with source signals in the signal covariance [2]. Because of this, the resulting peaks of the psuedospectrum produced by MUSIC is likely to have incorrect peaks [1].

The accuracy of subspace techniques (i.e. MUSIC) in determining AoAs is far superior to interfermotery systems that solely use the phase difference of two antennas. This is because subspace techniques are resilient in a non ideal environment with environmental/system inherent interference/noise [3,4,5]. As you suggested in #15, "Work by MacCurdy and Richardson here at Cornell suggested that a completely AOA-based triangulation system will be woefully inadequate to achieve high resolution." I believe the type of system they are referring to is a non-subspace AoA interferometry system. Since frequency hopping would not account for the effects of environmental/system-inherent noise, using a subspace technique with smoothing would be a prerequisite to achieving high accuracy AoA based on previous findings, and not a supplementation.

[1] https://github.com/jakapoor/AMRUPT/blob/master/Literature/General_radio_direction_finding/Angle%20of%20Arrival%20Methods/GIRD_Systems_Intro_to_MUSIC_ESPRIT.pdf [2] https://github.com/jakapoor/AMRUPT/blob/master/Literature/General_radio_direction_finding/Angle%20of%20Arrival%20Methods/Direction%20of%20Arrival%20Estimation%20in%20a%20Multipath%20Environment%20an%20Overview%20and%20a%20New%20Contribution.pdf [3] https://github.com/jakapoor/AMRUPT/blob/master/Literature/General_radio_direction_finding/introduction%20to%20the%20theory%20of%20direction%20finding.pdf [4] https://github.com/jakapoor/AMRUPT/blob/master/Literature/General_radio_direction_finding/Angle%20of%20Arrival%20Methods/Approaches%20for%20Angle%20of%20Arrival%20Estimation.pdf [5] https://github.com/jakapoor/AMRUPT/blob/master/Literature/General_radio_direction_finding/Angle%20of%20Arrival%20Methods/Multiple%20Emitter%20Location%20and%20Signal%20Parameter%20Estimation.pdf

Thanks for this detailed analysis.

I see now that we were comparing worst-case power consumption on our system with the actual power consumption of Krueger's. That said, I still want to make sure we are as conservative as possible regarding power consumption. The functionality of any solar panel depends on its access to direct and strong sunlight (containing several orders of magnitude more energy than shade or filtered light), which may not be available all the time in sub-tropical places where the system will be deployed (like Florida), and may be even less available in the dense rainforest environments of Trinidad. We need to employ an energy harvesting solution that does not result in brown/black-outs. To do this we will need to critically evaluate the components we use, the modes they are used in (e.g. maximizing sleep mode durations), as well as the source of the energy supply itself.

For this, and other reasons concerning the rigid layout requirements of a 4-antenna system, the decision to use 4 antennas and MUSIC should not be taken lightly.

As you suggested in #15, "Work by MacCurdy and Richardson here at Cornell suggested that a completely AOA-based triangulation system will be woefully inadequate to achieve high resolution." I believe the type of system they are referring to is a non-subspace AoA interferometry system.

This is incorrect. Gabrielson et al. say the following about the AOA system they tested:

Digitally steered phased - array approaches have also been employed to determine tag bearing. These methods use multiple antennas, usually in a circular or linear array, and establish signal direction by measuring the phase difference of the signal at each receiving antenna. This method usually requires multiple synchronized receiver signal paths; modern directional receivers usually accomplish the task with high-speed synchronous analog-to-digital converters (ADCs) operating at the IF stage of the receiver. The sampled multichannel signal is then digitally down-converted and the bearing is established via software; the multiple signal classification (MUSIC) [15] algorithm is widely used for this purpose. The complexity of this approach can be problematic for wildlife tracking applications, and receivers of this type are costly. Additionally, phased-array receive antennas must be mounted far from other objects; experiments conducted by our group showed significant variation in signal phase due to nearby vegetation. This constraint requires phased-array antennas to be mounted on tall, sturdy masts rather than opportunistically placed in trees.

As you can see, they tested out precisely the kind of AOA system we are considering, and found it to be ineffective. This underlies my emphasis on forward compatibility of our system with the HMFCW ranging technique described by Dr. Kan and colleagues.

Since frequency hopping would not account for the effects of environmental/system-inherent noise, using a subspace technique with smoothing would be a prerequisite to achieving high accuracy AoA based on previous findings, and not a supplementation.

The HMFCW (~=frequency hopping) ranging algorithm developed by Dr. Kan and colleagues was designed specifically to deal with the effects of noise, and to keep the system simple and more resilient to complications from layout constraints. They state:

In order to get AoA information from each carrier, different from previous work using low-directivity antenna for indoor locating purposes [10], which resort to building a large M-element antenna array, we simply use 2-element antenna arrays. Although with an increasing size of M, a linear array can be designed with high directivity, and super resolution algorithms such as MUSIC can be applied, a large M will lead to a heavy and cumbersome infrastructure which contradicts our motivation of using miniaturized low-directivity antennas instead of cumbersome high-directivity antennas.

Combining a multi-antenna MUSIC-like algorithm with a multi-frequency approach seems a laudable endeavor, but we need to make sure we don't paint ourselves into a corner by depending on the MUSIC algorithm.

All this said, if we cannot maintain coherence between ground-nodes (without time-consuming recalibration) as we receive multi-frequency signals, we may already have reached a dead-end with forward-compatibility of our system to the ranging approach.

As you can see, they tested out precisely the kind of AOA system we are considering, and found it to be ineffective. This underlies my emphasis on forward compatibility of our system with the HMFCW ranging technique described by Dr. Kan and colleagues.

Ok, thank you for finding this passage as I had trouble finding this specifically. Is this passage in the direction finding handbook? If so, what page is it on? It is well known now from previous works that the cause of this multipath problem is due to correlated signals within the signal covariance matrix. This passage does not mention the spatial smoothing techniques that I have reiterated for making MUSIC adaptable to multipath environments. I do agree with this passage though on the matter of basestation placement. We have already discussed that we should place our receiver basestations high up in the air (near the top of trees in a forest environment). I do not believe this is a significant constraint as our design calls for a small number of receivers for each several-acre coverage zone. Furthermore, when an open space in the environment is unavailable, the relatively low weight <30 lb basestation (the proposed 5.7 weight APC Back-UPS + 14 lb solar panel will form the bulk of this weight) can be put on a platform. In general, this setup will also be beneficial for the forward compatible system to have less multipath at receivers and greater receiving range.

Combining a multi-antenna MUSIC-like algorithm with a multi-frequency approach seems a laudable endeavor, but we need to make sure we don't paint ourselves into a corner by depending on the MUSIC algorithm. All this said, if we cannot maintain coherence between ground-nodes (without time-consuming recalibration) as we receive multi-frequency signals, we may already have reached a dead-end with forward-compatibility of our system to the ranging approach.

I appreciate the skepticism here. The methodology in the proposal accounts for many of these issues as well as the references provided above (i.e. high antenna constraint and multipath interference - [1,2]). Please consider that we are close to obtaining AoAs from root MUSIC with subspace smoothing (ETA 1-2 weeks away). Then we will reassess.

For the latter issue in the forward compatibility approach, I believe only phase/frequency offsets need to be recalibrated for (the frequency and bulk sampling offsets from the ADCs will not change because this is not dependent on the frequency of the received signal). Furthermore, the cubic alignment and beamforming methods developed to counteract phase/frequency offsets are not as computationally expensive as the long FFT used for bulk offsets (the GNU radio blocks in the Whiting's implementation perform these continuously, rather than every 10 iterations for bulk offsets).

Furthermore, a cross correlation must be performed at each frequency hop within the coherent receiver because the phase offset (along with the bulk offset) is inherently corrected here by cross correlating white noise signal in the coherent receiver [3, 4]. If we desire to reduce the software computational complexity of the coherent receiver for frequency hopping, we could just correct for phase offsets at each frequency hop by adjusting for differences in AoAs when the white noise signal is provided to each receiver channel so that a long FFT convolution does not need to be performed at each frequency hop.

[1] https://github.com/jakapoor/AMRUPT/blob/master/Literature/General_radio_direction_finding/Angle%20of%20Arrival%20Methods/GIRD_Systems_DOA_Multipath.pdf [2]https://github.com/jakapoor/AMRUPT/blob/master/Literature/General_radio_direction_finding/Angle%20of%20Arrival%20Methods/Direction%20of%20Arrival%20Estimation%20in%20a%20Multipath%20Environment%20an%20Overview%20and%20a%20New%20Contribution.pdf [3] https://github.com/tejeez/rtl_coherent [4] https://coherent-receiver.com/support

Hi Russell,

Our discussion is expanding far beyond power management in this discussion, so I'm reposting relevant information in the appropriate issues, and we can continue the discussion there.

jakapoor / AMRUPT

Power management monitoring #17