You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The setup to capture raw data needed for #2 is a bit too involved for casual users.
For example, to capture SPS30 messages (47 bytes long) from /dev/ttyUSB0 one needs to
The obscurity of the commands involved is not going to help gaining contributions for #2.
Besides the commands are slightly different for different sensors.
With the introduction of -n N, --samples N on #4, one can further extend the application to provide the raw data on the right format. The following would capture 10 messages, with a frequency of 15 seconds:
pms -s /dev/ttyUSB0 -m SPS30 -n 10 -i 15 raw
capture
Saving raw data to a file could be a good way to create sample data for testing.
This would provide a path to test the command line interface without real hardware attached.
would write the raw data into a file with a well defined name pattern, e.g. start-time.pms. In the previous example, the file name would be something line 2020-01-01_15:22:23.pms
The extension .pms would indicate that we are not reading from a serial port.
The start time is retrieved from the filename. The complete file would be decode if number of samples (-n) is not specified.
combining sub-commands
pms serial and pms csv have some overlap with pms raw-data. Maybe this 3 sub-commands can be rolled into one.
In addition to reducing the number of options, combining this sub-commands would help with the coverage on travis builds.
The text was updated successfully, but these errors were encountered:
raw sample data
The setup to capture raw data needed for #2 is a bit too involved for casual users.
For example, to capture SPS30 messages (47 bytes long) from
/dev/ttyUSB0
one needs tostty -F /dev/ttyUSB0 min 0 -icanon tail -f /dev/ttyUSB0 | xxd -g1 -c47
The obscurity of the commands involved is not going to help gaining contributions for #2.
Besides the commands are slightly different for different sensors.
With the introduction of
-n N, --samples N
on #4, one can further extend the application to provide the raw data on the right format. The following would capture 10 messages, with a frequency of 15 seconds:capture
Saving raw data to a file could be a good way to create sample data for testing.
This would provide a path to test the command line interface without real hardware attached.
would write the raw data into a file with a well defined name pattern, e.g.
start-time.pms
. In the previous example, the file name would be something line2020-01-01_15:22:23.pms
decode
Once we can capture raw data, caould decode it as
The extension
.pms
would indicate that we are not reading from a serial port.The start time is retrieved from the filename. The complete file would be decode if number of samples (
-n
) is not specified.combining sub-commands
pms serial
andpms csv
have some overlap withpms raw-data
. Maybe this 3 sub-commands can be rolled into one.In addition to reducing the number of options, combining this sub-commands would help with the coverage on travis builds.
The text was updated successfully, but these errors were encountered: