.WXTOIMG RASPBERRY UPDATE
.WXTOIMG RASPBERRY FREE
Fix #400 by using which to find path for meteor_demod.Disable sending of mail after "at" job execution by in #403.FLIP capture only if PASS_DIRECTION is Northbound by in #398.Add a push provider to Matrix by in #362.METEOR on TMPFS depending on free memory by in #359.Update push scripts so output is logged to the file by in #387.Add Missing Config to Schema and ffmpeg by in #337.
.WXTOIMG RASPBERRY CODE
for git fu, many general code contributions and for sanity checks on a nearly daily for testing and being patient! What's Changed.for his continued support, critical eye and key work on various elements of the ‘plumbing’.The list shows only those that there are scripts in the /image_processors/ folder - there are a couple purposefully left out, but would be easy to introduce for those keen to do so.
.WXTOIMG RASPBERRY MANUAL
We have enabled as many enhancements as possible in the NOAA workflows, and the webpanel now includes a hyperlink to a ‘details’ page that contains much of the documentation from the wxtoimg command line manual that relates to each enhancement type. It also means that colour-schema and other elements in the spectrograms can be more customised by those who want to do so. In the next iteration it may be suitable to flip it along with the NORTHBOUND passes so that as displayed in webpanel the timeline will alway flow in the same direction as the pass images shown (interference bars will then correlate in parallel between the two). The spectrogram has been moved from SOX generation to FFMPEG generation, and also is represented vertically instead of horizontally. py files showing where edits must be manually made AFTER exporting the python from gnuradio composer to make the scripts work with the RN2 settings. grc files and annotation in the current 'default'. More details on the deeper code is included in the new README included in the audio_processors folder, which includes sample. On day one most users defaulting to ‘gnuradio’ in their settings.yml will see little difference to RN2, but over time the community can now look to a common method to introduce new hardware support to the project. qpsk files that then can be used in the /image_processors/ scripts. py to interface the python workflow to the RN2 workflow (documented in the examples provided) and to then use alternative hardware to capture the source. This release DOES NOT seek to provide immediate access to the wider hardware options, but it DOES allow the community to begin to interface their own hardware by modifying the gnuradio composer files (.grc files included in the /audio_processors/ folder, to export python (.py) scripts similar to those included for the SDR, to copy the modifications that must then be made manually to the. Since gnuradio can allow interchange of such ‘source blocks’ this methodology potentially opens up RN2 to support wider SDR hardware options. In the original incarnation of RN2 the NOAA captures were driven directly through the audio_processor scripts to use rtl_fm directly, and the METEOR-M2 captures were driven using a python script that was originally generated in gnuradio and used the OSMOCOM source block, which in turn uses the rtl_fm binary to interface to the SDR card. ‘Defaulting to gnuradio’Ī number of users have expressed an interested to support a wider variety of SDR hardware devices beyond those interfaced to the original default rtl-sdr cards through the rtl-fm based commands used in the associated drivers.
0 kommentar(er)
