Sorry for the delay, I was busy with Xmas.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Dec 26 2014
Dec 18 2014
Compression doesn't really help the lossless path, as you have to plan for the worst case, which is no compression at all.
@sebastian: maybe, it would for sure put a certain load on the memory controller (limited resource) and probably reading every 8th pixel would also give a very strange preview while not really reducing the memory load that much (access is 64-128bit).
Dec 17 2014
@philippej: if you check the image pipeline the AXIOM Alpha uses, you will see that the entire raw image is already present in memory so it can be accessed from the arm cores. It is very likely that the "normal" operation will be similar on the Beta.
Dec 16 2014
Low resolution means scaling the high resolution version down.
This is a very expensive (resource wise) and power hungry task.
Compressing the data with e.g. JPEG or similar is also very intensive.
While doable, I'm not sure we actually want that for the Beta.
Any news on this?
As usual, the question of using lossy or lossless compression will split the community into (at least) two groups :)
Dec 15 2014
Bluetooth is not planned for the AXIOM Beta, but it should be fairly easy to use an USB Bluetooth dongle on the Beta.
Dec 9 2014
I think for the AXIOM Beta this is already accomplished with the MicroZed 7010 (~200 USD) and the CMV2000 sensor (~200 USD) plus maybe 300-500 USD for the remaining parts.
Dec 6 2014
17:30 < Bertl> regarding T206, I think we need to define the Beta Staging process first, because the points listed there sound a little naive to me 17:30 < Bertl> we won't "have a batch ready" and then ask folks to "buy" for several reasons 17:31 < Bertl> a) folks will pick individual configurations and probably decide on sensor, shields, etc 17:31 < Bertl> b) we do not have the time/money to "make" a number of Betas in every configuration 17:33 < Bertl> c) we want to handle arbitrary reordering (folks who do not want the beta right now) as fast as possible, so that we can manufacture and test the Betas in a timely manner 17:35 < Bertl> we also have to make it as transparent as possible, and supply folks with the necessary information what is available when and how an upgrade path could look like (if we allow for one) 17:35 < Bertl> i.e. the first Betas will unlikely be the final Betas, unless everybody decides to "wait" (which is fine for us as well)
Dec 2 2014
Dec 1 2014
I would say it uses CET
Nov 29 2014
Forgot to mention, behaviour is the same on the 7020 MicroZed.
Nov 27 2014
Presuming "ISO" refers to ISO 9660/ECMA-119 the compact disc filesystem.
something strange is going on.
Nov 25 2014
I presume I should put a rootfs on partition 2, yes?
after adjusting the uImage to uImage.bin, this gives:
After a long search for a _working_ SD card reader/writer (I have now three non working adapters) I'm now finally ready to do some testing.
Nov 20 2014
Potential cooperation with inviso who consider to open up their framegrabber design and create an AXIOM Beta SDI Shield.
what is lsm?
Nov 14 2014
will test on the 7020 MicroZed ASAP.
yes.
A working boot image (SD card and TFTP) would be very useful in the near future (let's say 1-2 weeks).
Nov 11 2014
Electrical interface specification required.
Electrical interface specification required.
Nov 8 2014
The basic idea so far is to have a metal plate covering the entire sensor PCB (front side), pressing against the sensor base (thermal connection) similar to the heat sinks used for CPUs.
Yes, we stumbled upon the inogeni converter several months ago, we even planned to get one back then but it never happened.
I think gphoto(2) support might be interesting, although it seems to me that it is pretty much Linux only (which isn't a problem for me at all).
Nov 2 2014
Sounds impractical to me, as both, the planned Beta Board as well as the MicroZed have connectors on the sides, so they are likely to be blocked by those backward facing receptacles.
Just for reference, most HDMI receptacles are 90° (aka RA).
Oct 30 2014
If you want to run java(script) on the Governator, then you need to plan for more CPU resources, more power, etc.
Doable but not sure it is worth the efford. I.e. it might be simpler/better to use an existing embedded system with
LCD for this (e.g. a Raspberry PI or similar)
If we decide to use the PIC32MZ for the "Governator", we might be better off to extend an existing simulator to cover the hardware (LCD, Button) and avoid duplicating the code.
Can't we simply give him the necessary commit rights and let him commit the latest version himself?
Oct 22 2014
maybe informative.