-
-
Notifications
You must be signed in to change notification settings - Fork 303
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
Clean up packet bundles and feature flags #294
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about the changes in featureflags. I can't review that. That template/class is something that i understand too less.
The following should be reviewed, i could not read the code from the other side so i dont know wht it expects:
sendPacketType
sendLong (uint64_t or int64_t)
The new packet bundling logic is not working as intended, sends empty bundles flooding the network when there's no data written between I mentioned previously that we can't write the bundle header to the UDP library buffer from SlimeVR-Tracker-ESP/src/network/connection.cpp Lines 117 to 128 in dd21566
We could alternatively fix it by changing checks in the Maybe also worth moving the list of default firmware flags back into SlimeVR-Tracker-ESP/src/network/connection.h Lines 173 to 175 in dd21566
|
c877176
to
69dcc7d
Compare
I've moved the list of active features next to where they are declared. Next time please use review comments ^^ |
8fba600
to
be6ba09
Compare
I fixed this now, it how has a buffer of the size of |
@0forks @unlogisch04 @Eirenliel please review |
be6ba09
to
78d4a1d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me it seems to work. But i did not test it with trackers.
For ICM20948 there was a fix needed as they had a internal delay to not send too much updates.
For me the featureflags is something that could be improved more in the meaning more simple as 1 class / function that is seeded with different enums.
/* | ||
The current incoming packet that is being handled | ||
TODO: remove this from the class and make it a local variable | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This todo is open?
Forgot or does it not matter for this PR?
if (getBundleSize() + size > MAX_BUNDLE_SIZE) { | ||
m_Logger.error("Bundled packet too large"); | ||
|
||
// TODO: Drop the currently forming packet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clean up and reset of the buffer?
I think we should check for length before we even add more bytes, so we could send a packetbundle, and open a new one for the one that did not fit.
|
||
// I hate C++11 - they fixed this in C++14, but our compilers are old as the iceage | ||
struct EnumClassHash { | ||
template <typename T> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not like the template here. As we do not save any programming bytes with it. Also the code understanding is more difficult in my meaning. I think that's a possible improvement for the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine, I am curious about the comments on the last review though and would appreciate an update
/* `53` is the maximum size of any packet that could be bundled, which is the | ||
* inspection packet. The additional `2` bytes are from the field which describes | ||
* how long the next bundled packet is. If you're having bundle size issues, then | ||
* you forgot to increase MAX_IMU_COUNT in `defines.h`. */ | ||
constexpr static size_t MAX_BUNDLE_SIZE = MAX_IMU_COUNT * (53 + 2); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please change to MAX_IMU_COUNT * 64
(really 63 but it'll be aligned anyway), it'll drop packets in case of BNO+mag+tap with only 55 bytes. The comment also should reflect that it's the size of the whole bundle, not individual packets inside.
I did check the performance on that PR. It seems todo the relevant function (has) is about 8 times slower: It only gets called currently at each packet once. so about 100-120times a sec. FeatureFlag1 = the new function
|
No description provided.