AmpeRose: Plans for week 2

Hello world!

We are the AmpeRose Team, and we’re excited to tell you that today we embark on our noble quest of creating an affordable high precision Micro-Ammeter!

This week our work will be divided between two crucial tasks:

1-We are going to conduct an extensive research on current measurement techniques and state of the art tools to perform them. This task will be supervised by Ian.

2-Meanwhile, under Michel’s lead falls the task of specifying the architecture of our embedded system, as well as its interface with the IoT device.

In both of the aforementioned tasks, we will first focus on the functionalities, and once we have a clear image, we will choose specific components that fit our specifications.

We will be setting the overall specs and performance requirements for our project very soon, so feel free to comment with your notes, suggestions or remarks!

Keeping you posted,

[SpiROSE] Hunting for a SBC, blinkies and bandwidth considerations

Hey y’all !

So we’re getting a compressed video stream from a laptop / computer / wizard, and we somehow need to send it to our blinkies. Thus I went hunting for a single board computer (à la Raspberry Pi) which meets the following criterias :

  • 5GHz Wifi : even a compressed H264 or H265 stream takes some bandwidth. Moreover, we’d like to have the most reliable link possible. With all the networks there are @telecom, 2.4GHz is out of the question.
  • High bandwidth wired link : be it LVDS, Ethernet, anything; we need to get the data out of the SBC. Either to an FPGA or straight to the blades, chances are hundreds of megabytes will be transferred. Gigabit ethernet is the most interesting one, as it is really easy to use and distribute to many nodes.
  • Hardware video decoder : H264 (or even better, H265) is a huge help to overcome bandwidth limitations. However, even a powerful SBC has troubles decoding a 1080p@60Hz stream in real time. The test was done on an Odroid C1+ (Cortex A5 @1.5GHz x4), wich decoded a 1080p H264 stream at 70fps, but with frequent dips at 30fps. This also leaves very little room for other stuff to be happening, as all 4 cores were maxed out.
  • SoM form factor : oh my, connectors are a mess. This is not a mandatory criteria, but it helps. We’d like to get a SBC that offers an edge connector, to easily integrate it on a custom PCB. A widely known example is the Raspberry Pi Compute Module.

After sifting through the interwebz, this table was born. It allowed us to highly narrow down a suitable candidate. A totally overkill board is the FireFly RK3399, but is pretty hard to find and is considered a VERY bad idea by T.G. because of the Rockchip chip. The final choice still needs to be made, but this will come in handy.

I also quickly went shopping for small RGB leds, and a few were found. This table summarises the 3 most interesting one, where the second one looks really good.

Since we are considering sending data to the blades using ethernet, I wanted to know what kind of bandwidth we could expect of a microcontroller loaded with a 100Mbps link. After some Quick’n’dirty® coding, I ended up with a board able to receive 7.38 MiB/s of data. This test was done without any kind of optimization, with lwIP+ChibiOS running on a STM32F407.

Much more was done, but I won’t repeat my colleagues :]

Next week, I’ll focus with the others of defining the exact LED count we want, but right now, we are looking at 128 LEDs per blade. We will also discuss some possible optimisations of the data we send to the blade, and the layout of the voxels : do we just map a square image on a circle (à la ROSEace) or do we try to be smarter and wrap it on it, or maybe be even smarter?

AmpeROSE Week 2: The First Presentation

Hello, everyone!

Here is an update for the AmpeROSE project:

The First Presentation

For this week, our main mission was to prepare an initial presentation of our project to be done before our teachers and colleagues. The presentation had to cover five essential aspects:

  • What is our goal with this project, and what are the use cases we envision for it?
  • What are the main features of the project?
  • What are the the technical limitations our project will suffer from?
  • What are our Project Specific Success Criteria (PSSC)? These are a series of simple “yes or no” (or “done or not done”) questions, each corresponding to a step in the design and construction of the AmpeROSE device, such that a step will only be considered complete if  the corresponding PSSC may be answered affirmatively.
  • Which technologies will be used for data communication in the project?

Thinking about these questions really helped make the AmpeROSE device more concrete to us. Here are the answers we have at this point, to a lesser or greater degree, they are all likely to evolve as the project goes on:


Our goal with ampeROSE is to build a prototype for an affordable digital ammeter that integrates naturally with the conception of low-power connected objects. The ammeter will be placed between the battery and the device under test, and transmit the measurement data to a computer, where an user interface makes it possible to visualize the data and treat it (for instance, with some of the usual options found in a digital oscilloscope: FFT, integration, trigger options, determinations of min and max values…).

Main Features

The main features are similar to what was described in the previous post about AmpeROSE:

  • High sampling rate (at least 1MHz).
  • A dynamic range going from 10nA to 100mA.
  • Self-calibration.
  • Data transfer to a host pc.
  • A simple and effective user interface.

Technical Limitations

An important technical limitation is that the measurements with AmpeROSE will necessarily be intrusive to some degree to the normal operation of the device under test. Our challenge is then to diminish this intrusiveness as much as possible, so the measurements are as accurate to the real values as possible.


We structured our PSSC around five main themes:

  • Current Measurement: the design and implementation of the analog circuitry used to measure the current being drawn from the battery by the device under test, and how it will interface with the digital part of AmpeROSE.
  • Data Processing: the design and implementation of the digital part of AmpeROSE (selelection of the embedded processor, development of the firmware…)
  • Circuit Board: The design and implementation of the circuit board which will house both the digital and analogic composants of AmpeROSE.
  • Packaging: The conception of the 3d-printed packaging that will house the circuit board.
  • User Interface: The development of the program that communicates with AmpeROSE, through which the user will be able to access the data collected by the ammeter.

Communication Technologies

We are still considering USB 2, USB 3 and Ethernet as options for connecting AmpeROSE to the computer hosting the user interface (or even having two or three of technologies as options to the user). A question that must be answered before we can reach a decision is whether the bit rate that will be required for transmitting the measurements to the user interface is compatible with even USB 2. Some back-of-the-envelope calculations suggest it should be, but we really need to determine this more formally, which leads us to:

Numbers, numbers, numbers…

For this new week, the first goal (indeed, to be completed by the end of monday morning) is to augment our description of our project with informed estimations of all the key quantities related to it:

  • What computing power will be demanded from the embedded processor within AmpeROSE (multiplication / additions per second…)
  • How much measurement data AmpeROSE should able to store internally at any given time.
  • What bit rate will be required for the communication between the AmpeROSE device and the computer hosting the user interface (as mentioned)

And most important of all:

  • etc.

This exercice will be essential in order to proceed to the selection of specific components for AmpeROSE. Check in next week to learn what conclusions we reached!


Hi all,

This week’s post is a group post as well. It sums up what we have done and what’s planned for next week.

I wish you happy Reading !

Enguerrand for the ZeROSEro7 team



This week, we made the first version of our PSSCs – Project Specific Success Criteria – which are reachable on the Wiki page of our project (Only available for other students). Each of our 3 devices has it’s own PSSCs although many deadlines are shared across them. Our general idea would be to have all of the PCBs ordered early December and meanwhile we would develop the softwares on development boards. This means that we should choose the µControllers, OS and Wireless modules soon so that we have ordered the dev boards and modules for testing around mid November.


We also made our first presentation in class where we explained our PSSCs and features of each device. Here is what we have came up with for now :

USB Sniffer

  • USB Female
  • USB Male
  • BLE
  • (Optional battery)

Spy Talk

  • USB (debug and recharge)
  • BLE
  • LoRa
  • Battery

Stealth Drop

  • USB (debug and recharge)
  • BLE
  • Wifi
  • Battery


We are still investigating solutions for these questions :

  • Will the USB Sniffer be able to take control of the keyboard and write stuff. Example : typing a password would open a shell on a notepad.
    • Will the USB Sniffer be able to remotely control the computer through Windows shortcuts. Example : ctrl+R, cmd, DOS commands ….
  • Will the USB Sniffer have a battery for instance to still emit over a weekend where the computer is shut down ?
  • The SpyTalk is a BLE to LoRa relay and thus, most of the software part can be done in the smartphone app (messages routing, encryption …). Is there any difficult computing left for the device?

Next Week : Constraints and Components (beginning)

Next week, we will put numbers on all the constraints we want for the project in order to choose the components. This includes range, bandwidth, memory available, battery life …

Since we have 3 devices and not just one, and that they share some modules in common, we want to reuse as much as possible the same components between them.
Ideally, all 3 would have the same µController, BLE and USB ports; We would also find a single dev board that can take the role of any of our gadgets. The flash sizes vary a lot between them so it probably won’t be the same (small for SpyTalk, 1Gb for USB and several Gb for StealthDrop).


Our methodology to achieve the component selection at the moment is to scan the recommended vendors for the BLE modules for instance. Then compare them. It gives us a good idea of what’s achievable (range, size, consumption…) and which components would best suit each of our devices. We also keep in mind that the USB sniffer should be as small as possible (Ideally the size of both USB connectors and no more) as well as the SpyTalk which is to be carried by the agent at all times. One of our concealments designs would be to hide it in a zippo for instance.

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: Security and interactivity

As we discussed the plans of the project, we quickly realised that allowing rather large devices to rotate at around 2,000 RPM was not inconsequential to anyone using SpiROSE with regards to safety. A first mandatory step is to use a large transparent cylinder to prevent any moving part from flying away with high energy, should the implemented fixation fail at any moment. But this is not enough. We must make sure that no one tries to move SpiROSE while it is working – you do not want to destabilise a device with blades that have a terminal speed sufficient to race with a car on German highways !

Therefore, an Inertial Measurement Unit (IMU) is planned to be placed in the fixed part of SpiROSE to monitor any movement of the device – except the vibrations caused by the rotation – in order to know whether it is safe for SpiROSE to be working. First of all, before the system is even started, it checks if it’s completely still and horizontal. Then, while it is spinning, SpiROSE is able to detect any extern action and to perform an emergency brake on the moving parts. We were thinking about mechanical brakes to quickly and significantly reduce the angular speed, but it has to be calibrated not to have a massive deceleration that could weaken or destroy parts.

Let’s jump to another feature of SpiROSE, its interactivity. We do not just want a 3D display, but a 3D display that can be, as much as possible, controlled by the user. We decided to use an LCD display for the human-computer interaction. It is attached to the fixed base. It will for instance display information from the IMU or some useful other from the SBC sent through CAN/FlexRay/IrDA/BLE. The interface will allow a user to adjust some parameters – we have not decided of all of them yet – on the 3D display. A clickable rotary encoder or an endless potentiometer allows us to navigate through the interface and set adjustments, for instance we could rotate a steady 3D image. Isn’t it pleasant to touch a knob rather than to move to the other side of SpiROSE to see the face of your favorite character displayed in 3D ?

The exact features available on the LCD display will become more and more accurate as the project keeps going. Yet we have to focus on more basic features for SpiROSE by the end of the upcoming week, such as the exact dimensions of the device thanks to the mechanic, so that we can really begin working on something that we know is feasible !

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!

Data path in SpiROSE

During this week, we worked on having a better understanding of the project and tried to define a clear data path between the computer and the rotating LEDs. Actually, we had to make a list of PSSCs for yesterday’s presentation and while we were finding new criteria, we realized more and more the amount of work needed to reach the end of the project. Therefore this step was a pretty urgent matter.

At first, we wanted to bind the SpiROSE to a computer through a usual Gbps RJ-45 link, and send the frames to the blades through 5GHz Wi-Fi, because it was the easiest way to scale the display to what we expected. However, we didn’t managed to find cheap and easy ways to do 5GHz Wi-Fi. Besides, we were not really sure of whether interferences effects could happen and it didn’t solve the power issue too.

So after looking for a wireless solution to send data from the computer to the display, we finally decided to find a SBC because of the 5GHz Wi-Fi capability we usually find on them.

The idea yesterday afternoon was to send compressed frames from the computer to SpiROSE in 5GHz 867Mbps Wi-Fi, then decode them on the SBC and send them to a FPGA which will do the transform and filtering computation for each LEDs.

After the presentation, we kept on looking for solutions so as to do all of these computations on the SBC directly, but we couldn’t solve the issue of transmitting the data to the blades from the SBC. We will find solutions by deleting some available voxels close to the center and make the resolution uniform across the display. However, it will be more difficult to do circular pattern painting. Maybe we can manage to do both ? At the moment we are trying to find a way to connect the blades to the SBC.

This week, I will work on having better specifications of the project so that any question like how many LEDs on a blade or what is the speed of the engine is sorted out before the middle of the next week. It will also help to have hindsight of what we choose and later will highlight what changed if we need to cut our expectation for the project.

We will also try to validate another mechanical model, try to negotiate more space or to match our expectation about how the blades are rotating by doing some great jokes with the mechanician. But even if I’m not bad at pun, I’m scared by how we will manage to fix the blades to the drum.

SpiROSE: how about the mechanics?

This week was full of requirement definitions. How many leds do we put, what bandwidth can we expect between the computer and the display, what technology can we use for [insert stuff here]… Lots of them have been defined, and more than 70 PSSC (Project Specific Success Criteria) have been written. During this time, mechanical drawings have been done to try different mechanical layouts.

The system is based on a main layout : a big squared block makes the fixed part of the system. A big plexiglass© cylinder with a top roof is put
over the block. Inside the fixed cylinder is the rotative part of the display. There have been multiple rotative versions. The idea is to make
something that can infer no occlusion while it’s turning. The induced problems are:
– The PCBs must be fixed without inducing occlusion (when turning)
– The layout of the system where the PCBs are going to be fixed shall not induce occlusion when turning.
– This system must resist without wobbling and have an intertia momentum small enough to respect our security criteria.


Mechanical preview

Example of full design with triangular rotary mechanism


We ended with about 5 designs for the moving part that we’re going to review with the mechanic.
More to be done on next week, as the mechanical drawings should be done at the end of next week!

[ZeROSEro7] Spy factory since 1962

Our ROSE project – RObotic and Embedded Systems – called ZeROSEro7 will upgrade the spy world! A panoply for Secret agent with several spy weapons the most miniaturized and discreet possible. A small informer which tells you where your target is. A device plug on a computer which send to you important data inside the laptop. And more ideas…

This project includes a team of  Enguerrand, Vincent and Erwan, who will design, produce and valid the viability and performance of our smart devices.

First of all, we had to choose only 3 spy weapons among several gadget ideas we had. We considered our interest in each device and took into account some technical difficulties in order to choose the best ones.

Each device description is following:

  • USB Sniffer
  • Spy Talk
  • Stealth Drop

Then, we will think about technical solutions to design them. We will be able to write a specification for each spy weapon we decided to develop.

After that, we will be able to evaluate more precisely each device difficulty. Considering time and cost constraints, we will modify expectations to make them more or less challenging.

USB Sniffer

Need to know the passwords used on that computer? Or do you want to know email contacts of your targets ? Well, all of this could be retrieved with a keylogger but maybe their security is too high. We have another solution for you !

This would be a small usb2usb device that you plug in between the computer and it’s keyboard. While for the user it will remain transparent and forward all traffic, it will log all the typing in the background and communicate it on demand through some wireless mean. It could even do some pre-sorting and mark susceptible passwords and emails. This gadget should be as small and discreet as possible so that no one notices the little man in the middle.

Spy Talk

Even during a mission, the MI6 agents have to communicate to one another. Still, there might be someone tracking the public network activity and detect them. Hence, they need to have their own private and stealthy communication network. Our goal would be to make some easily concealable relay stations that could be planted across the city. The agents would then be able to communicate using their phones without using any sort of public service.

Stealth Drop

To transfer big amounts of data without being noticed, you can use a USB key. The sender can hide it in a dead drop and the receiver can come and pick it up in the following days. That way they can’t be spotted in the same place at the same time. Yet, they do have to go to the same place.

Our dead drop would add some range to that process so that the agents no longer have to be at the same rendez-vous place. Instead of a USB key, the sender would place a device which will send the data up to a range of a few blocks.The receiver can then activate it and transfer the data with a huge rate and in an even less noticeable way.