#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

good day

including super fast rebuild caching in case of only driver changes

hello!

Good Morning!

MEETING TIME, who is here?

yeah sure

I integrated them with the existing hardware, where some problems occurred but I managed to solve them with Bertl

note here: the channels are connected at the parallel interface and generate a 'fixed' pattern

many thanks!

Hi

I initially was using the driver developed last year to upload my bitstream on the MachXO2

and as discussed earlier in the chat, the machXO2 was being reset, when the driver was being unloaded

hopefully I can get it uploaded succesfully and finalize my gateware by this week

did you work with bluez to get this sorted?

I think it would be good to remove the reset from the driver unload or at least make it optional (e.g. via driver option)

ok, another option bluez suggested was to use svf files to generated the commands since the driver supports openocd

okay, that would be the third option then, to use the openocd interface the driver provides to send/receive the jtag data

right, tpw_rules is next, please go ahead

yay!

then the next step is porting Bertl's pixel remapper from verilog and we should be able to see some images from the sensor soon :D

yes, sorry

but it does seem to work well on anuejn's beta. i want to try it on the others when they have sensors just to make sure it is robust

that should be it from me this week

many thanks

BAndiT1983 shared some news but excused himself from the meeting

https://i2.paste.pics/82e0a2098b5f7ce278a7532cc469abe9.png

eppisai: are you here?

we might be able to collaborate with the technical university vienna on CNC manufacturing on camera related metal parts

hi..i don't have much progress to report

right

eppisai: what kind of issues?

:(

did you try it on another laptop as planned?

i have switched the cables, tried on another laptop.. showed nothing..

right Bertl please share your closing words/progress with us?

well, last week, some of our students touched the remote hardware the very first time ;)

and some issues were found which resulted in me reworking one of the betas to make it work as intended

I also spent some time on further testing of the Axiom Beta PCBs and will hopefully get this week to actually assembling new Betas

great!

the video stream is still an open issue, I investigated youtube and twitch but both require a quite complicated setup and have huge delays

5-15 seconds

maybe an option, haven't considered it yet

also what about just a basic nginx + rtmp plugin setup?

I'm open for all solutions, the best performance/ease of use I had so far was with a server at the university of vienna

i think that time is probably fine?

unfortunately we cannot use the server for our streaming purpose

that's it from my side for this week

anyone else who wants to report/share anything?

I should be able to figure that out, it is likely some rtsp proxy

thanks for the moderation!

thank you :)

I see

what was used on the viewing / receiving side?

yes, it was an rtsp stream with ffmpeg

client can use whatever app they want

sure, but the client can also affect the latency, if I understand the server right, it has the ability to "transcode" from rtsp to hls for example, which will probably add some latency compared to just listening to the rtsp stream

Bertl_oO: did the rtsp-simple-server work behind nat?

so here is my report (a little late to the party):

now we produce zip files that can be executed via python and are self unpacking

this fixes some issues with to long arguments and is generally much more hackable after building the bitstream

we now have better caching (does not rebuild the bitstream if only driver code changed)

thats it from my side