Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

DAQ system with FPGA and 1KHz sampling rate

Status
Not open for further replies.
V

Vlad.

Full Member level 3
Joined
Jun 4, 2012
Messages
179
Helped
3
Reputation
6
Reaction score
4
Trophy points
1,298
Location
Bucharest/Romania
Activity points
2,568
Hi there,

I am designing an FPGA-based custom DAQ to be used to monitor some voltages at maximum 1KHz sampling rate , hence I am curious which way is preferred to be done the signal acquisition, hence I am think on 2 possible ways:

1- will be to take 1000 samples in 1 sec and after will send them to a PC GUI.
2- use the GUI to send request for samples (one request for one sample), hence will be around 1000 requests in 1 sec.

Right now I am using a custom UART core designed by me in VHDL, but I am thinking to go and use the ETHERNET communication, TCP/IP to send data as strings.

Please let me know, about your ideas or thoughts regarding this kind of application.

Many thanks,
Vlad
 

It depends on your application. If 1 kHz sampling rate must be preserved with good precision then use solution when each measurement is triggered by FPGA. Using an ordinary PC it is impossible to generate an event every 1 ms with good precision.
 

tcp/ip is viable. converting to ascii is one of those things that is done for data normalization. I'm not a fan of this, but I know people do it.

tcp/ip can be done with a soft-core cpu. The protocol was written with the assumption that a CPU would be used. I don't think I'd trust free ip cores for tcp/ip. The spec has an ascii-art flow chart of the fsm without corner cases. This can easily let you create a design that deadlocks in some cases.

There are other options -- protocols similar to tftp for example -- where you can get reliability without resorting to stateful connections. If this is directly connected, udp should be fine.
 

Hi,

I don't think that requesting every ms a single sample is a good idea.
You won't get precise frequency and low jitter.

What is your input signal?
How do you process the digital data?
What result do you expect?

Klaus
 

Hi there,

Many thanks for your answers.
@KlausST
-my input signal will be a voltage signal, which I am trying to catch its variations over time.
-the digital data will be stored in a RAM, to be sent after to a PC, from where will be displayed.

Based on your replies, I am thinking to trigger to sample in to the FPGA, hence I will get 1000 samples in 1 sec, store them in to a buffer (e.g. RAM), and while taking new samples, send the current stored sample to a PC, and so on.


Vlad
 

Hi,

Why storing them? Why not sending them immediately?
Storing just needs RAM and causes delay.

One value per ms shouldn't be a problem.

Klaus
 

Yes, that can be done, but in my case since I have an UART core in the FPGA as communication channel, either I shall increase the baud rate to handle the data amount (300000 bits of data over 1s), but I have to see if its stable, or should try to use TCP/IP.


Vlad
 

It's no problem to use 922 kBaud UART with USB-to-UART converter (highest PC standard baud rate). Of course not for the FPGA, but the data transfer is also quite reliable on the PC side.

I would start with this simple solution, you can switch to TCP/IP later, if actually required for the project.
 

Hi,

There is a lack of information.
How do you come to 300000bits/s? This means 300 bits per sample. This are 30 bytes.

In either case:
It makes no difference if you store the data in RAM and transer it later, or you transfer the data immediately.
You need the same interface speed.

Sadly you didn't answer a single question of my post#4.
* "voltage signal" doesn't give useful information. Temperature? Speed? Brightness?

Klaus
 

Hi KlausST,

So I have to monitor 16 channels with 16 bits resolution, hence are 16 voltage signals to be monitored. Adding also some configuration bits its gets around 250-300 k bits/s.
Yes, I am aware that I need the same speed, but I was asking about the acquisition itself if should be stored first and after sent, or just sent to PC.
The signals, are voltages which should or not vary over time, during operations, are provided by some prototype ASICs during operation. And also I dont know how will vary over time.

I will try to do it with a 500k baud rate, and see how it works.

Vlad
 

Hi,

No things clearing up:
16 analog channels each with 16 bits resolution. = 32 bytes = 320 bits to transmit.
Every 1 ms --> 320kBaud

But additionally you need some frame sync. How do you decide to do the frame sync?
Timed? With timeout? What time?
Consider what happens when you miss a byte...or there is an additional byte in the buffer...sooner or later this will happen.

Klaus
 

Yes, you are right with the calculations, I just put the number without the additional ones, you had included also the start and stop bits, which is also my configuration 10 bits for 8 effective bits (1 start and one 1 stop bit).

Regarding the frame sync, I am aware of that, till now I had used an ASCII char,1 byte, lets say letter A placed as header before my data string, and in my GUI I am looking to get the data from A to the next A, and I will count the bytes, so see if they are all arrived. Do you have another solutions?

Vlad
 

Hi,

If you use a single character (like "A") there is an 1:256 chance that the same character is included in your ADC data.
Now that you are sending 16 x 2 x 1000 bytes per frame you should expect 125 "A" in one frame.

A 16 bit checksum is more reliable.
Again: What do you do if this doesn't match?

Klaus
 

Transmitting ASCII formatted data with respective sync characters (e.g. CR/LF) is of course possible, but involves a huge overhead and ineffective channel utilization. I would think about a binary format, probably using a simple protocol like MODBUS RTU.
 

In the past I had used sync chars in my applications with microcontroler, but I did not get any transfer error, like the one pointed by you, but yes of course you are right, there is a chance, and data will be screw up, so for that I added also the byte counting between As. Anyway, I am more interested in your solution with 16 bit checksum, I will try to see about it, maybe you have some documentation to point out to me.

Regarding your question, if the data received will not match my conditions, I will just ignore that sample, or/and request another one in order to get the total number of required samples.

Vlad
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top