segunda-feira, 13 de janeiro de 2020

Note2_RPi4_V6.6_The temperature of Pi







Note2_RPi4_V6.6

The temperature of Pi A


___________________________________________________________________________ 

NB:  those technology-oriented and/or in a hurry might want to skip all the blue text, and also just check the table, the plots and read the ordinary black text of the concluding remarks.

___________________________________________________________________________


Rationale

Here I present the results of testing a Single Board Computer (SBC) B , a Raspberry Pi 4 , Model B 2GB (RPi4), through different configurations; and the resulting CPU temperatures and ratios with ambient temperature measures. To stress it clearly: this is not a laboratorial test (and these should be valued) but instead a close to real-world sequential set of tasks.
The intermediate goal being: to “build” a SDR system with an optimal performance, reliability and user friendly; targeted to sailors; to receive and record maritime safety information from LF/MF (Navtex) up to UHF (Inmarsat/SafetyNet/ECG) passing to the non mandatory but very useful SSB data broadcasts (as RTTY text and meteo charts as WeatherFax). On land tests but as a sort of marine pre-prototype.
The ultimate goal being: to contribute to SDR prototyping to be tested in real maritime conditions for off shore vessels, with leisure ones being the even more specific target. Let such prototypes be both commercial or the result of collaborative efforts similar to OpenCPN. Ence the time-line and final question from 1st running OS install to: “is a SBC as the new Rpi4, almost  ready to be an headless faithful SDC front-end to run critical radio applications in a marine environment?”.
Unless relevant to understand a specific issue, I will not go in the next sections of this post, into further details on the ultimate marine goals or the reasons of choosing a given test setup or sequence; please refer to other posts in this blog and information elsewhere available on such subject.

A hot topic among tech-oriented and users is the temperature reached by Rpi4. (obviously, pun intended). High temperatures, as detected by the system, lead to a reduction in the CPU frequency (throttle), in fact a safety mechanism to protect the CPU and the whole computer, the trade-off being a reduced performance.

Temperature issues of electronic equipment onboard vessels are also a serious matter of concern for safety-aware seafarers.  Above and below deck in hot climates, but not only: displays can became un-readable; each or all of the systems could start to show random behaviours or worse to display wrong information without any warning.  And ultimately they all fail 1,D.


The Method

Material, specifications of tested hardware and software

The specifications of this single case study  of a Rpi4 “subject” and his hardware and software environment

Please note, here all the main hardware and software used during the initial setup and test of the Rpi4  is listed; the specific hardware used in each trial is clearly pointed under sub-sections.

-       VHF antenna , Shakespeare, Skinny-Mini, Model Nº 5250-AIS
-       Software Defined Radio (SDR) hardware front-end, SDRPlay DSP 1A (SP1A)2
                                          
-       Single Board Computer (SBC), Raspberry Pi 4B 2Gb (Rpi4) 2

-            Eprom up to date, as is, since Rpi4 unboxing: VL805,00137ab
-            only directly connected to the Local Area Network (LAN), Wi-Fi not running or
                     even configured
-            Naked, i.e., bare SBC as is from out the box
-            OR
-            Dressed, i.e., in an Aluminium Heatsink Case for Raspberry Pi 4 from The Pi Hut
-            Operating System (OS) SDRPlay V_0.6 (SDRPv0.6), based in the Raspbian   
                               Buster OS, with SDRplay compatible software
-                    CubicSDR-0.2.5 3 as is from SDRPv0.6 and with its automatic choices when it found other 
                   connected hardware:, Zero-IF, no filters, but
-                    audio sample rate 48 kHz.
-                    playing music from a local FM broadcast
-                     input bandwidth, sample rate menu (IB)
-                     2048 kHz
-                     OR
-                     500 kHz
-                     SoapyRemote as is from SDRPv0.6
-                     SSH server as is from SDRPv0.6, accessed in a bash terminal from a MacBook
-                     VNC server of Rpi4 as is from the above distribution but                                       
                    720X480@60Hz
-                     OR
                                1024X768@60Hz
 
-       Raspberry Pi Official USB-C power supply (Pi Official Power Supply)
-       OR 
       PowerBank Imuto, Model Nº X6L Pro  (PowerBank)
-         Projector 1chip DLP, Benq, Model W1070+ (Projector)
-                        1920X1080@60 Hz
-                        Or
-                        1024X768@60Hz
-       USB Extended Keyboard from an old mac (USB Keyboard)
-       OR
-       Bluetooth Apple Magic Keyboard, Model Nº A1644 (Bluetooth Keyboard)

-       USB Trackball Kensington,  Model Nº M0147 (USB Trackball)
-       OR
-       Bluetooth Apple Magic Trackpad 2, Model Nº A1535 (Bluetooth Trackpad)
-        
-       Portable Computer for support and SSH access and/or VNC client and/or SDR back-end while receiving IQ streams from Rpi4 or running SDR software independently as a benchmark bed to Rpi4 performance: MacBook (Retina, 12-inch, Early 2015) (Mac)
-                        Built-In Retina LCD, native resolution of 2304X1440@ (60?) Hz
-                        8 Gb RAM
-                        Mac OS Sierra, v10.12.6
-                        CubicSDR-0.2.5 3
-                        FLDIGI-4.1.08
-                        BlackHole 16 ch from Existencial Audio v0.2.5 4
-                        Native (OS) Screen Sharing (works as Mac VNC client)
           
-       Mixed interconnected networks (LAN-WLAN) with a Router Huawei Model Nº EchoLife HS8247W, both for the LAN with Category 5 cabling (Cat 5) and Wireless Local Area Network (WLAN), Mac only directly connected to the WLAN (LAN-WLAN)
-       OR 3
-       Ethernet network only, LAN, for Rpi4 and Mac, both computers connected to a Switch Netgear Model Nº GS30SE (used as a “dumb” switch not configured) with Category 7 cabling (Cat 7);   Switch and Router Huawei also interconnected with Cat 7 cabling; Mac with its Wi-Fi off thus connected only to the LAN through a Belkin USB-C  Hub Model Nº F4U092WiFi (LAN only)

-       Cables of all kinds,  q.s.


Tools and generic setup to measure temperature

RPi4 placed in a shelf of an aluminium rack, holding the majority of the devices of      input/output, internet server and switch used in this study as well as other electric and electronic appliances.

Internal temperature of the CPU of Rpi4: shell command # vcgencmd – measure_temp (e) running on the desktop of the tested unit or from a SSH shell from the Mac. (CPUt)

External temperature of the CPU of Rpi4: consumer infrared thermometer, LaserGrip, Model Nº GM550, measures at around 20 cm with the infrared beam perpendicular to the surface of the CPU, pre-baseline condition (infrared thermometer)

Room/ambient temperature: consumer unit, ThermoPro, Model Nº  TP-50, placed at a central and relatively stable spot in the room, at around 3 meters from the Rpi4. (AMBt)

Procedures

Sequence of conditions, each one with a given configuration determined by the more broad goal of research – case study of a SBC which could be used as part of a portable, reliable setup for radio reception in leisure boats. Whenever possible: incremental modifications to improve performance, reliability and user ease of operation and improved listening/reading experience of the radio messages.

            For each test/trial
-       apply configuration to be tested;
-       let RPi4 run with the intended configuration for 20 minutes;
-       measure temperatures, both AMBt and CPUt, in the following 21-23 minutes interval; repeat, inspect and correct setup if necessary. Instead of the more robust approach of always running several trials; and to take later an average or median from those trials as the representative value of a given experimental condition. This approach would have consumed too much time in this quasi-experimental, real world study.


The Results of this quasi-experimental / real test

The absolute values of RPi4 temperature range from general minimum of 41 °C to a maximum of 70 °C. For the Naked conditions the minimum was of 56 °C and the maximum of 70 °C. For the Dressed conditions the minimum was of 46 °C and the maximum of 54 °C.

In the “pre-baseline” condition,  the CPUt was of 24,5 °C for an AMBt of 22,5 °C. So just plugin the Rpi4 and let the electric power flood-in is not a problem at least with such a low ambient temperature.

From now on we will present temperature mainly relative data and plots, i.e., relating the Raspberrian Pi 4, model B 2GB values with those from Ambient room measures. See The Table, Plot1 with relative values of CPUt/AMBt and,  Plot 2 with relative-cumulative values of CPUt/AMBt.  An approach of obvious practical interest for real world situations. Anyway, knowing that the stable averaged ambient temperature was of 22,1 °C with a standard deviation (s.d.) of only 0,2, it is fairly easy to estimate the absolute temperatures of the Rpi4 CPU. And, by the way, since it is related to heat transfer, the relative humidity in the air was in the interval of 50-60%.




The Table





Plot 1 and Plot 2
 See The Table for the content of each condition number, as hardware, software and configurations used.
Red points represent the computed results from the measures of the CPU and Ambient temperatures.
Blue lines are aproximative adjusted regression curves.
The gray blur in Plot 1 stands for, aproximately, the area where data points should be if they are well fitted by the regression equation


 In the 4 baselines (conditions nº 1, 12, 14, 19): taking all the 4 baselines together, the relative  CPUt/AMBt has a mean of 2,1 and a s.d. of 0,4. Thus the “original” absolute                  temperatures ranged from 40 to 50 °C, a bit above the double of the ambient mean of 22,1 °C. The Dressed Rpi4 has its absolute idle temperature lowered to around 41,5 °C, less than the double of the ambient temperature, relative ratio of 1,9 (condition nº 14).

Comment on condition LAN only with Soapy Remote running on the Rpi4 Naked (condition nº 13):  temperature seems to drop down to a relative value similar to baseline 1 and 2 (2,3). But WiFi was not configured or even used in Rpi4. The test of a LAN only condition, replacing a mixed LAN-WLAN was targeted to solve the problem of reliability of CubicSDR when running as client in another computer. In such situation could the forwarding of IQ data for a WiFi client be the source of extra-load for the LAN server and thus leading to a noticeable increase of the CPU temperature? Needs to be further investigated. 


Comparing the relative values, from the Naked to the Dressed conditions, the advantage of using a heatsink case are evident: a drop from a mean of 2,9 to 2,3, respectively. A relative value similar to the previous baselines with the naked Rpi4 (but see the previous comment).

Considering the 2 last outliers in Plot 1 (conditions 16 and 17) and the very slight drop in the Plot 2 with the optimization of the software and parameters by condition 10 (starting the use of Soapy Remote, instead of running CubicSDR directly on RPi4) and continued with the series of records with the heatsink case: under a statistical although a little speculative point of view, there is still space for improvement both in the hardware/software side of the Rpi4 and in the passive heatsink solutions. More specifically, the gray area following the data points is the confidence interval of 95% for the average value (method Loess used to compute and apply the model of linear regression).

Overall, the results of our tests with a RPi4 with the latest firmware update available and, comparing  Naked with  Dressed conditions, i.e. The Raspberry Pi 4 Model B of the first generation, with or without a passive cooling Aluminium Heatsink Case, seem very impressive. In the final best scenario (condition nº 18) the relative value is of 2,1 while streaming IQ data, thus corresponding to an absolute CPU temperature of about 46 °C. A very reasonable working temperature for a single board computer. But check the next section.


Discussion and Concluding remarks

With a RPi4 treated with an updated Eprom / OS and software plus a heatsinc case as in our study,  results of functional temperatures are between 46 and 54 degrees Celsius. A good result. Such data seems to point to Rpi4 as an usable SBC, if not out-of-the-box just with a few improvements; let it be on  land, industrial, ham automatic (not-attend) panadapters or offshore.
However, the above results were gathered with forgiven, stable,  ambient temperatures of around 22 °C. In the real world, out of the comfort of offices and houses, both the range and the variations across time spans are very large. That is why I am stressing the need of calculating relative values of temperature between the Rpi4 and the ambient.

There are plenty of temperature RPi4 observations around in the internet. A few seem to be reports from well done experiments, even if the methodology details are some times hard to find or to understand. I got my brand new Rpi4 already with the latest Eprom version. VL805 FW version: 000137ab. And no, I did not reverse the process just to report temperature logs with older Eprom releases. 

Fortunately, Gareth Halfacree did lots of tests and Alex Bate blogged it [1]. Focusing our attention on the reported data related to Eprom upgrades, quoting the web page:

This feature takes a look at how each successive firmware release has improved Raspberry Pi 4, using a synthetic workload designed – unlike a real-world task – to make the system-on-chip (SoC) get as hot as possible in as short a time as possible.

Summarizing, in about 6 months (always with a naked Rpi4 (?) since the 1st version of the firmware as installed in RPri4 launched by 24 June 2019 2019 up to the date of the post, 28th November 2019, when  the stable firmware update was the  VLI, SDRAM, Clocking” and there was by that time a Beta firmware version, so an overall total of 4 firmware updates by then (thanks to the hardworking development team). The drop in measured temperature (it seems of the CPU but could be a stochastic central tendency measure recorded from thermal snapshots of the whole board ?)  thanks to firmware updates was of 10,9 % (last stable update) or of 11,3 %  (beta update), overall from 72,1 °C to 64,8 °C , a drop of  7,3 °C. I missed the ambient temperature in the blog page (about 24 °C it seems from one of the readers comments ?).


But also the author of the blog clearly admits (showing some results in a plot but with no temperature data if I am not wrong) that after all:

(…)though the biggest impact can be achieved simply by adjusting Raspberry Pi’s orientation.

That is trough a physical simple action as changing the laying position on the table of the Rpi4 board. So let us move to other physical interventions like using cases to enclose a Rpi4.

In a Youtube video of the channel “ExplainingComputers”  made public by last 24th November 2019, Christopher Barnatt [2] compares the temperature of a Rpi4 dressed with two passive wraps (“passive cooling solutions” as named by the author) with his own previous records on temperatures with several brands of active cooling systems. Quoting:

Raspberry Pi 4 passive cooling, plus firmware update that significantly reduces the temperature of the Pi. Tested in this video are the Kodi Edition FLIRC case, and the Aluminium Heatsink Case for Raspberry Pi 4

In his test the Christopher Barnatt ‘ s Rpi4 had the same firmware update as my unit (VL805 FW version: 000137ab) and also tested the case I used here. Data was collected after letting the Rpi4 rest for a few minutes, then the test runs for 7 times and a series of measures are timely performed: all automated by a bash script with the command #vcgencmd measure_temp (shown around minute 7.40 of the video). The verbally reported ambient temperature in the video would have been around 23 °C (not sure about how, or if, it was measured). A summary table of the data is presented around the minute 15 of the video; all the results are judged by the author as “very impressive”. Exemplifying several (total of 8, 1st at idle, 7 while the test was running) values were presented for the best active cooling, niknamed ICE tower, and for the second tested,  passive one, niknamed Heatsink Case; respectively from 29 (at idle) to a final value 34 °C for the active and from 35 (at idle) to 56 °C for the passive. The outside of the Heatsink Case  is “slightly warm (…) nice to warm your hands at the winter” the author says in the video.  As the irony of using prime numbers computation as the included stress test in his bash script E.  British humour at its best.
In short, if I computed well the statistics, from the Christopher Barnatt ‘ s data:    17,1 % more at idle for the Heatsink Case; and, averaging the 7 loop tests measures, 33,7 % than the ICE tower under high load computation. Nevertheless all the results of all the several cases tested might be evaluated as very good or even impressive as underlined several times by the author.
Christopher Barnatt concludes that the two tested cases achieved very good results, in particular if paired with the available firmware update but (of course) none achieved the same results as the active coolers, namely the ICE tower. In general (active and passive as tested  and presented in 3 videos from the author), the results are evaluated as much better than those obtained with RPI4 with older firmware versions and undressed and/or with the official Rpi case.


Methodological problems. First, using disparate apparatus and procedures to measure the same variable. Here, Rpi4 naked and off – infrared thermometer versus Rpi4 running naked or dressed in a case – command line tool.
Second, relaying on internal measures. Here and in the majority of the available reports around. Assessing the Rpi4 CPU temperature with a command line tool, part of a distribution package of tools and software, running on top of an OS/Kernel, running on the CPU/SBC that is being evaluated.
The 1st issue is odd; but we can live with it. It’s a minor lack of consistency and giving the low sophistication and data aggregation of the statistics used here it does not compromise the analysis. The infrared thermometer was just used once at the very beginning of the time series records to get a sort of pre-baseline temperature reading. Afterwards the same measure and tool was always used.
The 2ed issue should be a real matter of concern. Here and elsewhere regardless of the topic and the object/sample of research. Relaying in internal assessments of the object-itself of inquiry to evaluate a variable is plain wrong F. And yes, I used it, and yes, most if not almost all of the other reports available around were based on data collected by the internal shell command # vcgencmd –measure_temp.  Anyway thank you, developer(s) of Vcgencmd; I use it a lot for several purposes. In short, infrared thermometers, camera thermal images (as used in the herewith cited study, reference [1] and the like, are fine but only for naked SBC. For consistent and comparable results in most of the practical and foreseeable situations (SBC naked, in cases, in embedded industrial systems, etc) what we should use / have used was a proper calibrated system composed by tiny thermal sensors placed on the surface of the CPU, linked to an external ADC/DSP processor.
As far as I am concerned I do have only a few lousy personal excuses for this methodological issue.
 
Regardless of the issues of the method,  we should highlight that, the addition / multiplicative / cumulative effects of all sort of  software and hardware actions could in the end promote a large noticeable drop in the final Rpi4 temperature; even if each one seems not effective by its own or is impact is not fully understood. 
 
Anyway, even the RPi4 unit I used, dressed with a passive heatsink box performs quite well at acceptable absolute temperatures while keeping a low footprint as expected of a Single Board Computer. So, no major performance drawbacks of this SBC should be expected because of overheating.  A fine solution then, but only with relatively low ambient temperatures. In fact, both the herewith presented results as those from the quoted tests by other authors [1] and [2], where gathered with ambient temperatures as those commonly found in the controlled interior of a building during the winter. Room temperatures  for offices  and houses in the winter between 20 and 25 °C might be regarded as a good compromise: gentle enough for humans and low enough for the more and more omnipresent technological gadgets.
Furthermore, we should keep in mind that in hot climates or just by “our” European Atlantic summer ambient temperatures above 30º C are normal; Even in the Greenwich longitudes, between 40-50 degrees north. Not to mention the climate rage we are all facing worldwide. On land I’m not sure if  the best active case will be enough; maybe it is better just throwing the Raspeberry Pi 4 to an aquarium full of mineral oil instead, no kidding. Offshore, inside a series production fiber glass or metal sailing boat we might climb up to 40 º C or even above, in the middle of the day; of course at our latitudes and longitudes, the sea water is usually below 20 °C even in August. Nevertheless, keep running one Raspeberry Pi 4 while tied to a pack of beers,  roped and trailed from the bow of the boat, might not be a feasible solution.


So, returning to our initial question:  is a Raspberry Pi 4 almost  ready to be an headless faithful SBC to run critical applications in a marine environment? And, specifically radio critical applications to receive safety messages in vessels, with a focus on leisure boats? Simple answer: a loud no. And probably not even ready for land based serious applications. At least and until even the preliminary drawbacks of temperature, already largely documented by the technological community in the last months are solved; including in harsh conditions as on offshore. Which are at least as demanding if not more as those found in the industrial land-based area: temperature, vibration, dirt, power requirements and resistance to power fluctuations, EMI interference, memory/system integrity, etc.


Again it is worth nothing that the developers of SDRPlay did an excellent job. A 0.6, pre-1x Operating System version is supposed to be an experimental, unstable one and, given the issues largely documented of the Raspberry Pi 4 Model B, the worst was to be expected. Nevertheless, the truth is that the 0.6 OS worked fine and was a platform quite reliable during the tests described in this post. Allowing also a steady running of the remote IQ streaming server. And being loaded with almost all the software defined radio needed, I do intended to keep the Rpi4 as a testing unit but only for  pre-prototype  in “sailors armchair” further experiments.

In fact, taking also in account all the hardware and software issues, reported by independent reputable reviewers the best place to have now a Raspeberry Pi 4 Model B is in a protected environment, as those where also the tests herewith quoted were done, with stable and relatively low temperatures.

Nowadays and at least in the foreseeable close future, using revised older Pi models as the 3B+ and 3A+, simpler and cooler out of the box, is the sensible option, or even industrial grade SBC; Specifically, for everyday real world use or for prototyping tests in the field of “would be” Single Board Computers for critical applications.








 __________________________________________________________________________



Acknowledgments

To Alfredo Pereira who did the fine plots in R.
To Christopher Barnatt (Youtube channel “ExplainingComputers” ) for his friendly reply about a previous version of this post.
To "Lake-Effect ", member of the Cruisers.forum, for helpful comments on a a previous version of this post.

To my sons for their help in reviewing this post but not only.



Technical Footnotes and References

Footnotes

Note 1
My own experience with an iPad in hot summer days, dressed with a waterproof case and secured with RamMount hardware. As a surrogate of chart plotters close to the helm. By the way, the shiny plotters installed in new charter boats look very trendy with its white cover put in, during navigation.
-       is the display hard to read? Your eyes should also be suffering with such amounts of Sun light. Put eyeglasses with polarized lenses to protect your eyes. Bonus: if (keep the sunglasses!) you rotate your iPad (clock or anticlockwise as you wish) you’ll find that in a certain orientations the iPad screen becomes more readable.
-       Is it too hot and the iPad even starts complaining with repetitive warning messages? Then it also means that it is, again, too hot for you. So, go to a shadowed and fresh spot and take also the poor agonizing and de-hydrated iPad with you.
-       Still to hot but not possible to stop and you really need to go on at the helm? Pick up a very damp cloth, better with fresh and spring water but if your reserves of drinkable water are low damp the cloud with salt water and put it over the iPad; I’m not kidding, did it several times with no problems … but of course if you try it and got problems don’t blame me as I do not guaranty this method by any sort or means.
-       Or, if you are in a hurry (and in spite of being one more broken middle class lady or gentleman) or if you are a member of the exclusive “more money than sense sailors club”: just buy an astoundingly exquisitely manufactured, nevertheless a good value for money,  born from a French-German coalition piece of hardware designated as a Sunshade for aiShell™ Air [5]. Did not test this but should improve both the readability of the iPad and its freshness, depending on the altitude of the sun and the path of your sailing, of course.

Note 2
On the SBC (Rpi4)  and SDR (SP1A) hardware tested here, other remarks than on temperature, specifically on cables and connectors submitted to a lot of stress during our tests. Not a very different situation from other cases given the targeted markets of these devices.
Rpi4: no problems with the USB-C, USB 2 and 3, RJ45 plugs; But the micro card holder is clumsy, anterior versions with a push-push holder were much friendly, easier and safe to manipulate; mini HDMI ports are just too fragile, better to replace by proper full ports or to use also for data including video output, USB -C ports.
SP1A, but the same could be pointed to the other models from SDRPlay: the performance of my unit was good. A RSPduo or a new RSPdx would be the better choice for a real-world application. Like, radio for marine applications from Navtex to SafetyNet. But the SP1A was fine for these tests. Problem: that USB Male B plug. People don’t hard print anymore. So it is more and more difficult to find cables with USB Male B plugs. When we find internet or local suppliers it is hard to access the quality of the cable and plugs. So, better to change the connection in the RSP to a USB-C or if keeping those B plugs – better to include in the pack a 2.0 cable from a brand tested and certified by the SDRPlay team or, even better to change the connector port to a 3.0 and to include in the pack with the RSP unit, one 3.0 Male B plug .

Note 3
CubicSDR has a good intuitive user interface, if not the best of the SDR front-ends available. One of the kind just use it out of the box and learn by using it, with no need for boring manual readings or frustrating forum checks. Nor a solid background in fiddling with knobs and tribal 73 salutes.  As long as the user interface is concerned. Of course, to use CubicSDR for a purpose and, understanding what a given command is for, requests a decent knowledge of radio in general and SDR in particular.
But it is also a very temperamental piece of software. When facing problems with other hardware or software components, of signal reception, and other issues Cubic SDR will start stuttering the output audio and/or “stuttering” the waterfalls of the signal; or it freezes completely; or it just quit; with no previous warning or post-report. Here, CubicSDR started to show over and over these symptoms, at 10 minutes intervals or even less, when:
-       the Soapy Remote in RPi4 was working and streaming the IQ signals extracted from the SP1A
-       the LAN-WLAN setup was used
-       the CubicSDR in the Mac was receiving that IQ stream from the Rpi4.
Meanwhile, Soapy Remote was working smoothly and reliably for hours. So, after a few more tests the major culprit candidate seemed to be the poor quality of the internet setup. That is why at a given moment the LAN-WLAN setup was replaced by a LAN only one. An improvement of the CubicSDR  behaviour was expected; not necessarily accompanied by a drop in the Rpi4 CPU load and temperature.
A parasite variable could have been the quality of the IQ signal or the ratio Signal/Noise. That is, a degraded signal might lead to an overload of both Soapy Remote and CubicSDR. What could interfere or explain the erratic behaviour of CubicSDR. I did a few tests, degrading and enhancing the quality of the signal received from the FM broadcasting by changing the position of the antenna (quantitative results not presented here). These manipulations were irrelevant: did not have at all an  impact on the CubicSDR reliability. So the key factor, if not the unique one, was the speed and/or the sustained transfer rate of the network. As reported above with a LAN only configuration the best results were obtained here.

Note 4
BlackHole 16 ch from Existencial Audio seems to be, at last, the way to go as far as  virtual cables to Macs are requested: usable, stable, frequently updated, always on, well documented, open source and free to use. We just need to configure the Multi Output Device [6] , to both send the sound stream to the digital program (ex, for reading satellite data) and to listen it through the Mac output (internal speakers, jack for headphones, etc). Get used to it at home, otherwise in several public situations you‘ll be furiously pressing buttons, hitting menus and so on trying to shut up the shouting beast living in the loudspeakers.


References

1. https://www.raspberrypi.org/blog/thermal-testing-raspberry-pi-4/

2. Youtube video of 2019. Raspberry Pi 4 Passive Cooling:


4. https://github.com/ExistentialAudio/BlackHole/wiki/Multi-Output-Device





 ______________________________________________________________________




Contextual Conjectures and Background

A scientist in a remote research facility. Rare and narrow schedules to went to civilization and to go visit his partner. He  recorded the weight of is beard at given intervals, when alone, in preparation for visiting his partner, etc. He published a paper with the data and plots quite a long time ago. An unexpected classic on emotions, expectations and physical quantities. I never found or read the original paper.  Go Google it.

Micro-Climatology. Rudolf Geiger is one of the most recognized founders of this discipline. A German researcher born by the end of the 19th century, (one more in the foundation of  modern scientific paradigms). Plenty of straight reasoning, data and plots of the ambient temperature above the soil  and, the temperature below the soil. Patiently recorded at scheduled and regular intervals. In modern language, we can found there good examples of phase analysis; phase delays or phase shifts between temperature above and below de soil. As in many phenomena. As in light; as in electromagnetic waves; as in radio operation of digital modes like Phase –Shift Keying (PSK). As in the fusion of multimodal perceptions (visual, auditory, tactile …) by humans and animals. The approach of Rudolf Geiger was of course very influential for the agriculture industry but not only on limited areas as such. Small, micro, obsessive work inspiring several commendable inquiries in diverse scientific areas.

More than twenty five years ago, I read carefully the book of Rudolf Geiger on the climate near the ground; in fact I  read a translation of his book, in a readable language.  Already in this century I continued spending several years working in experiments with human beings. With methods created by the end of the 19th century by researchers on what would be called later Psychophysics. Still a very good methodological source for both fundamental research and, applied, human factors engineering. Psychophysics is an inter-disciplinary domain founded among others by Ernst Heinrich Weber (1795- 1878) a German anatomist and physiologist. Who, also did several experiments on temperature perception, using very simple tools. Within a context of severe, obsessive and purposeful scientific enquiries in disparate domains, as the studies of Rudolf Geiger. Up to 2010 I always refused to work on subjects even remotely close to affects, emotions and the like. Not because I though such things were not scientifically
 interesting or personally relevant. But because I firmly believed that we, the so called scientific, very international, cosmopolitan and savvy community, do not even had the right questions not to mention the right tools to study such volatile creatures. Then I was invited to participate in a project. Those kind of invitations one cannot refuse. Endless meetings of a multidisciplinary team, with software and hardware developers, mechanical engineers, psychologists and other beings. More than a year just running pre-studies, pilots, trials after trials. The master students at the basement facilities shaking with the cold; my team manager, a postdoctoral researcher, complaining about the “over-engineering obsession of the boss” and related costs. Only two years later we start to get tiny consistent results. Then, much to my dismay we found, in a very technological and industrial targeted study, that emotions were much more tied with, and “predictive” of, physical quantities than even the most elaborated rationale or perceptual assessments [II]. I am still amused with my own perplexities with such findings almost as I am with the idiosyncrasies of sailors.

Contextual Footnotes and References


Footnotes

Note A
Or the temperature of Pi as computed in degrees Celsius,  or a cartesian  plot  of Pi temperature or the psychophysics of Pi C

Note B
Small board computer (SBC): not a long time ago,  tech oriented persons just talked about embedded systems and the like. Maybe using the designation SBC is a sort of branding,  more sexy and trendy to sell these things. Fashion is everywhere.

Note C 
Cartesian because we also due to Mr. René the invention of the plots with X and Y coordinates or axes. And not only his speculations against speculators. As in Discours de la méthode or Les Passions de l'âme; or his suspicious appetite for bull eyes hidden in his Traité de l'homme.
Psychophysics of a Indian character in a computer graphics film scenario. India: a millenary culture with mathematics built-in.

Note D
Supporting a  prophecy of  Bruce Bauer [I] , in the defense of keep using the old methods of celestial navigation but with a broad relevance for all the electronic devices inboard  (quoting by memory): “Everything automatic will ultimately fail automatically.”


Note E
No, Pi is not a prime number among other reasons because it might be real and positive but  it is not an integer. But the debate on the relationship between Pi and prime numbers is always fascinating. On other hand the relationship between Pi, the Raspberry SBC and prime numbers is unknown but, being the Raspberry Foundation a British one and the mathematical basis  of the modern computational science due to the genial Mr. Turing, everything is possible.

Note F
Of course,  it is easy and appellative to rely on self-reports of the subjects, to gather data on the degrees of freedom of a given variable. The researcher just “asks” to the object what he is feeling instead of going to the trouble of devising and applying his own, external-independent-controlled, measures. Self states of conscience could be a matter of great interest in animals and machines by its own and, not only to perform “Turing tests”. But that is a different line of research and overall a complete different history. For the target of the majority of the research going around with live or inanimate creatures we should not use self-reports.
Moreover, it does not matter for the targeted research goals we are talking about, how smart or accurate was the  work of the developer(s) who wrote the code of a given piece of software as in experiences with live beings, it does not matter either who trained (shaped, in lab jargon) the pigeon or the toddler. “Hey dear subject, could you give me a number for the temperature of you brain? Thank you! And by the way, the temperature of your liver is … ?”. And no, the fact that it was and is done in the majority of the studies does not validate such approach. Research, let it be on the meaning of everything or on the temperature of a 2 cm2 silicon square, is not a matter of majority opinion , nor a matter of democracy nor a matter or mass behaviour.


References

I. Bauer, Bruce (1995, 2 ed). The Sextant Handbook, adjustment, repair, use and history. International Marine/Ragged Mountain Press.

II. Vieira, J., Osório, J., Mouta, S., Delgado, P., Portinha, A., Meireles, J., Santos, J. (2017). Kansei engineering as a tool for the design of in-vehicle rubber keypads. Applied Ergonomics: 61, 1-11.




Sem comentários:

Enviar um comentário