MS0NTR-Radio-Club
/
dump1090-fa
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
dump1090-fa/util.h

70 lines
2.4 KiB
C
Raw Permalink Normal View History

Only emit network messages once we have seen two of them (except in --net-verbatim mode, where we emit them all) Move aircraft tracking into track.[ch]. Clean up references to "interactive mode" when tracking aircraft - we always track aircraft, even in non-interactive mode.
2015-02-08 14:27:03 +00:00
// Part of dump1090, a Mode S message decoder for RTLSDR devices.
//
fix a trivial copy-paste typo in comments Signed-off-by: Gluttton <gluttton@ukr.net>
2020-08-31 19:51:29 +00:00
// util.h: misc utilities prototypes
Only emit network messages once we have seen two of them (except in --net-verbatim mode, where we emit them all) Move aircraft tracking into track.[ch]. Clean up references to "interactive mode" when tracking aircraft - we always track aircraft, even in non-interactive mode.
2015-02-08 14:27:03 +00:00
//
// Copyright (c) 2015 Oliver Jowett <oliver@mutability.co.uk>
//
Whitespace changes only: cleaning up trailing whitespace at EOL
2017-06-15 17:16:51 +00:00
// This file is free software: you may copy, redistribute and/or modify it
Only emit network messages once we have seen two of them (except in --net-verbatim mode, where we emit them all) Move aircraft tracking into track.[ch]. Clean up references to "interactive mode" when tracking aircraft - we always track aircraft, even in non-interactive mode.
2015-02-08 14:27:03 +00:00
// under the terms of the GNU General Public License as published by the
Whitespace changes only: cleaning up trailing whitespace at EOL
2017-06-15 17:16:51 +00:00
// Free Software Foundation, either version 2 of the License, or (at your
// option) any later version.
Only emit network messages once we have seen two of them (except in --net-verbatim mode, where we emit them all) Move aircraft tracking into track.[ch]. Clean up references to "interactive mode" when tracking aircraft - we always track aircraft, even in non-interactive mode.
2015-02-08 14:27:03 +00:00
//
Whitespace changes only: cleaning up trailing whitespace at EOL
2017-06-15 17:16:51 +00:00
// This file is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Only emit network messages once we have seen two of them (except in --net-verbatim mode, where we emit them all) Move aircraft tracking into track.[ch]. Clean up references to "interactive mode" when tracking aircraft - we always track aircraft, even in non-interactive mode.
2015-02-08 14:27:03 +00:00
// General Public License for more details.
//
Whitespace changes only: cleaning up trailing whitespace at EOL
2017-06-15 17:16:51 +00:00
// You should have received a copy of the GNU General Public License
Only emit network messages once we have seen two of them (except in --net-verbatim mode, where we emit them all) Move aircraft tracking into track.[ch]. Clean up references to "interactive mode" when tracking aircraft - we always track aircraft, even in non-interactive mode.
2015-02-08 14:27:03 +00:00
// along with this program. If not, see <http://www.gnu.org/licenses/>.
#ifndef DUMP1090_UTIL_H
#define DUMP1090_UTIL_H
#include <stdint.h>
Don't hang on exit if rtlsdr hardware stops sending samples. Give up and exit after 30 seconds of no sample data, rather than just warning and continuing. background & discussion: https://discussions.flightaware.com/t/cpu-hikes-crash-dump1090-fa/74759 The scenario this addresses is: * Hardware wedges, USB bulk endpoint stops providing data * librtlsdr remains in rtlsdr_read_async() waiting for either USB data which never arrives, or a cancellation via _a different thread_ calling rtlsdr_cancel_async(). * main thread notices the lack of SDR data and complains * something external e.g. piaware tries a restart and sends SIGTERM * the signal handler sets Modes.exit = 1; the main thread starts waiting for receive thread termination * because we're never getting callbacks from rtlsdr_read_async(), we never call rtlsdr_cancel_async * dump1090 hangs waiting on receive thread termination To fix this, add a sdrStop() handler function where the general contract is "make the receive thread terminate". In the rtlsdr case, this calls rtlsdr_cancel_async directly, which will make rtlsdr_read_async() return even if the hardware is stuck. The main thread then calls sdrStop() before waiting for receive thread termination. Also, as discussed in the thread above, there's not really much point in continuing to run if the SDR has wedged, so bail out after 30 seconds of no sample data. Also, if pthread_timedjoin_np is available, use it in preference to pthread_join so that we do not wait indefinitely for the receive thread on shutdown. If the join times out, give up and abort() as we can't safely continue a clean shutdown while the receive thread is running.
2021-03-20 17:51:08 +00:00
#include <pthread.h>
Only emit network messages once we have seen two of them (except in --net-verbatim mode, where we emit them all) Move aircraft tracking into track.[ch]. Clean up references to "interactive mode" when tracking aircraft - we always track aircraft, even in non-interactive mode.
2015-02-08 14:27:03 +00:00
Store computed reception time in the message struct so we don't rely on the message being emitted immediately. Fix computation of reception time so it's more sensible (the block timestamp is some time after reception of the _end_ of the block, not the start) - this means that message-emission times are always later than message-reception times in SBS output, which is a bit more sensible. Use clock_gettime in preference to ftime.
2015-02-08 17:46:01 +00:00
/* Returns system time in milliseconds */
Only emit network messages once we have seen two of them (except in --net-verbatim mode, where we emit them all) Move aircraft tracking into track.[ch]. Clean up references to "interactive mode" when tracking aircraft - we always track aircraft, even in non-interactive mode.
2015-02-08 14:27:03 +00:00
uint64_t mstime(void);
WIP on new faup1090 output, data aging, refactoring
2017-12-02 17:38:33 +00:00
/* Returns the time for the current message we're dealing with */
extern uint64_t _messageNow;
static inline uint64_t messageNow() {
return _messageNow;
}
Store computed reception time in the message struct so we don't rely on the message being emitted immediately. Fix computation of reception time so it's more sensible (the block timestamp is some time after reception of the _end_ of the block, not the start) - this means that message-emission times are always later than message-reception times in SBS output, which is a bit more sensible. Use clock_gettime in preference to ftime.
2015-02-08 17:46:01 +00:00
/* Returns the time elapsed, in nanoseconds, from t1 to t2,
uint64_t (even at 12MHz) isn't going to overflow any time soon, don't worry about wrapping.
2015-02-08 17:59:20 +00:00
* where t1 and t2 are 12MHz counters.
Store computed reception time in the message struct so we don't rely on the message being emitted immediately. Fix computation of reception time so it's more sensible (the block timestamp is some time after reception of the _end_ of the block, not the start) - this means that message-emission times are always later than message-reception times in SBS output, which is a bit more sensible. Use clock_gettime in preference to ftime.
2015-02-08 17:46:01 +00:00
*/
uint64_t (even at 12MHz) isn't going to overflow any time soon, don't worry about wrapping.
2015-02-08 17:59:20 +00:00
int64_t receiveclock_ns_elapsed(uint64_t t1, uint64_t t2);
Store computed reception time in the message struct so we don't rely on the message being emitted immediately. Fix computation of reception time so it's more sensible (the block timestamp is some time after reception of the _end_ of the block, not the start) - this means that message-emission times are always later than message-reception times in SBS output, which is a bit more sensible. Use clock_gettime in preference to ftime.
2015-02-08 17:46:01 +00:00
WIP on new faup1090 output, data aging, refactoring
2017-12-02 17:38:33 +00:00
/* Same, in milliseconds */
int64_t receiveclock_ms_elapsed(uint64_t t1, uint64_t t2);
Store computed reception time in the message struct so we don't rely on the message being emitted immediately. Fix computation of reception time so it's more sensible (the block timestamp is some time after reception of the _end_ of the block, not the start) - this means that message-emission times are always later than message-reception times in SBS output, which is a bit more sensible. Use clock_gettime in preference to ftime.
2015-02-08 17:46:01 +00:00
/* Normalize the value in ts so that ts->nsec lies in
* [0,999999999]
*/
struct timespec;
void normalize_timespec(struct timespec *ts);
Factor out FIFO handling; reimplement as a linked list, not a circular buffer. Update all the SDR implementation to use it. This was getting pretty ugly with code getting copy&pasted in all the SDR implementations. Unify it all and give it a simpler API. Linked list works out much simpler than the circular buffer. Also, simplify copying the overlap region around by just using a separate buffer (it's only a few hundred bytes long, so the double copy is not a big deal).
2020-08-05 08:18:59 +00:00
/* Find the absolute system time that is `timeout_ms` milliseconds in the future, and store that in *ts */
void get_deadline(uint32_t timeout_ms, struct timespec *ts);
Move {start,end}_cpu_timing into util.c
2017-01-27 12:33:43 +00:00
/* record current CPU time in start_time */
void start_cpu_timing(struct timespec *start_time);
/* add difference between start_time and the current CPU time to add_to */
void end_cpu_timing(const struct timespec *start_time, struct timespec *add_to);
Factor out sdr thread CPU monitoring
2020-08-05 04:00:50 +00:00
/* like end_cpu_timing followed by start_cpu_timing, but without a gap */
void update_cpu_timing(struct timespec *start_time, struct timespec *add_to);
Set SDR thread name if pthread_setname_np() is available
2020-08-05 03:51:32 +00:00
/* set current thread name, if supported */
void set_thread_name(const char *name);
Don't hang on exit if rtlsdr hardware stops sending samples. Give up and exit after 30 seconds of no sample data, rather than just warning and continuing. background & discussion: https://discussions.flightaware.com/t/cpu-hikes-crash-dump1090-fa/74759 The scenario this addresses is: * Hardware wedges, USB bulk endpoint stops providing data * librtlsdr remains in rtlsdr_read_async() waiting for either USB data which never arrives, or a cancellation via _a different thread_ calling rtlsdr_cancel_async(). * main thread notices the lack of SDR data and complains * something external e.g. piaware tries a restart and sends SIGTERM * the signal handler sets Modes.exit = 1; the main thread starts waiting for receive thread termination * because we're never getting callbacks from rtlsdr_read_async(), we never call rtlsdr_cancel_async * dump1090 hangs waiting on receive thread termination To fix this, add a sdrStop() handler function where the general contract is "make the receive thread terminate". In the rtlsdr case, this calls rtlsdr_cancel_async directly, which will make rtlsdr_read_async() return even if the hardware is stuck. The main thread then calls sdrStop() before waiting for receive thread termination. Also, as discussed in the thread above, there's not really much point in continuing to run if the SDR has wedged, so bail out after 30 seconds of no sample data. Also, if pthread_timedjoin_np is available, use it in preference to pthread_join so that we do not wait indefinitely for the receive thread on shutdown. If the join times out, give up and abort() as we can't safely continue a clean shutdown while the receive thread is running.
2021-03-20 17:51:08 +00:00
/* wait for the given thread to terminate, like pthread_join. If supported,
* if the thread has not terminated within `timeout_ms` milliseconds, return ETIMEDOUT.
*/
int join_thread(pthread_t thread, void **retval, uint32_t timeout_ms);
Only emit network messages once we have seen two of them (except in --net-verbatim mode, where we emit them all) Move aircraft tracking into track.[ch]. Clean up references to "interactive mode" when tracking aircraft - we always track aircraft, even in non-interactive mode.
2015-02-08 14:27:03 +00:00
#endif