Install script is already in repo. One for RESTServer will follow at some point.

Moved related parts of code and started adding unit tests.

Added install_daemon.sh script.

Added Main.cpp, adjusted RESTServer code accordingly.

I'm working on it. Actually Step 2 is already fully automated.

Some recent discourse for posterity:

Does anyone have a list of the Beta's rails and realistic maximum currents? (The description in @usmanwardog's post above is a bit hand-wavey ;)

@BAndiT1983 As client side looks rather small I would suggest vanilla javascript.

@maltefiala What about Meteor or Dart for the client side? I'm not that deep into web development jungle and if one searches the web, then thousands of frameworks can be found.

Reference for golang REST service, required for basic testing at the moment: https://thenewstack.io/make-a-restful-json-api-go/
Used JS REST lib (client side): https://github.com/marmelab/restful.js/tree/master

Thank you for reviewing my proposal. Sorry I wasn't able to respond earlier, I was busy in a 36 hours long 'Smart India Hackathon', it's over now. I would definitely work upon on your suggestions and submit the final proposal into the GSoC system in few hours.

@anuditverma,
thanks for your application! I just finished looking at it and am looking forward to receive your final application tomorrow.

@anuditverma,
thanks for ping, will answer tomorrow

Hi @maltefiala,
Please have a look on my proposal draft, allow me to utilize your valuable feedback to improve it further so that I can upload a final version.
Thank you, waiting for your response.

In T734#11374, @Bertl wrote:

@mash: while that is a good idea for cutting/post software, this is not an option for the AXIOM Beta as there is no GPU to accelerate anything.

@mash: while that is a good idea for cutting/post software, this is not an option for the AXIOM Beta as there is no GPU to accelerate anything.

It is unlikely that the lens system manufacturers will disclose the information about their lenses, but of course, it is worth a try contacting and asking them.

I figured out that camera lenses are using 16bit addressing system and SPI protocol. We need to send and retrieve 16bit data from lenses. And then we need to decode that data stream to human readable. Unfortunately, the data that can be sent and retrieve to lenses is different for every model of the same lens manufacturer. Camera manufacturers include all the information(focus length, aperture range) in their firmware through camera lens ID code. Either we need to get data stream information and observe that by oscilloscope and function generator and translate that to lens information but we've to perform that for every lens model on the planet or else we can ask the camera manufacturers about their own SPI system (what bytes for what).

Every manufacturer has different protocol for their lenses.

Clarify me whether the communication system between cameras( of different manufacturers) and lens is same or do we need to implement different communication protocols for different camera manufacturers? Do all lens systems from various manufacturers follow same communication protocol to their cameras?

Sebastian, if there's need at some point in time then i can translate the article natively, if machine translation is not clear enough.

the waveform and vectorscope feature requests are long outstanding wishes.

Is it something like this (http://www.ixbt.com/digimage/canonautosonyl.shtml) that you want to implement ??

Hi,
Is it something like this (http://www.ixbt.com/digimage/canonautosonyl.shtml) that you want to implement ??

My very direct and subjective feedback:

In T765#11343, @RexOr wrote:

@merikhan36 - Do you have any FPGA related experience?

@merikhan36 - Do you have any FPGA related experience?

Any feedback on the suggested project will be appreciated :)

Thanks for your application draft. I will look at it following week. If you don't hear back from me until April 1st, please ping me.

I have prepared my first draft of the proposal, please review and comment wherever necessary, it will help in improving it more.

Thanks, very interesting!

Can you elaborate more on the technical background of this proposed feature and planned implementation?

Sorry for delay, yes @sebastian this is my GSoC project proposal.

Sorry for delay, yes @sebastian this is my GSoC project proposal.

The implementation has to be done on both FPGAs (Xilinx ZYNQ and Lattice MachXO2).
As this is a FOSS/OH project, you have to limit the design to IP without restrictions on both sides.
Using platform specific primitives like DDR I/O, SerDes or FIFOs is not as problem, as long as they are variants to a generic entity (which can be adapted to a new platform with little to none effort).

Hi Bertl,
I am final year undergraduate of Electronic and Telecommunication Engineering, University of Moratuwa. I have gone through the description of the project that you are posted and I am clarifying on it. I have done many FPGA related projects and I am very interested in this field. I have few questions on this project.
• Do we have to implement the communication interface in the both Xilinx and lattice fpga platforms?
• If yes then will we be able to use the ip cores like xilincs fifos?
• Or else should it be a single implementation which can be run on both platforms?