More details: UP 2 Squared with Intel Pentium Quad Core up to 2.5Ghz N4200 with USB3 OTG, 1x SATA, 1x mPCI-e and 1x M.2 2230 E-key starting at around 320$ excl. taxes.
Dimensions: 85.6 x 90mm
- Queries
- All Stories
- Search
- Advanced Search
All Stories
Mar 8 2018
Mar 7 2018
Mar 5 2018
"We are an association of visually impaired photographers since 2009, participating to photographic festival exibitions. We are based in Carcassonne, in the South of France.
Mar 4 2018
@malita With HDMI know-how we mean that you have a basic understanding how HDMI works, how the data is encoded and transported between source and sink and what the building blocks of an HDMI image are ... Tim does a nice overview of HDMI here https://media.ccc.de/v/33c3-8057-dissecting_hdmi
Hi,
I am from University of Peradeniya Sri Lanka. And I like to engage in the project. Can you please explain what is meant by " HDMI know-how " in the prerequsites section?
Correct cmv_hist3 link: https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/cmv_tools/cmv_hist3
Mar 3 2018
Mar 2 2018
All the important stuff (until new videos are added)
Mar 1 2018
Great! I take it you mean this flavor of libwebsockets: https://libwebsockets.org/
We can test by replacing Pistache by libwebsockets, but it takes some time (maybe on weekend), as currently preparations for GSoC and my packing for move to new city are ongoing.
Here is some information about websockets vs. ajax
Feb 28 2018
@jatha Have you set Travis CI up?
That sounds great!
As a new Beta is finally connected to the server, i could test again if i can finally set gain through daemon. If it works, then more usage cases can be implemented and tested. As it is necessary before we know what we need to supply to the camera, but most work should be done by daemon, also using pre-defined (stored in binary files) stuff like FPGA bitstreams.
As far as the API goes, I would like to suggest versioning it according to a reference standard that documents the REST call, its expectations and all values. The current state (at T865) is what I would consider to be V0 - because it is not systematically standardised. As soon as everything is "written in stone", I would propose promoting the API to V1.
No complete reference yet, as it was created while developing. Have no direct access to the hardware, so it takes more effort to test.
Yes, looking often into Lab and IRC.
Andrej, are you tracking this conversation too?
Is there a complete list of all current and valid REST package requests?
Cool - I saw that referenced in the C code, but didn't know how to expect / construct it from the JS.
There is a thing missing, which i forgot to tell. REST sends a JSON package, format is described in https://lab.apertus.org/T865.
I totally understand the issue with node running on the box, and is why I suggested the C library for websockets.
I created an overview block diagram with @BAndiT1983 of the current situation which hopefully provides some insight:
Should we make an issue here https://github.com/apertus-open-source-cinema/beta-software/issues about registering the available components and middleware routes in order to match the interface expectations as detailed here:
another interesting candidate: http://www.up-board.org/ai-edge/up-core-plus/
no price or details on the expansion modules (SATA, PCIe) yet though
- One thing to keep in mind is that we should get a confirmation from the camera back to the remote that a particular setting/command was applied successfully.
- Also can we push commands from camera to webremote currently without polling?
Sounds good.
A readme is a good idea.
Feb 27 2018
Added those to the doc. Any other questions let me know and I'll ask all together during next contact.
Is the foam ESD safe?
Is it conductive?
maybe move this to the OC git repo, which would make it more likely to be foud by people who want to contribute?
many thanks :)
now, can we finally make this new structure a bit more clear for people coming from github? this would be quite nice. maybe making it clear by putting a readme inside the hardware repo which links to the fileserver and/or to the wiki and clarifies what should go into git and what belongs to the fileserver.
Also, there is a small issue: ./run_image.sh dev/microzed-image-1.3 runs run_image.sh which is not in the project. Maybe it is ./runQEMU.sh ?
There are still issues with the build scripts: most importantly, the sha256 checksums do not match for xilinx. (./guest-images/dev/microzed-image-1.3/build.sh, which should be ./guest-images/dev/microzed-image-1.4/build.sh, given the patch at https://github.com/apertus-open-source-cinema/axiom-beta-qemu/tree/ffe128c9cbff62e75bd0c5d44ef1f914c393fd8f)
@davidak can do, but what structure and location do we want for those?
We can remove powerboard test boards, they were actually built but only for evaluation/test purposed before the actual power board design.
After discussing to remove the files from the wiki and only have them on github, we decided that the past workflow works good for developing hardware and we will keep them organized in the wiki.
Feb 26 2018
Logs from LinuxMint 18.3
The following is log of build on Manjaro Community 17.1.5 (arch)
https://pastebin.com/GZ136Ure
Looks good!
Dimensions: W11" x L10" x H7"
I will most definitely also be there this year, and we are planning on running a KinoKabaret Assembly using the KINOÏT Platform. It would be really great to work together and let some hacker-filmmakers get some experience with the AXIOM.
I took the local-storage route for the vue.js version of the interface that I built. Here is the flow:
Legal issues? If you mean JetBrains Webstorm - there aren't any legal issues. The EAP version is their prerelease of their software and it is entirely legal and free to use - without registration. Otherwise I wouldn't have shared it in the VM I built.
Aha, so you want to risk legal issues? VSCode is widely accepted, even by Linux community.
Yeah, but I really avoid Microsoft at every level in the stack - and I won't be installing visual studio anything on linux. Webstorm is simply the best because the entire environment is built for the kind of engineering needed by web developers...
To bypass problems with licenses, you can use VSCode, which has a ton of plugins for different areas, also Node, Vue and so on.
I just made you all a VM Snapshot for Oracle VM VirtualBox. It's current state has:
I also first had the issue that all the JS and CSS files were reported 404 by the python SimpleHTTPServer even though they were all in place...
Will do it later, if new commits are still not working, am at work now and cannot access my private machine.
I really didn't want to sound condescending, I hope you don't have that impression. In the future it would be excellent if you would make a normal issue report at github that has:
JS was enabled, but browser refused to apply a CSS file with cryptic name (seems like hash). Am not new to web development, doing it daily in my regular job (although it's GWT and Java mainly).
and pull the repo again - there seem to have been a few files in the dist folder that weren't added to the repo yesterday
ok... what security measures? have you enabled javascript?
A server was used, which was always sufficient for web development. Browser refused to apply CSS, because of security measures.
FYI - I updated the README at the Git Repo - and found a couple files that weren't included in yesterday's commit.
You will see a blank page if you just open the html file in your browser - but that just won't work, sorry. You need to serve it (like I said in the message.) In fact, after I finished the build process this is what it says:
Feb 25 2018
Using Windows, npm runs through, at least no errors while getting packages. But the HTML page is completely blank, console output in dev tools is showing several resources with 404 and browser refuses to apply the CSS file. Could you take a look, please? Maybe a fresh VM to check if it is possible to build and display the stuff?
I hope it is dynamic enough.
Feb 24 2018
We unified the Control software, its now called "AXIOM WebRemote" (also moved it to the correct folder on github):
https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/http/AXIOM%20WebRemote
https://wiki.apertus.org/index.php/AXIOM_WebRemote