From CSL Wiki

Notes

UART

• 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 or Hostmote

• 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)

Data Level

• 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)

Proposal

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

• Framed
• CRC checks
• Retransmissions (both directions)
• buffered
• prioritized
• static and dynamic configuration: data rate, platform, rtx, crc, etc.
• throughput at least radio rate
• interfaces?

AM layer

• TOS meta-description (XML?)
• issues:
  • word alignment
  • TOS format
• what role does a mig-like tool play

Existing Code

Serial Protocol

• UART.nc
• hostmote

TinyOS AM translation layer

• TOSBase
• Network Types
• MIG
• Transceiver
• Motenic
• Packetizer
• Messenger
• Serial Forwarder

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.