-
Notifications
You must be signed in to change notification settings - Fork 0
Add maude_kwargs #89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add maude_kwargs #89
Conversation
Needs tests. |
My first go at using this to get ASVT data in the range for the test bits failed as it looks like IMGTYPE=3. @mbaski is IMGTYPE=3 expected in the test data?
|
@javierggt Do you agree the issue here a) that this is IMGTYPE=3 data and b) that doesn't index into IMG_INDICES? Also, how do you think that should be handled? Null pixel data or? The unhandled exception probably not the right thing. |
Not sure what IMGTYPE represents but AAPIXTLM only has values of 0, 1, and 2 in the data: >> tlm = data_source_telemetry;
>> tlm.tlm_server_url = [fileparts(tlm.tlm_server_url) '/ASVT'];
>> tlm.time_start = time('2020:008:23:30');
>> tlm.time_end = time('2020:009:00:45');
>> [d,t] = tlm.get_data_by_name('AACAINT0');
>> bin = dec2bin(unique(d),16)
bin =
0000000001101010
0010000001101010
0110000001101010
1010000001101010
>> bin2dec(bin(:,1:2))
ans =
0
0
1
2 |
Thanks Mark. Sorry, I confused this issue. I was trying to look at the those header bits, but the decom we have in this module also tries to organize the pixel data. IMGTYPE is what we are calling the later word that is supposed to indicate for each slot if we are getting a 4x4, part of 6x6, or part of an 8x8. It also has a type=3 that indicates "memory download". That type=3 is unhandled in this decom code as far as I can tell and threw an exception. But, I suppose at this point I don't know if that is a problem with my first go at using the ASVT channel, if that is expected the way you are using the PEA, or if there could be another problem with this decom or my changes. DS reports a little diff in the data with the dat file:
so simultaneous to double-checking that I figured I'd look at getting this decom code in order |
Sorry for the noise @mbaski, this IMGTYPE=3 was due to a bug I introduced; the decom code was getting some information from FLIGHT and some from ASVT and making a mess of it. |
No worries, glad you're making progress! |
This seems fine to me. Nothing controversial. I would normally just call it kwargs because that is just the standard. If you ever decided to use any argument in there before passing it to maude, they will cease to be "maude kwargs" and would just be "kwargs." Still, whatever the name I am ok with it. |
Thanks @javierggt. I'm also fine with maude_kwargs or kwargs; went with maude_kwargs because that was @taldcroft 's suggestion and because all the (not specified) kwargs are going to maude at this point. |
Superseded by #90 |
Add maude_kwargs