CTRE ambiguous functions

[LaviRZ]

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

[Joe_Ross]

@LaviRZ

So which is it? Is it the number of samples or the milliseconds of filtering?

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

[bovlb]

@LaviRZ

how will the following function return an ErrorCode?

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.

[ozrien]

@Joe_Ross

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

Bingo.

@LaviRZ

So which is it? Is it the number of samples or the milliseconds of filtering?

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

@LaviRZ

is how will the following function return an ErrorCode? Will I have to get it through getLastError()?

Yes, that’s the point of the function.

@bovlb

As most of the neighbouring methods return ErrorCode from the underlying function

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

@bovlb

and the documentation is just misleading.

Seems clear to me.

[bovlb]

@ozrien

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

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:

@LaviRZ

If so, how will I know if that error has originated from this operation?

[LaviRZ]

@ozrien

Seems clear to me.

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…

[ozrien]

@LaviRZ

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

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

@LaviRZ

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

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

Issues · CrossTheRoadElec/Phoenix-Releases

[bovlb]

@ozrien

@LaviRZ

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

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

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.

[Jacob_C]

@bovlb

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’.

[bovlb]

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

[connor.worley]

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.

[jtrv]

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

abseil / Status User Guide

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)