Fa-grafana 2.0 Release

[eric1tran]

Had some time to give attention to fa-grafana that we released a while back

Fa-grafana - Dockerized Grafana Dashboards

Hey all, We’ve been exploring some potential uses for Docker and Grafana recently. For those of you unfamiliar with Docker, it is a useful tool that makes it easy to create and deploy applications in the form of “containers”. Think of a container as a pre-packaged, lightweight environment containing all the software and dependencies required for an application to run. No need to worry about the hassle of installing dependencies on your system. Introducing…fa-grafana, a Dockerized environment …

This release

• Replaces previous dump1090 dashboard with a Flight Tracking dashboard that monitors piaware status and dump1090-fa metrics
• Adds a Raspberry Pi System Metrics dashboard to monitor system information
• Uses the latest dump1090exporter which reduces the Docker image size from 727 MB to 50.6MB

GitHub - flightaware/fa-grafana: Grafana dashboards for PiAware

Grafana has some alerting capability that would be interesting to explore. If anyone’s done anything cool with Grafana, feel free to share!

(I am aware that SD card wear may be an issue over time. Ultimately, I’d like to have it where you’d run Grafana and Prometheus externally on dedicated, durable hardware and you can monitor/scrape all your receivers with the Prometheus exporters running on them.)

[foxhunter]

Nice!

Would it work with Piaware running on a different device?
I am using a Jetvision receiver with Piaware installed on it, but would like to have Grafana running on a spare Raspberry accessing the Piaware install via network

Thanks

[eric1tran]

@foxhunter I just tested it out on a remote PiAware and it does…What decoder does the Jetvision receiver use?

First step would be to get the exporters running on it. Just remove Prometheus and Grafana sections from the docker-compose file before starting it up. (I’m assuming it serves piaware status.json and /data/aircraft.json on port 8080…you’ll need a slight tweak if it’s on a different port)

You can confirm everything is working as expected if you see the metrics on port 9100, 9101, and 9105. Then we can move on to the other Pi setup.

[foxhunter]

Thanks for your reply

unfortunately there is no /data/aircraft.json on the device accessible via web interface. It even does not have 8080 open.

Jetvision is using a self developed decoder which combines also the web interface named rcd (short for Radarcape decoder), so that might not work directly.

As i do have a commercial license all ports are open and i could setup dump1090 or readsb on the networked Pi grabbing data from one of the open ports as a helper application.

Then i would not need to maintain lots of files individually and do not need to install something on the Jetvision device.

Let me try it that way first.

[AhrBee]

@eric1tran

(I am aware that SD card wear may be an issue over time. Ultimately, I’d like to have it where you’d run Grafana and Prometheus externally on dedicated, durable hardware and you can monitor/scrape all your receivers with the Prometheus exporters running on them.)

For the adventuresome enthusiasts - one can repurpose a thin client with SSD for relatively cheap and not ‘sandpaper’ SD cards. If one has a newer Raspberry Pi, one can run off SSD plugged into a free USB 3.0 port as well.

Reference:

FYI: Alternatives to Raspberry Pi for this hobby

Seeing the low availability and (when available) prices for Raspberry Pi of various models, I set out to look for alternatives that I can get within my limited budget, yet still have a soemthing I can experiment with. Maybe obvious to folks here, but I found that repurposing a thin client meets my needs nicely, and I thought I would share my perceived benefits of experiences here. Definitely not a ‘plug-and-go’ approach, but if one is motivated to dig and learn and has some te…

[SOLVED] SLAX Linux AMD64 OS: faup1090 is not working

You are right. The Radio was Generic DVB-T and the antena was the mag-mout whip supplied with the DVB-T, It was placed indoors on a cookie-can lid, just a meter away from the dongle (the length of coax of antenna is only one meter)

[foxhunter]

@AhrBee

For the adventuresome enthusiasts - one can repurpose a thin client with SSD for relatively cheap and not ‘sandpaper’ SD cards. If one has a newer Raspberry Pi, one can run off SSD plugged into a free USB 3.0 port as well.

That’s why currently two of my Raspberries are running 100% on SSD.
Meanwhile smaller SSD (128GB are not more expensive than similar SD cards)

For USB 3.0 high speed for sure you need a Raspberry 4
The Raspberry 3 is significantly slower, some SD cards can outperform an SSD connected to it’s USB slot

[HenryAbbott]

Just an aside: it is difficult to check, but most of these cheap mag-mount antennas do not have coax at all: it is just a simple wire. I learned this when I tried to use the “coax” for screening in a receiver to pick up the IF for frequency display.

[glennblum]

Pretty interesting. It was a easy install and the learning curve was easy.

[MC130E]

@foxhunter

Jetvision is using a self developed decoder which combines also the web interface named rcd (short for Radarcape decoder), so that might not work directly.

As i do have a commercial license all ports are open and i could setup dump1090 or readsb on the networked Pi grabbing data from one of the open ports as a helper application.

Foxhunter,

About that Jetvision receiver. We have many PlanePlotter users pulling beast binary data from their Radarcapes and Air!Squitters (with commercial license) over TCP ports 10002 or 10003. For us, the preferred one is 10003 since it filters out some of the bad CRC messages and does not forward them to the next piece of software to filter out.

The Jetvision 10003 port will work exactly like a dump1090-fa type port=30005. You can use beast-splitter or your favorite receiver to connect to it. If you do not need mode-a/c, you can disable that with a separate menu option.

Raw Data Streaming to Network (TCP and UDP)

Radarcape/Air!Squitter Features

Reference the Piaware software on the Jetvision device. There is a similar issue with the direct uploading feature that “supports” feeding data to the PlanePlotter network has some limitations. For the PP network, the built-in Jetvision feeder does not support mlat, so most pull the data from the Jetvision device and then upload another way.

Those are nice receivers. Their advertising for the Air!Squitter especially can be a bit misleading and we have had a couple new PP users purchase them only later to find out that the ports are not open without the very expensive commercial license. They have since changed their advertising to be a bit clearer.

-Dan

[foxhunter]

I think you did not get my statement.replying to the question “what decoder does Jetvision receiver use?” from above

I know how to access the open ports of a Jetvision device. Mine is running since two years now.
But the above solution requires access to the JSON files generated by decoders like dump1090 or readsb.

The Jetvision devices use their own decoders without these JSON files.
As i said i do have the ports open and operate a Raspberry getting the data from it.

[MC130E]

@foxhunter

I think you did not get my statement.replying to the question “what decoder does Jetvision receiver use?” from above

Hi,

Copy all. When you mentioned possibly pulling raw data from one of the Jetvision open ports and creating the json elsewhere, I did not realize you were already doing so.

Sorry for the clutter to the thread.

Thanks,
-Dan

[eric1tran]

I see. You should be able to get the dump1090exporter image running on your networked Pi then and get Grafana monitoring either decoder. PiAware/node exporter metrics may be a little difficult without installing anything on the Jetvision device. Let me know if you have any questions or run into anything.

[foxhunter]

Thanks

I will give it a try over the weekend. Shouldn’t be that complicated.
the Jetvision device does have a port open for periodic JSON, but it’s different to the structure of the dump1090 decoder. Maybe i dig into this as well.

@MC130E

Sorry for the clutter to the thread.

Nothing to say sorry about it. Can happen.

[marcoprocopio92]

The dashboards look great.
Can’t get the project working on my Raspberry 3B though running piaware via WiFi.

At first I was getting UnixHTTPConnectionPool(host=‘localhost’, port=None): Read timed out. (read timeout=60) when running docker-compose up

some googling seemed to suggest to add to .env
DOCKER_CLIENT_TIMEOUT=120
COMPOSE_HTTP_TIMEOUT=120

Which now results in the following error when retrying docker-compose up
ROR: for node-exporter Cannot start service node-exporter: OCI runtime create failed: container_linux.go:367: starting container process caused: process_linux.go:340: applying cgroup configuration for process caused: error while starting unit “docker-b8dadbc39afdfd7af8245b16c565da935484236fc9218c73e7c3098637685181.scope” with properties [{Name:Description Value:“libcontainer container b8dadbc39afdfd7af8245b16c565da935484236fc9218c73e7c3098637685181”} {Name:Slice Value:“system.slice”} {Name:PIDs Value:@au [2237]} {Name:Delegate Value:true} {Name:MemoryAccounting Value:true} {Name:CPUAccounting Value:true} {Name:IOAccounting Value:true} {Name:DefaultDependencies Value:false} {Name:DevicePolicy Value:“strict”} {Name:DeviceAllow Value:@a(ss) } {Name:DeviceAllow Value:[“INVALID”, “INVALID”, “INVALID”, “INVALID”, “INVALID”, “INVALID”, “INVALID”, “INVALID”, “INVALID”, “INVALID”, “INVALID”, “INVALID”]}]: Failed to activate service ‘org.freedesktop.systemd1’: timed out (service_start_timeout=25000ms): unknown
For each of the three docker images.

[marcoprocopio92]

Hi, just wanted to say that this must have been my Piaware image being corrupted in some way.
I started over with a fresh Piaware image and the Grafana setup worked as per GH readme with no problems.