Also from the MWCI rules, (IRCWCC has similar rules here as well): H. 7. Classes 4,5,6 and 7 may have sidemounted cannons (any cannon which is angled more than 15 degrees from the longitudinal centerline of the model). Warships in these classes are allowed sidemounts as follows: a) Ships under 720': These ships may carry a maximum of two sidemount cannons with a maximum of one firing cannon covering any specific side. On these ships, one specific fixed quadrant shall be left unarmed at all times. The definition of quadrants are: forward and stern quadrants are 30 degree segments arranged 15 degrees either side of the ship's longitudinal centerline; side quadrants are those extending from the end of the bow quadrant to the beginning of the stern quadrant on either side. b) Ships over 720': These ships may carry a maximum of three sidemount cannons with a maximum of two firing cannons covering a specific side. When two cannons are firing into the same quadrant, they must be in separate turrets. All quadrants may be covered. c) Yamato, Iowa, Richelieu, Vanguard, and Rodney classes: These ships may carry a maximum of four sidemount cannons with a maximum of two firing cannons covering any specific side. When two cannons are firing into the same quadrant, they may be mounted in a single turret. All quadrants may be covered. d) Rotating turrets (turrets that traverse from one quadrant to another) are allowed on classes 4-7 provided that they do not violate the above restrictions. e) Pivoting turrets (turrets that traverse within one quadrant, and do not leave that quadrant) are allowed. f) Side mounted (broadside) cannons may not be down angled more than 20 degrees measured from the horizon So that pretty much limits the usefulness of a system like this on the small gun end of the hobby. Rotating and pivoting as well as elevating cannons have all been done, technical challeges of a good system aside without automatic ranging and targeting it still comes down to how good a captian is at using a cannon with an adjustable aimpoint. The most effective ones ive seen only have one or two setting so your sterns could hit say 10 feet back or flick the switch and now they hit 2 feet back. I think djrainer has a nice system like that in the back of one of his boats. Or another simple system that rotates a sidemount from one side to the other. It would be pretty neat on a big gun ship to have all the turrets rotate and hit one point, pretty nasty to be on the recieving end.
Thanks, both Specialist & Snipe Hunter, for posting that info. As for "automatic" tracking & ranging: I can see where there might be some room for interpretation of just what "automatic" means. Mine would involve the use of sensors other than the captain's eyeballs to determine range and/or bearing from ship to target (which we haven't discussed (yet)), directly coupled to the system used to aim (rotate & elevate) guns. If you break that coupling, between target position determination & aiming of guns, then the term "automatic" would not apply - IMO, at least. This should allow an "indicator" to the captain, which he could in turn enter into his aiming system somehow. Something like the British "matching pointers" system, maybe? I certainly agree that, where most (if not all) guns are fixed & of a common caliber, the benefits are limited, & might not be worth the trouble at all. Where I see the most benefit is on ships where most, if not all, turrets rotate & elevate & fire mixed calibers with various rate-of-fire restrictions. Also, in larger scales, where it's possible to arm more guns due to having more space & displacement available, it could actually be practical to arm everything if somebody wanted to. That's basically how most Big Gun ships work today. The only thing is, the captain has to exercise individual control over each turret to aim them at that point, but that's the general objective. It can be a real challenge to get a number of guns aligned, quickly, even with the ship sitting on the bench - never mind while maneuvering in combat. I see it as a potential major convenience, to let the captain focus on the target & the action more, & less having to fuss with details of aiming individual mounts. I don't really see it as any sort of "overwhelming advantage" to be gained over other captains, although there's certainly plenty to be said for convenience. Part of why I'm interested in collaborating is that I don't want to be the only one with such a system, & if we can get the development split up among several people, there's a better chance that we can develop something that all can use. I guess that leads to another couple of high-level objectives to consider: - The system should be adaptable to any ship, regardless of armament configuration, & not need any special knowledge or equipment to set it up for any ship (i.e. you shouldn't need to be a programmer or even need to modify the source code at all). - The system shouldn't cost much more than a good, conventional R/C system (subject to further definition, but I'd think somewhere in the lower $hundreds, not $thousands). JM
I'd like to use the following submitted requirements to illustrate how we might collaborate. Here we have 1 guy that wants buttons, & another that wants a knob, to indicate direction (bearing) to target. 1.B. really ought to be broken up into 2 requirements: 1 to indicate the TARGET's bearing with a knob, & another to indicate the (a?) TURRET's direction of aim. Those might seem like conflicting requirements, but that doesn't necessarily have to be the case. If the entire system is built as a collection of modules, then a variety of "target input" modules could be built to satisfy different needs. As long as there's a consistent interface defined for the "target input" module to provide data input to the "target definition" module (that takes inputs & develops a firing solution), then anybody can pretty much build anything that they want for target inputting. For example: - If somebody wants to use buttons, they can use buttons. - If somebody wants to use a 360-degree knob, they can use a 360-degree knob. - If somebody wants to use a 270-degree knob, they can use a 270-degree knob. - If somebody wants to use a Palm-style touch-pad, they can use a touch-pad. - Even if somebody wants to use a PC-based display of realtime sonar/laser/IR plot data, as long as they can put their target data into the format defined for the interface, more power to 'em! Basically, what it comes down to is this: Your "target input" module sends whatever data (i.e. range & bearing as absolute minimums) to the "target definition" module. How you (as the designer of a particular "target input" module) obtain that information is entirely up to you, & really irrelevant to the rest of the system. Decisions to be made: - Exact data to be sent (presume range & bearing at least, but maybe other, such as "shoot" commands, etc.) - How to represent that data (i.e. numeric range, what values represent what bearings) - How to transmit (parallel, serial synchronous, serial asynchronous, etc.) - Timing, speed, framing, error checking, etc. - Size, shape, weight, mouting methods - Power (voltage as well as current) - Connector(s) There are plenty of other ways to break down the system, & this is just 1 example. Another might be several different ways to physically control a turret. As long as a method fits within the architectural framework of the system, then it should work. Assuming, of course, that the architecture is well enough defined to cover everything that it has to. So, once we have all the requirements defined (do we have that yet?), we can look into the details of how each can be accomplished. As it becomes clear what modules are going to be needed, people can step forward to start designing & building them. Instead of it being an overwhelming task for 1 person to define, design, & build everything, it can be a much more reasonable & realistic job for a number of people, working together. When enough modules have been build, we'll all have ourselves a fire control system that everybody can use. Are we all still on board, here (at least in general terms)? JM
I'm still in! At least I think so. From what I understand, you don't care what human interface is used, so long as it provides the same data to the fire control system (ie range and bearing). It could be a touch-screen radar display, a gimbal setup, or even few simple buttons, as long as it provides the necessary data in a useable format. Following that thought, it would make sense that it should be able to work with a variety of cannons, as long as those cannons all operate off the same data inputs. The fire control system would receive a standard format for target information from the human interface (range and bearing) and output a standard format to all the different cannons, telling each (no matter what design) the direction and depression that it should aim at. By the way, would it be possible to get the guy who runs BDE in on this venture? I wouldn't expect him to help quite so much on the research/development/prototype stages, but he does already offer cannons that can be positionally controlled from a standard servo. A fire-control system would be a great addition to his product line.
That's my thinking. Maximum flexibility, as far as what anybody wants to use as input. Modular design keeps individual subsystems from getting overloaded. "Fire control engine" takes inputs, does calcs, lookups, etc., sends aiming/firing orders to ship/guns. Again, that matches my thinking. I'd expand to include fixed guns/torpedoes, too. I've got no problem with whomever may want to join in. This is a public forum, after all. I haven't issued any specific invitations, only general. It might not be a bad idea to get somebody involved who's already into production of combat equipment. Maybe if we can get the design hammered out, BDE's (or whatever supplier's) contribution might be to get them produced in quantities? With any luck, we might get ours free for our effort! JM
On the sub-topic of using a modular, distributed architecture vs. monolithic: I would recommend to anybody who is designing a fire control system, whether they are collaborating with others or not, to resist the temptation of trying to make a single chip do "everything". A microcontroller (uC) is not a mini-PC on a chip. Trying to make a single chip be the entire system is just asking for trouble, IMO. I know there's a tendency to want to get something simple working, then add to it in increments. Things may be working fine until you add some feature, then what had been working suddenly won't work anymore. The way to add incremental feature is to define a distributed architecture where individual features - and the controller(s) that support them - can be added without having a big effect on the main system. As a general rule of thumb, I recommend that you only ask 1 controller to do 1 major task - once you've got the major tasks defined, that is. Of course, there will be secondary tasks such as communication between controllers, & small odd jobs that need to fit somewhere, but you should be careful about trying to do too much all at once. Some of the resources that you'll need to careful about over-extending are: - Instruction cycles. It's pretty easy to eat up too many cycles, which basically means time, but it's not exactly the same thing. Since cycles * clock speed = time, it would seem that a faster clock would solve all timing problems. That won't always be the case, though. Sometimes, speeding up the clock just shortens the time for a problem to come around again. Using a compiled or interpreted programming language can make it harder to keep track of cycle usage. IMO, a good compiler for uC use should be able to tell you how many cycles a given directive will take to execute (most time a range, min. to max., depending on data). - Code space. Trying to do too much at once, especially, can get into trouble here. Any controller is going to have a limited space that you can put code into. Generally, the things are designed with the expectation that they'll be used as I recommended - 1 major task per chip. On top of that, if you use an interpreted language, some of the space that would otherwise be available will get used up by the interpreter. - I/O pins (as well as other chip functions). It's pretty easy to assume that, if you want to add more inputs or outputs, just go to a chip with more pins. While that works up to a point, it's important to note that certain on-chip resources may be limited & can't always be extended to every pin. For example, a particular controller may have 30 general I/O pins but only 4 Analog-Digital Converters (ADCs). If you need 6 ADCs, what can you do? There might not even be an otherwise-equivalent chip with 6 ADCs. You might be able to play some games, allocating your limited ADCs on the fly to different pins as needed, but this is going to eat up some code space & instruction cycles, causing potential problems in those areas. Control 30 servos from a single chip? Well, assuming you'd want to do that in the 1st place... Add up the time: 2 msec for the longest pulse, plus inter-pulse time, plus sync pulse. You've got 20 msec to get it all done, plus all the other "stuff" in between. Very few uCs multi-task. That means that there can only be 1 thing going on at once. You can't go off & do some calculation while you're waiting for a pulse to finish - you've got to wait. All of these problem areas can be helped by using a modular architecture. Not necessarily eliminated, but you've got a better chance of making it all work right than if you try to cram everything but the kitchen sink into a single uC. Also, by making the system modular, you can build in the option to make certain features active or not using the same hardware & software. For example, you might want to include a status display of LEDs that show whether each gun is ready, reloading, on- or off-target, or low on ammo. Keeping track of all those possible displays would be a burden on a controller whose main job is to plot firing solutions. However, a 2nd controller that's dedicated to the task could do it without much trouble. More importantly, it can do it without impacting the ability of the "main" controller to do ITs job. Communication between controllers isn't a lot of trouble. It gets done all the time. At the very least, you're going to have to communicate with a radio transmitter & receiver, anyway, so it's not like you can avoid it even if you wanted to for some reason. uCs are cheap, small, & making them work together is pretty easy. Communication between devices is a topic worthy of its own post, which will follow soon. JM
RE: Communication between uCs & other devices Among the design decisions that need to be made are how to communicate between devices. This includes uC to uC, as well as uC to certain other components that may be used. There are 3 basic methods to consider, each with their own plusses & minuses. Sometimes, the method is chosen for you, such as when a particular device can only use 1 method. Parallel In parallel communication, individual bits are transmitted over their own dedicated signal lead (wire, board trace, etc.). This is the method used in PCs to communicate on their main bus, access disk drives, etc. I'm sure everyone has seen the parallel traces on a PC motherboard that lead to connectors. Also, ribbon cables. While this provides the greatest transfer speed of the methods, it will eat a lot of pins on whatever devices are involved. As an example of how parallel communication might be used, imagine that you have a 8-bit "word" of data in a register of 1 uC, and you want to get it into a register of another uC: - Move the contents of the source register into the register associated with 8 I/O pins. Obviously, 8 pins need to be available, & need to be configured for output. Many uCs "group" some of their general pins into a port that is named. This can make things a lot easier for you, since you can move date to & from the named port, instead of each bit. At this point, the data will be present on the individual pins of the source uC. You will have used 8 pins, but very few instruction cycles (maybe as few as 1). - You'll need Some way to tell the destination uC or other device that it needs to "read" the data. The 8 pins will need to be connected to 8 pins on the destination, plus you'll need another to "enable" the receiver. The sender would set this pin to the opposite of its "idle" state, then return it to idle. The receiver, when it "sees" this state change, needs to enable its register that is associated with the 8 data bits, configured as input. Move the contents of the I/O register to some other register. This has used 9 pins on each uC, but only a small number of instruction cycles in each, so it's pretty fast start-to-finish. Options, as more devices may be connected to the same data bus: Individual "enable/select" pins on the various devices all will require their own pin on the "master" uC. Obviously, the more "slaves" on the bus, the more pins will be required on the "master" to make this method work. A better option might be to use an addressing scheme like what your PC's main bus uses. In this method, each device has a unique address, must "know" what it's address is, & the master puts the address of the intended device onto the address bus. The same bus can be used for both address & data, if you add an "address/data" signal bit. Alternatively, separate address & data buses could be used, but that uses even more pins. The master puts the address of a device onto the bus & asserts the "read" signal. All devices then read the address from the bus & compare it to their own. If it doesn't match, they ignore what comes next, otherwise they read data from the bus when the "A/D" bit changes back to "data". Addition of a "read/write" (R/W) bit can make this type of bus bidirectional - "slaves" can send data back to the "master". You've got to set up some sort of arbitration scheme, or you're likely to have multiple "slaves" all trying to gain control of the bus at once, which won't work out very well. It could be as simple as having all the slaves wait until they're "polled" by the master. Asynchronous Serial Most of us are generally familiar with this method. It's what our PCs' serial ports use to communicate with modems, etc. This is termed "asychronous" because each end of the channel needs to keep its own timing - there is no common timing signal (see Synchronous Serial for that). You've got to establish a protocol of speed, character length, framing, parity, etc. on both sides. It's pretty tough to set up an asychronous serial bus of multiple devices. On the plus side, though, you can get it done with as few as 2 leads if you don't need to send in both directions. Bits of data are shifted one-at-a-time onto a single lead, which is the "serial" part. Each bit-shift is going to take an instruction cycle, plus whatever timing & looping code needed, so this method is heavier on the cycle usage than a parallel bus. Synchronous Serial This method is actually pretty common. Like asychronous, data is sent bit-by-bit over a single lead. The "synchronous" part means that there's a common "clock" for both/all involved devices. Often, the "master" supplies the clock - it doesn't even have to be a regular pulse, it just needs to be set high or low as needed. Typically, every time there's a low-to-high transition on the clock, 1 bit is written to the data lead by the sender & read by the receiver. 2-3 leads are all that's needed for a typical synchronous serial interface. As with asychronous, it can eat up some instruction cycles - even more if one of the uCs has to supply a clock. One of the good aspects of this method is that there are a lot of devices available that use it. I2C is an example of a synchronous serial protocol, but it isn't always necessary to use (or even bother to read) the standard - it's pretty easy to "roll your own" synchronous serial interface. One of the most useful devices that you'll find is called a Shift Register. Shift registers come in different sizes &types, but the ones you'll find most useful are 8-bit serial in/parallel out or parallel in/serial out. Serial in/parallel out allows you to do stuff like manipulate a number of LEDs, switches, etc. without eating up a lot of your uC pins. Using 3 pins (data, clock, & enable), send a byte to the SI/PO shift register using synchronous serial. The shift register will set its 8 parallel output pins depending on the bits in the byte that it received. Parallel in/serial out works just the opposite, & can be used for sampling switches, etc. 8 parallel inputs are set in the shift register. The uC enables the PI/SO shift register, which sends a serial byte that represents the state of each bit. Each type can help conserve uC pins for either input or output & can become some of your best friends when you get familiar with them. Anyway, there's a brief overview of the 3 main methods we'll have available to transfer data between devices in a system. This all goes to the point of not trying to do "everything" in a single chip. It's easy enough to dedicate controllers for different tasks, each doing its thing "in parallel", & giving the master what it needs when it needs it. None of the individual controller need to be heavily tasked, while trying to do it all in a single controller may be more than it can handle. Once we get to laying out details of exactly what tasks are going to be done & where, we'll have to decide which communication method(s) we'll want to use. JM
Back to features. Underlined items updated 03/11/2008. Here's a list of what we've got so far. Most of the submissions are mine, which is probably OK since I believe I've been thinking about it the longest. Don't anybody else be shy about suggesting anything! I've combined several posts'-worth & organized it into levels. I. Primary Goals: A. Simplify User Interface B. Manage Multiple Guns II. Secondary Goals: A. Avoid building something that others won’t want to fight against, or make rules to outlaw B. The system should be adaptable to any ship, regardless of armament configuration, & not need any special knowledge or equipment to set it up for any ship (i.e. you shouldn't need to be a programmer or even need to modify the source code at all). C. The system shouldn't cost much more than a good, conventional R/C system (subject to further definition, but I'd think somewhere in the lower $hundreds, not $thousands). D. Fire control & ship control need to fit into a single hand-held unit for the operator. Size, weight, power, etc. TBD. III, Specific Features: A. Indicate the range and bearing to up to 4 target]s. A.1. Allocate a number of "aiming points" to calculate for eg : 0,15,30,60,90 degrees in each quadrant. If you then placed buttons at these locations around your controller, hitting the button for, say, port 30 degrees would cause all turrets that could bear to elevate to parallel to the water surface, traverse to the bearing required to hit in the target box for that location and depress barrels the required amount. A.2. Have a 360-degree dial to indicate direction to target. A.3. Have a 270-degree knob to show what direction the front gun is facing, then make the back gun turn parallel. A.4. Simulate "velocity" control over the front gun, and have the aft cannon stay parallel (i.e. drive forward gun with a hacked servo or ESC/motor). A.5. Feedback to user regarding status of weapons (on target, ready, reloading, etc.) either actual via telemetry from ship or assumed based on actions, events, etc. B. Up to 16 positionally controlled guns and/or other weapons (including but not limited to fixed guns, torpedoes, searchlights, sound modules, etc.) automatically aim at indicated points (targets) and fire under operator control. B.1. Get both front guns and aft guns pointing in the same direction. B.2. Convergence, depression, and ranging can be added later (rather get a perfectly working sample without convergence and ranging than a glitchy specimen with them). C. Upon pressing the trigger, all guns that are on-target fire, all others do not. C.1. Restrict each cannon to its proper rate of fire. Pull the trigger before it's allowed to fire, and nothing happens. C.2. Measure rate of fire and inform the skipper when it's safe to fire, but do not physically limit firing. C.3. Automatic stabilization of those guns that are adjustable in elevation/depression to compensate for sea state and/or vessel trim. C.4. Disallow firing of guns where their (presumed/calculated) elevation exceeds a defined safety margin. D. Miscellaneous Features D.1. Disallow firing until some specific, unambiguous action is taken by the user to go "off safe". D.2. For all movable weapons, define a "home" position that the weapon may be aimed to as a default under conditions such as initial power-up, reset, or prior to going off safe. Anything else to add? In a perfect world, where anything is possible & everything works right all the time, what would you like to do with regard to targeting/fire control? JM
Allow me to clarify what "velocity" control is. Velocity control is basically the current standard for turret control, using standard hobby radios. Move the stick left, and the turrets rotate towards port. Move the stick right, and the turrets rotate towards starboard. Move the stick farther right, and the turrets rotate faster. Release the stick and let it return to center, and the turrets stop moving. This system is fairly simple to implement in battleships, but only permits firing a full broadside towards targets directly port or starboard and no other angles in between. With a gun director system using "velocity" control, you would have the aforementioned velocity control over the front cannons only. Any other cannons, including stern and wing turrets, would adjust track with the front cannons. Most ships have a pretty good range of motion for their forward cannons, Usually 270 degrees or more. It's also possible to draw a line from the center of the ship, that all turrets attempt to match themselves to, which would provide full 360 degree targeting. The reason why I suggested this control style is because it does not require transmitter modifications of any sort. Hopefully this will make the director more appealing to people in my club, who have little to no interest in transmitter modifications or building whole new radios.
OK, I get it. That's using a hacked servo (for continuous rotation) or reversing ESC/motor to drive the turrets. I've got ships that work that way myself. I've never heard it called that before. Regarding those who have no interest in modifying or building radios: How do you think they might take to the idea of buying a system already built, from a supplier (such as BDE, etc.), if the cost is at least in the ballpark of a "traditional" 6-7 channel R/C set? JM
I want to comment a little on some of the required features: A.4. is going to be a challenge to implement together with the others. The reason is that in all the others (A.1. - A.3.) the data indicates a specific bearing (position within the range of possible positions), while A.4. indicates a movement or rate & direction of change. To be understandable by the "core" module, the inputs need to be speaking a common language. If the input is an angle, whether that angle is produced by switches, knob, or something else, it still means the same thing to the core. If the meaning of the input is something different, then the core will need to know. This might mean having 2 different inputs, 1 for angle & another for movement. Or, it could mean including a switch, jumper, etc. that tells the core what type of data is being input. From a user's perspective, I don't care too much for A.4. as an input. That said, I have this exact method implemented in at least 3 of my own ships. The problem I have with this method is that it's pretty tough sometimes to tell where those barrels are pointed. A gray turret, on a gray ship, 40-50 feet away, at a bad angle, on a gray day - I've got pretty decent distant vision, & I have trouble telling where it's aimed a lot of times. I know some people have painted the backs of their turrets, to help them tell where they're aimed. As challenging as it can be for a human captain to tell where a turret is aimed, the controller is going to have the same issue. It will need some definite position feedback of the position of the "master" turret, so that it knows where to aim the other(s). It can't get this information from the captain's input at all; it will have to get it directly from the "master" turret. Also, there's no way to get this information back to the transmitter, so certain other features that depend on that data being in the captain's hand won't be possible. This includes things like indicators of which guns are/aren't on target, which are in "reload", etc. This is because, at the transmitter, you really won't know where the guns actually are, only that you're trying to move them 1 way or the other. I'm not trying to say not to do this, just pointing out some considerations. Another important consideration, especially for a system that's intended to be used by people who aren't programmers or engineers, is configuration. Every ship is going to be different, & there's going to need to be an easy way for the average captain to set it up to work with the ship he has. The comment was made that the A.4. option is for those who can't be expected to modify a R/C transmitter's inputs. It's not reasonable to expect that person to make code changes or select electronic components, either. If they could do that, they should have no problem modifying their R/C equipment. They'll need a simple way to do things like set the range of motion of turrets & match that range to the input. Give the matter some thought. JM
Perhaps this might work. All turrets are individually rotated and are set to roughly converge by mixing. "b" turret is set as the "master", with a laser pointer attached. "a" and "x" turrets are slaved to it via a "seeker eye" system that can track the master's laser dot. When in "Auto" mode each cannon would be enabled to fire only when it has a lock on the master cannon's laser. Auto mode would need to be switchable, on/off. I dont know what sort of onboard processing gear would be required, or if seperate laser frequencies would be required...not my field. Just a thought.
Is this about how to make feature A.4. work or a new requirement? With all the possible sub-topics that could be going on here, I think it's a really good idea to quote something to make it clear what the comment is about. JM
Another proposed feature requirement: Fire control & ship control need to fit into a single hand-held unit for the operator. Size, weight, power, etc. TBD. Just to be clear that what we're talking about ends up being a single "box" for complete ship control & not 2 (or more) separate ones. I don't think a completely separate box for fire control would be user-friendly at all. Something that attaches to an existing transmitter should be OK. JM
My $.02 Maybe since with JohnmCA72's idea of an on/of switch, with the "turn off" message send a message for the guns to rotate to a normal setup. For example guns rotate so each turret covers a side and the rear turret points aft. This could make it so the entire setup, whether the fire control is turned on or not, can fit on one remote.
Yes, I proposed this idea as (maybe) a way to make A.4. work. Thought it could be set up from a knob on the radio, which would be set to turn at the same rate as it moved turret "B". When the system is active,it would take control of the rotation and "holdfire" of "A" and "C" turrets, with it inactive, the knob would rotate all three cannon, as normal.
Let's see if we can smoke out as many feature requirements, wishes, etc. as possible. Imagine the best possible world, where everything is possible, works right all the time, & you don't have to know or care how it works. What would you want to be able to do? Technology can solve any problem; what problem(s) would you like to have solved? The "hows" are interesting, but I'd really like to make sure we have all the "whats" down on a list. That'll tell us what "hows" need to get figured out. I worked for about 14 years for a company called VMX, a "pioneer" in voice mail. VMX did some dumb things, but they also did some pretty good ones. One of the best things they did was, when they built the 1st commercial voice mail system for 3M in St. Paul, they built it with 64 ports (a port = 1 phone line; 1 caller connected to the system). Having an architecture that could run 64 ports, it was pretty easy to configure systems for 32 ports, 48, 16, 8, or whatever. Other companies built smaller systems first, in the 4-16 port range. A lot of them had a alot of trouble, scaling their smaller systems up to the size that VMX had been building since day 1. I consider that a very valuable lesson, that it's a lot easier to scale a system down than to scale it up. You can always turn off ports, features, or whatever. But you can't always add, once your design has been set, without running into built-in limitations that you put there yourself. Applying that lesson to the fire control project: Make sure that it's designed so that it can handle everything that anybody is ever even remotely likely to want it to do, even if all those features are never actually turned on all at once. JM
Some more unsolicited general advice for those participating in this project (or not): Spend some time getting to know your microcontrollers. A system is going to consist of many simple parts, just like a mechanical system is built out of the 3 simple machines: Lever, wheel-and-axle, inclined plane. Learn how to make the basic features work, find out what happens when they DON'T work, & learn all the variations on using them. You're going to need basic functions such as: - "Read" whether a switch is on or off. - Turn things on or off (lighting LEDs simulates this nicely). - "Read" the amount of resistance on a pin. - Communicate with some other external device. - Operate servos. - Decode radio receivers' servo pulses. Most (all that I know of, anyway) uCs have tutorials available. Use them. Build up the most basic, simple functions that you can. Then, start integrating multiple functions. Example; You can turn on an LED, & you can read a switch. Integrate the 2, so that when you press the switch, the LED turns on (or flashes, or whatever). Extend the integration further, with more features & functions adding to the complexity. See how many different ways you can build a servo tester. Before you know it, we'll all feel comfortable enough with our uCs to take on building parts of a fire control system that, by then hopefully will be fully defined. JM
More on features. We should consider other possible uses beyond our own personal interests. One that I can think of off-hand is that non-combat scale model builders might be interested in realistic-looking movements & maybe blowing smoke puffs or activating sound modules. Another possibility that even has potential combat use might be controlling searchlights for night combat. I'm sure there are other ideas, too. Let's hear some more! JM
I've updated the features list on Page 2. Those added are underlined. I added some semi-arbitrary numbers (up to 4 targets & up to 16 weapons). Still OK? I'd like to stress that any/all features are optional for any given implementation. I seriously doubt that anybody will ever put everything in, but we need to account for it all. Example: Added user feedback as a feature. This could take the form of some LEDs, a voice module with earpiece that somebody mentioned, a detailed video display, or whatever else somebody cares to dream up. All I'd like to do is define what information will be available & how it will be packaged. What anybody chooses to do with it (including nothing at all) is up to them. Personally, I'd like an array of bi-color LEDs - not to watch constantly, but I think an occasional brief look-down could help, just to see if I've got a bunch of red, green, or whatever. I can tell you this: Having some indicator of what's going on other than just a ship with rotating/firing guns can be a big help in debugging. Even if I never use it in combat, just having a green LED telling me that something THINKS a gun is on target, even if the gun itself maybe isn't, could tell me a lot about what the system is/isn't doing & where to look for trouble. JM
