MuonPi-Wiki - User contributions [en-gb]

Raspberry Pi Setup

2023-04-28T16:33:21Z

Simonglm:

(Requirements: Raspberry Pi Versions 0, 2, 3, 4 (with 40-pin GPIO connector) )

This article will introduce to you, how to set up a Raspberry Pi from scratch with all software needed to run the detector hardware.

DISCLAIMER: If not stated otherwise, this tutorial is developed on Raspian 10 Buster.

__TOC__

= Setup =
=== Basic ===
* Create a fresh install of RaspberryPi OS (at least Buster) according to the [https://www.raspberrypi.org/documentation/installation/installing-images/ tutorial]
* Update your system:
sudo apt update && sudo apt upgrade
* Change the default password of the user <code>pi</code>:
passwd
* (Optional) For a headless install (without monitor and mouse/keyboard), we recommend following this [https://www.raspberrypi.org/documentation/configuration/wireless/headless.md guide].
=== Interfaces ===
sudo raspi-config
* '''Enable the serial interface''' (UART) and '''disable the login shell''' via the UART:
3 Interface Options -> P6 Serial Port -> No (login shell over serial) -> Yes (serial port)
* Enable I2C Interface:
3 Interface Options -> P5 I2C -> Yes (enable)
* (Optional) '''Enable SSH''':
3 Interface Options -> P2 SSH -> Yes (enable)

=== Network ===
By default, the RPi is configured to automatically obtain an IP address when a connection is available and DHCP in your local network is active (this should be the case for most local/home networks).
If you prefer a fixed IP address in a local network: edit the file /etc/dhcpcd.conf. Use the template and uncomment the "Example Static IP Configuration" section with your desired IP address.
If network access should be established via WiFi, either configure it via the network configuration wizard in the graphical desktop environment (usually network icon in the system bar), or manually following these steps (either method is fine):
* Make sure that the wpa_supplicant package is installed:
sudo apt install wpasupplicant
* edit the file /etc/wpa_supplicant/wpa_supplicant.conf:
sudo nano /etc/wpa_supplicant/wpa_supplicant.conf
the configuration should look like this (non-relevant lines not shown):
update_config=1
country=DE</br>
network={
ssid="<your network ssid>"
psk="<your wifi password>"
key_mgmt=WPA-PSK
}
Enter your WiFi's SSID and password in the indicated fields.
Finally, restart the system that the changes take effect.

=== MuonPi software installation ===
(Requirements: a MuonPi board plugged onto the GPIO connector of the RPi)
* First, update your system to make sure, certificates and dependencies are up to date. This might take a while depending on how regularly the system is being updated.
sudo apt update && sudo apt upgrade

* Import and trust the public key as an apt package repository
sudo sh -c "curl https://archive.muonpi.org/muondetector.public.key | gpg --dearmor > /etc/apt/trusted.gpg.d/muondetector.gpg"
* Add archive.muonpi.org repository to the list of sources for apt
sudo sh -c "echo deb <nowiki>https://archive.muonpi.org/raspbian $(lsb_release -cs) main</nowiki> > /etc/apt/sources.list.d/muondetector.list"
* Update the package list:
sudo apt update
* Install the muondetector-daemon package and it's dependencies:
sudo apt install muondetector-daemon
* Optional: install the Graphical User Interface (GUI) program to monitor and control the MuonPi locally.
sudo apt install muondetector-gui
{{Note|Note that if you want to use the gui on the raspberrypi, it is recommended to use the Raspberrypi OS with Desktop preinstalled.|reminder}}

* The GUI can connect to the MuonPi over network as well, so it can be installed on other computers in the local network. Currently, binary packages for Raspbian, Ubuntu and Windows are available. The Linux-based versions can be installed from the package repositories (execute steps 1,2 and 4 from this list). The Windows program can be downloaded directly from https://archive.muonpi.org and installed by simply unpacking the zip-archive.

=== Login with your user credentials (only once) ===

Before taking the MuonPi detector into operation, you have to set your credentials for publishing data messages to the server via [http://mqtt.org/ MQTT] protocol on first start. This can be managed in two ways, one secure and one where your credentials appear as plain text in the config file:
==== The Recommended Method ====
In a bash shell on the MuonPi, run the command <code>muondetector-login</code>.

'''Note that for the software version 2.0.0 the command to run is <code>sudo runuser -u muonuser -- muondetector-login</code> instead.'''

When asked for sudo access, enter the password of your raspberry pi user.
When asked for your user name and password, enter the credentials supplied to you by a MounPi.org official. The credentials are stored (not in clear text) for all further telemetry connections.

==== Alternative Method ====
Uncomment the <code>mqtt_user</code> and <code>mqtt_password</code> options in <code>/etc/muondetector/muondetector.conf</code> and type your personal username and password into these fields between the quotation marks. Be aware, that these credentials are written in plain text into this file and can be retrieved by malware attacks. However, if you operate a station inside a home network and set up a strong ssh authentication (see above), you should be relatively safe.

=== Start the Daemon ===
The daemon should be enabled and started automatically after installation and on every reboot. However, when changing items in the config file, the changes have to be made effective by a daemon restart:
sudo systemctl restart muondetector-daemon.service

To see the current status of the daemon service use following command:
systemctl status muondetector-daemon.service

It can happen that the status shows 'failed' in red, usually a restart of the daemon service resolves this.

If the service should not enable itself by default the status shows a grey 'not loaded'. To enable the service use:
sudo systemctl enable muondetector-daemon.service

= Configuration =

Edit the configuration file /etc/muondetector/muondetector.conf: <code>nano /etc/muondetector/muondetector.conf</code>.
Change the settings according to your needs or leave them untouched, if unsure. The comments in the config file should guide you through any required modifications. One option, however, describes the placement of your detector. If you like, choose a stationID descriptor, eg.:</br>
(file: <code>/etc/muondetector/muondetector.conf</code>)
<nowiki>#</nowiki> A unique identifier of the user's station
<nowiki>#</nowiki> leave on default when the user operates a single station
<nowiki>#</nowiki> all detectors of the user are distinguishable on the basis of this id
stationID = "HomeOffice"

(anything which best describes the location of your detector like e.g. "GarageSW", "Bldg16Lab105", "AtticNE"). If you operate only one stationary detector, it may as well be left on the default ID which is "0" (zero).

'''Important''': When operating multiple detectors (under the same MQTT user account, see above) the stationID descriptor '''must''' be unique for each detector.

Spam filtering

2023-02-12T18:49:59Z

Simonglm: Created page with "Our website uses '''postfix''' as it's MTA (mail transport agent), which also has the ability to forward incoming mails to so called ''MILTERS'' ("mail filters"). One of those..."

Our website uses '''postfix''' as it's MTA (mail transport agent), which also has the ability to forward incoming mails to so called ''MILTERS'' ("mail filters").
One of those milters configured on our server is the spam filter '''Rspamd'''.

The WebUI of the service is located at [http://rspamd.muonpi.org rspamd.muonpi.org].
The rspamd service itself is running on <code>localhost:11332</code> with the UI running on <code>localhost:11334</code>.

===Terminology===
''Spam'' is unwanted mail, while ''Ham'' is referring to false positives.

From Wikipedia on [https://en.wikipedia.org/wiki/Spam_(food) Spam (food)]:
<blockquote>Spam has affected popular culture, including a Monty Python skit, which repeated the name many times, leading to its name being borrowed to describe unsolicited electronic messages, especially email.</blockquote>

== Setup ==
Setup and configuration was done according to [https://rspamd.com/doc/integration.html this guide].
Configuration for postfix is rather simple, just add <code>inet:localhost:11332</code> to the <code>smtpd_milters</code> field:

<code>smtpd_milters = unix:/opendkim/opendkim.sock,inet:localhost:11332</code>

== Training the filter==
Rspamd has the ability to learn to better filter spam. The training data is stored using a '''redis''' database.

Training can be done by two different methods: Via the WebUIs ''Scan/Learn'' Section of via the command line interface <code>rspamc</code>.

=== The WebUI===
After logging into the WebUI you can see the status of the filter. On the right hand side, a pie chart shows how many mails have been processed and the portions of rejected or annotated mails.
The Table named ''Bayesian statistics'' shows how many mails have been declared as 'Spam' or as 'Ham'.

Training is done in the '''Scan/Learn''' tab of the WebUI. Paste the raw message source into the text field and click '''Scan message'''.
Below you will see the result of the scan. The 'action' indicates what Rspamd would do if it where to receive that mail.
The symbols listed give the merits on which a message was evaluated.
They can either have a positive or negative value, indicating if their presence indicates if the given message is ''spam'' or ''ham''.

You can tell rspamd to learn from this message by choosing '''Upload Ham''' or '''Upload Spam'''.

=== The CLI ===
Similar to the WebUI, you can check if a given mail is spam or not by calling <code>rspamc suspicious.eml</code>.
After analysis, the found symbols and the collective score is shown.
To train the filter on this suspicious mail call <code>rspamc learn_spam suspicious.eml</code> and <code>rspamc learn_ham suspicious.eml</code> respectively.

== Dovecot CLI: 'doveadm' ==
Since most of the incomming mail is recieved by OSTicket via ''support@muonpi.org'' which does not provide the raw message source in the tickets, <code>doveadm</code> is used to get the message source.

'''NOTE''': This can only be done with superuser permissions and gives full read/write access to '''all''' users mails. So be careful!

Use <code>doveadm search [-u <user>|-A] [-S <socket_path>] <search query></code> to search for mails. See [https://wiki.dovecot.org/Tools/Doveadm/Search wiki.dovecot.org] for command reference and [https://wiki2.dovecot.org/Tools/Doveadm/SearchQuery this page] for ''search_query'' reference.

This one-liner will search and save mails from user <user> which were sent/recieved on the date <YYYY-MM-DD>:<br>
<code>doveadm search -u <user> ON <YYYY-MM-DD> | while read guid uid; do doveadm fetch -u <user> text mailbox-guid $guid uid $uid > $uid.eml; done</code>

Resource usage

2021-11-22T14:31:15Z

Simonglm: moved sentence above the table

== Hardware Resources ==
=== CPU ===
The majority of CPU utilization associated with the muondetector-daemon is due to the signal transfer to and from the MuonPi HAT via the GPIO-pins. As of [https://github.com/MuonPi/muondetector/releases/tag/v2.0.2 v2.0.2], this is handled by the "pigpiod" process, which takes about 20% of the processor time according to [[wikipedia:top (software)|top]]. The muondetector-daemon itself, uses only ~2%.

=== RAM ===
=== Disk I/O ===

== Network Resources ==
If you wish to operate the MuonPi within a network, that is a company's or other organization's network, the admins might be interested what data this device gathers and transmits or receives.
Here we elaborate on how the MuonPi uses the network and how a typical data packet looks like.

=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple: All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packet sizes over 45minutes]]

=== Outgoing Ports ===
{| class="wikitable"
|-
! Source Port !! Purpose !! Destination
|-
| muonpi:51508 || GUI connection to other machine on network || othermachine:39830
|-
| muonpi:41930 || MQTT message publishing to muonpi.org || muonpi.org:1883
|}

(Connections to localhost are excluded here)

As indicated by the table, the firewall has to allow outgoing connections to our servers on port 1883.
Otherwise the muondetector-login command will fail to establish the data link, and no event data will be sent to contribute to the detector network.

=== MQTT Packet ===
Detector telemetry and measurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client.

Generally two types of MQTT messages are sent: the event message and the log message.

====Event message====
The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature.

Example data of multiple MQTT packets being send to our servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! - !! Event counter !! - !! - !! -
|-
| 1 || muonpi/data/<user>/<detectorID> || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/<user>/<detectorID> || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/<user>/<detectorID> || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/<user>/<detectorID> || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/<user>/<detectorID> || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/<user>/<detectorID> || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/<user>/<detectorID> || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

These event messages are sent every time the unit detects a signal above the threshold.
It contains the UNIX timestamp of the rising and the falling edge of the signal and the number of the event.
The MQTT topic includes the username and the detectorID as registered with us, and allows us to associate the incoming data on our servers to your detector.

==== Log message ====
The log message contains various metadata about your MuonPi setup.
Most of the time, it consist of multiple MQTT messages packed into a single TCP packets, but it can sometimes also be separated into two packets.

An exemplary log message along with a description of each entry:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || [[wikipedia:GeoHash|GeoHash]]
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage across sensing resistor
|}

Resource usage

2021-11-22T14:28:57Z

Simonglm: /* MQTT Packet */

== Hardware Resources ==
=== CPU ===
The majority of CPU utilization associated with the muondetector-daemon is due to the signal transfer to and from the MuonPi HAT via the GPIO-pins. As of [https://github.com/MuonPi/muondetector/releases/tag/v2.0.2 v2.0.2], this is handled by the "pigpiod" process, which takes about 20% of the processor time according to [[wikipedia:top (software)|top]]. The muondetector-daemon itself, uses only ~2%.

=== RAM ===
=== Disk I/O ===

== Network Resources ==
If you wish to operate the MuonPi within a network, that is a company's or other organization's network, the admins might be interested what data this device gathers and transmits or receives.
Here we elaborate on how the MuonPi uses the network and how a typical data packet looks like.

=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple: All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packet sizes over 45minutes]]

=== Outgoing Ports ===
{| class="wikitable"
|-
! Source Port !! Purpose !! Destination
|-
| muonpi:51508 || GUI connection to other machine on network || othermachine:39830
|-
| muonpi:41930 || MQTT message publishing to muonpi.org || muonpi.org:1883
|}

(Connections to localhost are excluded here)

As indicated by the table, the firewall has to allow outgoing connections to our servers on port 1883.
Otherwise the muondetector-login command will fail to establish the data link, and no event data will be sent to contribute to the detector network.

=== MQTT Packet ===
Detector telemetry and measurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client.

Generally two types of MQTT messages are sent: the event message and the log message.

====Event message====
The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

Example data of multiple MQTT packets being send to our servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! - !! Event counter !! - !! - !! -
|-
| 1 || muonpi/data/<user>/<detectorID> || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/<user>/<detectorID> || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/<user>/<detectorID> || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/<user>/<detectorID> || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/<user>/<detectorID> || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/<user>/<detectorID> || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/<user>/<detectorID> || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

These event messages are sent every time the unit detects a signal above the threshold.
It contains the UNIX timestamp of the rising and the falling edge of the signal and the number of the event.
The MQTT topic includes the username and the detectorID as registered with us, and allows us to associate the incoming data on our servers to your detector.

==== Log message ====
The log message contains various metadata about your MuonPi setup.
Most of the time, it consist of multiple MQTT messages packed into a single TCP packets, but it can sometimes also be separated into two packets.

An exemplary log message along with a description of each entry:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || [[wikipedia:GeoHash|GeoHash]]
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage across sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (elaborate in [[Privacy]])

Resource usage

2021-11-22T14:00:34Z

Simonglm: /* Network Resources */

== Hardware Resources ==
=== CPU ===
The majority of CPU utilization associated with the muondetector-daemon is due to the signal transfer to and from the MuonPi HAT via the GPIO-pins. As of [https://github.com/MuonPi/muondetector/releases/tag/v2.0.2 v2.0.2], this is handled by the "pigpiod" process, which takes about 20% of the processor time according to [[wikipedia:top (software)|top]]. The muondetector-daemon itself, uses only ~2%.

=== RAM ===
=== Disk I/O ===

== Network Resources ==
If you wish to operate the MuonPi within a network, that is a company's or other organization's network, the admins might be interested what data this device gathers and transmits or receives.
Here we elaborate on how the MuonPi uses the network and how a typical data packet looks like.

=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple: All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packet sizes over 45minutes]]

=== Outgoing Ports ===
{| class="wikitable"
|-
! Source Port !! Purpose !! Destination
|-
| muonpi:51508 || GUI connection to other machine on network || othermachine:39830
|-
| muonpi:41930 || MQTT message publishing to muonpi.org || muonpi.org:1883
|}

(Connections to localhost are excluded here)

As indicated by the table, the firewall has to allow outgoing connections to our servers on port 1883.
Otherwise the muondetector-login command will fail to establish the data link, and no event data will be sent to contribute to the detector network.

=== MQTT Packet ===
Detector telemetry and mesurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client.

Generally two types of MQTT messages are send, the event message and the log message.

The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

The log messages consist of multiple MQTT messages packed into a single (sometimes two seperate) TCP packets

Example data of multiple MQTT packets being send to our data evaluation servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! - !! Event counter !! - !! - !! -
|-
| 1 || muonpi/data/user/0 || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/user/0 || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/user/0 || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/user/0 || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/user/0 || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/user/0 || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/user/0 || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

==== Log message ====
The log message contains various meta data about your MuonPi setup.

Example log message:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || GeoHash
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage accross sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (ellaborate in [[Privacy]])

Resource usage

2021-11-22T13:32:38Z

Simonglm: /* CPU */

== Hardware Resources ==
=== CPU ===
The majority of CPU utilization associated with the muondetector-daemon is due to the signal transfer to and from the MuonPi HAT via the GPIO-pins. As of [https://github.com/MuonPi/muondetector/releases/tag/v2.0.2 v2.0.2], this is handled by the "pigpiod" process, which takes about 20% of the processor time according to [[wikipedia:top (software)|top]]. The muondetector-daemon itself, uses only ~2%.

=== RAM ===
=== Disk I/O ===

== Network Resources ==
=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple: All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packet sizes over 45minutes]]

=== Used Ports ===
{| class="wikitable"
|-
! Port !! Application
|-
| 51508 || GUI connection
|-
| 8888 || pigpiod
|-
| 1883 (out) || MQTT message publish
|}

=== MQTT Packet ===
Detector telemetry and mesurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client with a short TCP message.

Generally two types of MQTT messages are send, the event message and the log message.

The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

The log messages consist of multiple MQTT messages packed into a single (sometimes two seperate) TCP packets

Example data of multiple MQTT packets being send to our data evaluation servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! - !! Event counter !! - !! - !! -
|-
| 1 || muonpi/data/user/0 || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/user/0 || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/user/0 || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/user/0 || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/user/0 || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/user/0 || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/user/0 || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

==== Log message ====
The log message contains various meta data about your MuonPi setup.

Example log message:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || GeoHash
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage accross sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (ellaborate in [[Privacy]])

Resource usage

2021-03-25T19:31:30Z

Simonglm: removed non-descript header text in table header

== Hardware Resources ==
=== CPU ===
=== RAM ===
=== Disk I/O ===

== Network Resources ==
=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple: All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packet sizes over 45minutes]]

=== Used Ports ===
{| class="wikitable"
|-
! Port !! Application
|-
| 51508 || GUI connection
|-
| 8888 || pigpiod
|-
| 1883 (out) || MQTT message publish
|}

=== MQTT Packet ===
Detector telemetry and mesurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client with a short TCP message.

Generally two types of MQTT messages are send, the event message and the log message.

The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

The log messages consist of multiple MQTT messages packed into a single (sometimes two seperate) TCP packets

Example data of multiple MQTT packets being send to our data evaluation servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! - !! Event counter !! - !! - !! -
|-
| 1 || muonpi/data/user/0 || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/user/0 || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/user/0 || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/user/0 || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/user/0 || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/user/0 || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/user/0 || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

==== Log message ====
The log message contains various meta data about your MuonPi setup.

Example log message:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || GeoHash
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage accross sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (ellaborate in [[Privacy]])

User detectors gallery

2021-03-21T13:35:14Z

Simonglm: ...that was too large

<div>
<gallery mode="packed-hover" widths=350px heights=300px>
Image:MuonPi-UserSetUp1.jpg|Users setup of the MuonPi detector next to the router.
Image:User detector dl4ina.jpg|User setup of DL4INA with single-channel connected hexagonal scintillator.
Image:User_detector_slu.jpg| User setup of slu with custom 3D printed encasing
Image:Detector_user_mw1cf.jpg| User setup of mw1cfwith, from his [https://mw1cfnradio.blogspot.com/2020/12/a-minor-departure-from-things-entirely.html blogpost]
Image:Detector_user_mmo.jpg| User setup of mmo with operating on a Raspberry Pi 0 WH
Image:MunoPi case in the dark.jpg| Custom enclosure for the complete detector setup. Including the Raspberry Pi, MuonPi HAT, and a hexagonal Scintillator. 3D Model was made by user 'slu' from the community.
</gallery>
</div>

User detectors gallery

2021-03-21T13:33:50Z

Simonglm: Increased image size

<div>
<gallery mode="packed-hover" widths=400px heights=300px>
Image:MuonPi-UserSetUp1.jpg|Users setup of the MuonPi detector next to the router.
Image:User detector dl4ina.jpg|User setup of DL4INA with single-channel connected hexagonal scintillator.
Image:User_detector_slu.jpg| User setup of slu with custom 3D printed encasing
Image:Detector_user_mw1cf.jpg| User setup of mw1cfwith, from his [https://mw1cfnradio.blogspot.com/2020/12/a-minor-departure-from-things-entirely.html blogpost]
Image:Detector_user_mmo.jpg| User setup of mmo with operating on a Raspberry Pi 0 WH
Image:MunoPi case in the dark.jpg| Custom enclosure for the complete detector setup. Including the Raspberry Pi, MuonPi HAT, and a hexagonal Scintillator. 3D Model was made by user 'slu' from the community.
</gallery>
</div>

User detectors gallery

2021-03-21T13:25:46Z

Simonglm: Added image of MuonPi case by 'slu'

<div>
<gallery mode="packed-hover">
Image:MuonPi-UserSetUp1.jpg|Users setup of the MuonPi detector next to the WiFi router.
Image:User detector dl4ina.jpg|User setup of DL4INA with single-channel connected hexagonal scintillator.
Image:User_detector_slu.jpg| User setup of slu with custom 3D printed encasing
Image:Detector_user_mw1cf.jpg| User setup of mw1cfwith, from his [https://mw1cfnradio.blogspot.com/2020/12/a-minor-departure-from-things-entirely.html blogpost]
Image:Detector_user_mmo.jpg| User setup of mmo with operating on a Raspberry Pi 0 WH
Image:MunoPi case in the dark.jpg| Custom enclosure for the complete detector setup. Including the Raspberry Pi, MuonPi HAT, and a hexagonal Scintillator. 3D Model was made by user 'slu' from the community.
</gallery>
</div>

File:MunoPi case in the dark.jpg

2021-03-21T13:23:54Z

Simonglm:

Custom enclosure for the complete detector setup. Including the Raspberry Pi, MuonPi HAT, and a hexagonal Scintillator. 3D Model was made by user 'slu' from the community.

User detectors gallery

2021-02-23T20:10:20Z

Simonglm:

<div>
<gallery mode="slideshow">
Image:MuonPi-UserSetUp1.jpg|Users setup of the MuonPi detector next to the WiFi router.
Image:User detector dl4ina.jpg|User setup of DL4INA with single-channel connected hexagonal scintillator.
</gallery>
</div>

Setup Mail Client

2021-02-15T12:33:15Z

Simonglm: Was 589 a typo? 587 is SMTP default and works fine

If you want to setup your mail client to use the Mail address issued by MuonPi.org, use the below settings for setup.

Do not use your full E-Mail address as username.

{| class="wikitable"
|+ Settings
| || '''IMAP''' || '''SMTP'''
|-
| Address || mail.muonpi.org || mail.muonpi.org
|-
| Security || STARTTLS || STARTTLS
|-
| Authentication Method || Normal password || Normal password
|-
| Port || 143 || 587
|-
| Username || <username> || <username>
|-
| Password || <password> || <password>
|}

User detectors gallery

2021-02-09T20:16:05Z

Simonglm: Created page with "<div> <gallery mode="slideshow"> Image:MuonPi-UserSetUp1.jpg|Users setup of the MuonPi detector next to the WiFi router. Although this is an wikipedia:Electromagnetic_interf..."

<div>
<gallery mode="slideshow">
Image:MuonPi-UserSetUp1.jpg|Users setup of the MuonPi detector next to the WiFi router. Although this is an [[wikipedia:Electromagnetic_interference|EMI]] nightmare, the detector works unaffected.
</gallery>
</div>

Main Page

2021-02-09T20:08:01Z

Simonglm: /* Gallery of Users' Detectors */

= The MuonPi Cosmic Detector Project =
The MuonPi Project is a [https://www.raspberrypi.org/ RaspberryPi]-based system using an inexpensive plastic [[Scintillator|scintillator]] + [[Silicon photomultiplier|SiPM]] photo sensor to detect muons from cosmic air showers with a time-stamping accuracy of several tens of nanoseconds utilizing the [https://www.u-blox.com/en/product/neo-m8-series u-blox NEO-M8N GNSS] module's "timemark" feature.

==== Learn about cosmic radiation ====
* Get started with [[Cosmic Rays]], especially [[Muon]]s

*[https://www.vox.com/the-highlight/2019/7/16/17690740/cosmic-rays-universe-theory-science Extremely powerful cosmic rays are raining down on us. No one knows where they come from.] But with large-scale experiments, scientists around the world are determined to find out. ''Vox'' Jul 25, 2019

*[https://home.cern/science/physics/cosmic-rays-particles-outer-space Cosmic rays: particles from outer space] Earth is subject to a constant bombardment of subatomic particles that can reach energies far higher than the largest machines. ''CERN''

* [https://www.weltderphysik.de/mediathek/podcast/kosmische-strahlung/ "Kosmische Strahlung"] Podcast (in German) on [https://www.weltderphysik.de weltderphysik.de]
* [https://www.weltderphysik.de/thema/bmbf/astro-undastroteilchenphysik/der-kosmischen-strahlung-auf-der-spur/ "Der kosmischen Strahlung auf der Spur"] article (in German) on [https://www.weltderphysik.de weltderphysik.de]
* [https://www.weltderphysik.de/gebiet/universum/news/2017/kosmische-teilchen-mit-extragalaktischem-ursprung/ "Kosmische Teilchen mit extragalaktischem Ursprung"] article (in German) on [https://www.weltderphysik.de weltderphysik.de]

==== Learn about the detectors ====
* Basics of [[Scintillator]]s
* Find out about [[Silicon photomultiplier|Silicon Photomultipliers]]
* How our [[The Detector|Detectors]] are assembled

==== Related and similar projects ====

* [http://cosmicpi.org/ CosmicPi]: A CERN-based project that aims to build the world's largest open-source distributed cosmic ray telescope.
* [https://www.hisparc.nl/en/ HiSPARC]: A distributed muon detection network aimed for high-schools and an experience of over 15 years.

= The Hardware =

=== SiPM PCB ===
The SiPM photo sensor which detects the dim light generated inside the scintillation detector is mounted on a small [[Sipm_board|SiPM board]]. Different numbers of SiPMs and read-out configurations can be realized through it's flexible design.

=== Preamplifier ===
The [[preamplifier]] is located in close vicinity to the [[sipm_board|SiPM photodetector board]] and amplifies the weak signals for transmission to the [[muonpi_board|MuonPi]] board, where they are further processed and evaluated.

=== The MuonPi-Board ===
The main signal processing, voltage generation and parameter monitoring and adjustment is done on the Raspberry Pi plug-on [[muonpi_board|MuonPi Board]]. The board's design is open source hardware and exhibits only commercially available off-the-shelf components which can be obtained from several distributors. With some soldering experience, the MuonPi HAT can be assembled utilizing a standard soldering equipment. A how-to guide and useful hints are available in the [[Assembly Guide|Assembly Guide]].

= The Software =
The MuonPi software collection is entirely open source and [https://github.com/MuonPi available on github]
It consists of several components:
* '''muondetector-daemon''' The main control program running as a background system service on the RPi. The daemon configures, controls and supervises the components on the MuonPi HAT board, handles the comunication to the u-Blox chip and to the outside world via MQTT link and direct access socket, monitors system parameters, such as temperature, voltages, curent, rates etc., performs statistics collections, calculations and logging and much more. The daemon can be installed through the standard system software management tools (such as apt) from our [https://archive.muonpi.org package repository] or compiled from the [https://github.com/MuonPi/muondetector github source] and is everything which is needed to operate a MuonPi detector.
* '''muondetector-gui''' A graphical user interface (GUI) program which can be launched on any computer in the same network as the MuonPi detector in order to monitor and adjust all operation parameters of the detector, if required. The GUI is available for [https://archive.muonpi.org download] as binary package for several platforms (Raspbian, Ubuntu, Windows) or can be compiled from the current [https://github.com/MuonPi/muondetector github master branch].
* '''muondetector-login''' A small command line helper tool to initially set up the MQTT telemetry link. The program will ask for the supplied MQTT credentials and stores them locally in encrypted form for continuous use.
* '''muondetector-cluster''' Allows the operation of a multi-detector cluster as an entity. The program is the cluster head or interface towards the server, searches for coincidences within the cluster and sends the combined coincidence events instead of the single event telegrams to the server. This tool is in development phase with more information about it's utilization to come in near future.

= Setup and Operation of the Detector =
Here you find a collection of HOW-TOs useful to set-up and operate a detector:

*[[The Detector|How to assemble the detector plates]]

*[[Assembly Guide|MuonPi HAT assembly guide]]

*[[Hardware Setup|How to set up the detector hardware]]

*[[Raspberry Pi Setup|How to install and set up the MuonPi software]]

*[[MuonPi - Grafana|How to view your detector data using Grafana]]

*Detector Surveillance through a [[MuonPi Telegram Bot|Telegram Bot]]

The completed setup is fairly insensitive to the location where it will operate.
Basic requirement is a good GPS signal, low humidity and obviously power and network connectivity.
A stable temperature for the scintillator and preamp is desirable, as it affects the noise level of the setup.
Muons will penetrate several meters of granite rock, so placing the detector in the basement leaves the muon measurements unaffected.
However due to radon collection in basement rooms and potassium decay a slightly higher natural radioactive background can be observed.

In case there are problems with the set-up or operation of the detector, have a look in the [[Troubleshooting]] section.

= Related Articles =

[[News and articles]] about cosmic rays and similar projects.

= Other languages =

* [[Main Page/de]]

= Admin Area =

Useful [[resources]] for admins.

= [[user detectors gallery|Gallery of Users' Detectors]] =

= About this Wiki =
* How to edit? [[help for creators]]
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings List of config variables]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailing list of new MediaWiki version announcements]

----
Sandbox page for testing/playing:
* [[Sandbox]]

Main Page

2021-02-09T20:03:01Z

Simonglm: /* Gallery of Users' Detectors */ Added photo of a user setup

= The MuonPi Cosmic Detector Project =
The MuonPi Project is a [https://www.raspberrypi.org/ RaspberryPi]-based system using an inexpensive plastic [[Scintillator|scintillator]] + [[Silicon photomultiplier|SiPM]] photo sensor to detect muons from cosmic air showers with a time-stamping accuracy of several tens of nanoseconds utilizing the [https://www.u-blox.com/en/product/neo-m8-series u-blox NEO-M8N GNSS] module's "timemark" feature.

==== Learn about cosmic radiation ====
* Get started with [[Cosmic Rays]], especially [[Muon]]s

*[https://www.vox.com/the-highlight/2019/7/16/17690740/cosmic-rays-universe-theory-science Extremely powerful cosmic rays are raining down on us. No one knows where they come from.] But with large-scale experiments, scientists around the world are determined to find out. ''Vox'' Jul 25, 2019

*[https://home.cern/science/physics/cosmic-rays-particles-outer-space Cosmic rays: particles from outer space] Earth is subject to a constant bombardment of subatomic particles that can reach energies far higher than the largest machines. ''CERN''

* [https://www.weltderphysik.de/mediathek/podcast/kosmische-strahlung/ "Kosmische Strahlung"] Podcast (in German) on [https://www.weltderphysik.de weltderphysik.de]
* [https://www.weltderphysik.de/thema/bmbf/astro-undastroteilchenphysik/der-kosmischen-strahlung-auf-der-spur/ "Der kosmischen Strahlung auf der Spur"] article (in German) on [https://www.weltderphysik.de weltderphysik.de]
* [https://www.weltderphysik.de/gebiet/universum/news/2017/kosmische-teilchen-mit-extragalaktischem-ursprung/ "Kosmische Teilchen mit extragalaktischem Ursprung"] article (in German) on [https://www.weltderphysik.de weltderphysik.de]

==== Learn about the detectors ====
* Basics of [[Scintillator]]s
* Find out about [[Silicon photomultiplier|Silicon Photomultipliers]]
* How our [[The Detector|Detectors]] are assembled

==== Related and similar projects ====

* [http://cosmicpi.org/ CosmicPi]: A CERN-based project that aims to build the world's largest open-source distributed cosmic ray telescope.
* [https://www.hisparc.nl/en/ HiSPARC]: A distributed muon detection network aimed for high-schools and an experience of over 15 years.

= The Hardware =

=== SiPM PCB ===
The SiPM photo sensor which detects the dim light generated inside the scintillation detector is mounted on a small [[Sipm_board|SiPM board]]. Different numbers of SiPMs and read-out configurations can be realized through it's flexible design.

=== Preamplifier ===
The [[preamplifier]] is located in close vicinity to the [[sipm_board|SiPM photodetector board]] and amplifies the weak signals for transmission to the [[muonpi_board|MuonPi]] board, where they are further processed and evaluated.

=== The MuonPi-Board ===
The main signal processing, voltage generation and parameter monitoring and adjustment is done on the Raspberry Pi plug-on [[muonpi_board|MuonPi Board]]. The board's design is open source hardware and exhibits only commercially available off-the-shelf components which can be obtained from several distributors. With some soldering experience, the MuonPi HAT can be assembled utilizing a standard soldering equipment. A how-to guide and useful hints are available in the [[Assembly Guide|Assembly Guide]].

= The Software =
The MuonPi software collection is entirely open source and [https://github.com/MuonPi available on github]
It consists of several components:
* '''muondetector-daemon''' The main control program running as a background system service on the RPi. The daemon configures, controls and supervises the components on the MuonPi HAT board, handles the comunication to the u-Blox chip and to the outside world via MQTT link and direct access socket, monitors system parameters, such as temperature, voltages, curent, rates etc., performs statistics collections, calculations and logging and much more. The daemon can be installed through the standard system software management tools (such as apt) from our [https://archive.muonpi.org package repository] or compiled from the [https://github.com/MuonPi/muondetector github source] and is everything which is needed to operate a MuonPi detector.
* '''muondetector-gui''' A graphical user interface (GUI) program which can be launched on any computer in the same network as the MuonPi detector in order to monitor and adjust all operation parameters of the detector, if required. The GUI is available for [https://archive.muonpi.org download] as binary package for several platforms (Raspbian, Ubuntu, Windows) or can be compiled from the current [https://github.com/MuonPi/muondetector github master branch].
* '''muondetector-login''' A small command line helper tool to initially set up the MQTT telemetry link. The program will ask for the supplied MQTT credentials and stores them locally in encrypted form for continuous use.
* '''muondetector-cluster''' Allows the operation of a multi-detector cluster as an entity. The program is the cluster head or interface towards the server, searches for coincidences within the cluster and sends the combined coincidence events instead of the single event telegrams to the server. This tool is in development phase with more information about it's utilization to come in near future.

= Setup and Operation of the Detector =
Here you find a collection of HOW-TOs useful to set-up and operate a detector:

*[[The Detector|How to assemble the detector plates]]

*[[Assembly Guide|MuonPi HAT assembly guide]]

*[[Hardware Setup|How to set up the detector hardware]]

*[[Raspberry Pi Setup|How to install and set up the MuonPi software]]

*[[MuonPi - Grafana|How to view your detector data using Grafana]]

*Detector Surveillance through a [[MuonPi Telegram Bot|Telegram Bot]]

The completed setup is fairly insensitive to the location where it will operate.
Basic requirement is a good GPS signal, low humidity and obviously power and network connectivity.
A stable temperature for the scintillator and preamp is desirable, as it affects the noise level of the setup.
Muons will penetrate several meters of granite rock, so placing the detector in the basement leaves the muon measurements unaffected.
However due to radon collection in basement rooms and potassium decay a slightly higher natural radioactive background can be observed.

In case there are problems with the set-up or operation of the detector, have a look in the [[Troubleshooting]] section.

= Related Articles =

[[News and articles]] about cosmic rays and similar projects.

= Other languages =

* [[Main Page/de]]

= Admin Area =

Useful [[resources]] for admins.

= [[user detectors gallery|Gallery of Users' Detectors]] =
<div><ul>
<li style="display: inline-block; vertical-align: top;">
[[File:MuonPi-UserSetUp1.jpg|thumb|A users setup of the MuonPi detector next to the WiFi router. Althogh this is an EMI nightmare, the detector works unaffected]]</li>
</ul></div>

= About this Wiki =
* How to edit? [[help for creators]]
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings List of config variables]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailing list of new MediaWiki version announcements]

----
Sandbox page for testing/playing:
* [[Sandbox]]

File:MuonPi-UserSetUp1.jpg

2021-02-09T20:00:14Z

Simonglm:

MuonPi user setup

Sipm board

2021-02-09T19:49:04Z

Simonglm: Changed redirect target from SiPM Board to SiPM board

#REDIRECT[[SiPM_board]]

Sipm board

2021-02-09T19:48:46Z

Simonglm: Redirect

#REDIRECT[[SiPM_Board]]

Vorverstärker

2021-02-09T19:40:56Z

Simonglm: Fixed broken Link

Der Vorverstärker verstärkt die sehr kleine Signalamplitude des SiPMs um ~20dB und sollte möglichst nahe am SiPM selbst platziert werden, um ein akzeptables Signal-Rausch-Verhältnis (SNR) zu erhalten. Daher wurde eine Aufsteckplatine für das [[SiPM_board | SiPM Board]] im gleichen Formfaktor entworfen, die möglichst vielseitig sein soll, um sich für unterschiedliche Auslesekonzepte mit folgenden Eigenschaften anzupassen:
* Zuführung der SiPM-Vorspannung durch den Vorverstärker einschließlich Vorspannungsfilter
* AC-Kopplung des Vorstufeneingangs
* Basierend auf rauscharmem Infineon MMIC [https://www.infineon.com/cms/en/product/rf-wireless-control/low-noise-amplifier-lna-ics/general-purpose-lnas/bga614/ BGA614]
* Montagemöglichkeit für eine (Default, positiver Ausgang) oder zwei MMIC-Stufen (negativer Ausgang)
* Optionen für die Spannungsversorgung des Vorverstärkers (+5V): entweder über separaten Anschluss (J2) oder Fernspeisung über das Ausgangssignal (Default)

[[File:Preamp V3-1.jpg|thumb|640px|right|Schaltplan des Vorverstärkers]]

Für die verschiedenen Betriebsarten werden folgende '''Montageoptionen''' angeboten (nicht erwähnte Komponenten sind identisch wie im Schaltplan angegeben oder wie in der Standardoption):

'''Standard (einstufig, Fernspeisung)'''
* nicht montieren: IC2, C5, C6, L4, R5, C7, J2, J5
* montieren: R7 (0R), R6 (0R), C2 (0R), verbinde IC2 pins 1 zu 3 (z. B. mit kantenmontiertem 0R-Widerstand)

'''Dual-stage'''
* montieren: IC2, R6/C7 = Pol-Null-Korrektur-Netzwerk (z.B. 47R/22p)

'''Separater Anschluss der Spannungsversorgung'''
* nicht montieren: L3
* montieren: J2

'''Floating-Bias-Spannungsversorgung''' (galvanisch getrennt von Signal-GND)
* nicht montieren: R7
* montieren: C5, C6

'''Allzweck 50Ω HF-Verstärker''' (kein SiPM, Signaleingang über u.Fl-Buchse J5)
* nicht montieren: J1, J3, R1, R2, L2
* montieren: J5

[[File:Preamp sipm pcbs mounted.JPG|thumb|left|montierte Vorverstärker- (oben) und Fotosensor PCBs (unten) mit einem instrumentierten SiPM]]
[[File:Preamp_detail1.png|thumb|left|Montierter Vorverstärker, der auf die Stiftleisten der SiPM-Platine einer montierten Detektorplatte gesteckt wird]]

SiPM board

2021-02-09T19:36:54Z

Simonglm: Simonglm moved page Sipm board to SiPM board without leaving a redirect: Capitalisation

The SiPM board is a printed circuit board (PCB) designed to dock and process the signal from the SiPM-scintillator coupling into a readout. Ideally no information such as timing from the scintillator should be lost, and the signal could be amplified/ processed with the board. In some applications involving significant temperature fluctuations, a compensator could also be built into the board. For the Muonpi project, the board should just be able to dock the SiPM-scintillator coupling to the readout.

The circuit configuration of the PCB varies depending on the number of SiPM's it needs to accommodate. For housing a single [https://www.ketek.net/wp-content/uploads/2017/01/KETEK-PM3325-EB-PM3350-EB-Datasheet.pdf Ketek PM3350-EB] SiPM the configuration is to just connect it with ground and readout/ bias. However, for connecting multiple SiPM's there are two possible configurations: parallel (p) and hybrid (h) configuration as illustrated below.

[[File:Jepretan Layar 2020-06-23 pukul 4.23.54 PM.png|thumb|Parallel (p) and hybrid (h) configuration of SiPM board <ref>[S. Zimmermann. The panda barrel-tof detector. DPG-Frühjahrstagung, Münster. Austrian Academy of Sciences, Stefan Meyer Insitute for Subatomic Physics, 28th of March, 2017.]</ref>. The signal path is depicted in red, the bias current in green, and the ground in blue.]]

Both configurations are quite similar in term of performance, with the hybrid configuration having a slightly faster rising edge (by a few ns <ref>[L. Nies, H. G. Zaunick, & K.-T. Brinkmann. Development of a SiPM-based readout-module for the characterization of various scintillator materials. arXiv. (2018). </ref>). The signal amplitude for the hybrid configuration decreases by a factor of <math>\frac{1}{\sqrt{N}}</math> where N the number of SiPM, whereas the signal amplitude does not change for parallel configuration. However, the timing of the parallel configuration also decreases with the number of connected SiPM's; hence, for applications that are very time sensitive, the hybrid configuration might be necessary. Moreover, the hybrid configuration has more complexity, which might make the configuration more expensive to produce. Therefore for simplicity, the MuonPi project uses the parallel configuration. It keeps the simplicity while giving the option for adding SiPM further down the road. The schematic of the SiPM board for the MuonPi project is shown below.

<div><ul>
<li style="display: inline-block; vertical-align: top;"> [[File:SiPMBoard.png|thumb|none|300px|Schematic of the SiPM board used in the Muonpi project<ref>[L. Nies, “Development of a sipm-based readout-module for the characterization of various scintillation materials (bachelor’s thesis),” (August 2017).]</ref>]] </li>
<li style="display: inline-block; vertical-align: top;"> [[File:Sipm pcb unmounted.png|thumb|none|300px|Photograph of unmounted SiPM PCB V2.1]] </li>
<li style="display: inline-block; vertical-align: top;"> [[File:Sipm_pcb_parts.png|thumb|none|300px|Photograph of a mounted SiPM PCB V2.1 with single SiPM (default configuration), rubber spacer and reflective foil]] </li>
</ul></div>

SiPM board

2021-02-09T19:34:08Z

Simonglm: Fixed Naming inconsistencies

SiPM board

2021-02-09T19:29:22Z

Simonglm: Fixed Layout error

The SiPM board is a printed circuit board (PCB) designed to dock and process the signal from the SiPM-scintillator coupling into a readout. Ideally no information such as timing from the scintillator should be lost, and the signal could be amplified/ processed with the board. In some applications involving significant temperature fluctuations, a compensator could also be built into the board. For the Muonpi project, the board should just be able to dock the SiPM-scintillator coupling to the readout.

The circuit configuration of the PCB varies depending on the number of SiPM's it needs to accommodate. For housing a single [https://www.ketek.net/wp-content/uploads/2017/01/KETEK-PM3325-EB-PM3350-EB-Datasheet.pdf Ketek PM3350-EB] SiPM the configuration is to just connect it with ground and readout/ bias. However, for connecting multiple SiPM's there are two possible configurations: parallel (p) and hybrid (h) configuration as illustrated below.

[[File:Jepretan Layar 2020-06-23 pukul 4.23.54 PM.png|thumb|Parallel (p) and hybrid (h) configuration of SiPM board <ref>[S. Zimmermann. The panda barrel-tof detector. DPG-Frühjahrstagung, Münster. Austrian Academy of Sciences, Stefan Meyer Insitute for Subatomic Physics, 28th of March, 2017.]</ref>. The signal path is depicted in red, the bias current in green, and the ground in blue.]]

Both configurations are quite similar in term of performance, with the hybrid configuration having a slightly faster rising edge (by a few ns <ref>[Nies, L., Zaunick, H. G., & Brinkmann, K-. T.. Development of a SiPM-based readout-module for the characterization of various scintillator materials. arXiv. (2018). </ref>). The signal amplitude for the hybrid configuration decreases by a factor of <math>\frac{1}{\sqrt{N}}</math> where N the number of SiPM, whereas the signal amplitude does not change for parallel configuration. However, the timing of the parallel configuration also decreases with the number of connected SiPM's; hence, for applications that are very time sensitive, the hybrid configuration might be necessary. Moreover, the hybrid configuration has more complexity, which might make the configuration more expensive to produce. Therefore for simplicity, the Muonpi project uses the parallel configuration. It keeps the simplicity while giving the option for adding SiPM further down the road. The schematic of the SiPM board for the Muon Pi project is shown below.

<div><ul>
<li style="display: inline-block; vertical-align: top;"> [[File:SiPMBoard.png|thumb|none|300px|Schematic of the SiPM board used in the Muonpi project<ref>[L. Nies, “Development of a sipm-based readout-module for the characterization of various scintillation materials (bachelor’s thesis),” (August 2017).]</ref>]] </li>
<li style="display: inline-block; vertical-align: top;"> [[File:Sipm pcb unmounted.png|thumb|none|300px|Photograph of unmounted SiPM PCB V2.1]] </li>
<li style="display: inline-block; vertical-align: top;"> [[File:Sipm_pcb_parts.png|thumb|none|300px|Photograph of a mounted SiPM PCB V2.1 with single SiPM (default configuration), rubber spacer and reflective foil]] </li>
</ul></div>

SiPM board

2021-02-09T19:15:44Z

Simonglm: Added SiPM-Type and Link to Datasheet

The SiPM board is a printed circuit board (PCB) designed to dock and process the signal from the SiPM-scintillator coupling into a readout. Ideally no information such as timing from the scintillator should be lost, and the signal could be amplified/ processed with the board. In some applications involving significant temperature fluctuations, a compensator could also be built into the board. For the Muonpi project, the board should just be able to dock the SiPM-scintillator coupling to the readout.

The circuit configuration of the PCB varies depending on the number of SiPM's it needs to accommodate. For housing a single [https://www.ketek.net/wp-content/uploads/2017/01/KETEK-PM3325-EB-PM3350-EB-Datasheet.pdf Ketek PM3350-EB] SiPM the configuration is to just connect it with ground and readout/ bias. However, for connecting multiple SiPM's there are two possible configurations: parallel (p) and hybrid (h) configuration as illustrated below.

[[File:Jepretan Layar 2020-06-23 pukul 4.23.54 PM.png|thumb|Parallel (p) and hybrid (h) configuration of SiPM board <ref>[S. Zimmermann. The panda barrel-tof detector. DPG-Frühjahrstagung, Münster. Austrian Academy of Sciences, Stefan Meyer Insitute for Subatomic Physics, 28th of March, 2017.]</ref>. The signal path is depicted in red, the bias current in green, and the ground in blue.]]

Both configurations are quite similar in term of performance, with the hybrid configuration having a slightly faster rising edge (by a few ns <ref>[Nies, L., Zaunick, H. G., & Brinkmann, K-. T.. Development of a SiPM-based readout-module for the characterization of various scintillator materials. arXiv. (2018). </ref>). The signal amplitude for the hybrid configuration decreases by a factor of <math>\frac{1}{\sqrt{N}}</math> where N the number of SiPM, whereas the signal amplitude does not change for parallel configuration. However, the timing of the parallel configuration also decreases with the number of connected SiPM's; hence, for applications that are very time sensitive, the hybrid configuration might be necessary. Moreover, the hybrid configuration has more complexity, which might make the configuration more expensive to produce. Therefore for simplicity, the Muonpi project uses the parallel configuration. It keeps the simplicity while giving the option for adding SiPM further down the road. The schematic of the SiPM board for the Muon Pi project is shown below.

[[File:SiPMBoard.png| thumb| Schematic of the SiPM board used in the Muonpi project<ref>[L. Nies, “Development of a sipm-based readout-module for the characterization of various scintillation materials (bachelor’s thesis),” (August 2017).]</ref>]]

[[File:Sipm pcb unmounted.png|left|thumb|Photograph of unmounted SiPM PCB V2.1]]
[[File:Sipm_pcb_parts.png|center|thumb|Photograph of a mounted SiPM PCB V2.1 with single SiPM (default configuration), rubber spacer and reflective foil]]

Resource usage

2021-02-02T21:10:51Z

Simonglm: /* Network Resources */ Typo

== Hardware Resources ==
=== CPU ===
=== RAM ===
=== Disk I/O ===

== Network Resources ==
=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple: All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packet sizes over 45minutes]]

=== Used Ports ===
{| class="wikitable"
|-
! Port !! Application
|-
| 51508 || GUI connection
|-
| 8888 || pigpiod
|-
| 1883 (out) || MQTT message publish
|}

=== MQTT Packet ===
Detector telemetry and mesurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client with a short TCP message.

Generally two types of MQTT messages are send, the event message and the log message.

The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

The log messages consist of multiple MQTT messages packed into a single (sometimes two seperate) TCP packets

Example data of multiple MQTT packets being send to our data evaluation servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! Header text !! Event counter !! Header text !! Header text !! Header text
|-
| 1 || muonpi/data/user/0 || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/user/0 || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/user/0 || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/user/0 || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/user/0 || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/user/0 || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/user/0 || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

==== Log message ====
The log message contains various meta data about your MuonPi setup.

Example log message:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || GeoHash
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage accross sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (ellaborate in [[Privacy]])

Connectivity

2021-01-31T01:18:01Z

Simonglm: Redirect to subsection of Resources

#REDIRECT [[Resource usage#Network Resources]]

Resource usage

2021-01-31T01:14:13Z

Simonglm: Simonglm moved page Connectivity to Resource usage: Rename for more info on one page

== Hardware Resources ==
=== CPU ===
=== RAM ===
=== Disk I/O ===

== Network Resources ==
=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple:All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packetsizes over 45minutes]]

=== Used Ports ===
{| class="wikitable"
|-
! Port !! Application
|-
| 51508 || GUI connection
|-
| 8888 || pigpiod
|-
| 1883 (out) || MQTT message publish
|}

=== MQTT Packet ===
Detector telemetry and mesurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client with a short TCP message.

Generally two types of MQTT messages are send, the event message and the log message.

The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

The log messages consist of multiple MQTT messages packed into a single (sometimes two seperate) TCP packets

Example data of multiple MQTT packets being send to our data evaluation servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! Header text !! Event counter !! Header text !! Header text !! Header text
|-
| 1 || muonpi/data/user/0 || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/user/0 || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/user/0 || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/user/0 || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/user/0 || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/user/0 || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/user/0 || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

==== Log message ====
The log message contains various meta data about your MuonPi setup.

Example log message:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || GeoHash
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage accross sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (ellaborate in [[Privacy]])

Connectivity

2021-01-31T01:14:13Z

Simonglm: Simonglm moved page Connectivity to Resource usage: Rename for more info on one page

#REDIRECT [[Resource usage]]

Resource usage

2021-01-31T01:12:14Z

Simonglm: Restructuring for more comprehensive info on Resources in the future

== Hardware Resources ==
=== CPU ===
=== RAM ===
=== Disk I/O ===

== Network Resources ==
=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple:All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packetsizes over 45minutes]]

=== Used Ports ===
{| class="wikitable"
|-
! Port !! Application
|-
| 51508 || GUI connection
|-
| 8888 || pigpiod
|-
| 1883 (out) || MQTT message publish
|}

=== MQTT Packet ===
Detector telemetry and mesurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client with a short TCP message.

Generally two types of MQTT messages are send, the event message and the log message.

The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

The log messages consist of multiple MQTT messages packed into a single (sometimes two seperate) TCP packets

Example data of multiple MQTT packets being send to our data evaluation servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! Header text !! Event counter !! Header text !! Header text !! Header text
|-
| 1 || muonpi/data/user/0 || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/user/0 || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/user/0 || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/user/0 || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/user/0 || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/user/0 || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/user/0 || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

==== Log message ====
The log message contains various meta data about your MuonPi setup.

Example log message:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || GeoHash
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage accross sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (ellaborate in [[Privacy]])

Resource usage

2021-01-29T14:05:48Z

Simonglm: /* Used Ports */

WORK IN PROGRESS

Note: Explain how MuonPi uses the Network, Ports, etc.

== Network I/O ==
=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple:All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packetsizes over 45minutes]]

=== Used Ports ===
{| class="wikitable"
|-
! Port !! Application
|-
| 51508 || GUI connection
|-
| 1883 (out) || TCP/IP (MQTT)
|}

=== MQTT Packet ===
Detector telemetry and mesurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client with a short TCP message.

Generally two types of MQTT messages are send, the event message and the log message.

The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

The log messages consist of multiple MQTT messages packed into a single (sometimes two seperate) TCP packets

Example data of multiple MQTT packets being send to our data evaluation servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! Header text !! Event counter !! Header text !! Header text !! Header text
|-
| 1 || muonpi/data/user/0 || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/user/0 || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/user/0 || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/user/0 || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/user/0 || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/user/0 || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/user/0 || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

==== Log message ====
The log message contains various meta data about your MuonPi setup.

Example log message:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || GeoHash
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage accross sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (ellaborate in [[Privacy]])

Resource usage

2021-01-29T14:05:24Z

Simonglm: /* Used Ports */

WORK IN PROGRESS

Note: Explain how MuonPi uses the Network, Ports, etc.

== Network I/O ==
=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple:All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packetsizes over 45minutes]]

=== Used Ports ===
{| class="wikitable"
|-
! Header text !! Header text
|-
| 51508 || GUI connection
|-
| 1883 (out) || TCP/IP (MQTT)
|}

=== MQTT Packet ===
Detector telemetry and mesurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client with a short TCP message.

Generally two types of MQTT messages are send, the event message and the log message.

The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

The log messages consist of multiple MQTT messages packed into a single (sometimes two seperate) TCP packets

Example data of multiple MQTT packets being send to our data evaluation servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! Header text !! Event counter !! Header text !! Header text !! Header text
|-
| 1 || muonpi/data/user/0 || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/user/0 || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/user/0 || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/user/0 || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/user/0 || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/user/0 || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/user/0 || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

==== Log message ====
The log message contains various meta data about your MuonPi setup.

Example log message:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || GeoHash
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage accross sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (ellaborate in [[Privacy]])

Resource usage

2021-01-29T14:01:34Z

Simonglm: /* Used Ports */

WORK IN PROGRESS

Note: Explain how MuonPi uses the Network, Ports, etc.

== Network I/O ==
=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple:All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packetsizes over 45minutes]]

=== Used Ports ===
{| class="wikitable"
|-
! Header text !! Header text
|-
| 51508 || GUI connection
|-
| 50500 || TCP/IP (MQTT)
|}

=== MQTT Packet ===
Detector telemetry and mesurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client with a short TCP message.

Generally two types of MQTT messages are send, the event message and the log message.

The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

The log messages consist of multiple MQTT messages packed into a single (sometimes two seperate) TCP packets

Example data of multiple MQTT packets being send to our data evaluation servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! Header text !! Event counter !! Header text !! Header text !! Header text
|-
| 1 || muonpi/data/user/0 || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/user/0 || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/user/0 || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/user/0 || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/user/0 || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/user/0 || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/user/0 || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

==== Log message ====
The log message contains various meta data about your MuonPi setup.

Example log message:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || GeoHash
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage accross sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (ellaborate in [[Privacy]])

Raspberry Pi Setup

2021-01-29T13:47:55Z

Simonglm: /* Initial Setup */ hehe my bad

This article will introduce to you, how to set up a Raspberry Pi from scratch with all software needed to run the detector hardware.

DISCLAIMER: If not stated otherwise, this tutorial is developed on Raspian 10 Buster.

__TOC__

= Initial Setup =
(Requirements: Raspberry Pi Versions 0, 2, 3, 4 (with 40-pin GPIO connector) )
* Create a fresh install of Raspbian Buster operating system e.g. from [https://www.raspberrypi.org/downloads/raspberry-pi-os/ here] on microSD card (any version with or without desktop). For an headless install (without monitor and mouse/keyboard), we recommend following this [https://www.raspberrypi.org/documentation/configuration/wireless/headless.md guide].
* Change the default password of the user "pi". This is strongly recommended, since connections through ssh will be enabled in the next step which should always have a strong authentication metric. Change it with <code>sudo raspi-config</code> >> Change User Password or on the command line with <code>passwd</code>
* '''Enable the serial interface''' (UART) and '''disable the login shell''' via the UART. In terminal: <code>sudo raspi-config</code> >> Interfacing Options >> Serial >> Login shell over serial: No >> Enable serial hardware: Yes
* Enable I2C Interface: In terminal: <code>sudo raspi-config</code> >> Interfacing Options >> I2C >> Enable: Yes >> Reboot optional
* Enable SSH: The SSH protocol is needed if you want to remotely configure your headless Raspberry Pi. In a terminal: <code>sudo raspi-config</code> >> Interfacing Options >> SSH >> Enable: Yes >> Reboot
* Configure the network connection: By default, the RPi is configured to automatically obtain an IP address when a connection is available and DHCP in your local network is active (this should be the case for most local/home networks).
* If you prefer a fixed IP address in a local network: edit the file /etc/dhcpcd.conf. Use the template and uncomment the "Example Static IP Configuration" section with your desired IP address.
* If network access should be established via WiFi, either configure it via the network configuration wizard in the graphical desktop environment (usually network icon in the system bar), or manually following these steps (either method is fine):
** Make sure that the wpa_supplicant package is installed:<code>sudo apt install wpasupplicant</code>
** edit the file /etc/wpa_supplicant/wpa_supplicant.conf:<code>sudo nano /etc/wpa_supplicant/wpa_supplicant.conf</code>
the configuration should look like this (non-relevant lines not shown):

update_config=1
country=DE</br>
network={
ssid="<your network ssid>"
psk="<your wifi password>"
key_mgmt=WPA-PSK
}
Enter your WiFi's SSID and password in the indicated fields.
Finally, restart the system that the changes take effect.
Optionally, update your system by:
sudo apt update && sudo apt upgrade

You should have a fully configured Raspbian system by now and are ready-to-go to set up the MuonPi in the next step.

= MuonPi Setup =
(Requirements: a MuonPi board plugged onto the GPIO connector of the RPi)
* First, add the MuonPi apt repository to your system:
wget -qO - <nowiki>https://archive.muonpi.org/muondetector.public.key</nowiki> | sudo apt-key add -

sudo sh -c "echo deb <nowiki>https://archive.muonpi.org/raspbian buster main</nowiki> > /etc/apt/sources.list.d/muondetector.list"
* Update the repositories:
sudo apt update
* Install the muondetector-daemon package and it's dependencies:
sudo apt install muondetector-daemon
* Optional: install the Graphical User Interface (GUI) program to monitor and control the MuonPi locally
sudo apt install muondetector-gui
* The GUI can connect to the MuonPi over network as well, so it can be installed on other computers in the local network. Currently, binary packages for Raspbian, Ubuntu and Windows are available. The Linux-based versions can be installed from the package repositories (execute steps 1,2 and 4 from this list). The Windows program can be downloaded directly from https://archive.muonpi.org and installed by simply unpacking the zip-archive.

= Configuration and Start =

Now the installation of the muondetector-daemon should be adapted to your setup:

== Configuration ==
Edit the configuration file /etc/muondetector/muondetector.conf: <code>nano /etc/muondetector/muondetector.conf</code>.
Change the settings according to your needs or leave them untouched, if unsure. The comments in the config file should guide you through any required modifications. One option, however, describes the placement of your detector. If you like, choose a stationID descriptor, eg.:</br>
(file: <code>/etc/muondetector/muondetector.conf</code>)
<nowiki>#</nowiki> A unique identifier of the user's station
<nowiki>#</nowiki> leave on default when the user operates a single station
<nowiki>#</nowiki> all detectors of the user are distinguishable on the basis of this id
stationID = "HomeOffice"

(anything which best describes the location of your detector like e.g. "GarageSW", "Bldg16Lab105", "AtticNE"). If you operate only one stationary detector, it may as well be left on the default ID which is "0" (zero).

'''Important''': When operating multiple detectors (under the same user account, see below) the stationID descriptor '''must''' be unique for each detector.

== Login with your user credentials (only once) ==

Before taking the MuonPi detector into operation, you have to set your credentials for publishing data messages to the server via [http://mqtt.org/ MQTT] protocol on first start. This can be managed in two ways, one secure and one where your credentials appear as plain text in the config file:
==== The Recommended Method ====
In a bash shell on the MuonPi, run the command <code>muondetector-login</code>.

'''Note that for the software version 2.0.0 the command to run is <code>sudo runuser -u muonuser -- muondetector-login</code> instead.'''

When asked for sudo access, enter the password of your raspberry pi user.
When asked for your user name and password, enter the credentials supplied to you by a MounPi.org official. The credentials are stored (not in clear text) for all further telemetry connections.

==== Alternative Method ====
Uncomment the <code>mqtt_user</code> and <code>mqtt_password</code> options in <code>/etc/muondetector/muondetector.conf</code> and type your personal username and password into these fields between the quotation marks. Be aware, that these credentials are written in plain text into this file and can be retrieved by malware attacks. However, if you operate a station inside a home network and set up a strong ssh authentication (see above), you should be relatively safe.

== Start the Daemon ==
The daemon should be enabled and started automatically after installation and on every reboot. However, when changing items in the config file, the changes have to be made effective by a daemon restart:
sudo systemctl restart muondetector-daemon.service

To see the current status of the daemon service use following command:
systemctl status muondetector-daemon.service

It can happen that the status shows 'failed' in red, usually a restart of the daemon service resolves this.

If the service should not enable itself by default the status shows a grey 'not loaded'. To enable the service use:
sudo systemctl enable muondetector-daemon.service

Resource usage

2021-01-27T13:49:31Z

Simonglm: /* MQTT Packet */ annonymised

WORK IN PROGRESS

Note: Explain how MuonPi uses the Network, Ports, etc.

== Network I/O ==
=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple:All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packetsizes over 45minutes]]

=== Used Ports ===
51508 gui
50500 TCP/IP (MQTT)

=== MQTT Packet ===
Detector telemetry and mesurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client with a short TCP message.

Generally two types of MQTT messages are send, the event message and the log message.

The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

The log messages consist of multiple MQTT messages packed into a single (sometimes two seperate) TCP packets

Example data of multiple MQTT packets being send to our data evaluation servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! Header text !! Event counter !! Header text !! Header text !! Header text
|-
| 1 || muonpi/data/user/0 || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/user/0 || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/user/0 || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/user/0 || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/user/0 || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/user/0 || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/user/0 || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

==== Log message ====
The log message contains various meta data about your MuonPi setup.

Example log message:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || GeoHash
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage accross sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (ellaborate in [[Privacy]])

Resource usage

2021-01-27T13:15:28Z

Simonglm: /* MQTT Packet */

WORK IN PROGRESS

Note: Explain how MuonPi uses the Network, Ports, etc.

== Network I/O ==
=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple:All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packetsizes over 45minutes]]

=== Used Ports ===
51508 gui
50500 TCP/IP (MQTT)

=== MQTT Packet ===
Detector telemetry and mesurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client with a short TCP message.

Generally two types of MQTT messages are send, the event message and the log message.

The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| '''Total''' || '''150 byte'''
|}

The log messages consist of multiple MQTT messages packed into a single (sometimes two seperate) TCP packets

Example data of multiple MQTT packets being send to our data evaluation servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! Header text !! Event counter !! Header text !! Header text !! Header text
|-
| 1 || muonpi/data/simonglm/0 || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/simonglm/0 || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/simonglm/0 || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/simonglm/0 || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/simonglm/0 || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/simonglm/0 || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/simonglm/0 || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

==== Log message ====
The log message contains various meta data about your MuonPi setup.

Example log message:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || GeoHash
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage accross sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (ellaborate in [[Privacy]])

Resource usage

2021-01-27T03:58:51Z

Simonglm: Basic documentation of MQTT communication IO-rates and packet size statistic as well as packet content

WORK IN PROGRESS

Note: Explain how MuonPi uses the Network, Ports, etc.

== Network I/O ==
=== Data rate ===
The MuonPi detector board will send measurement data to our data evaluation servers, the rate of which greatly depends on the exact event rate.
In a proper setup these messages will average out to roughly 600 messages per minute with an average size of 110 bytes.
This however includes the acknowledgement packets which account for two thirds of the number of packets but they are only small in size (>150 bytes).
[[File:Muonpi-iorate.png |thumb|Purple:All messages send between the MuonPi unit and muonpi.org <br>
Green: Only MQTT publish messages, excluding acknowledgement messages]]
[[File:Muonpi-packetsize.png|thumb|Histogram of packetsizes over 45minutes]]

=== Used Ports ===
51508 gui
50500 TCP/IP (MQTT)

=== MQTT Packet ===
Detector telemetry and mesurement data is send to our servers via the MQTT protocol.
Upon receiving a MQTT message from the client our servers respond with an MQTT acknowledgment packet which is in turn acknowledged by the client with a short TCP message.

Generally two types of MQTT messages are send, the event message and the log message.

The event messages consist of the following:
{| class="wikitable"
|-
! Type !! Size
|-
| Ethernet frame || 14 byte
|-
| IP4 Header || 20 byte
|-
| TCP Header || 32 byte
|-
| MQTT message || 84 byte
|-
| Total || 150 byte
|}

The log messages consist of multiple MQTT messages packed into a single (sometimes two seperate) TCP packets

Example data of multiple MQTT packets being send to our data evaluation servers:
{| class="wikitable"
|-
! # !!MQTT topic !! timestamp (rising edge) !! timestamp (falling edge) !! Header text !! Event counter !! Header text !! Header text !! Header text
|-
| 1 || muonpi/data/simonglm/0 || 1611698307.895514697 || 1611698307.895515885 || 70 || 35109 || 1 || 2 || 1
|-
| 2 || muonpi/data/simonglm/0 || 1611698307.912153060 || 1611698307.912154247 || 70 || 35110 || 1 || 2 || 1
|-
| 3 || muonpi/data/simonglm/0 || 1611698308.237550951 || 1611698308.237552160 || 70 || 35111 || 1 || 2 || 1
|-
| 4 || muonpi/data/simonglm/0 || 1611698308.404480192 || 1611698308.404481380 || 70 || 35112 || 1 || 2 || 1
|-
| 5 || muonpi/data/simonglm/0 || 1611698308.699026112 || 1611698308.699027299 || 70 || 35113 || 1 || 2 || 1
|-
| 6 || muonpi/data/simonglm/0 || 1611698309.048519516 || 1611698309.048520724 || 70 || 35114 || 1 || 2 || 1
|-
| 7 || muonpi/data/simonglm/0 || 1611698309.133318449 || 1611698309.133319657 || 70 || 35115 || 1 || 2 || 1
|}

==== Log message ====
The log message contains various meta data about your MuonPi setup.

Example log message:
{| class="wikitable"
|-
! MQTT topic !! Date and Time !! Variable !! Value !! Unit !! Description
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || RXBufUsage || 0.0000000 || % || Buffer usage incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || TXBufUsage || 0.0000000 || % || Buffer usage outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || adcSamplingTime || 2.4608333 || ms ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaPower || 1.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || antennaStatus || 2 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockBias || -319713.3333333 || ns || Offset of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || clockDrift || -440.3333333 || ns/s || Drift of GNSS clock
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatus || 3 || || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || fixStatusString || 3D-Fix || ms || GNSS fix status
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || freqAccuracy || 265.0000000 || ps/s ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHash || u0ypy122vb || || GeoHash
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHeightMSL || 177.8400000 || m || Height above mean sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoHorAccuracy || 1.2220000 || m || Horizontal GNSS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLatitude || 50.5000000 || deg || Location latitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoLongitude || 8.7000000 || deg || Location longitude
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || geoVertAccuracy || 0.8540000 || m || Vertical GPS accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ibias || 10.2492675 || uA || Bias current for SiPMs
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || jammingLevel || 9.0000000 || % || Jamming level of GPS antenna
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxCNR || 43.0000000 || dB || Carrier to noise ratio
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxRXBufUsage || 25 || % || maximum buffer usage for incoming messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || maxTXBufUsage || 4 || % || maximum buffer usage for outgoing messages
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || meanGeoHeightMSL || 185.35 || m || mean height above sea level
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || positionDOP || 1.7333333 || || position dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampAGC || 1482.0000000 || ||
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || preampNoise || -87.0000000 || dBHz || noise level of SiPM preamp
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateAND || 0.0000000 || Hz || event rate (AND)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || rateXOR || 3.0525173 || Hz || event rate (XOR)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || sats || 20.7777778 || || number of GNSS satellites
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeMem || 815.3660000 || Mb || free memory space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemFreeSwap || 104.8540000 || Mb || free swap space in host system
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemLoadAvg || 0.2758790 || || average CPU load
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || systemUptime || 2.6875 || h || uptime
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || temperature || 41.5104167 || degC || Temperature (on PCB)
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeAccuracy || 31.5000000 || ns || event timing accuracy
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || timeDOP || 0.9233333 || || timing dilution of precision
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || ubloxUptime || 9771 || s || UBlox uptime in seconds
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || usedSats || 11.6666667 || || number of satellites in use
|-
| muonpi/log/v/0 || 2021-01-26_22-08-43 || vbias || 31.6119833 || V || SiPM bias voltage
|-
| muonpi/log/user/0 || 2021-01-26_22-08-43 || vsense || 0.2405174 || V || Voltage accross sensing resistor
|}

The only privacy sensitive information contained in these messages are the geolocation and ambient temperature. (ellaborate in [[Privacy]])

File:Muonpi-packetsize.png

2021-01-27T03:56:29Z

Simonglm:

Statistic of packetsize in MQTT communication

File:Muonpi-iorate.png

2021-01-27T03:05:50Z

Simonglm:

Graph of I/O-rate of MuonPi communication
MQTT messages + MQTT acknowledge + TCP acknowledge in purple and only MQTT messages in green

Main Page

2021-01-05T19:41:15Z

Simonglm: /* Setup and Operation of the Detector */ Added some comments about choosing a detector location.

= The MuonPi Cosmic Detector Project =
The MuonPi Project is a [https://www.raspberrypi.org/ RaspberryPi]-based system using an inexpensive plastic [[Scintillator|scintillator]] + [[Silicon photomultiplier|SiPM]] photo sensor to detect muons from cosmic air showers with a time-stamping accuracy of several tens of nanoseconds utilizing the [https://www.u-blox.com/en/product/neo-m8-series u-blox NEO-M8N GNSS] module's "timemark" feature.

==== Learn about cosmic radiation ====
* Get started with [[Cosmic Rays]], especially [[Muon]]s

*[https://www.vox.com/the-highlight/2019/7/16/17690740/cosmic-rays-universe-theory-science Extremely powerful cosmic rays are raining down on us. No one knows where they come from.] But with large-scale experiments, scientists around the world are determined to find out. ''Vox'' Jul 25, 2019

*[https://home.cern/science/physics/cosmic-rays-particles-outer-space Cosmic rays: particles from outer space] Earth is subject to a constant bombardment of subatomic particles that can reach energies far higher than the largest machines. ''CERN''

* [https://www.weltderphysik.de/mediathek/podcast/kosmische-strahlung/ "Kosmische Strahlung"] Podcast (in German) on [https://www.weltderphysik.de weltderphysik.de]
* [https://www.weltderphysik.de/thema/bmbf/astro-undastroteilchenphysik/der-kosmischen-strahlung-auf-der-spur/ "Der kosmischen Strahlung auf der Spur"] article (in German) on [https://www.weltderphysik.de weltderphysik.de]
* [https://www.weltderphysik.de/gebiet/universum/news/2017/kosmische-teilchen-mit-extragalaktischem-ursprung/ "Kosmische Teilchen mit extragalaktischem Ursprung"] article (in German) on [https://www.weltderphysik.de weltderphysik.de]

==== Learn about the detectors ====
* Basics of [[Scintillator]]s
* Find out about [[Silicon photomultiplier|Silicon Photomultipliers]]
* How our [[The Detector|Detectors]] are assembled

= The Hardware =

=== SiPM PCB ===
The SiPM photo sensor which detects the dim light generated inside the scintillation detector is mounted on a small [[Sipm_board|SiPM board]]. Different numbers of SiPMs and read-out configurations can be realized through it's flexible design.

=== Preamplifier ===
The [[preamplifier]] is located in close vicinity to the [[sipm_board|SiPM photodetector board]] and amplifies the weak signals for transmission to the [[muonpi_board|MuonPi]] board, where they are further processed and evaluated.

=== The MuonPi-Board ===
The main signal processing, voltage generation and parameter monitoring and adjustment is done on the Raspberry Pi plug-on [[muonpi_board|MuonPi Board]]. The board's design is open source hardware and exhibits only commercially available off-the-shelf components which can be obtained from several distributors. With some soldering experience, the MuonPi HAT can be assembled utilizing a standard soldering equipment. A how-to guide and useful hints are available in the [[Assembly Guide|Assembly Guide]].

= The Software =
The MuonPi software collection is entirely open source and [https://github.com/MuonPi available on github]
It consists of several components:
* '''muondetector-daemon''' The main control program running as a background system service on the RPi. The daemon configures, controls and supervises the components on the MuonPi HAT board, handles the comunication to the u-Blox chip and to the outside world via MQTT link and direct access socket, monitors system parameters, such as temperature, voltages, curent, rates etc., performs statistics collections, calculations and logging and much more. The daemon can be installed through the standard system software management tools (such as apt) from our [https://archive.muonpi.org package repository] or compiled from the [https://github.com/MuonPi/muondetector github source] and is everything which is needed to operate a MuonPi detector.
* '''muondetector-gui''' A graphical user interface (GUI) program which can be launched on any computer in the same network as the MuonPi detector in order to monitor and adjust all operation parameters of the detector, if required. The GUI is available for [https://archive.muonpi.org download] as binary package for several platforms (Raspbian, Ubuntu, Windows) or can be compiled from the current [https://github.com/MuonPi/muondetector github master branch].
* '''muondetector-login''' A small command line helper tool to initially set up the MQTT telemetry link. The program will ask for the supplied MQTT credentials and stores them locally in encrypted form for continuous use.
* '''muondetector-cluster''' Allows the operation of a multi-detector cluster as an entity. The program is the cluster head or interface towards the server, searches for coincidences within the cluster and sends the combined coincidence events instead of the single event telegrams to the server. This tool is in development phase with more information about it's utilization to come in near future.

= Setup and Operation of the Detector =
Here you find a collection of HOW-TOs useful to set-up and operate a detector:

*[[The Detector|How to assemble the detector plates]]

*[[Assembly Guide|MuonPi HAT assembly guide]]

*[[Hardware Setup|How to set up the detector hardware]]

*[[Raspberry Pi Setup|How to install and set up the MuonPi software]]

*[[MuonPi - Grafana|How to view your detector data using Grafana]]

*Detector Surveillance through a [[MuonPi Telegram Bot|Telegram Bot]]

The completed setup is fairly insensitive to the location where it will operate.
Basic requirement is a good GPS signal, low humidity and obviously power and network connectivity.
A stable temperature for the scintillator and preamp is desirable, as it affects the noise level of the setup.
Muons will penetrate several meters of granite rock, so placing the detector in the basement leaves the muon measurements unaffected.
However due to radon collection in basement rooms and potassium decay a slightly higher natural radioactive background can be observed.

In case there are problems with the set-up or operation of the detector, have a look in the [[Troubleshooting]] section.

= Related Articles =

[[News and articles]] about cosmic rays and similar projects.

= Other languages =

* [[Main Page/de]]

= Admin Area =

Useful [[resources]] for admins.

= About this Wiki =
* How to edit? [[help for creators]]
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings List of config variables]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailing list of new MediaWiki version announcements]

----
Sandbox page for testing/playing:
* [[Sandbox]]

Assembly Guide

2020-12-14T15:08:05Z

Simonglm:

This is a guide on how to populate our MuonPi-PCB, using the construction kit. You can get a kit or a fully assembled PCB by contacting us [http://www.muonpi.org/contact.html here].

All components in this kit (except for the pin headers) are surface-mount devices (SMD).
Most of these parts are only a few millimeters in size and are prone jump very far, should you slip with the tweezers.
Soldering these requires steady hands and a bit of technique, but this guide aims to help you with that.

== The Kit ==
The Kit contains all the parts you need to set up your very own particle detector using your Raspberry Pi.

Contents of the Kit are:
* The plastic scintillator (generously provided by [https://eljentechnology.com/ Eljen Technology])
* The bare printed circuit board ([[Muonpi board]])
* [https://en.wikipedia.org/wiki/Satellite_navigation GNSS] antenna
* Components to mount on the PCB (Resistors, Capacitors, Inductors, ICs, etc.)
* Bill of materials (BOM)

The individual components of the kit are glued to a nametag using tape, as can be seen in the picture.
[[File:Parts-packaging.jpg|thumb|Example of how parts in the detector PCB kit are packaged]]
Because of the size and difficulty labeling the parts, they are packaged using paper labels and clear tape.
Getting the parts out of their packaging has to be done quite carefully, as they are easy to lose.

== Tools ==
The bare essential tools are:
* soldering iron
* solder
* (metal) tweezers
* solder fume extractor
additional:
* flux
* solder wick
* vise or helping hands
* scalpel/scissors
* magnifying glass

Additionally, we recommend to choose a brightl workplace, as dim lights and small components can lead to eye strain and head aches.

Generally,the smaller the tip of your soldering iron is, the better, for small component soldering at least.
Of course if you have other solder tips, like ones with a solder depot, you can use those too.<br>
In any case whatever tools you need to get the job done, are the correct tools to use.

== Documentation ==
The schematic, layout and BOM of the current hardware version can be found on the [https://easyeda.com/MuonPi/cosmic_shower_detector_v1-52b8a2536bb6468e9f48412a774951d0_copy_copy easyEDA project page].
While soldering, finding the right pad, where a specific components has to go, can be quite difficult.
The labels on the PCB are small and space for them is very limited which makes some of them hard to read and find.
To help you find the correct solder pads, we recommend to have a computer nearby where you can open the [https://easyeda.com/editor#id=ad78628187d94b9cb54d8735233128d7 schematics] and use the search function.
Alternatively you can print out the layout that is attached on the easyEDA project page.

=== Mounting Options ===
The BOM specifies multiple mounting options, such as: "Full", "Single Channel", "External Bias Supply", "Fixed Input Polarity".
"External Bias Supply" and "Fixed Input Polarity" were used by us in the development and will not be discussed here further.
The default configuration of the kit contains only one scintillator, therefore only one channel of the detector electronics will be used at a time.
In that case, the "Single Channel" mounting option would be sufficient.
However the number of components in the kit follows the "Full" configuration, and mounting all components is still recommended.
Just mounting all the parts that are included in the kit will lead to a working PCB with both channels working.
Please [https://muonpi.org/contact.html contact us], if you are interested in a two scintillator setup.

== Assembly ==
First things first, you should setup your workspace with all parts layed out, along with the BOM and all the tools you might need.
Personally, I like to sort the parts into categories: Resistors, Capacitors, Inductors, ICs and others.
This helps to save time and gives a quick overview of your soldering progress.
In principle the choice which components to mount first comes down to personal preference.
A helpful guideline is to mount parts depending on their height.
Lower, smaller parts should be mounted first, as to not interfere too much in the later stages of assembly.
This is why the GPIO headers should be among the last components to be mounted.

Once you are set up, you can turn on your soldering iron and fume extractor and start soldering.

=== Tips on SMD soldering ===
SMD components are small and difficult to solder.
The easiest components to solder are the resistors and capacitors.
Start with these to get comfortable with SMD soldering first, then proceed to the more difficult ICs.<br>
A quick guide to SMD soldering can be found at [https://www.sparkfun.com/marcomm/SFE03-0010-KitCard-SolderingSMD-ReaderSpreads.pdf sparkfun.com].

Be careful with the tip of the iron and the PCB. Too much heat and scraping of the pads can remove the top layer from the PCB or even rip the pad off the PCB.
The later, depending on the pad this happens to, is very likely to completely brick the board and rendering it unusable.

=== Soldering Workflow ===
[[File:Closeup of one soldered pad and a resistor.jpg|thumb|left|Closeup of a pad with solder and a resistor]]
Take your BOM and choose one of the resistor/capacitor values to begin with and identify the pad label, where the part is supposed to be placed.
Now take your soldering iron and heat one side of the pad. After a couple of seconds of heating, add some solder to the pad.
Take out one of the components out of it's packaging and grab onto it with the tweezers as indicated in the picture on the right.
Heat the solder blob and slide the component into the molten solder from the side.
This ensures covering of the components contacts.
Placing the component into the blob from above can lead to solder bridges underneath the component, which will render the component useless.

Once one side of the component is fixed, it's good practice to lightly press down on the component and remelt the solder.
Doing this will help to mount the component flush to the board.
Although not always necessary, doing this will help to avoid solder bridges, especially between the legs of ICs.
[[File:Flush component.jpg|x300px|thumb|right|Component lifted on one side (top); pressed down and after remelting the solder (bottom)]]

It is a good idea to cross out the components on the BOM once they are soldered.
Should in the end a label on the BOM be left unmarked you can check to not miss any components.

When you are finished soldering all parts of one kind, pause and check you haven't missed any.
Only then move on to the next group of parts.

=== Integrated Circuits (ICs) ===
Once all passive Components are placed and double checked, we can move on to the integrated circuits.
Soldering these is considerably more difficult, especially the ADC and DAC (U401 & U402 in v3.x) have a very small pad pitch.
Solder bridges are almost unavoidable and need to be dealt with.

First, solder is added to one pad on a corner of the IC footprint.
Then, just like the passive components, the IC is moved into the molten solder.
It is very important to align all the legs of the IC on their respective pads.
Proceed to fix one of the other legs, preferably a leg on the diagonally opposite side.
The remaining unsoldered legs can now be soldered to the board.

If solder bridges are created, they need to be removed.
One possible method to remove solder bridges is the usage of flux.
Flux is a mixture of multiple compounds that remove and prevent build up of oxides on the solder blob.
Additionally it increases the surface tension of the molten solder and therefor promotes splitting of solder blobs.
So just using a good amount of flux can fix solder bridges.

However if there is too much solder on the pads, bridges cannot be fixed just using flux. In that case we need to remove some solder.
Solder wicks are very useful for this task as its tight copper webbing wicks up any excess solder.
Place the wick on the solder blob and using the hot soldering iron, press the wick on the solder from above.
After a while, once the wick is hot enough, the solder will melt and be picked up by the wick.
Remove the wick and soldering iron simultaneously, otherwise the wick will be soldered to the pad instead, and pulling on the wick in that case can rip the pad off of the PCB.

In the timelapse you might be able to catch, how I soldered the ADC and DAC (U401 & U402 in v3.x).
Since the pitch is very small and solder bridges are very likely, I didn't even bother trying to avoid them.
After fixing the IC in place on one leg, I added a lot of solder to all pins and pads in one big blob.
With the addition of flux, most of the solder was removed using the solder wick, in the hopes that some solder would remain under the legs.
On first sight it seemed to work, but testing of the board revealed that something did not work.
Knowing this technique is not 100% reliable, a quick reheat with careful addition of small amounts of solder fixed the issue and the board was fully operational.

{{#evt:service=youtube|id=E3kZMtjD76c|alignment=right|container=frame|description=Timelapse of IC soldering ([https://www.youtube.com/watch?v=E3kZMtjD76c link to youtube])|dimensions=480}}

=== Connectors ===
*'''SMA connectors:''' lots of heat
*'''UFL connectors:''' lots of solder

== Testing the board ==
'''How-To:'''
# Assemble the MuonPi-PCB as described in this guide
# [[Raspberry_Pi_Setup#MuonPi_Setup|Software Setup]]
# [[Hardware_Setup|Hardware Setup]]
To test your fully assembled board, follow the Software- and Hardware-Setup How-To.
Once everything is installed and connected your MuonPi is ready to boot.
Since the Version 2.0 of the muondetector-deamon will set default values for the thresholds and bias-voltage.
With these defaults the blue Ch1-LED should start flashing irregularly.
You are now seeing particles pass through your scintillator!

Assembly Guide

2020-12-12T21:37:57Z

Simonglm: /* Documentation */ Added reference to ibom.html

This is a guide on how to populate our MuonPi-PCB, using the construction kit. You can get a kit or a fully assembled PCB by contacting us [http://www.muonpi.org/contact.html here].

All components in this kit (except for the pin headers) are surface-mount devices (SMD).
Most of these parts are only a few millimeters in size and are prone jump very far, should you slip with the tweezers.
Soldering these requires steady hands and a bit of technique, but this guide aims to help you with that.

== The Kit ==
The Kit contains all the parts you need to set up your very own particle detector using your Raspberry Pi.

Contents of the Kit are:
* The plastic scintillator (generously provided by [https://eljentechnology.com/ Eljen Technology])
* The bare printed circuit board ([[Muonpi board]])
* [https://en.wikipedia.org/wiki/Satellite_navigation GNSS] antenna
* Components to mount on the PCB (Resistors, Capacitors, Inductors, ICs, etc.)
* Bill of materials (BOM)

The individual components of the kit are glued to a nametag using tape, as can be seen in the picture.
[[File:Parts-packaging.jpg|thumb|Example of how parts in the detector PCB kit are packaged]]
Because of the size and difficulty labeling the parts, they are packaged using paper labels and clear tape.
Getting the parts out of their packaging has to be done quite carefully, as they are easy to lose.

== Tools ==
The bare essential tools are:
* soldering iron
* solder
* (metal) tweezers
* solder fume extractor
additional:
* flux
* solder wick
* vise or helping hands
* scalpel/scissors
* magnifying glass

Additionally, we recommend to choose a brightl workplace, as dim lights and small components can lead to eye strain and head aches.

Generally,the smaller the tip of your soldering iron is, the better, for small component soldering at least.
Of course if you have other solder tips, like ones with a solder depot, you can use those too.<br>
In any case whatever tools you need to get the job done, are the correct tools to use.

== Documentation ==
The schematic, layout and BOM of the current hardware version can be found on the [https://easyeda.com/MuonPi/cosmic_shower_detector_v1-52b8a2536bb6468e9f48412a774951d0_copy_copy easyEDA project page].
While soldering, finding the right pad, where a specific components has to go, can be quite difficult.
The labels on the PCB are small and space for them is very limited which makes some of them hard to read and find.
To help you find the correct solder pads, an interactive BOM with the board layout, highlighting and clickable pads can be found [https://www.muonpi.org/bom/ibom.html on our website].
Alternatively you can print out the layout that is attached on the easyEDA project page.

=== Mounting Options ===
The BOM specifies multiple mounting options, such as: "Full", "Single Channel", "External Bias Supply", "Fixed Input Polarity".
"External Bias Supply" and "Fixed Input Polarity" were used by us in the development and will not be discussed here further.
The default configuration of the kit contains only one scintillator, therefore only one channel of the detector electronics will be used at a time.
In that case, the "Single Channel" mounting option would be sufficient.
However the number of components in the kit follows the "Full" configuration, and mounting all components is still recommended.
Just mounting all the parts that are included in the kit will lead to a working PCB with both channels working.
Please [https://muonpi.org/contact.html contact us], if you are interested in a two scintillator setup.

== Assembly ==
First things first, you should setup your workspace with all parts layed out, along with the BOM and all the tools you might need.
Personally, I like to sort the parts into categories: Resistors, Capacitors, Inductors, ICs and others.
This helps to save time and gives a quick overview of your soldering progress.
In principle the choice which components to mount first comes down to personal preference.
A helpful guideline is to mount parts depending on their height.
Lower, smaller parts should be mounted first, as to not interfere too much in the later stages of assembly.
This is why the GPIO headers should be among the last components to be mounted.

Once you are set up, you can turn on your soldering iron and fume extractor and start soldering.

=== Tips on SMD soldering ===
SMD components are small and difficult to solder.
The easiest components to solder are the resistors and capacitors.
Start with these to get comfortable with SMD soldering first, then proceed to the more difficult ICs.<br>
A quick guide to SMD soldering can be found at [https://www.sparkfun.com/marcomm/SFE03-0010-KitCard-SolderingSMD-ReaderSpreads.pdf sparkfun.com].

Be careful with the tip of the iron and the PCB. Too much heat and scraping of the pads can remove the top layer from the PCB or even rip the pad off the PCB.
The later, depending on the pad this happens to, is very likely to completely brick the board and rendering it unusable.

=== Soldering Workflow ===
[[File:Closeup of one soldered pad and a resistor.jpg|thumb|left|Closeup of a pad with solder and a resistor]]
Take your BOM and choose one of the resistor/capacitor values to begin with and identify the pad label, where the part is supposed to be placed.
Now take your soldering iron and heat one side of the pad. After a couple of seconds of heating, add some solder to the pad.
Take out one of the components out of it's packaging and grab onto it with the tweezers as indicated in the picture on the right.
Heat the solder blob and slide the component into the molten solder from the side.
This ensures covering of the components contacts.
Placing the component into the blob from above can lead to solder bridges underneath the component, which will render the component useless.

Once one side of the component is fixed, it's good practice to lightly press down on the component and remelt the solder.
Doing this will help to mount the component flush to the board.
Although not always necessary, doing this will help to avoid solder bridges, especially between the legs of ICs.
[[File:Flush component.jpg|x300px|thumb|right|Component lifted on one side (top); pressed down and after remelting the solder (bottom)]]

It is a good idea to cross out the components on the BOM once they are soldered.
Should in the end a label on the BOM be left unmarked you can check to not miss any components.

When you are finished soldering all parts of one kind, pause and check you haven't missed any.
Only then move on to the next group of parts.

=== Integrated Circuits (ICs) ===
Once all passive Components are placed and double checked, we can move on to the integrated circuits.
Soldering these is considerably more difficult, especially the ADC and DAC (U401 & U402 in v3.x) have a very small pad pitch.
Solder bridges are almost unavoidable and need to be dealt with.

First, solder is added to one pad on a corner of the IC footprint.
Then, just like the passive components, the IC is moved into the molten solder.
It is very important to align all the legs of the IC on their respective pads.
Proceed to fix one of the other legs, preferably a leg on the diagonally opposite side.
The remaining unsoldered legs can now be soldered to the board.

If solder bridges are created, they need to be removed.
One possible method to remove solder bridges is the usage of flux.
Flux is a mixture of multiple compounds that remove and prevent build up of oxides on the solder blob.
Additionally it increases the surface tension of the molten solder and therefor promotes splitting of solder blobs.
So just using a good amount of flux can fix solder bridges.

However if there is too much solder on the pads, bridges cannot be fixed just using flux. In that case we need to remove some solder.
Solder wicks are very useful for this task as its tight copper webbing wicks up any excess solder.
Place the wick on the solder blob and using the hot soldering iron, press the wick on the solder from above.
After a while, once the wick is hot enough, the solder will melt and be picked up by the wick.
Remove the wick and soldering iron simultaneously, otherwise the wick will be soldered to the pad instead, and pulling on the wick in that case can rip the pad off of the PCB.

In the timelapse you might be able to catch, how I soldered the ADC and DAC (U401 & U402 in v3.x).
Since the pitch is very small and solder bridges are very likely, I didn't even bother trying to avoid them.
After fixing the IC in place on one leg, I added a lot of solder to all pins and pads in one big blob.
With the addition of flux, most of the solder was removed using the solder wick, in the hopes that some solder would remain under the legs.
On first sight it seemed to work, but testing of the board revealed that something did not work.
Knowing that this technique is not 100% reliable, a quick reheat with careful addition of small amounts of solder fixed the issue and the board was fully operational.

{{#evt:service=youtube|id=E3kZMtjD76c|alignment=right|container=frame|description=Timelapse of IC soldering ([https://www.youtube.com/watch?v=E3kZMtjD76c link to youtube])|dimensions=480}}

=== UFL connectors ===

== Testing the board ==
To test your fully assembled board, get your Raspberry Pi and power it off. Now that the Pi is unpowered align the GPIO headers with the pins of the Pi. When aligned correctly, there should not be any pins unconnected and any headers left without a connection.
Next step is connecting the signal cables to the preamplifier of the SiPM

Hardware Setup

2020-12-10T15:08:55Z

Simonglm: syntax error

The MuonPi HAT board is a plug-on board for Raspberry-Pi minicomputers exhibiting a 40-pin GPIO-connector. Only place the board on the RPi with power disconnected. Use 13 mm long plastic spacers and 2.5mm metric screws to fix the board.
= Cable Connections =
The [[preamplifier]] attached to the [[Silicon_photomultiplier|SiPM]]-PCB and the [[Scintillator]] has two connections: One for the provision of the SiPM bias voltage (27...32V for KETEK-type SiPMs) and one for the combined output signal and preamp supply voltage. Both connectors are u.Fl-type coaxial receptacles with the same counterparts on the MuonPi board. They should be connected with standard u.Fl coaxial cables which are widely available (eg. at [https://www.amazon.de/-/en/U-FL-Hirose-Cable-1-13-20/dp/B01MTQGHPM/ref=sr_1_23?dchild=1&keywords=u.fl+kabel+ipx+ipex&qid=1607074316&sr=8-23 Amazon], [https://www.ebay.de/itm/10PCS-IPX-IPEX-u-fl-Female-1-13mm-Connector-Cable-Single-head-Adapter-Connect-QE/303795341801?hash=item46bb9d09e9:g:CpgAAOSw3jxe1erV Ebay] or AliExpress). The connection details are shown in the photograph below. The GNSS antenna is mounted to the SMA jack X7 at the lower edge of the board. Note, that antennas with integrated preamplifier ("active" antennas) are recommended to use in conjunction with the MuonPi board.

[[File:MuonPi-Connections.png|640px|thumb|Hardware connections between MuonPi HAT board and detector]]

Hardware Setup

2020-12-10T15:06:59Z

Simonglm: Phrasing of internal wiki links

The MuonPi HAT board is a plug-on board for Raspberry-Pi minicomputers exhibiting a 40-pin GPIO-connector. Only place the board on the RPi with power disconnected. Use 13 mm long plastic spacers and 2.5mm metric screws to fix the board.
= Cable Connections =
The [[preamplifier]] attached to the [[Silicon_photomultiplier|SiPM]-PCB and the [[Scintillator]] has two connections: One for the provision of the SiPM bias voltage (27...32V for KETEK-type SiPMs) and one for the combined output signal and preamp supply voltage. Both connectors are u.Fl-type coaxial receptacles with the same counterparts on the MuonPi board. They should be connected with standard u.Fl coaxial cables which are widely available (eg. at [https://www.amazon.de/-/en/U-FL-Hirose-Cable-1-13-20/dp/B01MTQGHPM/ref=sr_1_23?dchild=1&keywords=u.fl+kabel+ipx+ipex&qid=1607074316&sr=8-23 Amazon], [https://www.ebay.de/itm/10PCS-IPX-IPEX-u-fl-Female-1-13mm-Connector-Cable-Single-head-Adapter-Connect-QE/303795341801?hash=item46bb9d09e9:g:CpgAAOSw3jxe1erV Ebay] or AliExpress). The connection details are shown in the photograph below. The GNSS antenna is mounted to the SMA jack X7 at the lower edge of the board. Note, that antennas with integrated preamplifier ("active" antennas) are recommended to use in conjunction with the MuonPi board.

[[File:MuonPi-Connections.png|640px|thumb|Hardware connections between MuonPi HAT board and detector]]

Muonpi board

2020-12-10T14:03:02Z

Simonglm: Fixed broken preamp link

The MuonPi board is designed as plug-on board for the Raspberry Pi B+ in a form factor conforming with the [https://github.com/raspberrypi/hats RPi HAT specifications].

== Functional Description ==
The MuonPi board implements following functionalities:
* Two input channels
* Supply voltage for remote powering the [[preamplifier]] through the signal line: The voltage can be switched on/off through a GPIO signal (individually for the two channels). It includes overcurrent and overtemperature shutdown and a fault feedback signal.
* Bias voltage supply for the SiPM sensor and bias voltage/current supervision. A DC/DC converter generates the required reverse biasing voltage from the RPi's 5V rail. The voltage can be switched on/off through a GPIO signal. Actual bias voltage and current are measured through the on-board ADC. The voltage can be controlled through the on-board DAC (not in HW version 2).

[[File:MuonPi-blockscheme.png|640px|thumb|right|MuonPi functional block schematic]]

* Signal inverters for the two signal inputs in case negative signals are presented to the board
* Threshold discriminators with adjustable thresholds (DAC channels 1 and 2) in the range from 0.5 mV to 3V. The discriminator outputs are LVCMOS signals with a length of ~100 ns.
* Both channels are logically connected by one AND gate and one XOR gate. In this way, a coincidence ("both at the same time") as well as an anti-coincidence ("only exactly one") within a 100 ns time window can be asserted.
* The two gate signals (AND/XOR) are time-shaped to 1 us length and provided to the GPIO interface of the RPi
* The two discriminator signals and the two logic gate signals are fed to a multiplexer. Its output is fed to the time stamping input of the u-blox GNSS receiver.
* The u-blox GNSS receiver NEO-M8N is utilized to get the precise time and frequency reference in order to provide a sufficient precision of the time stamping on the nanosecond level. The time stamp of an event (leading and trailing edges of the signal present at the multiplexer output) is transmitted to the RPi via UART interface through the UBX-TIM-TM2 message.

== Detailed Description ==

The MuonPi board design is open hardware. It is entirely defined in the free EDA cloud tool [https://easyeda.com EasyEDA]. The [https://easyeda.com/MuonPi/cosmic_shower_detector_v1-52b8a2536bb6468e9f48412a774951d0_copy_copy current working version of the design is HW Ver 3] which is explained in detail below.

The predecessor versions are available for reference: [https://easyeda.com/hgzaunick/cosmic_shower_detector_v1-52b8a2536bb6468e9f48412a774951d0_copy HW Ver 2] and [https://easyeda.com/hgzaunick/cosmic_shower_detector_v1-52b8a2536bb6468e9f48412a774951d0 HW Ver 1].

=== Input Stage ===
[[File:Input stage v3.1.png|thumb|640px|Analog input stage (V3.1)]]
The signal input comprises a 50 Ohms-terminated signal path with simultaneous provision of the bias voltage (VPRE1) for remote powering of the preamplifier. The AC component is decoupled and provided to the differential wide-band amplifier U100/U200 (LMH6550) with a voltage gain of ~3. In this way, the output is symmetrical around a mid-scale common mode voltage with a non-inverted and an inverted signal superimposed. The analog switch U102/U202 (SN74LVC1G3157) selects either one depending on the switch control input (POL1) and presents the capacitively coupled signal to a fast comparator U2 (TLV3502). The threshold THR1 is provided from the DAC U402 (see "RPi Interface").

=== Digital Pulse Processor ===
The outputs of comparator U2 are time-shaped with monostable gate U300 to 100 ns wide pulses. These are indicated as discriminator outputs for both channels. They are logically connected with both, AND gate U304 (which is actually a NOR gate but with the inverted inputs acting as an AND) as well as XOR gate U303. These signals are shaped to 1 us pulse length and supplied to GPIO pins (EVT_XOR and EVT_AND). The discriminator signals are also time-shaped to ca. 100 ms length by U306 to drive the indicator LEDs for a discernible visual signal. With the multiplexer U305 (74AC151), one of the signals (EVT_AND, EVT_XOR, DISCR1, DISCR2, TIMEPULSE) connected to its inputs can be selected and fed to the output TIME_MEAS. The selection word is supplied by the I2C-expander U404 (PCF9536). The selected output is routed to the interrupt pin of the u-Blox NEO GNSS chip where the rising edge is timestamped with nanosecond resolution and sent as UBX message TIM-TM2 over the UART interface to the host. The discriminator signals, time-shaped logic gates and the inverted multiplexer output are all series terminated in order to avoid false triggering or wrong timing due to reflections whereas the non-inverted multiplexer output driving only the u-Blox interrupt pin is terminated with a Thevenin matching network at the end (see GNSS receiver).
[[File:Digital-pulse processor v3.1.png|thumb|640px|Digital pulse processor (V3.1)]]

=== GNSS Receiver ===
The u-Blox NEO M7/M8N receiver chip U700 processes the timing information from the GNSS satellites (GPS, Galileo, Glonass, BeiDou, QZSS, SBAS) and synchronizes its local TCXO to this time grid. The GNSS antenna is connected to SMA jack X7. The u-Blox chip provides a supply voltage for the antenna's preamplifier through R700/L700. The digital pulses are fed into the interrupt pin EXTINT0 for timestamping of both, rising and falling edges. The line is terminated by the Thevenin matching network R702/R703 which is driven by the output of multiplexer U305 with sufficient current. Note, that only the AC-family type has sufficient drive strength. Don't replace with other logic families.
Communication with the chip is done via UART interface connecting directly to the RPi's TxD/RxD serial lines. Additionaly, the I2C interface is connected to the board's I2C bus. As it turned out, the communication via I2C requires a master capable of clock stretching. This feature is currently not available on the RPi hardware I2C interface, so the u-Blox I2C interface is currently not used.
The 1pps time pulse is, additional to its distribution to a GPIO pin and the indicator LED409, routed to a the 2-pin pinheader connector J700 (TP_OUT) where it is available for other purposes. The u-Blox pps output can be programmed to other frequencies which may be utilized e.g. for PLL synchronization or disciplining a local oscillator (GPSDO).
[[File:Gnss receiver v3.1.png|thumb|640px|GNSS receiver section (V3.1)]]

=== RPi Interface ===
The interface of the MuonPi HAT connects to the 40-pin GPIO header of the Raspberry-Pi with several digital I/Os, the UART interface from the u-Blox chip and the interface to the on-board I2C bus. The four-channel ADC U401 (ADS1015/1115) acquires the voltages of the (optional) peak detector for the pulse amplitude measurement (ch1), the on-board supply voltage (nominal 3.3V, shifted into the ADC's input range by voltage divider R418/R419) on ch2 and the sense voltages (after the voltage dividers R505/506 and R507/508) at both ends of the sense resistor R504 (see "Power section") connected to channels 3 and 4, respectively. The 12-bit DAC U402 (MCP4728) provides a fine-grained adjustment of the two threshold voltages (THR1, THR2 on channels 1 and 2) and the control voltage on channel 3 for the DC/DC converter around U502. Channel 4 is not used, but routed to a through-hole pad "DAC4" where it may be used for any purpose. There are two I2C EEPROM chips on the board. U400 (24AA02UID) is for the MuonPi's specific storage of calibration parameters and the factory-programmed unique ID, while U405 (CAT24C32WI) which is actually connected to the RPi ID-I2C interface foreseen for exacly this purpose, provides the configuration parameters for HAT identification and automatic GPIO and boot overlay selection during the boot phase.
Furthermore, the temperature sensor U403 (LM75A/B) and the 4-bit I/O expander U404 (U404) are also controlled via the on-board I2C bus. The I/O expander chip U404 provides the selection bit pattern for the multiplexer U305.
[[File:Rpi interface v3.1.png|thumb|640px|RPi interface section with ADC, DAC, EEPROM, temp sensor, OLED interface and LEDs. (V3.1)]]

=== Power/Bias Supply ===
The bias voltage generation for the SiPM photo detector is foreseen in two ways, each one selected depending on the mounting. By default, the bias voltage of <33V is generated by the DC/DC converter around U502 (LM2733Y). It's output voltage is controlled by the voltage provided by channel 3 of the DAC (U402) with an intercept point set by the resistive divider network R500 to R502. The filtered output is shunted to ground by R503 to avoid a varying load of the converter circuit. After RF-filtering by L501, the voltage is passed through the current limiting series resistor R516 and shunted by n-mosfet Q501 which short-cuts the voltage to ground, when the BIAS_EN_N control signal is low. Otherwise, the non-zero output voltage is passed through the current measurement shunt R504. The symmetrical resistive dividers R505/R506 and R507/R508 tap the voltages at either side of R504 which are low-pass filtered through C503/C504 and buffered by U501 before routed to ADC channels 3 and 4. This circuit realizes both, measurement of the actual bias voltage present at the outputs X5,X6 as well as the measurement of the bias current.

Alternativeley, the bias supply may be provided by an external, plug-on module U505. This could be useful when employing photodetectors with different bias voltage specification, e.g. Hamamatsu-type SiPMs with larger operating voltages of ~50..90V. When suplying the bias voltage from such an external DC/DC converter, make sure to not mount the on-board converter U502 and associated components.

The supply voltage of +5V for the preamplifiers is controlled by the current-limited load switches U503/U504 (TPS22944). The switches are enabled independently with a high level on PREAMP1/2_EN signals from the GPIO. The fault outputs from the switches are diode-OR-ed with D501/D502 and provide an error input to the MuonPi in any of these cases: overcurrent (>100mA) and over-temperature. In all cases, the switch disconnects the output until the fault condition is removed.
[[File:Power section v3.1.png|thumb|640px|Power management and bias voltage generation (V3.1)]]

Main Page

2020-12-10T14:02:24Z

Simonglm: Fixed broken preamp link

= The MuonPi Cosmic Detector Project =
The MuonPi Project is a [https://www.raspberrypi.org/ RaspberryPi]-based system using an inexpensive plastic [[Scintillator|scintillator]] + [[Silicon photomultiplier|SiPM]] photo sensor to detect muons from cosmic air showers with a time-stamping accuracy of several tens of nanoseconds utilizing the [https://www.u-blox.com/en/product/neo-m8-series u-blox NEO-M8N GNSS] module's "timemark" feature.

==== Learn about cosmic radiation ====
* Get started with [[Cosmic Rays]], especially [[Muon]]s

*[https://www.vox.com/the-highlight/2019/7/16/17690740/cosmic-rays-universe-theory-science Extremely powerful cosmic rays are raining down on us. No one knows where they come from.] But with large-scale experiments, scientists around the world are determined to find out. ''Vox'' Jul 25, 2019

*[https://home.cern/science/physics/cosmic-rays-particles-outer-space Cosmic rays: particles from outer space] Earth is subject to a constant bombardment of subatomic particles that can reach energies far higher than the largest machines. ''CERN''

* [https://www.weltderphysik.de/mediathek/podcast/kosmische-strahlung/ "Kosmische Strahlung"] Podcast (in German) on [https://www.weltderphysik.de weltderphysik.de]
* [https://www.weltderphysik.de/thema/bmbf/astro-undastroteilchenphysik/der-kosmischen-strahlung-auf-der-spur/ "Der kosmischen Strahlung auf der Spur"] article (in German) on [https://www.weltderphysik.de weltderphysik.de]
* [https://www.weltderphysik.de/gebiet/universum/news/2017/kosmische-teilchen-mit-extragalaktischem-ursprung/ "Kosmische Teilchen mit extragalaktischem Ursprung"] article (in German) on [https://www.weltderphysik.de weltderphysik.de]

==== Learn about the detectors ====
* Basics of [[Scintillator]]s
* Find out about [[Silicon photomultiplier|Silicon Photomultipliers]]
* How our [[The Detector|Detectors]] are assembled

= The Hardware =

=== SiPM PCB ===
The SiPM photo sensor which detects the dim light generated inside the scintillation detector is mounted on a small [[Sipm_board|SiPM board]]. Different numbers of SiPMs and read-out configurations can be realized through it's flexible design.

=== Preamplifier ===
The [[preamplifier]] is located in close vicinity to the [[sipm_board|SiPM photodetector board]] and amplifies the weak signals for transmission to the [[muonpi_board|MuonPi]] board, where they are further processed and evaluated.

=== The MuonPi-Board ===
The main signal processing, voltage generation and parameter monitoring and adjustment is done on the Raspberry Pi plug-on [[muonpi_board|MuonPi Board]]. The board's design is open source hardware and exhibits only commercially available off-the-shelf components which can be obtained from several distributors. With some soldering experience, the MuonPi HAT can be assembled utilizing a standard soldering equipment. A how-to guide and useful hints are available in the [[Assembly Guide|Assembly Guide]].

= The Software =
The MuonPi software collection is entirely open source and [https://github.com/MuonPi available on github]
It consists of several components:
* '''muondetector-daemon''' The main control program running as a background system service on the RPi. The daemon configures, controls and supervises the components on the MuonPi HAT board, handles the comunication to the u-Blox chip and to the outside world via MQTT link and direct access socket, monitors system parameters, such as temperature, voltages, curent, rates etc., performs statistics collections, calculations and logging and much more. The daemon can be installed through the standard system software management tools (such as apt) from our [https://archive.muonpi.org package repository] or compiled from the [https://github.com/MuonPi/muondetector github source] and is everything which is needed to operate a MuonPi detector.
* '''muondetector-gui''' A graphical user interface (GUI) program which can be launched on any computer in the same network as the MuonPi detector in order to monitor and adjust all operation parameters of the detector, if required. The GUI is available for [https://archive.muonpi.org download] as binary package for several platforms (Raspbian, Ubuntu, Windows) or can be compiled from the current [https://github.com/MuonPi/muondetector github master branch].
* '''muondetector-login''' A small command line helper tool to initially set up the MQTT telemetry link. The program will ask for the supplied MQTT credentials and stores them locally in encrypted form for continuous use.
* '''muondetector-cluster''' Allows the operation of a multi-detector cluster as an entity. The program is the cluster head or interface towards the server, searches for coincidences within the cluster and sends the combined coincidence events instead of the single event telegrams to the server. This tool is in development phase with more information about it's utilization to come in near future.

= Setup and Operation of the Detector =
Here you find a collection of HOW-TOs useful to set-up and oparate a detector:

*[[The Detector|How to assemble the detector plates]]

*[[Assembly Guide|MuonPi HAT Assembly Guide]]

*[[Hardware Setup|How to set up the Detector Hardware]]

*[[Raspberry Pi Setup|How to install and set up the MuonPi Software]]

= Related Articles =

[[News and articles]] about cosmic rays and similar projects.

= Other languages =

* [[Main Page/de]]

= Admin Area =

Useful [[resources]] for admins.

= About this Wiki =
* How to edit? [[help for creators]]
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings List of config variables]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailing list of new MediaWiki version announcements]

----
Sandbox page for testing/playing:
* [[Sandbox]]

Preamp

2020-12-10T14:01:03Z

Simonglm: Simonglm moved page Preamp to Preamplifier: slang

#REDIRECT [[Preamplifier]]

Preamplifier

2020-12-10T14:01:02Z

Simonglm: Simonglm moved page Preamp to Preamplifier: slang

The preamplifier boosts the SiPM's very small signal amplitude by ~20dB and should be located as close as possible to the SiPM itself in order to maintain an acceptable signal-to-noise ratio (SNR). Therefore, a plug-on PCB for the [[sipm_board|SiPM board]] in the same form factor was designed, which shall be as versatile as possible in order to adapt for different read-out concepts with the following properties:
* supply of the SiPM bias voltage through the preamp including bias filter
* AC-coupling of the preamp input
* based on low-noise Infineon MMIC [https://www.infineon.com/cms/en/product/rf-wireless-control/low-noise-amplifier-lna-ics/general-purpose-lnas/bga614/ BGA614]
* mounting option for one (default, positive output) or two MMIC stages (negative output)
* options for preamp voltage supply (+5V): either via separate connector (J2) or remote powering via output signal (default)

[[File:Preamp V3-1.jpg|thumb|640px|right|Preamplifier schematic]]

For the different operation modes, the following '''mounting options''' are offered (unmentioned components are identical as indicated in the schematic or as in the default option):

'''Default (single-stage, remote powering)'''
* do not mount: IC2, C5, C6, L4, R5, C7, J2, J5
* mount: R7 (0R), R6 (0R), C2 (0R), connect IC2 pins 1 to 3 (e.g. with edge mounted 0R resistor)

'''Dual-stage'''
* mount: IC2, R6/C7 = pole-zero-cancellation network (e.g. 47R/22p)

'''Separate power supply connection'''
* do not mount: L3
* mount: J2

'''Floating bias voltage supply''' (galvanically isolated from signal GND)
* dnm: R7
* mount C5, C6

'''General purpose 50Ω RF amplifier''' (no SiPM, signal input via u.Fl socket J5)
* dnm: J1, J3, R1, R2, L2
* mount: J5

[[File:Preamp sipm pcbs mounted.JPG|thumb|left|mounted preamp (top) and photosensor PCBs (bottom) with one instrumented SiPM]]
[[File:Preamp_detail1.png|thumb|left|Mounted preamp plugged on the pin headers of the SiPM board of an assembled detector plate]]

Assembly Guide

2020-12-10T13:57:02Z

Simonglm: Finished IC section. Still [WIP]

This is a guide on how to populate our MuonPi-PCB, using the construction kit. You can get a kit or a fully assembled PCB by contacting us [http://www.muonpi.org/contact.html here].

All components in this kit (except for the pin headers) are surface-mount devices (SMD).
Most of these parts are only a few millimeters in size and are prone jump very far, should you slip with the tweezers.
Soldering these requires steady hands and a bit of technique, but this guide aims to help you with that.

== The Kit ==
The Kit contains all the parts you need to set up your very own particle detector using your Raspberry Pi.

Contents of the Kit are:
* The plastic scintillator (generously provided by [https://eljentechnology.com/ Eljen Technology])
* The bare printed circuit board ([[Muonpi board]])
* [https://en.wikipedia.org/wiki/Satellite_navigation GNSS] antenna
* Components to mount on the PCB (Resistors, Capacitors, Inductors, ICs, etc.)
* Bill of materials (BOM)

The individual components of the kit are glued to a nametag using tape, as can be seen in the picture.
[[File:Parts-packaging.jpg|thumb|Example of how parts in the detector PCB kit are packaged]]
Because of the size and difficulty labeling the parts, they are packaged using paper labels and clear tape.
Getting the parts out of their packaging has to be done quite carefully, as they are easy to lose.

== Tools ==
The bare essential tools are:
* soldering iron
* solder
* (metal) tweezers
* solder fume extractor
additional:
* flux
* solder wick
* vise or helping hands
* scalpel/scissors
* magnifying glass

Additionally, we recommend to choose a brightl workplace, as dim lights and small components can lead to eye strain and head aches.

Generally,the smaller the tip of your soldering iron is, the better, for small component soldering at least.
Of course if you have other solder tips, like ones with a solder depot, you can use those too.<br>
In any case whatever tools you need to get the job done, are the correct tools to use.

== Documentation ==
The schematic, layout and BOM of the current hardware version can be found on the [https://easyeda.com/MuonPi/cosmic_shower_detector_v1-52b8a2536bb6468e9f48412a774951d0_copy_copy easyEDA project page].
While soldering, finding the right pad, where a specific components has to go, can be quite difficult.
The labels on the PCB are small and space for them is very limited which makes some of them hard to read and find.
To help you find the correct solder pads, we recommend to have a computer nearby where you can open the [https://easyeda.com/editor#id=ad78628187d94b9cb54d8735233128d7 schematics] and use the search function.
Alternatively you can print out the layout that is attached on the easyEDA project page.

=== Mounting Options ===
The BOM specifies multiple mounting options, such as: "Full", "Single Channel", "External Bias Supply", "Fixed Input Polarity".
"External Bias Supply" and "Fixed Input Polarity" were used by us in the development and will not be discussed here further.
The default configuration of the kit contains only one scintillator, therefore only one channel of the detector electronics will be used at a time.
In that case, the "Single Channel" mounting option would be sufficient.
However the number of components in the kit follows the "Full" configuration, and mounting all components is still recommended.
Just mounting all the parts that are included in the kit will lead to a working PCB with both channels working.
Please [https://muonpi.org/contact.html contact us], if you are interested in a two scintillator setup.

== Assembly ==
First things first, you should setup your workspace with all parts layed out, along with the BOM and all the tools you might need.
Personally, I like to sort the parts into categories: Resistors, Capacitors, Inductors, ICs and others.
This helps to save time and gives a quick overview of your soldering progress.
In principle the choice which components to mount first comes down to personal preference.
A helpful guideline is to mount parts depending on their height.
Lower, smaller parts should be mounted first, as to not interfere too much in the later stages of assembly.
This is why the GPIO headers should be among the last components to be mounted.

Once you are set up, you can turn on your soldering iron and fume extractor and start soldering.

=== Tips on SMD soldering ===
SMD components are small and difficult to solder.
The easiest components to solder are the resistors and capacitors.
Start with these to get comfortable with SMD soldering first, then proceed to the more difficult ICs.<br>
A quick guide to SMD soldering can be found at [https://www.sparkfun.com/marcomm/SFE03-0010-KitCard-SolderingSMD-ReaderSpreads.pdf sparkfun.com].

Be careful with the tip of the iron and the PCB. Too much heat and scraping of the pads can remove the top layer from the PCB or even rip the pad off the PCB.
The later, depending on the pad this happens to, is very likely to completely brick the board and rendering it unusable.

=== Soldering Workflow ===
[[File:Closeup of one soldered pad and a resistor.jpg|thumb|left|Closeup of a pad with solder and a resistor]]
Take your BOM and choose one of the resistor/capacitor values to begin with and identify the pad label, where the part is supposed to be placed.
Now take your soldering iron and heat one side of the pad. After a couple of seconds of heating, add some solder to the pad.
Take out one of the components out of it's packaging and grab onto it with the tweezers as indicated in the picture on the right.
Heat the solder blob and slide the component into the molten solder from the side.
This ensures covering of the components contacts.
Placing the component into the blob from above can lead to solder bridges underneath the component, which will render the component useless.

Once one side of the component is fixed, it's good practice to lightly press down on the component and remelt the solder.
Doing this will help to mount the component flush to the board.
Although not always necessary, doing this will help to avoid solder bridges, especially between the legs of ICs.
[[File:Flush component.jpg|x300px|thumb|right|Component lifted on one side (top); pressed down and after remelting the solder (bottom)]]

It is a good idea to cross out the components on the BOM once they are soldered.
Should in the end a label on the BOM be left unmarked you can check to not miss any components.

When you are finished soldering all parts of one kind, pause and check you haven't missed any.
Only then move on to the next group of parts.

=== Integrated Circuits (ICs) ===
Once all passive Components are placed and double checked, we can move on to the integrated circuits.
Soldering these is considerably more difficult, especially the ADC and DAC (U401 & U402 in v3.x) have a very small pad pitch.
Solder bridges are almost unavoidable and need to be dealt with.

First, solder is added to one pad on a corner of the IC footprint.
Then, just like the passive components, the IC is moved into the molten solder.
It is very important to align all the legs of the IC on their respective pads.
Proceed to fix one of the other legs, preferably a leg on the diagonally opposite side.
The remaining unsoldered legs can now be soldered to the board.

If solder bridges are created, they need to be removed.
One possible method to remove solder bridges is the usage of flux.
Flux is a mixture of multiple compounds that remove and prevent build up of oxides on the solder blob.
Additionally it increases the surface tension of the molten solder and therefor promotes splitting of solder blobs.
So just using a good amount of flux can fix solder bridges.

However if there is too much solder on the pads, bridges cannot be fixed just using flux. In that case we need to remove some solder.
Solder wicks are very useful for this task as its tight copper webbing wicks up any excess solder.
Place the wick on the solder blob and using the hot soldering iron, press the wick on the solder from above.
After a while, once the wick is hot enough, the solder will melt and be picked up by the wick.
Remove the wick and soldering iron simultaneously, otherwise the wick will be soldered to the pad instead, and pulling on the wick in that case can rip the pad off of the PCB.

In the timelapse you might be able to catch, how I soldered the ADC and DAC (U401 & U402 in v3.x).
Since the pitch is very small and solder bridges are very likely, I didn't even bother trying to avoid them.
After fixing the IC in place on one leg, I added a lot of solder to all pins and pads in one big blob.
With the addition of flux, most of the solder was removed using the solder wick, in the hopes that some solder would remain under the legs.
On first sight it seemed to work, but testing of the board revealed that something did not work.
Knowing that this technique is not 100% reliable, a quick reheat with careful addition of small amounts of solder fixed the issue and the board was fully operational.

{{#evt:service=youtube|id=E3kZMtjD76c|alignment=right|container=frame|description=Timelapse of IC soldering ([https://www.youtube.com/watch?v=E3kZMtjD76c link to youtube])|dimensions=480}}

=== UFL connectors ===

== Testing the board ==
To test your fully assembled board, get your Raspberry Pi and power it off. Now that the Pi is unpowered align the GPIO headers with the pins of the Pi. When aligned correctly, there should not be any pins unconnected and any headers left without a connection.
Next step is connecting the signal cables to the preamplifier of the SiPM

Assembly Guide

2020-12-07T16:10:45Z

Simonglm:

[WORK IN PROGRESS] This is a guide on how to populate our MuonPi-PCB, using the construction kit. You can get a kit or a fully assembled PCB by contacting us [http://www.muonpi.org/contact.html here].

All components in this kit (except for the pin headers) are surface-mount devices (SMD).
Most of these parts are only a few millimeters in size and are prone jump very far, should you slip with the tweezers.
Soldering these requires steady hands and a bit of technique, but this guide aims to help you with that.

== The Kit ==
The Kit contains all the parts you need to set up your very own particle detector using your RaspberryPi.

Contents of the Kit are:
* The plastic scintillator (generously provided by [https://eljentechnology.com/ Eljen Technology])
* The bare printed circuit board ([[Muonpi board]])
* [https://en.wikipedia.org/wiki/Satellite_navigation GNSS] antenna
* Components to mount on the PCB (Resistors, Capacitors, Inductors, ICs, etc.)
* Bill of materials (BOM)

The individual components of the kit are glued to a nametag using tape, as can be seen in the picture.
[[File:Parts-packaging.jpg|thumb|Example of how parts in the detector PCB kit are packaged]]
Unfortunately getting the parts out of their packaging will take half of the time spent on assembly.
Be careful when you unpack these parts, they can get lost very easily

== Tools ==
The bare essential tools are:
* soldering iron
* solder
* (metal) tweezers
* solder fume extractor
additional:
* flux
* solder wick
* vise or helping hands
* scalpel/scissors
* magnifying glass

Additionally, we recommend to choose a brightl workplace, as dim lights and small components can lead to eye strain and head aches.

Generally,the smaller the tip of your soldering iron is, the better, for small component soldering at least.
Of course if you have other solder tips, like ones with a solder depot, you can use those too.<br>
In any case whatever tools you need to get the job done, are the correct tools to use.

== Documentation ==
The schematic, layout and BOM of the current hardware version can be found on the [https://easyeda.com/MuonPi/cosmic_shower_detector_v1-52b8a2536bb6468e9f48412a774951d0_copy_copy easyEDA project page].
While soldering, finding the right pad, where a specific components has to go, can be quite difficult.
The labels on the PCB are small and space for them is very limited which makes some of them hard to read and find.
To help you find the correct solder pads, we recommend to have a computer nearby where you can open the [https://easyeda.com/editor#id=ad78628187d94b9cb54d8735233128d7 schematics] and use the search function.
Alternatively you can print out the layout that is attached on the easyEDA project page.

=== Mounting Options ===
The BOM specifies multiple mounting options, such as: "Full", "Single Channel", "External Bias Supply", "Fixed Input Polarity".
"External Bias Supply" and "Fixed Input Polarity" were used by us in the development and will not be discussed here further.
The default configuration of the kit contains only one scintillator, therefore only one channel of the detector electronics will be used at a time.
In that case, the "Single Channel" mounting option would be sufficient.
However the number of components in the kit follows the "Full" configuration, and mounting all components is still recommended.
Just mounting all the parts that are included in the kit will lead to a working PCB with both channels working.
Please [https://muonpi.org/contact.html contact us], if you are interested in a two scintillator setup.

== Assembly ==
First things first, you should setup your workspace with all parts layed out, along with the BOM and all the tools you might need.
Personally, I like to sort the parts into categories: Resistors, Capacitors, Inductors, ICs and others.
This helps to save time and gives a quick overview of your soldering progress.
In principle the choice which components to mount first comes down to personal preference.
A helpful guideline is to mount parts depending on their height.
Lower, smaller parts should be mounted first, as to not interfere too much in the later stages of assembly.
This is why the GPIO headers should be among the last components to be mounted.

Once you are set up, you can turn on your soldering iron and fume extractor and start soldering.

=== Tips on SMD soldering ===
SMD components are small and difficult to solder.
The easiest components to solder are the resistors and capacitors.
Start with these to get comfortable with SMD soldering first, then proceed to the more difficult ICs.<br>
A quick guide to SMD soldering can be found at [https://www.sparkfun.com/marcomm/SFE03-0010-KitCard-SolderingSMD-ReaderSpreads.pdf sparkfun.com].

=== Soldering Workflow ===
[[File:Closeup of one soldered pad and a resistor.jpg|thumb|right|Closeup of a pad with solder and a resistor]]
Take your BOM and choose one of the resistor/capacitor values to begin with and identify the pad label, where the part is supposed to be placed.
Now take your soldering iron and heat one side of the pad. After a couple of seconds of heating, add some solder to the pad.
Take out one of the components out of it's packaging and grab onto it with the tweezers as indicated in the picture on the right.
Heat the solder blob and slide the component into the molten solder from the side.
This ensures covering of the components contacts.
Placing the component into the blob from above can lead to solder bridges underneath the component, which will render the component useless.

Once one side of the component is fixed, it's good practice to lightly press down on the component and remelt the solder.
Doing this will help to mount the component flush to the board.
Although not always necessary, doing this will help to avoid solder bridges, especially between the legs of ICs.
[[File:Flush component.jpg|x300px|thumb|right|Component lifted on one side (top); pressed down and after remelting the solder (bottom)]]

It is a good idea to cross out the components on the BOM once they are soldered.
Should in the end a label on the BOM be left unmarked you can check to not miss any components.

When you are finished soldering all parts of one kind, pause and check you haven't missed any.
Only then move on to the next group of parts.

=== Integrated Circuits (ICs) ===

{{#evt:service=youtube|id=E3kZMtjD76c|alignment=right|container=frame|description=Timelapse of IC soldering|dimensions=480}}

Assembly Guide

2020-12-07T15:54:20Z

Simonglm:

[WORK IN PROGRESS] This is a guide on how to populate our MuonPi-PCB, using the construction kit. You can get a kit or a fully assembled PCB by contacting us [http://www.muonpi.org/contact.html here].

All components in this kit (except for the pin headers) are surface-mount devices (SMD).
Most of these parts are only a few millimeters in size and are prone jump very far, should you slip with the tweezers.
Soldering these requires steady hands and a bit of technique, but this guide aims to help you with that.

== The Kit ==
The Kit contains all the parts you need to set up your very own particle detector using your RaspberryPi.

Contents of the Kit are:
* The plastic scintillator (generously provided by [https://eljentechnology.com/ Eljen Technology])
* The bare printed circuit board ([[Muonpi board]])
* [https://en.wikipedia.org/wiki/Satellite_navigation GNSS] antenna
* Components to mount on the PCB (Resistors, Capacitors, Inductors, ICs, etc.)
* Bill of materials (BOM)

The individual components of the kit are glued to a nametag using tape, as can be seen in the picture.
[[File:Parts-packaging.jpg|thumb|Example of how parts in the detector PCB kit are packaged]]
Unfortunately getting the parts out of their packaging will take half of the time spent on assembly.
Be careful when you unpack these parts, they can get lost very easily

== Tools ==
The bare essential tools are:
* soldering iron
* solder
* (metal) tweezers
* solder fume extractor
additional:
* flux
* solder wick
* vise or helping hands
* scalpel/scissors
* magnifying glass

Additionally, we recommend to choose a brightl workplace, as dim lights and small components can lead to eye strain and head aches.

Generally,the smaller the tip of your soldering iron is, the better, for small component soldering at least.
Of course if you have other solder tips, like ones with a solder depot, you can use those too.<br>
In any case whatever tools you need to get the job done, are the correct tools to use.

== Documentation ==
The schematic, layout and BOM of the current hardware version can be found on the [https://easyeda.com/MuonPi/cosmic_shower_detector_v1-52b8a2536bb6468e9f48412a774951d0_copy_copy easyEDA project page].
While soldering, finding the right pad, where a specific components has to go, can be quite difficult.
The labels on the PCB are small and space for them is very limited which makes some of them hard to read and find.
To help you find the correct solder pads, we recommend to have a computer nearby where you can open the [https://easyeda.com/editor#id=ad78628187d94b9cb54d8735233128d7 schematics] and use the search function.
Alternatively you can print out the layout that is attached on the easyEDA project page.

=== Mounting Options ===
The BOM specifies multiple mounting options, such as: "Full", "Single Channel", "External Bias Supply", "Fixed Input Polarity".
"External Bias Supply" and "Fixed Input Polarity" were used by us in the development and will not be discussed here further.
The default configuration of the kit contains only one scintillator, therefore only one channel of the detector electronics will be used at a time.
In that case, the "Single Channel" mounting option would be sufficient.
However the number of components in the kit follows the "Full" configuration, and mounting all components is still recommended.
Just mounting all the parts that are included in the kit will lead to a working PCB with both channels working.
Please [https://muonpi.org/contact.html contact us], if you are interested in a two scintillator setup.

== Assembly ==
First things first, you should setup your workspace with all parts layed out, along with the BOM and all the tools you might need.
Personally, I like to sort the parts into categories: Resistors, Capacitors, Inductors, ICs and others.
This helps to save time and gives a quick overview of your soldering progress.
In principle the choice which components to mount first comes down to personal preference.
A helpful guideline is to mount parts depending on their height.
Lower, smaller parts should be mounted first, as to not interfere too much in the later stages of assembly.
This is why the GPIO headers should be among the last components to be mounted.

Once you are set up, you can turn on your soldering iron and fume extractor and start soldering.

=== Tips on SMD soldering ===
SMD components are small and difficult to solder.
The easiest components to solder are the resistors and capacitors.
Start with these to get comfortable with SMD soldering first, then proceed to the more difficult ICs.<br>
A quick guide to SMD soldering can be found at [https://www.sparkfun.com/marcomm/SFE03-0010-KitCard-SolderingSMD-ReaderSpreads.pdf sparkfun.com].

=== Soldering Workflow ===
[[File:Closeup of one soldered pad and a resistor.jpg|thumb|right|Closeup of a pad with solder and a resistor]]
Take your BOM and choose one of the resistor values to begin with and identify the pad label, where the resistor is supposed to be placed.
Now take your soldering iron and heat one side of the pad. After a couple of seconds of heating, add some solder to the pad.
Take out one of the resistors out of it's packaging and grab onto it with the tweezers as indicated in the picture on the right.
Heat the solder blob and slide the component into the molten solder from the side.
This ensures covering of the components contacts.
Placing the component into the blob from above can lead to solder bridges underneath the component, which will render the component useless.
Once one side of the component is fixed, it's good practice to lightly press down on the component and remelt the solder.
Doing this will help to mount the component flush to the board.
Although not always necessary, doing this will help to avoid solder bridges, especially between the legs of ICs.
[[File:Flush component.jpg|x300px|thumb|right|Component lifted on one side (top); pressed down and after remelting the solder (bottom)]]

=== Integrated Circuits (ICs) ===
{{#evt:service=youtube|id=E3kZMtjD76c|alignment=right|container=frame|description=Timelapse of IC soldering|dimensions=480}}