2017

Embsys meetings usually take place each wednesday at 20 o'clock on jitsi.

Everyone is welcomed.

2017.06.14 - HD - 20.00 (Paris time)

  • There's a real need for documentation --> @eiffel will do what he can and make us happy ;-)

2017.05.10 - HD - 20.00 (Paris time)

Polytech

Analog

All PCB files are now together to form a unique PCB file.

The routing and the choice of the CMOS components need to be done.

DMA

When the ADC is connected to the DMA IP the software indicates that there is a problem between the two clocks of the components. But the two components are clocked at 125 MHz.

This problem will be investigated.

PIC32

The work on PIC32 is abandoned, all tries were unsuccessful.

2017.05.03 - HD - 20.00 (Paris time)

Polytech

DMA

Without DMA, all memory transfers linked to a device have to be handled by the CPU (with load an store instructions). A device which has a DMA capability can move data by itself.

Polytech team gets a DMA IP developed by Vivado but due to some incompabilities it does not work on the RedPitaya. They are trying to adapt the IP for the RedPitaya's FPGA.

Analog

Band-pass filter was replaced by an active filter.

The simple envelop detector was replaced by a better one which works on the optimal part of the signal.

PCB

All KiCAD files are gathered in a big unique file which will be used to get the unique PCB.

PIC32

A member of Polytech team is working on the PIC32 microcontroller.

2017.04.26 - HD - 20.00 (Paris time)

Polytech

The acquisition block is finished (congratulations :) ).

The Polytech team wants to design storage blocks (for example a RAM IP) but their teacher advices them to design a Direct Memory Access (DMA) IP.

With the DMA capability, the FPGA can write data directly in the main memory used by the processor. \@eiffel thinks that it is a really good idea but he also thinks that the performances can maybe be limited by the bus used to access the main memory.

The bandwith of this solution should be about 100 Mbps.

2017.04.19 - HD - 20.00 (Paris time)

Current work

\@alister implemented an envelope detection IP on FPGA. The signal which is treated is generated by an arduino.

We will try to replace the Red Pitaya.

We can divide the architecture in two imprecise parts:

  • an analog part,
  • an other part which send data with wifi,

Analog part and signal

We need to define the inputs and the outputs of our system.

To treat the analog part we have to find an ADC and the circuit which comes with.
The bitwidth of the ADC must be determined.

However \@lecoued precised that the application currently deals with 14 bits signals.

Wi-Fi

For the wifi there are two possibilites :

  • using a micro-controller (like ESP32) which will send the picture and can also control the motors,
  • using a general purpose CPU with an OS

2017.03.22 - HD - 20.00 (Paris time)

Actual work

\@polytech-vikenesh and \@polytech-kevin work on numerical data acquisition on FPGA.

\@polytech-nivertan and @polytech-unknown (sorry I did not well unsertand your name...) work on analogic and envelop detection.
They try to get the negative part of the signal and to optimize analogic circuits which are on github (where ?).

Polytech's students suggest a circuit which permits to lose less signal than a diode bridge.

\@jerome works actually on a passive RLC which is poorly configurable, moreover the signal can not be boosted.
Polytech's students work on an active circuit which uses operationnal amplifiers.

Next work

We need to investigate how the numeric packets will be send.

Impotant points

The bottleneck is not clear it needs to be profiled.

\@luc said that during the march 2016 demonstration at Hôtel-Dieu the acquisition was made at 8 frames per second but I often heard that the Red Pitaya only gives 2 frames per second. It is not clear.

2017.03.01 - HD - 20.00 (Paris time)

Design

Polytech-team

Focus on two topics :

  • Design a unique PCB + miniaturization. \@eiffel notices that the Clarius uses 4 PCB : do we really need a unique PCB ? However, with several piled PCB, component shielding must be handled
  • Improve acquisition/treatment in the RedPitaya : design an intellectual property (IP) in VHDL for the acquisition, implement numerical envelope detection (double FFT) in VHDL (currently implemented in C)

Remark : RedPitaya's ADC are clocked at 100MHz which is quite powerful

Next week's objectives : Focus on analog part --> study circuits, remove useless components, study the noise in the system

Lausanne antenna

\@massoud wants to benchmark an ADC to see if he can get a sampling frequency of 50 MHz from the latter.

Frequencies of transducers

The frequencies of the 3 transducers will be:

  • 3.5 MHz,
  • 5 MHz (this transducer requires an ADC at 25 MHz to be suitably used),
  • 7.5 MHz

2017.02.15 - HD - 20.00 (Paris time)

Aim of the echopen device

The ideal goal would be to get 15 medical quality images per second that can detect 1 mm defects while remaining low-cost.
If compromises have to be made it is necessary to maximize the quality of the image leaving to lose a little on the low-cost side.

All calculations (signal processing) must be done on the device. It is necessary to minimize the execution on the phone.

Current Device

The current arrangements include:

  • A 18 V supply generates several voltages, one of which is -100 V to operate the transducer. To excite it also requires a pulse with a MOSFET. However, it is necessary to curb the voltage with a T / R switch so as not to grill everything. A band-pass filter (analog or digital) makes it easier to detect envelopes.
  • The system entries are:
  • The viewing angle of the image,
  • The line number of the image that impacts the framerate,

  • Depth of vision

  • The Red Pitaya card handles the digital side:

  • ADC,

  • DAC

The ADC and DAC of the Red Pitaya are addressed from the FPGA of the card.

Altran

The goal at the end of the collaboration would be to have about a hundred devices that can be clinically tested in some countries (with monetary standards binding as the United States or France).

The needs that Altran could fill

There are therefore several needs that Altran could fill:

  • In mechanics: with the probe head (with 3 transducers encapsulated in an oil bath, the liquid must have an impedance close to water),
  • Analog: amplification (45 dB to 90-100 dB), electromagnetic shielding (noise protection) and transformer (wires will not do the job due to the movement induced by the transducer),
  • An industrialization dossier,
  • Medical certifications,
  • Mechanical packaging (integration),
  • Open source community project management,
  • Someone who can manage the life cycle of a product
  • Envelope detection: digital or analog

To seduce Altran you need:

  • A block diagram,
  • A document summarizing the needs and bottlenecks

The ideal ADC should allow to have 100 MHz (which is rather big). The ideal DAC should convert 100 KB / s.

Bottlenecks and the theoretical figures of the desired performance are absolutely necessary.

Altran should not lose sight of the open source side (they should not give us files usable only with proprietary software linked to very expensive licenses).

Digital System and Analog System Comparisons

Digital system:

  • numeric (manipulation of 0 and 1 only),
  • Doppler (this is not in the specifications of the first version),
  • more expensive,
  • requires a 45 MHz ADC

Analog system:

  • cheap,
  • less flexible

Proposed approaches

Romain proposes a double approach:

  • Acquisition developed and optimized for us in pure analog
  • Non-low-cost digital approach combining an embedded system and an FPGA
  • It is necessary to keep in mind the mechanical constraints (dimensions) of the box and the thermal questions related to the miniaturization

The mechanics fixes a large part of the constraints, it is necessary to design something industrializable.
It is also necessary to keep in mind the fact of being certified medical device (for example with the extensions of video file).

2017.01.04 - HD - 20.00 (Paris time)

Agenda

  1. Introduction and presentations (newcomers)
  2. Current status of the embedded platform
  3. Hardware/processing needs and wishes
  4. Processing split (Hardware/Embedded Software/Smartphone)
  5. Hardware proposals

Attendees

\@rbo
\@benchoufi
\@eiffel
\@aurelie
\@omaciu

Benjamin, Mohammed, ??? sorry if I missed someone

Discussions

Introduction and presentations (newcomers)

Everyone gives a short presentation of him/herself and his/her interests in the project.

Current status of the embedded platform

\@jcbillard being absent, this point is not discussed further.

Hardware/processing needs and wishes

Before going to deep in the specifications of the system a list of needed and wished features must be established.
Besides the raw acquisition from ADCs and scan conversion, the embedded system will have to support additional features.
Identified features and functionalities include:

  1. WiFi communication with the smartphone
  2. Commands/configuration from the smartphone (gain adjustment, frequency,...)

To identify all needed and wished features a brainstorm document has been created by \@rbo so that everyone can put his ideas:
https://annuel.framapad.org/p/embsysBrainstorm

Processing split (Hardware/Embedded Software/Smartphone)

Today signal processing and scan conversion are performed on the embedded system (RedPitaya) and images are sent to the smartphone.
An analysis should be done to know the better way to split the processing between the embedded system and the smartphone. Should the embedded system perform the signal processing and scan conversion or should raw signals be sent to the smartphone and the processing done on the smartphone ?

Hardware proposals

\@jcbillard

Main CPU:
Texas Instruments OMAP-L138

  • ARM9 + C674x DSP cores at 450 MHz
  • uPP (Universal Parallel Port) useful for interfacing ADC
  • Available Linux support

ADC:
Texas Instruments ADS6142

\@rbo

Main CPU:
NXP i.MX7

  • ARM Cortex A7 single/dual core \@ 1 GHz + ARM Cortex M4 at 200 MHz:

ADC:

Action items

How do we handle tasks/issues ? Github issues, Markdown task lists, bugtracker ?

Methodology to use on github repositories and way of handling tasks/issues to be discussed and harmonized at project level for all repositories/groups.

Next meetup

January 6 2017, 20:00 to discuss some hardware specific stuff with \@jcbillard

results matching ""

    No results matching ""