Using Perimeter Detect



This describes the perimeter detect feature on Zymkey 4i. (This feature is not available on Zymkey 4i-lite)


Perimeter Detect provides two additional layers of physical security that can be used to detect when the perimeter of your device is breached. This is an important feature when devices are deployed in the field, unattended or in high risk enviroments.

Zymkey 4i includes two independent Perimeter Loops that can be configured to meet different applications.

(Note Zymkey 4i Lite does NOT include Perimeter Detect)

When a Perimeter Loop is breached, Zymkey 4i can be configured (at time of binding) to respond with different “Actions”, depending upon your security policy.

Connecting Perimeter Loop Circuits

Zymkey 4i uses a standard microUSB connector to interface to perimeter circuits 1 and 2. This is convenient for rapid prototyping and small scale production situations.

(For high volume applications, different connector types are available. Contact Zymbit for more details.)

Using a Standard USB Cable for Perimeter Loop

You can use a stand use a micro-usb EXTENSION cable, which carries all necessary signals, to connect to the perimeter detect. Remove the female connector if you need flying leads. See below.

Important: A standard micro-usb charging cable will NOT work, because it does not have a wire in slot 4.

Here is one example of an extension cable that will work.

Electrical Circuit

Each perimeter loop should be connected with a 30 AWG wire or thicker and nominal length of 10 feet. For longer lengths contact Zymbit. The wire should be electrically insulated for all applications. A shielded cable may be necessary for electrically noisy or industrial applications.

Custom flex PCBs and rigid PCBs may also be used to complete a perimeter loop circuit.

Perimeter Breach Response Actions

Prior to permanently binding your Zymkey to a specific host device, it can be configured through the API to respond to a perimeter breach event in one of three ways. After permanent binding is completed, the selected configuration is locked and immutable.

Response Choices

A) Do nothing (disable)
B) Notify host when perimeter breach occurs
C) Destroy all key material (this essentially destroys any encrypted data or filesystem)

Refer to API documentation for more details.

Application Examples

Coming soon

Available Dev Kits

Coming soon

ProtoKit 4 for Pi




I am very interested by the zymkey 4i product, especially by the physical tamper protection.

But I have few question:

I readed in the RTC tutorial that the coin cell only serves for the RTC, does it mean than the perimeter detection is only working when the zymkey is powered on thanks to my raspberry? In this case, how to protect from an attacker who would destroy the “enclosure” of my system while it is powered off, and also the perimeter two perimeters loop circuits? I mean, in “therory”, I guess it could easily identify the zimkey, and juste put two illegitimate loops circuit in the receptacle, to fake the zimkey before to put the system on again. Am I wrong? or maybe I am missing something?

In this case, does it mean the perimeter features is “nothing” without a strong “physical” protection like expoxy on the SD and the zymkey? So why to not use the coin cell to make the perimeter protection always activated?

By the way, is it possible to extend the RTC battery life, for example if I put many CR2032 coins in parallel?

And to finish, do you know when you could be able to release application examples and dev kits for the perimeter detection?

Thanks by advance!

By the way, your product looks really cool, good job!


Hi Tgratier,

  1. Perimeter detect does already work with battery backup, Otherwise, as you point out, its pretty useless. The Pi, Zymkey and Battery should be enclosed in one or both of the perimeter loops.

  2. Zymkey 4i is designed to accept CR1025 coin cells, with nomimal lifetime of 1.5 years (host not powered), 3-5 years (host powered 75% of time). There is no mechanical provision for larger coin cells, but electrically if you wanted to hot wire a larger battery of the same voltage, that should work, with some caveats. We do have some OEM products in the works that will allow the user to apply an ‘external battery’. Contact Zymbit to discuss the specifics of your application in more detail.

  3. We will release some application notes for perimeter detect in a couple of weeks. (Sept 21).

Thanks for your interest.


Ok thanks for the quick answer! I am glad to see I was misunderstood haha.
And sorry for my mistake about the coin model.


No apologies required. We are hear to help !


do you have any news about some applications notes release for perimeter detect?
Thanks by advance :slight_smile:



Putting together a general use case app note always takes longer than a specific use case, so sorry for the delay. We should having something up next week.

If you have a specific use case and need answers now then please contact us here


Ok cool, I will wait!
Thx :slight_smile:


From the initial specs I read “Optional accelerometer detects shock and orientation change events”. How can I use acceleromoter? Is this one of the two perimeters loops? What means optional? I am interested in ZYMKEY 4i.


If you bought the Zymkey 4i, the accellerometer comes as standard.

You will find details of how to use the accellerometer in the documentation, here: API Documentation

zymkey 4i 3i feature matrix 1707


Thanks, I understand acceleremeter is device integrated and doesn’t use(occupies) any of the two perimeter loop circuits
From introduction I also read “Power rail monitor detects anomolies like brown-out events”. I can not find any reference in the API documentation, can you tell me where to read about? Is this the mechanism used by perimeter loop system or something I can check from the API?


Your Zymkey contains three different layers of Tamper Detection. Each operates independent of the other:

  1. Accellerometer - accessible through API
  2. Perimeter detection loops x 2 - accessible through API
  3. Power rail monitor - for internal defense only. NOT accessible through the API


While waiting for the sample app, if USB is open (nothing connected) and run a script with these commands, should event happen?:
zymkey.client.wait_for_perimeter_event ()


I forgot to configure notification:
zymkey.client.set_perimeter_event_actions ( channel = 1, action_notify = True , action_self_destruct = False )


Happy to hear you found the solution.





it’s me again, for few questions.

I am trying to execute a periodic check of the PERIM1 circuit.
The code below works well during first rounds, but suddenly the breach action is not anymore detected.
After few minutes, it start to work well again, etc. If I reboot the pi, the code will works directly (during few rounds again).

I simply connect a USB cable with white and black wires connected, and make them touch themselves during the tests. I can’t see anything wrong in /var/log/syslog.

Is this my routine code which is not the best way to check the perimeter loop? Why is my zymkey just “stop to work” during few minutes? Should I use “zkWaitForPerimeterEvent(ctx, 0);” ?

By the way, in the code below the “num_timestamps” value is ALWAYS equal to “2”. Why 2 whereas I only set an action for the PERIM1 circuit and not PERIM2?

Thx by advance.

int num_timestamps = 0;
uint32_t *tab_event;
zkCTX ctx;

if(zkOpen(&ctx) <0)
	printf("Unable to setup RTC module\n");
	return 0;
zkSetPerimeterEventAction(ctx, 0, ZK_PERIMETER_EVENT_ACTION_NOTIFY);

	 *	do_something

	zkGetPerimeterDetectInfo(ctx, &tab_event, &num_timestamps);
	if(num_timestamps > 0)
		printf("num timestamp = %d\n", num_timestamps);
		printf("Last event = %ld\n", tab_event[0]);
		zkLEDFlash(ctx, 500, 500, 4);
		num_timestamps = 0;