Design and Construction of a Data Logging System

Post here information about your own engineering projects, including but not limited to building your own car or designing a virtual car through CAD.
rusefi
10
Joined: 04 Feb 2014, 22:27

Re: Design and Construction of a Data Logging System

Post

You might find http://rusefi.com/forum/viewtopic.php?f=4&t=359 useful.

That board is for stm32f4discovery, not your dev boards - but still, the schematics might be helpful. rusefi forum in general might be useful for some sensor decoding and stuff. Oh, and I really suggest you check our ChibiOS/RT - that's unless you have already chosen a different rtos. The point of ChibiOS/RT is that not only it has the os, but it also has hardware abstraction layer.

Caito
13
Joined: 16 Jun 2009, 05:30
Location: Switzerland

Re: Design and Construction of a Data Logging System

Post

rusefi wrote:You might find http://rusefi.com/forum/viewtopic.php?f=4&t=359 useful.

That board is for stm32f4discovery, not your dev boards - but still, the schematics might be helpful. rusefi forum in general might be useful for some sensor decoding and stuff. Oh, and I really suggest you check our ChibiOS/RT - that's unless you have already chosen a different rtos. The point of ChibiOS/RT is that not only it has the os, but it also has hardware abstraction layer.

Thanks!

We're using no RTOS for this project since we can derive all the times from a simple periodical interrupt. Data has to be acquired precisely and just buffered so it can be sent to the SD card.
Come back 747, we miss you!!

Jef Patat
61
Joined: 06 May 2011, 14:40

Re: Design and Construction of a Data Logging System

Post

Working without RTOS is making things hard on yourself. You are mentioning 1kHz sampling, buffering and writing to SD card in one sentence. Does the card need to be considered as a storage device for the board or also be considered as a portable storage device that can be read by a PC. In the latter case you will need some (probably FAT) file system. Doing all that in the timer interrupt doesn't seem wise, so you'll need to think about scheduling/synchronizing the work somehow.

rusefi
10
Joined: 04 Feb 2014, 22:27

Re: Design and Construction of a Data Logging System

Post

Sounds like you think "oh, rtos? it mush be slow as Windows". It's not.

I am not sure if an SD card can write a chunk of data in 1ms, can it? Because if it does not, you would need buffers and threads - that's where mutexes would come handy.

Jef Patat
61
Joined: 06 May 2011, 14:40

Re: Design and Construction of a Data Logging System

Post

Depends on how big that chunk of data is. Write speeds of several 100k/s are quite easy to achieve, even with filesystem. But to optimize write speeds normally the data is buffered. Because of the the way flash works writing one byte to flash takes a similar amount of time as writing one page. That means buffering, but buffering a complete page might be problematic due to hardware constraints. Another problem is that writing to SD will probably done via SPI or something else that is interrupt driven on itself. It's hard to imagine doing this from within a timer interrupt. Off course, it can be done without OS, but think carefully about the design, it might be not as simple as you think up front.

Maybe have a look at FreeRTOS for your purpose? Fairly documented, easy on resources and above all: free.

rusefi
10
Joined: 04 Feb 2014, 22:27

Re: Design and Construction of a Data Logging System

Post

Jef, I think we are talking about the same point.

100k/s is one thing, but my (rhetorical) question was how much data you can write within the next 1ms if you would try to implement a straight-forward solution of grabbing sensors and writing results 1000 times a second.

Caito
13
Joined: 16 Jun 2009, 05:30
Location: Switzerland

Re: Design and Construction of a Data Logging System

Post

Maybe I've not expressed myself clearly enough. I'll go through a brief explanation of the processes running and their speed/completion time.

Handling the timing for this project is easy enough to surpass the need of an RTOS, at least on our opinion. Though using an RTOS makes it easier to manage once it becomes large enough, on a low scale it's more difficult to deal with. Data acquisition, data storage and output management have all been taken into account. There's no much more to it on a "low-cost" data acquisition system.

GPS works with UART and continuously sends data, once output is active it sends data every 50ms(20Hz). GPS data via UART is managed with DMA(Direct Memory Access), so no processor intervention is needed until all data has been received. Once received it triggers a low priority interrupt which just pushes the data to a GPS buffer. The whole interrupt takes 5us. That's 5us at 20Hz, 100us in one second, or 0.01% processor usage.

A 1ms high priority interrupt manages the ADC, Gyro and Accel. Inside the interrupt we get the data from previous conversion and trigger the next conversion. We don't wait for it to convert.. we just let it sample while the processor is doing other stuff and get the data on the following interrupt, this way it takes only 10us. Every 10th interrupt (so we'd get 100Hz) we use the I2C bus to get data from Accel and Gyro. So this 10th interrupt is longer, 400us in total. We could've used DMA for the I2C, so it would take 20us rather than 400us, but we don't need that kind of performance. Rounding up, 10 interrupts take 490us(9 fast, 1 slow), that's over a total of 10ms. That means 4.9% processor usage.

So far we've got ~5% of the processor time used to acquire all channels and send them into buffers.

The remaining time (which occurs on the main() ) is needed to manage outputs (turn on/off depending on current channel states.. for example ADC1>256 turn on output1) and write to the SD Card. Output management takes very little time compared to the SD, just us.

The SD Card has a FAT file system. We're using FAT FS by Chan open library to manage the FAT. Every opened file has it's own buffer and will only send data to the SD when it reaches 512bytes, because the SD card is written by sectors. Once again the SD card is used with DMA so it needs little processor intervention. The SD card is managed using the 4-pin protocol, not SPI. SD Card speed exceeds 300kBytes/s, but a more conservative number(to do some math) is 200kBytes/s.

Our data throughput is around 1Mbyte/min, or 17kByte/s. Taking the 200kByte/s as a measurement this means 17/200= 8.5% of the processor time spent writing to the SD.

That means that only 13.5% of the processor is used, we still have lots of overhead to add stuff.

All the data has really precise and deterministic timing. I hope it's now clear that I don't need to do everything in the 1ms interrupt. On average, the 1ms interrupt lasts only 49us. The main() sends data to the SD which can be interrupted withouth any problem. If the FAT is working and interrupted nothing happens. Data is sent through DMA so once the command is given there's no need for processor intervention.

Overall we have allocated (in buffers and variables) less than 16kB of SRAM. The FAT files take no more than a couple of kB in total. Overall less than 20kB of SRAM used, which is not much at all. The microcontroller has 160kB (as a reference, the stm32f4 has 192kB of SRAM), so we're using just 12.5% of the SRAM available..


The code is simpler than you probably imagine, that's why we opted for no RTOS.

The main() is not finished, it needs start/stop management and other stuff. But we're acquiring everything and writing it to the SD. Today I tested the system for 40min, I got a 40Mb file as a result, the FAT FS managed it with no problem.


I'll try to keep this updated.

Cheers,
Caito.-
Come back 747, we miss you!!

Jef Patat
61
Joined: 06 May 2011, 14:40

Re: Design and Construction of a Data Logging System

Post

Nice to see your project is moving forward. To come back on the RTOS discussion. For me it has been a while since I have been working without so that of course biases my input. I didn't say you can't do without, I only wanted to make clear you have to think about certain aspects harder.

In your case for example I'm thinking mainly of the buffering. Do you buffer one sample, or multiple samples in something like a ring buffer? You are mentioning data is coming in through several interrupts. Then you buffer this data and later on write it to the card. Again, I'm not saying this can't be done, but it requires careful thinking to keep things in sync. You mention a GPS buffer. Does this mean you somehow merge the buffers (GPS, ADC, ...) later into one buffer from the main? Are you sure this will work reliably? To me it sounds like you might be loosing your time accuracy this way. Are you sure the GPS 20Hz is exactly in phase with your timer interrupt? Otherwise this might lead to a drift in capturing, which causes a drift in buffering, which causes... This mostly leads to hard to catch bugs. You might not notice them in your 40min test. You will need to find a decent way to test this, at 1kHz.

Note: I have years of experience in data capturing applications, though it is on a way higher level. We always capture and write to a buffer from the timer interrupt. So in the timer interrupt I would merge the ADC, Gyro, GPS, ... data into one buffer. This gives you precise timestamps and data that is into sync.

Caito
13
Joined: 16 Jun 2009, 05:30
Location: Switzerland

Re: Design and Construction of a Data Logging System

Post

Jef Patat wrote:Nice to see your project is moving forward. To come back on the RTOS discussion. For me it has been a while since I have been working without so that of course biases my input. I didn't say you can't do without, I only wanted to make clear you have to think about certain aspects harder.

In your case for example I'm thinking mainly of the buffering. Do you buffer one sample, or multiple samples in something like a ring buffer? You are mentioning data is coming in through several interrupts. Then you buffer this data and later on write it to the card. Again, I'm not saying this can't be done, but it requires careful thinking to keep things in sync. You mention a GPS buffer. Does this mean you somehow merge the buffers (GPS, ADC, ...) later into one buffer from the main? Are you sure this will work reliably? To me it sounds like you might be loosing your time accuracy this way. Are you sure the GPS 20Hz is exactly in phase with your timer interrupt? Otherwise this might lead to a drift in capturing, which causes a drift in buffering, which causes... This mostly leads to hard to catch bugs. You might not notice them in your 40min test. You will need to find a decent way to test this, at 1kHz.

Note: I have years of experience in data capturing applications, though it is on a way higher level. We always capture and write to a buffer from the timer interrupt. So in the timer interrupt I would merge the ADC, Gyro, GPS, ... data into one buffer. This gives you precise timestamps and data that is into sync.
Jef, lot's of thinking has gone into it. Sync has been proven and it works correctly, no data is mixed or put were it needn't to be.

It really is not that complicated as it seems to be. And 1kHz is not much at all, not even the 8kHz combined. I've recently designed systems for acquiring with combined sampling rates of 1MHz.
You just need to be tidy and make sure some things are executed in order, which is assured since we have total control of the microcontroller.

Regards,
Caito.
Come back 747, we miss you!!

Jef Patat
61
Joined: 06 May 2011, 14:40

Re: Design and Construction of a Data Logging System

Post

Caito wrote: lot's of thinking has gone into it.
I'm not saying you didn't. Then, on the other hand, in your first post, only a month old you were gathering specifications. Now, in one month you did all that thinking and implementing. Let me consider that 'lot' just relative.
Caito wrote: Sync has been proven and it works correctly, no data is mixed or put were it needn't to be.
Don't be that self assured when you're working on a thesis. Keep an open view. And remember: you can never prove something works correctly. Most experienced engineers know out of first hand experience that:
[*]You can only prove it works under certain circumstances.
[*]You can only prove it doesn't work

I just gave you my input, that doesn't mean I'm saying that what you are doing is wrong. Just try to keep the view open, exact measurement is one of the hardest things to do. (BTW, I'm not buying that 1MHz measurement, you probably don't even have the equipment/experience to test such a system accurately)

Caito
13
Joined: 16 Jun 2009, 05:30
Location: Switzerland

Re: Design and Construction of a Data Logging System

Post

The original thread started over a year ago, that's some time to think.

I desgined and built 12bit ADC system running at 1MSps with ENOB exceeding 11.5bit.It runs on SPI at 14MHz with digital communication with more than 4kV of isolation since it's connected to the utility grid. Thankfully I have all the necessary equipment and knowledge todo so. A paper was presented and accepted for ISIE 2014 (http://www.isie.boun.edu.tr). Of course I can't upload it since it's now copyrighted by IEEE, but you'll find it on a couple of weeks on IEEExplore. Two people with whom I coauthored will be presenting it in Istanbul on June.
Here's the title:
High Speed Fixed Point DSOGI PLL Implementation on FPGA for Synchronization of
Grid Connected Power Converters.


To continue on topic, we're now working on the pc software. It's the most boring part for us since it's a bit away of electronics. Just pure software.

We're developing it with Qt, so it will run on linux, mac and windows. For the plots we're using QCustomPlot (http://www.qcustomplot.com) which gives some really nice results. I'll post screens when we have a previdw of how it would look.

Bye!
Caito.-
Come back 747, we miss you!!

Jef Patat
61
Joined: 06 May 2011, 14:40

Re: Design and Construction of a Data Logging System

Post

Sorry, I apparently missed the year, which off course influenced my input #-o
We're currently investigating data acquisition with FPGA. But we're just investigating. My VHDL knowledge is rusty and my collegues don't have any. Our company has access to IEEE (don't know if they have access to everything) so I look forward to your paper.

Caito
13
Joined: 16 Jun 2009, 05:30
Location: Switzerland

Re: Design and Construction of a Data Logging System

Post

Time goes fast!

We finished the system. I can proudly say I'm now an Electronics Engineer! Yey! :mrgreen: :D

Final specs:
-8 analog channels at 1kHz (of which one is wired to battery voltage, and another one has a pullup for RTD measurement)
-4 digital channels at 100Hz
-2 acce at 100Hz
-1 gyro at 100Hz
-GPS at 200Hz
-2 fully protected low side (5A max) programmable outputs
-SD Card with FAT file system
-5V regulated output


Of course it still lacks lot's of stuff! It doesn't plot vs. distance and still needs some more time in the UserInterface development. But the Hardware/Firmware is really solid, so that's nice!

The UserInterface can use simple lookup tables to plot from 0-5V to whatever you want. It's done with a graphic style window, but it's still limited to a first degree polynomial (which suffices for most needs).

The PCB prototype was completely hand-made, and the case was 3D printed.

I hope you like it.

From the screen, most of the analog channels in the dashboard are missing.
Image

Image

We've received a couple of offers. For the moment we're planning on a test to see how it behaves against a Motec system. Some are skeptical, but we're assured of what we've done. The test will be done on a Turismo Nacional Clase 3 car at the Autodromo de La Plata, date to be confirmed.
Both systems will be tested at the same time, connecting the analog channels of both in parallel, but using different gyro, acce and GPS.


Bye!
Caito.
Come back 747, we miss you!!

graham.reeds
16
Joined: 30 Jul 2015, 09:16

Re: Design and Construction of a Data Logging System

Post

Is there any where we can download a PDF of your thesis?

Caito
13
Joined: 16 Jun 2009, 05:30
Location: Switzerland

Re: Design and Construction of a Data Logging System

Post

graham.reeds wrote:Is there any where we can download a PDF of your thesis?
Sadly no, and it would be in spanish. But if there's any details that you'd like to know don't hesitate and ask me, there are no secrets!
Come back 747, we miss you!!