TEP-Gateway

Notes

pc can always outclass the mote
thruput and reliability bottleneck is the mote
limited to 57600 (above which bits get corrupted) -- maybe to 115200.
microcontroller uart is the bottleneck, not the ftdi chip (on telos) -- timing issues, not buffer issues
- so maybe push on joe to fix this
- can we use usb directly from pc-side, perhaps in java? (ACTION ITEM), from mote-side (ACTION ITEM)
pc-side uart problems
- few different versions of java uart code that don't work the same, los connection to serial port after opened, etc.
- cory rewrote java libs.. called TOSCom - a drop in replacement for javax.comm (the other is called rxtx)
- sounds like there are a lot of c options we haven't considered (ACTION ITEM) - how far down does emstar go? (ACTION ITEM)
- platforms to consider: BT nodes, mica2, telos, imote2 (supports pluggable radios)

Framer - uses ideas from PPP. delimits frames with start and stop bytes. 2 bytes (int) type -- only 1 value. rest of packet same as radio packet. maybe crc. provision for acking pc-to-mote data and vice versa.
hostmote - type field, priority field, length field (and backup length field -- poor man's crc over the header), sequence number and crc. ack pc-to-mote data
stop bytes overwrite? write to max amount in case of "losing sync".
we agree: there must be a start byte, type field (e.g., data, config, debug -- priority field also in that order), priority field (independent of type), (ACTION ITEM - how is type recorded for debug) - both directions
how do we handle debug? (ACTION ITEM) (we have tunneled messages vs untunneled) - who should be responsible for stripping debug info out from within a tos message.
we agree: baud rate should be negotiated when possible (an error should be when not and incompatible), mote index (indirection: /dev/ttySO to /dev/mote/1) but not sure how to implement on other that fusd

PC      Transciever
--data--> 
<--ackA-
          --data---->
          <--LLack--
<--ackB-

PC      Mote
--data--> 
<--ackA-

acks: over serial (bi-directional)
(ACTION: read hostmote, tos/system/FramerM.nc tools/java/net/tinyos/packet/packetizer.java and compare, maybe ideas about robustness, acks, resets, watchdogs, etc)

need to exchange platform info
mote -> serial -> tcp -> java (java tool must know platform of mote)
meta info should be generated on pc-side of serial with link structure info provided by mote
(ACTION - look at joes' link layer tep)

General

mote platform requirements (msg format, word alignment, etc)
throughput (relative to the gateway's radio)
latency
usb vs serial (mica2 vs telos)
robustness (assertions, watchdogs, etc)
introspection (status from gateway node)
configuration (of gateway node)
time sync (pc-to-transceiver and transceiver-to-mote-network)
pc-side language support
pc-side platform support
abstraction of underlying radio and uart stacks (is this by platform or by stack? i.e. zigbee, bmac, smac, or micaz, mica2, telos? maybe we need protocol stack directories.)

Serial Protocol

AM layer

Serial Protocol

TinyOS AM translation layer

PC-Side Services

WebMote - The idea is that a local webserver:
- enumerates the locally attached motes
- allows you to give each one a meaningful name instead of only a MOTECOM
- lets you access their packets through a URL
- uses a readable ASCII format for transferring those packets, instead of a binary serial forwarder protocol. The protocol is just a hex representation of the bytes, one packet per line (like Listen). experiment to see if mote packets could be easily bridged to HTTP.
It's in the "broken" tinyos module, so you'll have to "cvs checkout broken", then its in the "experimental/get/tools/java" directory. Check that out, "javac .java", and run it. There's a README with some tips on using the mote listing features. If you run the "moteupdate.pl" script in the background, Telos motes will be autodetected and added to the list.