diff --git a/2023-12_usb-real-data-rates.md b/2023-12_usb-real-data-rates.md
index 1e93f4d0ece123e26b6f9242248f24d3423cfed9..0d0025fc72a9692ca29f56b06c1e56d7c2e9ac3f 100644
--- a/2023-12_usb-real-data-rates.md
+++ b/2023-12_usb-real-data-rates.md
@@ -10,27 +10,16 @@ To start, I spun up ...
-I would want to improve these by relating instantaneous real-data-rates with packet length and time deltas... i.e. for a 128 byte packet, supposing a 1ms interval, we have only `128k Byte / sec` whereas the spec looks for `296k Byte / sec` (for all the data).
+
-So, not done at all:
-
-- usb packet length is actually 64 bytes, so zero-delimited would mean we should see a step size around ~ 60 bytes, not 64 as tested ?
-- plot data-rates as well as per-packet delays
-- get COBS up to 512, or whatever the underlying USB packet size is ? how does that plot ?
-- what about multiple devices ?
-- what about flow control ?
-- how does it compare on a linux machine ? (the same machine, with linux)
- - how about a raspberry pi ?
-
-I think the big point will be that we will want to measure these links in-situ, to do intelligent (feedback!) systems design.
+So, we do win some speed when we increase packet sizes, but we have a clear trend around ~ 0.6 -> 0.9 Mbits/s ... which is not awesome; our spec for the data printer requires about 4 Mbits/s of real data rate.
## 2023 12 20
So - yeah, I want to keep working through this today, and I'm going to bundle code in here as well.
-Firstly, it seems like USB 2.0 Full Speed has core frame sizes of 512 bytes, which we should endeavour to use - finishing our little diagrams above. That means this NanoCOBS implementation as well?
+I wanted to see about improving with nanocobs and maybe packing more data (up to 512 encoded bytes rather than 255), but I don't think that's the bottleneck - instead I suspect that we can try linux instead of windows... and then anyways move on to i.e. ethernet tests or multiple devices / async patterns etc etc etc, so, let's see about linux, running the same code.
-OK so I'm going to see if I can't swap in nanocobs, then test again at 32 byte packets;
diff --git a/code/serial_sink/sink.py b/code/serial_sink/sink.py
index bc5adb075c573c8e5d6d73fdda5f0714c3c82705..858e5d583de1cc351099a0fd4ad03e4377389a72 100644
--- a/code/serial_sink/sink.py
+++ b/code/serial_sink/sink.py
@@ -7,7 +7,7 @@ import matplotlib.pyplot as plt
ser = CobsUsbSerial("COM23")
stamp_count = 10000
-pck_len = 128
+pck_len = 250
stamps = np.zeros(stamp_count)
diff --git a/code/serial_source/COBSUSBSerial.cpp b/code/serial_source/COBSUSBSerial.cpp
index 03939cc7b407f9f9d5e891a19bf39b513886e3ff..74fbf2e71bf0f03860aa483e842f17c339772afe 100644
--- a/code/serial_source/COBSUSBSerial.cpp
+++ b/code/serial_source/COBSUSBSerial.cpp
@@ -64,8 +64,11 @@ boolean COBSUSBSerial::clearToRead(void){
return (rxBufferLen > 0);
}
-void COBSUSBSerial::send(uint8_t* packet, size_t len){
- // ship it! blind!
+void COBSUSBSerial::send(uint8_t* packet, size_t len){
+ // we have a max: we need to stuff into 255,
+ // and we have a trailing zero and the first key
+ if(len > 253) len = 253;
+ // ship that,
size_t encodedLen = cobsEncode(packet, len, txBuffer);
// stuff 0 byte,
txBuffer[encodedLen] = 0;
diff --git a/code/serial_source/serial_source.ino b/code/serial_source/serial_source.ino
index 0096632b34d13134fbd650b6c101bd97404c4356..610940615df3a2decc89f341a90fe774b12ec599 100644
--- a/code/serial_source/serial_source.ino
+++ b/code/serial_source/serial_source.ino
@@ -40,7 +40,7 @@ void loop() {
// tx a stamp AFAP
if(cobs.clearToSend()){
chunk.u = micros();
- cobs.send(chunk.bytes, 128);
+ cobs.send(chunk.bytes, 250);
digitalWrite(PIN_LED_G, !digitalRead(PIN_LED_G));
}
// blink to see hangups
diff --git a/images/2023-12-12_ingest-histogram-single-source-pck-250.png b/images/2023-12-12_ingest-histogram-single-source-pck-250.png
new file mode 100644
index 0000000000000000000000000000000000000000..9fe96eec9653307a04a5e901563b2e752b337ed8
Binary files /dev/null and b/images/2023-12-12_ingest-histogram-single-source-pck-250.png differ