Printable View
I suspect the answer to my problem will be embarrasingly simple?
I am using a rotary pot fixed to a wind vein to record wind direction.
Assume that NORTH is 0 on the A/D reading [Maximum 255]
I want to average, say two readings, to smooth the results:
Reading 1 = 255, Reading 2 = 1, Average = 128 [ i.e SOUTH]
Reading 1 = 128, Reading 2 = 128, Average = 128 [SOUTH again]
Any ideas please? Sorry if this is an idiot question!
Regards Bill legge
Not an idiot question, the answer might be . . . .Quote:
Originally Posted by Bill Legge
store the values in a word variable, i e reading = (reading + reading) / 2
so reading1 = 255 + reading2 =256/2 = 128 . You can oversample several times to increase accuracy.
Take a peek at this thread, kind of interesting.
http://www.picbasic.co.uk/forum/showthread.php?t=6650
That is the same thing he has? I think.Quote:
Originally Posted by Joe S.
Hi Bill, the simple solution I can suggest is:
A1=Reading1*100/average
A2=Reading2*100/average
If A1>A2 then
If A1-A2>10 then discard
else
If A2-A1>10 then discard
endif
Naturally you can change the 10% threshold and lower it or increase it.
Al.
OK, except I think, thought. . . he was not adding them together in a <b>WORD</b> variable since byte only holds 255Quote:
Originally Posted by mackrackit
Bill,
If I understood your question correctly, when the A/D converter gives you a value of 0 that means pointing North and when you get a value of 128 that means pointing South (range is 0-255). Well, averaging a reading equal to 1 with a reading equal to 255 won't work. These two readings are close to 0 (North) but if you average then out you will get a value of 128 which is pointing South, the opposite direction.
This problem is harder than what it looks, so don't think you are asking an idiot question. Right now I can't think of a way of averaging these two values using simple algebra or a simple algorithm. However, by using trigonometry these kinds of problems are very easy to do. Unfortunately, PBP does not offer too many trigonometric functions except sine and cosine.
My suggestion,
- Treat each reading as an angle (that's what they really are).
- Use the PBP cosine function to add the X components of the angles (they can be as many as you want).
- Use the PBP sine function to add the Y components of the angles.
- Determine the new value of the new angle (new reading)
I am very sorry if I confused you more than what I helped you, but if you need help let me know.
Robert
First of all - a bit of relief that my difficulty is not in the 'daft' category.
1. Thanks for pointing me to the earlier discussion. I see M's solution and agree that it works fine with two readings - but I can't see an easy way of doing it with an array; say 16 readings? And wind direction needs a good bit of averaging to get a good result.
2. Effect of wind speed. I agree that wind direction is meaningless unless the wind is blowing. I have a threshold that discards direction reading unless there is a reasonable wind speed.
3. Trignometric solution. thanks, a neat idea but how to get the an angle once all the SIN and COS have been summed/differenced? I don't think inverse trig functions are available?
Overall, the task seems so visually simple that I still feel that some addition/subtraction of readings will do the trick. Perhaps it's as simple as:
1. Use, say, the first vector as a reference (zero)
2. Always measuring clockwise, add the angle to the next vector
3. divide by the number of vectors
4. Add this to the first vector
5. Subtract 256 if necssary (i.e one revolution)
The trick is to always measure angles in the same direction, say clockwise?
Regards Bill Legge
Bill,
Yes, you might be in the right track by measuring angles in the same direction. This might work for two angles, but if you need more than two readings it can get quite complex. Still you need to work out the algorithm and tested with different values.
I know that in order to get the angle you need inverse trigonometric functions, inverse tangent to be specific which is not available in PBP (maybe in future versions). But, I didn't want to throw that in here just in case you were not familiar with these functions. However if you know the signs of the X and Y resultant components that will tell you in which quadrant the angle is and that is a big help.
Note that the method of summing two readings and dividing by two (averaging) works most of the times. The only times that it doesn't work is when one of the readings value range is (0 < reading1 < 64) and the other value range is (192 < reading2 <= 255). When this happens you get bad results. Then, you might need to add or substract 128. Based on this info you should be able to write your algorithm.
Robert
Here's one that works real well.
But it requires PBP 2.60 for the ATN function.
The measured wind direction should be in the variable DIR.
Then GOSUB Avg_Wind
It works by averaging the SIN and COS separately for each sample.
Then converts those averages back to an angle with ATN.
Angles range from 0-255, representing 0-359 degrees.
If you don't have 2.60, the same thing can probably be done with scalerobotics cordic trig routines.Code:CLEAR
DIR VAR BYTE ; Current sample of wind direction (0-255)
S VAR BYTE ; averaged SIN
C VAR BYTE ; averaged COS
Wind VAR BYTE ; final averaged wind direction
Temp VAR BYTE ; temporary variable
AvgCount CON 10 ; amount of averaging to apply
;---------------------------------------------------------------
Avg_Wind: ; average in one DIR sample
Temp = SIN DIR+127
S=(S*(AvgCount-1)+Temp)/AvgCount
Temp = COS DIR+127
C=(C*(AvgCount-1)+Temp)/AvgCount
Wind = (C-127) ATN (S-127)
RETURN
;---------------------------------------------------------------
Set_Wind: ; Sets average wind direction without averaging
S = SIN DIR + 127
C = COS DIR + 127
GOTO Avg_Wind
HTH,
edit, I had a convoluted solution, but I have deleted it after seeing Darrel's elegant solution. Nice!
Hi Darell, could you explain me how you get the average?
Temp = SIN DIR+127 here variable Temp is equal to S since S=SIN DIR+127
Than
S=(S*(AvgCount-1)+Temp)/AvgCount
which is:
S=(S*9+S)/10
So S is still S
I must have lost something.
Al.
The results of the SIN and COS functions are a Signed number ranging from -127 to +127.
PBPW can't multiply or divide negative numbers, so they have to be scaled up to be worked with.
Since Temp is a Byte sized variable, adding 127 brings it up to a range of 0 to 254, which can then be averaged easily.
Then after averaging, 127 is subtracted to restore the signed numbers for use with ATN.
<hr>
For the averaging ...
The current average is multiplied by one less than the AvgCount, the new sample is added in for a total of 10 samples. Then it divides by 10 (AvgCount) to get the new average. No WORDs needed.Code:S=(S*9+Temp)/10 ; Temp is the new corrected sample
<br>
The new ATN function that Darrel mentions most likely stands for arctangent, which is the inverse tangent. It looks like this new PBP version is going to be loaded with a bunch of new goodies.
Robert
Yeah, I think it's more than fresh paint and new chrome bumpers, that's why I ordered mine yesterday. It's got some new array handling routines in there I am chompin' at the bit to try out.Quote:
Originally Posted by rsocor01
I think I've solved it for an array of 16 readings? The readings
1. A/D from a potentiometer
2. Range is 0 to 255
3. 0 is North, 64 East, 128 South,192 West
The rules:
1. Always work in pairs of vectors. Using EEPROM to store the vectors:0 to 15 Stores the vectors. 8 pairs16 to 23 Stores the next pairing. 4 pairs24 to 27 Stores the next pairing. 2 pairs28 to 29 Stores the last pair. 1 pair30 Stores the result2. If the difference between the vector pairs if <128 then average the vectors normally
3. If the difference between the vectors >128 then average normally, add 128, check for whole revolutions
I've run a fair number of tests and all seems to be OK?
Regards Bill Legge
Code:X VAR BYTE ' First vector
Y VAR BYTE ' Second vector
Difference VAR BYTE ' Difference between vectors, always +
Average VAR WORD ' Average of two vectors
J VAR BYTE ' EEPROM memory address
DATA 250,230,240,34,200,10,10,23,23,21,125,0,34,255,123 ' 16 vectors
Main:
FOR J = 0 TO 28 STEP 2 ' Read pairs of vectors
READ J, X
READ J+1,Y
if Y>X THEN SWAP X,Y ' X is always the larger variable
Difference = X-Y
Average = (Difference/2) + Y' Half difference and add to smaller vector
IF Difference>128 then
Average=Average+128 ' Reverse direction of vector
IF Average>255 THEN Average=Average-255 ' Whole revolution? Subtract 255 if necessary
ENDIF
WRITE J/2 + 16,Average
NEXT J
LCDOUT $fe,$80,"Average: ",DEC3 Average
END
Darell, I think that the problem given in post one still remain even with adding 1/10 of the variation (with your smooting system) because the variation are so big (1 to 255) that will making swinging also your reading if not filtered.
As far this new release of PBP 2.6 is concerned can you please clearify this trigonometric manipulation:
Wind = (C-127) ATN (S-127) = cos(a) (no math sign ?) ATN sin(a)
I know that tan(a) = sin(a)/cos(a) so (a) = atn (sin(a)/cos(a))
Is this the way that the new PBP use to extract the angle?
Thank you for your help in understanding.
Al.
Hmm, I don't know Bill.
I've had a play with your code, and I'm not sure about it.
It does seem to pick a valid point in-between two samples. But it only averages that point, and the previous point found between two other samples. It's not averaging all the samples, so it's still very jumpy.
Your explanation describes EEPROM locations up to 29, but there are only 15 DATA values, although I don't think that affects the problem.
I've modified the program a bit to use the Average as the X value, then read the samples one at a time, also connected a POT to simulate the wind vane, but I get the same results.
Another hiccup, if the average is currently 10, then it receives a string of 255 samples, it stops at 1, and never crosses 0. And for many other samples, it stops 1 number away from the actual reading. 250 might stop at 249 or 251.
I think finding a point in-between 2 samples is fairly easy. But averaging a large number of samples is something altogether different, and a 2-sample average just doesn't do it.
Aratti,
The ATN function is actually an ATAN2 type since it works for all four quadrants. An arctangent would only work with 1 quadrant.
The format of the statement is ...
Result = X ATN Y
There aren't any other "math signs" involved.
<br>
DT. Thanks for taking time to look into the code.
First, I wrote it specifically to average 16 samples - it won't work with any other number because of the counter:
J/2 + 16
This counter takes the average (or average+128 if the two sample are more that 128 apart - and checks for a 'roll-over' above 255) and stores them:
Samples 0 and 1 average stored in address 16
Samples 2 and 3 average stored in address 17
Samples 4 and 5 average stored in address 18
Samples 6 and 7 average stored in address 19
Samples 8 and 9 average stored in address 20
Samples 10 and 11 average stored in address 21
Samples 12 and 13 average stored in address 22
Samples 14 and 15 average stored in address 23
Then, the same J/2 + 16 deals with the next round of averages:
Averages of 16 and 17 stored in address 24
Averages of 18 and 19 stored in address 25
Averages of 20 and 21 stored in address 26
Avergaes of 22 and 23 stored in address 27
And again
Averages of 24 and 25 stored in address 28
Averages of 26 and 27 stored in address 29
And finally
Averages of 28 and 29 stored in address 30
I guess the same could be done for other numbers of samples but 16 seems a reasonable number for wind direction and the code is short and simple. I have spent a laborious few hours with a pocket calculator checking the results - and so far it is Ok. If you, or anyone else spots an error please let me know.
Regards Bill Legge
WOW! I really got that interpretation wrong didn't I? :o
OK, I think I understand what you're doing.
I'll play with that a bit and see what happens.
Thanks for explaining.
<br>
I'm thinking you might have a winner there Bill.
But I have a question or two.
I've had another go at your code and am getting some promising results.
It's hard to follow with a calculator, so I made an interface to help test the routines.
Also, instead of reading/writing to EEPROM, I've modified your routine to use an array, so that I can pass it data from the PC.
The array is a circular buffer that overwrites the oldest value with the new sample, and on each iteration runs your code to average all 16 samples in the array.
I'm thinking that the circular buffer might be a problem.
Maybe if it only took 16 samples then averaged ???
The modified routine looks like this ...The interface simply sends the Wind Vane readings to the PIC where it runs both of our averaging codes, and sends the results back for display.Code:X VAR BYTE ' First vector
Y VAR BYTE ' Second vector
Difference VAR BYTE ' Difference between vectors, always +
Average VAR WORD ' Average of two vectors
J VAR BYTE ' EEPROM memory address
BillsData VAR BYTE[32]
DataPos VAR BYTE
Bill_Avg:
DataPos = DataPos + 1
IF DataPos = 16 THEN DataPos = 0
BillsData(DataPos) = DIR
;DATA 250,230,240,34,200,10,10,23,23,21,125,0,34,255,123 ' 16 vectors
FOR J = 0 TO 28 STEP 2 ' Read pairs of vectors
; READ J, X
X = BillsData(J)
; READ J+1,Y
Y = BillsData(J+1)
if Y>X THEN SWAP X,Y ' X is always the larger variable
Difference = X-Y
Average = (Difference/2) + Y' Half difference and add to smaller vector
IF Difference>128 then
Average=Average+128 ' Reverse direction of vector
IF Average>255 THEN Average=Average-255 ' Whole revolution? Subtract 255 if necessary
ENDIF
; WRITE J/2 + 16,Average
BillsData(J/2 + 16) = Average
NEXT J
Bill_Value = Average
; LCDOUT $fe,$80,"Average: ",DEC3 Average
RETURN
Yours is on the right. Any thoughts on the sample buffer?
It works great unless there are large fast changes. (click image to play)
<object id='stUkhdQ01IR11XRFVbWlleU19R' width='711' height='444' type='application/x-shockwave-flash' data='http://www.screentoaster.com/swf/STPlayer.swf' codebase='http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,115,0'><param name='movie' value='http://www.screentoaster.com/swf/STPlayer.swf'/><param name='allowFullScreen' value='true'/><param name='allowScriptAccess' value='always'/><param name='flashvars' value='video=stUkhdQ01IR11XRFVbWlleU19R'/></object>
Sorry Internet Explorer only. :(
Darrel,
Thanks again for your investigation. The display 'InstruMental' is really good.
I guess the issue of:
1. Adding one new vector and then running the 'Averaging Tree' with 15 older vectors. Or...
2. Waiting till 16 new vectors are available and then running the 'Averaging Tree'
Is one of latency. And the selection should be based on:
1. The importance of immediate results.
2. The time interval between the availability of new vectors.
3. The need for the MCU to do other things.
I have attached some code that I used to send the averages to my PC with the screen presentation laid out so one can easily see, and check, the averages. The vectors come from a RANDOM function that loads up the PIC EEPROM. RS232 at 19,200 Baud on pin C.6. Loops continuosely.
Two questions for you please:
1. How does one post PBP code here so that it looks neat/tidy. My code looks OK on my PC but when I post it here it is a mess?
2. Is your 'InstruMental' writtern in Visual Basic? I want to learn this and recently got the book 'VISUAL BASIC FOR ELECTRONICS ENGINEERING APPLICATIONS' by Vincent Himpe. For me (An ex-electronics engineer) it's no good - starts off too advanced. Any advice on a good 'entry level' book?
Regards Bill Legge
Code:' -----[ Title ]-------------------------------------------------
'
' File...... WVL 877 VERTOR AVERAGE
' Purpose... Experiment with PIC16F877A
' Date...... July 2009
'
' -----[ Program Description ]---------------------------
'
' 1. Devices used: PIC16F877A on EasyPIC5
'
' ----[ Includes / Defines ]-----------------------------------------
'
define OSC 20 ' Define Xtal as 20 MHz. Use "HS" for programming
'
include "modedefs.bas" ' Include serout defines
'
' -----[ Initialization ]--------------------------------------------
'
ADCON1 = %00001110 ' A0 is analog, remainder digital
CMCON = %00000111 ' Comparators OFF
INTCON = $80 ' Turns off interrupts. See PBP page 187
TRISA = %00000001 ' A0 is A/D input
TRISB=0 : TRISC=0 : TRISD=0 : TRISE=0
PORTA=0 : PORTB=0 : PORTC=0 : PORTD=0 : PORTE=0
'
' ----[ Variables ]--------------------------------------------------
'
X VAR BYTE ' First vector READ
Y VAR byte ' Second vector READ
Vector var byte[31] ' Stores 16 A/D readings of wind direction and averages
Difference var byte ' Difference between vectors, always +
Average var word ' Average of two vectors
J var byte ' EEPROM memory address
K var word
Memory var byte ' Contents of EEPROM address J
TxPin var PORTC.6
Heartbeat var PORTC.0
'
'-----[ Main ]-------------------------------------------------------
'
Main:
for J = 0 to 15 ' Create 16 random numbers 1 to 255
random K
write J, K.lowbyte ' Load EEPROM with random numbers
next J
for J = 0 to 28 step 2 ' Read pairs of vectors
read J, X
read J+1,Y
if Y>X then swap X,Y ' X is always the larger variable
Difference = X-Y
Average = (Difference/2) + Y ' Half difference and add to smaller vector
IF DIFFERENCE>128 then
Average=Average+128 ' Reverse direction of vector
if Average>255 then Average=Average-255 ' Whole revolution? Subtract 255 if necessary
endif
write J/2 + 16,Average
next J
for J = 0 to 30 ' Send to PC at 19,200 Baud
read J, Vector[J]
next J
serout2 TxPin,32,["VECTOR ADDITION",13,13]
serout2 TxPin,32,[dec3 Vector[0],9,dec3 Vector[16],9,dec3 Vector[24],9,dec3 Vector[28],9,dec3 Vector[30],13]
serout2 TxPin,32,[dec3 Vector[1],13]
serout2 TxPin,32,[dec3 Vector[2],9,dec3 Vector[17],13]
serout2 TxPin,32,[dec3 Vector[3],13]
serout2 TxPin,32,[dec3 Vector[4],9,dec3 Vector[18],9,dec3 Vector[25],13]
serout2 TxPin,32,[dec3 Vector[5],13]
serout2 TxPin,32,[dec3 Vector[6],9,dec3 Vector[19],13]
serout2 TxPin,32,[dec3 Vector[7],13]
serout2 TxPin,32,[dec3 Vector[8],9,dec3 Vector[20],9,dec3 Vector[26],9,dec3 Vector[29],13]
serout2 TxPin,32,[dec3 Vector[9],13]
serout2 TxPin,32,[dec3 Vector[10],9,dec3 Vector[21],13]
serout2 TxPin,32,[dec3 Vector[11],13]
serout2 TxPin,32,[dec3 Vector[12],9,dec3 Vector[22],9,dec3 Vector[27],13]
serout2 TxPin,32,[dec3 Vector[13],13]
serout2 TxPin,32,[dec3 Vector[14],9,dec3 Vector[23],13]
serout2 TxPin,32,[dec3 Vector[15],13,13,13]
goto Main
END
Very nice animated simulation by DT. What program are you using to create this?
Now, in DT's posted program taking an average with "S=(S*(AvgCount-1)+Temp)/AvgCount" takes some time to converge. With sudden changes in wind direction, which is usually the case, a high sampling rate is needed to keep up with this algorithm. This is a common issue when averaging several readings.
Robert
Bill,
After more testing, I can say that the problem I was seeing was due to my averaging the circular buffer after each sample.
By taking 16 samples (at high speed) then averaging, the vane can never go more than 128 unless it's crossing zero and everything works fine. If the samples are slow enough that the vane can go more than 128, the problem shows up again.
I'm sticking with SIN/COS/ATN.<hr>
The program I'm using is DT_InstruMental. Something I've been working on for awhile that makes it easy to display info from the PIC graphically.
It's still in it's infancy, but the only way to figure out what I need to do with it, is to use it. ... So I'm using it.
Here's one of my favorites so far ... :)
<object id='stUkhdQ01IR11XRl9VWV1aVF5T' width='345' height='308' type='application/x-shockwave-flash' data='http://www.screentoaster.com/swf/STPlayer.swf' codebase='http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,115,0'><param name='movie' value='http://www.screentoaster.com/swf/STPlayer.swf'/><param name='allowFullScreen' value='true'/><param name='allowScriptAccess' value='always'/><param name='flashvars' value='video=stUkhdQ01IR11XRl9VWV1aVF5T'/></object>
It is what I 've been dreaming!
Can I have it?
Ioannis
NO! You can't have my KEG of beer. :eek:
Oh, you meant the program ...
I hope that everyone will have it someday, some kind of shareware/crippleware/demo, don't know yet.
But right now, you would hate me for the grief you would endure.
It really needs to be more user friendly, which is why I'm trying to use it as much as possible, so I can figure out the best way to go.
Before anyone gets it .. It must BE a dream, not a nighmare. :)
<br>
DT,
I used StampPlot from Selmaware for a PID motor control demonstration last year, thoughts on it ~ may be of some interest in your development?
1. Fantastic that I could produce a PC interface without learning Visual Basic.
2. I think it was free, or I paid a very small amount of $ for the improved graphic design function.
3. The complexity of the commands was OK once you had an example to modify ~ working with the User Guide alone was, in some cases, very difficult.
4. The supplied controls, whilst functionally good, were visually poor ~ I imagined they were modelled on instruments in a Soviet 1950 power station.
5. I would have been prepared to pay more for a better product that had the benefit of lots of polishing.
6. However, excellent value for the very low cost ~ a labour of love for the developer.
Regards Bill Legge
PS Any recomendations for a book on learn Visual Basic?
Bill,
Take a look at this software
http://www.abacom-online.de/uk/html/...ab-expert.html
I haven't used it yet but it looks like it would do the job. Has anybody used it?
Robert
Of course not! If I drink half of glass thenfor the rest of the day I 'll keep singing. And trust me, I am really bad singer!Quote:
Originally Posted by Darrel Taylor
About the software, I have no problem with the way you are going to distribute it, as long as I do not have to learn Visual $omething.
Ioannis
It displays fine on Firefox 3.0.12 here.Quote:
Sorry Internet Explorer only.
Bo
OH! Great, thanks.Quote:
Originally Posted by boroko
It must be my very old installation of FirFox that I never use.
I should update it I suppose. :o
<br>
Hi Folks,
Mainly for Darrel but happy to have input from all!
DT's example of averaging the direction (thanks Darrel) makes use of ATN from an 8 bit direction (0-255 = 0-359 degrees) and works well when I use this method with PBPro 2.60.
However this gives some inaccuracies and low resolution. I've acquired my direction with a 10 bit AD and converted down to 0-359 but no matter how I manipulate the numbers in DT's formula I get to about 270 deg's and then it rolls over with false values.
Is there a way to achieve the above or am I stuck with coarse direction? I'd like to have 1 degree changes if possible not the jumps 8 bit has.
Kind regards to all and thanks in advance,
Bill
As you have no code posted I can only guess that your vaariable are byte and not word.
Ioannis
Here is I use it and is very good.Quote:
Originally Posted by rsocor01
My scope project.
http://www.picbasic.co.uk/forum/atta...1&d=1269018483
Shouldn't it be converted to 0-255 (representing 0-359)?Quote:
Originally Posted by wjsmarine
ATN SIN and COS all use binary radians.
<br>
Hi Darrel and Ioannis,
Thanks for the help. I replied earlier but it didn't seem to make it, here goes again...
Ioannis the first thing I did when trying changes was to move to Words for the variables so was surprised when the numbers didn't crunch.
Darrel your code works well but gives 360/256 = 1.4 degree accuracy/resolution and I was hoping for better than this. I'm not strong at math so your comment about binary radians probably means I'm stuck with the original limits, which is probably okay for wind direction - but what do I do if I need greater accuracy for Tilt, etc?
Any suggestions and help is appreciated, thanks guys.
Bill
If you need more resolution, you'll need to pull out the Big Guns ...
Cordic trig assembly code for PIC18f (scalerobotics)
http://www.picbasic.co.uk/forum/showthread.php?t=10528
<br>
Bill, I also am trying to get an application going without having to use VB6. I need to interface a laptop computer to an 18F4550 based microcontroller via USB to read the data stored by the 18F4550 in its EEPROM over a 31 day period [93 bytes = 31 daily measurements x (date value, Data_LSB, Data_MSB) ] . I need the data to be inserted on the PC side into an Excel spreadsheet for plotting and analysis purposes by the user. It appears that StampPlot might be a candidate to do this, but it appears it really only works with BasicStamp and RS232 or serial interfaces and not USB. As a user of StampPlot can you advise me if I can adapt it to use for USB and PICBASICPro without a huge learning curve? My controller is done and my project has a short fuse so can't spend a lot of learning time to get the PC side and USB interface going Would really appreciate your advice!~Quote:
Originally Posted by Bill Legge
Jellis,
I thought this thread was long dead! My thoughts on PIC/USB/StampPlotPro:
1. StampPlotPro won't talk USB.
2. I don't know enough about USB comms to know how one would 'change' an incoming USB data stream, inside the laptop, to get it to talk to StampPlotPro.
I've now modified my weather station to record CSV files on a thumb drive by using a Vdrive2 module from Vinculum - about $50 - and transfer the data about once a month. However, this does not solve your need to get a 'real time display.'
I expect there must be some 'easy to customise' softwear for a PC that talks USB and gives a virtual instrument panel.
I keep putting off starting to learn VB. I'm told that it's quite easy? Thoughts on StampPlotPro:
1. Fast and easy to cobble displays together.
2. Documentation is pretty good.
3. I paid the extra ($20 I think?) for the add on bits - worth it.
4. The graphics are a bit '1950 Soviet power station' style - but you can add your own.
Sorry to be of little/no help to you. If you solve it, please let me know how.
Regards Bill Legge
If you use USB as CDC, it looks just like a COM port to the PC.
You should be able to convert any SEROUT's to ARRAYWRITE's, then send the array out USB to StampPlot.
Or you can send CSV text using CDC and capture it to a file with HyperTerminal.
Then import to excel.