The monitoring script has been completely changed and released in the 2.1.000 hotfix. I’ll explain here what the changes are and why we had to change it.
First of all, the reason for the change. We have decided to reduce the payload size in order to support low-bandwidth or low-data cap connections in remote areas. A single data point is now around 34 bytes as opposed to around 230 bytes in the previous version. Unlike the previous version, the data is transmitted in binary (although it is still stored in readable JSON format).
The new data format consist of the following fields:
start marker (OHD, short for Outernet Heartbeat Datagram)
device ID (128-bit identifier reasonably unique to each receiver)
timestamp (4 bits, low-resolution creation time relative to previous heartbeat datagram)
tuner vendor ID (16-bit)
tuner model ID (16-bit)
tuner preset ID (5 bits, finger preset of the tuner settings used to identify the satellite in use)
signal lock (1 bit)
service lock (1 bit)
signal strenght (4 bits)
SNR/quality (5 bits)
bitrate (6 bits)
carousel count (5 bits)
carousel status (31 bits for tracking up to 31 carousels, on/off for each)
end marker (DHO, reverse of the start marker)
The source code can be found on GitHub if you have concerns about what we collect and what we do with it. The monitoring script is in readable format on your receiver.
NOTE: Monitoring can be disabled by removing the file /mnt/persist/monitoring.yes. To do that, SSH into your device and run the following command:
sudo rm /mnt/persist/monitoring.yes
There is no need to restart your device. Monitoring will stop collecting and transmitting data as soon as you remove the file.
I saw the 500 error too. I think I didn’t wait long enough after the first power cycle of the Lighthouse. I gave it 5 minutes getting a coffee refill, and it came up with the setup screen.
Now I’ll wait to see what magical data comes down from Galaxy 19
The reason for that weird and ugly version number is a limitation in the sort utility in the OS which doesn’t recognize version numbers. Ideally, we’d use something like 2.1a1 or 2.1RC1 or something more human-friendly, but the sort would treat some of those as newer than 2.1, and not allow update from alpha/RC versions. So we dcided to have a 3-part version number where the last 3 digits are used for development snapshots.
We still haven’t plugged that issue, but did not want to delay the hotfix until that was fixed. We are currently working on a new algorithm for detecting reception problems as we’ve gained significantly more experience since the first monitoring server was implemented.
Would I be correct in assuming, since I am on Galaxy 19, and connected to the internet, your server would carry a report from me, or is the one receiver shown someone else? Seems as if there should be more than just 1 receiver reporting in on Galaxy 19. Ken
This is odd. Well, it’s a bug. We have a Lighthouse at the office pointed at G19. And there is another one in Boston that we use as a monitor. Not to mention one at my parents’ house. Those should all be online, but are not present in status.outernet
and Monitoring is running on my Lighthouse v2.0.000. I don’t know if the output was actually sent out over the internet to anybody. I’ll see if I can determine that. Ken
to see if the Monitor program is running? You are using 2.1.000, so it should be running. As I said to Syed, I don’t know if the output is going anywhere. The experts at Outernet will have to figure this one out. Ken
