You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
The text was updated successfully, but these errors were encountered:
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.
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.)
The text was updated successfully, but these errors were encountered: