Expand native SDK info and examples

README.md

@@ -203,6 +203,9 @@ so it differs between units.
   initialisation had been attempted. Treat it as a rule: call `absone_measure`
   only when the device status is `OK` and `absone_is_initialized` reports
   `True` (see [Device status and device error](#device-status-and-device-error)).
+- **The library's own wait for an absorbance result is 110 s** by default, after
+  which the call returns an error. The device can extend that wait, so it is
+  not a guaranteed bound.
 
 **Stopping a blocked measurement is a last resort.** The only way out of a call
 that does not return is to end the process; the library's own internal waits
@@ -311,7 +314,8 @@ These numbers are **not** the library's return codes listed under
 they coincide (`0x8001` there is `MEASUREMENT_SLOT_NOT_EMPTY`).
 
 **What the device actually reported** is not available through the API. It
-appears only in the protocol log (`enable_logging`), as a text ID such as
+appears only in the protocol log (`byonoy_enable_logging` in C, `enable_logging` in
+Python — it goes to the process's standard output), as a text ID such as
 `com.byonoy-AbsOne-MIN_LIGHT_ERROR`. For the two absorbance devices, these mean:
 
 | Text ID | Meaning |
@@ -471,6 +475,11 @@ Recovery is a device reboot. The internal variant can do this from software
 (`reboot()`); **the public variant cannot** — unplug the device and plug it back
 in. Either way it re-enumerates within a few seconds and you open it again.
 
+If the device is stuck again straight after a power cycle, check whether a
+process was ended in the middle of a call in between — a watchdog killing a
+slow first call is enough to put it back. Power-cycle it again, and give the
+first calls time to complete.
+
 > **Report it if it recurs.** A one-off on an engineering or pre-production unit
 > is not remarkable. A device that needs rebooting repeatedly, or one on which a
 > particular mode fails consistently, is a fault worth reporting to Byonoy