<wolfspraul>
marcan: just asked rejon who confirmed that you cannot put the laser rendition of the bad apple clip under a cc license
<marcan>
right, I figured
<wolfspraul>
I like the fact that it's scanned from a video
<marcan>
maybe once I learn japanese I'll be able to ask for permission :)
<wolfspraul>
maybe we can scan another video that is already cc licensed?
<wolfspraul>
it's not super important though, just that I think that's a capability worth talking about
<marcan>
yeah, but it's going to be hard to find something that works that well
<marcan>
well, technically, an early prototype of the tracer is in the LASE demo video - used for metaballs and fire, which are first rendered as bitmaps
<wolfspraul>
understand, needs to be pulled through some black&white naturalization or high-contrast or whatever filter
<marcan>
(after that was when I had the idea of plugging in ffmpeg and the whole video tracing thing took off)
<marcan>
oh, it doesn't require that
<marcan>
I have a Canny edge tracer that looks for edges, regardless of whether the video is black/white
<marcan>
and does a pretty good job
<marcan>
but of course it can't magically turn a normal video into a perfect stylized shadow art thing like that bad apple video
<wolfspraul>
understood
<wolfspraul>
real life problems :-)
<wolfspraul>
but the idea is still cool!
<marcan>
I've been meaning to apply it to a realtime depth image lifted from a Kinect
<rejon>
that is pretty cool marcan
<marcan>
that should give us something very similar to the Bad Apple video, but from a live feed :)
<wolfspraul>
marcan: ah yes, I think rejon is openclipart founder :-)
<wolfspraul>
rejon: is that right Jon?
<marcan>
there's an svg2ild in there for static images (that can be embedded in openlase apps), though it doesn't (yet) do animation
<marcan>
(that's how the LASE title and the Euskal Encounter outro were done for LASE)
<wolfspraul>
so since marcan has not gone to sleep yet, just for the record the idea being discussed here is to manufacture his laser projector as copyleft hardware
<wolfspraul>
tuxbrain was so super excited about it and said it had to be combined with milkymist one - SOMEHOW
<wolfspraul>
:-)
<marcan>
(fwiw, it was always meant to be open hardware ;)
<wolfspraul>
sure, we know
<wolfspraul>
it will take some time for more people to understand how it's built, how it could be used with our video synthesizer, and so on
<wolfspraul>
marcan: it would be awesome if you could do the electrical design in KiCad, we've done a lot of work with KiCad and come to like it
<marcan>
that's what I was thinking about using
<marcan>
I've never used it but it's been on my TODO list for a while
<wolfspraul>
rejon: (marcan correct me if I'm wrong) my understanding of the design is that at the core it's a cheap laser pointer, then some mirrors and electro motors for positioning, and a microcontroller/circuit to integrate the whole thing
<marcan>
Eagle freeware being closed source and limited, and gEDA, well, can be a bit annoying at times
<marcan>
kicad looks good, I've just been waiting for an excuse to try it :)
<wolfspraul>
marcan: you are in the right place here, we've done _A LOT_ of KiCad work
<marcan>
cool
<marcan>
as for the hardware, it's even simpler
<wolfspraul>
data is fed to the projector mainly in the form of audio channels, on M1 (Milkymist One), maybe we can hook it up over USB...
<marcan>
there's a tiny micro but it's just there for some power/safety stuff
<marcan>
the core is just a USB sound card feeding straight into the motor drivers
<wolfspraul>
marcan: if you don't have a repository yet, feel free to use the projects.qi-hardware.com server
<wolfspraul>
for the KiCad files
<wolfspraul>
but I think you have a repo already, then it's more important to keep it all in one place...
<marcan>
yeah, I have an OpenLase Git on git.marcansoft.com
<marcan>
I'll put the hardware stuff on a repo next to that
<kristianpaul>
ha, is sounded like like jean michel jarre, and it is :-), great stuff
<wolfspraul>
but yes, keep it in one place
<marcan>
yeah, I saw that on the tuxbrain talk
<marcan>
that definitely convinced me to try it :)
<kristianpaul>
s/is/it
<wolfspraul>
try what?
<marcan>
KiCad
<wolfspraul>
ah yes, definitely
<marcan>
the motors are off the shelf chinese galvos (they come with the mirrors and all that) with their drivers and whatnot
<wolfspraul>
I can dismiss any concerns about 'not ready for professionals' today, easily. we've done enough work in the last years to know it's not true.
<marcan>
the current design is a patchwork of stuff (hacked USB sound card, hacked laser pointer, galvos, etc.)
<marcan>
but I want to unify all the electronics into one or a few boards designed from scratch as all-digital controllers, at least up until the galvos
<wolfspraul>
our goal should be to integrate everything as much as possible, and to make it as cheap and robust as possible
<wolfspraul>
easier said than done :-)
<marcan>
so I wouldn't use the original galvo controllers (the galvos can be sourced standalone, I've asked for them once)
<marcan>
I think I can get huge advantages in performance and features that way :)
<wolfspraul>
for sourcing, I suggest digi-key as a first orientation on availability
<marcan>
for electronics, of course
<marcan>
but you won't find galvos on digi-key ;)
<wolfspraul>
if you need stuff that is not on digikey, like modules or those galvos, please bring it up as early as possible and I do some reasearch in China
<wolfspraul>
100% of our vendors and supply chain are documented
<wolfspraul>
I am not holding _any_ information back when I manufacture something
<wolfspraul>
as much as you know about them, hard specs
<marcan>
wolfspraul: the galvos, or the other stuff?
<wolfspraul>
everything that is not on digikey :-)
<wolfspraul>
so I think now we have:
<wolfspraul>
1) galvos
<wolfspraul>
2) laser
<wolfspraul>
3) dichros
<wolfspraul>
if we call these things 'modules', we need to be careful with those modules
<wolfspraul>
I don't want to depend on completely opaque ebay sources
<marcan>
of course
<wolfspraul>
the spot market in Shenzhen is a heaven for modules, but I need to spend a little time to see which is the best way to source 'standardized' modules
<wolfspraul>
for example for LCM, or touch panels, or many others types I'm very clear nowadays
<wolfspraul>
but of course for those 3 - no idea now :-)
<marcan>
I think we want to do two things, 1) make the board as generic as possible so people can use their own modules, 2) find some "reference" sources for complete kits or whatever if we do that
<wolfspraul>
oh I want to make a full product, including mechanical design, everything
<marcan>
sure, but I think we also want to be able to sell the board to someone who wants to use it to build their own projector
<wolfspraul>
not me, you can do that :-)
<marcan>
since everyone seems to want different colors/powers/galvo quality :)
<wolfspraul>
or Tuxbrain :-)
<marcan>
sure :)
<wolfspraul>
fine, but I am interested in making those decisions towards what _we_ consider is 'good' quality
<wolfspraul>
so the end user can just buy the thing and it will work
<marcan>
agreed
<wolfspraul>
since everything is open, opportunities for branching out in a new direction are always there
<wolfspraul>
in fact making that easy is a key goal
<marcan>
which means I need to experiment still :)
<wolfspraul>
but because that is easy, I can solely focus on what I believe is a good integrated product
<wolfspraul>
definitely, this will take months
<wolfspraul>
what would help me now is to understand more about the galvos, laser and dichros we need
<wolfspraul>
their specs
<marcan>
for 1) I only know of those galvos, 2) I'm just using DealExtreme pointers, but thankfully diode laser modules aren't rocket science and are fairly interchangeable; 3) no clue about dichros yet (I haven't done RGB yet), but I understand it's a pretty generic item
<wolfspraul>
with 'now' I don't mean right now (you need to go sleep), but I mean in next days/weeks
<marcan>
i.e. a hunk of glass passing one wavelength and reflecting another, it doesn't really matter who you get it from
<wolfspraul>
dealextreme is not bad
<wolfspraul>
it's like a remote version of digging through shenzhen spot markets
<wolfspraul>
of course super inefficient compared with a trip there
<marcan>
yeah
<marcan>
their lasers are a bit hit and miss at times though :P
<wolfspraul>
everything there is :-)
<wolfspraul>
but if you would spend a week with me walking around the markets, you would realize the inability to build a reproducible online shop out of this :-)
<wolfspraul>
that's the work I can contribute to your project actually
<marcan>
haha :)
<wolfspraul>
find cheap ways to integrate everything
<wolfspraul>
cleanup the sources
<wolfspraul>
find some hard-to-source modules
<marcan>
yeah, having someone who knows his way around Chinese markets is a huge bonus
<marcan>
especially since that's the only way to get affordable laser parts (particularly the galvos)
<marcan>
(and the lasers)
<wolfspraul>
well we need to dig out the facts, specs etc.
<marcan>
I'd say we need to decide on them first :)
<wolfspraul>
once we dig this out, we can do sourcing anywhere, in the end it is quite possible that many parts actually come from Japan/Korea/Taiwan
<marcan>
basically I want to start working on the new hardware soonish and see where that gets me, I don't think I'll be able to start deciding on hard specs until I have some prototypes for the electronics and I can actually test stuff
<marcan>
but if you want to know what my _current_ hacky projector looks like, well, the basic specs are 30kpps galvos, and a 200mW (currently) DPSS green laser diode
<wolfspraul>
you have a much clearer idea on specs than me right now, so it helps if you write up what type of laser/galvo/dichro _might_ work
<wolfspraul>
ah there you go :-)
<marcan>
s/diode/module/
<kristianpaul>
sorry interrupt again but, i'm confuse, where are the schematics here  git.marcansoft.com ?
<marcan>
(there's no such thing as a green laser diode)
<marcan>
kristianpaul: the schematics aren't on the git, I just wrote a quick blog post about the hardware some time ago
<marcan>
since the current version is very much DIY/adapt-as-you-go, not really a 100% reproducible product
<marcan>
other than mechanical stuff (case, heatsinks, mounts, that kind of stuff), not that I can think of
<marcan>
the final design is very much up in the air, but I don't intend to use anything exotic
<marcan>
the only mildly weird thing is I want to use an XMOS micro, which is a newfangled multicore event-driven thing that I think is a good match, but that's on digi-key too
<wolfspraul>
marcan: I am not an electrical engineer, I can barely read a circuit
<wolfspraul>
just clarifying my role
<wolfspraul>
so what I can help with is sourcing, manufacturability
<marcan>
rejon: wow, 6000W :)
<wolfspraul>
so you will see me following your project very much from a sourcing side. asking questions about specs of parts etc.
<wolfspraul>
if you use KiCad, you can follow some of the naming conventions we've come up with, if you like
<kristianpaul>
and hopefully safety ;)
<marcan>
the new design will be much safer (laser-wise) than what I have now
<marcan>
since I'll do the galvo driving loop in the micro, if the galvos break/stop moving I can turn off the laser
<wolfspraul>
marcan: Werner Almesberger (wpwrak) may have feedback for you once your KiCad project is up. Stuff is also written up and you can look at the KiCad projects on projects.qi-hardware.com
<marcan>
right now that can't be detected since the galvo drivers give no feedback :)
<marcan>
(the #1 unsafe situation for a laser scanner is that the laser stops and delivers full power to one point, then if someone gets hit in the eye you've got a problem)
<marcan>
wolfspraul: will do
<kristianpaul>
(feedback) yeah, was about to point that..
<wolfspraul>
feel free to use if it makes sense for you, we are all learning and debating what's best...
<kristianpaul>
hey, i missed that page, looks interesting
<marcan>
duly noted
<rejon>
updated
<kristianpaul>
can you replace laser by some sort of hihg power LED or something?
<kristianpaul>
well, just barelly asking
<marcan>
I've had a crazy year (moves, conferences, stuff to organize, jobs etc), but as soon as I get more "stable" in the coming months I want to start seriously cleaning up OpenLase and working on the hardware
<marcan>
since I've had several interested people, and just not enough time to really start documenting things properly :/
<marcan>
kristianpaul: not really, it needs to be a laser to be collimated
<wolfspraul>
I'm interested too, it allows me to dig into parts I haven't digged in before (galvos/dichros/laser), and out of that we can build good products in the future, maybe :-)
<marcan>
you can't really focus an LED down to a line
<kristianpaul>
yeah..
<marcan>
one of the cool things about the laser projector is you can project on uneven of way off-angle surfaces
<kristianpaul>
well, be safe ! i'll follow your blog for now as well :)
<marcan>
and there are no focus issues, you just adjust the transform
<rejon>
wolfspraul: btw the point of laoban soundsystem always was to make copyleft/open soundsystems
<rejon>
ears are super sensitive
<rejon>
and bass/sound is all around
<rejon>
vision you have to get heads pointed at
<wolfspraul>
marcan: so that's my wishlist - more documentation about the desired/required/best specs for those 3 parts
<marcan>
wolfspraul: will do, just don't expect it "real soon" because I'm still very much unclear about it still, I need to start doing some prototyping first :)
<wolfspraul>
marcan: do you have a picture of the innards of your current projector?
<wolfspraul>
marcan: oh sure, keep us posted about the prototyping. I'm sure those are exactly the points that will come up there.
<marcan>
as you can see, veery hacky construction ;)
<kristianpaul>
but works very well !
<marcan>
thanks :)
<kristianpaul>
and no injuries so far, right? :)
<marcan>
not that I know of anyway :)
<kristianpaul>
:-)
<marcan>
I'm pretty careful, and I've got my safety goggles
<marcan>
the rule at 100mW or so, as far as I can calculate, is that it should be safe as long as it's drawing something nontrivial (though you don't want to get hit deliberately, of course)
<wolfspraul>
marcan: are all pictures/videos on your blog or posted by you cc-by?
<marcan>
so the danger is while you're adjusting or messing with the projector itself, and that's when you use goggles :)
<marcan>
wolfspraul: consider all the pictures cc-by, as for the videos, if they don't contain third-party source video or audio, same thing
<wolfspraul>
got it, great!
<wolfspraul>
marcan: can the projector be passively cooled?
<marcan>
currently it's all passive, though if we put it in a case it might be a good idea to get some airflow
<marcan>
but with some clever engineering (using the case as a heatsink...) it can probably be done entirely passive
<wolfspraul>
on that picture, where are the galvos?
<kristianpaul>
ahh outw_p is from the outb familly
<kristianpaul>
i guess i can just re-use the mmio functions from milkymist rtems bsp
<wolfspraul>
kristianpaul: how's the gps stuff coming along btw?
<kristianpaul>
this a nice doc svn.psas.pdx.edu/svn/psas/trunk/gps/documentation/adg_thesis_final.pdf
<kristianpaul>
wolfspraul: working on osgps porting
<kristianpaul>
well, for now verifying code compatiblity
<kristianpaul>
seems write/read not big deal
<kristianpaul>
now remains, registers compatibillity check, and intterupt handling
<wpwrak>
(openlase) neat stuff !
<wpwrak>
marcan: (safety) how fast can you switch the laser on/off ? e.g., could you control its power with a PWM without getting the beam visibly chopped ? and when the beam hits an eye, how long do you have before it does damage ?
<wpwrak>
(hw guide) makes me realize just how much we still have to document :-) complete naming conventions, sizing conventions for schematics (text, symbols), idem for footprint/layout (a lot more parameters), tables of parameters per component types, ... then there are a few things at the extreme end of the range, like caps with merely fF (and tolerances in % or F) that deviate from the usual rules
<wpwrak>
(hw guide) next, package naming conventions, footprint style conventions/recommendations, workflow (e.g., how do i add a symmbol or a footprint; how do i generate gerbers from my project), recommended mechanical parameters, footprint dimensioning rules and recommendations (these are my favourite - remember all those long posts full of obscure numbers and more references than the average PhD thesis, with all the sources violently contra
<wpwrak>
dicting themselves ? :)
<rejon>
hopefully we will pick up some phds too wpwrak
<wpwrak>
(hw guide) sourcing best practices, etc. etc.
<wpwrak>
a PhD in copyleft hw would be sweet ;-)
<rejon>
another option
<rejon>
:)
<wpwrak>
well, sebastien should be about halfway there. llhdl should also satisfy the prerequisite theoretical work. write a few conference papers and find a university where they're not too picky about form, and voila :)
<wolfspraul>
halfway, phew. i'm halfdead. even just working on sourcing makes me feel there's still 1000 things I cannot even spell right.
<wolfspraul>
Adam's testing is slowly making progress btw
<wolfspraul>
we have to wait for full data for all 90 pcbas first
<wolfspraul>
7 in 100% pass condition now, I hope this goes up! :-)
<wpwrak>
93% yield isn't half bad
<wolfspraul>
no I have 7 boards that pass 100%
<wolfspraul>
after testing 27 :-)
<wolfspraul>
but we need a full data set first...
<wpwrak>
oh :)
<wolfspraul>
first priority - make as many boards 100% pass as quickly as possible
<wolfspraul>
second priority - understand systematic problems of this run so that the next run has better yield/less problems
<wolfspraul>
third priority - fix boards one by one, starting with the easiest, moving towards the harder ones, and stopping when it's so hard (per board) that it makes no economic sense to continue, and instead start the next run
<wolfspraul>
we are in #1 now
<wpwrak>
yes, makes sense
<rejon>
good logik
<wpwrak>
#1 has actually to parts: #1.1 make a few work 100%, so you know that there's no common fatal flaw. #1.2 get boards ready for distribution/selling. #1.2. may or may not be in you critical path, depending on what other things you need (e.g., case parts, accessories, box, ...)
<aw>
rejon, hi
<wolfspraul>
wpwrak: #1.1 is what the very first board is for, that is taken off the smt line before the rest is pushed through. A bit risky maybe to only take 1, but that's how it's done normally.
<aw>
i am still testing..rc3 though
<wolfspraul>
I guess the assumption is that the smt/reflow process is so deterministic that if there are no problems with the first board, the rest can be pushed through safely
<wolfspraul>
too much data in that situation wouldn't help you either, because the line is waiting...
<wpwrak>
(just one) yeah, one is hard enough work and you have just one adam :)
<aw>
rejon, so my apartment/office here now is messy a little, after testing all boards firstly maybe we can meet at somewhere. ;-)
<wpwrak>
in theory, >1 board would be good to spot very bad variations or exceeded tolerances. but the value of adding boards quickly diminishes. and your smt line will only have so much patience ;-)
<roh>
yay. glueing done. solvent jar closed (i hope i can let it be closed for some time now)
<rejon>
aw: cool man
<rejon>
don't want to distract you
<rejon>
i'm here near taipei 101
<roh>
now letting it rest a few hours.. will do qc on the remaining sheets now and then check the yesterday-glued 75 (qc) and package them
<roh>
rejon: youre in tpe? nice.
<wpwrak>
roh: does the solvent at least smell "nice" ? ;-)
<roh>
i havent smelled it yet. i guess thats a good sign
<wpwrak>
how boring ;-)
<roh>
a chemist i know warned me about it, but commented that its 'a nice turn when it happens'
<wpwrak>
*grin*
<roh>
i guess he must know. (/me likes physics but chemicals are still something i consult people on a default basis)
<aw>
rejon, ;-)
<wpwrak>
roh: you should once try pcb speed etching. mix ~30% HCl and ~30% Peroxide in equal parts, then insert the PCB and agitate it a bit. make sure spills and fumes will be contained :)
<rejon>
aw: there is something brewing for next tues. then you can meet a few people working on parts of the puzzle :)
<wpwrak>
roh: if you're really good, you will even be able to get the board out before it's completely ruined :)
<rejon>
might be better
<wolfspraul>
wpwrak: "may the yield be with you" :-)
<roh>
wpwrak: i am really happy we got a ventillation system here
<roh>
wpwrak: used it a lot lately for making sure nobody gets harmed.
<wpwrak>
sigh, what happened to the mad scientists of the good old days ?
<roh>
it has 3 power levels and was built for the former useage as solarium. i only use stage1 on outtake air usually. sometimes also stage1 intake
<roh>
every stage eats about 3kW. so its 18 kW max power.
<roh>
also kinda funny: stage 3 out and no in active makes the inner front door open by itself (against a spring loaded closer) because of the air getting sucked out.
<wpwrak>
hmm. are you sure it's designed to work with chemicals ? some stuff can be quite corrosive. without an appropriate filter, you won't enjoy that ventilation for long ...
<roh>
afaik all filters are gone already. its mostly consisting of tubing made from fire-zinked metal and some aluminium parts
<roh>
also it was for free (well.. eats electricity for breakfast)
<wpwrak>
well, you may want to check its condition every once in a while :)
<wpwrak>
and avoid experiments with quicksilver :)
<wpwrak>
didn't spot anything obviously wrong with my wpan boards. that was encouraging :)
<roh>
:)
<wpwrak>
that "bad apple" song seems to have inspired quite a lot of creative adaptations. various laser shows, ASCII art, minesweeper art, one even hand-carving real apples ! http://www.youtube.com/watch?v=Ol2LDUcoVhk
<wolfspraul>
wow, yes. that must be thousands of pictures with the apples...
<roh>
btw.. i hope you all ordered your camp tickets ;)
<wolfspraul>
how many did you sell so far?
<wolfspraul>
wpwrak: after the laser projector, we work on the automated apple peel cutter
<roh>
wolfspraul: not sure. i dont have the numbers. but its not sure there will be a on-site sale at all
<wpwrak>
wolfspraul: yeah, when i saw this, i started to wonder how hard it would be to cnc-mill an apple ;-)
<wolfspraul>
the artist is also in there, very humble at 2:38
<wolfspraul>
a real fan
<wpwrak>
yeah, this must take quite some dedication
<wpwrak>
and the cool thing is: THEY'RE ALL CRIMINALS ! they're blatantly violating the copyright. lock them away ! now ! :)
<wpwrak>
xiangfu: question: what would you think i moved fped's "home" over to qi-hw, and take over the fped project you've already created here ? i think all your things are under debian/, so it should be easy to have the main repository and your debian work coexist
<xiangfu>
wpwrak, yes. that will be great.
<xiangfu>
yes. all debian package stuff is under debian/
<wpwrak>
xiangfu: i'll make myself project admin then, okay ?
<xiangfu>
yes. sure.
<wpwrak>
and shall we merge debian/ into the main branch ? or would you prefer to keep it in a separate branch ?
<xiangfu>
if you don't mind put 'debian/' in your source code, just do it.
<xiangfu>
I just put the 'debian/' in xburst-tools 'master' branch
<wpwrak>
perfect. i'll merge it then.
<xiangfu>
then we can just remove the 'debian' branch
<qi-bot>
[commit] Werner Almesberger: changed GUI page location, checkout instructions, and e-mail address (master) http://qi-hw.com/p/fped/f0c0ae7
<kyak>
wpwrak: i re-used your code from ubb-vga to disable/enable interrupts (i think it works because if i disable interrupts and then don't enable them, the system looks pretty much halted)
<kyak>
my intention is to disable interrupts in the beginning of each iteration (calculation step) and then enable them again; and so forth
<kyak>
probably this way i can achieve real-time, who knows :)
<kyak>
but the question is now, how (where?) to get the timer source?
<kyak>
i need to have some timer running, and trigger my calculations in defined time steps
<kyak>
suddenly i understood that this code is also in ubb-vga..
<kyak>
i'm not sure how it works, but it seems that you are using the hardware timer provided by 4740
<kyak>
what is the resolution of this timer? is it a reliable source of time?
<kyak>
it's a little bit of a magic for me, how you interact with CPU registers from your application.. Is is the linux kernel that provides such interface? Or how does it work?
<kyak>
probably it has soemthing to do with /dev/mem where these registers are mapped into specific region.. But how do you know where?
<kyak>
</monologue>
<kyak>
:)
<kristianpaul>
i think there is a RTC driver...
<kristianpaul>
s/think/remenber
<kyak>
there is a /dev/rtc, i'm not sure how it can be used, bur Werner is using something else..
<larsc>
the rtc timer has a resolution of 1 second...
<kyak>
so the rtc timer is not sufficient for this task..
<marcan>
wpwrak: PWM with green lasers is tricky because they're not diode lasers, they use a diode laser to pump a crystal laser and the latter has issues turning on and off really fast
<marcan>
though maybe it'll all smooth out in the end as long as you PWM the pump diode fast enough
<marcan>
I think few people do PWM though, it's mostly analog current control
<marcan>
as for safety, that depends on the laser power, of course
<marcan>
there are exposure limits that vary by wavelength, power, and time (Maximum Permissible Exposure)
<marcan>
but as a rule of thumb, <5mW is safe under all conditions, ~100mW or so is safe as long as it's actively moving and the target isn't too close, and once you start going into the W range then you really need to avoid hitting people at all, moving or not
<marcan>
I intend to program MPE limits into the DSP so that it accumulates exposure into a grid of buckets across the screen, and limits power once it exceeds a threshold per bucket
<wpwrak>
kyak: the clock frequency is 112 MHz
<wpwrak>
kyak: the code is indeed a little unusual ;-) i don't wait for a timer interrupt. instead, i busy loop until the timer reaches its limit
<wpwrak>
kyak: if you want timer interrupts (or any other interrupts), you need to go into the kernel.
<wpwrak>
marcan: (exposure) yeah, i was thinking that your MCU could perhaps lower the duty cycle of the laser if it stays too long in the same area/bucket
<wpwrak>
marcan: but if the later isn't easy to control with a PWM, then that wouldn't quite fly
<wpwrak>
marcan: i any case, you'd need the exposure limit in something like J/m^2. then you could translate this to J/degrees^2, etc.
<marcan>
well, most drivers use analog power control instead of PWM, which is mostly equivalent (just less efficient)
<marcan>
that's what I have right now (just a simple current driver)
<wpwrak>
ah, efficiency could also be a consideration. get rid of those bulky heat spreaders ;-)
<marcan>
and yeah, of course the exposure limits are heavily dependent on how far you are, beam divergence, etc...
<marcan>
I'm just doing some educated guesstimating, but you definitely need a real laser safety engineer and an exposure meter, *especially* if you plan on deliberately aiming at people (audience scanning)
<marcan>
me, I just project onto a wall, so I just roll with some basic MPE calculations and making sure I avoid hitting anyone in the first place
<marcan>
bbl, food and stuff :)
<wpwrak>
with a really powerful laser, you could add a "cook lunch" mode ;-)
<roh>
well.. its easier to cook with the exhaust-air of the laser cooling subsystem of a decent sized lasertube than by heating something up with the light coming out ;)
<wpwrak>
roh: how lame ;-)
<wolfspraul>
can we build an expansion cable, say, from the m1 expansion connector, and directly drive the laser or galvos?
<wolfspraul>
or from UBB :-) it's universal after all...
<wolfspraul>
what kind of processing power or input is needed to drive the projector? (without MCU or XMOS I mean)
<kyak>
wpwrak: do i understand it correctly that you read the timer value from within your application and act when it reaches according value?
<wpwrak>
kyak: yes. well, what i actually poll is the flag that indicates a timer overrun, see ubb-vga.c (delay)
<wolfspraul>
roh: will you do the first logo test today? please send me a picture asap then I can sign it off and we are good to go... (is this the planned procedure?)
<wpwrak>
kyak: the polling is in the first while loop
<roh>
i guess so
<roh>
i just finished cleaning the shields
<wpwrak>
kyak: after that, i read the timer value and add some more loops based on the difference to the expected value. this is to compensate for cycles i may have missed when polling.
<kyak>
wpwrak: i see. What if you enabled interupts while you are in a waiting loop?
<wpwrak>
kyak: (delay loop) that way, my contraption gets a little more accurate, reducing pixel noise
<roh>
dunno if its a good idea to laser today.. kinda tired and lasering the sheets should be error-free (or i would have to cut some more lids)
<wpwrak>
(interrupts) then an unknown (and variable) amount of latency would get added
<kyak>
wpwrak: ok, thanks :) i will need some time to think it over
<wpwrak>
kyak: and you'd have to disable interrupts at the end again. also, the code running while interrupts are enabled would change the cache. so cache refills would add some latency as well. but your application may not need such high timer precision.
<wolfspraul>
roh: ok sure tomorrow is also fine. just send me a photo of 1 top acrylic first, then do the rest.
<wolfspraul>
is that ok?
<roh>
i'll do a test on some leftover material first
<kyak>
wpwrak: you said, that enabling interrupts during delay loop would add unknown (and variable) latency. But if you poll the timer continously during this delay loop, and disable interrupts again just in the moment when you see that the timer is "full" (i.e. it is time to calculate the next step), would it solve the problem?
<wpwrak>
kyak: no, because you may not be scheduled when the timer reaches the critical value
<kyak>
right..
<wpwrak>
you could compensate this, of course: first loop/sleep until you're "close", then disable interrupts and loop
<wpwrak>
but that may be too coarse to be useful
<kyak>
ha
<kyak>
would be a nice trick
<wpwrak>
in the kernel, you'd only have to worry about timer interrupt latency, which should usually be small
<kyak>
should i consider running an application as a kernel module?
<larsc>
kyak: depending on what you want to do hrtimers might be an option
<wpwrak>
if you need strict timing and have a low duty cycle, yes
<wpwrak>
if you ned strict timing and have a high duty cycle (i.e., if there's no point in letting anything else run), then you could use the ubb-vga approach
<kyak>
larsc: i'm not yet sure what i want to do, for now i'm just exploring :)
<wpwrak>
if you have extremely strict timing, you'd even combine both approaches
<larsc>
and there is also uio which can be used to deliver irqs to userspacce
<wpwrak>
if you have loose timing and only need high CPU priority, you could increase your task's scheduling priority
<kyak>
wpwrak: i see. Could you explain how does it work that you disable interrupts, but you are still able to poll the timer? Where is it coming from?
<wpwrak>
larsc: yeah. may actually be nice to have a generic uio driver :)
<kyak>
larsc: btw, are hr timers disabled in Ben;s kernel for a reason?
<wpwrak>
kyak: the timer has a register bit it sets when it overflows
<kyak>
wpwrak: so you read the register from userspace? How?
<wpwrak>
kyak: do you have the 4720 or 4740 programmer's manual ? (from ingenic)
<kyak>
wpwrak: i don't
<wpwrak>
larsc: (generic) im gpio -> uio
<kyak>
i guess i should get the manual and ask less questions :)
<wpwrak>
the manual will answer some questions. and probably create a lot more ;-)
<wolfspraul>
kyak: what you don't?
<wolfspraul>
really?
<kyak>
wolfspraul: got it now :)
<wolfspraul>
ah perfect, I would have emailed otherwise
<kyak>
and UIO also seems like a good way to get timer interrupts in userspace
<Ayla>
the binary can be anywhere on the filesystem, but the data has to be on /usr/share/gmenu2x
<kristianpaul>
got it
<kristianpaul>
okay i'll reboot and see
<kristianpaul>
ahhh loop
<kristianpaul>
if you read this messages in the logs, check http://..
<kristianpaul>
so no start Ayla
<marcan>
wolfspraul: if there are FPGA pins available on the expansion connector, it should be easy to add a, say, modified I2S interface to drive the laser (with HDL changes)
<marcan>
you could have that connect to the XMOS for high-level data, or shift all the laser duties over to the MM, but in the latter case then you wouldn't be able to have a standalone projector and that's no fun
<kristianpaul>
there are 10 pins i think
<kristianpaul>
if we're talking about mm1 :)
<marcan>
yeah
<marcan>
wolfspraul: re: FPGA on the laser, it'd work I'm sure, but I think implementing a softcore is overkill
<marcan>
I've looked into XMOS and I like what I've seen, they're trying to step into FPGA territory while remaining a micro, so it's fairly flexible and powerful
<kristianpaul>
ot you can run a soft* over a 8bits mcu if you need flexibillity beyond HDL logic
<marcan>
and they do lots of audio stuff, which is extremely similar to laser processing, so there's examples available for that
<kristianpaul>
but at the cost of theri licenses :)
<kristianpaul>
i mean for the examples
<marcan>
I think they have decent licenses (and if they don't I can probably get them to, I have a friend who is a friend of the company founder ;)
<marcan>
and I also have people working on completely open development tools, so I'm not concerned about lock-in to their SDK either
<kristianpaul>
well, last time iremeber some parts of the llvmm port where not floss, anywa i never used that xmos kit at much
<kristianpaul>
anyway, if you need help integrating that I2S in the milkymist soc, jsut let me now, i'll do my best :)
<marcan>
yeah, they also have the XC language stuff, which is a proprietary hack (though convenient), but I'll avoid it unless there are open dev tools
<marcan>
will do :)
<kristianpaul>
ah, good, (avoid XC)
<kristianpaul>
you're gonna belive me but i get the kit because was alsmot free and i tought was an FPGA xD
<marcan>
I think the best plan here is to have the laser have its own standalone MCU for processing/safety/etc, and have it take both USB 2.0 (for PC usage) and something like I2S for the MM or similar standalone hardware
<kristianpaul>
later i discover tht truth..
<kristianpaul>
you're not*
<marcan>
haha, yeah, it's definitely not an FPGA
<marcan>
but it can do some things that used to require an FPGA to do sanely before (without hard macros), which is nice
<wpwrak>
so xmos is a bit like the propeller ?
<marcan>
yup, but a lot more powerful
<marcan>
it's a similar concept
<marcan>
but instead of just independent cores, they also have multithreading
<wpwrak>
yeah, the prop is a bit on the sluggish side
<marcan>
so you have a 400MIPS core that can run 4x100MIPS threads (but not 1x400MIPS thread)
<marcan>
I believe they do that because of pipeline advantages
<marcan>
the 4-core versions do up to 1600MIPS total
<marcan>
I'll use an L1 (single low-power core, 4x100MIPS through 8x50MIPS) or two of them if I have to (there's an L2, which is two L1s in a single package, but it's a horrid dual-row QFN that I've already had a bad prototyping episode with)
<wpwrak>
looks as if the 400 MIPS code does 8 x 50 MIPS, no ? that would be similar to the prop
<wpwrak>
ah no, they claim 100 MIPS
<wpwrak>
okay, so the threads share something beyond just global memory. so there's a difference to the prop. looks more flexible, though.
<marcan>
they have communication channels, internal and external
<marcan>
and the threads don't have dedicated memory, and shared memory isn't slow like on the prop
<wpwrak>
yeah, and you avoid the weird memory model
<marcan>
wolfspraul: the prop is 160MIPS total, the xmos is 400MIPS total (for an L1), or I think 500MIPS recently?
<marcan>
and yeah, it's a more classical architecture
<marcan>
I meant wpwrak, tab completion fail :)
<Ayla>
kristianpaul: you did put the data in /usr/share/gmenu2x? Does it fail with an error message?
<wpwrak>
ah, i had something like 48 MHz/MIPS per .. duh, thingy, in the back of my head. but anyway, when i looked at it, it seemed a bit too slow to do interesting things.
<marcan>
also, the xmos has single-cycle multiply-accumulate iirc
<marcan>
while the prop doesn't do mul at all
<wpwrak>
heh. time to undust those DSP books ;-)
<marcan>
yup :)
<wpwrak>
the prop has many weird things. starting with the ROM ...
<marcan>
I really need to read up on PID loops and the like to work out a reasonably optimal galvo control loop
<marcan>
but I think it'll totally be worth being able to compensate hardware oddities in software
<marcan>
a few opamps can't really compete with a DSP :)
<wpwrak>
everything is moving towards software. so the approach sounds very reasonable to me
<marcan>
I know there are veeeery expensive pro galvos that do the same thing, but still have an analog input
<marcan>
but we're talking ridiculous prices
<wpwrak>
cheap is better (as long as it works) :)
<marcan>
I don't know of any system that uses a single chip to do the whole shebang, including host interface, "DAC", and galvo loops
<marcan>
the idea here is to integrate everything to simplify and make it cheap :)
<kristianpaul>
Ayla: yes i did
<marcan>
(and kick ILDA's ass - I mean, ILDA is cool and everything, but it's about time we ditch the decades old +/-12V analog differential standard)
<wpwrak>
;-))
<kristianpaul>
Ayla: i jsut moved old gmenu2x and copied the tarball you agve me from /
<Ayla>
kristianpaul: and is there any error message?
<DocScrutinizer>
kristianpaul: for galvanometer mirror control you don't need a loop nowadays I'd say. you need a proper hw bridge driver, and a sw that models the hw with all the inertia, feeds the original signal to the model and derive the driver signal from it. As this is a calculation that doesn't have to be done in realtime, you can calculate the mangled driver signal with all the overshots and whatnot on a 4bit cpu, then store it to e.g. a .wav
<DocScrutinizer>
and simply playback that .wav to the hw power driver
<DocScrutinizer>
I.E. use your audio card plus a 10..50W audio stereo amp to drive the galvos
<kristianpaul>
DocScrutinizer: okay but i think you talk, with wrong person i jsut discover what a galvanometer is from  cxadams work
<kristianpaul>
but yeah, a good hbridge is enought
<kristianpaul>
hw*
<kristianpaul>
but wait, you stilll need fedback unless you want to blind somobody..
<DocScrutinizer>
what kind of feedback?
<kristianpaul>
a rotary magnnetic enconder or soemthing less fancy
<kristianpaul>
cause the point for safety as i understand is poweroff laser if galvanometer get stuck..
<DocScrutinizer>
useless. you calibrate your model once. After that you know what your mirror is doing right now, even without feedback
<DocScrutinizer>
well, such a safety circuit has to work completely independently from the regular controller anyway
<kristianpaul>
yeah, sure, as i said, is just for safety not control
<wpwrak>
you could do that with a microphone and voice recognition. "turn off on ARRRGH!!! I AM BLIND !!" (chances are that you're not quite ... yet :)
<whitequark>
kristianpaul: about the gmenu2x debugging
<whitequark>
strace is *incredibly* useful (together with sources)
<whitequark>
it's the tool i've used to make gmenu2x work
<Ayla>
currently, gmenu2x is compiled with TARGET_GP2X, even when compiling for dingoo or nanonote
<Ayla>
that's only cleanups
<kristianpaul>
i think issue is about how you linked this gmenu2x..
<kristianpaul>
there are plenty of No such file or directory in the strace log
<Ayla>
maybe I should commit it then, and see if it works with the automated build
<kristianpaul>
yeah :)
<mth>
Ayla: if you put the implementation of Touchscreen::initialized() in the header, the compiler can determine at compile time that it always returns false and therefore the code it guards is unreachable
<Ayla>
mth: I wasn't aware of that, it concerns only C++?