RFC: Embed our knowledge of VSFR types into the batch reader #49
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following on to #48 , I thought I might do some initial work on simplifying the
batch_read_vsfrs()
API. As best I can tell, radiacode transports all VSFRs as uint32le on the wire, no matter how many information-bearing bits they contain: a bool takes 32 bits, just like a float.Conveniently, the
SFR_FILE
VS tells us which VSFR IDs are defined, and how to interpret them. It is fairly straightforward to parse the output of thecommands()
function which reads theSFR_FILE
to produce a dict of format strings.I updated
batch_read_vsfrs()
and its callers to omit the format argument, and just use the lookup dict to figure out what format to use.As a quick test, the
get_alarm_limits()
function works correctly, as does the hand-rolled equivalent ofenergy_calib()
:rc.batch_read_vsfrs([ CHN_TO_keV_A0, CHN_TO_keV_A1, CHN_TO_keV_A2])
Thoughs?
PS. here's the trashy script I used to generate the body of the lookup dict...