Upcoming Challenges

This semester will have a number of key tasks and challenges that I will need to overcome in order to complete the Thesis project to my satisfaction.

1 ~.Communication.

Due to the unforeseen issues withe RBL BLE modules described in a prior post I need to decide whether to continue pursuing this route or go with a different wireless solution. This is a primary issue, and needs to be solved within the next few days. I am beginning to lean to a solution I have already worked with in a prior proejct as it would both enable much simpler networking and a broader range of devices that I can use as the final receiver. With that said, the financial cost of the RBL modules is not insignificant and their advertised benefits would be a great asset to this project (provided I can get them to work within the next week).

2 `.Structure

This is another yet to be solved problem. Although 3D printing is an effective prototyping method, and I will continue with it, it is unable to duplicate the aesthetics established by my design process. It’s important to follow through form the designs in order to have a coherent final style guide. My current consideration is to create a simplified 3D printed electronics housing for each module and then attach other materials onto it via adhesives or mounting methods (Snap-in, bolts, etc). This will require a set of quick tests to decide what would be best for this process.

3 ).Write-out

The final outcome for this semester will be presented at the OCADU GradX, meaning that there are some considerations that need to be taken to make the invisible visible for the public. Data gathered by the sensors will have to be presented in a compelling and perhaps interactive manner. This will be a challenge after the codebase is complete, but must be considered throughout.

4 _.Functions

Communication is one thing, and although the code will not be challenging it will need to have a fairly high degree of stability. It will also need to be very general.

Each module can have a sensor or a part of a sensor (for example 1/2 of a 360deg ambient sound sensor is on one shoulder), the message that the module sends out to the collector will need to provide a very clear note of which sensor is which. The collector will have to process this data in order to unify the sensors that are split amongst modules.

Tag structure: Mod 1 thru 3 followed by sensor 1 thru 3 followed by sensor value i.e. 1|1|255 <- neck module, light sensor, full bright. If there are multiple sensor ‘pieces’ on different modules they are easily distinguishable. (1|1|255, 2|1|255) etc. This is a preliminary idea, and there might need to be more metadata passed through.

A lot of the data noise will need to be cleaned up on the software level as well (likely with basic thresholds).

The collector module (upper hip) will need to consolidate this data into a package that can be logged internally and synced as appropriate to an internet enabled device (Currently a mobile phone). Each package will be given a distinct time stamp and any message backlog will be pushed to the phone at the next best opportunity.

With the above code completed the project will have everything it needs to provide a clean interface for the gathered ambient data.

There are also a few parts that need to be ordered soon,

2x Colour light sensor. (And a focus lens that needs to be tested)
4x Wireless Charging coil and circuit.