#apertus IRC Channel Logs

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

good morning

(with dramatic music, by accident :D)

simonrepp: nice :)

we currently still use Eagle. the Eagle designs can be found here: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/

we also use a script to generate gerber files from the board files. se6astian has the details on that

so there's different 3d part libraries to choose from?

.brd? .sch? :) ...

the .brd are the board design files

i see, wires, parts (with identifiers), cool

http://3dbrdviewer.cytec.bg/

se6astian: yeah, just found that as well

big problem though: the boards are not purple!!!!

ah, no, you can select the color :)

I tried with the power board, and it looks like there are 10 of 250 components rendered

but maybe it can be adapted/improved ... no idea

so i mainly have 2 questions still:

http://www.traceparts.com/

and assuming i manage to create script(s) that successfully gather all parts and correctly place them according to the .brd files - will i get complete 3d representations of a board, or are there things on the board that are NOT represented in the eagle designs?

the PCB itself is represented in the eagle files too, but it is probably way easier to use the gerber files for that, but I might be completely wrong here

http://www.digikey.com/en/resources/3d-models

farnell has the 3D models linked to the parts

I'm sure there are many more, but for our purpose it would be more than sufficient to have a custom part library

yeah i see, looks like i'll just have to see what's to be found where and then put together all the pieces step by step, working through everythign that's missing

are the gerber files for the pcb itself also at the /Stuff/AXIOM/BETA/ location?

i might get back to that offer, but i think it would be cleaner to do the mapping inside the EAGLE->3D conversion pipeline itself

(unless there are components where there is no unique identification possible from the EAGLE file itself, there we might have to augment right at the source i guess)

exactly :) and less organization required for me as well if i can just adjust the mapping myself

okay

well great, i think i can start with what i have here :) thanks so much!

some gerber files are linked on the wiki: https://wiki.apertus.org/index.php/AXIOM_Beta_Main_Board_V0.36_R1.2

regarding irc meeting -> my initial suggestion would be 15h or 16h CET, and during weekdays (from my side no preference for any specific of them), does that sound good for you guys?

16:00 CET sounds good

I did a doodle recently with 4 other team members and we settled for 19:00

monday/tuesday I am most flexible with time

how about monday 19th at 19h as a first date?

there is a project to do 3d visualization of brd files in sketchup

I have an appointment on monday 19th at 19:00 I am afraid

another appointment :)

yes its the typical "after work I am free" time :)

ok then other suggestions please :)

if you're fine with missing out already on the first test meeting se6astian then we can do mon/tue 19h anyway if that's a good general choice for everyone (just not for you specifically the first time)

ok then i'll just pick either of the two next week and announce that

i'll announce on team@ and .. somewhere else?

ultimately i think this is something to publicly announce as well (it's a great way for the public to see activity and openness for a project, at least that's how i experience it for the blender irc meetings eg), but maybe for the first test meetings we can figure out how it works for ourselves, then we'll later we'll be able to pull off sensible meetings with a larger audience as well :)

and axiom-dev@ with 48 members

probably with a smaller circle first

i'm documenting this on lab.apertus.org right now, and will announce it the next days

ok, documented: https://lab.apertus.org/T260 thanks everyone, i'm off :)

off for now .. bbs

ping

hey

skinkie: you wanted to know the details of the Betas custom kernel herbert created IIRC

but it did contain a lot more before xilinx updated the kernel and it might contain a number of other patches in the future when we add custom drivers/fixes

Bertl: is the generation of the kernel and bootloader something that is stable?

bootloader is unclear, we currently use the very same bootloader files we generated back then

for the environment I promised to follow up with a separate e-Mail but haven't had the time yet to work it out

off for now ... bbl