X-Virus-Scanned: clean according to Sophos on Logan.com Return-Path: Received: from ispmxmta06-srv.alltel.net ([166.102.165.167] verified) by logan.com (CommuniGate Pro SMTP 5.0.9) with ESMTP id 1073922 for flyrotary@lancaironline.net; Wed, 19 Apr 2006 21:28:35 -0400 Received-SPF: pass receiver=logan.com; client-ip=166.102.165.167; envelope-from=trpeters@alltel.net Received: from ispmxaamta05-gx.alltel.net ([69.40.91.233]) by ispmxmta06-srv.alltel.net with ESMTP id <20060420012749.KVBL12807.ispmxmta06-srv.alltel.net@ispmxaamta05-gx.alltel.net> for ; Wed, 19 Apr 2006 20:27:49 -0500 Received: from 3F8JX51SHAW ([69.40.91.233]) by ispmxaamta05-gx.alltel.net with SMTP id <20060420012748.GWBB21540.ispmxaamta05-gx.alltel.net@3F8JX51SHAW> for ; Wed, 19 Apr 2006 20:27:48 -0500 Message-ID: <000e01c66419$a2a28e00$6400a8c0@shaw.shawinc.com> From: "Timothy Peters" To: "Rotary motors in aircraft" References: Subject: Re: [FlyRotary] Re: Possible data-logging solution? Date: Wed, 19 Apr 2006 21:27:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C663F8.1B660D70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C663F8.1B660D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageTracy, Just a couple of questions/comments... How will the data transfer be triggered? The most obvious would be a = command sent by the PC, but you could have a physical push button send = on the EM2 if your end is not bi-directional. I assume when you are talking about markers like $F9, you are not = talking about the ASCII characters but Hex... but then word length is 16 = bits. I may be missing something there. I guess it doesn't really = matter since I would read binary, and just keep binary format for each = marker... or look for fixed length returns for each channel if the = individual values can get high enough to encroach on the markers. Flow control isn't a problem since even the most basic PC has much more = memory available to buffer the transfer than most Integrated Control = chip memory allocation. The latest real time logging I have been = working on can file append 10,000 lines (80 ASCII characters a line) a = minute clocking less than 10% CPU time. An application should be able = to write as fast as you can send, or just save in memory to be written = after transfer.=20 I'm not a huge fan of Excel. I would probably graph out each channel in = the application display with some form of movable correlation line = marking the identical time position in each graph with text fields = showing the text data for a given time position. I already do something = similar to that with factory Schedule/Demand monitors. If users want to = view/manipulate the data in their own way, a dump to a .CSV file that = any spreadsheet program can import is fairly simple. I work for a manufacturing company, so this is the sort of programming I = do. Computer integrated manufacturing with single point control / = communication / data display with PLC's, scales, scanners, mainframe = computers, etc. =20 If Joe decides against working on this, let me know and I'll take a shot = at it. -Tim ----- Original Message -----=20 From: Tracy Crook=20 To: Rotary motors in aircraft=20 Sent: Wednesday, April 19, 2006 7:36 PM Subject: [FlyRotary] Re: Possible data-logging solution? Thanks Tim, =20 Joe Hull is a pretty good programmer and said he would take a look at = it but don't have any commitments at this point. Any and all help would = be appreciated on either part of this project. I'm simply out of time = to do it all myself. Any contributor will get full credit for their = efforts and if this stuff ever makes any profit, I'll count you in for = royalties! (hint, it won't be like winning the Power Ball Lotto : ) For anyone interested, Boring technical details of the task follow = below: All others may delete message now. =20 Data logger protocol This protocol is still being worked out so if you have any suggestions = to make it easier of more reliable, fire away. =20 The first part needed is a PC Program to input a stream of data words = on a serial port from the data logger and store them as a disk file. = The words will represent multiple blocks of 28 14 bit values. Each 14 = bit word in the block is one of the 28 data channels in the EM2 engine = monitor. There is one 28 word block for each 2 second sample period. = Definition and order of data words still being developed. The serial data file stream is preceded by a file start marker byte of = $F9. The data words are then sent as two bytes having the msb (bit 7) = cleared and the lower 7 bits holding the data. The least significant 7 = bits of the 14 bit word are sent first. At the end of each 28 word data = block there will be an end of block marker of $FA.=20 The end of the data file will be signified by an end of file marker = byte of $FF. =20 The async serial data will come from the data logger at a baud-rate of = 19,200. Currently there are no flow control lines (CTS / RTS) on this = serial interface but these could be added if necessary. =20 The second half will be an EXCEL spreadsheet that displays the data = file as 28 channels in chart form with time being the X axis (2 seconds = per data block) and the value of each channel plotted on the Y axis. = Don't know if it is practical to display all 28 channels on one chart = (would be nice, in order to see unexpected correlations) or to have = separate charts for various groups. Each channel will be associated with a different formula to convert = the raw sensor data word to human readable units (degrees F, PSI, etc.) = These formulas are already developed. I have only a little EXCEL experience so I don't know if I'm expecting = too much from it or not. Your input welcome here. Tracy Tracy, If you don't have any volunteers by now, get me the details and I'll = take a look at it. =20 -Tim ----- Original Message -----=20 From: Tracy Crook=20 To: Rotary motors in aircraft=20 Sent: Monday, April 17, 2006 10:14 AM Subject: [FlyRotary] Re: Possible data-logging solution? I'll check this out but in the mean time I added a simple data = logger to the fly-by-wire board since it only required the addition of 1 = inexpensive part. Data logging time is limited to 74 minutes at a = sample rate of once every 2 seconds. This should be plenty for = analyzing cooling & performance issues. It ain't over yet since this only stores the raw sensor data. As = Rusty points out, I (or a volunteer with some programming/EXCEL chops?) = need to write the program to download the data and an EXCEL spreadsheet = to display it in a nice chart. BTW, Congrats Buly! Now, give us more details on that needed = cooling tune-up : ) Tracy (did I mention I was looking for volunteer programmers?) Subject: [FlyRotary] Re: Possible data-logging solution? Tracy: Could this module be added to the EM2 or EC2 to add = datalogging in a simple manner? http://www.labjack.com/labjack_u3.html=20 Interesting Phil. I just bought a serial data logger for my = Dynon DS180 (EFIS and EMS). I just received the Dynon, and data logger, = so I haven't had time to try anything with them, but this setup has = promise for Tracy's stuff as well. =20 http://www.zen30649.zen.co.uk/product_antilog.html At the moment, the unit only logs one of the two serial = channels, but in the next version of software, it will log both = channels. It uses SD or MMC memory cards, so you can take them home to = read them. The OEM version has this card slot available on the bottom = of the board, where the boxed version is enclosed. I'm told you can use = any branded memory, so you don't have to buy theirs. I got the 128 mb = version, since they seem to screw you on the memory cost, and I can buy = larger cards much cheaper from other vendors. =20 They don't use the FAT file system, so you need their "reader" = program to read the memory card on a PC, or you can use a laptop and = download the data via X-modem. Once I get the data, the next problem = will be figuring out what to do with it. I guess I'll be learning more = about Excel than I cared to know. =20 Cheers, Rusty (one week until my "sentence" in Cleveland starts) ------=_NextPart_000_000B_01C663F8.1B660D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Tracy,
 
Just a couple of = questions/comments...
 
How will the data transfer be triggered?  = The most=20 obvious would be a command sent by the PC, but you could have a physical = push=20 button send on the EM2 if your end is not = bi-directional.
 
I assume when you are talking about markers like = $F9, you=20 are not talking about the ASCII characters but Hex... but then word = length is 16=20 bits.  I may be missing something there.  I guess it doesn't = really=20 matter since I would read binary, and just keep binary format for each = marker...=20 or look for fixed length returns for each channel if the individual = values can=20 get high enough to encroach on the markers.
 
Flow control isn't a problem since even the most = basic PC=20 has much more memory available to buffer the transfer than most = Integrated=20 Control chip memory allocation.  The latest real time logging = I have=20 been working on can file append 10,000 lines (80 ASCII = characters=20 a line) a minute clocking less than 10% CPU time.  An = application=20 should be able to write as fast as you can send, or just save in memory = to be=20 written after transfer. 
 
I'm not a huge fan of Excel.  I would = probably=20 graph out each channel in the application display with = some form=20 of movable correlation line marking the identical time position in each = graph=20 with text fields showing the text data for a given time position.  = I=20 already do something similar to that with factory = Schedule/Demand=20 monitors.  If users want to view/manipulate the data in = their own=20 way, a dump to a .CSV file that any spreadsheet program can import is = fairly=20 simple.
 
I work for a manufacturing company, so this is = the sort of=20 programming I do.  Computer integrated manufacturing with single = point=20 control / communication / data display with PLC's, scales, = scanners,=20 mainframe computers, etc. 
 
If Joe decides against working on this, let me = know and=20 I'll take a shot at it.
 
-Tim
 
 
----- Original Message -----
From:=20 Tracy = Crook
Sent: Wednesday, April 19, 2006 = 7:36=20 PM
Subject: [FlyRotary] Re: = Possible=20 data-logging solution?

Thanks Tim, 
Joe Hull is a pretty good programmer and said he would take a = look at it=20 but don't have any commitments at this point.  Any and all help = would be=20 appreciated on either part of this project.  I'm simply out of = time to do=20 it all myself.  Any contributor will get full credit for their = efforts=20 and if this stuff ever makes any profit, I'll count you in for=20 royalties!  (hint, it won't be like winning the Power Ball Lotto = :=20 )
 
For anyone interested, Boring technical details of the task = follow=20 below:  All others may delete message now. 
 
 Data logger protocol
 
This protocol is still being worked out so if you have any = suggestions to=20 make it easier of more reliable, fire away.   
 
The first part needed is a PC Program to input a stream = of data words on a serial port from the data = logger and=20 store them as a disk file.  The words will represent multiple = blocks of=20 28 14 bit values.    Each 14 bit word in the block = is one=20 of the 28 data channels in the EM2 engine monitor.  There is = one 28=20 word block for each 2 second sample period.  Definition and order = of data=20 words still being developed.
 
The serial data file stream is preceded by a=20 file start marker byte of $F9.  The data words are then sent = as two=20 bytes having the msb (bit 7) cleared and the lower 7 bits holding = the=20 data.  The least significant 7 bits of the 14 bit word are sent=20 first.  At the end of each 28 word data block there will be an = end of=20 block marker of $FA. 
 
The end of the data file will be signified by an end of = file=20 marker byte of $FF. 
 
The async serial data will come from the data logger at a = baud-rate of=20 19,200.   Currently there are no flow control lines (CTS / = RTS) on=20 this serial interface but these could be added if necessary.  =
 
The second half will be an EXCEL spreadsheet that displays the = data file=20 as 28 channels in chart form with time being the X axis (2 seconds per = data=20 block) and the value of each channel plotted on the Y = axis.   Don't=20 know if it is practical to display all 28 channels on one chart (would = be=20 nice,  in order to see unexpected correlations) or to have = separate=20 charts for various groups.
 
Each channel will be associated with a different formula to = convert the=20 raw sensor data word to human readable units (degrees F, PSI,=20 etc.)   These formulas are already developed.
 
I have only a little EXCEL experience so I don't know if=20 I'm expecting too much from it or not.  Your input welcome=20 here.
 
Tracy

Tracy,
 
If you don't have any volunteers by now, get = me the=20 details and I'll take a look at it. 
 
-Tim
 
----- Original Message ----- =
From:=20 Tracy=20 Crook
To: Rotary motors in = aircraft=20
Sent: Monday, April 17, = 2006 10:14=20 AM
Subject: [FlyRotary] Re: = Possible=20 data-logging solution?

I'll check this out but in the mean time I added a simple = data=20 logger to the fly-by-wire board since it only required the = addition of 1=20 inexpensive part.   Data logging time is limited to 74 = minutes=20 at a sample rate of once every 2 seconds.   This = should be=20 plenty for analyzing cooling & performance issues.
 
It ain't over yet since this only stores the raw = sensor=20 data.  As Rusty points out, I (or a volunteer with some=20 programming/EXCEL chops?) need to write the program to download = the data=20 and an EXCEL spreadsheet to display it in a nice=20 chart.
 
BTW,  Congrats Buly!  Now, give us more = details on=20 that needed cooling tune-up : )
 
Tracy  (did I mention I was looking for = volunteer=20 programmers?)
 
 
Subject: [FlyRotary] Re: Possible data-logging = solution?

Tracy:   Could = this module be=20 added to the EM2 or EC2 to add datalogging in a simple = manner?

http://www.labjack.com/la= bjack_u3.html 
 
Interesting=20 Phil.  I just bought a serial data logger for my Dynon = DS180 (EFIS=20 and EMS).  I just received the Dynon, and data logger, = so I=20 haven't had time to try anything with them, but this setup = has=20 promise for Tracy's stuff as=20 well.  
 
http://www.ze= n30649.zen.co.uk/product_antilog.html
 
At the = moment, the=20 unit only logs one of the two serial channels, but in = the next=20 version of software, it will log both channels.  = It uses SD or=20 MMC memory cards, so you can take them home to read them.  = The OEM=20 version has this card slot available on the bottom of = the=20 board, where the boxed version is enclosed.  I'm told you = can use=20 any branded memory, so you don't have to buy theirs.  I got = the 128=20 mb version, since they seem to screw you on the = memory cost,=20 and I can buy larger cards much cheaper from other=20 vendors.  
 
They = don't use the=20 FAT file system, so you need their "reader" program to read the = memory=20 card on a PC, or you can use a laptop and download the data = via=20 X-modem.  Once I get the data, the next problem will be = figuring=20 out what to do with it.  I guess I'll be learning more = about Excel=20 than I cared to know. 
 
Cheers,
Rusty = (one week=20 until my "sentence" in Cleveland = starts)
 
  
------=_NextPart_000_000B_01C663F8.1B660D70--