Hi again, thanks for the reply Andrej and yes let's see what others have in their mind, meanwhile I will try the example you have mentioned and try to learn more about the project idea itself.
Thanks again, I hope to make some progress very soon.

Hello and welcome,

Hi,
I am Anudit Verma, a final year CS undergrad from University School of Information, Communication and Technology (USICT), Delhi, India. I am an avid open source enthusiast and a contributor, always interested in learning something new while contributing significantly to the open source community. I have worked earlier on a GSoC project with CiviCRM, in helping them integrate OSDI API into their system, my project can be seen here. I did most of my project's work in PHP, along with that it include working with JSON & XML data, I also know C/C++, haven't used Google's Protocol Buffers though, but I am very much interested in this project, I might learn something new and exciting. You can know more about me at anudit.in/aboutme
I followed the discussion on this thread, so I am also aware of the fact that we are currently focusing more on the project's tasks and discussing less about which language to be used in order to complete this project, but I have a small doubt here, so is it upon a student to choose the language to go with, which is the part of his skill set ? I completely understand the fact that we are not choosing the ease of code-bility of a student in any language rather we could set a specific language so as to optimise the project itself at the end. Could you please throw more light in this regard ? Also it would be great if you can provide some links of the resources from where I can learn more about the code base of Apertus and start my contributions.

You still shouldn't forget, that ARM processors have not infinite resources to process things. If it's possible we should use JIT versions of languages or ones optimized for ARM. Had just a glimpse at it on google while lunch break at work.

All languages mentioned are well tested, providing a rich environment.

A word of caution, just because some language is hip at the moment, doesn't mean that the performance or feature set is suited for embedded systems. It should be evaluated first. I still vote for C/C++ for the backend, it maybe complex for some people, but it's giving the most performance (usually).

This is what I find confusing, alas me recommending the renaming to "AXIOM Beta Webinterface".

I would also like to add that there is no exclusivity with APIs. We can do PHP, python, nodejs, go and bash, etc. APIs and it will make users and developers the happier the more options there are.

Backend language

Dear @all,
after talking with Sebastion today, I would recommend restructuring the task as follow:

Here is the final cut version if you are interested

Above (top right) is an early crude waveform produced from data from the Axiom Beta. The larger waveform is from a recording at 1080p as viewed on DaVinci Resolve, which includes the Axiom Beta overlay.

A good example ist the waveform of Final Cut Pro X, it has color information merged into the luma based waveform. You can watch it here at minute 3:10 youtube

Started through setting U-Boot as kernel manually. I suppose QEMU is not replicating the search for boot.bin on first partition, as the hardware does (needs verification). Built newest U-Boot (2017) from Xilinx to check if there would be less problems, than with one from 2014 from apertus°.

The relevant documentation is here: https://wiki.apertus.org/index.php/AXIOM_Beta/AXIOM_Beta_Software#Overlay_Images

I'll have to get a grasp of the system context first, but it's definitely something I could write, so I'll tentatively take this on myself :)

./whitebalance.py outputs:

first version works pretty well already.

Why not. After all, the IMU is currently 'solder-on' so we can try different ones without changing the entire design.
With a little trick (connecting the solder-on boards with small pins) they can also be easily swapped.
All that is required is a tiny PCB with the proper connections.

What about this guy?

Other candidates are:

Bertl: lienarization LUTs, RCN, CMV register und alle generator settings sind fuer snaps relevant
Bertl: die addressaufteilung unterscheidet grob zwischen input pipeline (0x8*) und output pipeline (0x6*) wenn ich mich recht erinnere
Bertl: (oder umgekehrt :)

What is the price?

I'm not sure of what the desirable specifications are for an IMU, but the invensense mpu9250 is pretty easy to use and rather inexpensive. It has a sample rate of up to 32kHz.