Although i have not done much noise/emissions testing on this topic, have we considered recommending turning off HDMI to reduce emissions from the Pi, when people are considering mounting the Pi, LNA and SDR on the mast?
i.e. 891,000 MHz and others
Although by disabling HDMI it may make it harder to diagnose if issues occur, it may also reduce power consumption for stable remote nodes. I keep a spare SD Card available with HDMI activated for any occasions where SSH doesn’t work.
Issue this command from a SSH session.
/opt/vc/bin/tvservice -o
Results in.
Powering off HDMI
This may need to be made permanent, as I expect HDMI reactivates after reboot.
To power back on.
/opt/vc/bin/tvservice --preferred
Results on.
Powering on HDMI with preferred settings
In some circumstances you may need to also issue the following for the screen to display properly.
I haven’t had much or a chance to play. If Ethernet connected, turning off Bluetooth and WiFi would also reduce emissions.
I’ve turned HDMI off on both of my nodes (299 and 334), which are both mast mounted and use 2.4G to connect to my home WiFi.
I’m just scheduling some observations that I have already seen, to see if the noise floor drops a little.
I was also going to put it into test mode and see what affect it has on and off against a known beacon and also tune it to the known HDMI frequencies to see if ti makes much difference.
The difference in construction and shielding of some cables seems to vary greatly and therefore leak EMI more in some.
If the video chip doesn’t have sync with a cable or monitor, as you have inferred, the chip may not generate a signal and therefore maybe doesn’t generate the EMI.
As it seems there are differences in EMI from the cable and station, we could come up with a series of tests, based on particular hardware configurations and deployment methods for people to assess the quality of the station - obviously providing tweaks that could help.
eg.:
Once active tune to known PI, Pager, FM/TV broadcast and other known terrestrial signals.
ramifications include, not being able to detect some satellites if the noise floor is too high or the SDR front end is being saturated.
remedy, consider a notch filter, different antenna design, etc.
We could provide what is expected, based on the existing community stations, what will be seen, what cant be seen (eg. good ISS or SSTV from a turnstile), the mandatory need for a LNA if you are interested in observing a wide range of sat’s, etc.
Some of this practical information might help set some expectations and amount of effort/cost required.
Not everyone has the facility or budget to get a rotator. What are the other options what could be considered to increase the attractiveness of the community.
Does this really need to go into the SatNOGS software? It seems to me to be more of a system-level consideration, one that could have confusing implications if initiated by a single software package on a RPi node that has multiple uses. In my case, all my RPis are headless, and I routinely set them up to keep the HDMI display circuitry switched off by including
/usr/bin/tvservice -o
in /etc/rc.local
This way, it gets set up at boot time, and, as mentioned above, should save 25mA from the power-supply budget. If one wants to temporarily use a display, then the HDMI display can be reenabled manually using
SatNOGS Client Ansible’s purpose is exactly to set up such system level configuration. Enabling such kind of features is usually configurable through satnogs-setup script.