Categories

[AmpeROSE] How to discover the AmpeROSE device?

Hi everybody,

As you can expect, here we are going to see how the AmpeROSE could be discovered by the software on the computer. We thought of 2 ways to do that. The first way consists in using the Zeroconf technologies and the second one is our solution using an UDP server on the AmpeROSE.

  1. Zeroconf : The Zeroconf (or Zero-configuration networking) is a providing 3 technologies: the IP address assignations (1), the name resolution (2) and the services discovery (3). The first two technologies are usually done, respectively, by a DHCP server and a DNS server but the Zeroconf does it without any servers. In our application, we would not be using the address assignation since we suppose that a DHCP server will be available but we would use the two other services. In fact, we need only to implement the second part because the service discovery is done by the computer. To implement the name resolution, there are 2 protocols: the multicast DNS (mDNS) and the Link-local Multicast Name Resolution (LLMNR) respectively developed by Apple and Microsoft. If we choose to do it, we will use the mDNS since it is the most used.
  2. UDP server : If we take this option, we will implement a simple udp server on the AmpeROSE responding to a specific broadcast by a message giving its name.

We did not decide which one will be used but here are some of the pros and cons of these solutions:

Pros Cons
Zeroconf Compatible with a widely used protocol. Only partial implementation available.
UDP server Simple implementation. Not standard.

 

We need to discuss this a little more but if you have suggestions about that feel free to leave a comment J

[AmpeROSE] Field-Programmable Gate Amperose

Hello everyone,

In this post I’d like to elaborate on how AmpeROSE’s FPGA component will operate, in the configuration where it actively participates in the automatic calibration and data acquisition. You may also want to refer to my previous post on this subject.

Automatic Calibration

When we were performing SPICE simulations of our measurement circuit, we observed the following phenomenon that led us away from thinking of implementing the calibration logic as a synchronous state machine (namely, a bidirectional shift register):

  • If the frequency of the clock driving the state machine was too elevated (>1MHz), the output of any comparators going high would very often cause the state machine to go to the corresponding extreme measurement range, even when stopping at the middle range would be the correct thing to do. This, in turn, caused the other comparator output to go high, and the state machine would oscillate. The cause of this exagerated reaction was that the state machine performed the second change in calibration before the rest of the circuit had time to properly react to the first change, and reach a new burden voltage corresponding to the current measurement range.
  • On the other hand, if the clock frequency was reduced to allow for the reaction time of the circuit after a state change (according to our simulations, about 2.5 us on the worst case, owing to the capacitances of the switches in the shunt selector), then a sudden peak in burden voltage that happened to take place just after a rising clock edge would go untreated for a very long time.

There is actually a way to address these issues without abandoning the idea of a synchronous implementation: a state machine clocked at a high frequency, which allows for a short reaction time, associated with a down-counter. Whenever a state change occurs, the down-counter is loaded with a value proportional to the reaction time allowed to the circuit, and further state changes are blocked up until the counter reaches 0. This is the strategy that I followed for implementing our calibration logic in SystemVerilog.

In terms of what exactly is the “high frequency” that should be used to clock our state machine and the counter, we calculated that in most extreme situation that still falls in our expected operating conditions (up to 300 mA drawn by the device under test (DUT), which has a bulk capacitance of 500nF) the DUT’s bulk capacitance should be able to hold the drop in the DUT’s supply voltage under 1V for about 1.66us, so we should, at the very least, react faster than this. Fortunately, Quartus indicates that maximum clock frequency for the current version of the calibration circuit is 111MHz, so we should be able to even approach the reaction time of our hardware comparators (5ns) if this proves to be necessary.

Regarding how the clock will be supplied to the calibration state machine, one of the dedicated clock inputs for the FPGA is connected to a pin of the uC which can be configured as the master clock of a Serial Audio Interface. Such a master clock signal can receive the output of the uC’s PLLI2S phase-locked loop, which we are not otherwise using in our design. This affords us a great flexibility in terms of choosing the clock frequency.

Context bits and SPI

When our external ADC signals that a new measurement is available, the FPGA “takes a snapshot” of the calibration state, of the context bits and of a bit indicating whether the calibration changed since the last measurement (which is then reset), and places it in an 8-bit register.

The “data ready” signal from the ADC is also transported to the microcontroller (uC), which should begin a SPI read of 32 bits. For the first 24 bits, the FPGA simply transports the signals between the uC and the ADC, so the 24-bit voltage measurement can be read. For the last eight bits, on the other hand, the FPGA inserts the bits from the “snapshot” on the MISO line, one per cycle of the serial clock. Thus, the uC receives the complete set of 32 bits corresponding the measurement (24 for the voltage measurement, 5 for the context and 3 for the automatic calibration) by the end of the SPI read.

How to test it all

I put together a straightforward testbench using Verilator and systemC. This testbench has simple systemC threads and methods playing the role of the components of the system (ADC, uC, comparators) which communicate through signals between themselves and to a systemC model of our FPGA, generated by Verilator from the SystemVerilog code.

Periodically, the uC thread determines a 32-bit measurement that should be obtained, and communicates it to the other threads, which cooperate to create the conditions for it to be produced (the ADC thread signals that is has completed its measurement and sends the most significant 24 bits of the 32, the comparators method react to the switch outputs of the FPGA model as if the correct range to be reached is the one described by the two least significant bits of the 32, etc.).

When the adc thread signals that a measurement is ready, the uC thread performs a SPI read, where the FPGA model plays the role described in the previous section. If the 32 bit reading obtained from this transaction is different from what was expected, the simulation returns an error. This testbench is currently passed by the SystemVerilog code.

How to proceed from here

The next immediate steps would be to improve the testbench to make it more realistic, and then to test the SystemVerilog code using a real FPGA and a microcontroller, such as the DE1-SoC boards present in our lab and our development board, respectively. After we receive our PCB, we should strive test it with our actual uC and FPGA as soon as possible.

[AmpeRose] A finger in every pie

Hello everyone,

As always this post of mine is long overdue, but to catch up on the delay, I’m gonna try to squeeze what I want to say into this one post. Here goes…

Holidays With The PCB

In the week before the holidays, and during the first week of said holidays, (Merry Christmas and happy new year, by the way!) I worked on verifying our schematics for the PCB, with the rest of my team, and I did the placement and routing of our PCB.

However, since our PCB’s design is very delicate, and very prone to being messed up by small details like distance between components, one of our professors, Alex Polti, redid the analog circuit and part of the digital circuit. So let’s give him a shout-out folks!

Minor adjustments were in order because some parts we needed for the pcb went out of stock, but this didn’t have a major impact on the circuit.

 

After The Holidays, The GUI Days

In the second part of the holidays, and all the way up to this week, I’ve been working with Abdelhadi on our PC software. We’ve faced many challenges, some of which were quite difficult. I’m not gonna talk a lot about this because Abdelhadi has already covered it in his post. I structured our code, and wrote some of the backend and view levels, as well as a trial for the USB and a few tests, while Abdelhadi worked the interface and the ethernet connection, along with a nice emulator. We have a basic working UI now, and are working on bettering it. We are also planning on changing the DataView level, because it’s proving to be very stiff and problematic to deal with: It isn’t allowing for easy control of the triggers, and the data retrieval functions implemented inside are very limited, and allow for so very little control.

This week, I’ve done a fast check on Bilal’s code for our microcontroller’s code. He’s done a pretty neat job of writing a simple API for us to use. Momo’s already reviewed and changed some things in this code, and I’m currently reviewing it one last time.

One more thing I’ve been doing during this time is updating our environment. This includes creating a new docker image for our CI as well as updating our CI pipelines and makefiles.

 

Upcoming Week, Upcoming Work

For the upcoming week, I’m planning on fully reviewing the C code, as well as the FPGA’s code. We’re planning on merging our work on our master branch to close a “few” PSSC issues.

But most of all, I’m impatiently waiting to get my hands on the PCB so that we could test it, and get it working.

 

We’ll keep you posted guys,

Michel

[AmpeROSE] User Interface

Hello everyone,

Lately I was working on the User Interface. The software that will run on the PC must receive measurements from AmpeRose, send commands to AmpeRose (through Ethernet or USB) and display the received measurements in the UI. The user can decide if he wants to display all the data he received, display the data that satisfies a certain trigger, display the spectrum … Another critical role of the PC software is data correction. During the initial phase, all the calibration data will be sent to PC and during the normal stream of measurements, the software will correct the received measurements accordingly.

In a previous post, we presented the class diagrams that will be implemented. As a first step, Michel & I implemented the skeleton (with some modifications judged necessary). As discussed in the mentioned post, the software has 3 main components:

Back-end

The back-end will handle all the connections with AmpeRose. It must implement 2 main methods: Send Command and Receive Measurement.

In order to implement these methods, I had to implement first the Ethernet Connection class. Since AmpeRose will be the server of two TCP connections (Data – Commands), the PC software will then implement 2 TCP clients that run in 2 different threads. Ethernet receiver will read packets of measurements and place them in a queue. Ethernet sender will read from the commands queue and send them to AmpeRose.

The words sent / received in the connection component of the back-end are raw 32 bit words that currently have no significance. That’s why we have to implement a command translator and a data translator. The command translator will make a mapping between 32 bit words and commands we defined in our protocol. The data translator will take the 32 bit words and extract the value, caliber and GPIO status.

The final component of the back-end is the Data Corrector. The data corrector implements 2 methods. The first will add calibration measurements and the second will apply the correction on a given measurement. We are planning to use a linear regression for correction however this component is not implemented yet.

To sum up, in order to send a command we will have to translate it first (using Command Translator) and send it then to AmpeRose using the chosen connection (by placing it in the commands queue in the Ethernet case and the Ethernet sender thread will then get the command from the queue and send it). In order to receive a measurement, we will read a value from the chosen connection (in the Ethernet case, we will read from the queue filled by the Ethernet receiver thread). The read value will be then expanded into useful information and the correction will be applied. In order to test these functionalities, I wrote a simple AmpeRose emulator and we can successfully send commands and receive measurements (generated with a frequency of 100KHz).

Data View

Data view is an intermediary layer between back-end and the main UI. It handles how this data will be viewed. In this class we can chose the view mode: Normal View Mode where data are viewed as a normal continuous stream – Trigger View Mode where only data that obey to a certain trigger are shown. (We can also chose the trigger that will be applied: a threshold – a certain slope …). The main thread of the data view calls the receive measurement of the back-end and store the data in a data container with a capacity specified by the user.

User Interface

Unlike what I thought, the graph display of the received measurements turned out to be the trickiest part of the PC software. The UI is composed of 2 main parts: Control and Graph (as planned in this post). The user will control when he wants to start and stop the acquisition and how the data will be displayed. Initially, in the case of many connected components AmpeRose, the user will also chose to which specific one he wants to connect.

The tricky part is how we are going to display 100,000 points / second. Receiving the measurements at this rate is not a problem however displaying them is. In the current version we are applying a down-sampling and once we zoom in more and more points will be restored. PyQtGraph (the library we are using) supports 3 methods for down-sampling: ‘subsample’ where we take the first of N samples, ‘mean’ where we calculate the mean of N samples and ‘peak’ where we down-sample by drawing a saw wave that follows the min and max of the original data. For now we are using the ‘peak’ method because we are interested in the extreme values.

Next Week

For now, we have a basic working UI ready to be used with the micro-controller. The UI for now can start and stop acquisition, receive measurements and display them. This week I will continue working on the UI. I will start by the implementation of the data correction and statistics. I already implemented the trigger view mode but it needs a lot of improvements that I will work on too. I will try to improve the performance of the graph display (Normally the down-sampling calculations are done in the main thread that may cause lagging when more and more data are received that’s why I will try to implement the down-sampling in a separate thread). Finally, on another note, if we receive our card this week I will also work on testing it.

Until next week 🙂

 

[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] Recalibrating our Architecture

Hello, everyone!

In this post, I’d like to discuss a final significant change that our architecture for AmpeROSE underwent in the end of December.

The calibration problem

As you may recall, a fundamental task for AmpeROSE is to perform “automatic calibration”, controlling in real time the value of its shunt resistance, which is used to convert the current drawn by the device under test (DUT) into a tension that is amplified and measured by an ADC. Each possible value for the shunt corresponds to a range of current values that may be effectively measured with it. Having an inadequate shunt value at a given time can cause the following negative consequences:

  1. If the current is too small for the shunt (there’s a larger available value for the shunt that we should be using), we lose precision.
  2. If the current is too big for the shunt (there’s a smaller available value for the shunt that we should be using), we lose measurements, as the reading will just be stuck at the maximum value for the measurement range corresponding to the current shunt. More importantly, we risk having a brownout on the DUT if the burden voltage becomes large and the situation persists for longer than the DUT’s power supply circuit can handle.

You may consult these two previous posts (1, 2) to review our process for arriving at the automatic calibration scheme we initially based our schematics and PCB design on. Here is a high-level view of it, with the calibration circuit in the center:

In this configuration, hardware comparators are used to generate signals that indicate whenever the amplified shunt voltage has surpassed the upper limit for the current measurement range (VIN>VON), or gone below its lower limit (VIN<VOFF). A third comparator determines whether the burden voltage (voltage on the shunts) has surpassed its maximum allowable value, its output being ALERT. These outputs are fed into a circuit composed of discrete ICS (NAND and NOT gates, SR latches and delay blocks) that implements the calibration logic and generated two outputs (SW1 and SW2) which contror transistor switches which may be used to connect and disconnect resistor in parallel with the shunt, thus changing its value.

In this configuration, it is the microcontoller’s job to read each mesurement from the ADC when it’s ready, through SPI, and sample values of the calibration outputs and of the context bits to associate with the measurement. It also determines the reference voltages for the comparators using its digital to analog converters and controlling a potentiometer.

In the course of the elaboration of our printed circuit board (PCB), this approach for the calibration circuit proved to be problematic, in particular the placing and routing of the different ICs, some of them containing several logic gates that would , not to mention the difficulty of reasoning about the timing of the logic signals. More importantly, the calibration logic would be locked into what is determined by the discrete ICs placed on the PCB, and would be impossible to correct if tests with the finished PCB revealed that corrections would be in order.

In view of these issues, our supervisors encouraged us to consider two alternative approaches that would grant us more flexibility and could be implemented more expediently:

Calibrate using a FPGA

This approach uses a small field-programmable gate array – FPGA (small in terms of package size/pin numbers, and in terms of number of interal logic cells) to implement the calibration logic and generate the SWx outputs. The calibration circuit would be described using a hardware description language such as SystemVerilog, which we have employed often in our embedded systems education, and could be corrected by reprogramming the FPGA through JTAG.

Additionally, we envision using the fpga to read the ADC measurement and the context bits, and prepare and transmit the complete measurement word to the microcontroller though SPI.

Calibrate using the microcontroller

In this approach the outputs of the comparators would be connected to microcontroller pins and would generate fast interrupts, whose service routines would implement the calibration logic and update the shunt control signals.

This design has the advantage of simplifying even more the PCB, and would take advantage of the relatively powerful microcontroller we’re using in our design. On the other hand, performing the calibration does represents a significant burden on microntroller if compared with the circuit with the FPGA, especially because it will also be managing an Ethernet connection.

And the winner is…

Neither! I mean, both! Our PCB will contain a MAX3000A fpga with 44 pins and 64 macrocells, but the components have been placed and routed in such a way that it will be possible to implement either of the designs present above in the PCB, just by reprogramming the microcontroller and the FPGA. The calibration using the FPGA will work essentially as described previously, while for the calibration using the microcontroller, the FPGA will be programmed to simply transmit signals transperantly between the microcontroller and other components in the board.

This strategy will allow us to evaluate the feasibility of both strategies, with the goal of determining which would be more interesting for a more mature version of AmpeROSE. I’m currently working on the SystemVerilog code for the calibration using FPGA, which should then be simulated and tested so we can be confident it’s likely to work when we receive our PCB.

[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] Simulation of initial calibration

Hello everyone!

This time, we are going to talk about the simulation, especially, some simulation that helps to see how we will do the initial calibration.

First, the full simulated circuit is the following one:

On the top left, there is the current mirror, then in the centre to the right there is the part of the circuit that allows to do the current-to-voltage conversion and a model of the DUT (device under test composed by a battery of 5V and a resistive charge associated to a decoupling capacitor). At the bottom, there is on the left the amplification and then the filter in the middle.  The last element on the right is the simulation of the signals that allows to control the shunts.

Here are some interesting measurements done on this circuit:

At the bottom there is the current generated by the current mirror in the measurement stage. As you can see, it as the form of a pulse, the on level is 2mA. Just above, there are the command signals of the shunts.

Here, we will focus on two times, each being represented by the vertical dotted lines. The first one correspond to the case where the second shunt is activated, so we have current flowing through the shunt 2 and 3. And the second case correspond to all shunts being used.

On the plot above, the signal represented is the output signal on which some computation where done. The formula is the following one: (VFILTER – Voffset) / (100 * 2m). So the first step is the subtraction, we remove the offsets introduced by the amplifiers. It is not represented here but we can measure it, we just have to measure VFILTER when there is no current flowing into the shunts. Then there is a division by 100 which is the amplification and 2m which is the value of the current at our points of interests here. As you may have guessed, this curve allows us to deduce the real resistances of the shunts including the values of the resistances of the transistors. At the first cursor, we can observe that the resistance is 10.002891 Ω and the second give us the value of 176.87423 mΩ.

Then, we can use these values while measuring that what was done on the first plot. We use the following formula: (VFILTER – Voffset) / (100 * Res). So here again, there is the correction of the offset and then the division by the amplification and the value of the resistance, 10. 002891 Ω at the first cursor and 176.87423 mΩ at the second cursor. And as you can see on the plot, the value deduced back is 2mA in both cases which is the actual current flowing.

As you saw here, we have a good faith in our system, now, it will be harder to do exactly the same thing as here. The main reason is that the measurement will be done through an ADC. The results is that the offset may be less precise for example. There is also the fact that resistors will have errors on theirs values, so we may need to verify the value of the amplification. We also may have an error on the current generated. So even though these results are promising, we will have a lot to do in our software to do a good initial calibration.

[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] A little bit of everything

Hello,

Last week I was supposed to start working on the UI that will receive data from Amperose and display them. However since we were finalizing the design of our circuit and its schematics, I had to work on other tasks (Given that finishing the PCB has the highest priority).

First of all, we solved the last few problems we faced (with the help of M. Polti) so Momo and I worked on the simulations (LTSpice again 🙁 ) to make sure we have an operating circuit.

Second, since the schematics were done, every single member had to review the schematics to find all the errors. Reviewing the schematics includes reviewing ALL the datasheets of the elements we used.

Right now, while my teammates are working on the PCB, I am helping them with the switching circuitry. I am trying to distribute the logical elements packaging and pins to make routing easier. I am still far from finding the optimal assignment but there are a lot of advancements.

Back to my original task, when I was not working on the previous tasks, I started implementing – with the help of Michel – the class diagram he made for the backend of UI. As for the display part, since we are going to use PyQtGraph, I followed the given examples and I wrote some myself to get familiar with this awesome library. In addition I implemented a simple server – client program. The server (UI) makes a broadcast to find a client listening on a specific port (Amperose). Then a connection between them is established, and the client code starts sending random numbers. The server reads these numbers and displays them on a graph. Nothing too fancy, but still useful.

This week, after we finish the PCB, I will go back to my original task and get it working by the end of the week.