NTIA/ITS Spectrum Monitoring SCOS sensor reference implementation
OTHER License
Bot releases are hidden (Show)
This release includes the following changes:
Published by jhazentia over 4 years ago
The largest change in the release is that the /acquisitions
endpoint, which holds data produced when the scheduler runs a task that saves data in the database, and the /results
endpoint, which was created later to give some status information about each task run, have been merged into a new /tasks
endpoint.
We also took this opportunity to relocate the "task queue", which provides a snapshot of upcoming tasks as seen by the scheduler, from the /status
endpoint into /tasks
.
/tasks/upcoming
now shows the tasks queue. It now shows at most settings.MAX_TASK_QUEUE
upcoming tasks.
/tasks/completed
gives overview information about the number of results available for each schedule entry that you have permissions to view, and also provides a link to download a multi-recording archive of all available data for that schedule entry.
/tasks/completed/{schedule_entry_name}
lists each task result and "metadata" and SigMF "archive" links under the new data key, if available.
/tasks/completed/{schedule_entry_name}/{task_id}
shows the detail view for a single task result.
Multi-recording SigMF archives are now supported, which means actions can produce them. The "stepped frequency" style actions now produce a multi-recording archive to allow a different sample rate at each center frequency.
Python 3.7 or later is required
Other changes:
/configs/actions/README.md
)/tasks/upcoming
) "time" field changed from epoch timestamp to datetime string to better align with rest of APIpre-commit
. See the DEVELOPING.md file for notesPublished by bradeales over 4 years ago
The largest change in the release is that the /acquisitions
endpoint, which holds data produced when the scheduler runs a task that saves data in the database, and the /results
endpoint, which was created later to give some status information about each task run, have been merged into a new /tasks
endpoint.
We also took this opportunity to relocate the "task queue", which provides a snapshot of upcoming tasks as seen by the scheduler, from the /status
endpoint into /tasks
.
/tasks/upcoming
now shows the tasks queue. It now shows at most settings.MAX_TASK_QUEUE
upcoming tasks.
/tasks/completed
gives overview information about the number of results available for each schedule entry that you have permissions to view, and also provides a link to download a multi-recording archive of all available data for that schedule entry.
/tasks/completed/{schedule_entry_name}
lists each task result and "metadata" and SigMF "archive" links under the new data key, if available.
/tasks/completed/{schedule_entry_name}/{task_id}
shows the detail view for a single task result.
Multi-recording SigMF archives are now supported, which means actions can produce them. The "stepped frequency" style actions now produce a multi-recording archive to allow a different sample rate at each center frequency.
Other changes:
/configs/actions/README.md
)/tasks/upcoming
) "time" field changed from epoch timestamp to datetime string to better align with rest of APIpre-commit
. See the DEVELOPING.md file for notesPublished by jhazentia over 5 years ago
The largest change in the release is that the /acquisitions
endpoint, which holds data produced when the scheduler runs a task that saves data in the database, and the /results
endpoint, which was created later to give some status information about each task run, have been merged into a new /tasks
endpoint.
We also took this opportunity to relocate the "task queue", which provides a snapshot of upcoming tasks as seen by the scheduler, from the /status
endpoint into /tasks
.
/tasks/upcoming
now shows the tasks queue. It now shows at most settings.MAX_TASK_QUEUE
upcoming tasks.
/tasks/completed
gives overview information about the number of results available for each schedule entry that you have permissions to view, and also provides a link to download a multi-recording archive of all available data for that schedule entry.
/tasks/completed/{schedule_entry_name}
lists each task result and "metadata" and SigMF "archive" links under the new data
key, if available.
/tasks/completed/{schedule_entry_name}/{task_id}
shows the detail view for a single task result
Multi-recording SigMF archive are now supported, which means actions can produce them. The "stepped frequency" style actions now produce multi-recording archive to allow a different sample rate at each center frequency.
Other changes:
/tasks/upcoming
) "time" field changed from epoch timestamp to datetime string to better align with rest of APIpre-commit
. See the DEVELOPING.md file for notesPublished by djanderson over 5 years ago
The largest change in the release is that the /acquisitions
endpoint, which holds data produced when the scheduler runs a task that saves data in the database, and the /results
endpoint, which was created later to give some status information about each task run, have been merged into a new /tasks
endpoint.
We also took this opportunity to relocate the "task queue", which provides a snapshot of upcoming tasks as seen by the scheduler, from the /status
endpoint into /tasks
.
/tasks/upcoming
now shows the tasks queue. It now shows at most settings.MAX_TASK_QUEUE
upcoming tasks.
/tasks/completed
gives overview information about the number of results available for reach schedule entry that you have permissions to view, and also provides a link to download a multi-recording archive of all available data for that schedule entry.
/tasks/completed/{schedule_entry_name}
lists each task result and "metadata" and SigMF "archive" links under the new data
key, if available.
/tasks/completed/{schedule_entry_name}/{task_id}
shows the detail view for a single task result
Multi-recording SigMF archive are now supported, which means actions can produce them. The "stepped frequency" style actions now produce multi-recording archive to allow a different sample rate at each center frequency.
Other changes:
/tasks/upcoming
) "time" field changed from epoch timestamp to datetime string to better align with rest of APIpre-commit
. See the DEVELOPING.md file fore notesPublished by djanderson over 5 years ago
This release makes several modification to the API in order to better handle having a large number of acquisitions on disk. The changes include
next
and previous
page links, a link count
, and results
which holds the original array. Thank to this, loading a very large list of acquisitions will not crash the system.GET /api/v1/schedule/
HTTP 200 OK
Allow: GET, POST, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept
{
"count": 5,
"next": null,
"previous": null,
"results": [
...
]
}
/api/v1/acquisitions/
overview now includes an archive
link option which will create a single multi-recording SigMF archive of all available acquisitionsPublished by djanderson almost 6 years ago
Issue was in the actual USRP interface code and is not hit by tests or the monitor_usrp
task, so slid through. Re: issue #135.
Published by djanderson almost 6 years ago
Published by djanderson almost 6 years ago
Fix an issue where the autoheal tagged image wasn't being downloaded properly.
Published by djanderson almost 6 years ago
This release includes many updates from almost a half year of running sensors in the lab.
Some of the many improvements include:
stop
into absolute_stop
and relative_stop
, where absolute_stop
takes an ISO 8601 datetime string and relative_stop
is seconds after start.sync_gps
actionactive
flag to schedule entryresults
endpointvalidate_only
capability to schedule entryapi
docker containerautoheal
at build-time instead of runtime to allow sensor to run without network connectionmonitor_usrp
task even more robustPublished by djanderson over 6 years ago
This fixes a docker image build issue in the v0.1-beta.2 release.
New:
Updated:
Published by djanderson over 6 years ago
New:
/admin
(not /api/v1/admin
), used to add and change sensor definition and sub-typesTaskResult
modelcallback_url
field is added to the schedule entry which adds allows the scheduler to POST a JSONified TaskResult
after each taskUpdated:
Published by djanderson almost 7 years ago
Includes breaking change: ScheduleEntry object's relative_stop
property is now named stop_is_relative
.
Published by djanderson almost 7 years ago