From ea22e59993ffb39f92061db19d45b478f2919c60 Mon Sep 17 00:00:00 2001
From: echicken <echicken@bbs.electronicchicken.com>
Date: Tue, 30 Apr 2024 05:20:58 +0000
Subject: [PATCH] We'll a what now?
---
README.md | 2 +-
src/lib/device.ts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/README.md b/README.md
index 524b153..f884833 100644
--- a/README.md
+++ b/README.md
@@ -309,7 +309,7 @@ Create a Device
| `debug` | `boolean` | `false` | Enable debug logging (all sent and received frames, etc. - noisy) |
| `configId?` | `number` | `undefined` | is a local identifier that appears in log messages but does not go out over the air |
| `heartbeatInterval` | `number` | `30` | is the time (in seconds) between heartbeat (keepalive) messages to the device |
-| `writeDelay` | `number` | `2000` | is the time (in milliseconds) between writes of frames to the device *Notes on writeDelay:* I don't like `writeDelay`, but I found that if I sent multiple frames in quick succession some might be dropped silently despite there being room in the device's queue, and even when they didn't get dropped they were sometimes sent over the air out of sequence. It's not clear whether every frame sent to the device elicits a response to the client, so we can't necessarily wait for "ack" (To do: verify this), though this would be better than some dumb/arbitrary sleep. For now we'll a default 2000 ms between frames when writing. `2000` was arrived at by trial-and-error. This might be a problem with my device (Heltec v3), so you can try reducing this value and see what happens with your hardware. |
+| `writeDelay` | `number` | `2000` | is the time (in milliseconds) between writes of frames to the device *Notes on writeDelay:* I don't like `writeDelay`, but I found that if I sent multiple frames in quick succession some might be dropped silently despite there being room in the device's queue, and even when they didn't get dropped they were sometimes sent over the air out of sequence. It's not clear whether every frame sent to the device elicits a response to the client, so we can't necessarily wait for "ack" (To do: verify this), though this would be better than some dumb/arbitrary sleep. For now we'll wait a default 2000 ms between frames when writing. `2000` was arrived at by trial-and-error. This might be a problem with my device (Heltec v3), so you can try reducing this value and see what happens with your hardware. |
###### Returns
diff --git a/src/lib/device.ts b/src/lib/device.ts
index 71962fb..3851fb0 100644
--- a/src/lib/device.ts
+++ b/src/lib/device.ts
@@ -104,7 +104,7 @@ export default abstract class Device extends js.global.EventEmitter {
* so we can't necessarily wait for "ack" (To do: verify this), though this would be better
* than some dumb/arbitrary sleep.
*
- * For now we'll a default 2000 ms between frames when writing.
+ * For now we'll wait a default 2000 ms between frames when writing.
* `2000` was arrived at by trial-and-error. This might be a problem with my device (Heltec v3),
* so you can try reducing this value and see what happens with your hardware.
*/
--
GitLab