Welcome to Laser Pointer Forums - discuss green laser pointers, blue laser pointers, and all types of lasers



Peregrine 1.4 beta - Packed with new features!

Atomicrox

Well-known member
Joined
Jun 22, 2011
Messages
2,432
Points
83
Thanks for testing, That seems correct. Even with rerender false it's still choppy? on 1.4 and smooth on 1.5?
 
Last edited:



netwave

New member
Joined
Sep 28, 2009
Messages
139
Points
0
Yeah still choppy with v1.4 rerender false and in v1.5 it obviously produces no gaps so appears slightly neater graphing, though if the line is getting stitched allot I expect its because of the amount of processing power JAVA demands.

I have to click connect first in v1.4 or it says: waiting for input...
That maybe because I'm using the simpleLPM protocol being that no code was specifically added for the Cubic.
Though Peregrine 1.5 auto discovers what COM port an LPM's using which is a bonus.
 

Atomicrox

Well-known member
Joined
Jun 22, 2011
Messages
2,432
Points
83
Well, I could make it stitch the points (that only takes two lines of code), but that won't solve the actual problem (that the datapoints are unevenly spaced due to slowness).

I managed to do some simulations by limiting my computer to 40% of it's clockrate (about 1.2GHz) and forcing Java to run on a single core. It didn't slow down to the point of producing gaps while not rerendering, but it does produce gaps if rerender=true. I also compared to Trevor's version and unfortunately mine seems to be slower, even after disabling oversampling and comparing my "roll" end action to his "monitoring" (which are pretty much the same thing). This only made a difference when rerendering (i.e. after the graph passes the first 60s), though.

TBH I don't think I'll be able to "fix" this. I don't know of a (sort of automatic) way to profile processing applications and it would take time that I don't have to analyse this manually. If I were to do that I'd rather rewrite it from scratch in something more efficient than Java/Processing. I don't think this slowness makes a difference to most users, but those with older computers that are noticing slowness should probably use Trevor's version instead.

Edit: I had done this so long ago I forgot you have to set "Comm.Serial.AutoConnectPort" to your port name (and remove the first # of the line) on your data/Peregrine.conf file for it to autoconnect.


@Trevor: while doing the simulations I noticed Peregrine 1.5 does not auto detect my LPM correctly. It thinks it's a Kenometer and keeps attempting handshakes (I'm using simple mode). Since there's no way to force it to a specific protocol I had to comment out the contents of HandshakeProcess() on Serial.pde to get it to work. Here's the simplified code I was using (on an Arduino Mega), in case you want to test it:

Code:
float value = 2.2;

void setup()
{
  Serial.begin( 9600 );
}

void loop()
{
  Serial.println( value, 8 );

  delay( 100 );
}
 
Last edited:

netwave

New member
Joined
Sep 28, 2009
Messages
139
Points
0
Not sure if this will make a difference, but what version of processing are you using?
I've been using processing v2.1 Windows x64
If your version is the older recommended beta build that's been removed from the host site upload it & I'le re-test to see if I get better results with rerender false.
 

Trevor

Well-known member
Joined
Jul 17, 2009
Messages
4,513
Points
113
Well, I could make it stitch the points (that only takes two lines of code), but that won't solve the actual problem (that the datapoints are unevenly spaced due to slowness).

I managed to do some simulations by limiting my computer to 40% of it's clockrate (about 1.2GHz) and forcing Java to run on a single core. It didn't slow down to the point of producing gaps while not rerendering, but it does produce gaps if rerender=true. I also compared to Trevor's version and unfortunately mine seems to be slower, even after disabling oversampling and comparing my "roll" end action to his "monitoring" (which are pretty much the same thing). This only made a difference when rerendering (i.e. after the graph passes the first 60s), though.

TBH I don't think I'll be able to "fix" this. I don't know of a (sort of automatic) way to profile processing applications and it would take time that I don't have to analyse this manually. If I were to do that I'd rather rewrite it from scratch in something more efficient than Java/Processing. I don't think this slowness makes a difference to most users, but those with older computers that are noticing slowness should probably use Trevor's version instead.

Edit: I had done this so long ago I forgot you have to set "Comm.Serial.AutoConnectPort" to your port name (and remove the first # of the line) on your data/Peregrine.conf file for it to autoconnect.


@Trevor: while doing the simulations I noticed Peregrine 1.5 does not auto detect my LPM correctly. It thinks it's a Kenometer and keeps attempting handshakes (I'm using simple mode). Since there's no way to force it to a specific protocol I had to comment out the contents of HandshakeProcess() on Serial.pde to get it to work. Here's the simplified code I was using (on an Arduino Mega), in case you want to test it:

Code:
float value = 2.2;

void setup()
{
  Serial.begin( 9600 );
}

void loop()
{
  Serial.println( value, 8 );

  delay( 100 );
}
Okay... sorry for not getting on replying to this earlier. Apart from making random little posts, I'm a bit scarce on the forum.

Peregrine buffers the serial input until it sees "\n" at which point it throws an interrupt. The problem that is most likely occurring here is that the computer is not fast enough to service that interrupt in a timely manner. So, by the time it actually is dealing with interrupts, a few readings have built up - and they all get the same timestamp. This also has the side effect of making the graph stutter.

Short of a complete redesign in a native Windows language, I'm not sure how to fix the speed on slower machines.

Regarding the question of what version of Processing to compile under, you want 2.0b7. I have a Windows version somewhere but I'll need to find it. But - you are aware there are compiled versions in the release, right? Just look in the "Windows" folder, and you can get around the issue of needing a different version of Processing than the current release.

With regards to the Kenometer protocol thing... interesting. That code you commented out is meant to cease attempting handshakes as soon as any packet is received. It worked on my Arduino Uno masquerading as a Kenometer. I'll look into that when I get a chance.

Regarding the issue Seoul_lasers is having, have you tried using the binary packaged with the release?

Trevor
 

Atomicrox

Well-known member
Joined
Jun 22, 2011
Messages
2,432
Points
83
@netwave: I'm also using the 2.0b7 Trevor mentioned. It's over 300MB, if it was smaller I'd upload it for you. But just use the executables included, like Trevor said.

@Trevor: I noticed the protocol was wrong on the debug pane and that the handshake counter was rolling. Then I just searched the source files for lines that had "INPUT_KENOMETER" and that function came up, I commented the contents out and it worked (detected my Arduino as simple). Didn't invastigate any further than that :p
 

Trevor

Well-known member
Joined
Jul 17, 2009
Messages
4,513
Points
113
@netwave: I'm also using the 2.0b7 Trevor mentioned. It's over 300MB, if it was smaller I'd upload it for you. But just use the executables included, like Trevor said.

@Trevor: I noticed the protocol was wrong on the debug pane and that the handshake counter was rolling. Then I just searched the source files for lines that had "INPUT_KENOMETER" and that function came up, I commented the contents out and it worked (detected my Arduino as simple). Didn't invastigate any further than that :p
Just tested your sketch with my prototype Radiant X4 (it presents as an Arduino Leonardo) and the detection that the LPM is NOT a Kenometer worked fine.

I think I have a few different Arduino flavors here; I'll try to reproduce the issue using another type when I get the chance. But since Peregrine is just looking for data coming in over serial, I feel like it's independent of the board doing the input.

Hm.

Trevor
 

Atomicrox

Well-known member
Joined
Jun 22, 2011
Messages
2,432
Points
83
Tested with a nano and it worked fine. Might be something specific about the mega.
 

Trevor

Well-known member
Joined
Jul 17, 2009
Messages
4,513
Points
113
Tested with a nano and it worked fine. Might be something specific about the mega.
That is very weird. Certainly worth further investigation.

Also, sidenote. I'm really glad I added the debug mode; it's made troubleshooting really easy. :D

Trevor
 

Atomicrox

Well-known member
Joined
Jun 22, 2011
Messages
2,432
Points
83
Yeah, it's strange... Do you know of any software to intercept and log the serial communication byte by byte?


I'm glad as well XD
 

hakzaw1

Well-known member
Joined
Apr 2, 2009
Messages
9,774
Points
113
So of the dozen or so links to downloads in this thread can somebody tell me which I should be using- i have a beta test version Radaint X4
My laptop crashed and i am in dire need to make a bunch of graphs--

If any of the old links are not good can you plz delete them??

thanks HK
 

jimdt7

Well-known member
Joined
Feb 5, 2011
Messages
1,899
Points
48
Whenever I try to open Peregrine I get this error:
"Windows cannot find javaw.exe. Make sure you typed the name correctly and then try again." I'm on Windows 8.1! :thinking:

Jim
 

jimdt7

Well-known member
Joined
Feb 5, 2011
Messages
1,899
Points
48
Nevermind, I fixed it by reinstalling java! :D

Jim
 




Top