Deliver Insanely Great Service with Saleae. Join the Team!

Apply Here

Work directly with founders Joe & Mark to develop and deliver five-star customer service to the heroes who depend on our Logic product.

Saleae is seeking to reinvent electrical engineering test equipment, and we need four rock solid competencies to do it.  One of these four is Insanely Great Service.

Insanely Great Service means very low latency response, crystal clear and accurate technical answers, pain-minimized problem resolutions, and genuine warmth and positivity.  It also means relentless continuous improvement of the service platform though lean-startup-style experimentation, instrumentation & analytics, and high-cadence A/B testing of improvements.

The role you are applying for has two components, each expected to take about 50% of your time: (1) deliver Insanely Great Service directly to customers via phone, web-chat, email, Twitter, Facebook, etc., and (2) run a sprint driven process of continuous improvement involving instrumentation & analytics, maintaining a prioritized backlog of testable improvement ideas, and building out and A/B testing the most promising ideas.

Responsibilities

  • Hands-on delivery of Insanely Great Service (~3-4 hours/day)
    • Quickly respond to incoming customer communications via phone, website chat, email, Twitter, Facebook, and the community forum.
    • Provide extremely clear, technically accurate, and appropriate answers to customer questions.
    • Provide straightforward and pain free solutions to all customer problems with Saleae products.
    • Ensure customers receive warm, empathetic, and positive communications consistently.
  • Drive continuous improvement in the support platform (remaining time)
    • Instrument and monitor key support metrics
    • Use analytics to continuously improve our understanding of the customer support funnel
    • Maintain a prioritized backlog of testable improvement ideas
    • Each sprint, run a complete continuous improvement loop:
      • Implement new/improved functionality or content
      • Deploy changes as A/B tests
      • Analyze results and generate new ideas, insights, questions, and/or tests.
    • Develop and maintain any necessary standards, service-level commitments, controls, and/or procedures related to customer service/solutions.
  • Advocate for the customer within the organization; fight for improvements in product and marketing based on your evolving insight into the customer.

Qualifications

  • Very high interpersonal skills; highly empathetic, warm, and positive.
  • Extreme clarity of communication, written and verbal.
  • Broad electrical engineering and embedded system knowledge & experience, including:
    • Firmware & embedded system development
    • Analog electronics fundamentals
    • Board-level design & debug
  • Passion for engineering as evidenced by past and/or current side projects.
  • Passion for service excellence, including self-service.
  • Ideal: Compelling technical writer
  • Ideal: Intuition and experience around user experience (UX) design, in particular software/web – UX wireframes; sketches.
  • Ideal: Practical front-end web development (html/css/js) ability and recent experience.

Quick Experience Survey

Please fill out this multiple-choice experience survey before submitting your application.

Apply Here

Why Saleae Exists

One of my tasks over the past quarter has been to figure out precisely why Saleae exists and precisely what our mission is for the next few years. I’m not going to address that latter question now, but I thought I’d take a moment to share what I think about why Saleae needs to exist.

What an individual can accomplish within the scope of a life is profoundly and inextricably bound up with the tools at their disposal.

Think about the process and tools you use to create electrical engineering designs and circuit boards. Now imagine that the process and the tools you used were 10x worse—or 10x times better—it would make a huge difference, right? And that’s multiplied by all the other electrical engineers, hundreds of thousands of men and women. Those tools and those processes—if they are 10% better, or 100% better, or 1,000% better—they make an absolutely massive difference in our world. We’re talking Tamagotchi pets vs. city on Mars kind of differences here. Orders of magnitude.

And yet, the processes and tools for electrical engineering don’t get love. They’re not sexy and cool, and the market is zero-sum-competitive and price driven and stodgy. On the one hand, you have cheap, derivative crap and zero innovation, and on the other hand, you have $20,000+ beige machines, and it’s like, which beige machine would you like, the one from soulless corporation A, or soulless corporation B?

But it doesn’t need to be this way. The tools of electrical engineering can and should be badass. Tony Stark badass. They need to be 10x better. Ten times more valuable. And what, precisely, is the value?  It’s time. It’s all we have in this world, as Andy Grove might say, and these goddamn beige machines are wasting it.

So now, we’ve gotten somewhere to start from. The reasons Saleae needs to exist are that 1) our EE tools need to be 10x better, so we can build the kind of exciting future we all want; and 2) our tools need to be badass, so we can get fired up about what we do every day.

I’m not saying we’re going to succeed, or that what we’ve done to date has been particularly groundbreaking.

But we’re going to try.

2016 Q1 Update

Hi Everyone,

The Saleae team and I had a great first quarter and are excited about what 2016 will bring. First, a bit of backstory:

My questionable (in my opinion) execution of the last product launch shook my confidence for some time—and it’s taken a while to figure out exactly what I want to do with Saleae and how I can become an effective executive for the sort of company we want to build.  The real question was if I could commit myself—and get excited about—the new role that I needed to play, one where I remove myself from day-to-day engineering and operations and become the leader we need. So it’s been an enormous relief to have found that I’m really liking the new role—and I feel like I can really dig in and apply my intelligence on this entirely new class of problem. Building an organization in many ways is an engineering problem. It’s complicated and messy and difficult, but it is a problem that can be defined and quantified and largely solved, and I think I can be quite good at it in time.

Q1 Saleae Shirt BackWithin the team, we’re calling this transition Saleae 2.0. Basically, the idea is to think of it as if we were starting over—like if we were starting a brand new company, how would we do things? There is this weight of past foibles that sort of drags you back and gives you reason to doubt you can change—and starting fresh, at a new company, I mean, can help that problem. So this idea of Saleae 2.0 helps make it work.

For the team, Saleae 2.0 started Jan. 1, 2016. That’s when we really started operating in a new way. And so Q1 was really a critical test to see if we could make that work or not. Week by week, we run sprints, and the idea is to work to accomplish the goals set up for the quarter—called OKRs (objectives and key results, something Intel came up with, I believe). The OKRs are specific and measureable and assigned to individuals—such that you can really measure your progress and keep everyone accountable. And the idea is that the OKRs are a little bit crazy—a little bit out of reach, such that if you achieve 70% of what you set out to achieve, you’re doing quite well.

I’m happy to report that we now have a crystal-clear, super exciting vision for what we want Saleae to become. And you may be glad to know it does in fact include taking the logic analyzer to awesome new heights and fully addressing the feature requests you’ve provided over the years. The trouble has been to figure out a way to do that in a way that also will dramatically and sustainably grow the business (the logic analyzer market being what it is). I think we’ve got the business case cracked. It’s not something that I can go into detail on now—we’ll let it sort of unveil itself over time.

Our OKRs for Q1 were largely focused around getting our crap together operationally; but in Q2, things start to get interesting—with cool software shipping and hiring for some key roles.

First of all, we’re getting out of bloody beta. We’ll be shipping a new release every two weeks. And by the end of Q2, we’ll be delivering some new and interesting value, although Mark has asked me not to say anything specific about it for the time being.

Q1 Saleae Shirt Front On the hiring front, we’re actively looking for a person who can deliver awesome technical customer support with super low latency—someone who will treat our customers with care and can directly help and relate to them because of their loads of experience in electrical engineering and embedded systems. We’re also going to hire a flat-out incredible software person—someone with broad and deep experience with software product development, continuous integration, leading a team, and designing software architectures across numerous bleeding-edge technologies like C++14, .NET Core & Native, Cuda/OpenCL, and NodeJS/Angular/React. And lastly, we’ll be hiring an exceptional individual to head up a new growth team. Someone who’s a rare combination of designer, copywriter, front-end developer, and marketer.

So there you have it. It’s a bit of a brave new world for us, and it won’t be easy. We’re going to work like hell to make it work. Wish us luck.

 

Logic 8 Stock Status & EOL Part Managment

Update: as of January 22nd, we are now in stock of Logic 8 (hooray!) and we are projected to remain so, with at most perhaps a 1-week gap in about 3-4 weeks.

***

Sadly, as of today (December 29th) we are now out of Logic 8, completely.   I apologize — I know this is a terrible inconvenience for many of you, who rely on our product to get important stuff done every day.

Alternate sources, my lead time estimate, and the backstory are below.

Alternate Sources

As of today, the following US distributors still have some stock of Logic 8:

Sadly, the distributors above are now sold out as well.

Lead Time

I expect to have new Logic 8 inventory arrive next week, and should be shipping out to customers by Thursday the 28th at the latest.  I do expect we may run out of stock again briefly in mid-February.

The lead time is not likely to be less than a full 30 days, and it may be longer.  The best case to expect would be Feb 1st, and it could be as late as April 1, although I expect this is now unlikely.  We’re going to try and beat the Feb 1st date, but there is no guarantee of success on this.

Today is December 29th January 7th 19th. I’ll update the above lead time and distributor list at least every week.

What happened

A single-source, critical component for Logic 8, Pro 8, and Pro 16 was canceled by Analog Devices earlier this year.  The required PCB redesign for this part is non-trivial, and requires firmware, software, and HDL changes — so we decided to push it out a year so we could focus on more pressing matters.   We ordered two years worth of the part.

The last date to make the life time buy was early November, and our manufacturing partner OSE placed our final order months before this date, with an expected delivery this month. A few weeks ago it came to light that ADI was going to slip the delivery to the end of February 2016;  OSE and their distribution partner have been battling hard with ADI to bring in the date , but so far we don’t have a definitive improvement in that delivery date.

We have extra of this part, but we have to carefully ration them for Logic Pro 8 and Logic Pro 16, because the financial consequences of not doing so would be radically more severe.  Logic 8 as you may guess is quite popular, but due to its lower relative price, Pro 8 and Pro 16 contribute a far larger percentage of total contribution margin.  Even then we are going to be dangerously close to running out of those models as well.

The good news is that OSE is being super aggressive at solving this problem on our behalf, having managed to escalate the issue all the way to ADI’s VP-level, which is looking promising at the moment.  Having the right partner fight for you makes a huge difference.  What’s especially interesting is that 75% of OSE’s business is IC package & test – so they know exactly how long various steps in semiconductor processes should take if they are actually being escalated, vs not escalated — and therefore they know if they are getting a load of BS or not with respect to the lead time.

Of course in addition to OSE’s efforts we’ve been investigating exactly what it would take to redesign the board and software/firmware/HDL.  It’s doable but as you might imagine not a super fast fix to the issue due to the multiple prototype builds required.  We also ordered two years worth of the EOL’d part, which puts us in the awkward (although certainly manageable) position of supporting multiple versions of the same product at the same time.

Most recently (and bizarrely) OSE managed to locate a 100% pin compatible replacement part from a small and relatively unknown semiconductor manufacturer here in the Bay Area.  The part has a different data sheet, but the numbers on the data sheet are identical – and I have since confirmed with the company that it is – in fact – the identical part.  This is not commodity part by any means, and this is not just a pin compatible clone, but literally the same ASIC design – same IP.  I look forward to learning exactly how the same IP managed to end up being owned and manufactured by two different entities.  No doubt there was some joint development agreement between the two small companies who independently brought the part to market around 2010.  Or who knows, maybe it’s juicier than that.  Semiconductors is a crazy business.  So the good news is that we may well have a short and long term 2nd source for this part, which would be huge.

Current Plan

Note: despite my optimism below please do not expect any Logic 8 from us any earlier than 30 days out.

Progress has been slow due to the holidays, but on Monday Jan 4th OSE will learn if we can in fact order the stock of this alternate (identical) part — i.e. if we can get a reasonable price.  Assuming we can get the stock we will order all of it and immediately run a test PCBA to just double confirm that this is the identical part, followed by production, probably of Logic 8.  

The alternative part still does not have a definite lead time, for some reason the company is dragging their feet.  I remain optimistic as we continue to force the issue.  Pricing initially looks like it could be an issue as well.

Also on monday OSE will have updates from ADI as to if the lead time, given the ADI VP-level involvement, if in fact it can be shorted.  Given the current state of production, OSE believes that the parts could ship in a little over a week if they we’re given appropriate priority.  The wafer/die is already manufactured (TSMC) and on the way to the packaging/test house, the lead time of which completely controls the schedule.

It now looks like we will have parts in hand by February 1st, and OSE is working to accelerate this.  Overall this is good news.

If the above two items look proposing, we can immediately release the additional parts we do have for Logic 8 production, since we would be assured that Logic Pro 8 and Pro 16 would also have enough parts.  Absolute best case scenario we could start shipping Logic 8 backorders on the 18th of January.

I have released the order to build Logic 8 using the EOL parts we still have in stock, based on the improved lead time.  With luck this means we be back in stock of Logic 8 by the last week of January, and perhaps a bit sooner.

Customer Support – backlog & average response time

I’ve been reading (listening to, actually) the book ‘The Phoenix Project’ over the last couple of days.  This is a novel about turning around a dysfunctional IT/DevOps group.  I highly recommend it – it’s in the same format as the much older, now classic ‘The Goal’ which is a novel about turning around a struggling manufacturing plant before its shut down.  Both books are surprising thrilling and inspirational.  

Anyway, while listening this morning I was struck by something about resource allocation — that the average wait time for a resource is proportional to the % time the resource is utilized divided by the % time the resource is idle. Aka U/(1-U).  If a resource is allocated %50 of the time, the average wait time for that resource is 50/50 = ~ 1 unit of time; A resource allocated 95% of the time will have a wait time of 95/5 = 19 units of time.  As the resource approaches its capacity, on average you’ll be waiting longer and longer for it.

Anyway I was thinking about how this applies to customer support.  If we had one person, virtually doing nothing but support (100% utilized), the average wait time would be very large, several days on average most likely.

However, if we had two people, splitting the support equally, the average amount of time a customer would wait for a reply would be many times smaller.  This is despite the fact that the same number of actual support tickets is coming into the system, and the same total time (and therefore the cost) is being spent on those tickets.  Furthermore, it’s not like the additional support resources would actually be idle the rest of the time – as long as support was prioritized, they could do other work the rest of the time.  The only downside is the context switching penalty, which isn’t trivial.  Still, seems like it would be worth it.  Done, right, spreading support work out to a great number of technical staff would have large customer benefits.

The next problem is that the support tickets have high variability in terms of the expertise required of the individual.   This creates constraints in the system, where a particular engineer becomes the choke point for all questions of a given category.  In our case these are also the most time consuming questions, and ones for which training at least superficially seems impossible.

The solution for this is a knowledge base, but now we’re talking about taking those key engineers, and making they write some massive knowledge base instead of getting anything else done.  And also maintaining it all the time. Furthermore, it always takes less time to bang out a ticket reply than to create a new knowledge base article — and I think most firms never build up a good knowledge base for this reason.  This is something we’ve actually thought a lot about, and already have a system in place for.  If you’ve written into support over the past couple of months, you already have an idea of what we’re doing.  It’s very rough and not yet public facing.  A rough but functional public-facing implementation is gong live in our first sprint in January.

 

Saleae Playbook

The 2.0 Logic Analyzers we released last year are pretty good all around I think — however the process by which they got to market was highly problematic.

2015 has been a year of recovery and reflection for me personally; things were very dicey for a long time, not really recovering until midway through this year.  Things are looking very healthy now – financially – which has been an enormous relief, and produced the mindset we can get through anything.  Turns out paying your vendors late is not the end of the world.  For a while after I was a little unsure of my direction, and spent some time learning modern web stuff like Angular so I could execute some exciting marketing efforts, but a couple months back it became clear I was just repeating my previous mistakes – making myself the bottleneck.  The problem with being able and willing to do just about anything is that it’s too tempting just to start doing it.  As they say for hiring people, past behavior is an excellent predictor of future behavior, and now — at 35 — it would be a reasonable bet to say that I’ll never become a great founder/CEO.  Well, I’m not giving up.

Here’s my view:

The CEO’s job is to execute the Company Playbook, as well as conceive, maintain, and champion it.  The Company Playbook spells out the company’s mission, its values, and how it plans and executes.  This playbook may just be in the CEO/Founder’s head, but it’s always there.

Here’s a rough/condensed outline of the new Saleae Playbook:

  1. The company’s overarching mission
  2. The values of the company
  3. The organization’s people – organizational structure, KPIs & accountable individuals, scorecards, processes for hiring (finding, attracting, and assessing), onboarding, evaluations, culture, feedback, dismissal, and communication.
  4. The organization’s partners – selection process, management process, partner scorecards
  5. Planning & Execution – KPIs, Planning & Execution cycle/process, Scrum, resolving contested decisions
  6. Finance – cost control, liquidity policy, capital deployment strategy
  7. Marketing – process
  8. Engineering — best practices for software, product development
  9. Other – security, insurance, corporate stuff.

In the CEO’s head or not, the degree to which playbook is “correct” — coupled with the CEO’s ability to execute the playbook — determine the firm’s fate.  The playbook is essentially an algorithm, and it could be quite bad, or quite good, at achieving its goal function – the company’s mission.

I think the most important parts of the playbook, in order, are:

  1. Crystal clear, compelling mission
  2. Hiring
  3. Planning/Execution, & KPI selection.

I think it is probably very advisable that the firm use Scrum for planning & execution — most obviously for product development & marketing, but I also think it should be used by every other team in the company as well.  Longer term planning activities should happen at a regular, but slower, cadence.

There are many excellent resources out there for filling in your own playbook.  Most recently I’ve been integrating ideas from Work Rules! and Scaling Up.  Y-Combinator also has a ton of material on this as do many others.  However I haven’t found resources that by themselves are entirely comprehensive.

I’ll share the full outline of the comprehensive Playbook in a few weeks.

Transitioning away from in-house manufacturing

After a lot of thought, Mark and I have decided to move entirely away from in-house manufacturing.  While it is at least theoretically possible to do in-house manufacturing quite well, and to do it reasonably cost effectively – it takes a huge amount of work and commitment.  It makes sense in some situations — perhaps because either you have no choice or it gives you some sort of advantage.  “Because it’s awesome” is not a good rationale.  This is one of the reasons why it’s good to have some good investors or advisers or board members – some sort of oversight who can call you out when you’re being dumb.

Well, Saleae doesn’t really derive any competitive advantage for in-house manufacturing, apart from the fact that it makes for cool pictures and office tours.

However, it is critical that we find an awesome partner to do the manufacturing.  Someone with ideally much better quality control and processes and capacity than we would on our own.  And ideally the same cost or lower.

I’ve heard lots of stories about factories in China needing constant supervision to assure quality – that you just have to have an engineer basically live there.  This is not something I want to deal with at all.  (I’m sure many factories in China are extremely well run, it’s not like I’ve done a comprehensive survey or something.)

Here’s a reasonable wish list for a contract manufacturing partner I think:

  • The people there are honest, friendly, generally happy, and really care
  • Turnover is low, and people think highly of the management
  • Vendor management, procurement, material resource planning is world class
  • Engineering, QA process control is excellent
  • Direct access to key people – procurement, engineering, project management, QA
  • Fast, efficient, and very clear communication
  • Open book processes, open book costs
  • Over-the-top personal endorsements from other customers at established, excellent companies
  • Reasonably long history; long relationships with other customers
  • Established customers have higher complexity PCBAs / products than yours
  • Willing to work with your volumes
  • Good final price and payment terms

I’m excited to announce that we have in fact found such a partner, and have been working together for several months now. They will be doing a 100% box build for us, for all our products.  Our costs will not increase, and I believe our quality will ultimately improve overall.

This new manufacturing partner is in Taiwan, which Mark and I had the pleasure of visiting recently – and in my estimation it is a truly wonderful country.  We really enjoyed our time there.  I believe other parts of the world may also be good places to find manufacturing partners of a similar caliber and cost.  Not 100% sure, but perhaps Poland, South Korea, and Mexico.

It is difficult to find such good suppliers, and I don’t yet have a great algorithm to share on the matter.  However it is now obvious to me that key partner selection is one of the most critical functions of the CEO (partners could include manufacturing, marketing, accounting, legal, design, etc). Here are a few ideas:

  • Don’t settle – assume that the perfect partner exists, and that your job is to find them.
  • Become comfortable traveling internationally. Spend enough time to really understand the people you’re considering working with.  Are they genuine, good people, who really care?
  • There are “tiers” of partners. They will require different “account sizes.”  You’ll need to figure out what your annual spend is likely to be is and that will automatically narrow the list of firms that will work with you.  Of course most will not put on their website “must have annual spend greater than $500,000” but a quick call will get it sorted.
  • Websites generally speaking aren’t going to be that helpful. Just start setting up calls.  These people can help educate you about the market too, so you will be increasingly sophisticated as time go on.
  • Bigger isn’t necessarily a bad thing. It could be really good if it means great processes are in place. After all, they must have done something right to get big in the first place.  So the question is – will your small account receive awesome service or not.  Will the A players at the firm at least review and sign off the work that the more junior people on your small account are doing?
  • References are everything. Insist on them, and the more the better.  Probably even call their customers that they did not explicitly give you contact information for.
  • Make sure their other customers are in some way aspirational for you. Do you think the partner’s other customers are cool, well run companies you to aspire to be like?
  • Make a comprehensive wish list, and update it as you talk to more and more people.

Ultimately you’re going to have to turn a lot of these companies down – you can only pick one after all.  For me, this is kind of rough.  But that’s life.  However, hopefully you’re now at the beginning of a wonderful, stress-free relationship — and that’s exciting.

 

 

Why we need to raise Logic’s price

I have always been quite aggressive on keeping prices low. I’m very much more a consumer products guy than an enterprise products guy. I spent a long time working on projects on the side, and I really appreciate the need for great tools that aren’t outrageously expensive – even if professional organizations are far less cost sensitive. I also am a big fan of fairness and value for money. Also, low cost is a competitive advantage in that larger companies aren’t interested in trying to compete, and new entrants aren’t lured in by the promise of massive profits. And I think it has played a pivotal role in Logic become the most popular logic analyzer in the world (logic analyzers are a very small market, but hey, that’s still pretty cool).

I was extremely aggressive on pricing for the new products. The current price includes baked in assumptions about future cost lowering activities, like more in-house manufacturing, including pick and place, machining and anodizing, and injection molding. However, implementing these cost cutting measures requires capital or access to capital. And I’m sorry to say for a number of reasons we don’t have the capitol to aggressively execute on all those measures right now.

In creating the new product lineup, in anticipation of future increased sales, we hired more engineers – not that many really, we’re talking 4-5, but it put us in a moderately cash-flow negative position, which we funded with an SBA-backed term loan. However, since the development took far longer than we wanted we ran low on reserves and so to bridge the gap to we launched a pre-order. This would have worked fine other than for two reasons: 1 – actually getting the products out the door once again took longer than anticipated and 2 – for many of our customers, Logic isn’t the sort of thing you pre-order. It’s great for individuals to pre-order, but clearly not for companies – although many still did which was amazing and awesome. So as the pre-order period stretched on longer than desired, we began burning down cash reserves again.

Ultimately we did ship all the pre-orders, and I’m happy to say that sales rates are good enough so that the new larger company is now profitable by a reasonable margin.

However – this is a paper profit and the cash flow reality is more dire. Any company requires working capital (cash set aside for inventory and cash-flow-gaps – gaps between selling and receiving payment), and I let ours get way too low.

Complicating this, quite a few months ago I decided – and convinced others – that we should do our own pick and place. The new Logic products have FAR more components than the old units, and PCB assembly costs scale with the number of components/board. Because the boards are also expensive – both the board itself and the parts on it – we cannot build in large quantities overseas without a (for us) vast amount of working capital. On paper, doing pick and place in house lets you get close to overseas costs and – critically – allows you to run with very small inventory levels when properly managed. Given the number of boards we build and the number of parts on each board (Pro 16 has 930) this adds up to a pretty compelling story.

The reality of the pick and place has been different. So far I don’t believe I did sufficient due diligence in selecting a supplier and our equipment was both delivered quite late and has been functionally problematic, resulting in slow and delayed production. We are working every day on this issue, and building as fast as we can – and after enormous effort we’re now – fairly slowly — catching up with our backorders.

All this is a long winded way of saying that we need to raise prices. I have no choice. I know it will come as bad news to many. Although I think many would agree that perhaps a Saleae with higher prices is better than no Saleae all.

The new prices are as follows:
Logic 4: $109
Logic 8: $219
Logic Pro 8: $479
Logic Pro 16: $599

In addition to playing a critical role in our near-term survival, longer term higher prices are likely to allow us, with future cost reductions, to potentially keep up a larger software developer staff and develop new features faster, the pace of which I know has been frustratingly slow since all efforts have been directed at the new product support until recently.

In addition, we are raising a small amount debt financing from private individuals to help fund our working capital requirements. Details on that can be found here.

Please feel free to write us with any feedback you like, we read and reply to it all and take it very seriously. Thank you for being a Logic customer, and for all the support over the years. It’s meant a ton to my brother and I, I can assure you.

With kindest regards,
Joe
Co-Founder & CEO

Using the SDK

Do you love your Saleae analyzer, but need it to do something extra, or do something it already does, only differently?  You can do these things, and more, with the Saleae Logic SDKs.  This post is a brief introduction to the Saleae SDKs, providing an overview of the Saleae Scripting Socket API and Analyzer SDK, along with links to documentation, resources, and source code.  Future posts about the SDKs may go into more detail, however this should whet your appetite for Logic customization and control using Saleae SDKs.

Suppose you are designing an embedded system with a requirement to monitor communications, control, or data buses, detect particular activity, and take some action when it occurs.  You could do this in the lab with Logic by using the GUI to configure appropriate triggers, capture, and analyze the data yourself, however, an embedded system usually has to take care of itself, and we can’t afford to have a human in the loop in this hypothetical production system (a human would be much more expensive, and less reliable, than Logic and some code).  This is where Logic’s SDK support comes in.  Using the SDKs, we can configure and control Logic under program control without interacting with the GUI, to capture data when triggered, and then process our captured data with custom analyzers (plugins) for more refined detection capability; when our custom analyzer plugin confirms the event of interest has occurred, the controlling program can take appropriate action.

Scripting Socket API  & Analyzer SDK

Saleae provides SDK support for controlling Logic itself, and for implementing custom plugins for data analysis.  The SDK for controlling Logic is called the Scripting Socket API, and provides programmatic control of and access to the internal functions of Logic, bypassing Logic’s GUI.  The SDK for implementing Logic plugins is called the Analyzer SDK, it provides a framework for developing custom modules to analyze data captured by Logic, and is used by Saleae developers to craft Logic’s protocol analyzer plugins.

Scripting Socket API

The Saleae Scripting Socket API http://support.saleae.com/hc/en-us/articles/201104764-Socket-API-beta gives you remote control and access to Logic’s internal functions and data through command line scripting rvia a network socket.  The Scripting Socket API source and documentation are available at  http://support.saleae.com/hc/en-us/article_attachments/201228475/LogicAutomationController.zip.  After unpacking the archive, look for the documentation, Logic+Automation+Users+Guide.pdf.

Overview

Saleae Logic Analyzers have a scriptable configuration, command, and control interface  via a network socket server, which enables you to programmatically operate Logic and export captured data via a TCP connection.  The scripting socket server is platform independent, consisting of a text-based protocol designed for sending commands to Logic and receiving responses from Logic.

Each command will return back with either an “ACK” or a “NAK” string when Logic executes the command.  If any error occurs, or if the command is unrecognized, the software will return “NAK”.  The scripting interface supports a few commands.  Some commands require arguments.  Arguments must be separated with the comma character: ‘,’.

The scripting socket server will work with any tcp client, once enabled, however Saleae provides a Windows-only console application (with C# source) which will access and pass commands and responses to and from the software’s socket for you.  The automation tester ships pre-built with the Scripting Socket API as LogicAutomationController.exe and can be found in the (bin/Release directory).

Getting Started

The socket connection default is TCP port 10429.  To use the Scripting Socket API, enable the scripting interface in the software by opening the preferences dialog from the options menu, selecting the developer tab, and then check the box for “Enable scripting socket server.”  Save these changes.

Automation Tester Program

Start the Automation Tester Program (LogicAutomationController.exe  in the bin/Release directory) and it prompts you to enter the host ip address; you’ll probably want to just hit Enter to accept the default of ‘localhost’.  Next, you are prompted to provide the host port, hit Enter to accept the default of 10429/tcp (which is the default server port Logic will be listening on, because we did not change the server port when we enabled the scripting interface in the previous step).

The Automation Tester Program will try to connect to Logic and if successful will report

Connecting…
Connected
Enter a string to xmit, q to exit.

If there is an error connecting, check connections, firewalls, etc. and try again.  If connected, you can send commands, receive responses, get help, or start demo mode.

Hitting ‘h’ followed by Enter displays example commands:

Example scripts:
set_sample_rate, 12000000, 6000000
set_num_samples, 1000000
set_trigger, high, negedge, low, none,
capture_to_file, c:/test1.logicdata

Enter a string to xmit, q to exit.

While the application is running, Socket commands can also be typed directly into the command prompt.  When creating automation scripts, it may be simpler to customize the source of the Automation Tester Program using the C# Functions as described in “Using the C# console app”, in Logic+Automation+Users+Guide.pdf..

Demo Mode

Typing ‘demo’ followed by Enter starts demo mode.  The software will run through a sequence of demonstration commands prompted by the enter key.  In Demo Mode the application calls the Demo() function within the SocketAPI class, shown below:

public void Demo()
{

StringHelper.WriteLine(“Demo Mode Initiated”);
GetConnectedDevices();
WaitForConsole();
SelectActiveDevice(2);
WaitForConsole();
SetActiveChannels(new int[] { 0, 1, 2, 3, 4 }, new int[] { 0, 1 });
WaitForConsole();
List<int> digital_channels = new List<int>();
List<int> analog_channels = new List<int>();
GetActiveChannels(digital_channels, analog_channels);
WaitForConsole();
SetNumSamples(2000000);
WaitForConsole();
Capture();
WaitForConsole();

//export captured data

List<SampleRate> sample_rates = GetAvailableSampleRates();
SetSampleRate(sample_rates.First());
WaitForConsole();
Capture();
WaitForConsole();
Trigger[] trigger = { Trigger.High, Trigger.Posedge, Trigger.High, Trigger.None, Trigger.High };
SetTrigger(trigger);
WaitForConsole();
ResetActiveChannels();
WaitForConsole();
SetCapturePretriggerBufferSize(1000000);
WaitForConsole();
Capture();
WaitForConsole();
StringHelper.WriteLine(“Demo Complete”);

}

Using the C# App

The SocketAPI class, in the automation program, directly implements C# functions for controlling the software.

An instance of the SocketAPI class must be constructed in order to establish the socket connection. The constructor takes both the IP address and port number of the requested socket. The default values are set for localhost and the default software socket port.

SocketAPI( String host_str = “127.0.0.1”, int port_input = 10429 )

{

this.port = port_input;
this.host = host_str;
Socket = new TcpClient(host, port);
Stream = Socket.GetStream();

}

The functions may then be called from the created object:

SAPI = new SocketAPI(host, port);
SAPI.FunctionCall();

Functions and commands can be broken down into several categories.  In this brief introduction we will describe one socket command and the corresponding function from each category listed in Logic+Automation+Users+Guide.pdf; for complete coverage, please review the Users Guide.

Software PreCapture

The command to get available sample rates is in the PreCapture category.

Socket Command

Socket Command: get_all_sample_rates

This command returns all the available sample rate combinations for the current performance level and channel combination.

Example: get_all_sample_rates
Response( ${digital sample rate), ${analog sample rate} ):
5000000, 1250000
10000000, 625000

C# Function

List<SampleRate> GetAvailableSampleRates()

This function returns a list of all the sample rates available for the current
performance option and channel combination.

struct SampleRate
{

public int AnalogSampleRate;
public int DigitalSampleRate;

}

Device/Channel Selection

When preparing to capture you may want to confirm the connected devices, and the Get Connected Devices command can help.

Socket Command

Socket Command: get_connected_devices
This command will return a list of the devices currently connected to the computer.  The connected device will have the return parameter ACTIVE at the end of the line.

Example:
get_connected_devices
Response
1, Demo Logic, LOGIC_DEVICE, 0x19b2
2, My Logic 16, LOGIC16_DEVICE, 0x2b13, ACTIVE
ACK

C# Function

ConnectedDevices[] GetConnectedDevices()

The function returns an array of ConnectedDevices structs. The structs contains the type of device, the name, the device id, the index of the device and whether or not the device is currently active.

struct ConnectedDevices
{

String type;
String name;
int device_id;
int index;
bool is_active;

}

Capture Data

When ready to capture, we’ll need to issue the Capture command.

Socket Command

Socket Command: capture

This command starts a capture. It will return NAK if an error occurs.

Example:
capture

C# Function

void Capture()

The function takes no parameters.

Example:
Capture()

Save/Load

After capture you may want to Save the data.

Socket Command

Socket Command: save_to_file
This command saves the results of the current tab to a specified file. (Write permission required)
Example
save_to_file, C:\temp.logicdata

C# Function

void SaveToFile(String file)
The function takes a string with the file name to save to.
Example:
SaveToFile(“C:/temp_file”)

Analysis and Export

In the next section we will introduce the Analyzer SDK; for now, we will use the Get Analyzers command to find out what analyzers are installed.

Socket Command

Socket Command: get_analyzers

This function will return a list of analyzers currently attached to the capture, along with indexes so you can access them later.

Example:
get_analyzers
Return Value:
SPI, 0
I2C, 1
SPI, 2

Please note that each line is separated by the ‘\n’ character.

C# Function

Analyzer[] GetAnalyzers()
The function returns an array of Strings, each containing the name and index of the analyzer.

struct Analyzer
{

String type;
int index;

}

Example:
Analyzer[] Analyzers = GetAnalyzers()

Analyzer SDK

The Saleae Analyzer SDK http://support.saleae.com/hc/en-us/articles/201104644-Analyzer-SDK lets you make your own custom protocol analyzers.  The Analyzer SDK and documentation are available at http://downloads.saleae.com/SDK/SaleaeAnalyzerSdk-1.1.14.zip .  After unpacking the archive, look in the documentation folder for Saleae Analyzer SDK.pdf.

Getting Started

The Analyzer SDK User Guide tells you how to set up your build environment, compile, and debug your Analyzer SDK Project in your choice of Windows, Mac, or Linux, with support for C++.  A sample analyzer source project is provided and used as an example throughout the User Guide.  The sample builds and runs out of the box.

Writing the Code for Your Analyzer Plugin

There are 4 c++ files and 4 header files that you will implement to create your analyzer.  The procedure in the User Guide describes how to build a working analyzer from the sample, and you will be modifying that code to suit your needs.  The User Guide explains customizing the sample code in detail; these are just excerpts, to get you started. Note, you may need to take a look at some of the other Analyzer SDK articles on the help center to get up and running. Depending on what version of the Saleae software you are using, or which OS could require different steps. Please check the analyzer SDK help center article for details.

Conceptually, the analyzer can be broken into 4 main parts – the 4 c++ files.

First, you’ll work on the AnalyzerSettings-derived class. You’ll define the settings your analyzer needs, and create interfaces that’ll allow the Logic software to display a GUI for the settings. You’ll also implement serialization for these settings so they can be saved and recalled from disk.

Next you implement the SimulationDataGenerator class. Here you’ll generate simulated data that can be later to test your analyzer, or provide an example of what your analyzer expects.

Third you’ll create your AnalyzerResults-derived class. This class translates saved results into text for a variety of uses. Here you’ll start thinking about the format your results will be saved in. You probably will revisit your this file after implementing your Analyzer.

Lastly, you’ll implement your Analyzer-derived class. The main thing you’ll do here is translate data streams into results, based on your protocol.

Analyzer Settings

After setting up your analyzer project, and renaming the source files to match your project, the first step is to implement/modify your analyzer’s AnalyzerSettings-derived class.  In this file, you provide a declaration for your uniquely-named, (e.g. {YourName}AnalyzerSettings class). This class must inherit from AnalyzerSettings, and should include the AnalyzerSettings.h header file.  The User Guide describes in detail how to flesh out the class including defining User-modifiable settings such as Bit rate and Bits per transfer, providing an interface object for each settings variable, writing the constructor and destructor, and completing the remainder of the necessary interfaces.

 

SimulationDataGenerator

The next step after creating your uniquely-named, (e.g. {YourName}AnalyzerSettings) files, is to create your SimulationDataGenerator.  Your SimulationDataGenerator class provides simulated data so that you can test your analyzer against controlled, predictable waveforms.  Generally you should make the simulated data match the user settings, so you can easily test under a variety of expected conditions. In addition, simulated data gives end users an example of what to expect when using your analyzer, as well as examples of what the waveforms should look like.  That said, fully implementing simulated data is not absolutely required to make an analyzer.  Besides the constructor and destructor, there are only two required functions, and two required variables.  Other functions and variables can be added, to help implement your simulated data. The User Guide provides details using SimpleSerialSimulationDataGenerator.h as an example starting point.

AnalyzerResults-derived class

After creating your SimulationDataGenerator class, working on your uniquely-named, (e.g. {YourName}AnalyzerResults) files is the next step. AnalyzerResults is what we use to transform our results into text for display and as well as exported files, etc.  In addition to the constructor and destructor, there are 5 functions we’ll need to implement: GenerateBubbleText, GenerateExportFile, GenerateFrameTabularText, GeneratePacketTabularText, and GenerateTransactionTabularText.  The User Guide provides detailed examples.

Analyzer-derived class

Your Analyzer-derived class is the heart of the analyzer. It’s here were we analyze the bits coming in – in real time – and generate analyzer results. Other than a few other housekeeping things, that’s it. Let’s get started with your uniquely-named, (e.g. {YourName}Analyzer.h).

In addition to the constructor and destructor, here are the functions you’ll need to implement:

virtual void WorkerThread();

virtual U32 GenerateSimulationData( U64 newest_sample_requested, U32 sample_rate, SimulationChannelDescriptor** simulation_channels );

virtual U32 GetMinimumSampleRateHz();

virtual const char* GetAnalyzerName() const;

virtual bool NeedsRerun();

extern “C” ANALYZER_EXPORT const char* __cdecl GetAnalyzerName();

extern “C” ANALYZER_EXPORT Analyzer* __cdecl CreateAnalyzer( );

extern “C” ANALYZER_EXPORT void __cdecl DestroyAnalyzer( Analyzer* analyzer );

You’ll also need these member variables:

std::auto_ptr< {YourName}AnalyzerSettings > mSettings;
std::auto_ptr< {YourName}AnalyzerResults > mResults;
{YourName}SimulationDataGenerator mSimulationDataGenerator;
bool mSimulationInitilized;

You’ll also need one AnalyzerChannelData raw pointer for each input. For SerialAnalyzer, for example, we need

AnalyzerChannelData* mSerial;

As you develop your analyzer, you’ll add additional member variables and helper functions depending on your analysis needs.

The User Guide describes in detail how to complete the implementation of your uniquely-named Analyzer, (e.g. {YourName}Analyzer.cpp).

 

Summary

This post introduced the Saleae Scripting Socket API and Analyzer SDK, with links to resources including documentation and code.  Watch the http://support.saleae.com/hc/en-us/categories/200077184-SDKs-Automation-Betas for updates, and look for future posts digging deeper into the SDKs.  If you have a cool custom device application or analysis plugin you’d like to share, please let us know!

How to Easily Debug Embedded Interrupts Using Logic: Part 3

In the second blog post of this feature, we showed you how to capture interrupt signals. This post is our third and final of our series on how to easily debug embedded interrupts. In this post, we will take you through how to use Logic’s measurement capability.

Measure

With our signals captured, we can determine intervals of interest using Logic’s measurement capability. Measurements can be made from a saved capture as well; to load a saved capture, on the right-hand side of Logic’s display, Options->Open Capture. Logic opens the capture at the same viewing location from when it was saved. Moving the mouse pointer to an event of interest displays the associated timing. Double-click on a signal transition to horizontally zoom in. Position the mouse pointer at the left edge of a channel display, and a left-pointing arrow appears; click on it to advance to the previous edge in that direction. On the keyboard, CTRL_PLUS also zooms in, and CTRL_MINUS zooms out.

Logic allows us to to measure timing in our ISR by moving Timing Markers to relative locations in the capture, and Logic computes and displays the result for us. On the right-hand side of Logic’s display, look for the Timing Marker Pair A1 and A2. Using the mouse, click and drag A1 and A2 to points on the capture and Logic will display the time difference A1 – A2. We can use this to measure the performance of our ISR.

Drag A1 to the falling edge of INT0, and drag A2 to the falling edge of Output1 (ISR Active); from this measurement the minimum time required from the assertion of the external interrupt INT0 to the ISR entry is 1.75 microseconds. The minimum time to enter the ISR may be critical; if a device needs service faster than this minimum, a designer may have to increase clock speed.

Drag A1 to the falling edge of Output1 (ISR Active) and drag A2 to the rising edge of the same signal; from this measurement the running time required for the simulated work done in the ISR is 17.33 microseconds. The running time of ISRs should usually be kept as short as possible, and Logic helps us measure the time required so we can evaluate the performance impact of changes to our code.

Drag A1 to the falling edge of INT0, and drag A2 to the rising edge of Output2 (ISR Done); from this measurement the minimum time required from the assertion of the external interrupt INT0 until the ISR completes and control is returned to main is 20 microseconds. The minimum time to fully service an interrupt and return control to main with interrupts enabled and ready to service a subsequent interrupt may be a limiting factor in a system’s capabilities. If servicing interrupts can’t be done fast enough, a designer may need to re-engineer the system to accomodate the service rates available, or take other actions to increase the interrupt service rate.

This video shows our measurement scenario, working with a saved capture:

Analyze Capture
Analyze Capture

Summary

We have shown how to use Logic 4 to debug embedded interrupt issues in a typical embedded system. Logic 4 provides the visibility to understand and verify the timing and correctness of embedded code.

Part 1 
Part 2
Part 3