It is still relevant, although it has somewhat progressed.

Sebastian and I are on IRC most of the time and we use it a lot in general, so I don't think a weekly IRC meeting would be a problem.
Still leaves the question of agenda and summary and probably finding good dates as well.
Also it will be additional work for somebody to organize and coordinate.

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.

Other candidates are:

Why stop there, why not 16K 600FPS ... :)

Do you have any open source stacks/designs for handling thunderbolt?
If so, please share with us.

The problem is simple:

• we have 12 LVDS lanes with up the 1.5Gbit of encoded data (officially 1.0Gbit per lane).
• SATA requires 3+ Gbit to be useful, i.e. we would need MGTs to handle that.
• UHS-II can be done with a cheap FPGA

Didn't know that BM decided to make the PCC FOSS/OH ...

We need to record metadata anyway, for example to keep information about exposure time, sensor register settings, etc.
If we decide to do it in a separate file/stream then we need very precise timestamps (or frame numbers) to go with.

Sounds nice! Do you happen to have a FOSS/OH solution for PCI-E 3.0 and M.2?

Note that fairphone does not limit itself to "fair" components.

All our plugin modules have an EEPROM on the I2C bus.
Recent Power Boards feature en EEPROM on the I2C bus as well.
The Main Board can be uniquely identified via PICs and MachXO2s.

The fact that the task is sitting there for a year now means that probably nobody is interested enough to work on it.
As you are very interested, maybe you could start working on the conversion.

We now think we know how UHS-II works and where the challenges are.
No hardware tests have been concluded so far because we still need to write software to utilize UHS-II.

Actually (nitpicking here :) the IMU doesn't record the motion, it tracks it with several sensors.

http://forum.arduino.cc/index.php?topic=22327.15

Specifically test/enable CEC and HPD as well as DDC

While it certainly works well in post processing, this probably isn't a good idea for real-time stabilization in the AXIOM Beta.

Personally I have no problem with that.

Dave Jones is an iconic figure.
You might not know him, and he is certainly not always right, but he is one of those internet phenomenons.
If we can find something better on the topic, it would be very welcome, if not, it is probably a lot better than nothing.

Currently we have Eagle design files (switching to KiCAD is still on the roadmap), so we need to have some kind of auto conversion for now if we want to utilize KiCAD for the 3D export.

Altera MAX 10 doesn't seem to be a good option as far as we checked.

For any LCD/LED/eInk display that we want to consider, please first make sure that a datasheet is available and link it here, so that we can do some basic technical plausibility checks ...

Sounds great, looking forward to it in anticipation!

Well, personally I prefer a full width adaptive layout anytime over a fixed width layout.

we also want sdcc and gputils (latest version) for pic related code and general tools like vim, gcc, python, etc for various tasks.

But we definitely need a different video to show the process (if we want to) because it is ill advised to promote weapons in public :)

Yes, interface board with FPGA is still on the roadmap :)

if we want to go for an eInk/ePaper dispay, we need to get a sample for testing.

HDMI Module and outline has been fixed (for the 1x HDMI module).

Was mit einigem Aufwand moeglich waere ist eine Bounding Box um tPlace, bPlace zu legen (oder alternativ um die pads).

Unwahrscheinlich, da Komponenten quasi beliebige Gestalt haben koennen.

AFAIK, CFast is basically SATA, so something different :)

I'd suggest to use at least five states (not started, started, good progress, almost finished and finished), otherwise most tasks will hang in the "in progress" state for a long time. Note that the "moon phase" concept and the color coding could be used as well.

@sebastian: please check with Andon if they would do a two-part version (no connection between top and bottom block) - like the one we are investigating from Selwyn - and if, at what cost.

While it sounds appealing, I don't think we can have this one central place because there are a number of very different requirements to different types of data.

Well, it hangs out of the page right now ...

As sebastian explained, UHS-II is electrically different from "normal" SD, so the only way to make this work is through special hardware.

What about simple roman numerals?
If there is a need to denote different parts/variants, add a letter, e.g.

Just a note: in general I prefer mailing lists because of the simple off-line backup and accessibility.

Option 4:
Get 4x30 µPGA blocks which match the Andon pins from a third party.

I went ahead and ordered the Kingston Reader as they are very cheap on CLEVERsparen.at, so that leaves the cards and the card sockets.

Maybe get two of these (one for analysis, one for actual use):
http://www.amazon.com/Kingston-Digital-MobileLite-Multi-Function-FCR-MLG4/dp/B00KX4TORI
http://geizhals.at/kingston-mobilelite-g4-reader-fcr-mlg4-a1128626.html

We will do a different HDMI module, I should have more details soon.

IMHO, if there is no demand, no need to spend time on keeping it up-to-date.

The first thing which comes to my mind with the "heat sink fan" is precession.

We got the 90 degree question at NAB, from somebody who was interested in using a lot of the Betas side by side.

The PNG button below the AXIOM logo says "apertus" ...

@FrancoisGandon: That would be very much appreciated!

Back for the alpha I started writing my own devicetree and I simply copied the relevant part from there (adjusting to the decompiled devicetree of course).

u-boot networking is still a big problem, especially for TFTP based boot.

QSPI works with the correct devicetree entry.

What happens is that the GEM is initialized with the u-boot hard coded MAC address, and changing the etheraddr later in uEnv.txt does indeed change the u-boot generated packets, but it doesn't update (or reinitialize) the GEM, so it still only receives packets for the hardcoded MAC.

It seems, u-boot doesn't update the GEM registers.

btw, where can I find/get the kernel/u-boot sources you used?

u-boot seems to have a problem with modified MAC addresses.

Here is a better one:
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/module_single3.png

Any progress here?
Can we expect something in the near future?

Ah, sorry, for the remote less power is required of course.

If you find a panel that does 6-41V with roughly 3-5A then it should be fine.

@sebastian mostly it means that we probably won't have the resources to run a 3D LUT on full data, especially not on 150+ FPS 4K data in realtime, and it isn't necessary either, as this is better done in post.

The Test Pattern is precisely that, a pattern which is sent from the sensor _instead_ of the actual image.

My preference (as stated on IRC):

Do you mean internal or general?

I presume differences in the two potentials (i.e. insufficient grounding).

Well, actually the ZedBoard has proper ESD protection on the HDMI port (D12,D13, and D14).

I rolled my own devicetree for the ZedBoard, it might make sense to do so for the MicroZed as well.
Also some devices will not be required in the kernels (because the hardware is not there) and others might need to be enabled (because the default is to disable them)

QSPI is not accessible under linux with the image:
[ 0.746324] zynq-qspi e000d000.ps7-qspi: pclk clock not found.
[ 0.750826] zynq-qspi: probe of e000d000.ps7-qspi failed with error -2

We should really move that to a faster medium, please ping me on IRC in the future if you need to know something to avoid further delays.

"black shading" sounds interesting, please elaborate what it is and how it is done.

The explanation in the link doesn't make sense to me, please give an example for discrete values (e.g. an 8 bit range)

We have about 16Gbit/s bandwidth to the shield, doing the math explains why this isn't really "easier" :)

We plan to have two different HDMI shields, one with 3 ports and one with a single port (maybe 2 ports if we have enough bandwidth) which will allow for higher pixel clocks and thus larger formats.

Adding a complete image path/feature cross-switch would be possible but very expensive FPGA resource wise, so I would prefer to select in advance which path can apply what features.

no, it doesn't because it seems to execute the wrong script.

Please, if possible, provide some examples for good/bad features so that we can avoid making the same mistakes others made and strive for the "best possible" implementation :)

Nice! Please investigate how we can get our hands on such a board for testing (in exchange for 200 USD of course).

For me it would make most sense to check each channel in the raw bayer data for over/under a certain threshold (which could be different/weighted) as the main idea is to prevent information loss from clipping, no?

yup

Just to sum up, the given algorithms are quite complex and require several rows (min 3) of data.

Direction of the stripes?
Color of the stripes?

Maybe test it out on the Alpha?

@colinelves at the moment, number 0 (getting a still image from the sensor) is what we focus on :)

Please define "image frequency" and explain how it is calculated from the raw Bayer data.

Judging from my experience with "smart" devices (including consumer cameras, phones, tablets), such a "guessing" will consume a lot of resources and get it right in at most 80% of all cases and will annoy in the remaining 20%, because it just can't get it right there. Note that the 20% will be the ones everybody talks about :)

Problem seems to be power consumption related.
I got it to boot after applying additional power (i.e. the USB power is insufficient).

When manually booting with bootm 0x3000000 - 0x2A00000 it boots up to a certain point where it simply resets.