Design Comparison

8/13/2019 Design Comparison

http://slidepdf.com/reader/full/design-comparison 1/19

Wireless Data Acquisition and

Plotting: Final PresentationReview and Analysis of the Design Project

University of Tennessee, Fall 2013

Presented to Dr! A"idi and #$# %00 st&dents

'e(te)"er 1*, 2013



2

Topics Summary of the project's development timeline

Pro!lems encountered and our solutions

"#planation of the plotting soft$are% various approaches Technical analysis of sampling and data transmission

Future $or& and conclusion

Topics Timeline Pro!lems Technical

onclusion



3

Summary of Timeline Three separate plotting methods

( )odified *ogan Stan&'s Plotting Soft$are

+ Discovery of latency pro!lem ( ,-. Plot / Perl / data pipe

+ -ot enough control

( 0tustomPlot

+ Stro!oscopic pro!lem


onclusion



%

*ogan Stan&'s Soft$are: modified 1ery slo$ $aveforms

.na!le to handle high

sampling rates "#tremely messy

code!ase2organi3ation

A!solutely no

dynamic scaling


onclusion



+

*ogan Stan&'s Soft$are: modified Advantages of *ogan's soft$are:

( Direct line dra$ing using 4pen1 requires very

little a!straction: this means it could possi!ly !e

more efficient if it $ere developed more fully

( The plot $as easy to read


onclusion



*ogan Stan&'s Soft$are: modified5mplementation: We used the Windo$s net$or& AP5 to

acquire data from the Arduino server6 A TP handsha&e is

used to esta!lish a connection% follo$ed !y the

transmission of .DP data6 Samples are scaled to *ogan'sformat so that his code can plot them6 The server $as

configured at the commandline6


onclusion



-

-e#t: ,-.plot / Perl script Pros:

( )ore dynamic6 The plot $ould !e scaled each

time a plot $as created% !ased on $hat the

highest and lo$est samples $ere6

( "#tremely simple implementation

( The data $as piped through stdout and used to

spa$n a ,-.plot instance in realtime

Topics Timeline Pro!lems Technical onclusion



.

Topics Time*ine Pro!lems Technical onclusion

,-.plot / Perl Script ons:

( 1ery high latency due to the plotting of every

point received

( Slightly less fle#i!ility

( -e$ instances of ,-.plot for every screen

update is very ugly and inefficient

( orollary: not as dynamic as $e'd li&e



*

A vie$ of the ,-.plot solution 5t's some$hat !etter loo&ing7




10

0t ustomPlot SolutionPros:

( ompletely 4S independent

( an run as a standalone e#ecuta!le% provided theshared li!raries are availa!le

( 1ery nice for plotting live data

( "#tensive documentation

( Po$erful li!raries

( ,ood community locally




11

0tustomPlot 1ie$"ven !etterloo&ing than the ,-.plot solution7

Topics Timeline Pro!lems Plotting onclusion



12

0tustomPlot onsons:

( Plotting could !e very ta#ing to P.% depending

on the frame si3e and refresh rate

( Slightly more overhead in terms of dependencies




13

0tustomPlot4ther considerations:

( )ultithreaded handling of input from the server

and output to the monitor6 Data is read in over

.DP% and stored in a circular !uffer inside a

thread6 The same data is read from the !uffer and

plotted in another thread6

( onfiguration data is stored inside of a te#t fileand read at startup for convenience




1%

8est Solution: 0tustomPlotThis method $as sho$n to allo$ for very efficient

plotting% certainly the most efficient that $e have tried6

8eing a!le to adjust the $indo$ during e#ecution is very

nice6 This solution is e#tensi!le as $ell% as there are verymany areas ripe for improvement that could !e easily

tac&led $ith the 0t li!raries6




1+

Technical Analysis


)atla! $as used to analyse some of thedata $e received6

We counted 9;<= points per period

$hich $ould yield a sampling rate ofaround 9>?&sps6

@o$ever% from a previous test% ouraverage sample B rate $as only C6<&sps6 The difference !et$een the

average rate and $hat $as sho$n inthe picture could mean that there aresamples that are not !eing sent !y theArduino !oard6



1

Technical Analysis


After consulting $ith a DSP e#pert% it $asdetermined that samples are pro!a!ly!eing missed in the firm$are on theArduino !oard6

Plausi!le e#planation: the fact that $e gather? samples one at a time then transmitthem all at once over W5F56 While thetransmission is !eing performed% ne$samples are not !eing received6

Solution: Whenever a sample is generated !y

the AD generate an interrupt andimmediately store the sample inside of acircular !uffer6 This $ill allo$ samples to!e gathered even during the middle of atransmission6



1-

Future Wor&: Firm$are✔ Stop using the slow AnalogReadPin() function and

instead generate an interrupt whenever a sample has beenacquired and store that sample inside of a circular buffer.

✔ Once the circular buffer has been implemented, transmitsamples from it instead of the current buffer.

✔ Increase SPI Bus Speeds on both the Arduino Board andthe WIFI shield to increase data TX speed.

✔ Networking: remove man-in-middle (router) and performan ad hoc connection to the client.




1.

Future Wor&: Plotting Soft$are


Add a control panel that $ill allo$ users to input thesampling rate of the AD% so that time can !e displayed on

the hori3ontal a#is6 Add a control panel that $ill allo$ the user to adjust the

hori3ontal and vertical scales of the plot and ho$ manypoints that are displayed at the same time6

Add a control panel that $ill allo$ the user to set a triggervoltage so that the plotting soft$are can trigger li&e a realscope6



1*

All's Well That "nds Well

We've loo&ed at our failures and successes% and our

solutions to the several stum!ling !loc&s6 5 !elieve $e

might have had a more fulfilling project if $e had a

little more time% !ecause $e're at the point $here

another month $ould sho$ drastic improvements6

Than& you for your time6 Fin.


Documents

Design Comparison