Kaitai: how to discard if type f4 field is 0xffffffff

SatNOGS Software
1

For RSP-03 we have to discard type f4 fields if they are of value 0xffffffff.

Things like

– id: check
type: f4

instances:
after_check:
if: check != 0xffffffff
value: check

or

– id: check
type: f4
valid:
expr: _ != 0xffffffff

won’t work.
We cannot compare with 0xffffffff since kaitai reads and translates that to NaN.

I’ve also tried to convert the f4 value to a string or an integer (.to_s or .to_i) for comparing, but then it seems there is no way to convert it back to a f4 value.

Any ideas?

While decode_frame shows 0xffffffff values just as NaN, satnogs discards the whole frame and so no values are written into Grafana DB at all.

1 Like
2

As a workaround, maybe try doing bitwise Xor with 0xffffffff and test if the result is 0x0?

3

Could you give an example?

4

expr: _ ^ 0xffffffff == 0

5

Btw, it would be great if you could share a link to the Kaitai web IDE with the current parser and example data. Then any suggestion could be easily validated.

6

We came across yesterday with a similar situation for the PHASMA mission, the solution we (@surligas @dzourn and I) found is that if a field returns a NaN value then it should be omitted and not pushed in InfluxDB. I’m going to open an issue and fix this for the next DB release.

1 Like
7

Hello,

I will also have a look, i m too busy these days (probably until the beginning of November) but i keep that in mind.

@fredy From my pov right now, yeah maybe we can discard the field, but in the long run, i think it is not really good, because this value even if there is an issue with kaitai to handle it, can be valuable for a sat team to know about and so keeping it. Maybe it is not the case for PHASMA and RSP-03 but at some point it can happen.

8

kaitai answers with

not matching the expression, got [NaN]

The problem is because 0xffffffff is parsed as NaN and NaN can be neither Xored nor compared with a number.

I don’t know where to get the link of my current kaitai IDE.
These are the decoder (from kosen-1) and the testfile I’ve used:
test-decoder.zip (1.5 KB)

9

Ok. Thanks for checking.

Maybe you could first parse the value into a raw type with a different id, do the validation and then create an instance with the f4 type only if validation is successful?

So like your first attempt, but with no type, and then use typecasting for the instance to convert to f4.

10

Parsing it into a byte array gives the chance to compare it.

  - id: byte_array
    size: 4
    valid:
        expr: _  != [255,255,255,255]

However, I then don’t know any way how to convert this byte array into a float number.

11

I have never used it myself, but if I understand the docs correctly, you do like this:

instances:
  check:
    value: byte_array.as<f4>

Sorry for not testing, I only have access to my phone.

12

I’ve tested it.

byte_array.as<f4> outputs just byte_array, it doesn’t convert it into f4.

13

Doh. I’m out of ideas unfortunately.

14

Could this work?

- id: byte_array
    size: 4
    valid:
        expr: _  != [255,255,255,255]
  instances:
    as_f4:
      if: byte_array != [255,255,255,255]
      pos: 0
      type: f4
15

Won’t work.
No way to parse within an instance.

16

Let me give my understanding and please correct me if I’m wrong:

  1. The field/parameter/measurement (whatever it is) it gets different values which makes sense, and it makes sense to visualize them.
  2. it gets the value 0xffffffff when there is no value for any reason (for example subsystem not working, error in subsystem’s functionality etc), so in this case there is no valid/useful value to visualize and by default in the panels we can show “NaN” text.

Given the above the solution of omitting to pass the field in InfluxDB is the best solution.

Two notes, again correct me if I’m wrong:

  1. In order 0xffffffff is translated to a meaningful value, it should have a different type than f4, so here to be translated as NaN is normal and from the above, it is normal to omit it
  2. @deckbsd I guess the “NaN valiue”(whatever actual value in combination with the type gives the NaN result) is meant that I don’t have input to format a value (for whatever reason) so I send something that doesn’t make sense or ends up to NaN value. In such a case, and given that you will have values on the other fields, you should be able to understand that you didn’t get a value or you had a NaN value for the missing field. In worst case scenario that doesn’t make sense you can check the raw frame.