LabVIEW
Preventing data loss in signal processing
Hi idiIE,
@iErd wrote:
I have to record a very large amount of data for real-time signal processing used in labview. A delay of more than 10 ms while receiving these data causes erroneous results for the system.
Can you explain the marked items with more details?
- Do you want to record or to process data?
- What is a "very large amount" in numbers?
- Do you talk about a "real-time system" or "short delay between signal acquisition and signal output"?
- Do you ´know how sample rate, number of samples and DAQmxRead time relate with each other?
I addition to the above comments.
What determines the speed of "receiving"? Is it dictated by the speed of communicating with an external instrument or by poor coding? What is the current speed and jitter and how do you measure it? How much data do you get ever <10ms (one point? Huge arrays?)
"Real time" in LabVIEW typically has a very specific meaning, involving LabVIEW RT running on a dedicated host and special real-time OS (i.e. NOT Windows!).
If you use the term colloquially, maybe you just want to see the processed data as it is recorded.
What kind of "processing" are you doing (Simple scaling? Huge transforms?) Is the processing asynchronous to the acquisition.
What are "erroneous results"? (Missing data? Wrong data? buffer overflow errors? no data?).
To give specific hardware advice, we need significantly more information.
Hello,
The values coming to the microprocessor via the serial port are characters.
The translation made by the interface after it has been received and processed as
It is taken back and then converted to radians. From these transactions
then the corresponding ROLL, PITCH and YAW in their respective order.
assigned to the variables. These calculations are always
by making the system consume a lot of energy, the microprocessor
will cause it to overheat. That's why communication
Each serial port is defined as an interrupt function.
It works every time the communication is completed. So very
calculations with many mathematical operations are here
Doing so will damage and disrupt communication. Therefore
kinematic calculations inside the main function
being carried out.
The main program cycle after each calculation
It will wait up to 1 millisecond, and the UART will deactivate the DMA layer.
will activate. This layer is an asynchronous mode of serial port communication.
way and waste of time in the main program cycle.
will prevent. In the meantime, data coming over the serial port
If there is no data according to the state of the variable that indicates its state
no action will be taken. If data has arrived, calculations
by sending this data to the necessary function for the backward angles
An array will be returned. This incoming data is a PWM signal.
will be sent to the relevant function to be created.
Pre-made STM32 for PWM rendering
Timer hardware in the architecture is used. Internal
The timer hardware is at the internal 48MHz frequency that the processor is fed.
It will occur here because it is fed from the oscillator that produces the clock signal.
The signal will also be 48MHz. But in this design
The servo motors used use the PWM signal at this frequency.
cannot detect this signal at certain values.
should be specified with dividers and adjusted to the appropriate value.
needs to be set. Then, with these values, a correct
Again, STM32 standard to generate PWM signal.
signal with incoming PWM signal generation construct in libraries
will be generated and held in the set PWM signal. STM32
Timer hardware layer with the help of standard library
automatically keeps the generated PWM signal.
PWM with simultaneous received serial port signal on oscilloscope output
signal is displayed. Signal shown in yellow
from the TIMER hardware of our STM32F051 microprocessor.
It is a PWM signal.
At the same time, the signal shown in blue
is the communication signal coming over the serial port.
As seen in the figure, from the communication signal
the previous PWM signal comes as 700us. Communication
The PWM signal after the signal continues as 1200us.
is doing. This value change graph is for one engine only.
shown. Outputs according to microprocessor program design
made after all calculations. back to back
There is a 20ms interval between two PWM signals.
It is seen that the calculations for 6 engines and
transfer to motors takes less than 20ms.
With the hardware layers of our selected processor,
It also benefits the design. We want to reduce the 20ms time even more.
I am also using NI veristand.
Waiting for your suggestions and opinions.
Hi idil,
@iErd wrote:
Waiting for your suggestions and opinions.
Opinion: your message is very hard to read.
Suggestion: Attach some code with example data so we actually see what you are talking about…
@iErd wrote:
The values coming to the microprocessor via the serial port are characters.
The translation made by the interface after it has been received and processed as it is taken back and then converted to radians. From these transactions then the corresponding ROLL, PITCH and YAW in their respective order. assigned to the variables.These calculations are always by making the system consume a lot of energy, the microprocessor will cause it to overheat.
I don't think we can help you with "µC overheating" issues in a LabVIEW forum…
Hi idil,
@iErd wrote:
the part that I really need is the speed of the data coming in the data collection unit between 20-30ms. What I can use to reduce this data collection rate to around 10 ms is to read the data in real-time without overflow and create a one-to-one simulation.
You use an UART to transfer data?
To speedup such communications you have two options:
- use a higher transmission rate (aka baudrate)
- send less data
So to speedup data transmission from 20ms to 10ms you could double the baudrate…
You could also implement a producer-consumer scheme to decouple communication from data processing. This often helps to maximize the communication port throughput…
@iErd wrote:
The values coming to the microprocessor via the serial port are characters.
The translation made by the interface after it has been received and processed as
It is taken back and then converted to radians. From these transactions
then the corresponding ROLL, PITCH and YAW in their respective order.
assigned to the variables. These calculations are always
by making the system consume a lot of energy, the microprocessor
will cause it to overheat. That's why communication
Each serial port is defined as an interrupt function.
It works every time the communication is completed. So very
calculations with many mathematical operations are here
Doing so will damage and disrupt communication. Therefore
kinematic calculations inside the main function
being carried out..
You are rambling about a lot of different very vague things, making it almost impossible to offer any suggestions.
Parsing a received string into a few scaled numerics is peanuts and probably the easiest task for your process and most likely NOT the limiting task. (You have not shown us your code, so maybe you are doing it wrong, possibly using a huge pile of Rube Goldberg code instead of something reasonable?)
A modern processor is designed not to overheat. It can run on 100% usage forever and might step down the clock if temperatures gets too high, especially of all cores are at 100%. Your processing is most likely confined to a single core, leaving lots of headroom. If things overheat, you might have a hardware problem (broken fan, obstructed air paths, poor thermal contact to heatsink, etc.). Maybe you want to run some stress tests to see where the problem is.
Can you explain what you mean by "defined as interrupt function" ? How does that integrate into a pure dataflow language such as LabVIEW. Show us some code!
How many serial ports are there?
Normally the transmission rate is determined by the sender and there is very little the receiver can do about it, except not being ready to read the data due to e.g. dataflow issues.
@iErd wrote:
Hello,
The values coming to the microprocessor via the serial port are characters.
The translation made by the interface after it has been received and processed as
It is taken back and then converted to radians. From these transactions
then the corresponding ROLL, PITCH and YAW in their respective order.
assigned to the variables. These calculations are always
by making the system consume a lot of energy, the microprocessor
will cause it to overheat. That's why communication
Each serial port is defined as an interrupt function.
It works every time the communication is completed. So very
calculations with many mathematical operations are here
Doing so will damage and disrupt communication. Therefore
kinematic calculations inside the main function
being carried out.
The main program cycle after each calculation
It will wait up to 1 millisecond, and the UART will deactivate the DMA layer.
will activate. This layer is an asynchronous mode of serial port communication.
way and waste of time in the main program cycle.
will prevent. In the meantime, data coming over the serial port
If there is no data according to the state of the variable that indicates its state
no action will be taken. If data has arrived, calculations
by sending this data to the necessary function for the backward angles
An array will be returned. This incoming data is a PWM signal.
will be sent to the relevant function to be created.
Pre-made STM32 for PWM rendering
Timer hardware in the architecture is used. Internal
The timer hardware is at the internal 48MHz frequency that the processor is fed.
It will occur here because it is fed from the oscillator that produces the clock signal.
The signal will also be 48MHz. But in this design
The servo motors used use the PWM signal at this frequency.
cannot detect this signal at certain values.
should be specified with dividers and adjusted to the appropriate value.
needs to be set. Then, with these values, a correct
Again, STM32 standard to generate PWM signal.
signal with incoming PWM signal generation construct in libraries
will be generated and held in the set PWM signal. STM32
Timer hardware layer with the help of standard library
automatically keeps the generated PWM signal.PWM with simultaneous received serial port signal on oscilloscope output
signal is displayed. Signal shown in yellow
from the TIMER hardware of our STM32F051 microprocessor.
It is a PWM signal.
At the same time, the signal shown in blue
is the communication signal coming over the serial port.
As seen in the figure, from the communication signal
the previous PWM signal comes as 700us. Communication
The PWM signal after the signal continues as 1200us.
is doing. This value change graph is for one engine only.
shown. Outputs according to microprocessor program design
made after all calculations. back to back
There is a 20ms interval between two PWM signals.
It is seen that the calculations for 6 engines and
transfer to motors takes less than 20ms.With the hardware layers of our selected processor,
It also benefits the design. We want to reduce the 20ms time even more.
I am also using NI veristand.
Waiting for your suggestions and opinions.
Instead of so many words, can you share a better block diagram of all the involved blocks?
I noticed you mentioned of NI Veristand, is your question about how to implement a high speed UART data capture in Veristand?
