Sampling Rate Arduino Galileo

lucamagno90:
Maybe, Arduino due will be my answer.

It might be if we knew what the question was.

42

I recently published an audio library, which does all this with 44100 Hz sampling. It only works with Teensy, because fast 32 bit processing and DMA data transfer are needed to support that speed really well.

Maybe this code will help?

For lower speeds, this site might help you?

http://www.plaindsp.com/

Thanks guys. But, specifically what is the sampling rate of Galileo??

about 7-8 milliseconds. Which is about 125 Hz.

I measured it at 1000 readings in 7.5 seconds on my Galileo.

For the Galileo version 2:-

The Galileo Gen 2 uses a Texas Instruments ADS108S102 ADC, which allows for a 4x increase in ADC sampling performance in Linux compared with Galileo Gen1

You are right, it's very low. I've read in the adc manual that the freqency sample is 1 Msps. So, sampling rate is not frequency sample.

It takes far more than theoretically fast hardware to deliver a reliable, low-jitter, relatively fast sample rate in the Arduino environment. Very careful software design is required, to deal with the many Arduino features and library using blocking APIs, and the use of other interrupts by at least serial and timing, and many libraries.

The links I posted in msg #4 show some examples.

Many people have ambitiously tried connecting awesome audio ADCs to Arduino, but failed to get any useful performance when it came to writing the software side.

Do not underestimate the difficultly of fast sampling software development.

lucamagno90:
You are right, it's very low. I've read in the adc manual that the freqency sample is 1 Msps. So, sampling rate is not frequency sample.

The A/D chip is connected through an I2C expansion chip that is only running at 100KHz. It is a piss poor design. I was talking to the designers at the Rome Maker Fair 2013 and they said that they did not realise the chip could not be run faster. Now on the second iteration of the board thy have put on a chip that can run at 400KHz hence it is four times faster but still piss poor. It is just a very badly designed system.

Grumpy_Mike:
The A/D chip is connected through an I2C expansion chip that is only running at 100KHz. It is a piss poor design.

I do wish you'd come down off the fence, stop beating about the bush and say what you really mean.

The sad part is Intel could have used a PCIe to some-other-bus bridge chip and then put a 8 or 16 bit parallel bus A/D chip on the board.

Linux supports SPI on chipsets with pretty advanced features, like scatter-gather DMA. Intel could have used such a chipset and put a fast SPI interface ADC chip on the board.

They could have done a lot of things. They're Intel. I'm not sure I'd say "piss poor", but I suppose I expect more from the likes of Intel.

I'm not sure I'd say "piss poor", but I suppose I expect more from the likes of Intel.

Yes but you didn't talk to the design team. I did and I stand by piss poor. They had not got a clue about what is important in an embedded processor system. Plus they were only kids with very little real world experience.

Well, they did something on it.

download this e-book for free and much of your problems seems to be solved.

good luck

download this e-book for free and much of your problems seems to be solved.

Can't see how a book can compensate for basically a flawed hardware design.

Just what do you mean by this?

Well, of course, you are all right if you blame the design team. This is what I mean when I say they have done something about it . First of all they designed a new board Gen2 as we know. They also extended de standaard Arduino API's with a few new ones. They allow us to work gradually up to approx. 3Mhz on the GPIO pins. And I can still code in arduino C. Perhaps the same thing can be done with a Beaglebone Black, but THEN I have to learn a new language again.
The book I mentioned above is written by a member of the design team and is free to download. Its about
The Intel Galileo and Galileo Gen2 and is loaded with information. I downloaded it and it was worth it.
The least I can say is, That they resolved the weak sampling rate. As far as I know, that's why the discussion is started.

Perhaps the same thing can be done with a Beaglebone Black, but THEN I have to learn a new language again.

Why?
Can't you program the Beaglebone in C++ as well?

heinzV:
The least I can say is that they resolved the weak sampling rate.

I downloaded the book, and looked through it. I didn't see anything that addressed the analog sampling rate. Can you tell us where that information is found in the book?

Well, my only excuse in the matter is the fact that I took the GPIO max freq for sample rate. I'm a bloody newbie sorry for that. Still, i have some questions. When we look at the datasheets the adc108s102 claims a sampling rate of 1M SPS, and a clock of 16 Mc. The Quark X1000 on the other hand has a 25 Mc clock on his SPI interface. One can hardly say that the hardware is flawed. I must confess that i know little to nothing of the innerts of Linux. If I am not misled, Linux has facilities for a master SPI . i think that some clever guy with enough knowledge will be able to do something about it. In any case, i have ordered the damn thing and will test some things out.
In the end, it will turn out that you Pro,s were all bloody right. :-[

my only excuse in the matter is the fact that I took the GPIO max freq for sample rate.

Just look at the schematics of the board and you will see that is not true. The A/D converter can only be accessed through the I2C port expander. In the first design the chip they used could only be run at 100KHZ, so on the second design they used a chip that could be run at 400KHz. So they turned a bloody stupid design into just a stupid design.

The Quark X1000 on the other hand has a 25 Mc clock on his SPI interface. One can hardly say that the hardware is flawed.

You can if all that power is held back by very slow I/O devices. Yes there are about three digital lines that can run fast but the majority of them are port bound. I would not even let my undergraduate students get away with that. At the very least the the digital and analogue I/O should be on the SPI bus.

The design of the Galileo II is very bad because they learned very little from the mistakes they made in the Galileo I, for a supposed big company they are totally stupid.

I did what you suggested and closeley inspected the schematics and datasheets. You are 100 percent right.
I think the Intel Galileo is solely designed for robotplay market, nothing else.
Because I owed this discussion something, I looked for a solution .
I found something on the forum

http://forum.arduino.cc/index.php?topic=144484.0

It concerns a arduino Due who is able to read a adc-channel at 2us. Albeit not in simple arduino C
So, after all , we can stick with arduino.

I leave it at that. Thank you all for your patience.

Thank you, all who posted in this thread. Especially that last post.