Peregrine 1.4 beta - Packed with new features!

First of all many thanks to Trevor for this wonderful piece of software!

I've been working on some modifications/additions to Peregrine and now I think I've got enough new stuff to be worth sharing my version with your guys. I talked with Trevor and he had the great idea of creating a new thread and letting people beta test my version for some time before merging it back on the official version.

Please post your feedback, even if it is to say it didn't run or you didn't like it. Let me know if you find any (unknown) bugs.

Here it is, at last: Peregrine 1.4!
Download it here.

Here's an exported graph showing some of the new features (software zeroing, selection box exporting and minimum power)


Here's a shot of the interface with the new buttons (sorry, no laser)


The changelog is quite long but IMHO very worth reading, else you might not notice some of the new features.

Changes from version 1.2.1.3 (made by Trevor) to version 1.4 (made by Atomic)

• Changed version to 1.4
• Changed autorange algorithm - now it goes: 1, 2, 3, ..., 9, 10, 20, 30, ..., 90, 100, 200, 300, ..., 900, 1000, 2000, 3000, ..., 9000, 10000, 20000 and so on.
• Interface changes
  • Moved status bar to bottom
  • Moved buttons
  • Moved contents of the Measurement menu to buttons because they're used all the time
    • Moved measurements settings from New to a Settings button
    • Changed the New menu to a (Re)start button, that starts a new measuremnt with current settings and discards the old one
    • Stop button will stop current measurement without erasing, just like it did before
  • Added the last missing time label on the graph and resized to accomodate
• Merged monitoring mode and regular measurements
  • New end action setting:
    • Stop: stops measuring when the graph border is reached
    • Roll Window: starts to roll the window when the graph border is reached, discarding old readings (this is the same as the old monitoring mode)
    • Increase Length: keeps getting new measurements and resizing the graph to fit, use this when you don't know how long you'll measure before starting (might slow down if you use it for a long time)
    • Added end action to configs
  • Threshold can be left negative or blank to disable - use this to start measuring as soon as you press (Re)start
    • Added default threshold to configs
• Removed auto start when connecting because it didn't read new settings - use the (Re)start button
• Cancelling the Settings dialog will now properly revert the changes made
• Added background color setting
• Made grid a lighter shade of grey (on both real time and exported graphs)
• Allowed saving whenever graphing is stopped (allows empty graphs but that's fine to me)
• Added software zeroing
  • Amount of samples to take before computing the zero can be set on configs (more samples will take longer but produce a better zero, adjust based on the datarate of your LPM)
  • Type of zero can be set on configs:
    • Minimum: use the smallest reading from the samples (will fluctuate slightly above zero, with rare negative readings)
    • Average (recommended): use the average of all the samples (will fluctuate around zero but both positive and negative readings might happen)
    • Maximum: use the highest reading from the samples (will fluctuate slightly below zero, with rare positive readings)
  • Added a panel that shows current zero
  • Added buttons to zero and unzero
  • Zero will be on exported graph if it's being used
• Added minimum reading panel
  • Added minimum on exported graph
• Improvements to exported graph
  • Added default export dir config, will default to user folder if commented out
  • Changed the code to make the graph mathematically accurate, considering the limitations of floating point math and rounding
    • Rescaled the time axis to include the borders and not just the inside
    • Made sure the graph line draws over everything else (border, grid and selection)
  • The selection box is now exported and the Peak/Average/Minimum readings will be taken from the selection
  • Added width and height configs (height was already there but didn't work) and made the exported graph resize accordingly (there are some limitations listed on the config file)
• Added autoconnect config - just type the name of your COM port and it will connect as soon as you plug it in
• Added software oversampling - this will collect a number of samples, compute the average and treat them as a single sample
  • Choose the amount of samples to average on the Settings dialog (more samples will decrease error/increase resolution but will lower the datarate) (use more samples to accurately read weak lasers) (can be left negative/zero/blank to disable)
  • Added to configs
• Internal changes:
  • Used enums instead of constants when possible
  • Centralized config loading
  • Removed start_flag
  • Removed done state
  • Added some debug values and moved others to fit window
  • Moved/restyled a lot of code (but not all of it)
  • Added some helper methods: drawRectangle, toPanelFormat and toRoundedString
  • Added variables for background, grid and selection box colors that affect both the real time graph and the exported graph, to make easier to add configs for them eventually

As any biggish software this has some bugs. Here's the list of what I've found so far.

Known bugs

• Real time graph has a few inaccuracies (use the exported graph when accuracy is needed)
  • A reading of 10% wont fall exactly on the first grid
  • The selection box is off by a few pixels
  • Grid size isn't consistent
• Peregrine will slow down if you leave it collecting data on Increase Length mode (workaround: increase oversampling to store less readings)
• Datarate seems slightly wrong when a lot of oversampling is used, needs further investigation but does not seem to affect accuracy

Subbed to remind me to read the details after lunch

http://www.radiantelectronics.org/Peregrine/1375558433249.zip

hosted it for you

Craig

Awesome!

For the moment, this build is an independent fork off of the official current build. By all accounts, everything seems to be working fine, but we want to make sure all is well before we incorporate everything into the main project.

Happy to see others working on my project as well. People like you are what makes open source successful.

Here it is on the OpenLPM web space: http://www.openlpm.com/peregrine/atomicrox_fork/peregrine_1_4.zip

Trevor

Thanks for hosting guys, I've changed the OP link to Trevor's host since he is the father of Peregrine.

Having a play with Atomics build with the zeroing feature...
I'm testing on the Cubic Meter via USB Com 9
At the top of Peregrine where is says Meter/Data Stream what should I select n'
what does that feature actually do?
Cheers.

That tells Peregrine how to understand the data received. Each LPM requires a different setting depending on it's firmware, you could ask Wade or try them out until one works (most likely Simple or OpenLPM). If it's working you got the right one already.

I raised the question as this beta build is graphing with either simple, kemometer, or laserbee selected!
I settled for the simple protocol being that Cubic was not an option & obviously don't own the other LPMs.
However the graphing remains choppy?
Maybe with all the extra's in this build, It's too much for my single core K125 processor?

Testing with Peregrine v1.5.0.4
I see under the (meter drop down) the data stream/LPM selection has been removed & replaced with Buad rate working for me at 9600 & no choppiness what so ever the graphing now..
It appears Peregrine v1.5.0.4 auto selects the protocol to be input_simple so that's how it will remain for now

Actually CPU usage and Ram allocation between the two builds are minimal looking at the de bug charts, so rules out the extra's in v1.4b & my computer processor theory!

So what do you think causes the graph line to go choppy? By that I mean the gaps in the graph line in the 1st image to be more specific.

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

If it's working with any setting you don't need to worry. Those don't interfere with any features.

The thing is that this (1.4) was forked from 1.2 - I started working on some new features and Trevor continued to work on other features. Then I released 1.4 and he released 1.5 without merging the code together. I think he intends to do that eventually, adding my features back to the "regular" version.

I never had that issue with my LPM but from what Trevor said I'm guessing that probably indicates some sort of problem with your LPM. It should be sending the data at a regular interval... currently you'll end up with an inaccurate graph either way - with gaps or "stitched", depending on which version you decide to use.

I'm guessing this is due to the bluetooth connection. Does it support USB datalogging? If it does, can you connect it through USB and test again? Maybe using a bluetooth connection for datalogging isn't a good idea after all.

There's one situation in which my version *will* be quite heavy on the processor - if you leave it increasing the length of the graph for a very long time (it has to redraw the whole graph every time and that takes some time if you have too much data). The solution is to increase oversampling, leaving less data to be redrawn.

Thanks Trevor, that explains things

Atomic, I've only been doing USB data logging so far, so anything Bluetooth is
irrelevant at this stage.

Thanks for the oversampling tip, I've since tried another laser & I'm getting smoother graphing :beer:

Strange. You might want to talk to Wade about that, maybe there's something in his code that can be improved to send the data at regular intervals..

Mind uploading a CSV export of a test? I'd like to have a look, just to see how large the fluctuations in the gaps are.

Trevor

Atomicrox said:

Strange. You might want to talk to Wade about that, maybe there's something in his code that can be improved to send the data at regular intervals..

Click to expand...

I just had a PM from Wade saying It should be sending around 10 data points per second with some minor fluctuation

Trevor said:

Mind uploading a CSV export of a test? I'd like to have a look, just to see how large the fluctuations in the gaps are.

Trevor

Click to expand...

I've just noticed, an exported graph image has the gaps stitched together!
Attached images with the CSV

Rob.