Little-Brosers Week 2: Walking into the unknown

Hello, this is the Little Brosers group. This will be the only post from our group this week as we have all worked collectively on the same subjects until now.


As you may have heard from other groups, the focus of this week was establishing PSSCs (Project Specific Success Criteria), cutting the big project into small digest pieces, and putting deadlines on them. We now have a better view of the road ahead of us, and it was both exciting and a little scary to quantify the amount of work this project will represent for the four of us.


We decide to class our PSSCs into four categories:


  • Algorithmic category, whose aim is to define precisely the protocol followed when a smartphone encounters a drop. The big steps are going to be the “handshake” and authentication, determining which message is missing to each entity, and finally the transfer of said messages.
  • Hardware dependant category, which regroups everything relating the PCB directly: schematics, test of each component, software closely related to hardware (OTA firmware update for example) …
  • Back-end category, which obviously concerns the main server which will act as our certification authority for users, our main tool to synchronize the dates of the drops and prevent a maximum amount of date cheating from users with malicious intents, and finally as a “main drop” connected to the internet to help synchronize messages.
  • App category, which is very important even though it is not the main focus of the project. These PSSCs will help ensure we do not forget to work on the specific aspects of a smartphone app while we are all very busy thinking about the rest.


Here is a link to the wiki of our repo, where you will find the exhaustive and up to date list of our PSSCs, which are obviously going to change in the next few days as we apply the feedback we’ve received after presenting them. You will also find a link to the presentation we gave on friday.


Next week, a few tasks await us. First, precising the theoric aspect of the exchange protocol between the drop and the smartphone. We are going to look for resources about hashing, Merkle trees and symmetrical/asymmetrical cryptography, and try to put on paper a first “pseudo-code” version of our protocol. Second, we are also going to have to put numbers on our needs for the project PCB, to further narrow down the component selection. In our case, we will have to find ways to discriminate the various BLE chips that we have spotted, as well as decide on what external flash we want. And last but not least, as mentioned earlier, we are also going to update the PSSCs to add a few things we have forgotten and correct a few mistakes in the planning.


Thank you all for reading, and see you next week !

The Little Brosers team

SpiROSE: PSSC, organization and yesterday’s presentation

This week we delve into the project and tried to figure out how to organize it, defined a data path and sought suitable components. This lead to a list of PSSC and a bit of panic when we realized how much we have to do. Fortunately we are five, and we will hopefully managed to parallelized many tasks.

We made several PSSC categories to define a clear organization : we separated software and hardware, and in each part made an incremental series of test. Because we won’t have the cards before early December, we will do as much test as we can on the devkits. We plan to test each main part -the fixed base, rotative base, and blades- individually, and then test their interaction.

So the organization is, loosely:

  • The following week will be focused on definitely settle the specifications, components, communication protocols and mechanic layout. Then we can make the PCBs’ schemes and rout them. This bring us to mid-november, where we can command all the components and PCB.
  • As soon as we receive the devkits we can start develop the code and test every part incrementally, hopefully this is done by the end of november.
  • After we receive the main cards, we will run the tests done on the devkits on our PCBs.
  • We will start to assemble the system in early December, when we have all the components for the fixed structure, and begin welding as soon as we have the electronic components. This has to be done before the first demo, mid-December.
  • In parallel we have to develop a software to generate 3D voxel image and animations. The image part as to be ready for the first demo. We also have to develop a simple 3D game, like Tron’s motorcycles, for the third demo.
  • We plan to have a first demo mid December, which will gives us the best -or the worst, if the demo failed- christmas ever. The first demo consist of streaming an image, not an animation, from the PC to SpiROSE.
  • The second demo, the one with beautiful 3D animations, should work in early January
  • The third and final demo is to play a game with SpiROSE as screen. This is planned for mid-january.

We presented this yesterday’s to the class and teachers, and it seems to be reasonable although there are still many things to decide that can have a huge impact on what we planned. Here is what we learned during this presentation:

  • We wanted to use PCIe for the communication between the FPGA and the SBC, this is not possible as the IP are under expensive licenses.
  • We may not need an FPGA if we drop the number of voxels.
  • We considered using LVDS video protocol, however  those kind of iP are not free
  • We have to be careful with the power on the brushes, and thus implement tests
  • We planned to use CAN or Flexray bus between the fixed part and the rotative one, but IrDA or Bluetooth will be sufficient and remove cables which is always nice.
  • Even without a central axe, we will still have occlusion when looking from slightly above SpiROSE.
  • We should try to simulate the POV effect with different layouts, with Blender for instance, in order to see the occlusion problems.

So by the end of next week, all this should be crystal clear and well defined!