Categories

[AmpeROSE] NET API

Hello everyone,

Last week, I talked about the sd API that I had built on top of fatfs API which simplifies some of its calls and adds debug information when debug mode is enabled.

I also showed you the different tests I had made and some of the results.

This week, I have started working on a new API and finished it yesterday. It’s the network API. It uses lwip and is built on top of the netconn API. It aims to simplify some its calls and add debug information like the sd API.

For example, it has the following functions:

  • launchTCPServer
  • launchUDPServer
  • connectTCP

To guarantee the expected behavior, I have developed 4 unit tests and executed them on the Olimex development board.

Have a nice day!

[AmpeROSE] ChibiOS – Sd card

Hello,

In the last two weeks, I was working on the backend, specifically on Sd card. I’m developing code and testing it on the same board that we used during TP: Olimex STM32-E407” before migrating to our real board.
I started by setting up ChibiOS and made some very simple tests (blinking the user-led, etc) to ensure the good control of the board. Then, started the real development.

ChibiOS.17.6.3 integrates fatfs (developed by Chan), an API that offers a very good level of abstraction when communicating with Sd card. It offers a lot of functions, for example f_mount, f_open, f_close, f_write, f_read etc, and it is actually well documented. Before using the Sd card, it must be formatted to fatfs (fat32 is the default one).

Besides the code of Sd card (API Calls, debug info,..), I developed six different tests, each one had a very specific objective. Let’s dive into them…

Test1: Unit test

It does the following:
– create a thread that will wait for the SD card ready state
– the thread will do the following:
* open file: test1.txt in mode rwa(read, write, append)
* write a str defined (5 times)
* write a single character (5 times)
* read a string
* write ROSE using write_sd function (buff)
* read ROSE using read_sd function (buff)
* if an error is detected during write, the thread immediately terminates (ex of errors: disk full, file full, …)
* close the file

It is a very simple unit test, that gave me the control over the Sd card.

Test2: Sd card delay characterizer – write_sd

It consists of a producer/consumer model. A timer (producer) generates data (an msg of 32 bits) and posts it in the consumer (a thread) mailbox (queue, buffer) which fetches each time there is a new message in its mailbox and write it to the Sd card using buffer mode (f_write). In the end of this test, min, max and the average of writing to the Sd card are shown.

Test3: Sd card delay characterizer – write_str_sd

Same as test1, but the goal is to characterize the delay of writing a string.

 

So far, writing each msg alone took a lot of time. Of course, it is not the optimal way to do that but I wanted to see the results to get an idea of the performance then try to optimize. Understand how the Sd card operates in write mode is essential to try to optimize this delay.

In a nutshell, writing to Sd card is read-modify-write of the smallest unit which is the sector (512 bytes most commonly used value). So when initiating a write operation, the Sd card fetches a sector into RAM, modify it with respect to the data that should be written then flush it back to the Sd card (when calling f_flush or when closing the file). So one way to improve the performance is to initiate a write operation with respect to a buffer that has the size of a sector, which brings us to Test4.

Test4: Sd card delay characterizer – write_sd bulk mode

Same as test2 and 3, but instead of writing each message alone, the messages are buffered internally and a write operation is initiated each time 512 bytes were buffered. The improvement was pretty good (the results will be shown at the end of the post).

Test5: Simulation1

AmpeROSE operates in two modes: streaming mode and the standalone mode where the Sd card is actually used to store data. The producer’s frequency is set to 100us and the simulation is run during 10s (default). This test is important because it gives us an idea of the ~minimum mailbox size in order to process all msg and discard nothing. (producer is much faster than the consumer => data might be discarded if there is no place to put it). The result was pretty good, the consumer was able to handle all of the messages without any loss.

Test6: Simulation2

In reality, the max sampling frequency is 100K (10us). This test implements the producer/consumer model with respect to this value using a general purpose timer.

You may be wondering the use of a GPT instead of a virtual timer which is easier and faster in implementation. The is due to the VT limitations. Internally, the VT uses the systick to generate the interruption, the freq of the systick is set to 10K which gives an interruption each 100us. Even when specifying a period of 10us of a VT, internally it is rounded up to the nearest value which is in this case 100us. A possible way to use a VT, in this case, would be to tune the systick variable up, but it is discouraged to do that.

Therefore a GPT is indispensable to implement the real 10us. The result is not good, ~50% of data were lost even by allocating the maximum available size on the Olimex board. In the outputs, you will notice how the percentage of loss decreases when the size of the buffer increases.

And before showing you the results of the different tests, I also added a configuration.h file which gives us the ability to choose between 3 modes (DEBUG, TEST and SHELL modes).
These 3 modes make the development process much easier and by the way, I use SEGGER Real-time coz it is much easier to use by comparing to the shell.

However, in production mode, debugging and testing are not important, in fact, their use will impact the memory space and the overall performance of the system. Therefore, this configuration file permits to disable them in a very practical way.

Tests results

ChibiOS/RTOS initialization

SD connected!
Mounting FS…
FS mounted!
******** Beginning of Tests ********
******** Test1 (unit tests) ********

–> Test1.a: write a string and a character to SD card
File opened
Str successfully written
Chr successfully written
Str successfully written
Chr successfully written
Str successfully written
Chr successfully written
Str successfully written
Chr successfully written
Str successfully written
Chr successfully written
File closed

–> Test1.b: read a string from SD card
File opened
Reading a str from SD card…
Str successfully read
Read the following str: ROSE 2018: AmpeROSE

Reading a str from SD card…
Str successfully read
Read the following str: WROSE 2018: AmpeROSE

Reading a str from SD card…
Str successfully read
Read the following str: WROSE 2018: AmpeROSE

Reading a str from SD card…
Str successfully read
Read the following str: WROSE 2018: AmpeROSE

Reading a str from SD card…
Str successfully read
Read the following str: WROSE 2018: AmpeROSE

File closed

–> Test1.c: write a bunch of bytes to SD card
File opened
Written with success
File closed

–> Test1.d: read a bunch of bytes from SD card
File opened
Read with success
Buff[i (1->4) ]: R O S E
File closed

******* Test2 (Word 32bit) ********

File opened
Please wait…

Statistics about this test
* Buffer size = 3000 (96Kb)
* Generated samples = 2048
* Processed samples = 2048
* Discarded samples = 0
* Remaining samples (in buffer) = 0
* About write operation to SD card:
–> Number of writeSD operation = 2048
==> Min delay (us) = 3000
==> Max delay (us) = 46000
==> Average delay (us) = 4683
==> Total delay (us) = 9591300

File closed

******** Test3 (String) ********

File opened
Please wait…

Statistics about this test
* Processed messages = 2048
* Discarded messages = 0
* About write operation to SD card:
–> Number of writeSD operation = 2048
==> Min delay (us) = 3100
==> Max delay (us) = 54000
==> Average delay (us) = 4619
==> Total delay (us) = 9461300

File closed

******** Test4 (Block 512B) ********

File opened
Please wait…

Statistics about this test
* Buffer size = 3000 (96Kb)
* Generated samples = 2048
* Processed samples = 2048
* Discarded samples = 0
* Remaining samples (in buffer) = 0
* About write operation to SD card:
–> Number of writeSD operation = 16
==> Min delay (us) = 3000
==> Max delay (us) = 21000
==> Average delay (us) = 6175
==> Total delay (us) = 98800

File closed

******** Test5 (Simulation1 – Word) ********

File opened
Please wait…
Time is up, stopping simulation…
File closed

Statistics about this simulation (0min) (3s)
*Total time of execution (0min) (50s)
* Buffer size = 10000 (320Kb)
* Generated samples (by ADC) = 15000
* Processed samples = 10649
* Discarded samples = 4351
* Remaining samples (in buffer) = 0
* About write operation to SD card:
–> Number of writeSD operation = 10649
==> Min delay (us) = 3000
==> Max delay (us) = 94000
==> Average delay (us) = 4619
==> Total delay (us) = 49194100

******** Test6 (Simulation2 – Bulk) ********

File opened
Please wait…
File closed

Statistics about this simulation (0min) (1s)
* Buffer size = 2048 (65Kb)
* Generated samples (by ADC) = 100000
* Processed samples (written) = 27904
* Discarded samples = 72096
* Remaining samples (in buffer) = 0
* About write operation to SD card:
–> Number of writeSD operation = 218
==> Min delay (us) = 3000
==> Max delay (us) = 37000
==> Average delay (us) = 4872
==> Total delay (us) = 1062100

No more tests to run

******** End of Tests ********

ChibiOS/RTOS initialization

SD connected!
Mounting FS…
FS mounted!
******** Beginning of Tests ********
******** Test6 (Simulation2 – Bulk) ********

File opened
Please wait…
File closed

Statistics about this simulation (0min) (1s)
* Buffer size = 4096 (131Kb)
* Generated samples (by ADC) = 100000
* Processed samples (written) = 30208
* Discarded samples = 69792
* Remaining samples (in buffer) = 0
* About write operation to SD card:
–> Number of writeSD operation = 236
==> Min delay (us) = 3000
==> Max delay (us) = 33000
==> Average delay (us) = 4726
==> Total delay (us) = 1115500

No more tests to run

******** End of Tests ********

ChibiOS/RTOS initialization

SD connected!
Mounting FS…
FS mounted!
******** Beginning of Tests ********
******** Test6 (Simulation2 – Bulk) ********

File opened
Please wait…
File closed

Statistics about this simulation (0min) (1s)
* Buffer size = 10000 (320Kb)
* Generated samples (by ADC) = 100000
* Processed samples (written) = 35984
* Discarded samples = 64016
* Remaining samples (in buffer) = 0
* About write operation to SD card:
–> Number of writeSD operation = 282
==> Min delay (us) = 2000
==> Max delay (us) = 39000
==> Average delay (us) = 4779
==> Total delay (us) = 1347700

No more tests to run

******** End of Tests ********

That’s all.

[AmpeROSE] Insomnia….

Good evening everyone,

This week, I was in charge of schematics, I started by reviewing the microcontroller and the digital circuits, then, I worked on the analog circuits, typically, the automatic switching calibration, the ADC, the current-voltage conversion and the selector DUT/MIR.

In terms of the power supply, I compiled a list of the different reference voltages that will be used along with the different components. As you may know,  our project relies on having a super clean power supply and minimize the noise to get good results and good precision. Therefore, the design consists of separating the power supply of the digital and analog circuits. Alexis Polti will help us to design and get such a clean power supply so a big thanks for him.

In terms of PCB, yesterday, I started working on it alongside Abdelhadi and Michel. We started by the ethernet module and after two days of sleep deprevation, we finalized the digital circuit. Routing the analog circuit is going to be a !$&^!$^!*$!*$&@ (PS: it is a bad word), and we hope to be able to finish it by 5 am.

See you next week,

[AmpeRose] And yet another problem… Experts… A word…

Hello,

So, in previous posts, we’ve shown you the results of simulating Switches, initial calibration, automatic calibration sub-system, etc. In addition, we’ve talked about some problems and how we’ve approached them and shared the results with you. However, we are still having a little problem, let’s see what’s happening… The origin of the problem is the DUT itself, to be more precise, it’s the decoupling capacitors that are bothering us. Yesterday, we showed you (In this post) that  a decoupling capacitor must be used by the DUT to ensure that we do not have a big voltage drop in case of a very fast transition between current ranges. This guarantees that the DUT will always be powered up.

Now, we’re getting closer to the problem.

Problem Statement

A negative current is being fed to AmpeRose by the decoupling capacitors during fast current transitions, therefore delaying the stabilisation of the op amp output.

Remember that we’re sampling each 10 us. That being said, a lot of samples would need to be discarded (~ 70) before voltage stabilization.

What do we want?

We want to block the current flowing from the decoupling capacitor of the DUT, easy, let’s use a diode.

Not that easy! In fact, an ideal diode would have definitely solved our problem(?), because it allows the current to flow in one direction only and does not consume any voltage (drop voltage = 0). However, such a diode does not exist… 🙁

Different solutions

Constructors (Linear tech, Maxim,…) provide different near-ideal diode solutions. However, the drop voltage is still huge, and therefore not suitable for our needs.

Well, I hope I made the problem clear… If you have any questions or clarification requests, we’re here to answer… And, it goes without saying… We’re open for any and all suggestions.

Thank you.

[AmpeRose] Believe it or not, STM32CubeMX wasn’t able to find a solution at full speed clock, but guess what, I did it…

Good evening everyone,

This week, I worked on schematics, simulation and power supply.

I started by reviewing the configuration of the STM32F767 microprocessor that is going to be used in our project. I used the STM32CubeMX software to review the pin assignments, check for potential conflicts.

In addition, one of the important aspect of this software is the clock configuration. Manually configuring it wouldn’t be an easy task though.

However, it’s not always possible to find an automatic solution using this software because there are a lot of constraints to take into consideration, lucky me, that was the case.

Eventually, I managed to manually configure the clock at full speed (spoiler 216MHz 🙂 ) and respect all different constraints. Yes I did it and I hate STM32CubeMX for that :).

In terms of schematics, I also reviewed them:  finalized the configuration of the microprocessor, removed some the unused pull down resistors in the ethernet schema in order to use less components and simplify the routing.

To have an idea of our full consumption, thus designing the right decoupling capacitors, I compiled a list that specifies the consumption of each component. The list is not fully complete yet because there has been some changes in some components, so I will finalize it when we choose the appropriate components that suit our needs.

Also, during this week, I joined the team and did some simulations in order to try to minimize the full drop voltage that occurs during the 100ns that corresponds more or less to the op amp response time. After all, the solution was to design an suitable decoupling capacitor that will maintain the voltage across the DUT.

Stay stuned,

See you next week.

[AmpeRose] Switching…

Hello, everyone!

In this post, I’m going to talk about the switches and the problems encountered and most importantly, how we approached these problems.

The switches are used to switch between different ranges. By acting on the switches, the value of the equivalent resistance changes, so the range changes as well.

Switches – problems

The simulation under LTspice takes into account the real model of the components thus making it possible to study the behavior of the system and to anticipate possible problems.

Ideal model In order to switch between the ranges, PMOS transistors are used.

VG = VCC => passing state

VG = GND => blocking state. 

In order to test the real behavior of the transistors, we consider the following schema:

For an ideal model we obtain the following results:

The results are in line with the expected values.

Simulated transistors

Among the transistors that have been simulated:

  • DMG3415U
  • DMP2035U
  • BSS84

In the following, we will see the results of the simulation of the first transistor, DMG3415U. This transistor has an ON resistance of 42.5mΩ and a leakage current of 1nA (for a temperature 25C).

Although the overshoot and undershoot can be accepted (very short duration), the real problem is that, after the undershoot, we never arrive at the expected value.  And this behavior is really catastrophic, since the voltage at the input of the ADC will not be the expected value.

In order to fully understand the cause of the problem, we embarked on an in-depth research into the mosfet transistor model.

A deeper look inside Mosfet Transistor

Let’s consider the following simplified model of a mosfet transistor:

RDS(on) – On Resistance T

This is the total resistance between the drain and source in a mosfet transistor. RDS(on) is the basis for a maximum current rating of the MOSFET and is also associated with current loss. So RDS(on) is not zero, therefore, it must be taken into consideration because a big resistance causes huge problems with respect to the lowest shunt resistor (~mOhm). Thus, the lower RDS(on), the better.

Intrinsic capacitances

Cgs, Cgd and Cds are the intrinsic capacitances. They are unwanted capacitances, but still are part of the transistor. Together with the resistance in the circuit, they put an upper limit to the speed of the transistor.

Ciss, Input Capacitance

This is the input capacitance measured between the gate and source terminals with the drain shorted to the source for AC signals.

Ciss = C gs + Cgd

The input capacitance must be charged to the threshold voltage before the device begins to turn on, and discharged to the plateau voltage before the device turns off. Therefore, the impedance of the drive circuitry and Ciss have a direct effect on the turn on and turn off delays.

Coss – Output Capacitance

This is the output capacitance measured between the drain and source terminals with the gate shorted to the source for AC voltages.

Coss = Cds +Cgd.

For soft switching applications, Coss is important because it can affect the resonance of the circuit.

Crss – Reverse Transfer Capacitance

This is the reverse transfer capacitance measured between the drain and gate terminals with the source connected to ground.

Crss = Cgd.

The reverse transfer capacitance, often referred to as the Miller capacitance, is one of the major parameters affecting voltage rise and fall times during switching. It also affects the turn-off delay time.

Miller effect in a nutshell

The Miller effect is a special case of the Miller theorem when the impedance element (connected between the amp’s input and output) is a capacitor.

This effect leads to an increase in the input capacitance.The consequence is slowing down the transition and increasing the propagation delay time.

Spurious oscillation

MOSFETs are capable of switching large amounts of current in incredibly short times. Their inputs are also relatively high impedance, which can lead to stability problems. Under certain conditions high voltage MOSFET devices can oscillate at very high frequencies due to stray inductance and capacitance in the surrounding circuit.

Inductances

The connections with the circuit exhibit a parasitic inductance, which is in no way specific to the MOSFET technology, but has important effects because of the high commutation speeds. Parasitic inductances tend to maintain their current constant and generate overvoltage during the transistor turn off, resulting in increasing commutation losses.

A parasitic inductance can be associated with each terminal of the MOSFET. They have different effects:

  • the gate inductance and the input capacitance of the transistor can constitute an oscillator. This must be avoided as it results in very high commutation losses (up to the destruction of the device)
  • the drain inductance tends to reduce the drain voltage when the MOSFET turns on, so it reduces turn on losses. However, as it creates an overvoltage during turn-off, it increases turn-off losses.
  • the source parasitic inductance has the same behaviour as the drain inductance, plus a feedback effect that makes commutation last longer, thus increasing commutation losses.

References

In conclusion, it is the intrinsic parasitic capacitances that come into play when measuring low current.

Switches – solutions

We saw that several parameters come into play when we want to select a mosfet transistor, this choice of course, depends on the type of application. The manufacturer provides in its datasheet, the values ​​of the various parameters:

  • RD (on)
  • Ciss
  • Coss
  • Crss
  • I leakage
  • 6 …

We  want a transistor with weak resistance, current leakage and capacitance. However, it was impossible to find such a transistor which met all these parameters.

Here is a compiled list of the most interesting transistors we’ve found:

  • DMG3415U
  • DMP2035U
  • BSS84
  • RRQ030P03
  • NextPowerS3
  • CSD25501F3

The solution to this problem is not to find the transistor having a minimum parasitic capacitance (although it would be very useful) because it is insufficient.

Several solutions were considered:

  • Using Load Switches (ADG801)
  • Configuration Change (Shunt resistors in series and the transistor will be in parallel)

The most realistic solution is therefore to try to manipulate the parameter R (in τ = RC) and not only the parameter C.

Current range

In the previous posts, it has already been established that there will be 4 current ranges, here is a quick recap:

  • 739 µA    →    303 mA
  • 7.39 µA   →    3,03 mA
  • 73.9 nA   →    30,3 µA
  • 1 nA        →    303 nA

The fourth range is not part of the AmpeRose specification, since the latter is designed to measure very low currents of the order of a few hundred nA which correspond well to the consumption of some embedded systems operating in standby mode.

Therefore, the current range was updated as follows:

  • 100uA − 300mA
  • 1uA     − 3mA
  • 10nA   − 30uA

Note that by reducing the number of ranges (4 -> 3), we also reduce the value of the largest resistance, therefore, improve the response after closing the switch.


[AmpeRose] Down from 10MHZ to 100KHZ

Hello everyone,

Sampling frequency is one the most important factor in AmpeRose, therefore it must be well characterized and well defined. In this post, I will show you how we passed from a 10 MHz frequency down to 100 KHz.

Introduction

AmpeRose is not made to measure current consumption of any existing device. In fact, it targets a very specific range of connected devices. It is only concerned by those which are low consumption. In order to profile an IoT device, it is necessary to study the maximum current required by its modules, typically, the communication module which consumes the majority of current. As examples of communication modules:

  • BLE
  • Lora
  • Wifi
  • Zigbee
  • Etc…

BLE (Bluetooth Low Energy)

Bluetooth Low Energy is an alternative to classic Bluetooth, with reduced cost and power consumption, while maintaining an equivalent range of communication.
BLE seeks to address devices with low computing power, low cost of production and life expectancy is to maximize. The idea is to reduce their activity time compared to devices based on classic Bluetooth. Raw performance such as the beginning of transmission will therefore naturally be affected.

  • Main features
Distance/range 50m
Over the air data rate 1 Mbit/s
throughput 0.27 Mbit/s
Latency(from a non-connected state) ~6 ms
Total time to send data < 3ms
Peak current consumption < 6 ms
  • Smallest activation time

                  According to https://www.eetimes.com/document.asp?doc_id=1278927, the shortest package would have 80 bits that would require 80 us to transmit it.

Lora

LoRa technology is designed for low-power wide area network (LPWAN) applications. It has a range of more than 15 kilometers and a capacity of up to 1 million nodes. The combination of low power consumption and long range limits the maximum data rate to 50 kilobits per second (Kbps).

  • Main features
Distance/range 15 km
Data rate 50 kb/s
Total time to send data (average) < 300ms
Power consumption during transmission < 40 mA
Average current consumption (active) 10 uA
  • Smallest activation time

          According to:

                       – https://www.link-labs.com/hubfs/DOCS.linklabs.com/2017/01/lora-scalability_r254.pdf

                       – http://www.semtech.com/images/datasheet/sx1272.pdf

         the shortest packet would have 16 bits that would require 320 us to transmit it.

Wifi

WiFi is an obvious choice for IoT connectivity because WiFi coverage is now almost ubiquitous, but it’s not always the right choice.

The WiFi standard, while being the obvious choice for IoT, has limits in terms of range and energy efficiency. To meet these requirements, the IEEE has published specifications for standards
–  802.11ah
–  802.11ax

  • Wifi HaLow 802.11ah

WiFi HaLow technology is based on the IEEE 802.11 ah standard ratified in October 2016. It was introduced specifically to address IoT’s range and power concerns. The 802.11ah standard uses the 900 MHz ISM unlicensed band to provide extended reach with low power requirements. The use of power is further optimized by using predefined periods of sleep / slumber and achieves a radius of one kilometer. In addition, it requires a separate infrastructure (compared to the WiFi standard) and specialized clients.

  • HEW (High Efficiency Wirless) 802. 11 ax

This technology also adds a number of user-friendly features for IoTs. It retains targeted wake up time and 802.11ah station pooling capabilities to help customers save energy and avoid collisions. This technology holds many promise for use as a means of communication in IoT.

  • Smallest activation time: 802.11 ah

         According to https://www.researchgate.net/publication/301776005_Throughput_and_Range_Characterization_of_IEEE_80211ah,

        the shortest packet would require (160 + 264 + 560) us = 984 us to transmit it considering delta = transmission delay as zero.

  • Smallest activation time: 802.11 ax

        According to https://www.researchgate.net/publication/313844761_AP-initiated_Multi-User_Transmissions_in_IEEE_80211ax_WLANs,

        the shortest package would require ~ 168 us to transmit it while only considering the physical header and neglecting the other parameters.

 

Zigbee

Zigbee is designed to meet the requirements of communication between devices. It is a specification that is built on top of the IEEE 802.15.4, communication standard. Zigbee is intended for low flow, low power and low cost applications. For this reason, it is much simpler than other protocols such as WiFi (IEEE 802.11).

  • Main features
Distance/range 10 m
Data rate 250 kb/s
Total time to send data (average) < 300ms
Power consumption during transmission < 30 mA
Power consumption during standby 350 uA
  • Smallest activation time

         According to

                  – http://voip.netlab.uky.edu/~fei/teaching/cs687_smartgrid/slides/3.zigbee.pdf

                  – http://www.springer.com/cda/content/document/cda_downloaddocument/9783319478050-c2.pdf?SGWID=0-0-45-1593332-p180328094

         the shortest package would require 352 us to transmit it.

 

Conclusion

According to this study, we can see that BLE technology has the smallest activation time of 80 us. Therefore, in order to detect the current consumption during this activation time, we must sample at F= 1/80us = 12.5 KHZ at least. However, by including a margin error, we will therefore sample at 100 Khz at least (smallest activation time : ~ 20 us and respect of Nyquist criterion Fe >= 2fmax).