my x-laser mobile beat mirage and etherdream2 ...

Ok. Somethin weird is goin on that i don't understand.
So i'm hopin' you guys can point out what dumb ass thing i'm doin...

my weird c++ goes...
it should be pretty easy to see how it maps to EtherDream.dll.
I flipped the usual order to EDWriteFrame with pps and reps.
so example below is 1000 pps and 1 rep.
Oh and f is just an increasing unsigned long with frame#.

void Framer::FRAME (ulong f)           // DA GUTS !!

{ ubyte c;

  ulong i, w, x;

   Dac [0].rMin = (uword)_c->r.Get ();   Dac [0].gMin = (uword)_c->g.Get ();

                                         Dac [0].bMin = (uword)_c->b.Get ();

   i = f % 64;

   c = (ubyte)i;   w = 65536 - (255-i)*255;   x = (65536 - w) / 2;

DBG("FRAME `d r=`d g=`d b=`d", f, Dac [0].rMin, Dac [0].gMin, Dac [0].bMin);

   ED.Dot (0, 0,0,0, x,     x);

   ED.Dot (0, 1,1,1, x+w-1, x);

   ED.Dot (0, 1,1,1, x+w-1, x+w-1);

   ED.Dot (0, 1,1,1, x,     x+w-1);

   ED.Dot (0, 1,1,1, x,     x);

DBG("putBgn");

   ED.Put (0, 1, 1000);  // plenty slow pps

DBG("putEnd");

}

What I really don't GET is why my green is SO FAINT on the laser.
minimum value to get a red is 1568. same for blue. green min is 1536.

Any red or blue AT ALL completely drown out green at it's max (32767).
And green even at 32767 at max is noooot very bright running this code.
I'd think this code would have huge lags at the dots.

I juuuuust dooooon't geeeet itt.

I'm sure my code is broke somewhere.
But it sure SEEMS like the green laser in this thing is not working properly.
argh.

oops.  and...



   void Dot (ubyte d,  ubyte r,ubyte g,ubyte b,  ulong x,ulong y)

   // r,g,b are balanced

   // x,y in 0-65535 as usual coords where y incr down.

   { EDCfg *c = & _cfg [d];

     EDPnt *p = & c->pt [c->npt++];

     uword  xr, xg, xb;

      xr = xg = xb = 0;

      if (r)  xr = (uword)(c->rMin + (ulong)(c->rMax-c->rMin) * (r-1) / 254);

      if (g)  xg = (uword)(c->gMin + (ulong)(c->gMax-c->gMin) * (g-1) / 254);

      if (b)  xb = (uword)(c->bMin + (ulong)(c->bMax-c->bMin) * (b-1) / 254);

      p->r = xr;

      p->g = xg;   if (xg > xr)  xr = xg;

      p->b = xb;   if (xb > xr)  xr = xb;

      p->i = xr;

      p->x = (sword)( (c->xFlip ? (65535-x) : x) - 32768 );

      p->y = (sword)( (c->yFlip ? y : (65535-y)) - 32768 );

      p->al = p->ar = 0;

DBG("pt[`d]  x=`d y=`d r=`d g=`d b=`d i=`d",

c->npt-1, p->x, p->y, p->r, p->g, p->b, p->i);

   }





   void Put (ubyte d, uword rep = 1, uword pps = 30000)

   {  if (! _dll)  return;

      while (Busy (d))  ::Sleep (2);

     EDCfg *c = & _cfg [d];

      EDWriteFrame (& c->dac, c->pt, c->npt*sizeof (EDPnt), pps, rep);

      Clr (d);

   }

gives this debugging...

00003001 8:00:38.430 PM 11932 FRAME 373 r=1500 g=32767 b=1500
00003002 8:00:38.430 PM 11932 pt[0] x=-7013 y=7012 r=0 g=0 b=0 i=0
00003003 8:00:38.430 PM 11932 pt[1] x=7012 y=7012 r=1500 g=32767 b=1500 i=32767
00003004 8:00:38.431 PM 11932 pt[2] x=7012 y=-7013 r=1500 g=32767 b=1500 i=32767
00003005 8:00:38.431 PM 11932 pt[3] x=-7013 y=-7013 r=1500 g=32767 b=1500 i=32767
00003006 8:00:38.431 PM 11932 pt[4] x=-7013 y=7012 r=1500 g=32767 b=1500 i=32767
00003007 8:00:38.431 PM 11932 putBgn
00003008 8:00:38.682 PM 11932 putEnd
00003009 8:00:38.682 PM 11932 FRAME 374 r=1500 g=32767 b=1500
00003010 8:00:38.682 PM 11932 pt[0] x=-7141 y=7140 r=0 g=0 b=0 i=0
00003011 8:00:38.682 PM 11932 pt[1] x=7139 y=7140 r=1500 g=32767 b=1500 i=32767
00003012 8:00:38.682 PM 11932 pt[2] x=7139 y=-7140 r=1500 g=32767 b=1500 i=32767
00003013 8:00:38.682 PM 11932 pt[3] x=-7141 y=-7140 r=1500 g=32767 b=1500 i=32767
00003014 8:00:38.682 PM 11932 pt[4] x=-7141 y=7140 r=1500 g=32767 b=1500 i=32767
00003015 8:00:38.682 PM 11932 putBgn
00003016 8:00:38.937 PM 11932 putEnd
00003017 8:00:38.937 PM 11932 FRAME 375 r=1500 g=32767 b=1500
00003018 8:00:38.937 PM 11932 pt[0] x=-7268 y=7267 r=0 g=0 b=0 i=0
00003019 8:00:38.937 PM 11932 pt[1] x=7267 y=7267 r=1500 g=32767 b=1500 i=32767
00003020 8:00:38.938 PM 11932 pt[2] x=7267 y=-7268 r=1500 g=32767 b=1500 i=32767
00003021 8:00:38.938 PM 11932 pt[3] x=-7268 y=-7268 r=1500 g=32767 b=1500 i=32767
00003022 8:00:38.938 PM 11932 pt[4] x=-7268 y=7267 r=1500 g=32767 b=1500 i=32767
00003023 8:00:38.938 PM 11932 putBgn
00003024 8:00:39.192 PM 11932 putEnd


So you can see from the timing that EDWriteFrame is not all that fast...
Like 1/4 a sec sometimes - pretty slow...
Does that sound normal ??

First. ED2 color values are 0-65535 natively. If you use the EzAud interface then 32767 should be ok for max but i am not sure for the native interface. Check into that.

Is it EDWriteFrame that is causing the slowdown or is it the loop where you check for the DAC not to be busy?

well i've got some BAD news :(

I guess x-laser doesn't quality control their lasers very well cuz the green diode just barely puts anything out !!

I also emailed the sales dude 2 weeks ago and no response.

I emailed him again 2 days ago and got an out of office that they're at NAMM or somethin.

So I emailed the main tech support email yesterday and I guess they don't work on weekends !!

ARGH.

I know it ain't just my code cuz red and blue behave just fine.
AND the demo that boots when the laser ain't connected to ILDA has very weak green.
VERY weak. Like just barely visible.

SO THAT SUUUUUCKS !!

And it does look like the delay is in the busy check.
Maybe I'll try skipping it and see what happens.
But i'm pretty sure i saw code that checks busy WITHIN EDWriteFrame that will just exit if busy.
But yep, often a full 1/4 a second waiting for busy to go away.

I must be overloading the dac with frames or somethin.

So do i just gotta not be constantly sending frames or somethin?

I'll try sending a repeating frame, too. That'll at least cause less traffic.

sigh.

Sorry about the laser. I'm sure you'll get it sorted out eventually.

I think there is a mimimum of 30 pts per frame or something like that for ED. Try increasing pts to see if that has any effect.

a minimum number of points? weird. why would there be a minimum?

well, i'll definitely give it a shot. and try repeat > 1. and give the dll/EtherDream2 some time to breath.

thanks for the suggestions. i'm gonna just keeeep trying stuff till somethin works :)

i'll eventually get it.

i HAD it on a 33 millisecond period timer wakeup.
But frame generation took too long cuz of that wait on busy to go away thing.

So i put it back to "just keep sendin frames in a tight loop".

So I'll just have to increase the period and try things till frame generation takes under 33 msec.

Minimum points might be because the overhead of sending one point at a time makes it slower then the single point can be processed.

I'll be experimenting with frame size and repeat today. We'll see how that affects timings.


So nowww i need to study point optimization.
I guess in general, you set pps to max your laser will do (30000 for mine).
Then you add extra drawn/undrawn points to give the scanner more time to get there.
Cuz that 30,000 assumes the beam is ONLY going 8 degrees max, right?

So the length of the drawn(or undrawn) line needs to be taken into account.

And when the beam cranks to a new angle, you may need dwell points at
the vertex depending on the angle between the 2 lines.

Anybody got any good docs on the technical aspects of doing this?

I'm guessing I'll need to calc the length of each segment, and angles between segments.
Then use those 2 values to add dwell points to give the servos multiples of the 30,000 pps (=1/30,000 of a sec) to truly "get there" before hitting the new beam color or off value and wrecking stuff cuz it ain't there yet.

I've found... http://www.art-science.org/journal/v...-v7n4pp155.pdf

Anybody got more docs?

Thanks much :) I'm over the funk of having to return my laser now at least.

I can make do with just red and blue and dream of greeeeen. that almost rhymes ha ha.

Yeahhhhhhhhhh it was that dang Sleep (2) ... SHEESH !!

2/60 of a sec is 1/30 of a sec which is the full time amount i've GOT to generate a frame...

I'll have to do a busy wait or use a higher precision timer to wake up.

Soooo i'm back on track again.

Sleep(2) is unlikely to sleep for 2ms. More than likely it will be around 8ms because of the minimum timeslice that Windows will actually sleep. You can measure it with a performance counter. In my code I just do a hard loop to wait for the DAC to become non-busy and it seems OK. Not optimal but I dont have a better solution at the moment.