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

Buy Site Supporter Role (remove some ads) | LPF Donations

Links below open in new window

ArcticMyst Security by Avery | Browser Hide by Avery

Peregrine 1.4 beta - Packed with new features!

Thanks for testing, That seems correct. Even with rerender false it's still choppy? on 1.4 and smooth on 1.5?
 
Last edited:





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.
 
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:
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.
 
Atomicrox said:
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 );
}
Click to expand...

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
 
@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
 
Atomicrox said:
@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
Click to expand...

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
 
Tested with a nano and it worked fine. Might be something specific about the mega.
 
Atomicrox said:
Tested with a nano and it worked fine. Might be something specific about the mega.
Click to expand...

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
 
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
 
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
 
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
 
You must log in or register to reply here.





Back
Top