Of course, still runs on some of my servers.

Why? Because I know it inside and out, it's simple, I know exactly what is running, when it's running and how it's running.

Glad to hear. Something to say to know the entirety of the system instead of just going with the trendiest option.

Tell that to the Romans :)

Why was the HackRF not included at all?

I don't have a good definitive answer to your question, other than we had to limit the scope of our work and we chose a representative set of devices amongst the ones that people showed interest in. Despite its popularity in wireless security research, I don't think the HackRF is widespread in the satcom or cubesat communities.

As far as I know (@csete or others might correct me here if I'm wrong), HackRF is primary a benchtop Software Defined Radio, and it's excellent for testing, prototyping, etc.

The paper @csete works on is focused on the use of such devices to enable satellite communications one should take into accounts the limitations and challenges of such signals (especially when working with Low Earth Orbit satellites).

HackRF is a great product with great value; if you are seeking to experiment with a versatile Software Defined Radio. In my personal opinion, it is the "swiss army knife" of SDRs.

Thank you for the explanation, I appreciate it :)

Is this a spinoff of StreamAlert? Any differences between the 2?

Yes, I was the original core dev of StreamAlert during my time at Airbnb.

I'd say the biggest differences are that Panther:

- Has a UI-driven workflow (vs CLI)

- Has an improved design to be more scalable and cost-effective

- Is written almost entirely in Golang

- Made a larger investment in the Athena side, allowing data pivoting and correlation across types

- Has first-class support for monitoring infrastructure as "resources", opening up more compliance use cases

We applied a lot of lessons learned from running StreamAlert and from my team's experiences at Amazon.

Thank you!