#apertus IRC Channel Logs

MEETING TIME

quick updates from me: we discussed moving the wiki to github hosted asciidocs with CI builds of PDF and HTML content - nothing decided yet but the topic is moving

anuejn and me plan to meet next monday to tinker with the axiom raw recorder setup/solution and push that forward hopefully then

but had no time to do so yet, but bertl briefed me about the steps already

well, I spent the last week investigating and evaluating an idea of mine for a cheap but reasonably powerful axiom recorder solution

1) how do we get the image data from the Axiom Beta into the recorder?

so far, the best solutions for 1) have been various capture cards, mostly USB based but also PCIe cards

(at least not for off the shelf solutions)

the second part, the storage system is a problem too, but this seems to get better at least if some NVMe is available

this chip basically is a custom processor and chipset solution with quite some peripherals and a number of PCIe lanes which connect it to the main processor on the RPi5

this is all connected via PCIe gen 2 and one PCIe lane is still available from the main CPU which can be used for something else

no, it is not easily available, but the good news is, it comes on the RPi5 and that is available for less than 100 bucks

and the RPi5 itself was the basis of my tests

and turns out, the MIPI side is almost perfect for us

(peanut gallery again: mipi is horrifying to implement afaict if you would want to do it yourself)

for now, we do not plan to do MIPI, although that could be the next step

so we can easily connect two HDMI outputs at 1080p60 in full raw to the system and also capture it successfully

one is to attach an NVMe to the one remaining PCIe lane

this gives us a sustained throughput of 850-950MB/s

so far I tested a setup with one HDMI to MIPI and recorded 10 minutes if 1080p60 at 3x8bit data directly to NVMe

and the test was done with pseudo random data from the Axiom Beta

it took about a second for the stream to stabilize (at the start) and from the 36000 captured frames I got one frame with an error

https://somlabs.com/product/dsi2hdmi/ ?

for the HDMI to MIPI solution I used cards based on the toshiba TC358743

this can be directly used on the RPi5 as it has support for the four lanes and a cable option for the CM4/zero which is the same interface as the RPi5 has

and when I contacted them, they sent me two of those boards for testing as well

that said, the HDMI to MIPI route could in the future, assuming that we can source the toshiba chips somewhere, be integrated into the Axiom Beta plugins

alternatively we could use other chips or cheap FPGA solutions (like the GoWin parts) to do LVDS to MIPI CSI directly without the HDMI step

another approach we are currently investigating is to use USB-C in Alt mode for HDMI, which in turn would allow to have 3 USB-C HDMI outputs on one dual plugin module

two of those connections could go to a custom HAT/RPi5 board which contains the two converter

and finally, with the detached sequencer, we can basically transport the full sensor format over those channels at reasonably high frame rates (>40FPS)

note that you could even add USB 3.x sticks for direct recording or similar as long as you distribute the bandwidth accordingly

well, that's it from my side, if there are any questions, I'm happy to answer them

which comes kind of naturally if you record each MIPI CSI stream to a separate USB stick/bus

do the mipi csi video inputs show up as v4l sources or how did you record/view them in your tests?

that is a setup script?

v4l2-ctl --verbose -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat='RGB3' --stream-mmap=4 --stream-skip=3 --stream-count=36000 --stream-to=/dev/nvme0n1 --stream-poll

very nice

*involves

yeah thats fine for us

so we can't simply send 2048x1536 for example (as we do on the Magewell cards), as the toshiba chip does not recognize those formats

which is basically a second base for the RPi5 where the NVMe goes

the X1001 ? https://geekworm.com/products/x1001

ah, great

I plan to do some more tests with USB storage and the second MIPI channel this week (the second adapter just arrived)

reading/writing mipi/ssd?

about 50% of one core is involved in MIPI capture and writing to NVMe

(there are four cores available on the RPi5)

and a GPU, where the data can also be routed to

very nice, yes

of course, but we still have minimal latency on the 'third' HDMI output from the Beta, so not a problem for real time stuff

super nice

so we do not need to worry about access as well as software support

anything else to report/share?

together with the Ninja V+ from BogdanXOR for testing last week

yes, I will test those soon as well when I get to my dupont cable collection

anyone else who wants to report?

thanks for the moderation se6astian!

I have some proven-to-work gateware for mipi dsi transmission on the lattice ecp5 parts

what do you do for a phy?

ahh, i didn't realize that was sanctioned

https://www.latticesemi.com/view_document?document_id=52562

though for csi we could get away with the simplified diagram on page 13

I think that adapting the code I have for CSI would not be a lot of work

Bertl: do you think that would also work for 7-Series HR IO?