Contributing an article

January 01, 2000

January 01, 2000

Content guidelines

For technical articles, we look for articles that address some common or emerging design problem and offer alternatives, tradeoffs and solutions. We tend to stay away from product-focused articles for a very pragmatic reason: Embedded's readers are quite savvy and appreciate a rounded problem/solution piece but typically lose interest quickly in something that's so specific to the authoring company's product line that there's little general benefit to a typical embedded systems engineer. Of course, specific products can be included as examples in discussing solutions but as a "for instance."

Our readers like to see code fragments - even pseudo-code. The presence of code in the article is also a positive indicator for us - or put another way: An embedded systems design/development article that doesn't have an opportunity to present some code or other design detail might be too conceptual to use as a technical article. (That said, it might be a fine candidate as a guest blog and we'd of course be happy to consider it as such.)

Figures and tables should positively contribute to the author's explanation (and the reader's understanding) of the topic. For an article on an MCU-based wireless sensor, it's not helpful to see a figure that only includes three blocks (for sensor, MCU, and wireless function or component); better would be one that a unique aspect of the design such as circuits for excitation, temperature compensation, and linearization (for example).

Technical articles tend to run ~2000 words but if the topic needs less, we'd rather see a focused piece than something padded to stretch. If the topic needs more, that's fine. We often split particularly long technical articles into multipart series.

Guest blogs tend to run ~800-1200 words or so. In contrast to technical articles, our blog posts tend to be much more opinionated naturally, but we still need to stay away from product-specific opinions!

Any contributed article must of course not have been published elsewhere.

Since we're not under the yoke of a print schedule, we can use material when you're ready to send it. An accepted piece would typically run relatively quickly after all the logistical requirements have been satisfied (see below). 

We recommend that you send us -- Clive "Max" Maxfield ( or Steve Evanczuk ( -- an abstract early in the process to make sure we're all thinking the same thing. 

Submission logistics:

  • Doc file: We prefer receiving a Word doc but rtf is fine. If the article includes external links, go ahead and use Word's embedded link feature or place the link inline within square brackets immediately following the link anchor text. Please do not use Word advanced formatting features such as auto-numbering, WordArt, Equation, or the like. These features do not survive import into our publishing tools (and worse, they're simply deleted so it's difficult to tell that they've been dropped). 
  • Figures and captions: We suggest including one for every 500-800 words or so if appropriate. In the copy, please include accompanying captions (one short sentence) at the desired location of the image in the article. A corresponding reference to the figure or table needs to appear in the copy itself. For the caption, please be sure to include the source of the image,  e.g.: Figure 1. Engineers really like this figure. (Source: XYZ Corp.)  
  • Graphics files: Please send figures/tables in separate files (jpg or png preferred) - please embed figures/thumbnails in the Word file to show position, but please also send the graphics in separate files anyway. Graphics extracted from a Word file are typically suboptimal. 
  • registration. Please be sure authors each register on (near the "search box" in the upper right of the home page), provide a bio (and picture if desired), and then send the editor the "screen name" and associated email address. The first and last name provided in the profile are used in the byline, which links to this profile so providing a bio is important. The email address will not be published: The system uses it to send notification of reader comments to the author(s). 
  • Contributor's Agreement. To ensure usage rights for publication, AspenCore (Embedded's publisher) requires authors to sign a contributor's agreement. Your editor will send this agreement to you on article acceptance. Each author will need to complete the top of page 1 as well as the signature page, sign, and return to the editor as a pdf.

If you have any further questions, please don't hesitate to ask your editor.

Loading comments...