1. technology and computing
2. consumer electronics
3. telephones
4. mobile phones

6.033 2015 Design Project FAQ Last update: 4/22/2015, 2:15pm Most of these questions have been asked on Piazza; we’re aggregating them here for your convenience. Be sure to read the ​
design project description​
and ​
errata​
as well. Sensor IDs: ● Can the major/minor IDs be changed through directives from the FCS, or must they be reprogrammed via someone from facilities manually attending to the device? ○ They’re controlled by the software on the sensor. Theoretically, you could change the major and minor IDs for each beacon. ● Do all sensors have unique IDs? ○ Each sensor node has a globally unique ID analogous to a MAC address. ● What is the maximum number of sensors we can have per region? ○ The limit of 64 is a mobile app limitation. There is no specified limit on the number of sensors per unit area, but it is unlikely to substantially exceed the density of nodes as measured campus­wide. ● Can the minor ID change every time the sensor beacons? ○ Yes Sensor File System: ● When a sensor records anomalous data, how does it mark it as anomalous? ○ That's up to you to determine ­ both the storage and communication of such information. ● Can we assume the sensor nodes have a file system? ○ It seems reasonable to assume a very simple file system; it would be desirable to specify your assumptions on that file system. Make a reasonable choice: a file system capable of supporting a certain number of files is fine, but assuming the same file system as modern Linux is unreasonable. ● Do the sensors’ embedded code and settings live on the flash storage? ○ Don't worry about the code and other related configuration to boot and run the program on the sensor node. You may assume that you can use the 8 MByte flash storage for your purposes. ● Does RAM persist while the sensor is asleep? ○ Yes, it persists in very low power mode. Sensor Location: ● Can we assume that all sensors are located in wifi­connected regions? ○ No. ● Do we have to consider frats/sororities and buildings very far from central campus for sensors? ○ Yes ● Can we make sensors unmovable as part of the design? ○ No ● Will sensors be located outdoors? ○ No, only indoors. Sensor Communication: ● Can sensors communicate with each other? ○ No, they communicate only with mobile devices. ● Could we incorporate logic into the sensor node so that it only broadcasts advertisements if certain conditions are true? ○ Yes, as long as the conditions are simple enough to implement on the sensor node. ● When a sensor connects to a mobile device, can it maintain the connection? ○ You may assume that both sides can maintain a connection, until either side decides to tear it down. Note, however, that maintaining a connection consumes energy. ● The BLE link layer protocol does not guarantee perfect reliability. Does that mean that communication can be corrupted? ○ Technically yes, but you don’t need to worry about it. You can assume that the BLE link layer has protocols in place to detect corrupted packets and retransmit them. Packets may still be lost, but your design does not need to deal with corrupted BLE packets. ● The sensor can make 50 connections per second, but each connection takes 2 seconds to establish. How is this possible? ○ The initial connection takes 2 seconds, after which you can do 50 per second. ● Can sensors send and receive data at the same time? ○ Yes ● Can the sensor tell if the phone disconnects while the sensor is sending data? ○ Yes ● What is the range of BLE? ○ Assume about 30 meters ● How many mobile devices can a sensor connect to at the same time? ○ Each sensor node can have at most one active connection to a mobile device. Each mobile device can have many active connections to different sensor nodes. ● Do we have to worry about how to partition data into 20 byte packets? ○ You should explain how you're transmitting/partitioning your data in these packets. Sensor Readings/Timings: ● How many bits are in a sensor value reading? ○ Each sensor’s data is recorded using a 32­​
bit timestamp (accurate to 1 second) and a 16​
­bit value. ● Is the timestamp required to be 32 bits or do we have a choice of reducing accuracy to minutes and shortening the number of bits required? ○ We would prefer it to be 32 bits, but if you find that there are some significant advantages to lowering its precision, you may do so, with justification. ● Can we assume that the sensor uses a UNIX timestamp? ○ Yes ● What's an approximate range for the frequency of sensor readings? ○ Typically 1 Hz or less. ● Does each sensor only measure one type of data (e.g. temperature or humidity)? ○ Yes ● How frequently will a sensor get anomalous data? ○ You may assume a low average, e.g., once a day, but there may be bursts such as in the case of a fire. State your assumptions. ● How is a sensor type determined? ○ Assume a sensor knows its type. ● Can sensors infer their battery level? ○ Yes, accurate to 1%. ● When a mobile device is in the vicinity of the sensor, are we supposed to have the app display the reading as of that moment from the sensor, or should the app display the sensor reading that was the most recently recorded in the past that is found in the FCS? ○ The former. The app should display the value most recently recorded by the sensor (which is probably not yet available at the FCS). Mobile App: ● Is there a limit to how long the packets (how many bits) can be from sending from the mobile to FCS (and vice versa?) ○ You can use HTTP or any other standard protocol for this. ● How much storage is on the mobile device? ○ Most mobile devices have a lot of storage. It is unreasonable to be able to specify how much this is exactly because it varies widely. FCS Server ● What is the storage capacity of FCS? ○ We haven't given you guidance about storage capacity of FCS, but assume it is a modern server with several terabytes of hard disk storage. Databases (if you choose to use them): ● Should we be designing the data structures for our databases, or can we assume the use of databases that support SQL­like queries? ○ You may assume SQL support. For groups unfamiliar with SQL, you may simply state what queries the Database supports. We are more interested in your data schema; the internal implementation is not required to be specified. ● What kind of constraints to databases have? ○ Here’s a brief description of what you can assume about databases for this project (if you’ve never used a database before, think of them as spreadsheets): ■ You can insert records of the form (key, field​
, field​
, ... field​
) 1​
2​
n​
■ You should be able to store as many records as you have storage capacity. So you'll want to think about how many bytes your records store, and whether it is reasonable to keep all of them or not. We haven't given you guidance about storage capacity of FCS, but assume it is a modern server with several terabytes of hard disk storage. ■ You can perform constant time lookup for a given key. Typically a single lookup takes a few milliseconds. ■ You can also create "index" structures that allow you to perform quick lookups on one of the fields. As a simple model you might assume that the latency is a few milliseconds per record retrieved via one of these index lookups. Clock Drift ● If the clock of a sensor is modified, should we change the timestamp of old records? ○ This is up to you. You can try to come up with some sensible semantics, or you can clearly describe what in your design will go wrong with a clock change. ● How unreliable is the sensor’s clock? ○ You may assume that the clock drift is no more than a few seconds/day. ● Can we trust the phone’s clock? ○ Yes