Tryna catch me drivin’ dirty

We decided to use the TLC5957 LED driver of Texas Instruments with Broadcom RGB LEDs: ASMB-KTF0-0A306.

Configuration

Brightness control

First, we have to determine the maximum current which will be used. The 3 colours of the RGB LEDs can get a 20 mA input current max and the driver can handle 20mA sink current max. So we choose a maximum current of 20mA.

We decided to configure the driver with the maximum value for the Brightness Control (BC) (and by consequence, the maximum gain) to provide the intensity to go over 20mA. So we have to choose a value of BC equals to 7. And to limit the current to 20mA max we have to put a 9.27kΩ IREF resistor between IREF and IREFGND pins.

After that, we have to choose the Colour control for each colour. This parameter is used to choose for each colour, the ratio between the maximum output current for this colour and the maximum output of the driver. This is used to tune the white balance. According to the LEDs datasheet, the mean intensities are 490mcd for Red, 1100mcd for Green, 215mcd for Blue. So, to have the same mean intensity for each colour, we have to choose those values for CC: 224 for Red, 100 for Green, 511 for Blue.

Display control

The main mode of this driver is done to be used with 16-bits colours. However, we want to use it with 9-bits colours. So, we have to use the other mode: the Poker Mode. When we choose the Poker Mode, we have to activate the ES-PWM and the XREFRESH.

Data configuration

The driver contains several registers. We will use the 4 main ones. The first one is the Common shift register (48bits). Every data one wants to input has to be written in this register. The second one is the FC data latch (48bits). This register is used to configure the driver. Both last ones are GS data latches 1 and 2 (768bits each). They are used to save the data and prepare it to be sent to the LEDs.

The communication between registers is led by the SCK clock and the LAT signal.

How to use the driver

Initialization

First, we have to configure the driver so, we have to configure the FC data latch. To do so, we send bit after bit the 48bits configuration from the MSB to the LSB. In this configuration, we specify different values like the BC, the CC for each colour. We also activate the Poker mode, the ES-PWM and disable the XREFRESH. After sending the 48bits, we send the FCWTREN (LAT high for 15 rising edges) command then the WRTFC (LAT high for 5 rising edges) as below.

Poker Mode

In the traditional mode, we input in the common register the 16bits of each colour from Blue to Red and from MSB to LSB. But, in Poker mode, it is different. We input the bit n of the Blue of the 15th LED then, the bit n of the Green of the 15th LED … until the bit n of the Red of the 0th LED.

So because we use 9-bits colours, we have to first send le Bit 8 of the colours of 16 LEDs then the Bit 8 etc until the Bit 0. Then we output everything. So how does this work? When one has input in the common register the 48 bits data which represent the Bit 8 of the colours of 16 LEDs, one sends WRTGS command (LAT high during one rising edge). This command will copy the 48 bits of the common register in the 1st GS Latch at the address of Bit 8 (address given by the GS data bit address counter). Then the GS data bit address counter is decreased 1. The process is the same for Bits 7 to 1. For Bit 0, one uses the LATGS command (LAT high during three rising edges). This command will do the same thing as WRTGS but, it will also copy the entire 1st GS latch into the second one, it resets the GS data bit address counter to 8 and increased 1 the LINE counter (it will be useful later). But it also forces out the new values which will be sent to the LEDs.

Just below, an example with 10-bits colours. For 9-bits colours, it is quite the same but there are only 8 calls of WRTGS and the GS data Bit address counter starts at 8.

ES-PWM

This is a different approach to realize a PWM. The high state period will be cut and spread to minimize the time between high and low states and get a better result.

Multiplexing

For this project, we decided to multiplex LEDs by 4. Indeed, this driver has enough pins to control 16 LEDs but on each column, we have 64 LEDs. The process to write data is quite the same as without multiplexing. However, they are some things new. First, we will now also use a line counter. This counter is here to know in which step of the multiplexing we are; do we display the first 16 LEDs, the second, the third or the fourth ones. This counter is used by the LED Open Detection which is used to prevent the caterpillar effect but we will explain this after.

So now how do we write our data? For the three first groups of 16 LEDs, it is still the same: 8 WRTGS + 1 LATGS. However, for the fourth group, the LATGS method will be replaced by the LINERESET command (LAT high during seven rising edges). This command will do the same things as LATGS but instead of increasing the LINE counter, it will reset it to 1. That means we sent the data on every LED.

There is an error in this graph, you should replace XREFRESH=0 by XREFRESH=1

Caterpillar cancelling

The caterpillar effect is a problem caused by broken LEDs in multiplexed architectures. As a result, the LEDs multiplexed with the broken one can blink whereas they should be off when the driver tries to switch on the broken one. The Line Counter and the LINERESET command help the Caterpillar cancelling function to detect the broken LEDs and to automatically turn off the output channel for the specific line (so only turn off the output for the broken LED and not to every LEDs multiplexed with it).

How To Touch together ? MQTT is here.

One of the most critical part of the project will be the communication. Whether it is between the Touchs of with the backend we need our device to be able to communicate.

The communication challenge:

The first thing we had to do was to choose the protocol. As we wanted to allow both a communication with a backend and between devices, we chose the MQTT protocol. It has the advantages to be easy to use and to easily allow us to switch from listening to the server to listening an other device.

The first step: the broker:

In MQTT, all devices (may it be a server or an actual connected thing) are clients. They can decide to talk (post) or to listen (subscribe). But for it to work we need a broker. It is the part that will spread the information from the posters to the subscribers. We decided to use Mosquitto. It is a free open-source broker that can be installed very easily on Linux (and also on Windows but… well it is Windows).

The second step: the server

In the same time as the search for the components, we started implementing a very basic server. We used the python library paho-mqtt which is very easy to use. The issue we wanted to deal with first was the representation of the box in the MQTT packets. As our marble will have two positions, we decided to code each one by a bit. So the first idea was to send one integer per lines which binary representation would have been the state of each marble in the line. Doing so we could easily communicate the state of the box. Yet the issue was that doing so we could only retain the last integer. The consequence would be that when a new box connects between to images it would only receive the last line.

To avoid that we decided we needed to send one MQTT post by images. The first idea was to send a string with all the integers. Yet this would have increase the size of the message and we found a more elegant solution: the byte array. So as of now we have a server that send images represented by a byte array. The first byte being the first eight marbles on the top left corner, the eight right next to those and so one to the end of the line (we don’t know yet the numbers of marble). Once we are at the end of the line, we start a new byte with the left part of the second line.

Conclusion:

So far we have a Mosquitto broker installed on one of our computers and the server sending bytes array representing the image to show. The issue we have now is that the broker is only reachable from the same computer. We will try to figure out if it comes from the computer, the broker or from the network. Yet as we have received our coils and Hall captors the next weeks will be dedicated to testing them.

A false sense of symmetry

Although our initial plan to light the petals was to put waveguides between the petals and LEDs placed on a flat rigid PCB (see “About LEDs“), Alexis recently told us using flexible PCBs might be possible.

Flexible PCBs could be placed directly on the inside of the demi-sphere of the sculpture, thus avoiding the use of waveguides and ensuring a good luminosity. Their drawbacks however includes a high cost and the fact that Alexis hasn’t yet used them for previous projects.

Using flexible PCBs, our idea would be to take advantage of the symmetry of the sculpture and place identical PCBs along each of the 13 spirals. On each PCB, we put LEDs corresponding each to a petal. There is one catch though: the spirals are all slightly different… Indeed, it is an important property of John Edmark’s sculpture to have each petal placed at a unique height and angle on the sphere, with a unique size. While this is great for fluid animations (see Generating 3D Models), it makes the placement of the LEDs on the PCB a bit of a headache…

LEDs placement

We decided to use a smaller version of our sculpture, with only 8 clockwise spirals and 13 anti-clockwise spirals (The previous images we showed you were of a 13 and 21 spiral model)

Ideally, we want each LED to be placed at the center of each petal. But using an identical LED placement on 13 different spirals will obviously introduce off-centered LEDs: our goal is to minimize this. In order to do this, I first aligned all of the spirals in the same orientation, and sorted them according to their lowest petal height:

The petals are getting in our way here, what we want is to just see the quadrilateral surrounding each petal.

We then need to flatten everything, it will makes things even clearer, and the PCB schematics needs to be done in 2D anyway.

The floor you see on this image is the actual floor of the pedestal on which the sculpture lies. You can see some petals are partly buried under the floor: they still need to be lighted for a fluid animation, but some are unfortunately too small to have LEDs placed underneath them. With this additional constraint in mind, I spent some time in blender figuring out the best LED placement, and this is the result:

LEDs are in red, their size is around 5mm on this image

Here is a superposition of the worst case spirals, which was also very helpful to design the placement:

Frustrating, isn’t it ?

Alexis is currently gathering information to assess the feasibility of flexible PCBs for our project, we will make sure to keep you updated on our final choice.

Pro (Component) Choice

Update on the choices in components for Litspin. All of the main components have been chosen. Here are the ones we landed on :

System on Module

After looking at the schematics for CyL3D, we saw that they used around 40 pins on the FPGA IO. This meant that we could use the same Aries Embedded SoM based on a Cyclone V combined with two ARM cores.

LED Driver

For our LED drivers, we’ve chosen the Texas Instruments TLC5957. They give us a high enough input data rate and PWM reference frequency as well as enough channels to drive our LEDs.

LEDs

The LEDs we will use are the Broadcom ASMB-KTF0-0A306. They are 4-pin (common anode) RGB LEDs.

The wifi module and sensors are given in a previous post.

The hardest choices require the strongest will

The past week I’ve been looking through datasheet after datasheet in order to find several components that would fit our project.

  • Hall effect sensor:

Looking through the different types of hall sensors, I found that a switch sensor was the best fit, since we will use it to get the motor’s speed rotation, we only need to know when the magnet will be aligned with the sensor. The constraints we had on the choice of sensor were not numerous: we need a sensor with digital output, with 3.3V in input. However, one interrogation I have is whether or not the inductive power transmission will infer with the sensor. Alexis said that it was not a problem, but I am still wondering if having a highly sensitive sensor like the one Cyled chose, the TLE4964-4M, won’t increase the risk of interfering with the power transmission. I honestly don’t think it will be a serious issue, but I prefer to be sure before I validate this sensor.

Another issue I had with the position sensor was if it would be precise enough. A solution to that could have been adding an optical sensor in order to have a second measure, but the problem was that most optical sensors use infrared, which we already use for communication. In fact, simply having several magnets on the fixed part allow us to have several measurement points per rotation.

  • Infrared sensor:

Regarding the communication from the mobile part to the static part, Alexis advised us to do some research on the IrDA protocol, which is a communication protocol using infrared transceivers. There are several communication speeds available (SIR, MIR and FIR), but since we only need to transmit speed commands to the motor, the lowest speed (SIR, which corresponds to a standard serial communication speed: 115.2 Kbps) will be sufficient. I chose to use this kit with a emitter and a receiver: TFBS4650-TR1.

  • Wifi module:

For the Wifi module, I had two main choices to make:

  • the hardware interface: I started by searching what Cyled did. However, they did not have much choice regarding the hardware interface, and had to choose a USB module. On the other hand, we have a larger SOM that gives us much more choice: USB, SPI, PCIe are the main ones. I found module for each of them, but I’m still not sure which interface would be the easiest to implement.
  • the protocol version: for the 802.11 protocol there are several versions, such as 802.11b, 802.11n or 802.11ac., 802.11ac is the most recent one and the fastest, but it also consumes more power, and most importantly, we don’t need that kind of speed, since we won’t do any streaming. Consequently I choose to stick with 802.11b/g/n compatible modules.
  • Leds:

In terms of lighting, we have the same constraints as Cyled, so we will just take the same: ASMB-KTF0-0A306.

EDIT: I didn’t publish this post right after I wrote it because at the time we were waiting for answers from Alexis, and I wanted to publish it with the answers.

After the discussion, several things changed:

We will in the use a sensorless motor, as Cyled did, so this eliminates the need for a IrDA communication with the motor. No IrDA communication means we can use an optical sensor along with the Hall sensor in order to increase to precision of the speed measurement, just like Cyled did. We will use the TCUT1600X01.

As for the Wifi module, in the end we will go with an ESP32-WROOM wifi module which will communicate in UART with the PCB.

That’s it for the choice of these components. We can now start making the PCB!

Communicating between Phyllos : Who’s Who ?

In order to display animations that flow back and forth between several Phyllo, the Phyllos need first to be able to know each other’s position. 

For now, we have reduced this problem to this : to display animations in the proper orientation relative to its neighbours, each Phyllo needs to know the direction of each neighboring Phyllo. They have no real need to know exactly how far they are from each other.

Associating detection and communication

It is not enough to merely detect Phyllos if the detection method doesn’t allow us to distinguish one Phyllo from another. We have to be able to both talk to a specific Phyllo AND know where it is physically located.

It’s the same problem as trying to find someone you’ve never met in a crowd, while you’re on the phone with them. At some point you’re going to need a sign to differentiate them from every other person around you.

So far we have discussed several ideas :

The IrDA idea

Our first idea was to place a lot of highly directional IR transceivers facing outwards all the way around the fixed part. Regularly, if a Phyllo isn’t communicating with anyone, it emits its identifier. If one of the transceivers detects an answer, the Phyllo uses this transceiver to speak with the Phyllo who answered. Like that, we communicate directly in the right direction. If three Phyllos are aligned, the middle Phyllo will hide the two others from each other, but it’s not a problem.

However, we do not know if it is feasible. One problem in particular is that, in order to use very directive IrDAs, we would need many of them to cover 360° and the processor probably won’t have enough UARTs.

The magnet sensor idea

Alexis suggested that we use magnetic sensors. It would then be possible to have hardware set ids by playing with north and south poles of magnets in each Phyllo. Alexis also lent us an evaluation board of such a sensor.

However, even with pretty strong magnets, we could not detect anything further than 5cm (which is to be compared with the 15cm diameter of a Phyllo). Moreover, it doesn’t seem easy to discriminate magnetic perturbation from each Phyllos, and even more if each of them hold several magnets. On top of that, we would need to filter out the Phyllo’s own magnets.

The rotating IR emitter idea

Our favorite idea so far is about combining Wifi and IR detection.

The Phyllos start with Wifi to list everyone present. They either already have unique identifiers, or cooperate to give each-other unique identifiers.

Then, in an agreed upon order, each Phyllo emits IR in all directions with several emitters around its fixed base to cover 360°. Each Phyllos also possesses an IR receptor on its rotating part, allowing them to determine the direction of the Phyllo who is currently emitting. Thanks to this protocol, the association between Phyllos’ ids and their location is possible.

Working anatomy of a Phyllo

Architecture

Here is a diagram summarizing the architecture of a Phyllo, to allow you to have a global vision : 

Some details

This week, we spend a lot of time trying to choose the components. Here are the solutions we explored and the decisions we took.

Motor and ESC

All the animations we will display are based on two or three basic animations : aging petals, de-aging petals and possibly fixed images. Here are simulations to visualize those animations :

Aging and de-aging petals

In order to display those animations without skipping any petal (have a look at this instructable to remember the “skipping petals” part) while flashing the LEDs at 30Hz (ie 30 frames per seconds), the Phyllo has to rotate at : 

AnimationSpeed (RPS)
Aging petals11.46
De-aging petals18.54
Fixed petals30

Furthermore, we are going to use a brushless motor (less wear-and-tear, less noise) controlled by an ESC. We have chosen not to use the same motor than J. Edmark (KV135) but a motor with a higher KV, in order to consume less power. A higher KV motor has a weaker torque at the beginning, so we will have to choose a precise ESC (some of them are controlled in I2C or SPI). 

For now, we have chosen:

For the ESC, we will first test if the ESC CyLED used last year is able to start our motor. If not, we will use the VESC 6+.

Battery

The LEDs will require a lot of power, but for very short bursts: they will require less than 1W on average. The motor require at most 75W. We would like to have 1h autonomy, so the battery has to provide 80000mWh. The motor we choose requires a 6S battery. Therefore the capacity must be more than 3622mAh. We have chosen this one : Batterie Lipo 6S 4500mAh.

Power transmission

First we wanted to have a wireless transmission to avoid the ugly effect of having a metal bar coming out of the top of the Phyllo, as CyLED did last year. After extensive research, we found that this type of energy transmission is currently used almost exclusively for mobile phone charging. Therefore, output power is usually far lower than our needs (20W against 120W). The few products with better output power are essentially coming out of China without any documentation.

We also considered the possibility of building our own wireless transmission to get an appropriate output power. However, it is too hard to get a satisfactory calibration and we do not have the time required.

The following idea was the slip ring. However it has a big flaw: it wears down quickly. We imagined to have one connection on the ball bearer of the motor. Then, we thought that we could put a second one as a ring on the axis of the motor to completely get rid of the slip ring.

This ball bearer has no other use than electricity transmission. Here the insulating layer enables the ball bearer to stick to the axis. It is also necessary since the axis already bears the current from the ball bearer of the motor.

Regulators

We will need at least a 3.3V regulator and a 5V regulator, to regulate the output voltage of the battery and of the power transmission device. We have considered 2 switching regulators : LT1765 and LM2678.

LEDs and light pipes

We haven’t received all the components yet… While we were working on the components choices, Vlaya has started to design some tests for the LEDs.

LED Drivers

We plan to use a LED driver for each spiral arms. The drivers need to have enough output channels to drive all the RGB LEDs of the spiral without multiplexing. A Phyllo has a different number of clockwise and anticlockwise spirals, so we can take as many drivers as the smaller spiral number, in which case they need to have more channels, or as many drivers as the bigger number, and they can have fewer output channels.

The drivers cannot be interrupted in the middle of a PWM cycle, therefore the clock of the internal PWM of the drivers needs to be fast enough that a PWM cycle is shorter than approximately 100µs. That is the time the LEDs can be flashed, if they stay on for longer periods the image will blur due to the Phyllo’s rotation.

Moreover we need to be able to communicate fast enough with the drivers to send the color values of each LED to the drivers in the time between each frame (1/30 of a second). And we need to be able to simultaneously enable and disable all the drivers.

Finally the output current must be high enough to power our LEDs with an acceptable brightness.

We have chosen these LED drivers : THL3502

  • 24 channels, allowing up to 8 RGB LEDs per driver
  • PWM 10 MHz and 8-bit brightness control, making for 25.6 µs PWM cycles
  • 10 Mbps I2C serial input, allowing us to send colors for 150 RGB LEDs in 240 µs
  • Output current : 100 mA

With the I2C interface, we cannot simultaneously fire and disable all the drivers. If the delay gets too big, a solution could be to separately control the current output to the LEDs with transistors.

Wifi

We will need Wifi to communicate with a Phyllo from a computer, and probably to communicate between Phyllos. At first, we wanted to use an ESP32 because it’s simple to use and easy to find help online. But after discussion with Alexis, we will use a AMW006.

SD

We would like to be able to upload complex animations frames on a Phyllo and maybe allow users to do the same. To provide the necessary storage space, we will use an SD card : JAE_ST1W008S4ER1500.

Angular position sensor

To be able to display neat and clear animations in a precise direction, we must be able to detect the alignment of the motor with its original position with an accuracy of less than half a degree (to have distinct images like J. Edmark). To do so, we will use a Hall effect sensor (TLE4964) and we planned an optical sensor (the same than Cyled : TCUT1600X01) just in case, even if theoretically, the Hall sensor is precise enough. The idea is to get a pulse every rotation and use these to deduce motor speed, and then integrate the speed, coupled with the once-a-rotation pulse, to deduce the angular position.

IrDA

To communicate inside a Phyllo between the fixed part and the rotating one, we will use IrDA. We have chosen these transceivers : TFDU4101-TT3.

The IrDA Design Guide requires a transmission distance of 0cm to at least 1m and an emission angle of at least 30 °. Thus, if we place the transceivers close to the axis of rotation, they will be able to communicate during most of a turn, so no worries about the transmission speed.

If we can not place them close enough to the axis of rotation (because of the wide motor diameter), we can reduce their directivity by putting a diffuser so that the LED illuminates the entire interior of the phyllo (or at least most of it) and the two transceivers can communicate all the time. It will not be necessary that it affects the communication of the other Phyllos.

If we cannot place them close to the axis of rotation nor diffuse enough light, and we are obliged to place one at the periphery of the PCB: we place one near the center facing outwards, the other on the periphery oriented towards the center. They will be able to communicate during 2.7ms minimum. In this case, we must take elbow transceivers like TFDU4101-TR3, probably faster ones…

To be continued…

The following post will detail our ideas about detection of other Phyllos and communication between them. And Monday, we have a meeting with Alexis to decide on a solution. We will keep you updated 🙂

Ah Qi, here we go again

After seeing Alexis, we noticed that the package of the previous component that we thought would do the job was based on BGA package… so we’re back to the previous step !

Basically the ideal component should :

  • be Qi compliant (low power profile and extended power profile)
  • have a 15 W power output
  • not have a BGA or CSP package which is definitely the hardest part

For a moment I thought I found the perfect match in the TS81000 : Qi compliant, up to 40W power output and QFN package ! Well yes, but actually no.

Alexis brilliantly pointed the fact that this component was only the auxiliary part of the receiver, and the other part which was the TS5111 has a WCSP package. This makes this solution unsuited to our project.

I also came across the BQ51013 which is interesting but can only deliver up to 5W. We think this might be too low for our project but as we still haven’t a precise idea of the power consumption of our device we might come back to it later.

For now we’re going to put aside the wireless power transmission and will stick to a basic USB port, that we will try to hide as much as possible.

Architecture: “The more it’s simple, the more it’s simple”

First, the work of some students

We spend a whole week working with just a few responses from Alexis, so we try on our own to find out how to make our architecture. This is what it would look like

We spend a lot of time exploring the best components, as you may have seen it in our previous posts.

We would have to make a lot of FPGA programming for the I/O expander, but we thought it was our unique solution.

We spend some times looking for a sensitive captor touch with only one key and the way to use it because we wanted to use the sensitive captor touch of an ESP32-WROOM-32D.

Then, destroy everything with a single Alexis and build again

We had a meeting with Alexis yesterday. He explained to us that the sensitive captor touch of the ESP32 wouldn’t do the job through the wood. One component to change. Fortunately, we already found a 3-key sensitive captor touch, we just have to make sure it will have enough strength to work through the wood.

Then, we spoke about the price and the length of the device. With 64 I/O expanders, Touch would be too expensive for funding it, that’s why we choose to make only a 16×16 grid of marbles.

The next step was the I/O expander: we cannot use them for our hall effect sensor because they are analogic and not numeric. We thought to change for numeric ones but we will come back to them later

We still need a lot of I/O expander, that’s why we need to find a better architecture for our H-bridge. Alexis first thought to make something similar to the architecture of a digicode. One half H-bridge by line, and one by column. If we want to activate the third coil of the fourth line, we would put VCC on the third half H-bridge and the ground for the fourth half H-bridge.

Finally, taking a look at our H-bridge gave us the best solution. This H-bridge can be controlled by an I2C bus, and we can give each of them a special address, so they can be on the same bus: instead of 32 pins, we just need to use three pins. Two for the I2C bus and one for the address, that we will link to some shift registers to control their address.

Now, are we happy? Not exactly, we still need to find how to control our hall effect sensors. A brief look at component gives us our last solution. We would use some analog multiplexers. So, here is our new architecture.

And now?

We are waiting for some coils and Hall effect sensors, and we will begin our tests.

To Qi, or not to Qi, that is the question (that was actually)

About Wireless Power Transmission

Because we wanted to create a design centered around aesthetic for our device, we chose to implement wireless charging for our battery.

There are plenty of ways to implement WPT. First of all there is near-field power transmission and far-field power transmission.

For our project, we will focus on a near-field power transmission. In this field, one of the most common technique is inductive coupling. But it is not the only one : capacitive coupling is an interesting technique for our project.

Capacitive coupling VS inductive coupling

Because inductive coupling is based on converting AC current to a magnetic field, there is a high risk that it will cause strong interferences and perturbations with the magnetic fields of the marbles, thus complicating our control over our device.

Regarding this point, capacitive is interesting because relying on a different medium to transfer energy i.e. not a magnetic field. Alas, the major problem with capacitive coupling is that there’s poor documentation on the subject and therefore is hard to implement.

In the end we choose to go for inductive coupling which is very well documented with the advantage of having many organizations working on the subject.
To counter undesirable effects of inductive coupling, we plan to implement electromagnetic shielding.

Qi standard and the Wireless Power Consortium

The Wireless Power Consotium is one the biggest and most important entity working on WPT. They established the Qi standard which is currently in version 1.2.3, with the specification downloadable here.

At first, when looking how we were going to implement Qi compliant WPT we looked for easy implementable solutions like the Würth Elektronik development kit after seeing a similar solution suggested by our comrades working on LitSpin.
Unfortunately implementation of the said kit would be too much space consuming and we would end up with a much thicker device than expected thus possibly ruining the aesthetic aspect.

Because of that and the fact that implementing by ourselves the Qi compliant receiving part of the WPT chain might involve an unknown quantity of unexpected work, we looked for other solutions which weren’t necessarily Qi compliant.

Long story short, the chinese components we could have used as a replacement would mean forgetting interoperability between transmitter and receiver. Therefore after discussing about this with Alexis, we decided that it’d be more safe to stay on the Qi standard as the specifications on the chinese components were vague. Moreover, using the Qi standard we’ll easily be able to order a Qi compliant power transmitter, already packed and beautiful like this one (this one has bad reviews but it’s just an example of the aesthetic we’re looking for).

How to Qi

We will be working on the Mobile Device part of the Wireless Power Charging | Source : http://www.idt.com P9415 datasheet

The research for Qi-compliant Wireless Power Receiver IC ended up being longer than expected because the components category name isn’t consistent throughout websites. In the end, and after going through pages and pages of datasheet we found this device that we need to further discuss with Alexis before order.

Particularly we need to know what’s behind the two arrows between Receiver and Load on the above image.