CTRE ambiguous functions

The following function is taking a parameter called filterWindowSamples:

but in Phoenix Tuner the field is described as

How much filtering (milliseconds) to apply to vbat measurement. This impacts voltage compensation mode and vbat reporting.

So which is it? Is it the number of samples or the milliseconds of filtering? Additionally, in the tuner the value is selected from the following drop-down:

When using the API, there is no mention of those specific values, but when using the function, the actual value is truncated to the nearest value that’s on the dropdown. For example, if I give the function the value 200 it will take it down to 128. This behavior is not mentioned in either the javadoc or the online CTRE docs. Similar behavior is mentioned in another function:

Another somewhat related question, is how will the following function return an ErrorCode? Will I have to get it through getLastError()? If so, how will I know if that error has originated from this operation?

Thanks in advance

1 Like

I suspect they are equivalent, since most things are sampled at 1khz (every 1 ms).

I believe this code ends up calling this code:

int BaseMotorController::GetStatusFramePeriod(StatusFrame frame, 
    int timeoutMs) {
      int periodMs = 0;
      c_MotController_GetStatusFramePeriod(m_handle, frame, &periodMs, timeoutMs);
     return periodMs;

As most of the neighbouring methods return ErrorCode from the underlying function, I suspect the errors are being discarded here, and the documentation is just misleading.


It’s both. A window size of 32 means 32 milliseconds.

Yes, that’s the point of the function.

All setters return an error code. Getters cannot since they return the retrieved value. That’s why GetLastError() exists.

Seems clear to me.

Good to know, thanks. You should put that in the documentation for the getters and/or in the class-level documentation. You could also provide the answer to the OP’s question:

So getLastError() will return ErrorCode.OK if the last function executed successfully?

And what about the documentation for configVoltageMeasurementFilter()? It should at least include an explanation of the possible values…

1 Like

Exactly - call it after your getter. It literally returns the error of the last thing you called.

Sounds like this would be a good issue to write on the issue tracker:

This is inconsistent with the online documentation which says:

Gets the last error generated by this object.

Which is it? The error status of the last call, or the last error generated? They can’t both be true.

They can - the error status of the last call is the last error generated. Keep in mind that ErrorCode.OK is one of the possible error codes.

In this context ‘error’ doesn’t mean ‘bad thing’, it means ‘error status’.

1 Like

Ah. So a lack of error is a form of error. That is not at all clear from the documentation.

C++23’s std::expected (ref) should help with this sort of thing, if we ever get compiler support for it. Not sure about Java.

StatusOr<T> is generally a trivial implementation in any language with generics.

Hopefully one one day we can stop passing objects and arrays by reference in Java* as a getter.

(*Yes yes I know pointer by value in Java blah blah)