see also: [[[[Project Lyta Configuration]] for config notes
===== MacMini =====
==== power setup ====
echo server_mode=1 > /proc/pmu/options)
===== Leaky Muscle Driver Board Prototype v1.1 notes =====
the boards IPs are 192.168.1.98 (MAC :99:37) and 192.168.2.99 (MAC :99:52)
(NOTE: i moved the :99:52 board to the 192.168.2 subnet so that i could connect directly to it while still being on the wireless network).
access the terminal mode setup interface by telnet to port 99.
access the driver board protocol by telnet to port 23.
example tcp2osc commandline: ./tcp2osc -h 192.168.1.98 -p 23 -l 5555 -o osc.udp://127.0.0.1:5556/ -v -b
then send commands with (for example): ./text2osc -h 127.0.0.1 -p 5555
/send [Q]
sent:/send [Q]
/send [I0]
sent:/send [I0]
/send [I0,7]
sent:/send [I0,7]
/send [I0,7=500]
sent:/send [I0,7=500]
/send [I0,7=0]
sent:/send [I0,7=0]
==== protocol ====
[?] (and similarly [Ix]) seems to actually send "[LF]" but the spec says it would send the more useful "[CR][LF]". basically having the line feed at the end makes it easier to parse the input as line-buffered data.
i've added an option (-b) to the tcp2osc program to better deal with this data format.
is it possible to set all output values in one command also? we will always be setting all of the output values at the same time.
==== number of inputs/outputs ====
if each board really just controls 8 inputs and 8 outputs, this means we will need 20 boards per cabinet. with the previous spec of one board controlling 32 muscles, we would need 5 boards. this change has potentially quadrupled the networking costs. (or trippled, if you consider the move from an 8 port switch, to a 24 port switch).
the spec suggests the possibility for multiple control boards to share an rs232/ethernet link. do you still have to address each control board seperately? how would this deal with simultaneous transmissions coming from each control board? if we have to wait for complete polling cycles for each set of 8 muscles to avoid collisions in the output, this will cause a lot of latency, as the time from poll to response is perceptibly slow (perhaps 200ms).
it would be great if by chaining the boards, we could just address more muscles with the one command, eg "[I0,32]" or "[I0,40]". perhaps this is indeed the way it would work. please describe in more detail how this chaining would behave, because it has a critical impact on the feasibility of the networking.
since the [?] command is less accurate than the [I] command, and it is possible to specify ranges to read all the values in one command with [I], we will probably never use [?].
==== data rate ====
as mentioned above, communication seems to be quite slow. when setting the rate of automatic updates, there seems to be an upper limit to how fast to be done before values are clumped together in one tcp packet (packets arrive every 250ms or so).
we are using [I] instead of [?]. would [?] be considerably faster because of the smaller number of characters? there seems to be no increase. also there is no difference between I0 and I0,7. actually, with a constantly changing input, the readings in each 'clump' of data are different, implying that they are actually being taken at different times, it is just that the rs232 stream is getting collected into large tcp packets.
here [[bursty.cap]] is a tcpdump file showing this. (it shows many telnet packets which contain several \r\r lumps.
===== Leaky Muscle Driver Board document queries [old as of 22 May 2005] =====
==== is 10-baseT sufficient? [yes] ====
i did some tests sending a line of ~36chars to the cerf (it has a 10baseT interface) and having it echo it back (to simulate the traffic of sending an ALL_OUT and recieving the response of an ALL_IN). the upper limit of what the interface can handle is reached somewhere around 1000Hz. since the sensors update at 20hz (maximum), this should be sufficient.
results were similar for both UDP and TCP (because it was a crossover connection with no other traffic).
==== which firmware is being used? ====
(which documentation should we be looking at for setup/configuration information?) eg:
* can it send/recieve UDP? (TCP/RS232 setup option T?) (TCP is wasted overhead for realtime control, as dropped packets will become redundant before they are retransmitted)
* where do responses go when a request is made over UDP? how is this configured? (TCP/RS232 setup options S and U?).
a freeware windows program, Hercules is mentioned in the charon docs and the driver board spec. we don't have any windows machines, so we need a way to configure everything without the use of this software. also, any configuration tasks that must be automated (if values are forgotten at reboot etc?) will need to be performed by our own code. so, we need to know the configuration protocol.
it seems that the only documented configuration protocol is over the direct rs232 connection. there is the ability to configure it over udp, but the protocol is not documented (udp setup is always demonstrated using the hercules software). there is also the ability to do configuration via tcp (telnet port 99), but it is not clear if this is enabled by default.
==== polling? ====
polling every 10-20Hz seems like a lot of unnecessary overhead, when we know we will always want the data. perhaps something like a heartbeat signal which tells the device to broadcast all sensor data for the next n seconds?
==== twisted charon1 ====
on the board wiring diagram, the right row of pins from the charon1 are upside down. is this just to make the diagram more readable?
==== addressing ====
we don't expect to have the devices on a shared bus (instead they will be connected via a switch) making the address prefix unnecessary. additionally, in normal operation, we will be polling all of the boards for their input values simultanously, which would cause chaos on a shared bus, or undesirable latency if we waited for a complete poll+response/timeout cycle with each board.
fortunately the address is optional and we can just ignore it.
==== diagnostic information ====
in what cases will the "Diag LED" be red? is it possible to access this state information over the ethernet connection, so we can consolidate diagnostic information for all of the boards on the controlling computer.
--
* some notes of [[TcpFlow]]
* http://web51.hw-server.com/
* [[bursty.cap]] : tcpdump logfile showing bursty tcp data
----
--[[pix]] - 01 Apr 2005