Channel switching proof of concept.

Isolated problem with high-speed sampling: clients jam up wireless
spectrum and trip over each other, so nothing gets through to host.

Solution: assign each client to a single static channel and make
host cycle between channels to receive messages from each client.

Tested with 4 clients each sending 32-byte packets every 5 ms.
Most likely works even faster, but have not tried (yet).
1000/5 = 200 packets/sec, each holding 16 2-byte samples.
200 * 16 / 4 = 800 samples/sec per client (with 4 clients).

This should translate to (at least) 400 samples/sec per client if
8 clients are in use. If bit-packing is added (since each sample
is actually 10 bits, but takes up 16 bits in packet), this would
yield approx 666 samples/sec per client.
Actual channel-switching proof of concept files. Oops.
Optimized channel switching, lots of future/untested code added.

Currently suffers from occasional dropouts, presumably due to RF
interference caused by wifi? Half a million wifi AP's here.

Need to incorporate/test commented-out code piece by piece.
Assigned two channels per client, instead of one.

Cuts throughput in half (to ~300 packets/sec combined), but
increases resilience against interference.
Fixed wireless dropouts; added setup timing/countdown sync.
Packet sending partially works.

Host is receiving duplicates from client, since client spams
the same packet until acknowledged.
Skew correction isn't working either, as a result.
Packet ack half-working, but this is really backwards.

Should probably switch host<->client roles.
SO CLOSE to working. Something is messed up with queues.

Most likely queue_packet_ready() on client side, otherwise something
to do with host/client onReceive.
Fixed queue_packet_ready error and added skew compensation.
Minor code cleanup and skew compensation changes.

TODO next: use client-side skew compensation based on host vs
clock time differences.
Pointless skew calculation
FINALLY fixed sync issue... and it wasn't sync-related.

Critical change: adding "&& count != data[0]" to onReceive in
client -- client was receiving multiple acks for single packet,
so it skipped ahead.
Working with two clients -- third won't receive countdown.
IT WORKS! Swapped GZLL client/host roles, fixed bugs.

Someone explain the point of line 149 in sync_client.ino, please.
It acts like a race condition where eventually lines 151-156
get stuck printing "P0L2R1", which  makes  precisely zero sense.
R should equal either P or L. Or something like that.
Working with 4 devices at 200hz for several minutes or more.
Code/commenting cleanup.
Fixed wireless communication (packetId)-related sync issues.

Devices would occasionally be offset due to host skipping a packet,
or something along those lines.
Simplified channel selection to use 1 channel all the time.
Code cleanup.
Better queue algorithms.