What are the most significant risks that could jeopardize the success of theproject? How are these risks being managed? What contingency plans are ready?
The risks that are yet to be fully quantified are the issue of range and the receiving capabilities of the central ESP.
In regards to the issue of range, we already have some data points to compare against. The first is that we were able to get about 30 meters of range indoors and in a non-line of sight situation though two thick brick walls. From this, we judge that it is likely that a 50 meter range is achievable in a wilderness environment where there is minimal interference from neighboring access points and where there isn’t a need for the signal to penetrate multiple brick walls. Should it not be possible to reach the 50 meter range figure we can always install antennas that are more directional. The current external antennas that we have are 3dBi omni directional antennas which can be easily replaced with higher gain antennas if needed. To verify we can just set up a camera and receiving node in Schenley Park and keep track of the distance until the stream drops. The test can be run under a variety of different conditions, for example in an open area with direct line of sight and then in a wooded area where the line of sight is blocked by a couple of trees. Terrain would have to be accounted for as well since in the wilderness, it can be guaranteed that every node is at the same elevation.
The current knowledge of the receiving capabilities of the central ESP is that it is able to handle one stream of camera data right now. We have yet to do testing beyond that. While we do have 6 cameras, most of the time the system will have at most one active stream. This is because the cameras will only send data when there is movement and not send data when there isn’t. Thus, it is unlikely that all 6 cameras will be active and sending data to the central node at once. In case that we do run into processing limitations on the central ESP, we can always drop the quality of the frames which will decrease the transmission size which in turn will lower the processing demand. Alternatively, we can also just include a second ESP to split the load. This is the less preferred option because it adds extra complexity.
Were any changes made to the existing design of the system (requirements,
block diagram, system spec, etc)? Why was this change necessary, what costs
does the change incur, and how will these costs be mitigated going forward?
The main change is on the front of the FPGA. Due to logic element sizing and time constraints, the JPEG decoder and the video driver will be split into two different FPGAs. This does increase the price of the central node but it is within our budget of $150.
Provide an updated schedule if changes have occurred
No changes
This is also the place to put some photos of your progress or to brag about a component you got working.
Validation Plan
One of the validation plans will be to ensure that the communication between the central ESP and the FPGAs is steady. The metrics for this will be twofold, a counter will be implemented on the FPGA so that we know what is the data rate that the ESP is streaming data to the FPGA. In addition to that, performance counters on the JPEG decoder will be added so that we know how many invalid JPEG frames are received.
In terms of actual metrics, we expect to see 60 JPEG frames transmitted every second by the ESP. Then, we expect to see that no more than 10% of the transmitted JPEG frames are invalid.
We will also perform testing via sending varying forms of input, images with different gradients, colors, patterns, to ensure robustness. We will also work on ensuring that multiple camera streams are still able to transmit simultaneously, to ensure that the system works under high pressure (all 6 cameras sensing and streaming). The receiver node needs to be able to handle all the 6 incoming streams, and then transmit them to the FPGA for further processing.