Peregrine 1.4 beta - Packed with new features!

Atomicrox · Jan 16, 2014

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.

wee40811 · Jan 16, 2014

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.

netwave · Jan 16, 2014

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?

wee40811 · Jan 17, 2014

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:

Atomicrox · Jan 17, 2014

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?

netwave · Jan 18, 2014

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

Atomicrox · Jan 18, 2014

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.

Seoul_lasers · Jan 19, 2014

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

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.

Atomicrox · Jan 19, 2014

Which new version, 1.4 or 1.5?
Have you selected the correct protocol/baudrate?

Seoul_lasers · Jan 19, 2014

Atomicrox said:
Which new version, 1.4 or 1.5?
Have you selected the correct protocol/baudrate?

Both 1.4 and 1.5 and the baudrate is set properly.

Connection in the debug shows FALSE.

:undecided:

Atomicrox · Jan 19, 2014

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?

Seoul_lasers · Jan 19, 2014

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?

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 · Jan 19, 2014

Can you connect over the Arduino serial monitor?

Seoul_lasers · Jan 20, 2014

ARG said:
Can you connect over the Arduino serial monitor?

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

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);   
}

Atomicrox · Jan 20, 2014

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

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.

netwave · Jan 20, 2014

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!

Peregrine 1.4 beta - Packed with new features!

Atomicrox

Well-known member

wee40811

New member

Attachments

netwave

Member

Attachments

wee40811

New member

Atomicrox

Well-known member

netwave

Member

Attachments

Atomicrox

Well-known member

Seoul_lasers

Well-known member

Atomicrox

Well-known member

Seoul_lasers

Well-known member

Atomicrox

Well-known member

Seoul_lasers

Well-known member

ARG

Well-known member

Seoul_lasers

Well-known member

Attachments

Atomicrox

Well-known member

netwave

Member

Online statistics

Forum statistics

Share this page