Skip to content
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

SD Recording has more hiccups. Due to BLE updateAdvertising? #55

Open
chipaudette opened this issue Aug 27, 2021 · 2 comments
Open

SD Recording has more hiccups. Due to BLE updateAdvertising? #55

chipaudette opened this issue Aug 27, 2021 · 2 comments

Comments

@chipaudette
Copy link
Member

The SD writing examples seem to have more hiccups than they used to. You can see the toggling lights hiccup every few seconds.

Is this due to the check on the Advertising of the BLE that we usually do every 5 seconds? I changed the Advertising check to 10 seconds and the hiccups were less frequent. It seems like that is the issue

Since that code is filled with delay() statements, it blocks until the BLE module can reply. Can we change the Teensy side of this serial communication to do less blocking?

(Also, perhaps the faster baudrate will help reduce this, too.)

@chipaudette
Copy link
Member Author

I just tried the SDWriter_Quad_wApp example with the higher speed baud rate. This example writes 4 channels at 44 kHz. The hiccups in the LEDs are much less apparent, but we're still getting some serviceSD warnings, generally dT millis in the warnings are 10-40, which I think are OK...but there are an awful lot of the warnings (1 every 10 seconds or so)

When I increase the sample rate to 96 kHz, I get more warnings (def faster than 1 every 10 seconds), but the dT millis are all about the same.

@chipaudette
Copy link
Member Author

For RevE, turning off any line that "checkAdvertising()" (or similar) avoids hiccups in the SD recording.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant