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!

There's definitely something wrong, your timesteps are all over the place with lots of zeros in the middle... can you do the same thing with version 1.5 of Peregrine? to see if it's something I added.
 





Hmm... The CSV looks strange... Some of the entries have the same time stamp. I never have this problem with my Peregrine while I was testing the Cube. And according to Trevor the timestamp is done at the computer side. So I am not sure if it has anything to do with my firmware. The attachment is the stability test I did for the cube it's in Excel, I imported in from the Peregrine. It should shed some light on the issue.
 

Attachments

As requested :)

I just noticed the screen shot show the peak as 1222.4mW & Average of 970.4mW
When the exported image gives the same peak level of 1222.4mW but an Average of 890.2mW?
 

Attachments

I looked at the data and looks like the Atomicrox's Peregrine seems to have some data been mark at same timestamp, but clearly is different data since the value is different. And this doesn't happened in Trevor's Peregrine. Perhaps this is due to the timer froze while the USB is still getting data and throwing interrupt?:thinking:
 
Strange.. the Peregrine 1.5 export is better but there are some repeated timestamps as well - they seem to be preceeded by a huge timestep, which makes it look like the computer was receiving (or registering) the data "in a burst" later on.

Wade, your export looks good, very similar to the ones I did locally with my DIY LPM.

netwave, can you try again with my version with the "Action to perform at the end" set to STOP? (click the SETTINGS button, chang the option and click OK - please do this before starting the measurement)

Also, netwave, what's your computer?
 
JAVA's demanding 94% CPU usage just for opening Peregrine & I've seen it up to 100% before I've clicked connect and start buttons.

My computer has no problems running big apps like wavelab & sony acid pro, It plays 1080p MKV files fine. All that demands far less on my CPU than JAVA which does not like single core CPU's it seems.
I'm running Windows 7 x64 OS & the computers an HP Pavillion DM3 with 3GB ram+256GB SSD HDD
It's an AMD Athlon II Neo K125 Single core Processor @ 1.7Ghz
It's nothing great, as I've had high spec laptop's before & they don't last due to excessive heat!

One thing I've just remembered!
I could not get Trevor's advised build of Processing,
The beta build version 2.0b7
It was removed from the host site: Download \ Processing.org So I'm on v2.1

So if anyone has 2.0b7 available that would be great.

I have an LG G Pad V500 on route with a 1.7 GHz Quad Core CPU so what's needed is a Peregrine.APK build so I can test out Wades BT add on ;)

Action to perform at the end> set to stop results in attachment!

Rob ;)
 

Attachments

Slightly better but still all over the place...

I'll see if I can get some free time tomorrow and take a closer look at this.
 
Trevor said:
Jesus... ~85% CPU utilization?

Java...

So... the choppiness. Story time!

In an earlier build of Peregrine, I built some logic into the graph rendering. If the time since the last received data and the current data packet differed from the average by a significant amount, a gap would be rendered in the graph.

This "feature" was undocumented (sorry) and was designed to display gaps in the graph where data was not transmitted to Peregrine during a laser test. The original logic was a little too sensitive, so I removed it for the time being so that I could figure out a good threshold for displaying a gap in the data.

The version of Peregrine that Atomicrox based his version on included this undocumented feature. The codebase that I built version 1.5 on did not.

That's why the gaps appear in one version, but do not in another.

Trevor
Click to expand...

I was just going to respond, that I was working on my ARG LPM 1.1v over the weekend and I noticed that the new version of Peregine no longer sees the LPM or allowsRX/TX input. Connection is FALSE and continues to hang.
:undecided: Not sure what has happened.
 
Which new version, 1.4 or 1.5?
Have you selected the correct protocol/baudrate?
 
That's awkward... and it works properly with the older version? can you post screenshots of the debug screen on the older version and either of the new versions?
 
Atomicrox said:
That's awkward... and it works properly with the older version? can you post screenshots of the debug screen on the older version and either of the new versions?
Click to expand...

Actually, I am thinking that there is a missing library somewhere or that the new JAVA somehow killed the serial libraries.... odd
I am going to go retry and get some pics of what's happening.

:undecided:
 
ARG said:
Can you connect over the Arduino serial monitor?
Click to expand...

Yes, so clearly this part works. I can connect over the Arduino serial monitor.
However, processing sketches refuse to see serial input..

I've attached 2 screen captures.
First .pdf attached is of Peregrine 1.5.0.

I'm going to try something in a few minutes to see if my theory is correct.
I think Processing has got the problem:confused:

UPDATE:

Looks like Processing 2.1 has got some language differences.
I just ran the sketch below, and behold... no serial input can be seen.

Code: 
import processing.serial.*;
Serial myPort;
String sensorReading="";
PFont font;


void setup() {
  size(400,200);
  myPort = new Serial(this, "tty.usbmodem1a1521", 9600);
  myPort.bufferUntil('\n');
  font = createFont(PFont.list()[2],32);
  textFont(font);
}

void draw() {
  //The serialEvent controls the display
}  

void serialEvent (Serial myPort){
 
  if(sensorReading != null){
    sensorReading=trim(sensorReading);
  }

  writeText("Sensor Reading: " + sensorReading);
}


void writeText(String textToWrite){
  background(255);
  fill(0);
  text(textToWrite, width/20, height/2);   
}
 

Attachments

Last edited:
netwave said:
JAVA's demanding 94% CPU usage just for opening Peregrine & I've seen it up to 100% before I've clicked connect and start buttons.

My computer has no problems running big apps like wavelab & sony acid pro, It plays 1080p MKV files fine. All that demands far less on my CPU than JAVA which does not like single core CPU's it seems.
I'm running Windows 7 x64 OS & the computers an HP Pavillion DM3 with 3GB ram+256GB SSD HDD
It's an AMD Athlon II Neo K125 Single core Processor @ 1.7Ghz
It's nothing great, as I've had high spec laptop's before & they don't last due to excessive heat!

One thing I've just remembered!
I could not get Trevor's advised build of Processing,
The beta build version 2.0b7
It was removed from the host site: Download \ Processing.org So I'm on v2.1

So if anyone has 2.0b7 available that would be great.

I have an LG G Pad V500 on route with a 1.7 GHz Quad Core CPU so what's needed is a Peregrine.APK build so I can test out Wades BT add on ;)

Action to perform at the end> set to stop results in attachment!

Rob ;)
Click to expand...

Sorry for the late reply. Hadn't had the time to actually plug in my LPM and test till now.

I looked closer and noticed something very strange on your screenshot. On the debug window you have "Rerender true"... it should always be false when you do graphs with "End Action Stop".

That shouldn't happen at all. Can you reproduce this once more? If you can please post the exact procedure (button click by button click) that got you there. This might be a bug...

Rerender makes Peregrine redraw all the datapoints on the graph at every update - which is much heavier than drawing just what changed. That is needed when increasing the length of the graph or when rolling the window.

Also do you mind trying to run Peregrine 1.5 with the Measurement/Monitor option? You'll have to let it run for over 60 seconds to be sure it starts to rerender. Leave it for an extra 30s, then stop the measurement, take a screenshot of the debug pane and export the dataset. I want to see if 1.5 also gets choppy if we force it to rerender.

Sorry for asking you to do this a lot of times but I want to isolate this issue and, if it is indeed a bug/issue on Peregrine 1.4, fix it.
 
Ok, I just went through all settings on both versions & took notes, this is what I found..

peregrine 1.4
***********
open app
settings/action to perform: increase length/ok/connect/start/renderer is "false" /stop
close app
open app
settings/action to perform: stop/ok/connect/start/renderer is "false" /stop
close app
open app
settings/action to perform: roll window/ok/connect/start/ renderer is "false" /stop
close app

note* every setting graphs

_______________________________________________________________

peregrine 1.5
***********
open app
measurement/new/start/connect/renderer is "false"/disconnect
close app
open app
measurement monitor/connect/renderer is "false"/disconnect
close app
open app
measurement stop/connect/renderer is "true" (no graphing) /disconnect
close app

So to my findings , with the settings action to perform: stop in v1.4 it graphs
and measurement stop in v1.5 does not graph!
 
You must log in or register to reply here.





Back
Top