#apertus IRC Channel Logs

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

morning folks!

hey, how's going?

morning usmankhan!

sensor is non trivial, as we support several sensors with different power requirements, here is a list of potential sensors with links:

on the input side, we currently max out at 2x 5V/3A, where one rail directly supplies the MicroZed and the other is used for everything else

Ok

from the eight regulated rails, typically two supply the interface board (currently unused) and six supply the sensor

the routing fabrics and other electronics usually consume a maximum of 100mA from the 5V supply rail, so the totla for all the regulated rails can be assumed to be around 2.5A @ 5V (to keep a safety margin to the 3A max)

alright

Sure

welcome niculescu_vlad!

Mr. Bertl, as I told you in the PM, I am interested to work on the fan controller and switching converter

What I want to ask first: is the fan controller a project for summer of code, or just a test task to be accepted in the SOC?

there are a number of related tasks and the fan controller can become quite complex

you mean the I2C block described in FPGA

then the various temperature sensors are located on different busses which kind of requires interaction with the control daemon T723

so it can become rather complex to integrate all the parts to have a closed loop system which actually regulates the fan according to all the gathered data

In other words, just the temperature sensors will provide the input data in the controller?

for example the power measurements and the current sensor state can be used to predict behaviour

Is there a list with all the sensors?

btw, I suggest you use a real IRC client instead of the web interface, as the web interface becomes annoying very fast ... there are a number of available clients for all platforms

regarding sensors, that also depends on some tasks

what is the purpose of this controller?

for what does it regulate the temperature?

for a camera circuit?

let me find a picture to illustrate

https://www.apertus.org/sites/default/files/ibc.jpg

in the version with enclosure, the fan is planned on the top of the enclosure, basically above the PCB stack

Great. So, it is a protection circuit. For this application, I guess over charge and over voltage circuits will be included.

but the cooling requirements are diverse, e.g. the Zynq is happy at 90°C while the Image Sensor should stay near room temperature

there are also state dependent requirements, for example if you are shooting (capturing video) you want to keep the fan as quiet as possible while still preventing the system from overheating

yes, the heat is one reason for the switching regulator ... we are currently burning half the power on LDOs :)

Yes. I guess you also want to keep the cooler at a constant speed. A future signal processing will easier cancel the noise if it is constant

so as you can see, the fan controller really ranges from 'easy' to 'hard' here

Elbehery_ meet niculescu_vlad, niculescu_vlad meet Elbehery_!

Ok.

ok. Thank you very much. I will get in touch with them

ok. That's great

hey niculescu_vlad, i am also working on the fan controller, at the moment i am trying to build very simple prototypes for both the slave and the pwm interface

no but i am trying to have a very simple model that can be enhanced, re-designed in order to understand more about the design parameters

I am working on the switching regulator project, and figuring out the small signal model of buck converter so that we can determine PID controller parameters. Feel free to let me know if you have any questions and I will do my best to answer what I have learned so far :)

Sure. This is good. I can design the pid controller for the fan

And also try to implement a variant of pwm generator

so far the i2c slave was implemented with an 8-bit pwm interface, but bertl mentioned that these might not be enough

But i guess the fun is not controlled via i2c. Just raw pwm

well, the reading are sent to the pwm via the i2c bus [as far as i understood from bertl]

correct, the relevant schematic is here: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_main_board_v0.36_r1.2.schematic.pdf

it has to be located in the east routing fabric (MachXO2)

which has only a very special connection to the Zynq

Yes.

[temp. sensors]-> I2C -> software->valid PWM values -> [PWM interface] -> fan

not all temp sensors are on I2C though :)

the sensors will hopefully be soon handled by the control daemon

the Zynq provides an on-die temp sensor which is converted by the Zynq internal ADC and can be read from userspace

(details can be found in the sensor datasheet)

note that small changes to the PWM circuitry are also an option for the next main board version, but we still need to handle the current interface as well (first page of the schematic I linked)

Ok. I have classes now but i will do a deep investigation after

how much should be the fan PWM frequency be? i am trying to identify the motor attached in the image above but can't identify it.

20~25k?

5V 120mA DC Brushless Fan

off for now ... bbl

Hello bertl, question about designing bidirectional protocol

every data stripped from their protocol is saved and then a packet is created

should i need to design protocol specific header now!!

hello ArrunM!

also note that we probably want CRC or ECC to ensure that the transmitted information is correct

ecc or crc will be taken care of

in both cases (CRC and ECC) an error counter should be incremented, in the ECC case, if correction is possible, account it differently

in case of the real-time wire updates the retransmission should be automatic (i.e. the next slot will update the values anyway)

but at least the error case needs to be handled gracefully

ok!!

hey Bertl_oO

Which are the communication protocols of the sensors?

32 lvds channels plus clock IIRC

not sure if you mean this by "communication" as well

That dri e

Sorry for spelling. I am mobile

then Bertl_oO will be able to help you

I was asking just about the communication between sensors and processing unit

I want to start implementing the verilog modules. That is why I was asking

i think bertl mentioned this earlier i quote "<Bertl_oO> the sensors exist throughout the AXIOM Beta, on different busses and readable via different mechanisms" but i am not currently aware of more details

good evening

o/

right so welcome to another IRC meeting

if you scroll down on the frontpage

https://wiki.apertus.org/index.php/IRC_Meeting_Notes

simonrepp: will also create the ones for today

Hey Alvis_!

I'm interested in working with apertus in GSoC this summer

I have a background in C/C++ and GPU programming

No problem at all!

just hang around, it will be over in an hour or less

I'll leave some messages here first is that ok?

the meeting happens here on this channel :)

Alvis_: do write them down in your text editor, you can paste them later :)

Ya, thanks!

okay, a number of things happened on my side since last time

)

we will also be able to use those boards for other stuff, like testing SFP and fiber optic connections

unfortunately I spent most of the remaining time with updates on 'old stuff' and reworking AXIOM Beta PCBs

i.e. I somehow assumed that the pinout on the mini DP connector would be the same as on the DP connector, and nobody figured that out :/

and then, as you probably experienced first hand, the GSoC 'students' are showing up, which I consider a very good sign

great thanks

real quick info mostly for the vienna apertus people: i'll be hosting a 2-3 days live art booth at the linuxwochen.at, and I requested the booth be placed next to AXIOM :)

\o/

that's all from me ;)

very nice

1. we currently have filmmaker/dop http://www.imdb.com/name/nm6877423/ here in vienna

do you know if it will be his main camera?

his main and only camera :)

another film project in parts shot with the axiom beta has premiere tomorrow: http://www.imdb.com/title/tt5902750

still a couple more to go and max will do the rest of the team talk editing

definitely

to fund a few fpga development related tasks in collaboration with timvideos.us

4k HDMI for example

and I have been working on visual concepts how a next interation of the Beta married with the Gamma could look like

nothing to share yet publically

can we already see it?

k

no drupal theme developer progress so far

very sad

would it be an option to install docker?

new axiom print flyers design is also progressing: https://lab.apertus.org/M11/36/

Bertl: docker is containerization ;)

https://lab.apertus.org/T741

davidak: I know :)

]

that should also be it for the meeting agenda

27.03 19 :00 ?

ok for me

fine with me!

I will send the invitations again

thanks!

have fun!

:D Thanks!

wb Alvis! meeting is over, you can paste your questions now :)

I'm interested in working with apertus in GSoC this summer

OpenCine: Raw Image Debayering Methods looks like an interesting task to me

Thank you!

Alvis: BAndiT1983|away is the person you want to talk to

oh ok thanks Bertl

it is probably a good idea to check out the OpenCine repository to get a feeling for the existing codebase

bertl i just pm you packet diag on https://lab.apertus.org/

here is fine, if the paste is longer, use a pastebin

off for now ... bbl

https://ibb.co/d0PxDv

Protocol data use data specific to application, ie reconstructing i2c or any protocol and the last byte store data to be transmitted!!

e.g. we could do 10 or 12bit chunks with 2-4 bits CRC/ECC per chunk

(just giving an example here)

if say 10 then extras gets wasted

Bertl_o0:Hi. So I was wondering for the bidirectional packet communication project, do we need to create a packet for handshaking (RTS/CTS) purpose ?

i.e. there is no need for request to send or clear to send messages

BAndiT1983|away, yea

Can I have more details about the task?

Alvis: what parts are you interested in?

The task is about porting the code to OpenCL/GPU right?

i'm checking the logs periodically, this week i will be just sporadically available, as i have to cure a bit

*includes

so debayering will be important there and especially fast processing

have you checked OC already and tried to compile the code?

so this task is about both coding the algorithm and porting it to GPU?

yup

oic

wait he already has the algorithm so it's not a phd thesis project right?

he invented an algorithm, which we want to reimplement on faster base

it was mentioned here -> https://www.apertus.org/what-is-debayering-article-october-2015

but depending on the stuff I work on, I'm checking IRC more or less often

or irritated

on the lab comments section

please let me know once you check it, i do have more questions

Bertl_oO: seen discussions about the protocol, checked the task and it said HDL or verilog, how is it done usually in FPGA?

both VHDL and Verilog are HDLs (Hardware Description Languages)

that is basically the way you 'program' for an FPGA

i'm not a really bloody beginner ;)

currently i'm using google flatbuffers for the daemon and it is really slim and fast, so i was wondering how it could be done on FPGA

so you build it in sdram and step over the bytes to send it?

while memory as 'ram' is available inside an FPGA, it is usually scarce and comes in blocks around 16kb

if you have to accumulate a larger (or unknown) number of packets, then FIFOs implemented with dual port memory are more common

really depends on the task, there is a lot of open IP out there, but usually it is geared to a specific task and adapting it often takes more time than writing it from scratch

Elbehery_: looks good (the TOP overview and code)

good night

night

where is master.sendData() used?

sendData is a task inside this module

BAndiT1983: wishbone is a nice and FOSS/OH bus system, but it is more suited for soft cores communicating with peripherials

of course, it also works nicely if you have pipelines of IP cores

there is an ongoing project to build a FOOS/OH bridge system

how is the protocol triggered between the FPGAs?

constantly? or has it some sort of interrupt to start new exchange?

replies get relayed back and will be returned accordingly

an interrupt would require some kind of 'interrupt line' which is not really available

just thinking about enumerating sensors which are present in the system, e.g. load description, ask every sensor/actor if it exists, reply to user what succeeded or failed

i've dropped a couple of steps, but you get the idea

Elbehery_: so if you have questions, now is the time to ask, before I go to bed :)

By "go to bed" he means take his socks off and slump onto a keyboard.

aha, okay , first thing i want to make sure about, does the big picture of the system i have posted on my github is correct ! i mean am i getting the whole big picture correctly ?

Have you seen Altered States? Cos that's what happens when Herbert exhausts himself.

https://youtu.be/67lYG7a4YOA

just watched it, man, the drugs were free in that time, i suppose

Elbehery_: it is correct, but not in all detail

this particular I2C bus is then transferred via the packet protocol to the MachXO2 (routing fabric east) where it attaches to the I2C PWM interface

Aha, do you think the design should allow more numbers of bytes for the pwm resolution ?

how big is the packet for PWM?

is it a stepper motor, because of pulse?

Aha, great

forgot the engish word -> rectifying

no rectification at the moment, but maybe we will do that :)

the current circuit can be found in the schematic on page 1

doesn't mean that we do not have to handle the existing circuitry as well

good night :) see you all tomorrow

so, socks are basically off :)