updated the readme, removing the 'slotted' stuff.

README.md

@@ -1,7 +1,7 @@
 # solum-esl-alternative-proto
 
 ## ⚠️⚠️⚠️THIS IS NOT PRODUCTION READY!⚠️⚠️⚠️
-This is not a final, polished codebase. Not by a long shot. It's a complicated system, and it is not unlikely to be a dead end. There are drawbacks to a slotted protocol, it's hard to debug, and it might not work all that well in unfavourable RF conditions. You'll need some knowledge on the use of these tags. A very good place to start is here: https://github.com/atc1441/ZBS_Flasher. You'll need to fix issues yourself, troubleshoot stuff. Once again: this is not for everyone.
+This is not a final, polished codebase. Not by a long shot. You'll need some knowledge on the use of these tags. A very good place to start is here: https://github.com/atc1441/ZBS_Flasher. You'll need to fix issues yourself, troubleshoot stuff. Once again: this is not for everyone.
 
 This is an alternative protocol for the ZBS243-based Electronic Shelf Labels - ESL / price tags by Solum / Samsung.
 
@@ -12,10 +12,11 @@ It is currently compatible with the following tags:
 * 1.54"
 
 ### Aims
-- Low power (currently around 8µA with 30 second latency)
-- Low latency (tags can check for new data every 30 seconds)
+- Low power (currently around 9µA with a minimum of 40 second latency)
+- Even lower power when there's no AP around
+- Low latency (tags can check for new data every 40 seconds)
 - High transfer speeds - It can do about 5kbyte/s in favorable RF conditions. This allows for lower power
-- RF-spectrum friendly - We don't need to acknowledge EVERY packet, and we don't need to transfer data we already have
+- RF-friendly - We don't need to acknowledge EVERY packet, and we don't need to transfer data we already have
 
 The entire setup requires a few tags, and an ESP32. A (preferably, but not necessarily) broken tag is used as an 802.15.4 radio for the ESP32. You'll need a ZBS_Flasher in order to flash both the AP with its firmware, and the tags. Using the 'mac' option on ZBS_Flasher makes sure a tag flashed with a custom firmware has a valid mac address; it used the stock mac address assigned to the tag if it hasn't been flashed before. If you want to set it yourself, you can edit the mac address in the infopage. The AP expects a tag with a mac that starts with 00:00, followed by 6 bytes. The MAC-address also needs to be set on the AP-tag.
 
@@ -23,15 +24,10 @@ Once flashed, you can hook the AP tag up to the ESP32 by connecting the tags ser
 
 You can access the ESP32 with any web browser after connecting it to your WiFi Network. The file browser is located at <ip>/edit. For sending data to tags, you'll need to upload the information in 'data' to the ESP32's filesystem. After uploading, you can access the status screen at <ip>/index.html. If everything is working, you should be able to see tags synchronising to the network. After uploading a suitable .bmp file to the filesystem, this file can be sent to the tag by entering it's 6-byte mac address and filename.
 
-## The synchronized/slotted protocol explained, kinda. This is simplified, the reality is even more convoluted
-
-- Every 30 seconds, the AP sends a 250ms long 'burst' of packets, each marked with a sequential 802.15.4 sequence number. The tag, when synchronized to the network, listens for a short while every 30 seconds, to receive exactly one packet. Based on the sequence number received by the tag, the tag can calculate clock drift and window-offset to the 30 seconds interval, in order to remain synchronized.
-- At bootup, the tag will try to find an access point, and get timing information. It will start a calibration cycle in order to characterize the difference between the AP's clock and the internal (RC) oscillator. This allows for a fairly precise reception of the sync burst. After initial calibration, the tag will slowly adjust its calibration value to compensate for drift in the RC oscillator frequency. 
-- When synced, the tag only listens for a -very- short period of time, which allows for both low power use and low latency.
-- The ESP32 can send a 'pendingData' message to the AP, indicating it wants a specific tag to check-in to the AP.
-- AP adds this pendingData struc to a queue, and adds these tags to the sync-burst
-- The sync-burst packets contain up to (currently) 2 mac addresses of tags that the AP wants to talk to, and an 'offset'. Tag receives a MAC address, see if it matches its own, and when it does, it sleeps for [offset] ms. This allows for minimal power consumption and maximum throughput, as the AP determines which tags are allowed to talk.
-- When addressed by AP in the sync-burst, the tag wakes up after the offset period, and requests information from the AP. The AP responds with some metadata, such as size, MD5 checksum, and data type.
+## The protocol explained
+- The tag checks in with the AP every 40+ seconds. Actual check-in interval is highly dependent on RF conditions
+- The AP holds a list with tag MAC's that have pending transfers.
+- If a tag checks in, the AP replies with either no data, or information about a pending transfer
 - The tag checks if this information is already downloaded to EEPROM, or is already displayed. If this is the case, the transfer is immediately cancelled by issuing a 'transfer complete' packet to the AP.
 - The tag then proceeds to request data in 'blocks' of 4096 bytes. The AP responds with an ACK on the request, and specifies how long it will spend to gather the data. The tag sleeps until the AP will send the data
 - The AP requests its block-buffer to be filled by the ESP32, specifying MD5 and blockID
@@ -56,7 +52,6 @@ You can access the ESP32 with any web browser after connecting it to your WiFi N
 - Do more with status info as sent by the tags
 
 ## Known issues:
-- The RC oscillator has some jitter, especially on longer sleep times. I find it difficult to have the tag sleep for much longer than 30s without losing synchronization to the network
 - For some reason, the screen needs to be reset and put to sleep -EVERY TIME- the tag wakes up. This is a relatively slow process; it would really help if we could find out what causes this. Some glitch on the reset line of the EPD would be my guess...
 - The ZBS CPU should be able to sleep during the EPD-draw command; however, this currently (for some reason) increases the sleep-current-draw
 - Some tags work better as AP's than others. Your range may suck. The boards on these tags are tiny and fragile. For instance, a dab of hot-glue on a board is enough to warp it pretty severely, and will damage the components that are soldered on there. Reportedly, segmented-display solum tags work well.