BeagleBone Synchronous Data Collection (GSOC 2018)

Google Summer of Code
1

Hello. My question is for Hunyue Yau and Kumar Abhishek. Kumar Abhisek your Hackday Project Page on beaglelogic gives a lot of information so does your article. A big shout-out to your successful beaglelogic standalone board. I came across this link which is apparently a proposal for gsoc 2017 for the same idea. I am assuming this proposal failed because the GitHub repo doesn’t exist. So here is a list of things that has kept me wondering:

  1. Why did the last year’s proposal fail? Can I get insights on some important issues in implementing a ‘synchronous beaglelogic’?

  2. What was the reason behind making beaglelogic asynchronous over synchronous when it was designed in the first place?

  3. Can you give me some idea where to start from in order to contribute to this idea? And what part of the code and hardware needs to modified/replaced? Can this be implemented in the existing Beaglelogic standalone?

2

Hi,

In general, proposals can fail for many reasons.

As implemented, BeagleLogic will sample at whatever rate it (the PRU) is setup
for. This has no relationship to the signal being observed, i.e. asynchronous.
So to get good picture of what is going on, the sample needs to be much faster
(sampling theory, etc.) then the signal.

Another way to look at the signal is to synchronously. There is a defined input
clock and the signal is looked at during a perdefined point in the clock.
(i.e. either or both edges with a time offset).

The idea is to create a synchronous sampling mode