#apertus IRC Channel Logs

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

meeting time!

please /msg me if you want to report ...

Hi

the issues with the new version of the remote have been solved

this allowed me to test my gateware directly on the remote

to further inspect the signals being sent to the remote, Bertl hooked up the terminals on the remote to a logic analyzer

and as expected we were able to add bounces to the signals

yeah sure, I've taken a few screenshots of the analyzer

https://usercontent.irccloud-cdn.com/file/vocTOQco/Screenshot%20from%202021-08-16%2018-42-44.png

the bounces are randomized , the first one simulates a push button and the second one simulates an encoder turn

these are the signals generated by an automated script, which would help in future testing on the remote

It can do basic operations like switch off/on bounces, load a seed value for the PRNG that generates bounces, and press buttons and turn dials with a specified time interval

looking forward to see that in future automated remote testing

by this week I'll be submitting my final report

and add more documentation on the project

that's it from my side

*bunch!

hello

i had to fix some more bugs in other parts of the gateware, but that is done. i have a couple more points to address in the review and then that will be ready to merge

but after that i will write up my report and submit it. i don't think it will be very long, basically just a list of PRs and some words on each

i really want to try out the HDMI as that was part of the job, but that relies on Bertl getting a Beta ready with HDMI

i.e. the remapper and HDMI output

ultimately this is up to your mentor, but I do not think it is a big problem

that is it from me

ah okay

And you are welcome to do contributions outside of GSoC

but personally I would also suggest to focus on the final report now and not on the hardware verification

because hardware is never without some issues

and the Beta - Remote connection showed us how long it can take for a seemingly simple setup to get it working

great progress as always!

anybody else who would like to report but didn't /msg me yet?

please go ahead then

*timer 2

Besides I am finishing up with all transition animations..

So, will talk with mentors.... Want to continue working on the tasks..

That's it from my side :)

btw, now that we fixed the I2C for the EF Remote

but as I said previously, focus on the final report for now and getting the code cleaned up, etc

I spent most of my spare time last week on getting the Remote and the Remote Control Shield working and tested

we also discovered that the timing was a little too agressive, so when sending too many I2C messages, some of them didn't go through/come back correctly

the firmware ICSP programmer was also updated to work properly with the EF Remote

not too much else happened, although there was some slow progess on getting the new Betas assembled and tested

if nobody else has anything to report, the meeting is concluded

thank you :)

Thank you

off for now ... bbl

I tried to reproduce the problem with this: https://github.com/apertus-open-source-cinema/naps/pull/30

vup: have you been able to demonstrate the brokenness yourself?

(but I did not try with your pattern_dram_test yet

alright, i was about to reimplement read_packet_to_file. should it just return a bytes object i guess?

tpw_rules: I see that you inserted a StreamBuffer, but I cannot figure out why this should make a difference

it just seemed random pieces were dropped on the floor

yes

well, largely

maybe the address didn't get incremented or something

it's consistent

ok, but after how many bytes?

0x84d80 bytes in is the first dropped line

look at /home/operator/tpw_rules/presumably_correct_pattern.bin for the result from 5fa5114 and /home/operator/tpw_rules/committed_broken_pattern.bin for the result from e97dc99

now I just need to find something that can visually diff two 70Mb files :P

well, per camera word.

i moved all the stuff in __init__ of DramPacketRingbufferCpuReader there and it works

emacs fares surprisingly well with diffing them

maybe those actually get dropped because the address has now a 1 bigger latency?

hm, i wonder if at that point the fifo fills up?

they are all still in the build

btw also the SimpleStreamGearbox does not work. i assume all the tests pass but that results in 0 data transferred. maybe that is a clue. is it something on the transmit end in the Cmv12kRx?

hmm what does "does not work" mean?

curious

yeah the tests pass

sure, it will take a while though, i don't keep compiled gateware around

(15-20 mins)

tpw_rules: hmm can you try to add a StreamInfo before and after the Gearbox in both cases?

yeah

hm, looks like it is my fault. or at least whatever condition is propagating all the way back through the fifo and it is filling up

ah, does it not handle non power of 2 division ratios?

yeah

tpw_rules: yeah, having some valid_not_ready > 0 for a stream that cannot actually buffer the data means you will drop some, which matches exactly what you can observe

and why is the FIFO backing up? there must be some interaction with the fix that breaks bursting or adds excessive delays

I think somewhere you just need to be able to buffer one more word

it should not fill up

yeah maybe

ok, so SimpleStreamGearbox works now and significantly simplifies the logic but the timing is of course much worse

lol

loooool

hm, yeah it is better in the sensor domain. maybe i will switch later