/*
* IArmable.cs
*
* Copyright © 2010
* Diversified Technical Systems, Inc.
* All Rights Reserved.
*/
namespace DTS.DAS.Concepts
{
///
/// different possible arm modes
///
public enum AvailableArmModes
{
LowPower,
CircularBuffer,
};
///
/// different possible armstatus
///
public enum ArmStatus
{
Disarming,
Disarmed,
Arming,
Armed,
Recording, // Extra statuses (chuck's mail)
}
///
///
/// Formal description of the ability to "arm".
///
///
public interface IArmable
{
void Arm();
void Disarm();
ArmStatus ArmStatus { get; }
AvailableArmModes ArmMode { get; }
}
}
//Like Rollin said, NGI will (for now) be orphaned. NASCAR is in for sure. TSR6DX is really TSRPRO, I think. RateTestTSR==BlastTestTSR and needs to be flattened. TSR==TSRBasic. The missing one in that list is HEADSII.
//NASCAR is 3 16-bit channels using a 216 daughterboard.
//TSRPRO is 6 channels, 3 16-bit on a 216 daughterboard, 3 12-bit on the 215 motherboard
//BlastTestTSR is 7 channels, 4 12-bit on the 215 motherboard, 3 16-bit on a hacked daughterboard
//TSRBasic is 3 12-bit channels on the 215 motherboard
//HEADSII is 7 12-bit channels on the 221 board
//The other missing component to some of what you sent earlier is that some of these systems have multiple sample rates. BlastTestTSR will have the 4 12-bit channels @ 40ksps and the 3 16-bit channels @ 1ksps. NGI had 2 24-bit channels @ 1ksps and 2 16-bit (?? can't remember for sure) channels @ 1sps. As it stands now we have the lower level download code just interpolate slow data to fast data and then everything has the "same" sample rate at the upper level, but it might be nice to deal with it more formally since that creates some funny edge cases we have to deal with by limiting the download to occur in sample number chunks that are a multiple of the fast rate divided by the slow rate.
//On 8/12/2010 11:12 AM, Paul Hrissikopoulos wrote:
//> By the way, the types that the switches currently in the TSR2 code seem to think important are:
//>
//> TSRModel.NASCARIDR:
//> TSRModel.TSR6DX:
//> TSRModel.RateTestTSR:
//> TSRModel.BlastTSR:
//> TSRModel.TSR:
//> TSRModel.NGIPrototype:
//>
//> Are we going to want all of those? Some of those? Those and then some?
//>
//> On 8/12/2010 11:07 AM, Paul Hrissikopoulos wrote:
//>> I guess in theory the software should be able to deal with the multiplicity of device types as it sees fit -- some code, definitely including parts of the UI, will need to be able to actively discriminate between types before doing something type-specific, but I think the hope is that the bulk should be able to use it in a more generic sense (arm the same, download the same, realtime the same, etc.). But still maybe that's a valid point -- do we foresee a ton of cases where we'll be doing interface is/as and/or typefield checks before doing something?
//>>
//>> On 8/12/2010 10:50 AM, Tadd Seiff wrote:
//>>> I like this.
//>>>
//>>> My approach at the moment is immediately how to use this as a HEADS device. My understanding is that the device will surface through the factory which will populate things such as TSR.Channel[] Channels which can then be accessed safely only with RunTime checks like if (HEADS == unit.TSRModel) {...}. Does this put us in the same position being at the mercy of switch statements at a higher level? This is just my knee-jerk reaction.
//>>>
//>>> On 8/12/2010 10:08 AM, Paul Hrissikopoulos wrote:
//>>>> My reordering is attached. Search it for "?" for some open questions. Please let me know if you think I'm missing anything major (or minor) or am entirely on the wrong track.
//>>>>
//>>>> On 8/9/2010 10:26 PM, Rollin White wrote:
//>>>>> Here's an update with a channel class.
//>>>>>
//>>>>> Please voice concerns, opinions, etc. This is just my simple view of the task.
//>>>>>
//>>>>> On 8/9/2010 3:02 PM, Rollin White wrote:
//>>>>>> Here's my first cut at the interface description for the next generation TSR class. The interface is meant to describe the features common to all models.
//>>>>>>
//>>>>>> In addition to what's here, there needs to be significant definition of the channel class. Finally, there are probably a few interfaces that need to be defined that class implementers would optionally implement. For example, ISupportsDynamicEventLength.
//>>>>>>
//>>>>>> This is simply a starting point. Comments welcome.
//>>>>
//>>>
//>>
//>
//>
//--
//Chuck Gillen-O'Neel
//Diversified Technical Systems, Inc.
//909 Electric Avenue, Suite 206
//Seal Beach, CA 90740
//Telephone: (562) 493-0158
//Email: chuck.go@dtsweb.com
// My comments:
// * For sensitivity we should either have mv/count and eu/mv for each channel OR have eu/count for each channel. Obviously the former is more flexible, but also a little more complicated and maybe unneeded for 95-99% of TSR/HEADS applications.
// * OffsetCounts in IChannel should be signed. We nearly always need to make offsets signed. I'm speaking from my own mistakes here ... !!! :)
// * We need to think about the arm states a bit more. There have been a couple of cases where having a Disarming state, in addition to Disarmed, has been nice.
// * For GPIOs we might as well surface (and extend the firmware a bit to support this) the fact that IOs can be inputs as well as high/low outputs. So, rather than just returning a bool we might want to return a state enum. It's already there in the interface for SetGPIO since the GPIOPin.Direction enum has input and output and if it's set to input the State parameter is effectively a no-op.
// * The question of a good interface for Calibration is still unanswered. The interface as shown is obviously fine for doing those three readings, but I'm not sure how truly useful that is in a generic sense. I have a feeling that this is a place where we'll be hooking in model checks, etc. etc. Maybe that's okay and can be limited to the cal software.
//On 8/12/2010 10:50 AM, Tadd Seiff wrote:
//> I like this.
//>
//> My approach at the moment is immediately how to use this as a HEADS device. My understanding is that the device will surface through the factory which will populate things such as TSR.Channel[] Channels which can then be accessed safely only with RunTime checks like if (HEADS == unit.TSRModel) {...}. Does this put us in the same position being at the mercy of switch statements at a higher level? This is just my knee-jerk reaction.
//>
//> On 8/12/2010 10:08 AM, Paul Hrissikopoulos wrote:
//>> My reordering is attached. Search it for "?" for some open questions. Please let me know if you think I'm missing anything major (or minor) or am entirely on the wrong track.
//>>
//>> On 8/9/2010 10:26 PM, Rollin White wrote:
//>>> Here's an update with a channel class.
//>>>
//>>> Please voice concerns, opinions, etc. This is just my simple view of the task.
//>>>
//>>> On 8/9/2010 3:02 PM, Rollin White wrote:
//>>>> Here's my first cut at the interface description for the next generation TSR class. The interface is meant to describe the features common to all models.
//>>>>
//>>>> In addition to what's here, there needs to be significant definition of the channel class. Finally, there are probably a few interfaces that need to be defined that class implementers would optionally implement. For example, ISupportsDynamicEventLength.
//>>>>
//>>>> This is simply a starting point. Comments welcome.
//>>
//>
//--
//Chuck Gillen-O'Neel
//Diversified Technical Systems, Inc.
//909 Electric Avenue, Suite 206
//Seal Beach, CA 90740
//Telephone: (562) 493-0158
//Email: chuck.go@dtsweb.com