Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Built-in file processor for binary BEAST format #35

Closed
wants to merge 3 commits into from

Conversation

denzen84
Copy link

@denzen84 denzen84 commented Feb 28, 2019

Hi all!

Almost a year ago I released beastblackbox utility to process binary BEAST logs.

Today I finished module for dump1090-fa that releases processing for binary BEAST files using standard interface for different types of SDR readers.

I tried to strictly follow the ideology and structure when writing this module. All changes made to neighboring modules (dump1090.h, sdr.c, net_io.c, net_io.h) were forced and did not changes the data processing code. The changes concerned only scope of visibility for certain functions.

Also I note changes in the net_io.c module. I separated the code responsible for generating output in the SBS format as a standalone function. So that this function could be used from other modules.

I hope you found this commit useful.

@denzen84 denzen84 changed the title Built-on file processor for binary BEAST format Built-in file processor for binary BEAST format Feb 28, 2019
@mutability
Copy link

I'm in two minds about this. This has several things going on, not all of which I want to take:

  1. some extra utility options e.g. SBS output to stdout
  2. some general changes e.g. the switch-vs-if thing
  3. the beast-format input thing

I'd like to see (1) and (2) as separate PRs. Some of the extra options I'm not sure even belong in dump1090; ideally I'd like to stop bolting on new options to dump1090 and have some separate utilities if you want to do things like e.g. ICAO filtering. (this is not a trivial thing to do, I admit).

Re performance, I will generally resist changes to make it "faster" at the expense of clarity unless you can demonstrate a non-trivial improvement, which mostly means changes in the demodulator and almost nowhere else; message decoding is super cheap compared to demodulation.

For (3) I really don't like the current implementation that bolts it on to the SDR logic; that's really the wrong place for it as you're entirely bypassing the demodulator in this case. It should be a separate input mechanism along the lines of network input.

@mutability
Copy link

I don't think I can merge this as-is.

@mutability mutability closed this Aug 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants