BBB - High speed data acquisition and web-based UI

RE: BBB - High speed data acquisition and web-based UI

Former Member — Mon, 17 Aug 2015 08:57:11 GMT

Hi Shabaz. This post has made me interested to use BBB as a data acquisition device. I have never used BBB and am excited to us it looking at its capability. As already mentioned above, I wanted to know how I can use the inbuilt ADCs of BBB board to achieve a data rate of 1MBps(or is it not possible). What if I don't want to use the web browser and wanted to write in the inbuilt memory or an external SDcard interface. My intention is to make a data acquisition and storage application using BBB at a minimum rate of 1 MSPS and log the data (without any data loss, I will be storing superposed sinusoids of frequency not more than 400 KHz). Is this possible with the BBB only without using any external ADC or hardware. If not what configuration do I need to have.

Thanks

RE: BBB - High speed data acquisition and web-based UI

Former Member — Sun, 19 Jul 2015 12:45:46 GMT

[mention:b0bc65b9ecdc4307bd967592f00e340a:e9ed411860ed4f2ba0265705b8793d05] Sir I am new to beaglebone black and I want to work on a similar idea of making a weather logger. Can you suggest some tutorials from which I can learn how to run the interface on the bbb landing page.

RE: BBB - High speed data acquisition and web-based UI

Former Member — Tue, 18 Feb 2014 13:07:17 GMT

Hi shabaz,

Why do you not directly configure the ADC registers with PRU, store on FIFODATA and sharedMem instead, and went around with the device tree?

RE: BBB - High speed data acquisition and web-based UI

morgaine — Sun, 29 Dec 2013 15:37:56 GMT

If it's OK with everyone here, I'm going to request in F&S that this comments thread be split at the point where we diverged from discussing shabaz's excellent blog article and began talking about OSHW. I suggest that beyond the split point it be turned into a new thread under Open Source Hardware, maybe titled "OSHW commercial dependencies" or something like that, please suggest better titles if anyone has one.

There are a few candidate posts at which to make the split that I can see, although it's fuzzy as the two topic became intermingled. Although the OSHW topic began earlier and the blame lies entirely on me (not on selsinork), I think the cleanest point to make a split is at the post:

selsinork Dec 28, 2013 1:54 PM (in response to Morgaine Dinova)

Would this be OK? And sorry for the meander, shahaz. [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-91406b05-8fd4-4a24-94fa-86e27d375d3e/6064.contentimage_5F00_403.png:16:16]

Morgaine.

RE: BBB - High speed data acquisition and web-based UI

Former Member — Wed, 20 Nov 2013 18:14:37 GMT

Shabaz - I am hoping to recreate this project, however I am having some trouble understanding how you set everything up. Is there anyway I could get some help?

RE: BBB - High speed data acquisition and web-based UI

Former Member — Thu, 15 Aug 2013 12:23:50 GMT

I'm a little confused as to how you set the LCD_DATA* pins to be linked as PRU*_R31[]. I can't tell by looking at the code provided. Can someone please explain to me or link me to somewhere that describes how to do so?

RE: BBB - High speed data acquisition and web-based UI

bwelsby — Sun, 04 Aug 2013 10:51:55 GMT

FYI you don't need to recompile the device tree to disable the HDMI you can add the following to the optargs in uEnv.txt

optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

I found this here

RE: BBB - High speed data acquisition and web-based UI

bwelsby — Sun, 04 Aug 2013 10:17:32 GMT

Excellent work!.

I thought the PRUs had a 16bit parallel capture mode or are all the pins not available on the BBB? (need to consult the docs) section 4.5.2.2.3.2 of the tech ref spruh73c.pdf

One thought I had was to use both PRUs to capture alternate bytes/words but that was just a thought, again are all the pins available?

RE: BBB - High speed data acquisition and web-based UI

Former Member — Sun, 04 Aug 2013 10:03:12 GMT

I'm curious if you considered using the onboard ADC ? At first glance it looks capable, but maybe not fast enough ?

The underside was more untidy!

lol.. you really should consider setting up to build your own pcbs for this stuff

and the local Maplin store doesn’t sell any 3.3V-compatible logic to divide by two!

Haven't used maplin in years, but have they really became so crap that they don't sell a simple 4013 or 74HC74 in the shops anymore ?

Anyway, in the abscence of an oscillator of the frequency you want, there are various simple programmable oscillators like the DS1077 or LTC6903/4 that are useful to have available for general prototyping work. They'll never have the accuracy of a proper fixed frequency crystal oscillator, but are extremely useful none the less as they allow you to quickly evaluate different frequencies. The price tag is rather more acceptable than a proper function generator too [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-91406b05-8fd4-4a24-94fa-86e27d375d3e/contentimage_5F00_1.png:16:16]

RE: BBB - High speed data acquisition and web-based UI

morgaine — Sun, 04 Aug 2013 10:02:16 GMT

In your original bbb--working-with-the-pru-icssprussv2 article, I recall that you said "There are 16 pins available for input in the fast mode, and 15 for output." Does this mean that 8 GPI inputs can be read by PRU1 and the other 8 by PRU2? If so, could the two PRUs be run in lockstep to sample all 16 bits at once and avoid the need for SAH altogether? That would be simpler, faster and cheaper than using an external 16:8 selector, so if the other PRU is unused it might be an all-round better approach for gaining more ADC width.

RE: BBB - High speed data acquisition and web-based UI

morgaine — Sun, 04 Aug 2013 08:48:51 GMT

After your I2S audio DAC article, I was wondering when the ADC one would appear. [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-91406b05-8fd4-4a24-94fa-86e27d375d3e/contentimage_5F00_2516.png:16:16]

In addition to SDR, I'm interested in ADC functionality for the multifunction instrument idea.

Since you pointed out that:

the KNJN board is not optimal for several reasons, and
you also want more ADC width and speed for the future, and
the PRU has plenty of speed in reserve, but
the number of PRU-connected GPIs is limited,

these four factors seem to combine towards using just 8 GPIs to read in bytes from an external 16:8 selector that samples an ADC of up to 16 bits wide and runs a lot faster. Because the PRU triggers sampling, only one half of the 16 bits would need to sample and hold while the PRU gets around to reading in the other half, thus saving us an 8-bit register while also allowing the ADC to run faster because its sample acquisition time is overlapped with the PRU read time.

Or, at the cost of SAH on all 16 bits, the sampler could be fully external and asynchronous w.r.to the PRU's cycle period to give the ADC even more acquisition time, although I'm in two minds about whether this helps since that might require the addition of under-read logic to tell the PRU that a sample was missed..

Maybe it's too early to be thinking about this without a coffee. [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-91406b05-8fd4-4a24-94fa-86e27d375d3e/contentimage_5F00_403.png:16:16]